The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
这是一份关于开源软件开发的常规礼仪规则的简短清单。实际上，这些规则在其他地方也适用，但在进行GitHub编码时最为显眼。我坚信，早晚所有编程都会成为开源，并且这些规则将适用于每个人。因此，现在就开始遵循它们是有意义的，无论你是积极的Apache贡献者还是《Java入门》书的快乐拥有者。
没有特定的顺序：
进行小型拉取请求。来自Google和苏黎世大学的Caitlin Sadowski等人的最新研究表明，变更的大小与评审质量之间存在很强的相关性：较大的变更（拉取请求）会对质量产生负面影响。根据这篇文章，Google的开发人员强烈鼓励进行小型的渐进式变更。除了Google，许多其他人也明确表示了相同的观点：Microsoft、Zalando、Atlassian和OpenSource.com。
不要合并变更。将所有想要进行的更改放入一个单一的拉取请求中，以便更快地合并它们，只进行一次评审，可能会让你产生合并冲突。不要这样做。这只会使流程更加复杂，并且会惹恼你的评审人员。规则很简单：一个变更 = 一个拉取请求。
在文档中使用优雅的Markdown。我没有找到任何关于此的科学研究，也许因为它是显而易见的：文本“为什么 f 是 nil？”比“为什么f是nil？”更容易阅读。富文本格式不仅使文本更美观，还有助于读者更快、更愉快地消化内容。在学习Markdown之后，我建议阅读Aaron Stannard在PetaBridge上的博文：如何专业使用GitHub。
称呼对方。无论何时，在评论（无论是在拉取请求还是问题中）时，始终以GitHub昵称作为你要交流的人的开头。如果不这样做，消息将无法到达对方的收件箱，并且很可能会丢失。在GitHub上活跃的人每天会收到来自GitHub的数百封电子邮件：他们不会阅读它们。他们只会阅读进入他们的”通知”中的内容。
说”请”、”谢谢”和”对不起”。根据教皇方济各的说法，成功的秘诀在于说三个简单的词。他并不是指开源开发者，但这个建议完全适用于我们程序员。有很多关于在线礼仪的文章，它们基本上都是一样的：礼貌地提问，心存感激，并准备承认错误。我推荐阅读GitHub高级产品经理Ben Balter的GitHub沟通规则。
提醒他们。当你对分支进行一些更改并希望再次审查你的拉取请求时：发布一条明确要求评审人员重新审查的消息。当你提交拉取请求时，发布一条消息，将其定向到项目的架构师：要求他们审查PR。等等。不要期望他们会关注你的活动。他们还有其他事情要做。提醒他们是你的责任。
进行描述性提交。Git提交消息的格式化风格在每个项目中通常都是非常具体的。然而，有一些相似之处和共同规则。我推荐阅读以下博文：Chris Beams的如何编写Git提交消息，Jeremy Gunter的关于提交礼仪的一些建议，以及Tim Pope的关于Git提交消息的说明。此外，还可以参考以下内容：conventionalcommits.org和50/72格式。
拥有一个头像。来自康涅狄格大学的Kristine L. Nowak等人的一项研究表明，拥有头像的用户，尤其是女性和拟人化的头像，比那些没有个人资料图片（或使用GitHub提供的默认图片）的用户更容易引起注意。当然，仅头像并不足够；你的GitHub个人资料还必须具备许多其他内容：描述、电子邮件、固定仓库等。使用这个个人资料作为例子：@m0nica。
保持在线。线下沟通比在线票务便宜得多：只需在办公室大声提问，就能立即得到答案。无需编写那些冗长的票务，用英语表达问题，等待指派者发布答案等。然而，离线交谈对项目有害，原因很多。每当你从GitHub问题转到Slack聊天来讨论问题时，都是对项目及其所有参与者的不利。请记住这一点。
友好地进行报告。与Git提交一样，错误报告规则因项目而异，但基本原则保持不变。只需在Google中搜索”如何撰写错误报告“，听听那些博主们说的话。你的错误报告比你的代码更能展示你是谁。你可以通过向Stack Overflow提交问题来进行练习：那里的社区会因你的所有错误而对你进行惩罚，迅速培养你的报告能力。
制作优雅的README。我之前写过这个问题：在开源项目中，一个完美编写和格式化的README文件的重要性很难被过分强调。编写好的代码很重要，但将其呈现出来也是在线礼仪的一部分：高质量的文档意味着对你的产品用户的尊重。
以上就是全部内容。如果你能做到这些，你将向其他开发者展示尊重，他们也将尊重你。我是否遗漏了重要的任何事情？
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 21:46
