KLDP의 향후 운영 방향에 대한 현실적인 개선 아이디어는?

권순선의 이미지

올해 2006년은 kldp가 10주년이 되는 해입니다. (1996년 10월 5일~) 그동안 static html --> 쉘 스크립트 --> perl을 이용한 yahoo 형식의 카테고리 엔진 --> docbook 채용 --> wiki 등 여러가지 형태의 소프트웨어들을 통해서 이곳을 업그레이드해 오면서 관리자의 손길은 최소한으로 줄이는 방향으로 작업을 진행해 왔고, 여러가지 사정을 감안해 볼 때 그 방향에 큰 문제는 없었던 것으로 생각됩니다. 그러면서 사용자들의 문제점들을 공유하기 위해 곁다리(?)로 만들었던 게시판-처음에는 kldp에 게시판은 없었고 질문/답변 게시판은 특히 일부러 달지 않았었습니다-이 지금은 가장 많은 사람들이 이용하는 서비스가 되었고 제 개인적인 느낌만인지는 모르겠지만 많은 사용자들이 오직 *.kldp.org 나 kldp.net 등 다른 곳에 대해서는 큰 관심이 없이 이곳 kldp bbs에서만 머무르는 현상이 날이 갈수록 심화되고 있는 듯 합니다.

그리고 kldp bbs 안에서도 질문/답변 게시판과 자유 게시판 외의 다른 게시판에서는 새로운 글의 빈도가 그다지 크지 않고, 그나마도 자유 게시판은 일부 사용자들이 가벼운 농담 따먹기(?)의 장소로 이용되기도 하고 이에 대해서 별도로 논쟁까지 일어나는 등 그다지 생산적이지 못한 현상들이 주기적으로 발생하고 있습니다. 저는 사실 이러한 현상들이 전혀 낯설지 않으며 기간의 차이는 있지만 이곳에서 반복적으로 발생하고 있는 일입니다. 이런 현상들은 좋다/나쁘다라고 이야기할 수 있는 성질의 것이 아니고, 방문자들이 '사이트의 목적에 부합하는 분야'의 컨텐트에 대한 생산/소비에 집중할 수 있는 적절한 방법을 찾지 못한 관리자의 책임이라고 생각합니다.

그래서 http://bbs.kldp.org/viewtopic.php?t=66847 과 같은 식의 고민을 시작하고 어느 정도 구체적인 그림까지 그려 보았는데 과연 잘 될 것인가 하는 걱정이 많이 들어 이에 대한 사용자 여러분들의 생각을 듣고 싶습니다. 개편 방향의 핵심인 drupal을 활용한 New KLDP를 통해서 기존의 kldp wiki, kldp bbs, geekforum등이 drupal 아래의 각 기능들(wiki, forum(bbs), blog(geekforum))으로 통합되고 여기에 개인 블로그까지 별도로 설정할 수 있도록 하게 된다면, 그리고 kldp.org의 초기화면이 더이상 각 사이트들로부터 만들어진 신규 컨텐트의 기계적인 업데이트 상황이 아닌 관리자가 선정한 컨텐트 혹은 방문자들의 투표를 통해서 선택된 컨텐트만이 강조되어 웹로그 형식으로 보여질 경우에 KLDP가 좀더 FOSS에 실질적으로 기여할 수 있는 공간으로 거듭날 수 있을까요, 아니면 사용자들은 별다른 신경도 쓰지 않으면서 괜히 불편하고 생소해지는 결과만을 낳게 될까요? 다른 분들은 어떻게 생각하시는지 매우 궁금합니다. 그 외에 위에 말씀드린 방법 말고 다른 더 좋은 아이디어가 있으시면 올려 주세요.

댓글

keizie의 이미지

개편 투표 쓰레드에도 적었습니다만, 위키를 다시 만드는 건 별로라고 생각합니다. 모니위키가 지원하는 SisterWiki 기능을 위키가 아닌 영역에도 적용할 수 있는데, SisterSoojung을 시도했었고 가능성을 확인했습니다. 예전에 blog.kldp.org가 잠깐 생겼을 때도 (그게 drupal이었죠 아마?) 그 비슷한 걸 하려고 생각했었는데 어느샌가 blog.kldp.org가 없어져서 그냥 접었더랬죠. 사이트 엔진 설정에서 조금만 지원해주면 기존 위키와의 자연스러운 연동은 쉽게 할 수 있습니다. drupal로 바꾸게 되고 기존 위키를 계속 쓰도록 결정이 나면 그 연결 부분을 구현할 용의가 있습니다.

이와 더불어 phpBB에서도 불만이었는데, 다른 부분에도 위키 방식의 제목 기준 링크를 만들고 싶습니다. phpBB를 뜯어보지 않아서 어떻게 하면 되는지는 모르지만 어차피 사람이 만든 건데 고치다보면 되겠죠. 물론 지금 있는 위키의 페이지 이름 규칙이나 링크 방식 자체도 편하지만은 않습니다. 여전히 개선의 여지가 있고 이건 꾸준히 개선해야 한다고 생각합니다. 그래도 http로 모든 링크를 시작하는 phpBB나 다른 것들보다는 훨씬 뛰어납니다.

그리고, blog.kldp.org에서도 봤지만, 개인 블로그를 굳이 KLDP에서까지 제공할 이유는 없다고 생각합니다. 이미 블로그는 거의 모든 사이트에서 당연히 제공하는 분위기가 되었고 사람들마다 한 개 이상의 블로그 페이지를 운영하고 있을 거라고 생각합니다. 지금 bbs.kldp.org에서 보이는 'FOSS스럽지 않음'이 개인 블로그에서는 훨씬 심해질 것이라고 생각합니다. gnome.or.kr/pgk에서 보이는 해커다움을 blog.kldp.org에서까지 기대하는 건 무리라는 거지요.

그런데 geekforum을 되살릴 수는 있나요? 할 수만 있다면 긱포럼을 되살려내는 것도 중요한 목표라고 생각합니다. 거기서 논의했던 것들과 그걸 자체적으로 책갈피 잡아둔 것들이 있으면 좋겠다고 가끔 생각하거든요. 특히 자체 책갈피 기능은 phpBB에서 참 아쉽습니다. 어느 한 쓰레드나 포스트를 개인정보의 어딘가에 기억해두는 게 마땅치 않아서 따로 브라우저의 책갈피에 넣어야 되니까요.

권순선의 이미지

http://drupal.org/project/interwiki 에 이미 그런 기능을 하는 비슷한 모듈이 있습니다. kldp wiki에 적용할 때 참고하려고 꼽아둔 것입니다. 참고하세요... :-) 그리고 wiki를 완전히 새로 시작할 것인지, 혹은 기존 데이터를 그대로 가져가는 것이 좋을지를 결정하는 것은 phpbb 데이터의 변환, 그리고 moniwiki가 drupal과 얼마나 잘 융합될 것인가에 대한 고민이 먼저 해결된 후에 생각할 일입니다.

phpbb에서 위키 방식의 제목 기준 링크라고 하는 것은 어떤 것인지 잘 모르겠네요. 좀더 자세한 설명 부탁드립니다.

