[홈으로] [게시판]

차례 [+]

닥북 한국을 활성화시키고 국내 닥북 사용을 촉진시키기 위한 노력의 하나로, 한글 닥북 문서 프로젝트를 제안합니다.

우선 아래의 기초 발제를 이곳에서 논의하는 것부터 시작했으면 합니다...

--류광

전반적으로 제가 평소에 생각하던 것과 똑같네요 ^^ 아직 구상단계니까.. 너무 세부적인 이야기는 공허할 수도 있어서 의견 달기가 조심스럽네요. --yongjoo

발제를 했으니 구체적인 논제를 정해서 토론을 하면 되죠 뭐... 너무 딱딱한가요? ^^ 기초 발제 부분은 그대로 두고, 토론 섹션에서 토론을 하되 formalpara와 문서 내부 링크를 이용해서 해당 글을 참조하는 식으로 진행해 보죠. formalpara를 이런 식으로 쓰게 되네요...(anchor 태그를 지원하는 쪽이 더 편할 것 같습니다만) --류광

문서화 게시 시스템에서 게시 시스템에 대한 좀 더 구체적인 이야기를 합시다.

문서화 프로젝트 제안을 위한 기초 발제

문서화의 의미, 목표

닥북 한국을 활성화하기 위해서는 닥북 사용자가 늘어야 합니다. 닥북 사용자가 늘어나게 하려면 닥북이 좋다는 것을 실제로 체험하게 하게 해야 하며, 또 큰 부담 없이 닥북을 자신의 문서화 노력에 매끄럽게 도입할 수 있어야 합니다.

닥북 한국의 닥북 문서화는 문서화 자체의 원래 목표, 즉 닥북 사용의 중요한 자원이 될 문서들을 생산하고 관리하는 것과 함께, 닥북 XML을 이용한 문서화의 한 전형, 모범을 만들고 그것을 전파하는 것도 목표로 합니다. 그 과정에서 닥북 한국의 여러 노력들을 하나의 흐름으로 조직화하는 효과도 노립니다.

전반적인 시스템

문서화 시스템은 크게 저장 시스템과 게시 시스템으로 나뉩니다.

저장 시스템은 닥북 문서들을 저장, 관리하는 공간입니다.

게시 시스템은 닥북 문서들을 소비 가능한 형식으로 변환한 결과를 웹을 통해서 제공하는 공간입니다.

저장과 게시의 분리

저장과 게시를 분리하는 이유는, 저장된 닥북 원본 문서와 게시를 위한 문서 사이에 많은 유연성이 존재하며 그 유연성이야말로 XML 기반 닥북의 큰 위력이기 때문입니다. 저장과 게시를 분리함으로써 닥북을 더욱 다양하게 활용할 수 있습니다.

관리자의 승인 절차

또한 저장과 게시의 분리는 문서화 과정 도중에 관리자에 의한 일종의 승인 절차가 존재한다는 뜻입니다. 이에 의해 게시되는 문서의 품질을 제어할 수 있습니다. 관료주의에 빠지는 것만 주의하면 될 것입니다.

저장 시스템

저장 시스템은 버전 제어를 위한 CVS 시스템과 가장 최신 버전만을 담는 파일 시스템으로 구성됩니다. 일괄적인 문서 변환, 가공, 정보 추출 등을 위한 자동화 도구들을 위해서는 파일 시스템의 존재가 꼭 필요할 것입니다.

게시 시스템은 일반적인 형태의 문서 표시와 함께 다양한 검색, 조회 기능도 필요할 것입니다. Cocoon 등의 기존 노력들을 평가해 봐야 할 것입니다.

보조적으로, 논의와 갱신 요청, 문서 제출 등을 위한 의사소통 통로가 필요한데 이미 있는 게시판, 위키, kldp.net의 패치 제출 공간 등을 활용하면 될 것입니다.

문서 생산은 특별한 시스템을 정하지 않고 참여자들이 각자 편한 방식으로, 손에 익은 도구들을 사용하게 하는 것이 좋겠습니다. 그러나 '권장하는 도구들' 정도는 제시해야 할 것입니다.

역할 모형

문서 생산자

지은이, 옮긴이 - 기초 문서를 생성.

엮은이 - 닥북 XML 마크업을 추가, 수정해서 닥북 문서를 생산.

관리자

올린이 - 엮은이의 문서를 저장 시스템에 추가 또는 갱신.

