**作为社区的贡献者/成员,请记住,您随时可以开放有关适度和问题的问题,以及社区适度化的问题. **
合作者的责任作为管理团队的一员30秒的代码
- **,您有以下责任: **成为问题追踪器中对话的一部分.
- **包括(但不限于)帮助新成员,讨论新功能和向人们解释决策. **审查拉请求.
- **你不需要通读所有的请求并且重新审查它们,但是每天花时间去检查一些请求可以帮助你很多. **保持文明和礼貌.
- **如果您即将发脾气,请退后一步,做其他事情. **我们希望我们与社区的互动有礼貌,以便更多的人可以加入项目并以任何可能的方式提供帮助.
- **这样我们可以奖励和鼓励人们继续成为社区的一部分. 当你想要的时候贡献,当你可以的时候适度. **如果你在这个项目之外有很多东西,那就没事了.
- **最好休息几天,而不是匆忙地处理问题,并拉扯可能破坏事物的请求. **合并请求和改变项目的准则
- 通常的准则应用.
- **确保像其他人一样跟随他们. **对于要求合并的拉动请求,应至少有2个(最好是3个)审核批准合并.
- **但是,有一些例外: **如果拉请求只能修复拼写错误
- ,没有必要等待第二个评论者(除非你不确定这些不是第一位的错别字). 如果拉取请求仅澄清摘录的描述或强制执行现有摘录的样式指南,您可能可以将其合并,而不需要第二个审阅者对其进行审阅,但前提是您确定了这一点.
- 确保拉请求通过travis ci构建,否则试着找出什么是错的,并通知作者的拉动请求.
- 修改脚本,指导方针和可能破坏我们现有流程的事情需要经过审查@chalarangelo
- **(这是暂时的,但是我们需要一个基线来确保在开始时我们尽可能少的事情). 在合并请求之后,请确保检查未标记的代码段并对其进行适当标记. 尝试保留所有代码段标记,以便列表和网站是最新的. 如果您对现有代码段进行了更改或添加,或者如果您想添加自己的代码段,那么您将会经历其他所有人的请求过程. 异常类似地适用于上面提到的关于合并拉取请求(即错字,描述说明以及处理脚本和构建过程变化的方式). 合作者建议的拉取请求应由至少两个其他合作者审查,以便被视为可以合并. 拉一个星期内不活动的请求应该关闭或暂停. **