블로그는 불특정 다수에게 모두 사용할 수 있게 하지 않고 정해진 사용자에게만 허용하면 될 것입니다. 지금과 같은 형태의 bbs에서는 칼럼과 같은 식의 글이 올라올 것이라고는 기대하기 어렵다고 보기 때문에 자신의 의견을 좀더 자유롭게 표현할 수 있는 블로그와 같은 형태의 공간이 필요하다고 생각했습니다.관리자가 적절한 블로그 엔트리/위키 엔트리/bbs 글타래를 골라서 초기화면으로 올리거나 혹은 사용자들이 개별 컨텐트에 대해서 투표를 할 수 있게 하여 일정 갯수 이상의 점수를 받는 컨텐트가 kldp.org 초기화면으로 올라가도록 설정하는 것도 가능하니.... 그러다 보면 geekforum과 같은 식으로 활발하게 운영되는 블로그도 생기겠지요.

ed.netdiver의 이미지

저도 kz님의 의견에 동의합니다.
blog부분은, gnome pgk형태가 kldp에도 있으면 하는 바램이 있었습니다.

많은 사람들이 FOSS에의 진입장벽을 이야기해왔지만, 이건 예전 perky님의 말씀에서처럼 각자의 기호와 관심사로 알아서 진입하는것이 맞는것 같습니다.
그러면서도 mentor/mentee system을 희망하는 사람들이 많은데, 이런 욕구를 굳이 BSD의 그것처럼 구축한다기보다는, category와 level로서 적절히 분화시키면 어떨까 싶습니다.
뭐랄까, category라고 하면, language, 각 분야별로 나눈다고 했을때, 그 level을 몇단계 나눌수 있는 구성이 된다면, 각자가 알아서 그 category에 들어가서 level up을 이룰수 있도록 하는거죠.
적절하게 표현이 안되는데(첫 출근의 부담으로 잠을 설쳤더니 머리가 멍~ㅎㅎ), C언어라면, 언어 자체를 배우는 레벨이 있겠고, sourceforge같은 적당한 프로젝트를 몇개 던져준다거나, 혹은 같이 issue화해서 고민해본다거나 하는 식의 study level, 그 다음에는 독자적인 project를 고민하는 level 이런 식인겁니다.

kldp.net의 경우 관심사가 같은 이들이 해당 과제에 참여하는 형태인것인데, 한편으로는 각 프로젝트간의 사용언어같은 공통분모랄지 하는 부분에서 여러 프로젝트 참여자들간에도 논의해볼수 있는 여지가 있을것 같거든요.
사실 이런 얘기는 기 개발자들 입장에서야 참여 혹은 monitoring으로 끝날 성질의 것이긴 한데요, ajax를 사용하는 여러 플젝의 경우는 ajax자체에 대한 고민은 모아져도 될성싶다 뭐 이런 식입니다. 그러는 가운데, mentee입장에 서는 사람들의 breeding도 되지 않겠나 하는...

아, 역시 머리가 멍해 정신없이 주절거리기만 하는것 같습니다.
요는, 1:1 mentor system구축이 아닌 n:n system을 category와 level 세분화 및 그에 따른 게시방 마련(현재 kldp구성으로 보자면) 형태로 가져가보는것은 어떨까 싶은겁니다.

두서없는 얘기 끝까지 읽어주셔서 감사합니다.
새해 복많이 받으시고, 건강하세요~

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

paek의 이미지

왜 매번 무언가 변한다고 하면 이제는 두렵습니다.

무언가를 또 배워야 되게 됨으로 인해서 (특히나 한국 대부분의 웹사이트와 다른 방법) 그로 오는 압박과 시간적 여유..

대부분 KLDP에 오는 사람들을 개인적으로 고려를 해봤을때, 대학생들과 직장인들이 주를 이룬다고 볼수 있으며, 이들이 자신의 학업또는 직장의 업무 이외에 새로운 게시판 적응을 위해서 무언가를 배우고 그 인터페이스에 익숙해지기 위해선 꽤 많은 시간이 걸릴꺼라 보입니다..

문론 KLDP 에 계속적으로 방문 하던 이들께서는 계속 방문 할지 모르겠으나, 오히려 개편때마다 점점 사용자들이 줄어드는걸 느끼는건 저뿐만인지 모르겠습니다.

예전 초기 KLDP 의 경우 관련 번역문서나 번역되어져 올라오는 관련 기술 문서들이 꽤 많았던것으로 기억됩니다만, 요즘은 그런 분의기는 하나도 안느껴지고 오로지 게시판만 활성화 되어 있는 KLDP 로 느껴집니다...

개인적으로는 첫페이지에는 그냥 예전 처럼 무언가 문서등을 찾기 쉬운형태로 갔으면 좋겠다는 생각이며, wiki 같은것으로 글쓰는걸 상당히 어려워 하는 이들이 많다는것을 감안한다면, 국내 실정에 맞는 에디터 같은 방식으로 가는것이 좋으리라 판단 됩니다.

--------------------------------------------------------

세상에서 나의 존재는 하나이다.
그러므로 세상에서 나는 특별한 존재이다.
-
책망과 비난은 변화가 아니다.
생각만으로 바뀌는것은 아무것도 없다.

keizie의 이미지

권순선 wrote:
phpbb에서 위키 방식의 제목 기준 링크라고 하는 것은 어떤 것인지 잘 모르겠네요.

가령 어떤 쓰레드를 가리킬 때 http.....t=nnnn이 아니라 [쓰레드 제목]이나 [해당 쓰레드의 어떤 정보], 아니면 interwiki 모듈을 확장해서 self:쓰레드+제목 식으로 한다는 거였습니다. 링크 걸릴 때 보이는 글자는 그냥 쓰레드 제목이라고만 나오게 할 수 있구요.

이게 되면 SisterDrupal도 간단하게 구현될 겁니다. SisterWiki의 구성요건은
1. drupal에 있는 모든 쓰레드의 제목을 얻을 수 있을 것.
2. drupal에 있는 쓰레드를 제목 기준으로 접근할 수 있을 것.
두 가지입니다. 나머지는 모니위키가 처리할 부분인데 metadb와 interwiki를 맞춰주면 금방 끝납니다. 저 두 개가 가능한가요?

권순선의 이미지

kz wrote:
권순선 wrote:
phpbb에서 위키 방식의 제목 기준 링크라고 하는 것은 어떤 것인지 잘 모르겠네요.

가령 어떤 쓰레드를 가리킬 때 http.....t=nnnn이 아니라 [쓰레드 제목]이나 [해당 쓰레드의 어떤 정보], 아니면 interwiki 모듈을 확장해서 self:쓰레드+제목 식으로 한다는 거였습니다. 링크 걸릴 때 보이는 글자는 그냥 쓰레드 제목이라고만 나오게 할 수 있구요.

이게 되면 SisterDrupal도 간단하게 구현될 겁니다. SisterWiki의 구성요건은
1. drupal에 있는 모든 쓰레드의 제목을 얻을 수 있을 것.
2. drupal에 있는 쓰레드를 제목 기준으로 접근할 수 있을 것.
두 가지입니다. 나머지는 모니위키가 처리할 부분인데 metadb와 interwiki를 맞춰주면 금방 끝납니다. 저 두 개가 가능한가요?


