Closing issues
There are two types of issues we use for development cycle: Bug
and Feature
. There are other labels for different purposes, however.
Anytime you got stuck or don’t know how something works: remember, that a documentation issue. You need to state that. Task will be reassigned to you. Documentation will be updated shortly. And you will continue to work on it once your new current task will be solved.
See what “To complete an issue” is.
How to complete a Feature
- Ask any question you have in the issue comments before starting
- Provide a simple write about how you are going to solve this issue, it might help to find wrong directions, and share ideas before writing any code. It might include a simple test to illustrate the desired functionality. Please, pay attention to this, since it may save a lot of time for both us and you
- Create a new branch named
issue-${ISSUE_NUMBER}
- Write some code to complete this task
- Write some additional tests to cover edge cases and some possible errors
- Write documentation about what have you done and why you have done it this way
- Submit a merge request
How to fix a Bug
- Ask any question you have in the issue comments before starting
- Provide a simple write about how you are going to solve this issue, it might help to find wrong directions, and share ideas before writing any code. It might include a simple test to illustrate the desired functionality. Please, pay attention to this, since it may save a lot of time for both us and you
- Create a new branch named
issue-${ISSUE_NUMBER}
- Write a test that is failing to validate that this bug exists
- If you can not recreate this bug, feel free to submit just a test with clear name and documentation linking to this issue
- If a test fails indeed, continue to the next step
- Now, when you have a regression test ready - create a fix for that bug
- Write any additional tests if needed
- Write a post-mortem entry about what was wrong
- Submit a merge request
Good read about “How to fix a bug”.
Notifications
Correct set of notifications allows users to productively work with asynchronous communication.
Lack or huge amount of notifications ruins the process. Managing them is a required skill for us.
We use /subscribe
gitlab quick action to subscribe authors of issues and merge-requests to the resource.
However, there are several things to keep in mind:
- You should enable email notifications for the project
- You can possibly enable pipeline browser notifications
- You can subscribe to related issues and merge requests
- You can use browser plugins
Do not close issues by hands
You should never close issues by hands. There’s only one way to close an issue: with a merge request. Any issue closed by anyone except the architect will be reopened.