如何组织在线图书工程啄木鸟/CPyUG 几年来主持组织了不少Py技术图书的翻译/原创工程, 但是能力有限，不可能出面组织所有图书的翻译，所以有必要分享在线图书工程的组织经验了 兴趣态度决定一切! - 在线分布式团队的构成,更加要求臭味相投,最好是一个稳固的社区中的老朋友们
- 选题的有趣和有用,也是图书成功的绝对必要条件
资源图书也是工程! - 就按照软件工程的方式来组织大家都习惯且有效!
- 网络中的对应免费服务是齐全的:
- 版本控制~ code.google 等等免费工程管理服务
- 日常沟通~ groups.google 等等免费列表服务
- 知识积累~ wikidot.com 等等免费维基服务
- 实时讨论~ IRC at freenode.org 等等聊天服务
- 项目管理~ Everydo 等等免费管理服务
- 进度计划~ google.com/calendar 等等在线日历服务
技巧没有规矩不成方圆 - 定期的IRC会议非常有助于鼓励士气,協商进度,调节任务
- 一定要有热心的核心人物来協調和决定所有变更(前期应该是发起人,后期由编辑分担比较合理)
- 200页以内的小书,团队有多少人是没有关系的,因为任何偏差都可以快速修订
- 大于300页的图书,写作团队应该控制在5人以内,否则,沟通将是没有尽头的事儿了:
- 合理的团队构成:
- 2~5人的撰写成员
- 3~10 人的校对成员
- 随便多少人的关注/宣传成员
- 1~2 个稳定的跟随编辑
- 一定不要使用任何 Office 格式文档来进行交互组织!这是无法进行版本控制的二进制东西!
- 结构化文本
- 纯文本
- HTML
- TeX文本
- 等等都是可以良好的通过版本控制环境进行充分管理的格式!一定要坚持使用!
- 即使在交付前统一倒入 Word 之流来统计字数,也要坚持使用!
原则所有人知道所有事儿！ - 这是社区化分布式协同的最重要原则! 防止误会/误解/偏差,令所有人都在正确的信息基础上进行工作/思考/创新;并可以立即分享到所有人的进步!
- 但是,这也是有技巧的哪:
任何事儿,得通过恰当的渠道令所有人舒服的获得; - 类似列表这种异步信息沟通,如果不是所有人一直积累浏览邮件,将形成各种"惊奇",,,特别是列表的使用礼节没有都习惯时;
- IRC 这种实时沟通渠道,对大家的时间要求非常高,而且到点如果手头有事儿的,也不可能很好的接受讨论信息,,,
所以,就俺的体验,一定要将各种渠道合理配合使用: - 维基作为唯一的正式决议通告方式,每个方面的决议使用独立的页面进行收集,整理,形成全球唯一的URL 标识的信息节点;
- 列表作为有证据记载的讨论中心,大家可以在不同的时间分别相互理解和发表意见,最终形成决议,正式发布到维基中
- IRC/MSN/好看/主页/日历,各种灵活的信息发布渠道,作为提醒渠道,将决议维基URL 不断的通告给所有人
这样,社区事务的正式发布/变更讨论/通告传播 就有机结合起来了,,, 翻译工程体验问题:改稿改到掛 | 老貓學出版：圖書出版業, 編輯知識, 產業分析 对策: - 保證可以找到好譯者的發譯指南
- 編輯與譯者的關係
- 編譯同盟
出版出版是不比撰写轻松的复杂工程! - 国家法令法规,行业潜则,市场反应,目标人群,流行模式,排版风格... 都是出版方面的专业知识,不是软件行业行者可以轻易体悟的到的!
- 有技术背景的编辑是个宝!
- 固定的编辑是永远的朋友!
- 固定的编辑追随进行田间管理是种幸福,否则是很郁闷的事儿~你得将相同的话,不断的反复说给不同的负责编辑
- 不使用 M$ Office 的编辑在中国是神话!
教训:: - 一定要有合同，有社区背景中，出版社对署名的理解是不同的，一定要事先沟通好，否则，会有解释不清的麻烦，对社区贡献也是个隐患
- 签定合同时,一定要有法人资格的社区出面来交涉,出版社会比较重视...
流程既然是工程,就必须在组织中实行明确的流程 工程理解一切基于以下对图书工程的理解::  - 主创和校对是内容和工程的主要推动和参与者
- 读者只是推广和消费者
而且对于角色的行为,有以下认识:: - 图书撰写和翻译对于作者来说在本地永远比在线要自在:
- 可以使用任意自个儿习惯的编辑环境
- 可以运用任意方便的文本处理工具进行批量处理
- 不用担心网络掉线引起的各种内容丢失问题
- 图书评注校对和读者来说在线永远是最自在的:
Workflow基于以上分析和经验,特别推荐以下工作流程::  - 主创,通过 code.google 等有版本管理系统的平台进行协同,透过SVN 等进行内容提交:
- 这就是主要也是唯一的撰写活动,不用额外的登录什么系统,熟悉什么流程
- 唯一要熟悉的是 reST 结构化文本格式
- 可以同时使用兼容的分布式版本管理系统进行本地修订版本的追踪
- 图书是工程 協同中引发的版本冲突,必须进行显要的提示和立即解决,这是其它任何協同方式无法和版本管理方式相比的!
- 校对,通过 维基或是Issue 等提案系统,将查阅时发现的问题,记录下来,并追踪提醒作者们及时完成修订
- 读者,通过 图书编译后发布的网站进行内容查阅,就地点击相关评注点进行反馈意见
Discuss一个团队，只要公开了项目到网络中，那么就会引发一系列的关注演变，从最终效果来看，和宗教没有什么不同，如果在天朝对宗教比较敏感的话，可以替代成任何其它称谓的比如说: 0. 教宗 -> 先知 , 发起 , 悟得者 ,,,
1. 主教 -> 知行 , 起行 , 学得者 ,,,
2. 教士 -> 行知 , 随行 , 跟得者 ,,,
3. 信徒 -> 用知 , 跟从 , 信得者 ,,,
4. 围观 -> 末知 , 从众 , 候得者 ,,,
5. 骂街 -> 逆知 , 别众 , 逆得者 ,,,
6. 其它 -> 不知 , 盲众 , 未得者 ,,,
,,, 不是嘛? SphinxSphinx 是一个包含一些自定宏的 reST 编译工具集; - 和 reST 的关系就象 米粒和电脑控制电饭锅,
- 想食到粄,我们可以用任何正式整熟之,
- 所以, 编辑 reST 你可以用你习惯的任何编辑器,甚至于 M$ Word
- Sphinx 只是提供了一个一致性的可以扩展/定制/自动执行的友好的图书式内容输出管理;
图书工程,我们在 可爱的Python 过程中,使用过wiki； - 但是感觉类似 Wiki/docs.google/SOHO ... 在线类撰写平台,都不方便:
- 容易被和谐
- 编辑器功能弱
- 随时可能断网，无法自动保存
- 多人協同修订同一页面时，冲突不容易解决
... 还是按照标准的软件开发方式来组织最舒心; 用各自最高效率的编辑环境，所想即所得; 如果喜欢 WYSIWYG 的推荐使用 gpage - Project Hosting on Google Code
|
Sign in to add a comment
看到潜规则了。
又学到了新东西了。
Discuss 对宗教的评述很贴切，呵呵。