우리도 1.1 좀 ... wink

안그래도 바쁘게들 준비 하고 계시리라 생각 됩니다. 설치 버전도 관리하고 티스토리도 나름대로 준비하시고.

**기대하고 있겠습니다**

위의 굵은 글씨는 압박, 다그침, 재촉등의 의미가 전혀 없음을 알려 드립니다.

그나저나 글도 잘 안쓰면서 이런 얘기를 하는 제가 참... 쓰다 만 글만 수두룩... (자료 편집 중 -_-)

lude 작성:

http://square.innori.com/90
플래시로 구현하는 방법이 있습니다.
하루속히 파이어폭스도 지원해주시옵소서

이런 기능이 간절하신 분들은 따로 확장기능 등으로 이용하는게 어떨가 싶습니다.

전 반대에 한 표 던집니다.

태터의 글 작성기 외의 방법으로도 글을 작성할 수 있었으면 좋겠습니다.

이를 구현한 플러그인이 있는 것으로 아는데 큰 문제가 없다면 티스토리에도 적용할 수 있었으면 하는 바램입니다.

ghost_ghost 작성:

안녕하세요 TNF에 새로 조인한 ghost_ghost 입니다. ^^

지금 티스토리쪽에 들어갈 플러그인 선별 및 검증 작업을 하고 있습니다.

현재 추천해주신 플러그인을 대상으로 하고 있고 리스트는 다음과 같습니다.

일차 검증 완료
    브레인 태그        차칸아이 님   
    리퍼러로그정리        CRIZIN 님
    Lightbox TT EX        치리 님

보류 대상
    Random Photo Viewer    JUNO 님
    Thumbnail List / RRMC Plugin J.Parket 님


미검증
    FootNote                        gofeel 님
    BlogAPI            coolengineer 님
    [태터 1.0.6?]태터 오에카키 Powring 님
    무지개 링크        JustKidding 님
    Entry Hits Plugin                    J.Parket 님
    hk_plug_v1.7        ideA Kiss 님
    CodeTagHelper        위쯔 님


선별 및 검증에 대한 기준은 다음과 같습니다.

    필수
    1. TatterTools 1.0.6 버전 기준으로 작동하는 플러그인
    2. 플러그인 이외에 TatterTools 소스 수정 여부
    3. 플러그인 내에 DB 스키마 변경 SQL문 존재 여부
    4. 플러그인 설정 여부 하드 코딩
    5. 포괄적인 버그나 적용이 불가능한 경우
   
    검토   
    6. 기타 임시 파일에 대한 생성 수정 여부 ==> 이 기준은 따로 검토 됩니다.
                7. 라이센스 제작자분들의 동의가 필요합니다. ^^

현재 보류 된 플러그인 등은 대부분 2,4번 기준에 부합되지 않아 보류된 경우입니다.
개인적으로도 참 있었으면 하는 기능 인데 아쉽습니다. ^^
제작자 분들께서 쪼금만 2,4번 부분을 수정해주시면 정말 정말 감사하겠습니다.

그럼 앞으로도 많이 플러그인 추천 올려주세요.

coolengineer님의 BlogAPI가 검증 과정이 궁금합니다. 티스토리에 추가되었으면 좋겠군요. : )

오픈오피스에서 metaweblogAPI를 이용한 블로그 확장 기능이 있어서 이를 사용해서 글을 올리려고 합니다.

5

(10 답글들, 티스토리(TiStory.com)에 작성)

gregarius.net - gregarius는 웹기반 설치형 리더입니다. GPL로 개발중입니다. 개발 버전 데모 사이트는 rss.gregarius.net에서 보실 수 있습니다.
hanrss.com - 가입형 웹기반 리더입니다.

위 두 리더가 사용해본 것 중에서 제일 나은 리더라고 생각되서 리더 부분 개발하실때 참고 하시라고 소개해 봅니다.

graphittie 작성:

아카이브는 어떻게 번역하면 좋을까요? 저장소?

지난 글? 지난 글 모음? 으음 -_-

7