펴낸이 - 닥북 문서를 실제 소비 형식으로 변환해서 게시 시스템에 추가 또는 갱신.

절차

가장 간략하게 이야기하면:

  1. 문서 생산자는 문서를 올린이에게 제출합니다.
  2. 올린이는 저장 시스템에 문서를 추가 또는 갱신합니다.
  3. 펴낸이는 문서를 변환해서 게시 시스템에 추가합니다.

이 과정에서 자동화된 통지 기능이라던가 선택적인 변환 등의 여러 도구들이 쓰이게 될 것입니다.

할일

음 토론이 더 이상 진행이 안 되는데요. 토론을 더 진행하는 게 무의미하다면 몇 가지 급히 할 일들을 정했으면 합니다.

문서화 프로젝트 홍보

닥북한국 메일링 리스트 가입자들과 기존 KLDP 작업 때 관심을 가지고 조금이나 참여하셨던 분들, 그리고 닥북을 사용하는/사용할만한 오픈소스 프로젝트들에게 간단한 소개문을 보냈으면 합니다.

소개문은 ?닥북 문서화 프로젝트 소개에서 지금까지의 논의를 정리해서 함께 만들구요. 뭐 아직 논의가 많이 진행되지 안았고 결정난 것도 거의 없지만, 이런 저런 논의가 되고 있다는 정도만 알려도 의미가 있을 것입니다.

만든 후에 몇 분이 분담해서 관련개인, 단체들에게 알립시다.

--류광

CVS 사용

CVS docs 모듈 추가

(적어도 임시적인)저장 시스템으로 닥북 한국 프로젝트의 CVS에 docs라는 이름의 모듈을 추가했으면 좋겠습니다. --류광

저장 시스템으로 쓸 목적이면 웹서버가 돌고 있는 docbook.or.kr에 별도로 만드는 것이 낫지 않을까요? 게시 시스템에서 cvs 명령을 써야 할테니, 게시 시스템과 같은 곳에 있는 것이 좋을 것 같습니다. -- 김민식

저도 찬성입니다. 특별히 반대하는 분이 없으면 docbook.or.kr에 CVS 저장소를 만들었으면 좋겠습니다. 최상위 모듈은 docs로 하고 그 아래 모듈들은 문서 분류 논의와 함께 차차 결정하면 될 것입니다. 그리고 가능하면 적당한 웹 인터페이스도 설치하구요.

그나저나 저는 CVS라고는 ?TortoiseCvs 밖에 모르는데 민식님이 해주세요~

--류광

좀 늦었습니다만, ~/public_html/cvs에 저장소를 만들어 두었습니다. 웹 인터페이스는 http://docbook.or.kr/cgi/viewcvs.cgi/를 보세요. -- 김민식

와 수고하셨습니다. 그런데 KLDP.net CVS 사용하듯이 제 컴퓨터에서 원격으로 접근하는게 가능한가요? 그리고 CVS 사용자를 우리가(그 서버의 docbook 계정) 더 추가하거나 관리할 수 있으면 좋겠는데 가능할까요? --류광

원격 접근은 CVSROOT를 :ext:[email protected]:/home/docbook/public_html/cvs로 해 주면 됩니다만, 사용자 추가/관리는 CVS를 pserver모드로 돌려야 가능하므로 root 권한 없이는 어렵습니다. -- 김민식

닥북 한국 CVS 사용 규칙에 대해

용주님의 'DocBook으로 글쓰기'를 시험삼아 닥북 한국 서버의 CVS(이하 닥북 한국 CVS 또는 ?DbkCvs)에 올렸습니다(여기). 몇 가지 규칙이 필요할 것 같습니다.(더 추가하세요)--류광

게시자 서명

위에 김민식님이 말씀하셨듯이 root 권한이 없는 현재 상황에서 닥북 한국 CVS가 받아들이는 ID는 docbook 뿐입니다. 그래서 커밋 시 메시지에 실제 게시자를 알 수 있는 아이디를 추가할 필요가 있습니다. 궁극적으로는 사용자 추가/관리 권한을 얻어야 할 것입니다.

문서 당 디렉터리

