위키에 바란다

1 # 대충 생각나는대로 일단 적어본다[ | ]

서브페이지 내에서만 랜덤 페이지가 적용되게 확장했으면 좋겠다.
쌍둥이 페이지 나오는 부분이 아래 이 페이지를 수정 덩덩덩 라인에 낑겨나오면 좋겠다.

myinterest 매크로는 mostpopular처럼 몇개만 본다라는 규정이 필요하며 myrecentchanges역할도 할 수 있어야 한다.
includeday 매크로 다음에 표같은 것이 안먹는다. 페이지 이름을 생략해도 안먹는다.
orphanedpages 매크로에서 하위페이지로의 링크가 있는데 미아 페이지로 인식한다. 거북이/바보라는 링크가 있고 거북이 페이지에 [ [/바보] ] 이런 링크가 있으면 이것은 링크가 아닌 것으로 인식한다.
- REDIRECT가 있는 미아 페이지는 빼야 한다.
페이지삭제나 이름변경도 RC에 마이너로 뜨고 페이지 삭제도 복구가 가능하도록
숨겨진 페이지나 사전처리된 어휘들같은 경우 조그만 태깅이 필요하다

2 # 레퍼런스[ | ]

유즈모드위키 : http://koreanrock.com 소스변경1 소스수정2
모인모인 : http://no-smok.net
PHPWiki : http://gpgstudy.com/gpgiki/
Wikipedia(php) :
스위키 : http://linux.dnip.net:8000/public/
wikiX : http://geni.cemtlo.com/wikix/ --> php + PostgreSQL/MySQL 동시 지원 (개발자:조희대님) http://www.godisgreen.com : 대단한 열정의 소유자!

3 # 로그인과 사용자 정보 관리[ | ]

가입절차 필요없이 이메일과 패스워드로 로그인
사용자 정보관리 페이지에 사용하려는 항목들
웹브라우저 닫은 다음에 로그아웃되게 할 것을 선택가능하게 하는 것이 좋음. 제로보드 참조.
- 로그인/아웃 관련 메뉴는 전면노출
- 별명 세팅 가능
- 관리자암호 설정가능 (모든이 쓰기가능, 허가받은 자만 쓰기 가능, 운영자만 쓰기가능)
- 페이지 접근관리. 페이지별로 보기권한 쓰기권한을 부여할 수 있도록. 심하면 매번 로그인해야하는 페이지도 만들 수 있게.

4 # Recent Changes[ | ]

마이너 에딧의 한계를 정해주어야 한다. 그렇지 못하면 악의적으로 이용할 수 있다.
- 일정 바이트 이상을 고치면 마이너 에딧으로 인정하지 않는다
- 일정 로열티가 쌓이지 않은 사람에게는 마이너 에딧을 허용하지 않는다 : 일종의 자동체크?
- 마이너 에딧을 체크해서 세이브하면 RC에 마이너 에딧임을 표시해주고 마이너 에딧까지 보기, 마이너 에딧 안보기의 옵션을 주면 매끄럽게 해결될 듯
- 그냥 세이브를 해도 일정 바이트 이하가 수정되면 자동으로 마이너 에딧을 표시해준다. RC에서는 보여준다.
생각해보니 마이너 에딧이 있으면 메이저 에딧도 있어야지.
특정분류의 RC보여주는 방법을 어떻게 할것인가. 디폴트 RC를 설정할 수 있게 한다.
RC에 나타나는 최종 수정자를 중복되지 않게 5명까지 보여주고 풍선도움말로 고친 시각과 IP를 보여주면 좋을듯 하다.
로그인을 한다음 특정 링크를 누르면 그 사람이 한번이상 작성한 적이 있는 페이지만 RC에 뜨게 해준다. 그 횟수는 개인적으로 조절할 수 있으며 여러번 수정한 페이지라면 더욱 눈에 띄는 색으로 나오도록 할 수 있을것이다.
역시 나만의 커스터마이징 된 RC를 만들 수 있어야 한다. 모든 페이지에 개인페이지로 만들기/개인페이지에서 제거하기 토글 버튼을 만들면 간단하게 할 수 있다. 로그인만 되어있다면.
모인모인처럼 새 페이지와 수정된 페이지를 구분하는 기능.

