... | ... | @@ -38,11 +38,11 @@ cd kea |
|
|
|
|
|
# Reviewing an issue
|
|
|
|
|
|
- as a reviewer: go to Issues->Board page. Look for an issue in review state that has no assignee. Assign to yourself. Review. Put some snarky comments. Add some more comments. Once you're done, reassign back to the developer.
|
|
|
- as a reviewer: go to Issues->Board page. Look for an issue in review state that has no assignee. Assign to yourself. Review. Put some snarky comments. Add some more comments. Once you're done, reassign back to the developer. Gitlab allows to also specify yourself as a reviewer. It's an additional step that useful for at least two reasons: later on, once the change is approved, your approval will show on the reviewers list as approved. Also, you can filter tickets by reviews, which makes easy to find tickets you reviewed. One limitation is that there can be only one reviewer specified in the free Gitlab version we're using.
|
|
|
|
|
|
- as a developer: look for issues that are assigned to you. Do your best with addressing the comments. Push your improvements to the branch. Once done reassign back to the reviewer. DO NOT MERGE until the reviewer says the code is ready.
|
|
|
|
|
|
- as a reviewer: Once all your comments are addressed, put a note that the code is ready to merge, open the MR, edit it and click on "remove the Draft/WIP prefix". Removal of the WIP status is a clear indication the code is ready to go.
|
|
|
- as a reviewer: Once all your comments are addressed, put a note that the code is ready to merge, open the MR, edit it and click on "remove the Draft/WIP prefix". Also, there's Approve button that you should click. Removal of the WIP status is a clear indication the code is ready to go.
|
|
|
|
|
|
- If you can't reach an agreement after several review rounds, you can do two things: ask for a third opinion (any developer will do) or ask the manager to solve the problem.
|
|
|
|
... | ... | |