하나의 문서가 여러 개의 파일들로 구성될 수 있으므로 논리적인 문서 하나가 독자적인 디렉터리 하나를 차지하는 게 좋을 것입니다. 그리고 CVS는 원본, 즉 XML 파일들과 변환에 꼭 필요한 파일들(이미지 파일 등)만 올리고, 변환으로 얻을 수 있는 2차적인 파일들(HTML, PDF 등)은 올리지 않는 게 좋을 것입니다. 단 렌더링 시험 결과 등의 목적이라면 그런 파일들도 올릴 수 있겠구요.

디렉터리 구성

docs 아래에 직접 개별 문서 디렉터리를 둘 것인가 아니면 그 사이에 HOW-TO, TIPS 같은 범주 디렉터리를 둘 것인가의 문제.

파일 인코딩

간단히 말하면 UTF-8을 강제할 것인가?

;강제해야 하지 않을까요? '표준'을 위해서~

토론

좀 더 구체적인 논의....

이 제안에 대한 전반적인 토론을 계속 하는 것과 더불어, 좀 더 구체적인 토론과 연구가 필요할 것 같습니다. 특히 구체적인 저장, 게시 시스템이 정해지기 전이라도 문서 생산을 추동할만한 기반을 최대한 빨리 마련했으면 좋겠습니다.

문서 생산을 위해서 일단 필요할 것은 이 정도가 아닐까요...

  • 임시적이나마 닥북 XML 문서를 제출하고 보관할 장소
  • 문서 작성 가이드라인

새로운 페이지로 분리해서 진행해도 좋겠습니다.

그리고 저장, 게시 시스템에 사용할 수 있을만한 여러 오픈소스 프로젝트들, 오픈 표준들, 또는 또는 직접 만든다고 했을 때 어느 정도 시간과 노력이 드는지를 평가할만한 자료나 논의가 필요할 것 같습니다. 역시 새로운 페이지로 분리해서 진행하는 게 좋겠습니다.

--류광

닥북을 최대한 활용한다는 것

저장과 게시의 분리와 관련해서:

글을 쓰면서 계속 떠오르는 생각은 문서를 만들고 HTML로 만들어서 게시하는 것 이상의 뭔가가 필요하다는 것입니다. 예를 들어 KLDP는 닥북 활용을 위해 위키를 도입하려 했다가 위키의 위력에 매료되어서 문서화 전체를 위키로 대체해 버렸습니다. 사실 여럿이서 문서를 만들고 깔끔한 형태로 게시하는 것만으로 본다면 위키만한 것도 없을 겁니다.

그러나 저는(그리고 닥북을 고민하는 다른 분들 역시) 문서화에는 그 이상의 것이 있다고 생각하고, 그 이상의 것을 가져다 주는 것이 닥북이라고 생각하고 있습니다. 닥북을 최대한 활용하는 문서화라는 것이 어떤 모습일까요? 그 상을 최대한 일치시키는 것이 이 논의 전체의 기본적인 목표일 것입니다....

--류광

단순하게 공동작업을 통한 HTML 게시를 생각하면, 위키 + 부가기능이면 충분하다고 생각합니다. 닥북을 통한 문서화의 장점을 만들어야 할 것 같습니다. 현재 위키와 비교해서 강점이라고 할 수 있는것인 printer-friendly output(pdf)일것 같습니다. 이것은 TeX의 진입장벽보다는 낮지만, 역시나 쉽게 할 수 없어서, 강점이 제대로 드러나지 않는 것 같습니다. 이부분을 보다 쉽게 할 수 있도록 하면 좋을 것 같습니다. 웹에서 보이는 화면과 같은 화면을 pdf형태로 얻을 수 있고, 윈도우 help file(chm)형태로 얻을 수 있다. 이런 다양한 활용도를 문서화프로젝트에서 실증하는것이 필요할 것 같습니다.

-- dyaus

제가 운영하는 사이트 역시 wiki를 통해서 문서화작업을 하도록 유도하고 있습니다만 개인적으론 docbook를 사용하고 있습니다. wiki를 도입한 이유는 일반 유저들이 docbook의 사용에 일말의 두려움을 가지고 있고 이 때문에 문서화로의 참여자체가 거의 이루어지지 않았기 때문입니다. wiki를 도입한 이후로는 확실히 예전 보다는 작성되는 문서의 수가 늘어 났습니다.

