You need to take care of when you contribution to Apache Airflow.

• hook是怎么使用的,如果初始化后存在是会继续保留的么,那对self.var赋值之后可以继续使用?这里
• test coverage是什么意思?这里
• up to 2019-01-28,CI test还是会无缘无故的报错,目前还没有人有空解决这个问题
• scheduler中也会将jar包放进解析中

• email 列表进行讨论提交vote,只有PMC成员才能在提交投票的时候选择是否(binding),社区成员只能选择(non-binding)

• 建议: 设置邮箱收件形式,以对话形式显示邮件列表
• 如果涉及较大的代码改动,应该想发邮箱给社区讨论,讨论成功后再进行代码修改
• 如果改动不大,就要先想之前的人为什么要这样写,在项目和使用者的角度考虑这个更改会带来什么样弊端影响PR-4933
• 不要改动和该jira ticket无关的内容,尽量保持修改的内容都是jira ticket中的内容,如果修改时发现了别的问题,可以新建一个jira ticket解决这个内容,或者修改jira ticket的内容对应该次内容
• 别人review了代码之后,如果有suggest可以将suggest接受,Airflow允许git push -f
• 如果Jira ticket重复了,应该使用较早之前的作为PR的依据并关掉新建的ticket(减少维护者的压力),因为别人可能一直在等到修复这个工作(或者这个feature)
• merge了PR之后,一般是committer将PR对应的jira ticket设置成解决的状态,但是如果committer忘记了设置也可以自己设置,但是一定要记得设置Fix Version fieldPR-4966
• 任何涉及代码的修改都应该创建一个jira ticket: 因为release的过程是以jira ticket为依据通过cherry-pick的方式从master中挑选出需要release的内容,如果jira中没有ticket这个修改就不会被release下一个版本中,详情可见
• 如果一个PR长期没有更新,可以通过PMC member的同意将其移交作者,通过"co-author"的形式合作完成co-author

• minor changes no need for JIRA ticket: just doc change or python docstring change
• 日志使用self.log('%s', var)而不是format或者f-string: PR-3980
• 不要使用**local()去格式化字符串,不要使用"...{var}...".format(**locals())在日志或者格式化字符串
• 不建议在constructor中写get_connection,会带来性能问题: comment-PR-4903
• 想要实现一个功能尽量使用一个方式.如果有很多不同的途径实现同一个功能可能会引起不必要的疑问: Support list tasks as upstream in chain
• 对于Fix任何代码,尽量都要增加单元测试,为了让别人重构时能够更好的测试,连log都可以增加测试
• 如果文档引用了大段代码,应该将代码放到example,然后在文档中用链接的方式引用代码
• 写代码时候要和项目尽量统一,但是不能一味和别人一样,要知道这样写的原因,看看有没有改进的空间,不然会出现类似这样的低级代码
• 函数/方法remove和deprecated的不同,remove是将函数从代码中移除,deprecated是函数还在代码中存在,但是调用的时候给使用者一个warning

• 如果ci测试中有部分package不能impoert就要看看setup.py的devel_all中是否存在,因为项目的devel_ci=devel_all先安装了包然后在测试test的代码

• 如果只是修改文档,可以在commit信息增加[ci skip]跳过CI测试,帮助ASF省钱PR-4747.但是要确保你修改的doc部分不会引起./doc/build.sh报错.否则会出现PR-4897
• ~~如果有新加的hook/operator,需要在airflow/docs/code.rst对应的位置增加说明,让API文档自动生成.~~自从PR-4788被merge之后我们就不需要对code.rst进行修改了,可以主动从python文件中解析出文档.最好也要在airflow/docs/howto中增加该hook/operator的说明
• 对于UPDATING.md的修改,只记录在## mastersection后面就行,不要写明具体的update版本,因为release是PMC/committer通过cherry-pick到release分支的.PR-4940
• 函数或者方法的docstring是通过sphinx进行渲染的,渲染的时候对docstring的缩进有要求,可是使用./docs/build.sh以及./docs/start_doc_server.sh查看文档的渲染PR-4895.如果有文档的修改都建议先在本地查看文档的渲染是否正确.运行./docs/build.sh的时候会将失败的docstring抛出,这是要记得查看
  • docstring 后面要加一行新行: You should add new line after description. Otherwise, the documentation will not generate properly
  • 参数如果要换行要空格
  • 如果docstring是一个列表的形式,如list of str,应该使用list[str]而不是list of str,因为sphinx能够渲染list[str]样式PR-4895

• 如果引用了extra package,在单元测试的时候可以使用try/except ImportError以及作用在class上的@unittest.skipIf跳过单元测试
• 增加功能或者修复bug的时候要看看是否缺少单元测试和文档,如果缺少则需要补充相应的

• airflow initdb创建connection都是假链接,尽量不要使用真实的链接避免用户因为误操作导致数据库/链接的错误,带来不必要的影响.PR-4930,PR-4895

• Operator的模板字段使用的是PR,使用[START translate_template_fields]以及[END translate_template_fields]完成文档内容的生成,而不是无用的注释
• 不要将密码或者token信息从hook或者operator传入,直接将敏感信息储存在conn_id中用作保密需求PR-4895
• 只从PR-5143之后可以直接写super().__init__(*args, **kwargs)

供应商文件夹,从别的地方copy-paste的代码,实现AIP-3的时候有讨论过,得出的结论是虽然Airflow/_vendor只是从供应商复制过来的代码,但是可以对他进行更改(因为已经不能和upstream进行简单的合并了),但是建议每次对_vendor文件夹的修改都单独一个PR,方便cherry-pick和回滚.

---