Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
175 lines (125 sloc) 8.13 KB

#summary 经验分享:"如何组织在线图书工程" #labels Phase-Support,ZoomQuiet

wiki:toc/

如何组织在线图书工程 =

啄木鸟/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. 其它 -> 不知 , 盲众 , 未得者 ,,,
 ,,,

不是嘛?

Sphinx ===

Sphinx 是一个包含一些自定宏的 reST 编译工具集;

  • 和 reST 的关系就象 米粒和电脑控制电饭锅,
  • 想食到粄,我们可以用任何正式整熟之,
  • 所以, 编辑 reST 你可以用你习惯的任何编辑器,甚至于 M$ Word
  • Sphinx 只是提供了一个一致性的可以扩展/定制/自动执行的友好的图书式内容输出管理;

图书工程,我们在 可爱的Python 过程中,使用过wiki;

  • 但是感觉类似 Wiki/docs.google/SOHO ... 在线类撰写平台,都不方便:
    • 容易被和谐
    • 编辑器功能弱
    • 随时可能断网,无法自动保存
    • 多人協同修订同一页面时,冲突不容易解决
    • ...
  • 还是按照标准的软件开发方式来组织最舒心;
  • 用各自最高效率的编辑环境,所想即所得;
  • 如果喜欢 WYSIWYG 的推荐使用 gpage - Project Hosting on Google Code
  • http://code.google.com/p/gpage/
  • 华华自个儿开发的 reST 编辑器 ;-)