StudioEgo와 Hoyajigi가 홍대정문앞에 있는 스타벅스 홍대정문점에서 만나서 구글맵 플러그인 소스를 공부를 해보았습니다. (실은 소스보면서 머리 싸매면서 고생했음)

3시간동안 구글맵 플러그인 소스를 보면서 어떻게 돌아가는지에 대해서 이야기를 많이 해보았습니다.

소스를 보면서  한 포스트에 구글맵 2개 밖에 안들어가는 문제에 대해 궁금해하였습니다.
구글맵 설명서에도 그런 내용 없는거 같고 플러그인에서 표시 할 때도 별 문제 없는거 같은데 왜 2개밖에 안들어갈까에 대해서 생각을 많이 해보았습니다.
print_r()로 모든 변수를 다 찍어 보았는데 머리 깨지는 줄 알았습니다.

GoogleMap/index.php 에서 구글맵을 블로그에 출력을 해주는 것을 소스 분석하면서 알게 되었습니다.
그러다

function GoogleMap_View($target, $mother)

이 함수가 Google Map치환자를 블로그에 출력을 하는 것을 알게 되었죠.

한 포스트에서 구글맵을 2개까지 출력하는데에는 정상적으로 돌아가는데 한 포스트에서 구글맵을 5개이상 출력을 해보니깐 2개만 출력되는 것 같습니다.

while (preg_match('/\[##_GoogleMap\|(([^|]+)\|)?_##\]/', $target, $matches, PREG_OFFSET_CAPTURE, $offset) > 0)

에서 한 포스트에서 여러개의 구글맵을 출력한다는 것을 알게 되었지요.

소스코드만 보면 한 포스트에 여러개의 구글맵이 돌아가는 것같은데 실제로 블로그 포스트를 보면 정작 2개만 표시되고 나머지는 치환자로만 보게 됩니다.

그래서 의심되는 코드 부분을 print_r()함수로 출력해보게 되었습니다.

$target = substr_replace($target, $output, $matches[0][1], strlen($matches[0][0]));
$offset += $matches[0][1] + strlen($output);

소스코드에서 $offset 부분을 제거해 보았습니다.

$offset += $matches[0][1] + strlen($output);

이 소스코드에서 주석처리만 해보니 한 포스트에서 5개 이상의 구글 맵이 출력되는 것을 확인하게 되었습니다.

$offset 이 어디에 쓰는지 몰라서 주석처리한 것뿐인데 주석처리만 하였더니 잘 돌아갈 뿐이였습니다......

이 소스코드를 우선 commit을 하게 되긴 하였다만 $offset이 어디쓰는지 몰라서 여쭈어 보는데 어디에 쓰는 건가요?

$offset을 어디서 쓰긴 하니깐 돌아가는 것 같은데 정확한 용도를 모르겠습니다.

이것때문에 3시간동안 삽질을 해보았습니다.

오늘 짝프로그래밍을 해보면서 호야지기님이나 저나 구글맵 API나 자바스크립트 공부를 죽어라 해야할것을 심각하게 생각했습니다.
오늘 짝프로그래밍의 후기였습니다.

1
마커를 찍을 때 지역태그가
서울시>강남구
라면 강남구에 얽힌 이야기 라고 찍히는데
좌표만 있고 지역태그가 없다면
여기에 뭐가 들어가야 할까요

2
지역태그와 위경도가 둘 다 있다면 위경도를 우선으로 위경도만 지도에 찍는게 맞나요?

3
왠지 어디선가 위도와 경도가 뒤바뀐듯한 기분이 든다는...

4
vim 에서 한 줄이 길어지면 자동으로 (중간을 잘라서) 다음줄로 내리는데 (표시에서의 문제가 아니라 코드에서... wrap nowrap의 문제는 아닌듯) 우짜죠

5
그냥 단순 알림
trac에서 메일을 쏴주기 시작했어요 짝짝짝

6
아이팟터치로 블로그 접속했을때 무조건 /i 모드로 이동하는거 너무해요
그냥 모드로 강제로 들어갈 수 있는 방법을 만들어주세요 <-요건 여기에 있어야 할게 아닌듯....

7
아이팟터치 얘기 나온김에 먼훗날 얘기
/i 인터페이스에서 fireevent 없으면 만들어야 겠죠...

8
왜 한 포스트에 구글맵 2개 밖에 안 들어가요?
구글맵 설명서에도 그런 내용 없는거 같고
플러그인에서 표시 할 때도 별 문제 없는거 같은데

