VCS라 함은 Version Control System을 말씀하시는 건가요? 그렇다면 CVS나 SVN 혹은 RCS 같은걸 말씀하시는 것이겠군요. 확인차 질문 드려 봅니다.

또 VCS를 이용한다면 어떤 식으로 하는 것이 좋을까요? 위키는 그 자???가 포메팅까지 담당하는 부분이 있기 때문에 편리???니다. 지금까지 여기 위키가 좀 기존 사용자 분들께 불편함을 드리고는 있지만요.

VCS에 넣고 작업한다면 어떤 형태가 좋을지 그런 것도 고민해 봐야 하??? 않을까 싶습니다. 공식 문서의 경우 특정 XML 문법에 맞게(아마도 DTD도 있는 것 같은데) 작성을 해야 하는 듯 싶네요. 문서 작업을 바로 이 형식으로 해야 할지 어떨지 모르겠습니다. 무엇보다 번역에 참가하시는 모든 분들이 필요한 DTD와 XML 사용법을 익혀야 할지도 모르겠군요. 포매팅 방법 결정도 중요할 것 같네요.

네. 어차피 공식 한글 문서를 커밋하려면 정해진 ???맷에 맞게 작성을 해야 하니 아예 번역 작업을 시작??? 때부터 정해진 포맷을 사용하는게 더 효율적일 것???라 생각합니다.

서버에 저장소를 따로 마련하??? 것보다는 github.com과 같은 호스팅서비스를 활용하는 것도 나쁘지 않을 것 같아요.

일단 지금과 같은 방식으로 할 때와 VCS를 이용해 ???장소에 저장하고 바로 커밋할 수 있도록 할 때 모두 나름의 장단점이 있을 것으로 보입니다.(쓰다가 나라가서...)

VCS를 사용하는 경우 장점으로는 바로 ???밋할 수 있는 가공품을 만들어 내기가 유리하다는 ???이 있겠고 단점으로는 번역에 참가하시는 분들의 진입 장벽이 높아 진다는 문제가 있을 수 있겠습니다.

현재와 같은 방식으로 진행하는 경우 진입 장벽??? 낮다는 장점이 있을 수 있지만, 추가 변환 작업과 ???비전에 대한 관리 작업 비용이 발생한다는 단점이 ???겠네요.

이런 것 이외에도 각각의 장점 및 단???이 있을 것으로 보이는데 지속적인 토의(토론?)??? 통해 나누어 보고 결정하는 것이 좋을 것 같습니다. 혹은 두 방식을 병행해서 검토하고 커밋하는 그룹과 일단 번역하는 그룹으로 나눌 수도 있을 것입니다. ???느 정도는 상호 보완적인 면이 있으니까요.

사실상 CVS나 SVN 등 서버를 구축하는 것은 그리 어???지 않습니다. 그러나...

일단 저부터도 번역을 ??? 어떻게 해야 할 지 모르겠군요. 저 서비스를 어떻??? 쓰는지도 모르겠고 더군다나 Gentoo 문서 관련 XML 문???도 모릅니다. 제가 걱정하는 것은 이렇게 함으로써 그나마 번역을 하고 계시던 분들이 부담을 느끼시고 포기하시는 것은 아닌가 싶습니다. 그리고 충분히 그럴 가능성이 있다고 보고요. 번역에 대한 의견을 가???신 분들이 여러 분 계신 듯 한데 이 의견이 각자 다???신 것 같네요.

지금 이 방향으로 진행할 경우 ???역을 이끌고 가실 분이 없는 이상, 오히려 역효과가 생기는게 아닐까 싶네요. 찬 물을 끼얹는 듯 해서 죄???합니다만, 제가 보기에 지금은 누군가 시작하는 것??? 중요하다기 보다는 시작한 뒤에 이 작업을 계속 유지해서 갈 수 있고 동시에 현재 번역에 참여하신 분???도 수용할 수 있는 길을 선택하는 것이 중요한 것이 아닌가 싶습니다. 시작은 그 뒤에 해도 늦지 않을 거???고 봅니다.

또 번역에 참여하신 분들이 마음의 준비를 비롯해 기술적인 부분에 대해서도 준비가 되셨는지 어떤지 알 수 없는 상태에서 이 방식으로 진???한다면 오히려 번역 결과물 도출은 늦어질 수도 있???고 보입니다. 더해서 가능한한 발생할 지도 모르는 ???제는 미연에 예방하는 것이 좋은데 지금 이 방식이 얼마나 번역에 기여하신 분들께 익숙한지 알 수 없기 때문에 여러 가지 당황스러운 일이 발생할 수도 있???니다.