이런 식의 컨텐트 연결은 잘 되면 물론 좋겠지만 지금처럼 wiki쪽에 방문자가 많지 않은 상황에서 얼마나 많은 사람들이 활용할지는 조금 의문입니다. 예를 들어 "Open Source"라는 키워드에 대해서 http://wiki.kldp.org/wiki.php/OpenSource 에 있는 것을 연결하기 위해(만약 연결 기능이 제공된다면) [wiki: OpenSource] 뭐 이런 식으로 명시적으로 적어 주어야 할 텐데 wiki에 해당 내용이 있다는 것을 아는 경우가 그렇게 많지는 않을 것 같고, http:// 로 시작하는 링크에 비해서 보기에 더 낫다는 장점 외에 특별히 부각될 만한 커다란 장점은 없어 보입니다. 물론 이런 기능 자체는 위에서도 적었지만 문제없이 제공 가능할 것으로 생각됩니다. 다만 얼마나 활용될 것인가, 실질적으로 얼마나 유용할 것인가에 대해서 이 기능의 비중을 보는 kz님과 저의 시각 차이가 있는 것 같습니다.
peco의 이미지

ed. 님의 말씀중에 참여 장벽을 낮운다는 내용과..
다른 주제의 글에서 kldp.net 에서 프로젝트를 할때
필요한 라이브러리 와 자료? 들이 필요하다는 글과
여러 프로젝트 소개가 필요하다는 글을 읽으면서
나름대로? 정리해본 내용을 쓰려합니다...

kldp의 주요 기능에 대해
잘 사용하지는 않더라도 따로 게시판 목록을
개설했으면 합니다.
1. 이후에 drupal.org 와 같은 형식을 사용할때
포럼과 wiki메뉴 양쪽에 같은 게시판이 사용된다면
좋을 수도 있을것 같습니다.
이 때 한번의 로그인으로 kldp.net wiki.kldp.org bbs.kldp.org를
사용하게 될때

포럼에 있는 게시판을
여러 다른 상위 메뉴에서도 보여줄 수도있고..
다른 상위 메뉴나 주제에서 사용하는 게시판을
포럼에서는 보이지 않게 할수도 있겠지만,
동시에 보이는게 좋은것 같습니다.. roll

2. 또한..
kldp에서 bbs에 상대적으로 집중된 관심을
지속적으로 kldp.net wiki.kldp.org 쪽으로
유도할수 있을것 같습니다.

게시판 제목은

kldp.net과 관련해서..
프로젝트 개설 토론, 상담 게시판
프로젝트에 도움이 되는 자료나 해외 프로젝트 소개

wiki.kldp.org과 관련해서..
번역문서 소식과 번역자 대화마당

근데.. 예전에 비슷한 게시판이
있었다가 없어졌나요? 어렴풋이 게시판 제목이 낮익네요...

프로젝트 개설 토론, 상담 게시판
(1. 현재의 추세?에서 공부를 위한 프로젝트를 하려고 할때
어떠한 프로젝트를 할 수 있는지 소개를 하고
질문을 하며, 같이 프로젝트에 관여할 사람들이
효율적으로 모일 수 있는 공간을 제공합니다.
2. 현재 자신이 진행하려는 프로젝트가
이미 존재 하는지,
참고할 만한 프로젝트나 자료가 있는지,
여기서도 같이 프로잭트를 할 사람을 구할수 있겠지만
kldp.net과 중복이 될 수 있을것 같습니다.)

프로젝트에 도움이 되는 자료나 해외 프로젝트 소개
(정기적으로 정리를 해서 kldp.net 에 정리를 해야
해야 할것 같습니다.
그리고 해외 프로젝트 메뉴를 만들고 카테고리를 만들어서
분류해서 적었으면 합니다..
프로젝트 주소, 소개하는 시점의 버젼, 프로젝트 내용 소개,
프로젝트에 대한의견, 관련된 프로젝트, 한글화된 프로젝트,
관련메뉴얼 과 한글로 번역된 메뉴얼 혹은 설치 도움글...
등을 가능한한 썼으면 하고요.. 업데이트를 계속 했으면 좋겠습니다..

해외 프로젝트 메뉴의 경우 위키에서 큰 분류를 만들고
정리를 하는것도 좋겠지만, 자율적으로는 잘
않될 수 있으니.. 관련 게시판의 내용을 단순히
정리하는일 이라면.. 지식이 부족하더라도 가능할 것이므로..
전담하는 관리자를 뽑아서 맞겼으면 합니다..)

번역문서 소식과 번역자 대화마당, 문서화 관련글
(이 게시판에는 번역자나 문서를 작성한 사람
혹은 번역이 전혀 않된 외국문서 소개등..
글을 작성 권한을 제한 함으로서,
번역자나 문서작성자와 독자? 들간의
대화 공간과 자료 교환 제공하고 번역이나
문서화에 대해 소개하는 공간을 마련했으면 합니다.)

구글로 kldp.org 에 대한 검색을 창이 생기게 되면서..
wiki 검색에서 않보이던 wiki이전의 html 이나 택스트
문서를 일부 다시 찾을수 있게 되지 않았나 하는 생각이
드는데요..
하지만, 아직도 wiki의 카테고리 분류가 좀더
보완이 되어서 기존에 있었던 문서들중에서
키워드 등록이 않된 미분류된 파일들을
wiki에 '미분류' 키워드를 만들거나 해서..
미분류 메뉴에 모두 포함 시키거나..
하는 일이 필요한것 같습니다..

-----------------------------------------------
이젠 초보프로그래머를 벗어나고 싶어라~ -.-

권순선의 이미지

ed. wrote:
저도 kz님의 의견에 동의합니다.
blog부분은, gnome pgk형태가 kldp에도 있으면 하는 바램이 있었습니다.

많은 사람들이 FOSS에의 진입장벽을 이야기해왔지만, 이건 예전 perky님의 말씀에서처럼 각자의 기호와 관심사로 알아서 진입하는것이 맞는것 같습니다.
그러면서도 mentor/mentee system을 희망하는 사람들이 많은데, 이런 욕구를 굳이 BSD의 그것처럼 구축한다기보다는, category와 level로서 적절히 분화시키면 어떨까 싶습니다.
뭐랄까, category라고 하면, language, 각 분야별로 나눈다고 했을때, 그 level을 몇단계 나눌수 있는 구성이 된다면, 각자가 알아서 그 category에 들어가서 level up을 이룰수 있도록 하는거죠.
적절하게 표현이 안되는데(첫 출근의 부담으로 잠을 설쳤더니 머리가 멍~ㅎㅎ), C언어라면, 언어 자체를 배우는 레벨이 있겠고, sourceforge같은 적당한 프로젝트를 몇개 던져준다거나, 혹은 같이 issue화해서 고민해본다거나 하는 식의 study level, 그 다음에는 독자적인 project를 고민하는 level 이런 식인겁니다.

kldp.net의 경우 관심사가 같은 이들이 해당 과제에 참여하는 형태인것인데, 한편으로는 각 프로젝트간의 사용언어같은 공통분모랄지 하는 부분에서 여러 프로젝트 참여자들간에도 논의해볼수 있는 여지가 있을것 같거든요.
사실 이런 얘기는 기 개발자들 입장에서야 참여 혹은 monitoring으로 끝날 성질의 것이긴 한데요, ajax를 사용하는 여러 플젝의 경우는 ajax자체에 대한 고민은 모아져도 될성싶다 뭐 이런 식입니다. 그러는 가운데, mentee입장에 서는 사람들의 breeding도 되지 않겠나 하는...

