1.0.5 배포 이후, 여러 분이 예상하시는 일들을 처리하느라 포럼에 자주 들리지 못해 죄송합니다.
1.0.6 및 개발 센터와 관련하여 몇 가지 말씀을 드리고 의견을 듣고자 합니다. 내일 오픈 모임에서 협의하셔도 될 것 같습니다.
아래 사항에 대한 반영은 별도로 공지 드리겠습니다.

1. sandbox 위치 조정
   sandbox의 repository 위치를 http://dev.tattertools.com/sandbox/trunk 에서 http://dev.tattertools.com/svn/sandbox 로 변경하고자 합니다.
   이를 통해 trunk와 마찬가지로 sandbox에 대한 변경 사항과 소스 등을 http://dev.tattertools.com의 trac을 통해 편리하게 살펴보실 수 있게 됩니다.

2. 개발 센터 reporter 추가
   이전에 말씀드린대로 일본어 지원에 많은 기여하고 계시는 Nazu NT님이 개발 센터 reporter로 등록되실 것입니다.
   앞으로도 많은 분들이 reporter 또는 developer로 등록되시길 희망합니다.
   이에 포럼과 다국어 처리, 플러그인에 많은 참여를 하고 계신 Remengen님, Louice P.님, KIM님, J. Parker님, JCrew님을 reporter로 초대하여 더욱 풍성한 태터툴즈를 기대하고자 합니다. 동의하시는 댓글을 여기에 달아주십시오.
   개발 센터 reporter로 추천하고 싶은 분이 계시면 알려 주십시오. 개발 센터 reporter가 되기 위해서는 TnF의 멤버로서 포럼에 참여하시는 분이여야 합니다. 또한 reporter는 개발자분들뿐만 아니라 다국어 처리, 개발 관련 문서화, 버그 확인 및 등록 등, 개발 센터에 참여하실 수 있는 분이시면 누구나 가능합니다.

3. 1.0.6 주요 작업
   이전에 말씀드린대로, 1.0.6은 1.0.5 이후 버그 패치와 더불어 다음 작업이 주로 처리될 것입니다.
   * 블로그 API 지원
   * Collective Anti-Spam
   * Plugin API - 사용자 설정 기능 제공
   * 위지윅 에디터 폰트 설정 i18n
   * 설정 관련 스키마 정리

4. 1.0.6 일정 조정
   1.0.6 배포 일정은 기 발표된 것보다 3주 정도 연기하여 조정하고자 합니다.
   또한 1.0.5 진행 경험을 토대로 베타 테스팅에 대한 기간 확대와 세분화가 필요한 것 같습니다.
   아래 5번의 1.0.6 포함 여부가 결정되는 되는 대로 조정된 일정을 말씀드리겠습니다.

5. 1.0.6에 Multi-user Multi-blog 지원 여부
   이에 대한 용어를 정리하면
    * Single-blog: 오직 한 블로그를 제공
    * One-user One-blog: 한 사용자가 한 블로그를 갖고, 여러 블로그를 제공
    * One-user Multi-blog: 한 사용자가 여러 블로그를 갖을 수 있고, 여러 블로그를 제공
    * Multi-user One-blog: 한 블로그를 여러 사용자가 갖을 수 있고, 여러 블로그를 제공
    * Multi-user Multi-blog: 한 사용자가 여러 블로그를 갖을 수 있고, 한 블로그를 여러 사용자가 갖을 수 있고, 여러 블로그를 제공
   0.9x는 Single-blog이며, 지금 1.0은 One-user One-blog입니다.
   위 목록의 순서는 현재 1.0의 스키마와 코어 구조를 기준으로 구현 난이도가 낮은 순입니다.
   Multi-user One-blog부터는 스키마와 코어 구조를 많이 변경해야 합니다.
   여러 분이 생각하시기에 1.0.6의 주요 작업이 매우 중요하지 않다면 1.0.6에서 Multi-user Multi-blog 지원을 고려하는 것이 가능합니다. 예상하는 작업 기간은 1개월입니다.
   이에 대한 의견을 주시거나 내일 오픈 모임에서 협의해 주셨으면 합니다.

6. 개발 센터 ticketing에 대한 절차
   개발 센터에 등록되는 ticket은 버그(defect), 기능개선(enhancement) 등으로 구분되어 있습니다.
   일반적으로 이러한 ticket 등록은 포럼에서 충분히 확인되었거나 협의된 것에 한하여 등록되어야 합니다.
   이렇게 확인되거나 협의된 내용이 ticket에 충분히 포함되어 있어야 합니다.

7. ticket 처리
   ticket에 대한 해결(구현, 버그 패치)을 svn에 commit하실 경우, ticket별로 나눠서 하셔야 합니다. 일반적인 순서는
     1. 버그 또는 기능 개선에 대한 협의를 포럼에서 진행한다.
     2. 버그에 대한 확인이나 기능 개선에 대한 방향이 정해지면 ticket으로 등록한다.
     3. trunk 또는 sandbox에 구현한다.
     4. 구현 중에 발생하는 문제나 협의 사항, 결정 사항 등을 포럼에 개진하여 의견을 교환하거나 해당 ticket에 comment로 기술한다.
     5. trunk 또는 sandbox에 commit하고, commit message에 해당되는 티켓 번호(예: #94)와 변경 사항에 대한 요약을 기술한다.
     6. trunk에 commit된 경우, ticket에 comment로 해당되는 svn changeset(예: [150])을 추가하고 해결되었으며 fixed로 변경하여 ticket을 closing한다.
        sandbox에 commit된 경우, ticket에 comment로 해당되는 svn changeset(예: [150])을 추가하고 해결되었으며 trunk 반영 담당자인 cement에 assign한다.
        (cement가 sandbox의 changeset을 확인하여 trunk에 반영하고 ticket을 closing 해 드릴 것입니다.)