(1 답글들, 아이디어 및 기능 제안에 작성)

블로그의 내용들은 상당히 다양한 주제들로 채워집니다.

일상의 짤막한 기록도 있고 토론 해볼만한 문제에 대해 적극적인 의견을 이야기하시는분 등등. 한 번 읽으면 그만인 종류의 글도 있지만 글쓴이의 글과 그 아래 달린 댓글들의 변화에 지속적으로 관심이 가는 경우도 있습니다.

태터툴즈 뿐만 아니라 다른 툴이나 블로그 서비스 사이트들을 이용해보면 후자의 경우는 좀 아쉬운 점이 있습니다.

글타래의 변화를 알아내려면 주기적인 직접 방문 외에는 별다른 방법이 없다.

같은 툴이나 서비스 사용자간에는 이런 기능이 어느정도 지원되기는 하는 것 같은데 그것만으로는 역시 부족하다는 생각이 듭니다. 저의 경우는 글쓴이의 의견에 대한 댓글을 달아둔 곳은 머리로 기억을 하거나 북마크에 잠시 임시로 등록해서 가끔 들어가보는 방식을 취하는데 이 때 제일 무서운 적은 과다한 알콜 섭취로 망가진 저의 기억력입니다. 북마크에 저장 해둬도 까맣게 잊곤 하지요. -_-

내가 할 말만 하고 그만인 경우는 괜찮지만 그에 대한 타인의 의견도 궁금할 경우 글타래의 변경사항을 추적할 수 있는 기능이 아쉬워집니다.

댓글 작성시 '이 글타래의 변경 사항 메일로 받기' 같은 선택 상자 같은 것이 있으면 어떨까 하는 생각을 합니다. RSS로 제공하는 것도 나쁘진 않은데 저는 메일쪽이 더 땡기는 군요. 메신저로도 받을 수 있으면 좋겠다는 생각도 듭니다.

기나긴 글타래에 댓글을 달 때 누구의 의견에 관련된 내용인지 표현하고 싶다

인용 기능 같은것이 있으면 좋겠다는 생각을 한 적이 많습니다. 인용 기능 이외에도 어느 정도 글을 다듬는데 도움이 될만한 기능도 필요하다는 생각입니다. 지금 태터툴즈는 댓글의 댓글(1단계)만을 지원해주는데요. 댓글의 댓글의 댓글(2단계)이 필요할 때도 있습니다. 그 이상도 그렇구요.
댓글의 댓글만을 지원해주기 보다는 인용을 지원해주고 시간의 흐름으로 표현해주는게 좋지 않을까 하는 생각이 듭니다.

지금 글을 쓰고 있는 이 PunBB의 글 작성창을 제 블로그 아래쪽에 가져다 붙였으면 하는 욕구가 생깁니다. 허허

직접적인 관련은 없지만 댓글의 수준 향상과 인터페이스의 관계에 대해 비논리적인 상상력을 발휘해 놓은 글이 있는데  참고 부탁드립니다

웹 디자인으로 댓글들의 수준이 올라갈까요? - http://mait.tistory.com/6

--

꼭 직접 블로그를 운영하지 않아도 여러 블로그나 사이트들에서 지원해주는 피드들을 이용하다 보면 이미 존재하고 있는 커뮤니티 사이트를 방문해서 이용하던 스타일에서 더 나아가 나만의 커뮤니티를 내가 직접 선택해서 만들어 가고 있구나 하는 생각이 들었습니다.

블로거들의 글을 단순히 소비하는 수준에서는 지금도 불편함이 없지만 참여해서 주고 받는 단계에서는 좀 아쉬운면이 느껴집니다.

여러 커뮤니티 사이트에서 이용하는 phpbb, punbb, vbulletin 같은 종류의 툴에서 지원되는 내용들을 응용해 보면 어떨까 하는 생각이었습니다.

lunamoth 작성:

예 동의합니다.

트랙백, 댓글, 트랙백 주소, 이름, 비밀번호, 홈페이지, 댓글 작성, 입력 정도면 충분할 것 같네요.