아, 역시 머리가 멍해 정신없이 주절거리기만 하는것 같습니다.
요는, 1:1 mentor system구축이 아닌 n:n system을 category와 level 세분화 및 그에 따른 게시방 마련(현재 kldp구성으로 보자면) 형태로 가져가보는것은 어떨까 싶은겁니다.

두서없는 얘기 끝까지 읽어주셔서 감사합니다.
새해 복많이 받으시고, 건강하세요~


사용자 모임이나 소그룹(daum.net의 카페와 같은 식의...) 기능을 이야기하고 계신 것으로 이해하였습니다. 자생적으로 활동하는 그룹이 많아서 나쁠 것은 없겠지요. 기술적으로도 이미 drupal에 그러한 모듈이 있기도 하고요. (정확히 어떤 기능을 제공해 주는지는 아직 테스트해 보지 않았습니다.) 이부분은 저도 처음에 괜찮겠다고 생각했었는데 실제 운영시에 부하가 너무 많이 걸리지 않을까 하는 걱정이 좀 들었습니다. (시스템에 대한 부하 / 관리에 대한 부하 모두)
권순선의 이미지

paek wrote:
왜 매번 무언가 변한다고 하면 이제는 두렵습니다.

무언가를 또 배워야 되게 됨으로 인해서 (특히나 한국 대부분의 웹사이트와 다른 방법) 그로 오는 압박과 시간적 여유..

대부분 KLDP에 오는 사람들을 개인적으로 고려를 해봤을때, 대학생들과 직장인들이 주를 이룬다고 볼수 있으며, 이들이 자신의 학업또는 직장의 업무 이외에 새로운 게시판 적응을 위해서 무언가를 배우고 그 인터페이스에 익숙해지기 위해선 꽤 많은 시간이 걸릴꺼라 보입니다..

문론 KLDP 에 계속적으로 방문 하던 이들께서는 계속 방문 할지 모르겠으나, 오히려 개편때마다 점점 사용자들이 줄어드는걸 느끼는건 저뿐만인지 모르겠습니다.

예전 초기 KLDP 의 경우 관련 번역문서나 번역되어져 올라오는 관련 기술 문서들이 꽤 많았던것으로 기억됩니다만, 요즘은 그런 분의기는 하나도 안느껴지고 오로지 게시판만 활성화 되어 있는 KLDP 로 느껴집니다...

개인적으로는 첫페이지에는 그냥 예전 처럼 무언가 문서등을 찾기 쉬운형태로 갔으면 좋겠다는 생각이며, wiki 같은것으로 글쓰는걸 상당히 어려워 하는 이들이 많다는것을 감안한다면, 국내 실정에 맞는 에디터 같은 방식으로 가는것이 좋으리라 판단 됩니다.


변화에 대한 댓가는 사실 상당히 큽니다. 충성도(?)가 높은 일부 사용자들을 제외한 대부분의 일반 사용자들은 조금이라도 낯선 인터페이스가 갑자기 나타나게 되면 큰 불편함을 느끼는 것이 당연합니다.

그렇지만 더욱 중요하게 생각해 보아야 할 것은 궁극적으로 가야 할 방향과 현재의 시스템이 그러한 방향으로 사용자들을 유도/유혹(:-))하는데 충분한 기능을 제공해 줄 수 있느냐 하는 것이겠지요. paek님이 언급하신 대로 '게시판만 활성화되어 있는 것처럼 보이는' 현재의 상황은 현 시스템을 그대로 유지하면서 타개할 수 있다고는 생각하지 않기 때문에 댓가를 치르더라도 변화가 필요한 시점이 왔다는 것이 제 판단입니다.

그리고, 첫페이지의 중요성을 감안할 때 paek님이 언급하신 문서 검색의 편의성 부분은 지금처럼 wiki의 카테고리를 적절한 위치에 그대로 유지하는 것으로 대체할 수 있을 것입니다.

ed.netdiver의 이미지

권순선 wrote:
ed. wrote:
저도 kz님의 의견에 동의합니다.
blog부분은, gnome pgk형태가 kldp에도 있으면 하는 바램이 있었습니다.

많은 사람들이 FOSS에의 진입장벽을 이야기해왔지만, 이건 예전 perky님의 말씀에서처럼 각자의 기호와 관심사로 알아서 진입하는것이 맞는것 같습니다.
그러면서도 mentor/mentee system을 희망하는 사람들이 많은데, 이런 욕구를 굳이 BSD의 그것처럼 구축한다기보다는, category와 level로서 적절히 분화시키면 어떨까 싶습니다.
뭐랄까, category라고 하면, language, 각 분야별로 나눈다고 했을때, 그 level을 몇단계 나눌수 있는 구성이 된다면, 각자가 알아서 그 category에 들어가서 level up을 이룰수 있도록 하는거죠.
적절하게 표현이 안되는데(첫 출근의 부담으로 잠을 설쳤더니 머리가 멍~ㅎㅎ), C언어라면, 언어 자체를 배우는 레벨이 있겠고, sourceforge같은 적당한 프로젝트를 몇개 던져준다거나, 혹은 같이 issue화해서 고민해본다거나 하는 식의 study level, 그 다음에는 독자적인 project를 고민하는 level 이런 식인겁니다.

kldp.net의 경우 관심사가 같은 이들이 해당 과제에 참여하는 형태인것인데, 한편으로는 각 프로젝트간의 사용언어같은 공통분모랄지 하는 부분에서 여러 프로젝트 참여자들간에도 논의해볼수 있는 여지가 있을것 같거든요.
사실 이런 얘기는 기 개발자들 입장에서야 참여 혹은 monitoring으로 끝날 성질의 것이긴 한데요, ajax를 사용하는 여러 플젝의 경우는 ajax자체에 대한 고민은 모아져도 될성싶다 뭐 이런 식입니다. 그러는 가운데, mentee입장에 서는 사람들의 breeding도 되지 않겠나 하는...

아, 역시 머리가 멍해 정신없이 주절거리기만 하는것 같습니다.
요는, 1:1 mentor system구축이 아닌 n:n system을 category와 level 세분화 및 그에 따른 게시방 마련(현재 kldp구성으로 보자면) 형태로 가져가보는것은 어떨까 싶은겁니다.

두서없는 얘기 끝까지 읽어주셔서 감사합니다.
새해 복많이 받으시고, 건강하세요~


사용자 모임이나 소그룹(daum.net의 카페와 같은 식의...) 기능을 이야기하고 계신 것으로 이해하였습니다. 자생적으로 활동하는 그룹이 많아서 나쁠 것은 없겠지요. 기술적으로도 이미 drupal에 그러한 모듈이 있기도 하고요. (정확히 어떤 기능을 제공해 주는지는 아직 테스트해 보지 않았습니다.) 이부분은 저도 처음에 괜찮겠다고 생각했었는데 실제 운영시에 부하가 너무 많이 걸리지 않을까 하는 걱정이 좀 들었습니다. (시스템에 대한 부하 / 관리에 대한 부하 모두)

좋은 답변 감사합니다.

