2015年8月10日,星期一

纸质评论与代码评论

因为我正在经历 NIPS 现在的提交过程,与 ICLR 提交过程很重要。 NIPS 提交过程是一种更为传统的过程,在该过程中,首先将(匿名)提交发送给(匿名)审稿人,后者提供反馈,然后作者就有机会对反馈进行回应。 ICLR 提交过程更加流畅:将非匿名提交发送给匿名评论者,后者提供反馈,然后作者和评论者进入一个周期,在此周期中,作者更新arxiv提交,评论者提供进一步的反馈。 (ICLR也有公开评论,但我不再赘述)。注意,在传统模型中,审阅者必须想象最终版本中我(承诺的)更改将是什么样子。

传统模型是从一个时代开始的,即纸张是实际的物理对象,该对象是通过蜗牛发送(通过蜗牛邮件!)发送给审阅者的,这些审阅者使用墨水笔为它们标记,希望技术的进步使我们能够开发出更有效的过程。我认为我们应该寻求软件工程的启发。作为研究人员和软件工程师,我非常感谢 外骨骼机器人 区别。在这种情况下,科学的外骨骼姿态使其适用于纸质评论的弹道概念,其中已完成或已拒绝的工作单元;工程更多是关于协作持续改进。确实,大多数期刊和一些会议采用了更加灵活的审查流程,“conditional accepts”(更改需要重新审核)和“shepherds”(致力于通过多轮审阅指导论文的审阅者)。这些过程给审阅者带来了更多负担,审阅者正在提供有价值的服务来帮助某人改进他们的工作,而无需给予任何补偿或认可。自然而然地,会议可能会犹豫不决,要求其志愿者审阅者对此提出要求。

解决方案是减轻各方认知和后勤负担的技术。代码审查与书面审查具有相同的广泛目标:通过同行反馈提高质量。我们可以从代码审查中学到一些东西:
  1. 增量审查。很少有程序员从头开发复杂的软件。大多数评论是关于大型软件的相对较小的更改。为了减轻审阅者的认知负担,将审阅更改,而不是整个新版本。可视化技术用于提高变更审核的生产率。
    1. 在这方面,论文的最初提交与典型的代码审阅是不同的,但是随后的修订周期与此非常吻合。
  2. 模块化更新。当程序员对一个软件进行几项不同的更改时,这些更改(在可能的范围内)被设计为可互换和独立审查。技术用于促进变化(被接受的子集)的组合。
    1. 这与审核过程非常吻合,因为不同的审核者的反馈类似于 问题 .
  3. 最小的清洁变化。聪明的程序员将使他们的更改在审查中最为清晰。这意味着很少“easy”诸如避免在语义上等效的词汇变化之类的事情。这也意味着清理程序的控制流与创建较大的更改之间存在紧张关系。

加上保留所有相关方匿名性的能力,您将拥有一个非常漂亮的论文评审平台,该平台可以合理地加快所有科学领域的步伐,同时提高质量。

这正是政府应资助的公共物品。学术界有人:写一份赠款!

没意见:

发表评论