"우리말 어쩌고 저째기 협회인가에서 '댓글'로 통일하자고 했다더군요"

‘리플’은 ‘댓글’로

트랙백은 엮인글로 표현하면 어떨까요? 이렇게 표현된 곳을 종종 보는데 괜찮은 것 같습니다. 생판 모르는 분이 봤을때 트랙백 보다는 엮인글쪽이 더 쉽게 이해가 가지 않을까 합니다.

트랙백을 보낼 때 제 글에도 그 쪽 글을 간단하게 언급할 수 있는 - 어디어디 글과 연결되어 있다는 - 기능을 바랬는데 핑백은 한단계 더 나아간 개념인 것 같군요.

이미 구현된 곳이 많다고 하니 태터도 얼른 구현되었으면 좋겠습니다.

지금은 트랙백 보내면서 본문에 "누구님의 이런글에서 어쩌구..." 이런식으로 링크 처리만 하는데 다른 분들도 그러신가요?

inureyes 작성:

신경쓰이지 않도록 원글이 윗쪽에 출력되도록 수정되었습니다.
sandbox에 commit 되었습니다.

덧) graphittie님의 xhtml에도 구현되어 있습니다. 현재 (sandbox r116 이후) 반영되어 있습니다. smile

설치 버전은 업데이트나 관리를 제대로 할 자신이 없어서 티스토리 가입하고 블로깅 중입니다. sandbox 버전을 돌려볼 능력이 없어서 구현하신 부분을 확인 못했습니다.

원글이 윗쪽에 출력되도록만 추가하신 거라면 한가지 제안을 더 드려보고자 합니다.

이 부분의 표현을 이 포럼에 쓰이는 punbb나 phpbb 방식으로 표현하면 어떨까 하는데요.

일단 댓글이 달려있는 글 제목들이 주루룩 보여줍니다.
정렬 기준은 최근에 갱신된 즉 가장 최근에 새 댓글이 달린 글이 위로 올라옵니다.
글 제목 근처에 아직 읽지 않은 댓글부터 바로 볼 수 있는 링크도 제공합니다.

Gmail이나 phpbb, punbb 등에 쓰이는 그런 글타래 방식이 갱신되는 정보를 열람하기에 괜찮은 방법인 것 같아 건의 드려봅니다.

inureyes 작성:
monet 작성:

티스토리에서 작성한 글을 접속자가 볼 수는 있지만..
마우스 오른쪽 클릭이나 드래그해서 담아갈 수 없도록 했으면  합니다.
네이버 블로그의 경우 음악이나 사진을 담아갈 수 없고, 소스 마져도
볼 수가 없게 해 놓았더라구요.
또 제가 트랙백 기능을 잘 몰라서 그런지는 몰라도 싸이처럼 스크랩
기능(스크랩가능/불가)이 있었으면 합니다.

네이버 블로그도 맘만 먹으면 바로 소스 보이고 다 퍼갈 수 있습니다.
HTML의 구조상 막는 것은 본질적으로 불가능합니다. smile

inureyes님 말씀처럼 어느 정도 줄일수는 있을 테지만 근본적으로 퍼가는 것을 방지할 수는 없습니다. IE에는 현재 없지만 파이어폭스같은 경우는  javascript 옵션 조절에서 드래그나 우클릭 방지 기능을 막을 수 있습니다.

12

(4 답글들, 티스토리(TiStory.com)에 작성)

공개된 만큼 스팸으로 돌아온다! 라고 평소 경험하고 있었지만...

지메일 스팸 필터 믿고 공개로 질렀네요 ^^;;

헉 플래시로 구현하게 되시면 7 버전으로 가능하게 구현을 부탁드립니다 ㅜㅜ

*nix쪽은 아직 8 버전이 없습니다. Mac OS X 버전은 있는 걸 보니 곧 되긴 할 것 같지만...

안그래도 요새 동작이 안되는 플래시들을 간혹 마주쳐서 우울해집니다 ...

4월10일 이후 변경 내용이 보이지 않는 것 같습니다.

