13 lines
2.2 KiB
Markdown
13 lines
2.2 KiB
Markdown
# Guidelines for reviewers and maintainers
|
|
|
|
Following are some guidelines for contributors who are providing reviews to the pull-requests.
|
|
|
|
1. On any given pull-request, there only one reviewer should be active at a time. Once the reviewer is done, others may add short comments or any further reviews as needed. Again, one at a time.
|
|
2. Assigning reviewers should be avoided unless the pull-request is for a particular task the reviewer is more proficient in.
|
|
3. Any contributor who has had their code merged into the repo can provide with reviews as they have gone through the repo standards at least once before. The reviewer will be on a first-come-first serve basis.
|
|
4. Most repositories have a check-list in the description for pull-requests. Many times, the contributors are not following them and simply remove the checklist or checkthem without taking the time to review the checklist items. These contributors are almost always copying the code from somewhere. These should be pointed out politely and reviews should be blocked until the contributor updates the basic code structure per the checklist and the repo standards.
|
|
5. The reviewers should label every pull-request appropriately - including "invalid" as the case may be.
|
|
6. Some pull-requests have existing duplicate code or duplicate pull-requests or sometimes, a novice might create a new pull-request for every new commit. This is a daunting task but one of the responsibility of a reviewer.
|
|
7. Discourage creating branches on the repo but rather fork the repo to the respective userspace and contribute from that fork.
|
|
8. Some repos - C & C++ - have collaboration with GitPod wherein the code and the contribution can be executed and tested online with relative simplicity. It also contains tools necessary to perform debug and CI checks without installing any tools. Encourage contributors to utilize the feature. Reviewers can test the contributed algorithms online without worrying about forks and branches.
|
|
9. There should not be any hurry to merge pull-requests. Since the repos are educational, better to get the contributions right even if it takes a bit longer to review. Encourage patience and develop debugging skills of contributors. |