사실 제가 생각해본건 좀 주제넘는 생각입니다.
뭐랄까, KLDP의 정체성과 맥락이 닿아있다고나 할까요?
위의 다른분께서 문서에 대한 이야기를 하셨는데요, 전 KLDP가 기존의 번역서나 howto로 채워지기에는 정체성의 한계에 도달했다고 생각합니다.
물론 순선님이나 다른 앞선세대 hacker분들이 보시기에는 기대수준에 한껏 못미치는 상황이긴 합니다만, 제 생각의 핵심은 한국 hacker의 breeding역할을 KLDP가 해야 하지 않나 싶다는 겁니다.
기존 자생적 hacker문화의 명맥과 입지가 갈수록 줄어들어가고 있다고 느끼시는 부분이 어쩌면 순선님으로 하여금 KLDP정체성고민의 한갈래일지 모르겠다고 생각하며, FOSS문화 창달에 앞장서기 위해서는 (ㅎㅎ) 결국 기존 개발자들의 흡수와 병행해서 제다이 수련생들을 일궈나가야 하지 않겠냐는거죠.ㅋㅋ

소모임 형태를 말씀하셨는데, 소모임은 너무 폐쇄적이지 않나 싶습니다. 또 한번 개설된 소모임에 자연스런 진입진출이 여의치 않은게 가장 큰 걸림돌이 되구요.

사실 적당한 방안은 저도 잘 모르겠습니다.
제가 아는 선에서 가장 적당한 모델은 tutor@python.org (quention이 아닌) 류의 mailing list식입니다만,
drupal 모델에서 적당한건 아닌것 같기도 하고요...

아 잘 모르겠습니다... :cry: (아~몰라몰라몰라~:울회사 2005년 최고 유행어...ㅋㅋ)

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

creativeidler의 이미지

전 개편 자체에는 찬성입니다. 기본적으로 프로그래머들은 다들 새로운 것을 시도해보길 좋아하지 않나요? 전 늘 새로운 도구를 써보고 새로운 기술을 써보는 것을 좋아합니다. 새로운 인터페이스를 써보는 것도 좋겠지요.

개인적으로 위키를 BBS보다 더 좋아합니다. 전 사실 BBS의 존재 자체가 FOSS에는 별반 도움이 안된다고 생각합니다. 노스모크나 Xper 등을 보면 위키에서도 충분히 토론이 잘 이루어집니다. 문서를 보는 사람 입장에서도 BBS에서 질답들을 검색해보는 것보다는 위키에서 지도를 통해 찾고 못 찾을 때만 검색을 활용하는 것이 더 편리하죠. BBS는 일반적으로 나왔던 질문이 거듭해서 나오는 경향이 있습니다. 통합으로 가고자 한다면 전 BBS 폐쇄! 까지는 아니더라도 초보자 전용 질답 게시판 외에 기술적인 이슈들은 죄다 위키로 옮겼으면 좋겠습니다.

위키가 어렵다..글쎄요. 일단 인터페이스에서 약간 개선할 만한 여지가 있는 것은 사실입니다만 위키를 어려워하는 사람이 FOSS에 어떤 기여를 할 수 있을지는 의문입니다.

만약 bbs를 유지하더라도 전 분류를 잘게 나누는 것은 결사 반대입니다. 질답 게시판 등에서 흔히 나타나는 현상인데 질답 게시판이 분류로 나뉘어 있으면 답을 받을 확률이 현저히 떨어집니다. 사람들이 많은 게시판에 들어가볼만큼 부지런하지 않기 때문이죠. 현재 kldp에서도 메인에 최근글로 일단 뜬 글은 계속 관심을 받지만 메인에서 사라지면 토론이 중단되는 일도 종종 생깁니다. 사람들이 세부 카테고리로 들어가고 싶어하지 않는다는 뜻이죠. 몇몇 커뮤니티에서 흔히 보이는 현상으로 질답 게시판에 쓰면 사람들이 안 보기 때문에 질문을 자유게시판에 올리는 경우가 있는데 이런 것도 분류가 제대로 기능하고 있지 않다는 증거죠. 게시판은 그냥 하나! 였으면 좋겠고 나누더라도 자유게시판/기술적인 이슈 두 가지 이상으로는 나누지 말았으면 좋겠습니다.

하지만, 어떻게 개편을 해도 사실 지금보다 상황이 크게 나아지진 않을 것 같습니다. 지금 kldp의 FOSS스럽지 않음은 구성원들의 성향이 그렇기 때문이지 시스템이 어떠헤 잘못 유도하고 있는 것은 아닌 것 같습니다. 구성원들 스스로가 FOSS에 기여하기보다는 그냥 와서 보드톡하는 걸 더 좋아하는 것 같습니다. 이런 성향 자체가 나쁘다고 생각하지도 않구요.

물론, 어차피 개선이라는 것이 어떤 혁명적 변화를 기대한다기보다 점진적인 발전을 기대하는 것이기에 개편 자체에는 지지를 보냅니다.

keizie의 이미지

권순선 wrote:
"Open Source"라는 키워드에 대해서 http://wiki.kldp.org/wiki.php/OpenSource 에 있는 것을 연결하기 위해(만약 연결 기능이 제공된다면) [wiki: OpenSource] 뭐 이런 식으로 명시적으로 적어 주어야 할 텐데 wiki에 해당 내용이 있다는 것을 아는 경우가 그렇게 많지는 않을 것 같고, http:// 로 시작하는 링크에 비해서 보기에 더 낫다는 장점 외에 특별히 부각될 만한 커다란 장점은 없어 보입니다.

제가 덜 말했나보네요. SisterWiki를 켜게 되고 다른 사이트를 적당한만큼 연결했다면, 링크 괄호 안에 아무거나 넣어도 됩니다.

예를 들어 적당한 페이지로 바로 연결되지 않은 제목 링크에 대한 예비 동작이 제목 검색이라면 해당 단어를 포함하는 (혹은 어떤 식으로든 조건에 걸린) 페이지가 나오게 됩니다. 검색이 훨씬 간단해지는 거죠. 지금의 정확도 떨어지는 phpBB 검색보다 검색 결과는 덜 나와도 적중도는 차라리 나을 거라고 생각합니다. 지금 wiki.kldp.org에서 한글처럼 대표적인 단어를 넣어보면 뜨는 페이지들이 그런 것들입니다.

해당 자료가 어디에 있든 어떤 형식이든 제목만 있고 SisterWiki에 걸려만 있으면 제목 적고 괄호 쳐주는 것만으로 링크가 걸리는 거죠.

ed.netdiver의 이미지

글타래가 활발히 이어지길 기대하며 posting해봅니당 :D

분류를 잘게 나누는것이 패착일거같다는 생각은 저도 동의합니다.
하지만, 말씀하셨다시피 글타래가 한번 묻히면 토론이 중단되버린다는점이 좀 그렇습니다.

짝퉁 분석을 해보면, KLDP가 번역서, howto에서 QnA로 발전해왔고, 그 2단계도 한계가 아닌가 싶은데, 그것의 대안은 무엇인가입니다.
QnA가 아닌 tutor(tutor@python처럼...)식이 어떨까 싶었던겁니다.
물론, QnA로도 충분히 study할 수 있었지만, base가 FOSS가 아닌 개인업무도우미수준이 아니었나 싶고, 제 느낌입니다만, wiki는 갈래를 나누는것보다 더 세분화되어버려 산만하게 느껴집니다.