수정을 약간 한 문서가 있는데 하루 이틀 지나도 보이지가 않네요.

최근바뀐글은 위키의 생명! =3=3

img 태그의 경우에는 alt 속성은 반드시 있어야 하지만 title 속성도 적용해 줄 수 있는 것 같습니다.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Title of page</title>
</head>
<body>
This is my first homepage. <b>This text is bold</b>
<img src="razor.jpg" alt="razor" title="레이저" />
</body>
</html>

위 소스로 유효성 검사를 해보면 alt 속성의 유무로만 유효성이 결정되고 title 속성은 영향을 주지 않습니다.

파이어폭스에서는 title 속성만을 툴팁으로 보여줍니다. 익스에서는 테스트해보지 못했네요. 들은바로는 alt 속성만 있는 경우는 alt 속성을 툴팁으로 보여주고, alt, title 속성이 둘 다 있는 경우는 title 속성을 툴팁으로 보여준다고 합니다.

이미지가 링크 처리된 경우는 a 태그에 title 속성을 넣어주고 img 태그에는 alt 속성만을 넣고 링크가 아닌 이미지는 alt, title 속성을 둘 다 넣어주는 방법은 어떨까요?

접근성 가이드라인에서는 이미지를 볼 수 없는 성황을 위해 alt, longdesc 속성을 이용하는 것을 위주로 설명 되어 있는데 이미 이미지를 볼 수 있는 사용자들에게 툴팁을 제공하기 위해서 title 속성을 쓰는것도 괜찮아 보입니다.

모질라포럼의 관련 글타래를 링크해 봅니다.

img의 alt와 a의 title 중복 대책
이미지 속성표기 질문?

확인하느라 찾아본 링크들인데 img 태그에서 title 속성 사용은 언급하고 있지 않습니다.

13.8 How to specify alternate text
Short text equivalents for images ("alt-text")
Long descriptions of images

inureyes 작성:

여러 부분에서 공감합니다. 결과적으로 향하는 목표는 같지만, 방법의 차이가 있는 것 같네요.

customer와 contributor를 구분하는 것은 굉장히 미묘한 문제지만, 꼭 필요한 문제이기도 합니다.
이 포럼이 'Tatter and firends'라는 contributor들 사이의 커뮤니케이션을 위하여 만들어졌다면, customer들을 위한 메인 페이지도 따로 존재해야 할 겁니다. 서로 다른 영역의 두 그룹을 묶는다는 것은 이도저도 아닌 결과를 낳을 수 있지 않을까요?

contributor들은 태터툴즈를 사용하시는 수많은 분들 중에 그에 대한 '책임' 을 져보고 싶다고 생각하시는 분들입니다. 그에 맞는 내용들이 있고 그에 따른 의사 소통이 있어야 하지 않을까요? trac과 여기 포럼이 서로 다른 공간처럼 구분되어 보이는 것은 웹 프로그램의 기능에 따른 구성의 문제이기 때문에 이 둘을 묶어 하나로 생각하는 것이 맞을겁니다. - 둘을 적당한 틀 안에서 통합해 버리는 것도 좋을 겁니다. (trac에서 여기에서처럼 자유로운 이야기나 다양한 의견을 나누기는 힘들죠)

그렇지만 태터툴즈의 메인페이지와의 통합은... 제 생각엔 제품 공장과 설계및 서포트를 담당하는 사무실과 월마트 판매점을 통합하자는 의견처럼 생각됩니다.

먼저 포럼의 성격을 확실히 해야겠군요. smile

customer와 contributor를 구분한다는 것은 전혀 생각해보지 못했던 문제이군요.

어쨌든 이미 많은 부분 계획대로 진척을 하셨고 지금도 충분히 좋다고 생각합니다. 앞서 말씀드렸듯이 저 개인적로는 이렇게 약간 다른 영역의 사용자 그룹이 있는것이 좋기도 하구요.

소필 작성:
inureyes 작성:

구현은 간단한데... 다중사용자들 모두가 그걸 원할까요?
처음부터 아는 사람들이 모여 같이 사용하는 경우이면 몰라도, 그렇지 않으면 많이 싫어하실 것 같애요 smile