위에도 말씀 드렸지만 포기하시는 분이 ???을 수도 있구요. 사람에 따라선 VCS를 자주 사용해 ???지 않은 분도 계실 겁니다.

솔직히 말씀 드려서 VCS에 결과물을 저장하는 방식이 잘못되었다거나 그???게 보진 않습니다. 하지만 위키도 충분히 그런 저장 및 버전 관리 기능을 가지고 있다고 보고 번역에 조???씩이라도 참여하시는 분들이 혼란스러우시지 않을??? 싶습니다. 그리고 이미 원문을 익스포트 받아다가 커밋해 두신 거 같은데, 그럼 기존에 번역하던 내용??? 또 어떻게 해야 될런지 그것도 문제군요. 어쨌든 상황 정리가 어느 정도 된 뒤에 적용하더라도 적용해야 하지 않을까 싶습니다.

gentoo.or.kr에서의 사용만을 위한 번역 작업이라면 ???키 기반도 좋은 성택이라고 봅니다만, 본문이 공식 홈페이지의 커미터 자격에 관한 글이었고, 장기적으로 보았을 때 문서의 유지보수를 위해 official document의 변화를 쉽게 추적할 수 있도록 git든 svn이든 VCS의 도입은 불가피할 것으로 생각합니다.

기???에 번역하던 내용을 적용하는 문제는 지금 VCS를 적???하든 하지 않든 커미터가 일일이 다 변환을 하셔야 하는 수고로움이 있을 테니까요.

organization을 만???건 '무조건 이 시스템으로 하자'의 의미가 아니라 '이런 저런 방향으로 진행을 직접 해 본 후에 선택을 하자'는 생각이니, 기존의 위키 시스템을 사용하는 것으로 결론이 나면 폐쇄를 하도록 하겠습니다. 사실 github에다 만든것도 사실 제가 할 줄 아는게 git 뿐이??? ㅎㅎ

아, 어떤 말씀이신지 알겠습니다. 최종적으론 관리를 위한 저장소가 필요하다는 점에는 공감합니다. 그렇다면 조금 방향을 바꿔서 이렇게 해 보는 것은 어???까요?

우선 빠른 번역 및 적극적인 참여 등을 ???해서 위키에서 번역 작업을 진행하고 이것을 변환하여 어느 정도 이상의 완성도를 가진 자료를 새 리비???으로 커밋하는 등의 방법을 써서 지속적으로 문서를 업데이트하고 이것을 공식 문서에 커밋하는 겁니다. 그렇게 되면 중간에서 변환하는 분이 계셔야 하고 ???렇긴 하겠지만, 일단은 이 방법이 좋은 거 같습니다. 그러니까 두 방식을 혼용해서 두 마리 토끼를 다 잡??? 보자는 거조.

근데... 전 git를 모르겠네요. 제??? 유일하게 아는건 svn... 아하하하... 다른 분들은 어???신가요? 요즘 의견들이 없으시네요 계속.

1년전에 이런 준비가 되어 있었군요 'ㅅ' 늦게 발견해서 포크해봅니다. git건 svn이건 hg건 최근에 좀 익혀둔지라 저 같은 경우는 이들 중 어느 쪽을 가도 버전관리에는 딱히 지장이 없을 것 같습니다. 조만간 하나하나씩 다시 시작해볼듯 싶네요. kldp에 제가 해둔게 있습니다만 아마 번역을 제대로 하려면 새로 해야 하지 않나 싶습니다.

아 그리고 혹시 이거 한 1년 지난거 같은데 메뉴얼 파일 다시 새로 받아야 하지 않을까요? 거의 1~2년에 한번씩 내용이 바뀌다보니 얼마나 바뀌었는지 확인도 해봐야 할 것 같네요.

이 시기에 진행에 나서셨던 분들과 다시 연계가 잘 되서 진행이 원활할 수 있다면 좋겠습니다. 저같은 경우는 의견 정리 하는 쪽으로 신경을 쓴 거라서 실제로 한건 하나도 없네요.

그나저나 DB 데이터 깨진거 글자 고치기도 해야 되는데 작년 여름에 한참 하다가 그 뒤로 제대로 못하고 있군요 ㅡ.ㅡ.