微信号:infoqchina

介绍:有内容的技术社区媒体

【第三只眼】关于审校的那些事儿

2014-07-07 21:25 杨赛

编辑工作一直跟审校脱不开关系。加入InfoQ一年半以来,我感觉我做的最多的事情主要是编辑后勤类工作,而后勤工作的核心就是——确保内容审校工作的顺利执行。这其中有几个关键点:


1、一篇译文或原创文章完成了,如何判断谁才是最适合审校这篇内容的编辑?第一顺位人、第二顺位人和第三顺位人分别应该是谁?

2、如果每篇内容都知道该交给谁审校最合适,如何才能及时的将“有内容要审校啦”的信息及时同步给他?

3、如果审校人表示“我来审校”之后,一天两天过去了,一周两周过去了,还是没有审校该怎么办?

4、如果审校人写了一堆修改意见退回给译/作者,译/作者却迟迟不做修改该怎么办?


目前来看,我们对上述问题设置了如下规则——虽然很多是不成文的、凭感觉执行的:


1、译文审校的第一顺位人是译文完成当天主动去认领该译文审校的同学,第二顺位人是翻译团队主编(就是周三“第三只眼”专栏的值班编辑,伯薇童鞋),第三顺位人是我。原创文章审校的第一顺位人是该领域的专栏主编,第二顺位人是该领域的第二位专栏主编,以此类推。

2、没有统一的信息同步机制,看到了就吱一声,到邮件群组或者小伙伴群求助。

3、审校不通过就不发布。

4、修改版不提交就不发布。


“审校不通过就不发布”、“允许且只允许受信任的人审校”,其实是借鉴了一些开源软件社区的协作思路。比如在Linux内核社区,maintainer是由于长期积累信用而受社区信任的人,他们有权对patch进行review,只有review通过(有的项目还会在review之前先做自动测试)之后才可以被提交并merge。这样做的好处是质量控制的比较严格,一般来说maintainer为了保护自己的信用会对patch进行比较严格的把关。而且在内核社区里,稍不留神就会被Linus抓住大喷一通,非常尴尬,所以对质量把控方面要更加谨慎。


但是,这种review机制也有一个很严重的问题,那就是大量无人review的patch会被淹没在每日的讨论当中,很多可能是很好的贡献逐渐就沉下去了。在快速吸收优秀的贡献 vs 质量把控之间存在一个平衡,对于内核这种核心软件来说,倾向于质量把控的选择很有道理,尤其是现在Linux内核的应用范围如此广泛的状态下,哪怕是一次失误,都有可能造成用户以后对内核升级心生恐惧。但是对于我们InfoQ翻译团队来说,这样的牺牲就不合理了,白白让编辑们等待了很长时间,体验很差,而且新闻也失去了时效性。


上周参加微软组织的一个开源交流活动,听Open Tech的Gianugo童鞋介绍了Apache社区的运作机制,感觉Apache社区的很多做法是我们可以借鉴的。其中有两点非常好:


1、投票机制。Apache社区的投票机制用于做一些事务性的决策,比如是否要接纳一位贡献者成为新的maintainer。其投票有四个选项:


+1:表示赞同,并且会以行动支持

+0:表示赞同,但是自己不会参与

-0:表示不赞同,但是不会阻止

-1:表示不赞同,并且会想办法阻止该提议的进行


投票细致分类的好处是,如果一个提议有人投了+1,那么投票结束、提议开始进展时,发起人就可以去找到那些+1的人来寻求支持。否决方面,Apache社区实行一票否决制,所以-1也被称为“原子弹”。当然,所有投-1票的人,都被要求描述自己否决该议题的理由,否则投票会被视为无效。


目前InfoQ新编辑的升级流程就是按照类似的投票机制来做的,即由三位资深的社区编辑给新译者做review并投票,三票赞同即通过,升级后的译者再提交译文即可无需老编辑审校。当然,这个机制仍然会遇到因为编辑没时间而拖延的问题,但是因为三位老编辑都很负责,所以这个问题还不大。


2、懒惰原则(Lazy Consensus)。懒惰原则简单来说就是一个“在规定时间内没有反对意见则默认继续”的原则,在任何流程当中都可以采用。Apache社区设置的时间限制是72小时,这个期限可以照顾到全球贡献者的时间。


习惯了严格review机制的开发者对此会有一种疑问:一般来说,最难review的代码也好,文章也好,往往正是那些问题最大的。有的时候我们不返回review意见,可能有三种情况:


A)太烂了,都没法儿说了

B)感觉好像有问题,但又说不出来问题在哪儿,需要想想

C)还没看,当然没法儿返回任何意见


C的情况属于失职,是我们需要避免的。但如果是A、B的情况,则审校者会陷入一个矛盾:为了保证软件质量,所以不能让这个patch进入下一步;但是为了让自己看起来专业,也不能随便写一个否决的反馈把提交者打发回去,而是要列出详细的理由。


但反过来想,其实也挺没道理的。为什么要浪费reviewer的宝贵时间去处理那些烂patch?对于特别烂的patch,为什么不能直接喷一句“太烂”?对于感觉有问题的patch,为什么不能直接说一句“我觉得有点问题,但是也没有想得很明白。要不你再看看,大家也帮忙看看”?之前翻译团队也出现过类似的问题,比如某个译者翻译的文章总是有很多问题,审校编辑审得多了,就会下意识避开这位译者的译文,于是他的译文就一直堆在待审校区无人问津。为什么不能直接跟他说,你翻译的质量还无法达到我们的要求,练练再来?总之,有反馈总胜于没有反馈。


所以,之后计划把这两条规则也融入到InfoQ编辑团队的操作当中去,让我们的编辑团队更高效、更透明。新规则的目标是,一篇新的内容完成之后,24小时内一定要有明确的“可以发布”或者“需要修改”的一个反馈。虽然不一定能立刻说出哪些具体的地方需要修改,但总得让人明白不是?


“第三只眼”:

主要由InfoQ编辑专门为微信公众账号自编自写的一个栏目,旨在表明编辑态度及表述平日见闻和思考,期望成为和读者沟通的桥梁。亦接受投稿:spark@cn.infoq.com


今日专栏作者:

杨赛(@lazycai),InfoQ中文站编辑。到处串门的互联网信徒,相信规则的力量。


 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 Ray Wenderlich 的 Objective-C编码规范 程序员周末都喜欢做什么? 产品设计重磅经验 ▏滴滴顺风车设计案例总结 王坚数博会演讲实录:“计算经济”是社会发展的新动力 Web性能压力测试工具——Siege详解