저같은경우는 친구들하고 같이 하기때문에 왠지모르게 통합 RSS가 있으면 좋겠다고 생각해봤어요 ^^;

planetplanet이라는 툴이 이런 역할을 해주긴 합니다. 일종의 메타 블로그 사이트(올블로그 같은)를 만들거나 RSS리더의 역할도 가능합니다. 급히 필요하신 상황이면 설치해보시면 어떨까 합니다. 상당한 규모의 사이트들에서 자주 쓰이는걸 봤습니다.

inureyes님의 의견 잘 읽었습니다.

Trac이나 이런 포럼류의 사용을 부담스럽게 느끼실만한 사용자층의 분들이 있다는 것은 저도 동의합니다. 포럼까지는 익숙해도 Trac에는 부담을 느끼실만한 사용자층도 존재할겁니다.

하지만 그렇다고 해서 현재처럼 물리적으로 분리된 인터페이스는 사용자층의 골을 더 깊게 만들수 있다는 생각입니다.

tatter-user, tatter-devel 식으로 메일링리스트가 분리되어 있다던지 포럼도 이와 비슷한 분류로 나눈다던지 하는것을 많이 보았습니다. 그 목적은 저도 충분히 동의합니다.
하지만 유저측에서 충분히 통합해서 볼 수 있는 메일링 리스트나 같은 포럼 인터페이스의 운영이 아닌 별개의 사이트처럼 존재하는 현재 상황에서는 사용자 계층 사이의 이동을 단절시키는 환경이 될 수 있다는 걱정입니다.

제가 올렸던 두 글의 핵심 '다른 사용자들의 대화를 보고 배운다'라는 것입니다.

솔직히 말씀드리면 전 이 포럼은 자주와도 공식 홈페이지 게시판쪽은 자주 안들릴것 같습니다. 검색하러는 갈 지 몰라도 질문을 올리거나, 답변을 달러 일부러 가지는 않을 것 같습니다.
하지만 같은 포럼상에서 운영된다면 오다가다 스치는 질문들에 제가 알고있는 해결방법이나, 부족한 정보를 가지고 있는 질문에 대한 충고같은 경우는 부담없이 적어줄 수 있습니다.

커밋 권한을 가지고 계신 개발자 분들이나 따로 모니터링을 담당하고 계신 분들께서 양쪽을 다 모니터하고 관리하실수도 있습니다. 하지만 사용자들 사이에서 해결할 수 있는 문제라면 그렇게 할 수 있는 환경을 제공하는것도 좋다고 생각합니다.

공식적인 창구는 Trac의 티켓 작성이지만, 이를 어려워 하실만한 분들은 질답게시판이나 개발 관련 게시판에 올릴 것이고 그 중간 다리는 저 같은 사용자가 될 수도 있고 개발에 직접 참여하시는 분들이 대행 할 수도 있습니다. 지금도 그런 구조로 처리하고 계시는 걸로 알고 있습니다.

공식 홈피의 질답게시판의 4가지 분류는 태터툴즈 사용에서 일어날 수 있는 문제를 다루는데 적절한 것 같습니다.

저도 제로보드 스타일의 게시판을 좋아하지 않기 때문에 이 공간이 더 좋고 편합니다. 하지만 저에게는 최악의 경우가 되겠지만 이곳이 없어지고 공식홈피쪽으로 통합한다면 이는 태터툴즈 개발에 있어서 더 도움이 된다고 생각합니다.

어떻게 해도 티켓 작성 할 분은 하고 안할분은 안할 것 입니다.

사용자층을 분리하지 말자.(분류당하고 싶지 않아요 - - 쿨럭)
저같이 한쪽만 가게 되는 사람이 양쪽 다 가는 사람보다 많으리라 생각됩니다.
서로 다른 계층의 사용자들간의 잠재적인 대화의 가능성을 조금이라도 더 열자




