在为开源项目做贡献时应该避免什么

随着#HacktoberFest成为一件事，已经有一大批开发人员拼命地试图为他们最喜欢的开源项目做出贡献。不幸的是，许多这样的拉请求都是浪费时间，维护人员最终无法使用这些贡献。维护人员不想浪费时间检查糟糕的PR，贡献者也不想浪费时间编写永远不会投入生产的代码。

让我们来看看开发人员在处理开放源码项目时容易犯的一些常见陷阱。顺便说一句，我们最近对Qvault前端进行了开源，如果你想帮忙的话，不妨看看这个。

你的公关应该做一件事。小的差异降低了审查者的认知负荷，并使您的代码更容易进入主分支。如果你对一个项目中的多个问题有意见，那就打开多个公关。

在我自己的项目中，这种情况最常发生在我身上。好心的开发者打开拉流请求时有下列烦恼之一：

当您为现有项目做贡献时，请使用现有样式。在这个Pull请求的上下文中，在“制表符与空格”的辩论中，没有人会对您的偏好表示异议。

如果你跳进了Github回购网站，发现了一些你不喜欢的东西，不要立即打开拉取请求。请改为执行以下步骤：

如果有问题，请联系维护人员(只需对问题发表评论)，让他们知道您想要解决该问题，并快速概述您将如何解决该问题。

这将有助于减少基于有缺陷的前提永远不会被接受的毫无意义的公关的产生。

有些代码库有数千个未解决的问题，以Go语言项目或nocode存储库为例。没有人想要阅读您的重复问题或查看您的重复拉入请求。对于您试图解决的问题，请确保不存在未解决或已关闭的问题。

并不是每个项目都需要(或关心)提交挤压。也就是说，没有不需要压缩提交的项目。为了安全起见，就给他们一个南瓜吧。

重新措辞、文档和其他无关紧要的改变会让你看起来像这些混蛋。这个特别恶劣的示例不仅限于毫无意义的文档更改，而且实际上使文档变得更糟。