위키가 문서작성이 편함에도 불구하고 개인적으로 docbook를 고집하는 이유는 우선 특별히 docbook이 위키보다 더 어려운지 모르겠고, 위에서 언급되었듯이 위키는 뭔가 빠진게 있다는 생각들 때문입니다. 위키로 작성된 문서는 동일한 위키를 이용했다면 모르지만 사이트 마다 형식이 약간씩 다릅니다. 문서가 정보로써 가치를 가지려면 예쁘게 보이는 것도 중요하지만(사실 docbook도 예쁘지만) 배포가 용이해야 하고 표준화된 포맷을 지킬수 있어야 된다고 생각합니다. 위키는 정해진 표준이 없고 배포역시 용이하지 않습니다. HTML의 서브셋, 이게 저의 개인적인 생각입니다. HTML역시 xml로 변환될 수 있고 다시 pdf로 변환 될 수 있지만 문서자체가 정보가 되기에는 근본적으로 결함을 가지고 있는데, 위키 역시 이러한 근본적인 결함을 가지고 있습니다. 다만 용이하게 참여할 수 있다는 것은 docbook에 비해서 큰 장점이라고 할 수 있겠습니다. 이것은 위키의 실시간성 때문이고 편집할때와 보여지는게 비슷해서 감각적으로 작업할 수 있다는 이유 때문이라고 생각됩니다. docbook 역시 몇번 작성하다 보면 감각적으로 작업할 수 있지만, (주로 HTML)보여지게 하려면 부가적인 작업이 필요하다는 단점도 있구요. 두번 손이 갑니다.

오늘이 처음 참가라서 이곳 글들의 흐름과는 관계없이 그냥 그동안 제가 docbooK와 위키에 대해 가졌던 일반적인 생각을 다루었습니다.

-- ?yundream

문서 자체가 정보라는 부분에 많이 동감합니다. 저는 문서 전체를 여러 형태로 변환하는 것과 함께 문서에 담긴 부분적인 정보를 검색, 취합해서 또다른 결과물을 만들어 내는 쪽의 활용에 관심이 많습니다. 간단하게는 주어진 닥북 XML 문서들에서 루트 요소의 제목만(/chapter/title) 뽑아내서 문서 목록을 만든다거나 등등... 문서화를 소비(?)하는 사람들이 그런 식의 활용을 얼마나 요구하는지는 잘 모르겠지만, 문서가 수십, 수백이 넘어가게 되면 그런 쪽의 활용이 중요해지지 않을까 예상합니다. --류광

저장과 게시의 분리에서 관리자의 개입 정도

관리자의 승인 절차에 대해:

일단 위키처럼 갱신만 되면 업데이트 목록이 나오고.. "판 올림"을 결정하면 정식으로 게시가 되도록 하면 좋지 않을까 생각합니다. 관리자가 꼭 개입하지 않아도 될 것 같습니다. 관리자가 선정하는 것은 최근 갱신된 추천 문서? 정도가 좋지 않을까요? --yongjoo

저는 어떤 형태로든 승인 절차가 필요하다고 생각합니다. 닥북 한글 문서화는 뭐랄까 닥북 한국의 공식 문서들을 만드는 일이라고 보거든요. 작업 현황(작업중, 승인 대기, 승인 등)을 일목요연하게 볼 수 있는 장치만 있으면 되지 않을까요?

혹시 위키나 phpNuke 같은 어떤 원스탑 모형을 생각하고 계신지요?(문서 올리고 버튼 클릭하면 결과가 나오고 등등...) 그게 편하긴 하겠지만 닥북 XML의 위력을 최대한 발휘하려면 (적어도 현재로서는)파일 시스템 상의 정적인 파일들을 셸에서 직접 다루는 작업도 필요할 거라고 예상하고 있습니다...

--류광

류광님 말씀에 따르자면 일종의 편집부?를 거쳐 책을 펴내는 온라인 퍼블리셔? 사이트가 되는 것인데요. 멋진 일이라고 생각합니다. 잘되면 문서를 작성하는 사람들에게 동기부여도 될 수 있을 것이구요(닥북 한국의 문서 사이트가 유명해지고 어느정도 권위를 인정 받는다면 가능할 것 같습니다). --yongjoo

버전 제어에서 작성자의 신원 보장

저장 시스템에 관련해서:

좀더 욕심을 내자면.. 자신의 작성한 문서와 함께 gpg 싸인 같은 것을 같이 저장하고 검증하고 할 수 있으면 좋을 것 같습니다. 아무래도 글은 소스코드와는 다른 점이 있어서, 자신의 사상이라든가.. 주장이라든가.. 하는 것이 포함된다면 남이 함부로 고치는 것을 원하지 않는 수가 훨씬 많기 때문에요. cvs를 쓴다면 아예 수정 못하게 하거나 또는 누가 어떻게 수정했는지 알 수는 있겠지만.. --yongjoo