오늘의 활동
* 그동안 봤던 소스코드에 대한 질의 응답
* 리눅스 서버에 woc2008-googlemap 브랜치를 가져와 설치·설정하는 과정 함께 보기
* 위경도 좌표계 추가 작업 : 텍스트큐브의 자료 구조를 바꾸려면 setup.php와 interface/blog/checkup.php를 이용하며, Textcube.Data.*.php 및 interface/owner/data/import/index.php, interface/owner/data/export/index.php를 이용해 TTXML 백업·복원 루틴까지 함께 작성해야 한다. 특히 TTXML은 하위호환성·상위호환성을 모두 고려하여 작성해야 한다.
* 함께 작업한 revision : r7215 ~ r7217

다음에 할 일
* 구글맵 플러그인에서 위경도 좌표를 지역 태그와 함께 직접 글에 설정할 수 있게 한다. (위경도 좌표 자료구조 이용)
* 지역로그에서 지역태그 말고 위경도 좌표가 글에 설정되어 있다면 이것을 대신 이용하게 한다.

미팅 내용
• 프로젝트 진행하면서 할 일들 소개, 연락처 교환
• 텍스트큐브 개발센터에서 읽어볼 만한 내용들(코딩 가이드라인, 플러그인 제작 레퍼런스 등) 소개
• 자바스크립트 기초 개념 일부 소개 - 구글맵 플러그인 코드 일부 설명함, 자바스크립트 관련해서는 별도 레퍼런스 제공 예정
• dev.textcube.org 계정 생성 - 프로젝트용 branch 접근 권한 설정 및 trac reporter 권한 추가

다행히 멘티 두 분 다 기초적이나마 subversion 사용 경험을 가지고 계셨습니다. 아마 윈도 환경에서 APM 설치하는 방식으로 개발하게 될 것 같네요. 앞으로 대충 일주일에 한번 정도 미팅을 가지기로 하였습니다.

멘티분들께 드린 과제 내용
• APM 설치 등 텍스트큐브 개발환경 세팅해보기 - setup 진행시 localhost가 아닌 127.0.0.1 사용해야 쿠키 관련 문제로 로그인 안 되는 현상을 막을 수 있으니 참고. (구글 크롬은 별도의 hosts 설정해야 함)
• subversion(윈도 환경이라면 TortoiseSVN 이용)으로 구글맵 프로젝트 branch를 체크아웃하여 docs 디렉토리에 시험삼아 간단한 텍스트파일 추가해보기 (혹시 발생할지 모르는 권한 설정 오류 체크)
• 구글맵 플러그인 소스코드 읽어보기 & Javascript/PHP 공부
• 포럼 가입 안 하신 멘티 한 분은 포럼 가입

이 외에 추가적으로 이슈트래킹에 대한 개념이나 trac 사용방법 등을 익혀주시면 될 것 같습니다. 다음 번 미팅은 부트캠프 때 하는 걸로 정하였습니다. ^^

현재 작업하고 있는 부분은 설정 파일을 저장하고 불러오는 부분입니다. 일부 설정은 레지스트리에 저장하겠지만, 나머지 설정은 C:\Documents and Settings\[user profile]\Local Settings\Application data\Textcube\Notifier\ 안에 저장할 예정입니다. 크기가 큰 정보도 저장할 수 있도록 하기 위해서입니다. 파일 형식은 ini 형식으로 할지 XML 형식으로 할지 고민중입니다. 일단은 확장성이 좋은 XML 쪽으로 할 생각입니다.

그리고 UI 쪽을 개선할 계획입니다. 현재는 트레이 아이콘에서 풍선 도움말을 띄워서 새 댓글이 있다는 것을 나타내고 있습니다. 댓글은 블로그로 이동한 다음에 찾도록 되어 있습니다. 앞으로 트레이 아이콘을 더블클릭하면 댓글 내용을 간단히 볼 수 있는 화면을 나타낼 계획입니다. 한RSS 알리미 화면과 비슷한 구조를 써서 표시하려고 합니다.

결과가 나오는 대로 업데이트 하도록 하겠습니다. 좋은 의견 많이 부탁드립니다.

patchworks 프로젝트는 태터툴즈의 (현재는 위지윅) 편집기와 (현재는 TTML) 포매터를 완전히 모듈화시키고 그 바탕에 새로운 편집기·포매터 플러그인을 만들려는 프로젝트입니다. 서브버전 커밋이 계속 안 되는 고난을 겪으면서 오늘 r3035로 커밋을 했는데, 여기에 있는 내용이 상당히 많기 때문에 구체적으로 어떻게 바뀌었는지 설명하려고 글을 씁니다.

...심심하신 분께서는 1.2 브랜치 체크아웃해서 테스트해 보시고 피드백해 주셔도 됩니다.

편집기와 포매터

