这是我的提示
- 不要以请求请求开始
- 遵守项目惯例
- 假设积极的意图
- 解释为什么。不要说“应该”！
- 焦点
- 一切都有帮助
一、不要以请求请求开始
如果您要做的事情比解决错字或小小的拼写错误还要复杂，请不要从请求请求开始。
在开始进行任何工作之前，请与项目维护人员联系。
您不想花时间在不需要的东西上或已经有人在工作。您也不想构建与该项目正在进行的其他项目不匹配的解决方案。
讨论进行更改，修复错误或添加建议功能的可能方法也可能会有所帮助。您将希望充分利用自己的时间，维护人员或从事项目工作的其他人员可能会有想法和建议来帮助您。
您可以通过以下方式与适当的人员“互动”：创建问题（如果是新问题），评论问题（如果已经与您要完成的工作相关），评论讨论，留言板，电子邮件列表，聊天室或其他适合该项目的地方。
力图尝试和该项目中的其他人一样进行工作。
二、遵守项目惯例
大多数项目都包含有关如何做出贡献的文档。其中大多数包含有关不以请求请求开头的注释。但是那里还有更多。如果一个项目中有一个项目，请确保阅读了tributing.md文档，并按照那里的内容进行操作。
如果项目没有贡献指南，请询问如何参与。并且，也许也建议做出贡献的指南。
通常，如果样式，结构和约定一致，则代码更易于理解（并因此进行检查和维护）。您所做的任何事情都应该看起来像属于代码库的其余部分。
一致性也适用于文档。当文档使用不同的时态，样式，术语等时，可能会使读者分心。
在创建问题和提交请求请求时，许多项目还使用模板和清单。始终努力提供信息并完成所需的任务。
这并不是很难做到的。
三、假设积极的意图
项目要求提供信息，因为它可以帮助您。他们并不要求这很困难。
项目维护者不希望您浪费时间。另外，他们想充分利用自己的时间。他们要求提供特定信息以评估和接受更改或理解问题。他们不会这样做浪费您的时间。
这一点是双向的。
项目维护人员需要记住，当一个问题以最少的细节提出时，这并不是因为有人感到困难或懒惰。他们可能无法提供更多信息。他们甚至可能不会说相同的语言。
善待。
四、解释为什么。不要说“应该”！
如果提出问题，请说明您为什么要进行更改，或新功能将如何为您提供帮助。这可以帮助其他人理解并允许适当的优先级。
在不解释原因的情况下，切勿说“您应该让它做X”。
我确信您的意见和想法很棒，但您要做的不只是陈述它们。
这是当前引起您的问题吗？还是只是您认为会“很不错”的事情？为什么要询问或提出建议可能是必不可少的。
五、焦点
而且，如果您提出有关问题的问题或建议新功能，请为每个问题或想法创建单独的问题。
将工作分解为离散的区域可以帮助理解，确定优先级并关联变更。
当一个问题仅列出一个问题时，分类和管理工作要容易得多。
查看更改可以更正一个错误或添加一项功能，这比较容易。
当讨论保持重点时，它也很有用。
根据项目的不同，在问题或评论中进行旁讨论可能会也可能不合适。我想更多地参与几个开源项目，但是我无法过滤掉所有看似无关的讨论，因此无法跟踪所有发生的相关讨论。
遵循项目惯例中的边讨论。
六、一切都有帮助
很少有项目的成功主要由代码决定。还有许多其他因素在起作用，您也可以为这些做出贡献。
这包括编写，扩展或翻译文档。-有些项目我不需要其他人编写代码，但我可以通过编写文档做出宝贵的贡献。
测试也是如此。-在有些项目中，其他人可以付钱来编写代码，但是我可以作为外部贡献者加入，并通过创建测试来做出重要而有价值的贡献。
同样，有些项目通过提问来增加价值。
第一次使用此工具的人呢？
您考虑过X吗？
你为什么那样做？
这可以是非正式的，也可以作为代码审查的一部分。
带来不同的观点和经验有助于创造对更多人和更多人有用的东西。
一切都有帮助。
您还可以通过其他方式支持项目。有关示例，请参见https://rapidxaml.dev/support
如果您可以提供财务支持，那可能会很棒，但并非每个项目都需要它。
即使您不能提供财务捐助，也有一些方法可以支持您使用和评价的项目。
- 在GitHub上留下星星。
- 留下评论或星级。
- 通过推文，博客文章，信息流，视频或您使用的任何方式来传播单词。
对于投资于创建开源项目的人们来说，反馈确实可以令人鼓舞，并且可以提醒人们，他们的努力受到重视和赞赏。
参考： Matt Lacey