또, 토론같은 경우도 대개 아주 일반론적인 접근(creativeidler님의 웹서비스 토론처럼요^^..덕분에 많이 배웁니다만^^ )이거나, 언어에 대한 부분도 학문적인 쪽으로 치우친다거나 하는 경향이 있다고 생각합니다.
그래서 breeding(study)과 QnA, 토론 및 사유가 가능한 창구가 있으면 좋겠다는게 제 생각입니다.
세분화의 단점은 저도 걱정되는 부분이긴 합니다만, 뭐랄까 gentoo의 세분화된 포럼식이라면 어떨까 싶었더랬습니다. 진입장벽도 낮고, log도 되고...
단 그 "세분화한 포럼"(편의상 이렇게 부르겠습니다)에 주도자(들)가 있어서 그 포럼을 이끄는 형태...
막연하게 이렇게 생각이 들었군요. :D

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

cdpark의 이미지

크게 손을 보려면 KLDP Wiki의 엔진을 위키백과에서 MediaWiki로 바꾸는 것도 고려해볼만합니다.

일단 redirect를 지원하는게 장점입니다. 사용자로서는 Open source/OpenSource/Open Source/오픈소스/오픈 소스 중 어느 단어로 페이지가 등록되었는지 일일이 신경써야 합니다. 이래서는 쓰기 귀찮죠. redirect를 지원하므로 다 redirect처리하면 됩니다. :)

많은 위키엔진이 지원하는 CamelCase의 자동 링크 기능이 소규모 그룹용/알파벳 기반 언어에서는 잘 동작하지만 한국어 등에서는 거의 도움이 안 됩니다. 특히 프로그래밍 관련 정보를 많이 다루는 kldp에서는 오히려 독입니다. "class MyQueue"에서 MyQueue"와 같은 엉뚱한 단어가 CamelCase로 잡히기도 하니깐요.

BBS/Blog 쪽에는 [[linux]]나 [[리눅스]] 라고 하면 Wiki의 항목으로 연결되는 정도의 확장만 설치하면 redirect를 통해 쉽게 해당 페이지로 연결할 수 있고요.

Wiki와 BBS의 완벽한 통합은 쉽지 않을 듯 싶네요. Wiki 페이지는 많은 사용자가 한꺼번에 바라보기엔 적합하지 않으니깐요. 하지만 wikinews를 위해 개발된 기능들을 잘 활용하면 되긴 합니다. http://meta.wikimedia.org/wiki/DynamicPageList 등의 확장을 잘 이용하면 게시판이나 FAQ 목록 등을 편하게 유지할 수도 있긴 합니다.

그러나 Wiki는 사용자들에게 부담을 줍니다. 특히 게시판 활용도 익숙하지 않은 사용자들에게는 더더욱요. Wiki를 통해 올린 자신의 글이 다른 사람에 의해 고쳐지는 것에 거부반응을 가진 사용자들이 꽤 많습니다. 이런 문화적인 거부반응을 시험하기엔 이미 KLDP는 너무 많이 성장했습니다. 아예 위키를 기반으로 한 위키 공동체에서도 겪는 문제인데, 위키 공동체가 목표가 아닌 KLDP에 도입하기엔 위험부담이 큽니다.

또 Wiki를 본격적으로 쓴다면 저작권 문제도 깔끔하게 정리하고 가야 합니다. 지금과 같은 BBS 체제에서야 퍼온 글은 퍼온 사람이 책임지면 되지만, wiki 시스템에서는 누가 퍼 온 글인지 꽤 애매해집니다. 퍼온 글이 계속 편집되고 성장해나가다가 저작권 문제를 정리하려다보면 그게 퍼온 글이 50%, 사용자 기여 50%의 혼합물이라는 걸 발견하게 됩니다. 정말 난감하죠.

세줄요약 :roll:
WIKI는 MediaWiki 추천
BBS에는 WIKI로의 연결을 위한 확장 제공
BBS와 WIKI와의 통합은 많은 고려가 필요함.

권순선의 이미지

http://bbs.kldp.org/viewtopic.php?t=68342 를 참고하세요. 개편 작업을 방문자 여러분들이 다함께 해나가는 일종의 축제(?)로 만들고 싶습니다.

keizie의 이미지

cdpark wrote:
세줄요약 :roll:
WIKI는 MediaWiki 추천
BBS에는 WIKI로의 연결을 위한 확장 제공
BBS와 WIKI와의 통합은 많은 고려가 필요함.

미디어위키가 좋다는 얘기는 많이 들었는데, 지금 모니에서 부족한 부분에 비해 어떤 장점이 있을까요? 말씀하신 낙타식 이름에 대해서 미디어위키가 제시하는 대안은 어떤 게 있습니까? 리다이렉트는 아시겠지만 모니에서도 지원하는 부분입니다.

위키의 자유로운 편집에 대해 거부감이 있을 수 있다는 데는 동의합니다. 저도 노스모크 등에서 이따금 봤던 일이기도 하니까요.

다만 그로 인해 위키의 효용이 저평가되지는 않았으면 합니다. bbs.kldp.org에서라면 길게 쓰레드를 늘여야 되는 것들이 위키로는 핵심만 정리할 수 있죠. 어차피 KLDP에서 제공할만한 내용들은 초기에 활발하게 편집이 되도 어느 정도 시간이 지나면 거의 갱신이 없을만한 것들입니다. 한 사람이 편집하는 사이 나중에 편집한 누군가가 먼저 저장하면 먼저 연 사람이 충돌을 겪기는 합니다만 이건 위키를 개선함으로써 해결할 수 있는 일이라고 생각합니다.

wkpark의 이미지

kz wrote:
cdpark wrote:
세줄요약 :roll:
WIKI는 MediaWiki 추천
BBS에는 WIKI로의 연결을 위한 확장 제공
BBS와 WIKI와의 통합은 많은 고려가 필요함.

미디어위키가 좋다는 얘기는 많이 들었는데, 지금 모니에서 부족한 부분에 비해 어떤 장점이 있을까요? 말씀하신 낙타식 이름에 대해서 미디어위키가 제시하는 대안은 어떤 게 있습니까? 리다이렉트는 아시겠지만 모니에서도 지원하는 부분입니다.

위키의 자유로운 편집에 대해 거부감이 있을 수 있다는 데는 동의합니다. 저도 노스모크 등에서 이따금 봤던 일이기도 하니까요.

다만 그로 인해 위키의 효용이 저평가되지는 않았으면 합니다. bbs.kldp.org에서라면 길게 쓰레드를 늘여야 되는 것들이 위키로는 핵심만 정리할 수 있죠. 어차피 KLDP에서 제공할만한 내용들은 초기에 활발하게 편집이 되도 어느 정도 시간이 지나면 거의 갱신이 없을만한 것들입니다. 한 사람이 편집하는 사이 나중에 편집한 누군가가 먼저 저장하면 먼저 연 사람이 충돌을 겪기는 합니다만 이건 위키를 개선함으로써 해결할 수 있는 일이라고 생각합니다.


위키에 대한 개편방향은 저는 다소 중립적인 견지를 가지고 있습니다. 일단, cdpark님이 지적하신 "라이센스"문제가 위키의 가장 큰 걸림돌이라고 생각하고 있어왔고, 예전의 kldp에서 하던 문서화는 블로그/개인미디어(위키포함) 시대로 넘어가면서 각자의 블로그/개인미디어 혹은 각각의 커뮤니티에 분산되게 되어서 kldpwiki가 기대만큼 활성화되지는 않는 것 같으며, 또, kldp 발전의 저해요소로 bbs및 kldp.net의 부자연스러움에 큰 원인이 있다고 나름대로 생각하고 있습니다.