약간 혼란스러울 수 있는 개념인데, 편집기와 포매터는 연관은 있지만 엄연히 다른 개념입니다. 편집기는 날 텍스트로 된 걸 보기 좋게 꾸며서 편집하기 좋게 인터페이스를 제공하는 것이고, 포매터는 이런 날 텍스트를 실제로 HTML로 렌더링하는 역할을 하게 됩니다. 따라서 편집기는 사실상 자바스크립트로 구현되고 포매터는 PHP로 구현된다고 보면 됩니다. 날 텍스트의 형태는 포매터에 따라 달라질 수 있기 때문에 보통 편집기와 포매터가 함께 제공된다고 생각할 수 있겠습니다.

편집기 인터페이스

각각의 편집기는 하나의 자바스크립트 오브젝트로 구현됩니다. 이 오브젝트는 편집기에 관련된 모든 일(이벤트 처리나 포맷 변환 등등...)을 하게 되며, 여러 개의 편집기 오브젝트가 공존할 경우에도 동작하도록 구현하는 게 좋습니다. 다만 현재 구현은 속성 창 때문에 하나의 오브젝트만 활성화되도록 되어 있습니다. 이 오브젝트는 외부에 네 개의 메소드를 노출시키는데,
- editor.initialize(textarea): 주어진 textarea 엘리먼트 주변에 필요한 요소들(속성 창 등)을 추가하고 이벤트 핸들러를 설치합니다.
- editor.finalize(): editor.initialize의 반대 역할로, 추가했던 요소들과 이벤트 핸들러 등을 모두 지워서 textarea를 다시 원래대로 되돌려 놓습니다. 이 메소드는 다른 편집기를 선택할 때 현재 편집기를 비활성화시키기 위해 꼭 필요합니다.
- editor.syncTextarea(): 원래 textarea가 아닌 다른 곳(위지윅 에디터 같은 경우)에서 편집이 일어 나고 있을 때 그 변경 사항을 원래 textarea에 동기화하는 역할을 합니다. textarea를 그대로 쓴다면 아무 일도 하지 않습니다.
- edtior.addObject(data): 편집기에 data로 명시된 그림·동영상·주크박스 등을 삽입합니다. data는 {mode: 'Image1L', objects: [...]} 형태의 오브젝트로 objects 속성에는 추가되어야 할 것들의 경로와 옵션, 설명 등이 배열로 들어 있습니다. 성공하면 true를, 아니면 false를 반환합니다.

거꾸로 편집기에서는 (아마 편집기에서나 쓰일 법한) 다음과 같음 전역 함수를 사용할 수 있습니다.
- savePosition(textarea): 주어진 textarea의 현재 선택 영역을 보존합니다. insertTag와 함께 쓰입니다.
- insertTag(textarea, prefix, postfix): 주어진 textarea의 현재 선택 영역의 앞뒤에 prefix와 postfix라는 텍스트를 추가합니다.
- editorChanged(): entryManager에게 현재 편집기에 있는 내용이 바뀌었음을 알립니다. 자동 저장에 쓰입니다.

포매터 인터페이스

포매터 인터페이스는 두 개의 PHP 함수로 구현됩니다. 하나는 텍스트를 받아서 HTML로 변환하는 함수(formatfunc)이고, 또 하나는 텍스트를 받아서 RSS 등에 쓸 수 있는 짧은 요약문을 반환하는 함수(summaryfunc)입니다. 이 때 주의할 점은 summaryfunc은 전문·부분 공개 설정을 읽어서 적절히 잘라 주고 하는 역할도 갖고 있다는 것입니다. (나중에 코어가 바뀌는 것을 염두에 두고 이렇게 했습니다.) formatfunc과 summaryfunc은 같은 형태의 인자를 받는데,

function formatfunc($owner, $id, $content, $keywords = array(), $useAbsolutePath = false);
// $owner, $id: 해당 글이 어디에 속해 있는지를 보임.
// $content: 변환될 글의 내용.
// $keywords: 키워드의 목록. 배열이 아니면 키워드 기능을 무시함. (키워드가 실제로 어떻게 해석되는지는 포매터마다 다름)
// $useAbsolutePath: 참이면 URL에 절대 경로를 사용하도록 함.

여기서 텍스트를 어떻게 지지고 볶는 지는 포매터 나름입니다.

편집기·포매터 플러그인

이번 작업으로 편집기와 포매터를 위한 플러그인 XML 포맷이 새로 생겼으며, 다음과 같습니다.

<binding>
    <formatter xml:lang="ko" id="markdown" name="마크다운 포매터">
        <format>FM_Markdown_format</format>
        <summary>FM_Markdown_summary</summary>
        <usedFor editor="markdown">마크다운 마크업</usedFor>
        <usedFor editor="plain" />
    </formatter>
    <editor xml:lang="ko" id="markdown" name="마크다운 편집기">
        <initialize>FM_Markdown_editorinit</initialize>
        <usedFor formatter="markdown">마크다운 마크업</usedFor>
    </editor>