덧)제로보드에
기존 글타래에 새로 댓글이 달리면 첫 목록으로 올려 보여주기,
내가 작성한 글에 덧글이 달리면 메일로 통보하기,
관심있는 글타래에 새 댓글이 달리면 메일로 받기,
다양한 검색 조건 지원
RSS지원
이 기능만 있으면 포럼 시스템으로 괜찮다고 생각하는데, PunBB 스킨을 제로보드 처럼 만드는게 쉬울려나요?

덧2)국제화를 대비해 버그 관리 시스템을 두가지 언어로 분리하거나 한쪽 언어로 통합하는것은 정말 힘든 사항이겠네요.

inureyes 작성:

네. 그렇게 되고 익숙해지면 좋습니다 smile
두가지 문제라면, 사용자들이 다가올 수 있는 진입장벽이 더 높아질 수 있다는 점과, 엄격한 코드 관리가 힘들어진다는 점 입니다. 후자의 이야기는 큰 문제가 아닐 수 있으니 생략하고, 앞 이야기를 해보겠습니다.

trac을 써보셔서 아시겠지만, 컴퓨터와 친하고 trac에 어느정도 익숙한 사람들에게는 정말 편리한 도구이지만 처음 접하거나 프로그래밍이나 위키에 그다지 관심이 없으신 분들에게는 외계어의 조합에 복잡다양한 구조일 뿐입니다. 이런 상황에서 trac으로 모든 개발 관련 사항을 이전한다면, 피드백을 어느정도 포기하자는 말이 되어버립니다. 그것도 가장 중요한 end-user 층에서요.

또한 i18n에 대비하여 현재 작성되는 trac의 내용등이 영어와 한국어 양 쪽을 동시에 작성하고 있으며 (전체는 아니지만) 곧 모든 내용의 작성이 영/한 양쪽으로 작성될 것을 생각하면... 개발관련 사항이 모두 그 쪽으로 이전했을 떄의 진입장벽은 하늘을 찌르겠지요 sad

물론 ticket을 작성할 수 있는 사용자층이 넓어져야 한다는 점에는 동의합니다. 하지만 그 경우 ticket을 작성하기 힘드신 분들에게는 (그 개념이 아예 이해가 힘드신 분들도 계시죠) 일종의 간극이 생겨버린다는 점에서 아직까지 무리라고 봅니다.
(처음에 포럼형식으로 게시판 만드는 것도 다들 의견이 분분했어요 ㅠ_ㅠ 우리나라에서 포럼형식으로 게시판 열면 전문가-_-들만 글 쓸 줄 알거라구요 -o- )

태터가 computer geek들만이 아니라 모든 사람들에게 사랑받으면서 자라려면, 아직까지는 국내의 환경을 고려하지 않을 수 없을 듯 합니다. 제 입장에서야 마잇님의 말대로 되는 것이 가장 직관적이고 편하지만, 천천히 가야 하는것 아니겠습니까 smile

공식홈페이지의 게시판을 합치는 이야기는 여러가지 의견이 있을 수 있으니 다 같이 생각을 해 보았으면 합니다. 여기로 합치면 좋겠지만, 세상엔 제로보드만 게시판으로 아시는 분들이 대부분입니다...

아무리 봐도 너무 뜬금없이 의견만 적은것 같아 몇마디 더 적어 봅니다.

프로그래밍 지식이 전무한 저같은 사용자로서는 소프트웨어를 사용하다 문제에 부딪쳤을때 하는 행동은
그냥 포기하고 다른 소프트웨어를 찾아보던지,
해당 소프트웨어 홈페이지로 가서 FAQ문서나 질답게시판을 검색하거나,
직접 관련은 없지만 간접적으로라도 관련이 있는 커뮤니티에 가서 검색, 질문을 시도, - 지식인이나, KLDP... 뭐 그런곳이 있겠습니다. 저의 경우로는.

오픈소스 문화를 접하지 못했을때는 이 과정에서 해결이 되지 않으면 그냥 불편을 감수하고 사용을 하거나 포기하는 쪽이었습니다.
상용 프로그램을 불법적으로 사용하는 경우가 아니라 하더라도 개발자에게 직접 해당 문제를 메일로 보낸다는 개념이 매우 부담스럽게 느껴졌습니다.

