使用GitHub问题
开始研究一个问题
- 给自己分配任务，这样每个人都能清楚地知道你在处理这个问题。它还可以帮助你跟踪当前的工作。
- 如果你因为某种原因停止了这个问题的工作，你不会继续在这个问题上工作，然后取消分配自己，留下任何有用的信息，最好是你为什么停止工作。
- 仔细阅读问题描述(最好读两遍)，并确保您完全理解问题。如果有什么不清楚的地方，在问题中发表评论并询问更多信息。
- 如果问题有点大，或者有很多方法可以解决这个问题(从用户体验或代码的角度)，但不清楚哪一种方法是最好的评论，并在评论中提到这一点，并寻求其他人的反馈。如果不容易的话，和别人打电话也会有帮助，因为有时和另一个人谈论一些事情和讨论一些事情可以帮助把事情弄得更清楚。
- 当处理一个可能需要超过4天时间的问题时，因为这是一些复杂的重构或工作，那么最好先写一些概念，并在进行任何工作之前仔细检查概念是否是一个好想法。
- 我们在GitHub上发表的任何评论都是公开的，会影响我们的形象等。不只是对这个用户，而是对每一个随着时间的推移会阅读这条评论的其他用户。
- 每一条评论都有可能把用户变成粉丝
- 我们可能已经回复了数千次，然后很容易就某件事快速询问或评论，但请记住，这可能是第一次对另一个人制造问题。这个问题对他们来说可能非常重要，他们可能花了一些时间来创造这个问题，一个好的回应将对他们产生影响。很难总是把以下的事情都包括在内，但我们尽了最大的努力，因为它甚至不需要我们花费更多的时间来添加一些额外的问候、感激、同情等等。
- 理想情况下，当我们第一次评论一个问题时，我们会以“嗨，@用户名”或“谢谢@用户名”这样的开头。
- 当用户创建功能请求或错误报告时，我们感谢他们花时间创建这个问题。
- 示例:感谢创建问题@username。非常感激。我刚刚安装了Windows，并且能够复制它……
- 当它是一个错误，我们可以复制它，理想情况下，我们承认这个问题，甚至可以说“对不起”或“一定很痛苦”或类似的合适的地方。
- 例子:嗨@用户名对此感到抱歉。我会尽我最大的努力，希望我们能把事情处理好，为你工作。
- 如果我们可能不会很快解决这个问题，我们可以邀请具有技术知识的用户创建一个拉请求。
- 如果一个问题实际上是一个问题，我们会关闭这个问题，并很好地引用论坛，因为GitHub回购不是一个提问的地方。
- 如果我们能邀请用户合作，那也总是很棒的
- 例如:现有的WP-Matomo将很快被稍微重命名为WP-Matomo Integration (WP-Piwik)，我们也将试图进一步减少那里的混乱。如果您对命名有任何想法或想法，以及如何更好地区分它们，请告诉我们。非常感谢您的反馈。
- 有时，当我们认为问题已经解决或问题已经解决时，我们会尝试结束问题。但我们提到，我们总是乐于重新讨论这个问题。
- 例如:……回答……我现在就结束这期。如果这没有帮助，或者如果我理解了错误的地方，请随时发表评论，我们很乐意重新讨论这个问题并进一步调查。
- 如果我们帮助了他们，我们也可以这样说:“太棒了，我很高兴它现在为你工作了。”
- 如果我们觉得我们回答了一个问题，一个FAQ可以防止同样的问题再次被问到(或者下次有人问这个问题时，我们可以简单地发送那个链接)，那么我们的目标是写一个FAQ。
- 回复时记得
- 保持礼貌和尊重。
- 承认对方已经投入的时间。
- 承认你要求对方额外投资的时间。
- 要心存感激。
- 专注于工作。
协作式软件开发是一个固有的社会过程，人类有一种自然的倾向，可以互换地对待贡献和贡献者。这是不言而喻的，但重要的是要保持对工作本身的关注，特别是在提供关键反馈的时候。