우선 kldp의 커뮤니케이션 축인 phpbb를 중점으로 살펴보면, 제가 잠깐 살펴본 바로는 drupal이 kldp에 훨씬 적합하다고 판단되고요,phpbb의 장점과 단점을 나열해본다면,
* 낯선 인터페이스: slashdot 혹은 geekforum의 인터페이스가 토론하기에는 가장 적합한 인터페이스인 것 같습니다. 평면적인 phpbb는 토론 글타래를 제대로 표현하지 못하고 있습니다.
* 오래된 글타래에 글을 추가하면 최신 리스트로 올라옴: phpbb를 도입해서 얻게된 가장 큰 학습효과가 아닌가 합니다. 썼던 글을 또 쓰는 쓸모없는 재생산이 줄어들었습니다.
* 느리고 불편한 검색: 한때 phpbb검색때문에 kldp가 잦은 다운을 겪기도 했었죠 (현재는 김정균님의 노력으로 매우 안정화 되었지만)

(아직 drupal이 phpbb의 단점을 모두 커버하고 있는지는 살펴보지 않아서 잘 모르겠습니다.)

위키 부분으로 다시 넘어가서,

cdpark님이 말씀하시는 리다이렉트 기능은 모니위키가 노스모크엔
진으로 채택되었을 당시 비슷한 기능을 집어넣어서 cvs에 들어갔습니다. (alias page name)
Mediawiki식 페이지 링크인 두개의 꺽쇠괄호 사용법도 최근 모인모인에 들어가는 토론이 있길래 역시 cvs에 넣었죠.

그밖에 작년 한해동안은 제가 바빠서 릴리스를 한번밖에 못했지만 1.1.0 릴리스 이후로 수많은 시범적 기능이 들어가서 테스트 및 안정화 중입니다.