리눅스를 사용하기 시작하면서 다양한 오픈소스 프로그램들과 접하게 되고, 메일링 리스트나 포럼을 보면서 버그 추적 시스템에 이미 보고 되어 있는 문제들에 대한 링크를 접하고 방문하게 되었습니다.
다른 사용자들이 그러한 시스템을 통해서 개발자와 대화하는 것을 보고 소프트웨어 개발이라는것이 어떻게 진행되는 것이고, 문제 해결에 어떤 정보가 필요한지, 어떤식으로 설명을 해야 좋은 결과를 얻을수 있는지, 버그 추적 시스템을 둘러보면서 어렴풋이 알게 되었습니다.

결국 저도 직접 거기에 참여해보게 되었고, 문제가 해결된 새 릴리즈를 설치하는 새로운 경험을 얻게 되었지요. 괜시리 흐믓하고 애정도 더 생기고 그렇더군요. 더 이상 문제 보고 같은 용건은 없지만 가끔 들러보게 되고 다른 사용자 보고에 해결 방법도 적어주고 그렇게 되더군요 자연스레...
좀 과장된 이야기지만, 막연한 질문만 올려놓고 누군가의 답변만 바라던 입장에서, 사소하나마 개발에 보탬이 될 수 있는 사용자로 거듭났다고 얘기해 볼 수 있겠습니다.

태터툴즈도 공개적인 라이센스와 개발 방식을 결정하신 김에 사용자과 개발자의 간격을 좁히고 좀 더 간결하고 통합적인 운영을 위해 이전에 언급한 2단계의 구성을 말씀드리게 되었습니다.

태터툴즈의 발전을 기원합니다.

inureyes 작성:
Ever_K 작성:

일단 크게 개발쪽과 고객지원쪽으로 세분화하고 해당 부분에 각 한분씩 총지휘자를 두는형식으로 진두지휘를 하게되고,

개발쪽에  플러그인,스킨 등 테터툴즈를 돌릴때 필요한 각종 개발을 담당하는 하위분야들을 두고, 사용자지원부분에 메뉴얼담당,Q&A담당,FAQ담당 등 이런식으로 빨리 세분화를 이루신후에 각 부분에 적절한 인재분을 배치하는게 좋을것같습니다.

이렇게 세분화하고 각 그룹원에게 자신이 해야될 목표를 확실히 구분지어주면 능률도 오르고 더욱 열심히하리라 생각이됩니다.

지휘자... 라기는 그렇고, chester님 의견대로 분야를 나누고 분야별로 관심있는 분들이 게시판에 모입시다. 그 후 그 카테고리 안에서 참여하시는 분들이 지휘자나 방향등을 자율적으로 결정하는 식이 나을 것 같습니다. (정 처음에 시작이 힘들다면 누구나 동의할만한 분들이 '장'을 맡아주시면 되겠죠^^) 위에서 아래로 척척척- 이 아니라 잘 안 될 것 같지만, 지금 위키 매뉴얼 채워지는 정도나 dev.tattertools.com 보시면 그렇지도 않습니다.
또한 그러한 분야의 구분이 너무 확실해서 배타성을 띄거나 하는 것도 안 좋을 것 같습니다. 일종의 명찰이라고 하는 것이 어떨까요? 모두들 관심있는 것으로 명찰을 하나씩 다는거죠. 나는 1반 너는 2반 이런 식으로요.

이상하게 들릴 수도 있지만, 속도가 전부는 아니라고 생각합니다. 완전한 세분화가 이루어질 수도 없지요. (코드 분석이 없이 플러그인 스트럭처 설명을 할 수는 없을테고, 환경 피드백 없이 디자인을 할 수도 없을테니까요 ^^; ) 주종목 명찰을 달되, 여기저기 기웃거리는 그런 즐거움도 있어야 하겠고, 별로 기여할 거리는 없지만 사람들이 좋아서 자유게시판 죽돌이가 되시는 분도 있어야 하지 않을런지요.