구체적인 저장 시스템

저장 시스템에 관련해서:

CVS보다는 좀 더 간단한 버젼 관리 시스템을 만들어 쓰는 것이 나을 것 같습니다. 사실 문서 작성에 있어서 브랜치나 머지같은 복잡한 기능들은 거의 쓰이지 않을 것이고, 사실 히스토리 관리가 주 목적일텐데, 이런건 버젼간 차이를 저장해 놓는 것만으로도 쉽게 해결할 수 있을 겁니다.

그리고 XML 저장은 파일 시스템보다는 XML 문서용 데이터베이스가 낫다는 생각입니다. 특히 XML이 파싱된 채로 저장되기 때문에 검색이나 문서 일부분 추출 등이 용이하다는 것이 파일 시스템에서는 제공하기 힘든 장점입니다. 다른 도구들을 쓸 때에는 임시 파일을 만들어 작업하면 될 테고요.

-- 김민식

버전 관리 시스템을 직접 만드는 거 어렵지 않나요? 저장 시스템이 파일 기반이라면 그냥 CVS를 사용해도 좋을 것 같습니다. 그러나 XML 문서 데이터베이스를 채택한다면 직접 만들 필요가 있겠네요.

XML 문서용 데이터베이스도 매력적인데요. 몇 가지 대표적인 과제들을 설정하고 파일 시스템과 데이터베이스에 대해 각각 평가를 해 봤으면 좋겠네요.

--류광

XML 데이터베이스가 여러가지로 가능성을 제시하는 것은 사실입니다만, 일단은 쉽고 빨리 구현할 수 있는 것으로부터 시작을 하고, 차차 더 고급 기술의 시스템으로 발전시키는 것이 현실적이지 않을까요?

기본적으로 버전 관리는 익숙한 CVS로 하고, 게시를 위한 저장은 파일시스템에 하는 것이 일단 쉽고 간단하고.. 문서 변환도 쉘스크립 정도로 해결할 수도 있고.. 일단 이렇게 시작하는것을 목표로 하는 것이 현실적이라고 생각합니다. 물론 XML DB에 버전관리 기능이 돌아가는 시작품을 곧 선보일 수 있다면 이야기가 달라지겠지요..

--yongjoo

저도 지금은 그게 합리적일 것 같습니다. 나중에 XML DB로 전환한다고 해도 파일 시스템의 파일들을 일괄적으로 XML DB에 집어 넣는 게 그리 어렵지 않을 것이구요.

다만... 두 접근방식에서 각각 아쉬운 점들을 생각하 본다면, 우선 파일 시스템에서는 유연하고도 효율적인 검색 기능을 어떻게 얻을 수 있는가의 문제가 걸립니다. 특히 온라인 상의 검색이요. 예를 들어 php에서 셸의 grep을 수행한다거나 XmlStarlet 같은 도구를 통해서 XPATH 질의를 수행한다거나 하는 방식으로 해결될 수도 있겠지만 나중에 문서가 많아지면 서버에 꽤 부담이 가지 않을까요?

그리고 문서의 범주 같은 문서 메타정보는 어떤 식으로 처리해야 할지도 걸립니다. 이 부분은 XML DB도 마찬가지인 것 같은데요. Berkeley DB XML에 관계형 DB에서 볼 수 있는 기능들도 있는지 모르겠네요.

--류광

Berkeley DB XML은 XML 저장 및 XPath 검색만을 제공합니다. 메타 정보는 최상위 요소에 속성으로 추가하는 방식으로 지원하고 있습니다. 하지만 보다 유연한 메타 정보 관리를 위해서라면 메타 정보를 별도로 저장하는 것이 좋을 것 같습니다. -- 김민식

DocBook.or.kr에 처음으로 조심스럽게 글 남깁니다. ^^ 우선 표준화를 염두에 둔다면 화일 시스템이 낫고, 편의성을 놓고 본다면 DB가 아무래도 유리하겠죠~ 하지만, Docbook의 원래 의도가 txt에 가까운 ?표준화 된 문서인 걸 생각할 때 화일시스템이 좋을 것 같습니다.

