에고, 어지럽네요. 두세번 더 읽어야 겠습니다.

참석자 : 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 ?
* 이후의 세계와 대응에 대한 토론들.