5 # 분류[ | ]

대분류명을 지정하여 RC를 미묘하게 제어할 수 있도록
해당 분류 페이지는 수동으로 수정하는 것이 바람직
자동구성되는 페이지는 해당 분류 페이지를 일단 모두 노출하는 정도로만
- 아티스트명만 따로 모아서 musicisland.org의 메뉴같은 콤보상자가 생기는 형태의 구성이 가능하도록 만들 수도 있을것
  - 저자동 고유연성 원칙에서 너무 먼가?
- 규칙은 어떻게 만드는 것이 좋을랑가.
사람 손으로 인덱싱을 만들게 하되 페이지 명으로 인덱싱 재구성이 가능하도록 하면 되겠다. 최근 올라온 순서로도. 링크 하나씩만 달아주면 되는거 아닌감.

6 # 메뉴[ | ]

Or try one of these actions: DeletePage, DeleteUploadedFile, LikePages, RenamePage, SpellCheck, UploadFile
- 이중 쓸만한 것은 UploadFile DeleteFile 정도군.
  - 그 페이지와 관련된 첨부파일의 경로들을 보여주는 페이지가 있으면 관리에 좋겠다.
- RenamePage DeletePage는 함부로 허용하기엔 너무 무모한 감이 있다.

7 # 차이점[ | ]

diff를 보여줄 때 지금처럼 한 문단단위로 보여주기 보단 특정 단어가 사라지고 특정 단어가 생겼다는 것 위주로 보여주는 것이 어떨까. 글자들 위에 가운데라인이 깔리는 태그 있자너 왜.

8 # 링크[ | ]

위키 네이밍에 관하여.
- 이건 노스모크가 잘하고 있다.
[[ ]] 외의 대안은 없나? =.=
스페이스가 꼭 없어야만 할까?
역링크
PhpWiki의 장점이라고 할 만한 것은, 페이지에 대한 역링크들이 페이지 하단에 요약되어 나온다는 점이다. 5 best incoming links 가 바로 그것이다. 또한 그 반대의 링크들, 즉 이 페이지에서 나가는 링크들인 5 best outgoing links 도 있다. 5라는 숫자는 시스템 관리자가 바꿀 수 있다. 모인모인에도 도입하면 좋지 않을까....
유즈모드위키에 주석달기 기능이 있는것 같은데 왜 안먹지
그림도 인터위키로 걸어서 직접 로딩이 되도록 하는 것이 낫다. CD ISBN:처럼
현재 앵커 기능에 버그가 있다. 영문으로 두단어 이상으로 된 페이지의 앵커는 잘 되는데 한글이나 한단어 페이지의 앵커는 안먹는다.

9 # 페이지 만들기[ | ]

페이지 만들기 마법사가 하나 필요할듯
- 템플릿 제공
누군가가 페이지 수정중일때는 락을 걸어서 다른 수정요청자를 기다리게 하는 것은 좋은듯
- 상당히 심각한 문제. Edit This Page를 다른 녀석이 눌렀을 때 그때 걸어주면 될 듯 하다.

10 # 이미지[ | ]

이미지를 문단의 왼쪽 오른쪽에 포함되어 위치할 수 있도록 하자.
이미지 파일명 및 확장자 인식의 문제 : 예를 들면 한글 이름으로 된 이미지나 혹은 JPG, GIF 확장자 파일을 읽는데 문제가 있음

11 # Text Formatting[ | ]

