그렇군요.  저도 XMLStruct을 더 자세히 읽어 보겠읍니다.

이제 대충 TatterTools 코드를 읽었읍니다. "Eolin.PHP.XMLRPC"에 chester님 말씀대로 XML-RPC가 구현되어 있더군요. 결국 Wrapper를 하나 만들어야 하네요. 무식이 박력이라고 제가 metaweblogAPI를 plugin 형태로 실현해 보려고 합니다.  한가지 확실하지 않은게 "Eolin.PHP.XMLRPC" 에서 어떻게 base64 binary 를 Encoding 하는지 잘 모르겠네요.  Moon Night 으로 하는 것이이라 시간은 장담은 못하지만 열심히 해보죠.^^

Friend -> Reporter -> Developer 라는 수직적인 모습이 아니었으면 합니다. 서로 역할이 틀린 뿐이죠.
저는 협의를 한다는 것에 대해 조금 문제가 있다고 생각합니다.
누구든 자기가 참여하고 싶은 것에  할 수 있도록 해야 한다고 생각합니다.  Buisiness 모델을 본다면 이런 식이겠죠.
Friend: User/Business Requuirements
Reporter: QA/Application/Test/Support
Developer: Programming
다만 각 영역마다 책임감있게 하실 수 있는 분들의 고유 권한이 있어야 겠죠.  예를 들면, 모든 개발자는 SandBox의 Check in/out 권한을 가지고 있지만 고유권한이 있는 분만 SandBox 에서 원본으로의 commit 권한을 갖읍니다. 말씀하신것 처럼 권력이라면 사실 Friend 그룹이 최고의 힘을 가지고 있어야 하지요. 그 그룹이 바로 customer를 대표하지 않습니까? ^^ Developer가 드라이브 한다면 배는 확실히 거꾸로 가는것 아니겠읍니까?
짧은 소견을 올려봅니다.

저의 생각을 말씀을 드리겠읍니다. 일단, document 작엄을 하실때는 가장 먼저 결정 하셔야 할 것은 target audience를 결정 하셔야 합니다.  말씀 하신대로 초보자를 위한 가이드라고 결정하셨으니 완전 초보를 위한것이 좋지 않을까 합니다. 가이드를 3개로 나누셔야 합니다. 1.설치 가이드 2. 유저 가이드 3. Technical 가이드

(1) 설치 (사용자/개발자 함께)
1. Prerequiste/Requirement (가능한 쉽게)
2. Kown issues ( release version 에 알고 있는 문제들)
3. Step By Step 설치 가이드 (DB setup, TT setup, .... )
4. 호스팅 서버에 설치하기  (태스트 통과한 호스팅 회사를 나열해 주는 것도 좋겠죠)
5. 도메인 설치
등등
 
(2) 유저 (사용자 만을 위한 가이드)
1. Step By Step사용방법 (Screen Shot은 여기에 들어 갑니다)
2. 많은 examples
사용 방법외엔 아무것도 믹스하면 안됩니다. (1 또는 3의 어디를 참조 하세요 만 가능합니다)

(3) 택크니컬 (개발자들이 많이 참여 하는 가이드)
1. Kown issues ( release version 에 알고 있는 문제들)
2. Bugs
3. Work around
4. Setup (예) mod_rewrite, My_SQL 5.0X password 문제등등 기술적인 문제들
5. Report