다음은 TNF의 활동 흐름와 태터툴즈의 개발 과정및 절차에 대한 설명을 담고 있습니다.

태터툴즈
1. 마일스톤 및 판번호

1.1 마일스톤
  마일스톤 코어는 태터툴즈의 코어 소스에 큰 변화가 있는 코드및 판올림을 의미합니다. 큰 변경사항이 있거나 사용자 UI및 사용성에 변화가 있는 경우에는 마일스톤 코어에 반영이 됩니다. 태터툴즈의 마일스톤 코어는 특별한 일이 없는 한 6개월을 주기로 생성됩니다. 마일스톤 코어 사이의 마이너 마일스톤들은 특별한 주기는 정해져 있지 않습니다.

1.2 판번호
태터툴즈는 '태터툴즈 1.X.X' 의 형태로 버전이 매겨지게 됩니다. 앞의 1은 태터툴즈 전체가 기존의 소스를 버리거나 새로운 프로그램으로 제작될 경우 변하게 됩니다. 따라서 앞의 판번호 1은 변하지 않습니다. 각 마일스톤 코어는 판번호의 1. 아래의 숫자에 영향을 줍니다. 예를 들어 태터툴즈 1.0 다음의 마일스톤 코어는 태터툴즈 1.1이며, 그 이후의 마일스톤 코어는 태터툴즈 1.2가 됩니다.
각 마일스톤 코어 아래의 판번호는 마이너 마일스톤 업데이트에 해당됩니다. 또한 버그 패치만이 있을 경우 한단계 하위의 판번호를 가지게 됩니다. 태터툴즈 1.1과 1.2 사이의 마이너 마일스톤 업데이트는 1.1.1이 되며, 태터툴즈 1.1.1의 버그를 해결한 판번호는 1.1.1.1이 됩니다.
판번호 매김의 경우 정책적인 이유에 의하여 변할 수 있습니다.

1.3 마일스톤 확정
  각 마일스톤 코어가 완료된 2개월 후, 다음 마일스톤 코어의 주 요건을 확정합니다. 확정 과정은 포럼에서 등록된 티켓들을 바탕으로 TNF와 TNC의 소스 모더레이터 그룹에서 회의를 통하여 결정하게 됩니다. 소스 모더레이터 회의의 구성원은 TNF 3인과 TNC 2인으로 구성되며, 각 요건의 통과를 위해서는 2/3 이상의 동의가 선행되어야 합니다.

2. 개발 과정

2.1 코드 수정
  코드에 접근할 수 있는 인원은 reporter와 developer로 제한됩니다. reporter는 sandbox와 브렌치 코드(branches 아래에 위치한 코드)를 수정할 수 있습니다. developer는 메인 트리 (trunk)도 수정할 수 있습니다. reporter가 브렌치 코드를 수정할 경우 반드시 명시적인 이유가 있어야 하며, 해당 내용이 dev@tattersite.com 메일링 리스트를 통하여 공유가 되어야 합니다.
