다음은 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 그룹에 의하여 논의되었습니다.