하테나의 텍스트 포매팅 룰
페이지 템플릿을 분류마다 설정할 수 있게
테이블이 현재는 하나의 문단만을 하나의 셀에서 처리하는데 여러 문단도 하나의 셀에서 처리하도록 하자.
- 그 방법으로는 현재 모인모인에 있는 {{| |}} 기능을 이용하여 이것으로 묶인 것들을 하나의 셀로 인식하게 하면 될 것이다.
- 하는 김에 {{| |}}기능도 만들고
- 자유로운 테이블 형식의 지원이 요망됨 : 1.5 시간짜리 수업이 중간 중간에 끼여 있는 시간표 등을 만들 경우라든가...
인터위키는 그냥 NoSmok:따위의 앞부분은 안보여주는 것이 좋다. 색으로 구분해도 좋으리라. 없는 페이지도 ?로 표시하기 보단 색이나 이탤릭 등으로 표기하는 것이 낫다. sfreaders.org참조
이미 포매팅 룰과 렌더링 룰은 어느정도 구분이 되어있다.
텍스트 뿐만 아니라 이미지 생성, 등록, 수정 기능도 제공할 필요가 있다. 수식까지 제공하면 더욱 좋다. 다양한 첨부파일의 종류에 따라 적절히 첨부파일을 본문에 삽입시켜주는 기능을 제공할 필요가 있다. 오에카키를 참조하자. 워드프로세서도.

11.1 Text Foratting Rules[ | ]

12 # 검색[ | ]

전문검색, 정규표현식 검색
제목검색, 인접검색
- 노스목의 제목검색이 인접검색결과로 나오는건 아주 맘에 든다.
검색창의 디폴트 세팅은 페이지제목검색결과겠지.
찾기/바꾸기 기능이 필요한데 모든 페이지를 뒤져 특정 텍스트를 바꾸는 정도면 될 것이다.
- 이 때 한번 바꾸면 회복이 안되기 때문에 가능하면 백업후 바꾸고 컨펌할 수 있게 해주는 것이 나을까나?
- 어차피 잘못 바꾼건지 잘 바꾼건지 파악하는 것은 매우 어려운 일이라 무용지물일수도 있겠다만 그래도.
- 역시 이것은 매니저만 가져야 할 기능이다.

13 # 인덱싱[ | ]

전체보기를 ABC순이나 가나다순으로 보기도 필요하지만 이것이 메인에 있을 필요는 없다.
카테고리 별로 인덱싱을 볼 수도 있어야 한다.
- 인덱싱 결과물을 정규화해서 그것을 콤보상자에 넣을 수 있다면 난 행복할거다.

14 # 게시판과의 융합[ | ]

일반 게시판의 짧은 리플처럼 피드백을 받을 수 있는 칸을 세팅에 따라 넣고 뺄 수 있게 한다.
- 이때 받은 피드백은 문미추가방식으로 위키에 올라간다.
- 당연히 올라간 글은 위키의 관리방식에 따른다.
- 위치도 조절가능하다.

15 # 데이터 백업[ | ]

16 # 페이지 전반을 관리하는 기능[ | ]

intermap emoticon 직접수정
이모티콘 사용 토글
config는 사용자별로 따로 만들 수 있게 하고
페이지 이름 수정
본문 단어 전체 페이지내 수정
- 매니저만 가능하도록 권한 설정이 필요
백업을 위한 데이터 파일과 설정 파일의 별도 관리
메인 메뉴의 위치와 구조를 개인별로 설정할 수 있어야 함.

17 # 부가기능[ | ]

기능상으로 봤을때 제목변환 뿐 아니라 텍스트 전체 변환 기능이 필요하다. 특히 링크걸기 할 때.
페이지 리다이렉션
링크에 풍선도움말로 페이지 정보를 보여줌 : 최종생성일, 수정횟수, 조회수 등등
읽어야 할 글을 모아두는 워칭기능. pediawiki

18 # 통계 & 매니지[ | ]

조회수
- dead link에 대한 접근 조회수를 파악할 수 있어야 한다.
- 내부링크로부터의 접근 조회수와 외부에서 접근한 조회수를 구분해야 한다. 페이지 이름바꾸기 등을 할 때 필수적인 고려요소가 된다.
피링크수
수정횟수
몇사람이 그 페이지에 참여했는지 카운팅
노스목에서 했던 엔트로피 측정도 가능하지 않을까? 하하
- 엔트로피 측정은 그 수치를 어떻게 수식화하느냐에 따라 달라진다. 실제로 의미있는 숫자를 만들기는 그리 쉽지 않다.