코드를 수정할 경우 그 리비전은 반드시 trac에 미리 등록되어 있는 티켓과 연관이 되어 있어야 합니다. 1바이트의 코드 반영도 해당되는 티켓이 없는 경우에는 되돌리기 됩니다. 커밋 로그에 해당되는 티켓에 대한 언급 ( #123 형태의) 이 있어야 하며, 해당되는 티켓에도 관련된 리비전으로의 링크가 ( r123 형태의) 명시되어야 합니다.

2.2 티켓 등록
reporter와 developer는 티켓을 등록할 수 있습니다. 포럼에서 논의된 내용의 경우 2.3의 절차에 따라 해당 포럼지기가 티켓 등록을 맡습니다. 이외의 티켓 등록은 자체 버그 발견및 수정을 위한 경우가 아닌 경우 제한됩니다.

2.3 새로운 기능 추가시 절차
아래에서는 기능 추가및 버그 수정시의 절차를 순서대로 명시합니다.
    1. 포럼에서 의견을 모으거나 논의를 진행합니다
    2. 논의의 진행상태에 따라 해당 포럼 게시판의 모더레이터는 논의를 판단하여 해당 task를 티켓으로 등록하고, 해당 티켓으로의 링크를 포럼의 답글로 공지합니다. 경우에 따라 해당 글을 잠글 수도 있습니다. 티켓 등록시 담당자에 대해서는 TNF의 '티켓 분야별 담당자'를 참고하시기 바랍니다.
    3. 해당 티켓이 처리되는 과정이 명확하게 티켓에 명시되도록 합니다.
    4. 티켓이 완료되었을 경우 완료 상황을 포럼의 해당 글에 공지합니다.
    5. 개발이 완료된 상황 시점에서 해당 티켓의 처리자는 해당 기능에 대한 기술적인 설명을 trac의 CC란에 doc at tattersite.com을 입력하여 메일링으로 발송하도록 합니다.
    6. doc팀은 메일로 도착한 내용을 바탕으로 해당 문서의 사용자 판을 처리합니다. 이 과정에서 help.tattertools.com 이나 doc.tattersite.com 의 내용을 수정하게 됩니다.

2.4 포럼이 아닌 개발 과정에서 버그 수정 절차
아래에서는 개발 과정및 코드 리뷰에서 버그를 발견하여 수정하는 경우를 명시합니다.
    1. 수정 이전에 티켓을 반드시 등록합니다. 티켓 등록 과정에서 trac의 CC 란에 dev at tattersite.com 을 입력하여 개발팀이 해당 버그에 대하여 알 수 있도록 합니다.
    2. 모든 commit은 해당하는 티켓이 대응 되어 있어야 합니다. 티켓이 없으며 티켓으로의 링크가 명시되지 않은 리비전은 이후 되돌리기 되거나 무시됩니다. 이는 2.1에서 명시한 것과 동일합니다.
    3. 해당 버그 수정이 끝난 경우 해당 티켓을 !cement로 소유자를 수정하면서 CC 란에 dev at tattersite.com 을 입력하여 티켓 완료를 알립니다. 이후 해당 코드는 코드 안정성 검사 후 trunk에 반영됩니다.
    4. 3번 과정에서 실시된 코드 안정성 검사에서 문제가 발견된 경우 이유 명시와 함께 해당 티켓을 다시 코드 수정자에게 배당하며 CC 란에 dev at tattersite.com 또는 해당 티켓 반영자의 이메일 주소를 입력하여 티켓 처리자가 알 수 있도록 합니다.
    5. trunk에 반영하는 경우 티켓을 닫으며 간단한 설명을 doc at tattersite.com 으로 발송합니다. 이후 진행은 2.3의 6번 과정을 따릅니다.

2.5 지역화 및 언어리소스와 언어팩 처리 절차
아래에서는는 지역화 작업을 진행할 때와 언어 리소스를 수정할 때, 언어팩을 제작할 때의 절차에 대하여 명시합니다.
    1. 지역화 작업에 대한 토론은 포럼을 통하여 이루어집니다. 이 과정에서 태터툴즈의 해당 지역을 위한 지역화 과정 작업이 필요한 경우 논의가 완성 되는대로 지역화 팀의 리더가 티켓을 등록합니다.
    2. 티켓의 내용이 코드 수정에 관련된 경우, 지역화가 일반적인 수정이 아니라 해당 지역에 특화된 경우 브렌칭을 요구할 수 있습니다. 이 경우 해당 내용을 티켓에 명시하고 dev at tattersite.com 으로 CC를 명기하면 판단 후 해당 언어권을 위한 브렌칭을 실시합니다.
    3. 티켓의 내용이 출력되는 언어 리소스 수정에 관련된 경우, 수정을 원하는 언어 리소스의 위치와 변경 내용을 티켓에 명시한 채로 CC에 dev at tattersite.com 을 넣어 등록해야 합니다. 이 경우 개발팀에서는 해당 티켓을 처리하고 닫으면서 CC에 i18n at tattersite.com을 넣어 지역화 그룹이 수정 사실을 인지할 수 있도록 해야 합니다.
    4. 티켓의 내용이 언어팩 수정에 관련된 경우, 개발팀에서는 언어 리소스 클로징 일자를 정하고 해당 일자를 미리 공지해야 합니다. 리소스 수정이 중단되면 개발팀은 언어 리소스 제작 티켓을 등록하고 CC에 i18n at tattersite.com 을 명기합니다. 지역화 팀은 해당 티켓에 따라 현 버전의 언어팩 파일을 만들고 커밋합니다. 각 언어팩의 커밋은 반드시 티켓에 리비전이 명시되어야 합니다. 모든 언어팩의 번역이 끝나는 경우

2.6 문서 작성 절차
    1. 문서팀은 각 티켓의 처리 과정에서 들어온 요건을 처리합니다.
    2. 문서화가 끝날 경우 해당 문서의 국제화가 필요한 경우 해당 문서의 번역을 위한 티켓을 등록합니다. 티켓 등록시 CC에 i18n at tattersite.com을 명시하여 해당 팀이 티켓에 대해 알 수 있도록 합니다.
    3. 지역화팀에서는 해당 티켓에 따라 문서를 번역한 후 CC를 통하여 해당 문서가 번역되었음을 알리도록 합니다.
    4. 문서팀에서는 번역된 문서들과 함께 문서의 종류에 따라 필요한 부분에 게시한 후 티켓을 닫습니다.

TNF

1. 소스코드 이외의 회의 및 이벤트 진행 과정
    1. 모든 TNF의 이벤트 및 행사 진행 과정은 무조건 TNF의 trac ( http://dev.tattersite.com) 을 거치도록 합니다.
    2. TNF 오프라인 회의나 오프라인 모임, 이벤트 진행등의 경우 포럼에서 논의 후 책임자를 정합니다. 해당 책임자는 TNF trac에 eventer 로그인 계정을 획득하게 됩니다.
    3. 책임자는 TNF trac에 해당 모임 및 이벤트를 티켓팅합니다.
    4. 책임자는 해당 논의가 진행되는 포럼에 해당 티켓으로의 링크를 명시합니다.
    5. 해당 티켓이 처리되는 과정이 명확하게 티켓에 명시되도록 합니다.
    6. 티켓이 완료되었을 경우 완료 상황을 포럼의 해당 글에 공지합니다.

2. 티켓 담당자
포럼의 각 게시판에서 아래의 담당자는 각 토픽의 진행에 따라 위의 절차에 따라 티켓을 등록하게 됩니다.
  * 아이디어 및 기능 제안 : daybreaker
  * 스킨 및 플러그인 : J.Parker, Peris, graphittie
  * 다국어 지원 : Louice P.
  * 버그 보고 및 QA : daybreaker, graphittie, inureyes
  * 유저 인터페이스 : graphittie
  * TNF 토의 및 과제 설정 : inureyes

아래의 담당자들은 해당 팀의 리더입니다. 각 팀의 리더는 메일링 리스트를 관리하는 권한을 가지며, 각 팀의 구성을 포함한 그 분야에 대한 결정권을 갖습니다.
  * 다국어 및 국제화 지원 : Louice P. (i18n at tattersite.com)
  * 사용자 지원 : LonnieNa (support at tattersite.com)
  * 코어 개발 : inureyes (dev at tattersite.com)
  * 플러그인 : J.Parker (plugin at tattersite.com)

3. 티켓 분야별 담당자
태터툴즈 코드 수정을 위한 티켓 등록시 티켓을 받는 분은 아래의 구분에 따라 해당되는 분께 지정하면 됩니다.

coolengineer
    * BlogAPI
    * po 관련 다국어 지원 프레임

daybreaker
    * XHTML/CSS
    * microformats/RSS/...
    * Core 버그 수정 및 기능 개선
    * DB 백엔드

graphittie
    * skin.html 하부 구조 관련(디자인 제외, 플러그인 이벤트 포함)
    * 관리자 화면 XHTML/CSS
    * 관련 버그 수정

inureyes
    * 새로운 기능 추가
    * 버그 수정

J.Parker
    * 기본 및 공개된 기타 플러그인
    * Universe/Expansion pack 관련 플러그인
    * 플러그인 업데이트 알림 플러그인
    * 기타 지원 플러그인

Louice
    * 다국어 번역 지원
    * 언어 리소스 수정

4. TNF Eventer / developer
TNF의 trac( http://dev.tattersite.com) 에서는 TNF에서 지원하는 개발 프로그램에 대한 저장소 제공 및 각종 모임과 이벤트를 티켓을 통하여 관리합니다.

4.1 developer
태터툴즈와 관련된 프로젝트를 진행하는 경우 TNF trac의 developer로 등록하여 subversion 저장소를 사용하실 수 있습니다. 등록을 위해서는 TNF 포럼을 통하여 요청하시면 해당 담당자가 처리하게 됩니다.

4.2 eventer
TNF 와 관련된 모임 및 이벤트, 프로젝트를 주관하는 역할을 하게 됩니다. 포럼에서 해당 이벤트에 대한 중지가 모이고 담당자가 정해지면 TNF trac 담당자는 해당 책임자에게 eventer 권한을 발급합니다. 해당 모임 및 이벤트 이후 해당 id 는 지속성 여부에 따라 삭제 또는 아무 권한이 없는 pool로 임시 이동됩니다.

이 문서는 2007년 2월 2일에 처음 작성되었습니다.
이 문서는 2007년 2월 5일에 최종적으로 수정되었습니다.
이 문서는 2007년 2월 9일부터 적용됩니다.
이 문서는 dev 그룹에 의하여 논의되었습니다.

다음은 TNF의 활동 흐름와 태터툴즈의 개발 과정및 절차에 대한 설명을 담고 있습니다.

태터툴즈
1. 마일스톤 및 판번호

1.1 마일스톤
  마일스톤 코어는 태터툴즈의 코어 소스에 큰 변화가 있는 코드및 판올림을 의미합니다. 큰 변경사항이 있거나 사용자 UI및 사용성에 변화가 있는 경우에는 마일스톤 코어에 반영이 됩니다. 태터툴즈의 마일스톤 코어는 특별한 일이 없는 한 6개월을 주기로 생성됩니다. 마일스톤 코어 사이의 마이너 마일스톤들은 특별한 주기는 정해져 있지 않습니다.

1.2 판번호
태터툴즈는 '태터툴즈 1.X.X' 의 형태로 버전이 매겨지게 됩니다. 앞의 1은 태터툴즈 전체가 기존의 소스를 버리거나 새로운 프로그램으로 제작될 경우 변하게 됩니다. 따라서 앞의 판번호 1은 변하지 않습니다. 각 마일스톤 코어는 판번호의 1. 아래의 숫자에 영향을 줍니다. 예를 들어 태터툴즈 1.0 다음의 마일스톤 코어는 태터툴즈 1.1이며, 그 이후의 마일스톤 코어는 태터툴즈 1.2가 됩니다.
각 마일스톤 코어 아래의 판번호는 마이너 마일스톤 업데이트에 해당됩니다. 또한 버그 패치만이 있을 경우 한단계 하위의 판번호를 가지게 됩니다. 태터툴즈 1.1과 1.2 사이의 마이너 마일스톤 업데이트는 1.1.1이 되며, 태터툴즈 1.1.1의 버그를 해결한 판번호는 1.1.1.1이 됩니다.
판번호 매김의 경우 정책적인 이유에 의하여 변할 수 있습니다.

1.3 마일스톤 확정
  각 마일스톤 코어가 완료된 2개월 후, 다음 마일스톤 코어의 주 요건을 확정합니다. 확정 과정은 포럼에서 등록된 티켓들을 바탕으로 TNF와 TNC의 소스 모더레이터 그룹에서 회의를 통하여 결정하게 됩니다. 소스 모더레이터 회의의 구성원은 TNF 3인과 TNC 2인으로 구성되며, 각 요건의 통과를 위해서는 2/3 이상의 동의가 선행되어야 합니다.

2. 개발 과정

2.1 코드 수정
  코드에 접근할 수 있는 인원은 reporter와 developer로 제한됩니다. reporter는 sandbox와 브렌치 코드(branches 아래에 위치한 코드)를 수정할 수 있습니다. developer는 메인 트리 (trunk)도 수정할 수 있습니다. reporter가 브렌치 코드를 수정할 경우 반드시 명시적인 이유가 있어야 하며, 해당 내용이 dev@tattersite.com 메일링 리스트를 통하여 공유가 되어야 합니다.
코드를 수정할 경우 그 리비전은 반드시 trac에 미리 등록되어 있는 티켓과 연관이 되어 있어야 합니다. 1바이트의 코드 반영도 해당되는 티켓이 없는 경우에는 되돌리기 됩니다. 커밋 로그에 해당되는 티켓에 대한 언급 ( #123 형태의) 이 있어야 하며, 해당되는 티켓에도 관련된 리비전으로의 링크가 ( r123 형태의) 명시되어야 합니다.

2.2 티켓 등록
reporter와 developer는 티켓을 등록할 수 있습니다. 포럼에서 논의된 내용의 경우 2.3의 절차에 따라 해당 포럼지기가 티켓 등록을 맡습니다. 이외의 티켓 등록은 자체 버그 발견및 수정을 위한 경우가 아닌 경우 제한됩니다.

2.3 새로운 기능 추가시 절차
아래에서는 기능 추가및 버그 수정시의 절차를 순서대로 명시합니다.
    1. 포럼에서 의견을 모으거나 논의를 진행합니다
    2. 논의의 진행상태에 따라 해당 포럼 게시판의 모더레이터는 논의를 판단하여 해당 task를 티켓으로 등록하고, 해당 티켓으로의 링크를 포럼의 답글로 공지합니다. 경우에 따라 해당 글을 잠글 수도 있습니다. 티켓 등록시 담당자에 대해서는 TNF의 '티켓 분야별 담당자'를 참고하시기 바랍니다.
    3. 해당 티켓이 처리되는 과정이 명확하게 티켓에 명시되도록 합니다.
    4. 티켓이 완료되었을 경우 완료 상황을 포럼의 해당 글에 공지합니다.
    5. 개발이 완료된 상황 시점에서 해당 티켓의 처리자는 해당 기능에 대한 기술적인 설명을 trac의 CC란에 doc at tattersite.com을 입력하여 메일링으로 발송하도록 합니다.
    6. doc팀은 메일로 도착한 내용을 바탕으로 해당 문서의 사용자 판을 처리합니다. 이 과정에서 help.tattertools.com 이나 doc.tattersite.com 의 내용을 수정하게 됩니다.

2.4 포럼이 아닌 개발 과정에서 버그 수정 절차
아래에서는 개발 과정및 코드 리뷰에서 버그를 발견하여 수정하는 경우를 명시합니다.
    1. 수정 이전에 티켓을 반드시 등록합니다. 티켓 등록 과정에서 trac의 CC 란에 dev at tattersite.com 을 입력하여 개발팀이 해당 버그에 대하여 알 수 있도록 합니다.
    2. 모든 commit은 해당하는 티켓이 대응 되어 있어야 합니다. 티켓이 없으며 티켓으로의 링크가 명시되지 않은 리비전은 이후 되돌리기 되거나 무시됩니다. 이는 2.1에서 명시한 것과 동일합니다.
    3. 해당 버그 수정이 끝난 경우 해당 티켓을 !cement로 소유자를 수정하면서 CC 란에 dev at tattersite.com 을 입력하여 티켓 완료를 알립니다. 이후 해당 코드는 코드 안정성 검사 후 trunk에 반영됩니다.
    4. 3번 과정에서 실시된 코드 안정성 검사에서 문제가 발견된 경우 이유 명시와 함께 해당 티켓을 다시 코드 수정자에게 배당하며 CC 란에 dev at tattersite.com 또는 해당 티켓 반영자의 이메일 주소를 입력하여 티켓 처리자가 알 수 있도록 합니다.
    5. trunk에 반영하는 경우 티켓을 닫으며 간단한 설명을 doc at tattersite.com 으로 발송합니다. 이후 진행은 2.3의 6번 과정을 따릅니다.

2.5 지역화 및 언어리소스와 언어팩 처리 절차
아래에서는는 지역화 작업을 진행할 때와 언어 리소스를 수정할 때, 언어팩을 제작할 때의 절차에 대하여 명시합니다.
    1. 지역화 작업에 대한 토론은 포럼을 통하여 이루어집니다. 이 과정에서 태터툴즈의 해당 지역을 위한 지역화 과정 작업이 필요한 경우 논의가 완성 되는대로 지역화 팀의 리더가 티켓을 등록합니다.
    2. 티켓의 내용이 코드 수정에 관련된 경우, 지역화가 일반적인 수정이 아니라 해당 지역에 특화된 경우 브렌칭을 요구할 수 있습니다. 이 경우 해당 내용을 티켓에 명시하고 dev at tattersite.com 으로 CC를 명기하면 판단 후 해당 언어권을 위한 브렌칭을 실시합니다.
    3. 티켓의 내용이 출력되는 언어 리소스 수정에 관련된 경우, 수정을 원하는 언어 리소스의 위치와 변경 내용을 티켓에 명시한 채로 CC에 dev at tattersite.com 을 넣어 등록해야 합니다. 이 경우 개발팀에서는 해당 티켓을 처리하고 닫으면서 CC에 i18n at tattersite.com을 넣어 지역화 그룹이 수정 사실을 인지할 수 있도록 해야 합니다.
    4. 티켓의 내용이 언어팩 수정에 관련된 경우, 개발팀에서는 언어 리소스 클로징 일자를 정하고 해당 일자를 미리 공지해야 합니다. 리소스 수정이 중단되면 개발팀은 언어 리소스 제작 티켓을 등록하고 CC에 i18n at tattersite.com 을 명기합니다. 지역화 팀은 해당 티켓에 따라 현 버전의 언어팩 파일을 만들고 커밋합니다. 각 언어팩의 커밋은 반드시 티켓에 리비전이 명시되어야 합니다. 모든 언어팩의 번역이 끝나는 경우

2.6 문서 작성 절차
    1. 문서팀은 각 티켓의 처리 과정에서 들어온 요건을 처리합니다.
    2. 문서화가 끝날 경우 해당 문서의 국제화가 필요한 경우 해당 문서의 번역을 위한 티켓을 등록합니다. 티켓 등록시 CC에 i18n at tattersite.com을 명시하여 해당 팀이 티켓에 대해 알 수 있도록 합니다.
    3. 지역화팀에서는 해당 티켓에 따라 문서를 번역한 후 CC를 통하여 해당 문서가 번역되었음을 알리도록 합니다.
    4. 문서팀에서는 번역된 문서들과 함께 문서의 종류에 따라 필요한 부분에 게시한 후 티켓을 닫습니다.

TNF

1. 소스코드 이외의 회의 및 이벤트 진행 과정
    1. 모든 TNF의 이벤트 및 행사 진행 과정은 무조건 TNF의 trac ( http://dev.tattersite.com) 을 거치도록 합니다.
    2. TNF 오프라인 회의나 오프라인 모임, 이벤트 진행등의 경우 포럼에서 논의 후 책임자를 정합니다. 해당 책임자는 TNF trac에 eventer 로그인 계정을 획득하게 됩니다.
    3. 책임자는 TNF trac에 해당 모임 및 이벤트를 티켓팅합니다.
    4. 책임자는 해당 논의가 진행되는 포럼에 해당 티켓으로의 링크를 명시합니다.
    5. 해당 티켓이 처리되는 과정이 명확하게 티켓에 명시되도록 합니다.
    6. 티켓이 완료되었을 경우 완료 상황을 포럼의 해당 글에 공지합니다.

2. 티켓 담당자
포럼의 각 게시판에서 아래의 담당자는 각 토픽의 진행에 따라 위의 절차에 따라 티켓을 등록하게 됩니다.
  * 아이디어 및 기능 제안 : daybreaker
  * 스킨 및 플러그인 : J.Parker, Peris, graphittie
  * 다국어 지원 : Louice P.
  * 버그 보고 및 QA : daybreaker, graphittie, inureyes
  * 유저 인터페이스 : graphittie
  * TNF 토의 및 과제 설정 : inureyes

아래의 담당자들은 해당 팀의 리더입니다. 각 팀의 리더는 메일링 리스트를 관리하는 권한을 가지며, 각 팀의 구성을 포함한 그 분야에 대한 결정권을 갖습니다.
  * 다국어 및 국제화 지원 : Louice P. (i18n at tattersite.com)
  * 사용자 지원 : LonnieNa (support at tattersite.com)
  * 코어 개발 : inureyes (dev at tattersite.com)
  * 플러그인 : J.Parker (plugin at tattersite.com)

3. 티켓 분야별 담당자
태터툴즈 코드 수정을 위한 티켓 등록시 티켓을 받는 분은 아래의 구분에 따라 해당되는 분께 지정하면 됩니다.

coolengineer
    * BlogAPI
    * po 관련 다국어 지원 프레임

daybreaker
    * XHTML/CSS
    * microformats/RSS/...
    * Core 버그 수정 및 기능 개선
    * DB 백엔드

graphittie
    * skin.html 하부 구조 관련(디자인 제외, 플러그인 이벤트 포함)
    * 관리자 화면 XHTML/CSS
    * 관련 버그 수정

inureyes
    * 새로운 기능 추가
    * 버그 수정

J.Parker
    * 기본 및 공개된 기타 플러그인
    * Universe/Expansion pack 관련 플러그인
    * 플러그인 업데이트 알림 플러그인
    * 기타 지원 플러그인

Louice
    * 다국어 번역 지원
    * 언어 리소스 수정

4. TNF Eventer / developer
TNF의 trac( http://dev.tattersite.com) 에서는 TNF에서 지원하는 개발 프로그램에 대한 저장소 제공 및 각종 모임과 이벤트를 티켓을 통하여 관리합니다.

4.1 developer
태터툴즈와 관련된 프로젝트를 진행하는 경우 TNF trac의 developer로 등록하여 subversion 저장소를 사용하실 수 있습니다. 등록을 위해서는 TNF 포럼을 통하여 요청하시면 해당 담당자가 처리하게 됩니다.

4.2 eventer
TNF 와 관련된 모임 및 이벤트, 프로젝트를 주관하는 역할을 하게 됩니다. 포럼에서 해당 이벤트에 대한 중지가 모이고 담당자가 정해지면 TNF trac 담당자는 해당 책임자에게 eventer 권한을 발급합니다. 해당 모임 및 이벤트 이후 해당 id 는 지속성 여부에 따라 삭제 또는 아무 권한이 없는 pool로 임시 이동됩니다.

이 문서는 2007년 2월 2일에 처음 작성되었습니다.
이 문서는 2007년 2월 5일에 최종적으로 수정되었습니다.
이 문서는 2007년 2월 9일부터 적용됩니다.
이 문서는 dev 그룹에 의하여 논의되었습니다.

회의록

참석자 : 571BO, coolengineer, daybreaker, gofeel, ikaris,  inureyes,  j.parker, LonnieNa, lunamoth,  mcfuture, papacha, 건더기, 작은인장

1. 6개월동안의 반성
예측했던 시나리오와 빗나간 부분들에 대한 반성.

2. 업무 stream 분산
현재 업무가 별형으로 구성되어 있어 모든 결정에 대한 로드가 inureyes에게 몰리고 있음. 이에 따라 최근 TNF의 프로젝트 및 커버 범위가 넓어짐에 따라 전체 의사 흐름의 속도가 느려지는 결과를 초래함. 원인의 이유로
* 각 프로젝트의 의사 흐름 과정이 체계화 또는 조직화 되어 있지 않음.
* 현재 진행중인 프로젝트 전체에 교신자로서 inureyes가 관여하고 있음.
* 늘어나는 프로젝트 수에 비하여 프로젝트의 담당자가 명확하지 않음
* 메일링리스트는 많으나 (tnf@, dev@, plugin@, skin@, i18n@, doc@) 각각의 개성이 명확하지 않음.
* 전체적인 의사 참여자의 배경이 코더로 치우쳐 있음
* 포럼, 블로그, 메일, trac등 작업 흐름에 간섭할 수 있는 부분이 순서없이 혼재하고 있음
* 코드 수정의 경우 티켓팅이 없이 수정되는 경우가 많음
* 코드 수정을 위해 접근하는 사람의 경우 초기 코드 이해에 시간이 너무 많이 걸림
* 문서화 작업이 제대로 수행되고 있지 않음
* TNF / TNC의 영역이 불명확하며, 이에 따라 외연이 희미해지는 문제가 있음
* TNF 활동 자체가 reward를 주는 환경이 되지 않고 있음. 이는 외연에 관련된 부분과 직결됨
* 의사 결정의 속도가 분야에 따라 고르게 분포되지 않음

이에따른 해결 방안으로 다음을 논의함
* 새로 시작하는 모든 프로젝트는 팀형으로 출발하며, 시작시 담당자를 명확히 함. 현재 진행중인 부분에 참여하고 있는 사람들은 집중화된 구조의 변환과 함께, 새로운 프로젝트에는 관여하지 않는 것으로 함.

* 모든 의견 처리 절차를 명확히 조정함. 모든 작업은 메일링 리스트와 티켓을 통하여 일직선상으로 진행되도록 함. 이와 같은 일원화 과정을 통하여 프로세스의 진행이 명확하도록 한다.
  + 새로운 기능 추가 및 버그 수정의 경우
    1. 포럼에서 의견을 모으거나 논의를 진행함
    2. 논의의 진행상태에 따라 해당 포럼 게시판의 모더레이터는 논의를 판단하여 해당 task를 티켓으로 등록하고, 해당 티켓으로의 링크를 포럼의 답글로 공지함. 경우에 따라 해당 글을 잠글 수도 있음.
    3. 해당 티켓이 처리되는 과정이 명확하게 티켓에 명시되도록 하며, 티켓이 완료되었을 경우 완료 상황을 포럼의 해당 글에 공지함.
    4. 개발이 완료된 상황 시점에서 해당 티켓의 처리자는 해당 기능에 대한 technical 한 설명을 doc@ 메일링으로 발송하도록 함.
    5. doc@ 메일링 관리자는 해당 문서의 사용자 버전을 처리함.
개발 과정에서 요건이 closing되는 시점과 로드맵을 명확히 할 필요성이 있다. 이러한 부분을 커버하기 위하여 TNF/TNC moderator에서 로드맵 확정 과정이 명시적으로 필요함.
  + 포럼이 아닌 개발 과정에서 버그를 수정하는 경우
    1. 수정 이전에 티켓을 반드시 등록함.
    2. 모든 commit은 해당하는 티켓이 대응 되어 있어야 함.
   + 소스코드 이외의 이벤트 진행이나 문서화의 경우
    1. 모든 TNF의 진행 과정은 무조건 trac을 거치도록 함.
    2. 과정은 '새로운 기능 추가 및 버그 수정의 경우'를 따라가도록 함.

  * 티켓처리의 분야가 명확하도록 조정할 필요가 있다. 관련하여 현재 코드 풀과 함께 어떤 분이 어떤 종류의 티켓을 받아야 하는지 명시해야 한다. (dev@에서 논의가 필요하다)

* 현재 TNF의 명문화된 부분으로는 조직 활동을 위한 많은 부분이 부족함. 강령등을 명확히 문서화 하여 외연의 고정을 꾀할 필요가 시급함. 또한 미리 정치적 중립성을 공표하여 이후 발생할 수 있는 트러블을 사전 차단할 필요성이 있다.

* 메일링리스트의 재정리가 필요하다. 각각의 메일링 리스트의 담당자를 명확히 정할 필요가 있으며, 메일링리스트의 관리자는 그 분야에 대한 최종 책임자로 활동한다. 태터툴즈 코드 티켓 처리와 관련하여 TNF/TNC의 코드 담당자들이 공유하는 dev@ 메일링 리스트 이외에는 명확한 담당자를 지정하고 해당 부분의 진행을 일임한다.
* 개발시 티켓 및 메일링 리스트를 통한 흐름은 dev@ ,plugin@, skin@ -> doc@ 의 과정으로 진행하며, 모든 진행 과정은 trac을 통하여 관리한다. 이 과정에서 문서등은 메일링 리스트를 통하여 진행됨.
* 메일링리스트 아카이브의 제공 및 메일링리스트 가입의 자율화. 이 경우 기존에 사용중이던 메일링 시스템을 버리고 googlegroups를 사용하는 방법이 있다.

* TNF와 TNC의 working field의 정의
 

* Supporters
  * 처음 시작이 '어렵지만 쉬운' 도구
  * gofeel, lonniena님 주도.

* 문서화 프로젝트 관련하여 hacking doc. 가 필요하다.
   * 기존 소스의 문서화 부분을 정리하는 방법에 대한 정의가 필요함. (RFC같은 식으로 번호를 통해 정의하는 방법이 있음)
   * 관련한 논의가 필요.

3. 향후 6개월 계획
* SNS or Publishing platform ?
* 이후의 세계와 대응에 대한 토론들.