꼭 필요하다면, 화일시스템을 유지하면서 필요하다면 DB시스템도 같이 활용하는 방안이 좋을 거라 생각됩니다.

-- ?cjdma(우연근)

게시 시스템의 범주 기능과 관련해서, 관계형 DB의 필요성

문서 범주에 대해 좀 더 첨언하자면, 저는 온라인 서점 같은 다중 범주 방식(PHPer들이 흔히 무한 카테고리라고 부르는거)이 이상적이라고 봅니다. 예를 들어 (잠깐 책 선전-.-) 제가 번역한 '게임 프로그래머를 위한 자료구조와 알고리즘'에 대한 강컴의 페이지를 보면 이 책은 세 가지 범주에 속하며 접근할 수 있는 경로는 네 가지입니다. 특히 흥미로운 것은 게임 프로그래밍이라는 상세 범주에 접근하는 경로가 두 가지라는 점입니다. 이런 식의 접근은 파일 시스템의 디렉터리 구조로도 부족하고(혹시 *nix의 '링크'라는 걸로 해결할 수 있을까요?), XML DB는 잘 모르겠고, 관계형 DB라면 자연스럽게 해결할 수 있습니다.

문서의 기본적인 메타 정보는 관계형 DB에 두고, 관계형 DB의 항목에 문서의 파일 경로나 XML DB의 레코드 번호(???) 같은 걸 저장해 두는 식의 혼합형도 생각해 볼 수 있을 것입니다....

--류광

파일 시스템에서 구현한다면 다중 범주는 링크로 다 해결 가능합니다.

돌보에서는 메타 정보를 XML로 만들어서 별도로 저장하고 있습니다. XML 형태가 필요없다면 그냥 Berkeley DB를 쓰는 것도 좋습니다. Berkeley DB와 Berkeley DB XML 모두를 변경하더라도 한 트랜잭션으로 처리할 수 있거든요. -- 김민식

빌드 가능한 문서화

BuildableDocumentation 을 문서화의 주요 목표 중 하나로 추가하는 문제....

기초적인 생각들(토론 참고용)

문서화의 정의

문서화(documentation)

주어진 문제 영역에 대한 조직화된 문서들을 만들고 관리하는 과정 또는 그 결과로 생긴 문서들의 집합


왜 문서화인가?

  • 닥북에 대한 지식과 정보를 공유한다.
  • 닥북 사용 수요를 우리 스스로 창출한다.
  • 닥북을 이용한 문서화의 전형, 모범을 창출하고 전파한다.
  • 개별 프로젝트들을 추동하고 조직화한다.

(사람 이외의) 프로젝트 3 대 요소: 내용 완성, 도구 완성, 절차 완성

내용 : 기존 문서 정리, 영문 문서 번역, 게시판 및 위키에서 내용 추출

도구 : 작성, 변환, 관리. 다양성, 선의의 경쟁

절차: 수작업과 일괄 처리의 이상적인 혼합을 찾자.


사람: 절차에 기반한 역할 모형 구축이 필요하다.

내용 생성 역할: 지은이, 엮은이, 옮긴이

관리 역할: 원본 저장소 관리, 게시 공간 관리


저장과 게시의 분리

온라인으로 할 수 있는 것과 오프라인으로 할 수 있는 것의 현실적인 구분

위키가 문서화 전체를 대신할 수는 없다.

데이터베이스로서의 DocBook XML 문서 집합

버전 제어는 필수.


문서화 대상: DocBook 관련 기술, 도구, 응용 분야

문서화 종류 - 입문서, 하우투, FAQ, 튜토리얼

입문서: 대상에 대한 소개

튜토리얼: 대상의 준비에서 기본적인 활용에 이르는 순차적인 구성의 문서

FAQ : 대상에 대한 질문 답변 모음


할 일:

핵심 그룹 결성 - 모든 논의를 주도, 종합하고 결의 사항들을 추진하는 3~5 인의 열성적인 참여자들

문서화의 목적, 방향에 대한 논의

절차와 저장-관리-게시 시스템에 대한 논의

절차 문서화

시스템 구축

문서화 참여 제안서 작성, 참여 유도

제일 위로
최종 수정 일시: 12월 03일(2005년) 09:19 AM 편집 | 정보 | 차이 | 비슷한페이지 | DebugInfo
유용한 페이지들: 분류 분류 | 자유로운 연습장 SandBox | 무작위 페이지들 RandomPages | 인기있는 페이지들 MostPopular