</binding>

<formatter> 및 <editor> 엘리먼트는 각 편집기·포매터를 식별하기 위한 식별자(id)를 갖습니다. 이 식별자는 꼭 필요하며, 다른 플러그인과 겹치지 않도록 적절히 잡아 주시는 게 좋습니다. (이 속성은 한 플러그인이 서로 비슷한 여러 편집기·포매터를 가질 경우를 감안하여 추가되었습니다.)

<format>, <summary>, <initialize>는 각각 HTML 변환 및 요약(포매터)과 초기화 코드(편집기)를 명시합니다. format과 summary는 앞에서 설명한 formatfunc과 summaryfunc과 같고, initialize는 해당 편집기 정보를 담은 하나의 인자를 받아서 편집기 초기화에 사용될 자바스크립트 코드를 반환합니다. initialize의 반환값은 switch문-_-에 들어 가기 때문에, 성공하면 return 문으로 해당 오브젝트를 반환하도록 하고 실패하면 break;로 빠져 나가 기본 편집기를 쓰도록 해야 합니다.

<usedFor>는 편집기와 포매터 사이의 연관 관계를 표시합니다. 예를 들어서 위의 설정에서는 "마크다운 포매터는 마크다운 편집기(markdown)와 기본 편집기(plain)에 쓰일 수 있다"는 것을 나타냅니다. 안에 텍스트 데이터가 있으면 해당 편집기-포매터 짝에 별도의 이름을 붙여 줍니다. (물론 아직 쓰이지는 않습니다만...) 편집기와 포매터가 서로를 가리키는 선언을 가지고 있어도 됩니다만, 이름이 따로 붙여져 있을 경우 둘 중 어느 게 사용될 지는 알 수 없습니다. (따라서 같은 이름을 쓸 것을 권장합니다)

아무 편집기·포매터 플러그인도 없을 때는 기본적으로 HTML 포매터(html)와 날 텍스트 편집기(plain)만이 사용됩니다. 이 포매터와 편집기는 기본적인 작업만을 수행하며, 새로운 플러그인을 만들고자 할 때 참고할 수 있고 편집기가 따로 없는 포매터를 위해서도 사용할 수 있습니다.

기타 코어 수정

- <prefix>Entries 테이블에 편집기와 포매터를 나타내는 두 개의 필드가 추가되었습니다.
- XML 백업 포맷에 편집기와 포매터 속성이 추가되었습니다. 속성이 없으면 현재 기본 설정을 사용하기 때문에 호환성은 유지됩니다.
- language/messages.php가 추가되었습니다. 이 파일은 관리자 언어 설정에 따라 자바스크립트 코드를 생성하며, PHP랑 비슷하게 _t() 함수를 구현합니다. 자바스크립트 등에서 지역화된 문자열이 필요할 때 쓸 수 있습니다. (N.B. 이 코드는 블로그 언어 설정에서도 쓸 수 있게 하는 게 좋겠지만 약간 모호한 경우가 있어서 뒤로 미룹니다.)
- 편집기에서 사용하는 자바스크립트 및 CSS 등을 추가할 수 있게 하기 위한 ShowAdminHeader 이벤트가 추가되었습니다. 각 함수는 알아서 $suri를 파싱해서 여기에 출력을 해야 하나 말아야 하나를 결정해야 합니다;
- EAF의 STD.addEventListener가 addEventListener 외에도 removeEventListener를 추가하도록 했습니다. 용도는 물론 편집기 finalize 메소드에서 쓰려고...

이상이 r3035(와 글 쓰면서 수정한-_- r3036)의 수정 목록입니다. 질문이 있거나 버그가 있거나(...없기를-_-) 심심하거나 <del>밥 뜯어내고 싶다거나</del> 하면 이 글타래에 달아 주세요.

http://freedom.laziel.com/

현재 기본 프레임워크는 구성되어 있고 (이것의 기능 개선도 필요합니다!!), 네이버, 이글루스 외의 모듈을 추가하고 해당 블로그 서비스의 업데이트에 따른 기존 모듈의 동작 오류를 함께 잡아나가실 분을 찾습니다. 동지 모집!! 참여 의사가 있으신 분은 laziel@tattertools.com 으로 이메일을 보내주세요.

태터툴즈
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 그룹에 의하여 논의되었습니다.

포럼지기는 해당 프로젝트들을 진행중이신 tokigun님과 corgan님께서 맡아주실 것입니다. 이후 프로젝트 종료 및 변경에 따라 포럼지기는 추가되거나 변경될 예정입니다.