19 # 기술적이 문제들 몇개[ | ]

인터위키 관련 버그수정
- 인터위키에서 한글제목이 네 글자 이상 될 때 제대로 링크가 되지 않는다. (예, NoSmok:쉬운위키소개) 이건 위키에바란다가 아니라 버그리포트에 써야 하는건가...?
- 더 심각한 버그도 있다. 노스모크의 "위키위키"라는 페이지를 인터위키로 링크하면 엄청난 일이 벌어진다.-.-
업로드

20 # include[ | ]

인클루드를 사용하면 위키의 태그가 적용되지 않는다.

21 # 변신된 위키[ | ]

위키를 이용한 협업시스템을 생각해볼 수 있겠지. 심하면 Team Source로도 쓸 수 있지 않으려나.
For kpopdb.com

자료의 부분수정 알고리즘에 대해 생각해보자

일단 필드를 자세히 쪼갠다.
각각의 필드는 위키스타일로 정보가 수정가능하게 만든다.
사용자가 정보를 수정하면 운영자에게 알림이 날아간다.
운영자는 그 정보의 순도(?)를 파악하고 +-점수를 부여한다. 동기부여책.
정보가 올바로 수정된 것인지를 운영자가 파악하고 그 수정안을 고정시킨다.
다음에는 사용자가 정보를 수정하려 해도 고정된 수정은 고칠 수 없음, 그것을 고치려면 다른 커뮤니케이션 수단을 거쳐야 함.

이정도면 괜찮겠구먼.

중간중간에 삽입하면 더 혼란스러울 것 같아서 여기에 모아서 약간의 의견을 첨부합니다.

include 매크로에서 위키태그가 적용되지 않는 문제와 인터위키에서 한글로 된 페이지제목을 제대로 처리하지 못하는 문제는 Jof님홈페이지에서 해결책을 볼 수 있습니다.

부가기능 항목에 있는 페이지 리다이렉션은 지금도 될 텐데요. 페이지 내용 제일 처음에 "#REDIRECT 다른페이지이름" 이라고 넣어주면 됩니다.

마이너에디트를 악의적으로 이용할 수 있다..라는 부분이 잘 이해가 안 됩니다만... 혹시 제가 처음 UseModWIki 를 사용할 때 가졌던 오해를 여기서도 가지고 계신 게 아닌가 해서 말이죠.. 마이너 에디트를 체크하고 저장할 경우, 별도의 revision 이 만들어지지 않고 최근 revision 에 포함되어 버리는 것처럼 오해할 수가 있는데, 그렇지 않거든요.. 마이너 에디트를 체크하든 하지 않든 페이지를 수정하면 별도의 revsion 으로 저장이 되기 때문에, 얼마든지 이전 상황으로 복원할 수 있습니다. 다만 각 페이지에 대해 diff 를 클릭했을때, 바로 직전의 minor edit 만을 보여줄 것인지 아니면 minor edit 는 무시하고 major edit 부터 보여줄 것인지를 Prefereces 에서 설정할 수 있을 뿐이죠. 음... 아니면 제가 미처 생각하지 못한 다른 문제점이 있는 건지...

현재도 RC 화면에서, minor edit 를 별도로 보여줍니다. preference 에서 "소소한 수정 출력방식" 을 "보여줌" 으로 했다면, RC 화면에서 마이너에디트된 페이지 옆에는 "(edit)" 라고 나옵니다.

지금 언뜻 떠오르는 것들을 간단히 정리하자면,

