审稿是统计之都主站工作的一个重要组成部分，在由作者或者编辑完成基本的编辑任务之后，编辑部会邀请专业的技术相关者进行文章的审核。本指南整理了一些参考事项。

本指南区分为几个部分：内容修正与编辑、文字修正与编辑、GitHub 上的操作、进阶审读。请按需阅读。内容，文章内容的准确性和易读性是最重要的。

• 内容修正与编辑这是总纲
• 文字修正与编辑包含了一些常见的格式问题
• 审稿的Github操作

内容修正与编辑

首先是确保内容的正确性。这当然需要作者进行把关，而审稿人则是第二层把关的。统计之都涉及的，大都是统计、数学、计算机、可视化，间杂着会议记录、访谈、杂谈等，所幸的是，审稿人大多是具有类似背景。

审稿人请尽量检查确认文章内容的准确性。包括但不限于知识点、术语、程序是否能够正确运行（如果投稿本身是可重复的，审稿人不妨自己跑一次，但是这点不强求），等等。

稿件从接收到作者推送到处理完成原则上不超过三个月，进度由编辑部控制。

进阶审稿

本文之前的介绍，都限制于“术”的层次。我们希望，有志之士能把审稿的内容增加到“道”的层次。

此话何解？一次完美的审稿，我们不仅仅是修正一些笔误、修改一些文字格式，更希望能够和作者一起完善文章、提高文章内容本身的质量。没错，这过程是不是让人想起了论文提交经历……诚然，统计之都并不是严肃刊物，但是我们和作者一样，都希望展现高质量的文章给大家观赏和研究。

以《十行代码预测插旗西雅图》为例，审稿是魔王，他对整个文章做了很多讨论，可以作为进阶审稿过程的一次参考。

另外一个例子是《心理学的危机》，里面黄湘云同学对整个文章提出了很多问题和修改，这也是一个很好的示例。

文字修正与编辑

(本部分注意内容，编辑和审读都请共同关注。)

这里整理了文字内容修正的一些问题。经验之谈：这里的细节看似很多，但是，在阅读文章的同时，只要见到任何文字错误就及时修改，实际上是很容易修正好的。

大部分是格式问题。 由于投稿来源于不同的作者，作者们可能并不注意到一些符合统计之都主站的格式问题。问题整理如下：

文件位置

• 文件的位置需要注意, 一定要放在 content/post/ 下，否则是无法成功发布文章的。
• 文件名需要按照 yyyy-mm-dd-slug.md 的形式完成, 缺了任何一个都会出错。比如说：2017-07-17-cos-new-site.md。

作者信息

• 目前编辑部成员和文章作者信息存放在data/members.yaml文件下。
• 若是新作者，请小编与作者联系提供照片和个人简介。

Meta 信息

• meta_extra字段中存放着“编辑”“审稿”等信息。这些信息统一由小编整理好写上去。
• 若作者没有自己在 Github 上发送 pull request，就请小编帮忙发一下，然后再开始在线审稿。
• 没有特殊情况的话，版权声明不用写了，交给标准模板处理。转载、翻译的在原文正文前面标注好原文链接和版权情况。
• 记得去论坛发帖然后添加 `forum_id！如果是论坛内容整理的文章，直接添加上对应帖子的 id 而不用另起一个。

Markdown 格式

Markdown 本质是轻量级标记格式，在纯文本的基础上增加必要标记从而达成富文本效果。因此我们有一些规范需要遵守。作者没有注意到的，请审稿人和小编一起修正。修正原则参见编辑部投稿指南

文字格式

• 同一篇文章内，请在以下格式中二选一并且在文中保持一致：(1) 中英文之间都添加空格，英文和中文标点之间不用空格；那么 why recommend this way 呢，English 和中文之间有空格，看上去更加舒服啊！(2) 中英文之间没有空格：比如说like this挤得不要不要的。另外作者有本身偏好的话，审稿标准请和原稿保持一致。
• 大小写：iOS、JavaScript、R、Python、TensorFlow、Stack Overflow、GitHub。强迫症患者请尽情修改此类错误。

系列文章标准格式

按照不同文章类型说明注意事项。以下系列文章，均建议使用标准的格式。例外情况到时大家酌情讨论。

访谈

参考这一篇。

• 访人的介绍写在第一段，除了名字粗体之外，使用普通自然段介绍即可。不用添加”【编者按】“等多余的说明（因为访谈稿的非对话内容总是编辑添加的，总不会是受访者按吧？）为啥写在前面？因为我们要知道受访人多牛逼才有兴趣看他们的访谈啊！
• 采访的背景、环境等写在对话之前。
• 对话形式中，采访人和受访人用粗体，然后冒号，然后普通字体的对话内容。
• 对话中插入较长的编者按或者其它注释的话（超过 20 个字？），我喜欢用脚注的形式标注。目的是为了不打断整个对话流的感觉。

每周精选

参考这一篇。

• 分类作为大标题，每个条目写上第一自然段。
• 投稿人作为作者标注，而且在正文第一段写明是投稿人，而不是文内链接的作者，以免引起误会。

翻译稿、转载稿

翻译稿、转载稿其实是一样的，都是衍生自别人的作品，所以这里归为一类。

• 原文作者写在 author 字段里。
• 译者啊、编辑等的名字，都写在 meta_extra 里。
• 版权，原文链接都写在原文第一自然段的前面，使用粗体。
• 原文作者的简介也写在原文正文第一自然段的前面。

GitHub 上的操作

简单地说

说了这么多，可是到底应该如何操作？如果没有特殊情况，所有的操作都是在 GitHub 上面，所以请审读员都注册一下 GitHub 帐号。有必要的话，请找管理员获取 COS 这个组织的一些操作权限。

现在作者的投稿都在 GitHub 上提交 pull request 的形式进行。因此，审稿也在作者提交的 pull request 之下，通过评论、协助作者修改的形式进行。我们对某些词语、内容添加特定的评论后，作者修改，对 pull request 提交新的 commit，我们再读一次。如此这般，直到大家都满意之后，完成审读过程。然后管理员 merge 文章到主站，上线。

细读投稿

有两种方式可以查看提交修改的内容，其一是点击绿色的小勾勾，可以查看在网页上预先生成的测试页面，也可以尝试用这个谷歌扩展插件来打开测试页面，相信我，这个插件还算好用。

另一种方式是直接在 Files changed 的这个模块查看变化的内容，如果你看任何一行觉得有什么问题，可以直接在下面评论，这是一个很方便相互交流的方式。

基本操作

在吐槽完毕之后，需要做出一个选择：评论、要求修改、同意。具体的操作是：

点击 Files changed > Review changes > 选择内容 > Submit review

其他需要注意的地方

如果最后作者对文章做了修改， 一定要及时回来通过文章， 一篇未通过的文章是不能进行下一步的操作的。如果没有问题，请找管理员进行 merge。如此这般，主站就可以上线了！