사람이 함께 하는 개발이 되었으면 합니다.
결국 우리가 쓰기 위해서 만드는 태터툴즈잖아요 big_smile

군대식 착착착이 아니라 느릴 것 같지만, 개인적으로는 그 과정이 가장 빨리 발전하는 방향이 되지 않을까 생각합니다. smile

이미 많은 고민과 생각으로 계획을 세우신듯 한데 너무 늦은 의견이 아닌가 걱정이 되지만 의견을 적어봅니다.

처음 dev.tattertools.com을 접속했을때 Trac 인터페이스를 보고 매우 반가웠습니다. 한손으로도 꼽아도 남을 횟수의 버그 리폿 경험을 가지고 있지만, 접해본 버그 트래킹 시스템 중에는 편리하고 간단하면서 개발 현황을 어렵지 않게 파악할 수 있었던 경험 때문이었습니다.

Trac과의 첫경험(?) 덕분이었는지 저는 공식적인 버그 트래킹 시스템에 리폿하는것에 대한 막연한 두려움?이랄까 그런것을 버리고 평소 자주 사용하던 소프트웨어의 불편했던 점과 건의사항을 개발자들에게 직접 전달하고 좋은 결과를 얻을 수 있었습니다. 새로운 릴리즈 변경사항에 비록 이름까지는 아니어도 제가 올렸던 버그 넘버가 적혀 있던걸 보고 매우 놀라운 감정을 느꼈습니다. (물론 좋은쪽입니다 ; -)

일단 가입하지 않은 상태에서는 새 티켓을 작성할 수 없는것 처럼 보여서 홈페이지의 게시판과 dev 사이트를 둘러보다가 Forum 메뉴 링크를 눈치채고 이 사이트로 들어오게 되었습니다.

제가 둘러본 바로는 사용자와의 대화창구를 3단계로 나누신 것 같습니다. 공식 홈페이지의 게시판들, 그 다음 이 포럼, 그리고 Trac.

현재 Trac은 저같은 사용자들한테는 읽기 전용으로 보입니다. 새 티켓 작성이 안되는 것 같습니다.

많은 고민과 생각으로 이런 구조을 결정하셨겠지만 저는 이 포럼과 Trac을 가능한 합쳤으면 좋겠다는 의견입니다.
공지사항, 아이디어, 플러그인, 잡담하기 포럼은 이 포럼 성격에 잘 맞는 것 같습니다.
하지만, 벌레잡기, 1.0.5개발 버전 게시판의 내용은 Trac쪽이 낫지 않을까 하는 생각입니다. 물론 그러러면 익명 사용자의 새 티켓 작성이나, 최소 제약없는 회원가입후 티겟 작성까지는 허용되어야 할 것입니다.

더 나아가 공식 홈페이지 쪽 게시판들과 이곳의 공지사항, 아이디어, 플러그인, 잡담하기와 같은 성격의 포럼을 합치는 것도 조심스레 건의를 드려봅니다.

간단히 요약하면, 제가 언급했던 3단계가 원래 의도하신 것이라면 이것을 2단계로 합치는 것이 어떨까 하는 의견이었습니다.

정작 젤 중요한 왜 그래야 하는지에 대한 의견을 못쓰겠네요. 논술세대가 아니어서 그런가 봅니다.  ;-)

어제 질문했던 사람이 오늘 답변하게 되고, 오늘 답변했던 사람이 내일 패치를 올리는 그런 환경을 만들어 나아가는데 보다 직관적이고 단순한 대화창구를 만들어 가는것이 좋다고 생각되어서 늦은감이 있지만 몇 마디 적어 보았습니다.

21

(11 답글들, 스킨 및 플러그인에 작성)

저도 한표 추가 합니다. big_smile

Perfomancing 같은 툴로 블로깅이 가능하면 좋겠습니다.

특정 블로그 서비스 사이트나 설치형 블로그 툴을 지원하는데 metaweblogAPI도 목록에 보입니다.