45 Github 发布注意事项
45 Github 发布注意事项
原文：https://medium.com/hackernoon/45-github-issues-dos-and-donts-dfec9ab4b612
我是 Quill 的作者和核心维护者——一个功能强大的富文本编辑器，内置一个 API。
许多开源项目使用 Github Issues 作为主要的沟通媒介和任务管理工具。它的开放性和可用性是他们最大的优势之一。但是一些快速的提示会让你成为一个更负责任的参与者，尤其是在大型项目中。
报告问题
做一期开一期。
做开两期做两期。
做 不做 把“哦，顺便说一句，我注意到了另一个问题”扯到一个不相关的问题上。
把事实和观点分开，最好是事实在前，观点在后。事实包括平台细节，复制步骤，你尝试过什么。意见包括对你没有调查过的根本原因的推测。
做要具体，尤其是在繁殖步骤上。不要使用“键入一些文本”这样的指令，而是要明确具体地使用指令:“键入‘测试’”。bug 可能跟 shift 键有关，别人反复敲打 adsfasdfadsfasd 也不会重现。这不是一个理论上的现象——规格不足仍然是有效问题因不可重现而关闭的最常见原因之一。
尽可能减少你的复制步骤来证明你的问题。这使得其他人更容易帮助你，剔除往往会揭示相关的互动。
做指定平台或环境，通常是浏览器和操作系统。这比人们想象的要重要得多。
做 不做 包括你没有测试过的平台。如果只有一个受支持的平台受到影响，这就足以成为一个合法的 bug。如果其他人不能在一个你没有测试过的平台上重现，而这个平台又包含在错误报告中，那么误报只会招致解雇。
务必在干净的环境中持续重现您的问题。从一致的部分开始。
即使没有重现步骤，如果你在认真努力后仍无法识别，也要报告重复出现的问题。对于环境和上下文的足够细节，这有时是没问题的，以便其他人能够帮助填补空白。
在适当的时候，是否使用了项目符号、冒号，甚至是不完整的从句。“平台:Chrome/OSX，未在其他地方测试”传达的信息与其语法正确的对等词一样多。
花额外的时间写一个好标题。它应该简短，但具有描述性——类似于编写一个好的提交消息的方法。贡献者通常在列表视图中查看问题，其中仅显示标题，标题错误的问题将被忽略。
做尝试解决或解决问题，并提供你所尝试的细节，即使没有成功。
知道答案就做回答别人的问题。回答问题不仅仅是维护人员的特权。真诚地帮助他人是开源的意义所在！
做 不做 猜测如果你不知道某人问题的答案。信号是有用的，而不是噪音，不管它们来自何方。
如果有问题模板，请遵照执行。
请求功能
一定要具体描述你希望被添加的内容，以及它将如何解决你面临的问题。
做 而不是** 仅仅用“让 X 更好”或者“提高 X”来打开一个问题。
*是否以“因 Z 而加 Y，使 X 更好”为特征请求打开问题。*
*做提出一个 API spec，即使它有明显的缺点。这将从具体细节开始对话，并由此取得进展。*
不要将特征尺寸与项目配合混淆。先确定适合，再实施。一些拟合特征将需要很长时间来实现，因为它们很大。但是无论多么容易，都不应该实现不合适的特性。
做 而不是** 打开假想的特征请求。如果你个人不需要这个特性或者没有用例，你就没有资格推荐这个解决方案。
*2016 年是否使用反应特征，而不是注释“+1”。一大群开源维护者为此几乎愤怒退出，Github 最终构建了它。现在使用它！*
*执行关闭你不再需要的特征请求。如果其他人有同样的要求，他们可以针对他们的需求单独提出一个问题。*
拉取请求
*Do 提交一个拉取请求来解决一个问题。*
*Do 提交两个拉请求来解决两个问题。*
Do not** 在不相关的提交或拉取请求中添加微小的空格或分号变化，即使这些微小的变化是正确的。请改为发出专用的提交或拉请求。
*如果有链接，请阅读 contributing.md 指南。*
*是否提交文档或注释中的错别字修复请求。这是将您的名字添加到贡献者列表中最简单、最受欢迎的方式。*
做 不做** 提交大额突击拉单请求。首先讨论它的必要性和你的方法的优点，可能是在 Github 问题或项目讨论论坛或邮件列表中。
当你忽略了上述内容，而你的“拉”请求被关闭时，不要感到惊讶或沮丧，要做。**
*Do***not期待所有拉取请求导致被合并。**
做 **不要 指望别人通过你的拉式请求来指导你。当时间允许时，它会发生，但是期待它是被误导的权利。如果你遇到困难，选择一种更简单的方式来做贡献。**
在你的拉取请求中包含测试。
如果有风格指南，请务必遵守。如果没有，请使用现有的代码库作为指南。
做 **不做 把实施成本和维护成本混为一谈。后者要昂贵得多，健康的项目需要认真考虑长期因素。**
做一个正派的人
搜索现有问题，看看你的问题是否已经被报告。它甚至可能已经解决了！
是否将其他问题标记为重复。有时很难在 Github 问题中找到正确的搜索词，尽管初衷是好的，但还是会出现重复。
务必保持评论简短、简洁且切中主题。高信息密度对于在开放源代码的分布式和多样化环境中进行有效的通信是必不可少的。
请务必阅读文档。没有人想在糟糕的一天展示自己丑陋的一面。也称为 RTFM。
如果你为一家拥有烦人的法律部门的大公司工作，并且在没有私人帮助的情况下会放弃使用项目，请给维护者发电子邮件。
不要给维护人员发电子邮件来引起他们对你报告的问题的注意。
是否享有由许可保证的“免费……无限制，包括但不限于使用、复制、修改、合并、出版、分发、再许可和/或销售软件副本的权利……”的许可开源软件的好处。
*Do *not 忽略全部大写部分:“软件“按原样”提供，没有任何形式的担保，无论是明示还是暗示……”开源在很大程度上是志愿者的努力。志愿者提供的任何额外帮助都是额外的。
对他人话语的理解要宽容。例如，合理的解释“你不明白什么？”包括居高临下的侮辱或匆忙的澄清尝试。但最仁慈的解释是，这是一个开放式的邀请，成为用于改进文档的数据点。随着全球多元化的个性和文化参与开源，以及书面文本的低情感密度，总是默认为对他人话语的最慈善的解释。
我错过了你的哪些该做和不该做的事？在评论或者推文中告诉我 @jhchen ！
本帖原载于 大卫·沃什 。感谢@ avital Oliver，@ Shapiro，@ timabbott审阅本帖草稿。
黑客中午是黑客如何开始他们的下午。我们是 @AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面 , 喜欢/在脸书给我们发消息，或者简单地，发推文/DM @HackerNoon。