把请求指导方针

阅读并遵循为项目提供指导方针和行为准则。下面是截图的地方找到他们第一次的贡献者和以前的贡献者。

• 让一个分支
  • 请创建一个单独的分支为每一个问题,你的工作中。不要修改默认分支(如。主,开发)你的叉子。
• 尽快把你的代码
  • 把你的代码就可以。遵循“尽早并且经常”规则。
  • 做一个拉请求你尽快和马克的标题“(在制品)”。您可以创建一个草案将请求。
    截图:如何创建起草公关?
• 描述你将请求
  • 使用指定的格式在拉请求模板库。完全填充模板为最大的冗长。
    • 标签号码代替实际的问题# (issue_number)如。# 42。当你的公关合并这关闭的问题。
    • 作者通过替换标签的实际问题@(作者)如。@issue_author。这会带来问题的记者谈话。
    • 通过添加一个标记你的任务清单x在[]如。[x]。这在你的待办事项列表检查了箱子。你检查,越多越好。
  • 详细描述您所做的更改。太多的细节比太少。
  • 描述如何测试你的变化。
  • 检查Preview选项卡来确保减价是正确地呈现,所有标签和引用有关。如果没有,回去编辑减价。
    截图:填充拉请求
• 请求审查
  • 一旦你的公关已经准备好了,去掉“(在制品)”称号和/或改变它从起草公关公关。
  • 如果一个特定的评论家不自动分配,请请求审查从项目维护人员手动和任何其他利害关系方。
• 加入反馈
  • 如果你的公关更改请求的审查,您将需要解决反馈和更新你的公关通过推动相同的分支。你不需要关闭公关并打开一个新的。
  • 一定要re-request审查一旦你改变了代码评审后,
    re-review截图:如何要求吗?
  • 要求re-review清楚地表明您处理更改请求和等待的维护者而不是相反。
    截图:差异的变化要求”和“审查所需的

代码的指导方针

• 编写综合和健壮的测试覆盖的变化你你的工作。
• 遵循适当的代码风格标准为您所使用的语言和框架(例如Python PEP 8)。
• 编写易读的代码——保持功能小,模块化和变量的描述性名称。
• 文档的代码。
• 确保所有现有的测试通过。
• 面向用户的代码应该支持以下浏览器:
  • 铬(Webkit-Blink / 22 +)
  • Firefox(壁虎/ 28 +)
  • 基于边缘(铬/ 12 +)
  • 歌剧(Chromium-Blink / 12.1 +)
  • Safari(苹果的Webkit / 7 +)
  • 即11(三叉戟)

我们的目标是评估在三个工作日内把请求。*。如果它已经在三个工作日内没有收到任何反馈,随时跟进。

*CC员工周一到周五工作,周末和国家法定假日不可用(具体假期观察随人的位置)。CC关闭之间每年圣诞前夜和新年的一天,几天后,CC全球峰会。同时,我们可用性等事件CC全球峰会期间和一年两次的员工聚会是有限的。