KTUG 위키를 모니위키로 교체하는 과정에서, jsboard를 위한 위키연동 확장을 재작성했는데 (interwiki, [[페이지 링크]]) 쓸만한 것 같더군요. 사실 일반게시판의 파서는 그 기능이 매우 단순하기때문에 위키기능을 추가하는 것이 어렵지 않았습니다. 위키의 핵심적인 기능인 "인터위키"와 "페이지이름으로 링크걸기" 외에 특정 url을 위키식 인터위키로 fix해주는 기능을 넣으니 (예를 들어, http://wiki.kldp.org/ 어쩌구로 시작하는 모든 링크를 KLDPWiki:페이지이름 으로 내부적으로 fix하는 필터링처리) 사용자들이 자동으로 학습하는 효과와 더불어 jsboard와 위키위키의 연동이 자연스러워지게 보이더군요.

기타 모니위키의 1.1.0 이후에 cvs에 들어간 기능들은 다음과 같습니다.
* AliasPageNames (페이지 이름의 여러 alias를 만들며 각 이름들로 페이지 링크를 만들 수 있고, 사용자가 위키식으로 추가 가능)
* Mediawiki식 링크
* url mapping: 특정 url을 원하는 새 url/interwiki로 fix
* FastSearch integration: perl 외부프로그램으로 지원하던 fast search모듈을 php로 통합
* 보다 안전한 login 시스템
* 많은 블로그에서 지원하는 방식의 작은 dictionary 지원
* 스팸 방지를 위한 이미지(ticket) 지원

개발중인 기능은,
* keyword 시스템: 분류분류를 대체할 새로운 tagging 시스템
* 간단한 형태소 분석을 통한 자동 키워드 추출 (php로 만든 작은 한글 형태소분석기 내장)

통합을 할때 고려해야 할 부분으로 생각하는 것은
* 위키와 로그인 통합
* 좀 더 쉬운 위키 인터페이스
* 편리한 검색 (매우 중요: 똑같은 질문이 재생산되지 않게 하기위해서는 검색을 먼저 하게끔 하는 패턴이 필요할 듯)

온갖 참된 삶은 만남이다 --Martin Buber

keizie의 이미지

bbs.kldp.org가 있을 때는 그나마 첫 페이지에 최근 글이 나왔습니다. GmailInvites나 OrkutInvites 같이 특수한 목적으로 갱신이 활발한 페이지도 있었죠.

요즘은 kldp.org에 오면 일단 drupal 안에서 모두 돌아가기 때문에 kldp.net이나 wiki.kldp.org는 있는지 없는지 생각지도 않게 됩니다. 이 쓰레드를 찬찬히 살펴보니 순선님이 위키에 대해 꽤나 쓸모 없다고 생각하시는 것 같기도 하고, 위키빠인 저로서는 (웃음) 좀 씁쓸합니다.

몇몇 쓰레드를 보면 쓰레드를 잠그거나 제목만 남기고 위키로 빼내서 정리하면 좋겠다 싶은 게 간간히 보입니다만, 개편 후 위키의 위상이 위태로움을 생각할 때 ..(음... 위로 시작하는 단어가 뭐 있나..) 여튼 그렇습니다. -_-a

권순선의 이미지

Wiki가 쓸모없다고 생각하는 것이 아니라 어떻게 하는 것이 좋을지 잘 몰라서입니다. http://kldp.org/node/71286 에 따로 글타래를 열어 두었으니 좋은 의견 있으시면 올려 주세요...

creativeidler의 이미지

Quote:
* 낯선 인터페이스: slashdot 혹은 geekforum의 인터페이스가 토론하기에는 가장 적합한 인터페이스인 것 같습니다. 평면적인 phpbb는 토론 글타래를 제대로 표현하지 못하고 있습니다.

저랑은 느낌이 다르네요. 저도 geekforum에서 꽤 오래 놀았지만 phpBB가 토론에는 더 효과적이라고 느낍니다. 쓰레드가 트리구조로 늘어서는 것이 실질적인 토론 흐름의 이해에 기여하지 못하는 것 같았거든요. 인용이 있기 때문에 굳이 꼬리에 꼬리를 물지 않더라도 잘 이어지는 것 같습니다.

그리고 오히려 꼬리에 꼬리를 물면서 주제를 벗어나는 그런 사태는 중간 중간에 적절한 견제가 들어옴으로써-_- 원래 주제로 돌아오게 하는 그런 효과도 있는 듯. 어쨋든 전 BBS를 유지한다면 지금의 phpBB 스타일이 좋습니다.

wkpark의 이미지

creativeidler wrote:
Quote:
* 낯선 인터페이스: slashdot 혹은 geekforum의 인터페이스가 토론하기에는 가장 적합한 인터페이스인 것 같습니다. 평면적인 phpbb는 토론 글타래를 제대로 표현하지 못하고 있습니다.

저랑은 느낌이 다르네요. 저도 geekforum에서 꽤 오래 놀았지만 phpBB가 토론에는 더 효과적이라고 느낍니다. 쓰레드가 트리구조로 늘어서는 것이 실질적인 토론 흐름의 이해에 기여하지 못하는 것 같았거든요. 인용이 있기 때문에 굳이 꼬리에 꼬리를 물지 않더라도 잘 이어지는 것 같습니다.

그리고 오히려 꼬리에 꼬리를 물면서 주제를 벗어나는 그런 사태는 중간 중간에 적절한 견제가 들어옴으로써-_- 원래 주제로 돌아오게 하는 그런 효과도 있는 듯. 어쨋든 전 BBS를 유지한다면 지금의 phpBB 스타일이 좋습니다.

너무 꼬리를 물면 보는데 따라 불편을 초래합니다만, geekforum에서는 더욱 심도 깊은 논쟁이 있었던 것으로 알고있습니다. (경우에 따라서는 너무 격렬해졌죠) phpBB는 긴 글타래의 경우, 토론의 흐름을 파악하는것이 쉽지 않습니다. 중간에 간혹있는 엉뚱한 얘기로 토론의 흐름이 끊어지기도 훨씬 쉽고요. 개인적 의견입니다만..

온갖 참된 삶은 만남이다 --Martin Buber

ed.netdiver의 이미지

phpbb의 특성은 좋아하지만, geekforum의 날 선 분위기가 더 좋았던것 같습니다.
이게 bbs를 바꿔서 그랬다고만도 할수 없을텐데도, 예의를 갖추게 된 대신에 거칠고 멋진 토론은 찾아볼수 없게 되어버렸다고 해야 할까요...

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

keizie의 이미지

wkpark wrote:
* 편리한 검색 (매우 중요: 똑같은 질문이 재생산되지 않게 하기위해서는 검색을 먼저 하게끔 하는 패턴이 필요할 듯)

http://www.oops.org/?t=lecture&sb=beginner&n=1 이것도 꼭 읽어보도록 유도해야 한다고 생각합니다. 뎡말. :twisted:

권순선의 이미지

drupal로 전환하게 되면 초기화면은 geekforum과 같은 웹로그처럼 운영되면서 bbs도 그대로 운영되므로 양쪽의 장점을 모두 살릴 수 있습니다. 그리고 웹로그에 게재할 컨텐트도 개별 블로그나 bbs에서 골라내면 되니 관리자도 편리해지고, 답글에 대한 moderation도 사용자들이 할 수 있으므로 좀더 공정한 운영이 가능합니다.

opiokane의 이미지

초기 화면도 중요한 것 같습니다.
아주 오래전에는 문서를 찾으려고, 그런데 요즈음은 사실 일하다가
휴식이나 시간 때우려고 kldp에 들어오는 경우가 많은데,,,심심풀이로
문서 번역이라도 할 수 있는 시간에 일단 kldp.org를 치고 들어오면
오른쪽 위의 "BBS"가 누르기 제일 쉽습니다. 게다가 북마크에
RSS Feed까지 등록 해 놓고 있다보면 다른 분들과의 잡담에
언제든지 참여할 수 있는 모든 준비가 되어 있습니다.

George double you Bush has two brains, the left and the right, like normal people. But the problem is that there is nothing right in his left brain and there is nothing left in his right brain"

shockyhan의 이미지

wkpark wrote:
creativeidler wrote:
Quote:
* 낯선 인터페이스: slashdot 혹은 geekforum의 인터페이스가 토론하기에는 가장 적합한 인터페이스인 것 같습니다. 평면적인 phpbb는 토론 글타래를 제대로 표현하지 못하고 있습니다.

저랑은 느낌이 다르네요. 저도 geekforum에서 꽤 오래 놀았지만 phpBB가 토론에는 더 효과적이라고 느낍니다. 쓰레드가 트리구조로 늘어서는 것이 실질적인 토론 흐름의 이해에 기여하지 못하는 것 같았거든요. 인용이 있기 때문에 굳이 꼬리에 꼬리를 물지 않더라도 잘 이어지는 것 같습니다.

그리고 오히려 꼬리에 꼬리를 물면서 주제를 벗어나는 그런 사태는 중간 중간에 적절한 견제가 들어옴으로써-_- 원래 주제로 돌아오게 하는 그런 효과도 있는 듯. 어쨋든 전 BBS를 유지한다면 지금의 phpBB 스타일이 좋습니다.

너무 꼬리를 물면 보는데 따라 불편을 초래합니다만, geekforum에서는 더욱 심도 깊은 논쟁이 있었던 것으로 알고있습니다. (경우에 따라서는 너무 격렬해졌죠) phpBB는 긴 글타래의 경우, 토론의 흐름을 파악하는것이 쉽지 않습니다. 중간에 간혹있는 엉뚱한 얘기로 토론의 흐름이 끊어지기도 훨씬 쉽고요. 개인적 의견입니다만..


쓰레드를 따라 갈수 있느냐 아니냐 하는 것은 중요한 내용이라 생각합니다.
대개 이렇게 민감한 문제는 사용자가 옵션으로 선택하게 하는게 좋은데, 너무 어려울까요?
추가로 모니위키에도 미디어위키처럼 토론 페이지가 따라 다니는 것이 가능하면 좋겠다고 생각합니다.

===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================

권순선의 이미지

shockyhan wrote:
wkpark wrote:
creativeidler wrote:
Quote:
* 낯선 인터페이스: slashdot 혹은 geekforum의 인터페이스가 토론하기에는 가장 적합한 인터페이스인 것 같습니다. 평면적인 phpbb는 토론 글타래를 제대로 표현하지 못하고 있습니다.

저랑은 느낌이 다르네요. 저도 geekforum에서 꽤 오래 놀았지만 phpBB가 토론에는 더 효과적이라고 느낍니다. 쓰레드가 트리구조로 늘어서는 것이 실질적인 토론 흐름의 이해에 기여하지 못하는 것 같았거든요. 인용이 있기 때문에 굳이 꼬리에 꼬리를 물지 않더라도 잘 이어지는 것 같습니다.

그리고 오히려 꼬리에 꼬리를 물면서 주제를 벗어나는 그런 사태는 중간 중간에 적절한 견제가 들어옴으로써-_- 원래 주제로 돌아오게 하는 그런 효과도 있는 듯. 어쨋든 전 BBS를 유지한다면 지금의 phpBB 스타일이 좋습니다.

너무 꼬리를 물면 보는데 따라 불편을 초래합니다만, geekforum에서는 더욱 심도 깊은 논쟁이 있었던 것으로 알고있습니다. (경우에 따라서는 너무 격렬해졌죠) phpBB는 긴 글타래의 경우, 토론의 흐름을 파악하는것이 쉽지 않습니다. 중간에 간혹있는 엉뚱한 얘기로 토론의 흐름이 끊어지기도 훨씬 쉽고요. 개인적 의견입니다만..


쓰레드를 따라 갈수 있느냐 아니냐 하는 것은 중요한 내용이라 생각합니다.
대개 이렇게 민감한 문제는 사용자가 옵션으로 선택하게 하는게 좋은데, 너무 어려울까요?
추가로 모니위키에도 미디어위키처럼 토론 페이지가 따라 다니는 것이 가능하면 좋겠다고 생각합니다.

New KLDP에서는 답글을 보는 방식을 사용자가 선택할 수 있습니다.

- 가장 최신의 답글이 가장 위에 올라오게 하는 방법
- 가장 최신의 답글이 가장 아래에 내려가게 하는 방법
- 쓰레드 별로 답글의 제목만 보여주게 하는 방법(일명 굴비)
- 쓰레드 별로 답글의 제목과 답글 내용을 함께 보여주는 방법

이중에서 자기 취향에 맞게 선택하실 수 있습니다.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.