21 Star 19 Fork 22

openEuler / avocado-vt

加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
克隆/下载
PR_Review_And_Contribute_Practices.txt 4.14 KB
一键复制 编辑 原始数据 按行查看 历史
For reviewers rules:
============================================================================
1)Everyone who has experiences in the project is encouraged to review PRs.
2)Respectful, kind, patient to the coders
3)Freely deny for changes the codebase does not want/need even though perfect design/codes
4)Ask questions rather than make statements.
5)Not encourage the “Why” questions.
Good practice: e.g. Wouldn't it make more sense to
Would you like to? Could you give the reason that ...?
6)Remember to praise.
7)Remember that there is often more than one way to approach a solution.
8)Given clear and useful comments, and explain the reason why reqest change
9)In general, reviewers should favor approving a PR once it is in a state where it definitely improves the overall code health of the system being worked on,
even if the PR isn't perfect.(maintainability, readability, and understandability)
10)Share your best practice/knowledge as a mentor.
11)Cautiously regard personal preference as best practice and impose to contributors
12)Dismiss your approval if you add new comment for a PR after you already have given an approval
13)It is ok to use a 'request review' tool to ask someone to review as you like, but not a must.
14)It is ok to cancel the request review to you if you think you are not a suitable one for this PR.
15)Wait for request review for no more than 2 weeks on those PRs which have already 2 approvals
Maintainer rules:
=============================================================================
1)includes all reviewer's rules
2)Make sure all PRs submitted can be closed within 3 months
3)Generally every PR needs at least 1 maintainer’s approval and total 2 approvals before being merged.
Add request for review for more maintainers if there is a need
Add a comment to explain why a PR need the label 'request_2_maintainers'
4)Mark proper and necessary labels according to the information provided by the PR contributor
5)Closing a PR threshold:no response from contributor after 1 month, the PR will be labelled as, "No response" and after 3 months it will be closed
Contributors Rules:
============================================================================
1)[Must] Coding style compliance, for example, align with inspekt tool, pep8
2)[Must] PR commit message is meaningful. Refer to the link on how to write a good commit message
3)[Must] Travis CI pass and no conflict
4)[Must] Provide test results. If no, provide justification. Apply to any PR
One of below options should be aligned:
5)[Must] If the function defined with right docstring (description and params, and return if have)
6)[Must] If the PR depends on other PRs, please add a comment to say if your PR has a dependence in order to ensure the PR is merged after dependence PRs
7)[Must] If the API of one library is changed, ask for all test cases to be modified which invoke this library and provide test results of representative test cases.
8)[Must] If the case does some package version judgement for the new case support or compatible backwards
9)[Must] If the test code have suitable env backup and recovery steps
10)[Optional] If have the necessary and clear comments for the code explanation for steps
11)[Optional] If the case is applied to multiple arches.
12)[Optional] If have duplication, need to create new function or reuse existing library in avocado/avocado-vt
13)[Optional] If the logic are complete and no important branches which are not dealt with
14)[Optional] If the code seems clear and concise, define functions to increase the readability
15)[Optional] Use python supported library instead of shell cmd running by process.run if possible
16)[Optional] If the feature test related aspects are correct
17)[Optional] Add comments to ask questions which you do not understand
18)[Optional] Pay more attention to ‘test.fail(xxx)’ or exception raise part, such as if there is log info
19)[Optional] Reply to the comment when you have fixed the comment (see good sample in Appendix.4)
20)[Optional] Better to use @Someone to ask for review when your PR is submitted
21)[Optional] Use ‘request review’ to ask the original reviewer to request again when you finish updates
1
https://gitee.com/openeuler/avocado-vt.git
git@gitee.com:openeuler/avocado-vt.git
openeuler
avocado-vt
avocado-vt
master

搜索帮助