原文·Why I gave your paper a Strong Reject [1]
作者·Matt Welsh [2]
刚刚完成了对另外一个会议投稿论文的复审，所以说，现在该是我写博客的时间了。
我慢慢的开始意识到，利用风趣的语言去教育每一个论文作者们，或者使用刻薄的语言给予一篇论文反馈意见已经不是我所期冀的事。真希望有人能够开一门“如何写一篇精妙的科学论文”的课程，并且把我的这篇文章作为课上的必读材料。但是如此的话，哎，我就要和这些被要求来读我这篇博文的可怜的人们纠缠在一起。或许从现在开始，我应该先将这篇博文附在我的所有论文反馈意见上。
今天我将说的所有内容其实早就被提及过（强烈反对）[3]，而且很有可能是我说的（勉强接受？），但我还是想分享一下几个最重要的，会使我恨不得撕碎一篇论文的原因。
（必要声明：这篇文章仅代表个人观点，不涉及公司或其他相关个人。）
差劲的摘要和前言。在读完一篇论文的摘要和前言后，我基本就可以确定将怀着怎样一种心情去继续阅读论文剩下的部分，当然我也一定不会去读一篇已经被我打上“强反对”标签的论文的剩余部分。记着我的话，我每天要读一打20到30篇的论文，所以不要期待我会在读了你糟糕的前言后，还会有心情去帮你挑论点或者数据的小错。
许多问题会出现在你的前言部分，比如到处可见的拼写错误和语法问题。（当然，在某些情况下这是可以忍受的，比如作者是非英母语地区的人。但如果这种情况下，他的文法仍然很差的话，我依然会强烈反对这篇论文，哪怕他的技术部分无懈可击。）还有一小种问题就是，缺少在摘要和前言中概括自己方法和成果的能力。别让我在深入地去读完你的文字后才可以理解你的工作内容和你的论文结果，这又不是丹布朗的小说，我不需要期待一个大反转结局。
我认为的好的论文需要一个如雄辩阐述式的前言。我在写论文的时候，往往会花费更多的时间在前两页，因为这才是一篇文章的重中之重。剩余的部分只不过是对前两页的支持罢了。
还没有定义清楚问题就阐述解决方案。 这是我个人的一大忌讳。许多论文在没有阐述清楚自己要解决什么问题的时候，就开始急于表达解决方案或者系统设计。最起码要做到的是，你要说一下自己的论文目标和受限条件。更好的改正方法就是提出一个真实的、具体的场景，并告诉我为什么现有的技术不能解决这个问题。简而言之，就是让我感受到你论文的强烈动机。
赘言实现细节，不说解决想法。许多系统领域的论文都有这个问题，浪费四到五页纸去说该系统如何实现中最无聊的部分——充盈着箭头和盒子的图，详细的API定义，该用哪个版本的python以及研究生桌子下的实验机的内存有多大。
对这种问题，我只能说：我根本就不在乎你的实现。我在乎的是你的想法是怎样的，以及这个想法是如何转化成为一个，远比你之前写的还抽象和高度概括的多的实现综述。许多人根本搞不清什么是想法，什么是作品—— 详见我之前发布过的内容. 有许多论文需要着墨于实现细节，例如一个很难的技术问题是如何被他们克服的。 但绝大多数的其他论文，实现是根本无足轻重的。所以千万别让你的论文充满这些垃圾，虽然这些内容会让你的论文看起来科技感十足。而我也知道，这几页是非常好写的，因此写多写少都不会让我对你另眼相看。
写一堆从毫无用处的文法意义上的废话。 相信我，你绝对不会让学术委员会成员们吃惊于你的：基于内容的动态可扩展帕累托最优中间层在基于云实现的传感敏感的分布式车辆中的应用。 如果你写的论文像自动生成的论文模板 ("在理论的理论大挑战是虚拟机和实时理论的重要统一。为了能网页浏览器构建何种程度上实现这一目的？"[4]), 或许你需要重新想一想该怎么去写论文了。 简练而准确得正确描述自己的想法。一个坏的想法不会因为你写得很花哨而被接受。
着眼一过于复杂的问题而创造出的工作。 许多计算机领域的研究都是先有解决方案而在之后才为它思考应用场景的。 (我也曾这样做过) 常见的情况是，当一位作者真正要开始写论文了，他才会开始为他设计的杰出解决方案想一个令人信服又十分具体的应用场景。然而审稿的人并不会被轻易愚弄。 如果把你所面对的问题稍稍简化一点，就让你的解决方案失去效果，那么你也应该去重新找一个问题来解决了。
没有描述文字的图表。 这是一个很小的问题，但往往会让我崩溃。你明白我的意思，在一个拥有多个坐标系和许多数据的图下面，图表名却只有两个字“图 3” 。审稿人需要花费很多时间去理解你画了些什么，然后才能明白哪些是这个表所提出的事实。 理想的说明文字应该是高度概况图表内容以及图中数据代表的含义的。这里的一张图来自于 我之前的某篇论文:
是不是很漂亮？即使某些粗读论文的人，他们或许并不会深入了解我的方法，但仍然可以清楚地明白这幅图表达的含义。
草率而幼稚地写相关工作部分** 相关工作部分绝对不是一个音乐单曲抢答游戏。 ("This one goes out to my main man, the one and only Docta Patterson up in Bezerkeley, what up G!")[5]。相关工作绝不单单是一串论文名，借此证明你知道这些文章。你应该详细描述他们的工作内容，并且将自己的方法与之进行对比。你绝对不能说： “文[1-36]同样与该问题相关。” 请尊重相关工作。如果你觉得他们的观点不对，说出来并解释原因。如果你赞成他们的观点，也记得向他们表达谢意和赞成。正如我博导告诉我的，站在巨人的头上，而不是脚趾头上。
[1] 文章简介：该文章来自于博客Volatile and Decentralized，刊载日：2016年4月20日。
[2] 作者简介：马特威尔士(Matt Welsh)是Google一名软件工程师，现致力于发展移动端网络性能。 他曾任哈佛大学教授。研究主要包括 分布式系统与网络.
[3] 翻译小注：由于译者初次翻译，又受困于时间。可能翻译效果差强人意，比如此处，就没办法还原作者原意，希望大家可以去看看原文，感受下作者巧思。
[4] 这一段原本就不存在意思，于是我就将原文机翻并复制过来。
[5] 我保留了这一段没有翻译，因为并没有查找到Dr. G,Patterson的相关信息，特此声明，他日如果找到一定回来补充。