위키위키의 기능요소들을 모두 well-define한다. 글쓰기, 수정, 링크만들기, 링크연결하기, 링크검색하기, 제목순정렬, 수정일자순정렬 등등등.
FormattingRule과 RenderingRule을 분리시킨다. 이것은 마치 HTML에서 의미중심의 태그와 화면출력중심의 태그가 구분되고, 브라우저에 따라 Rendering방식이 다른 것과 비슷하다고 볼 수 있다. FormattingRule은 글쓰기의 Style을 중심으로 구성되어야 하고, 이 FormattingRule을 어떻게 화면에 Rendering할 것이냐는 또다른 문제이다. 이용자별로 RedenringRule을 선택하는 기능도 생각해볼 수 있다. emoticon을 그림아이콘으로 보여줄 것인지, 그냥 문자열로 보여줄 것인지 각자 선택할 수 있지 않을까?
다양한 분류, 랭킹에 따른 나열을 지원할 필요가 있다. 조회수가 높은 문서, 수정회수가 높은 문서, 생성일이 최근인 문서, 링크를 많이 받은 문서 등등이 나름대로 다 의미가 있다. 단순하고 무의미한 RandomPage 따위로 문서를 밖으로 끄집어낼 것이 아니라, 다양한 기준에 따라 전체 문서들을 적절히 바깥으로 노출시켜주는 기능이 필요하다. 이런 것들은 노가다에 의존하지 않고 얼마든지 자동으로 처리할 수 있다. 물론 위키스타일의 장점을 살려 그 목록을 손으로 재처리하는 것도 가능하다.
텍스트 뿐만 아니라 이미지 생성, 등록, 수정 기능도 제공할 필요가 있다. 수식까지 제공하면 더욱 좋다. 다양한 첨부파일의 종류에 따라 적절히 첨부파일을 본문에 삽입시켜주는 기능을 제공할 필요가 있다. 오에카키를 참조하자.
위키는 그다지 혁명적이지 않다. 다만 처음 쓰는 사람이 쉽게 이해하기 어려울 정도로 시스템이 난해하게 꼬여있다. 처음 글쓰는 사람에게는 상세한 규칙같은 건 설명할 필요도 없고, 그냥 주제별(제목별)로 글쓰고 아무나 수정할 수 있으며, 괄호를 이용해 다른 문서의 제목으로 링크시킬 수 있다는 있다는 것만 설명하면 된다. 나머지 상세한 위키만의 문화는 사람들이 저절로 쉽게 알아차리고 자신들만의 규칙과 문화를 만들어 나간다. 스스로 깨달으면 되는 것을 미리부터 틀에 가두어 통제하려 들지만 않으면 된다.
상단 메뉴의 Index 같은 것은 사실 영 잘못된 메뉴이다. 글수가 수십개를 넘어가면, 그때부터 Index는 의미가 없다. 제목순으로 정렬된 목록을 봐서 뭐하겠다는 것인가? 자신이 여태까지 쓴 글의 제목을 보며 뿌듯해하는 것 이상의 의미가 없다. Index의 위치에는 전체 글의 목록을 다양한 기준으로 나열할 수 있는 그런 기능을 제공하면 되는 것이다. 전체 문서집합을 어떤 기준으로 칼질을 하고, 그 단면을 들여다볼 것인가에 초점을 맞추면 된다. 유의미한 칼질의 방향이 무엇인지 고민하자.
Login과 필명을 완전히 분리시키는 것이 이용자들을 오히려 덜 헷갈리게 만든다. Aragorn의 경우, WikiName과 필명, 글제목, 링크달기 등등 때문에 TWiki를 처음 쓰면서 수시간동안 헤맸다. 상당히 짜증나는 경험이었다. Login은 말그대로 인증을 위한 절차로 간주하고, 이메일 같은 것을 LoginName으로 쓰도록 유도하고, 개인 필명은 말 그대로 필명으로 생각하면 된다. 많은 사람들이 자신의 ID과 또다른 필명을 즐겨 쓴다는 사실을 주목할 필요가 있다.
카테고리관리기능, 특정 카테고리별 RecentChanges 기능, 임의의 카테고리들에 대한 RecentChanges 기능 등이 필요하다. 커다란 주제에 따라 선별적으로 글을 보는 기능은 반드시 필요하다. 사람이 글을 쓰는 커뮤니티를 정적인 시스템이라 간주하지 않고, 역동적이고 변화무쌍한 시스템으로 생각한다면, 반드시 구현해야 하는 기능이다. 경우에 따라 주제를 분리시킬 수도 있고, 통합할 수도 있으며, 주제가 크게 분리된 경우 아예 위키위키를 분리시킬 수도 있다.