Currently when creating issues we add the tags like ‘bug’, ‘enhancement’ ‘documentation’ Additionally we have ‘Aggregation service’ and ‘Update Service’. The current tags are listed at (https://github.com/ODIM-Project/ODIM/labels). We will drop using these are adopt the tags listed below. Going forward we will attach three types of tags to every issue in github namely:
- Issue type
- Issue priority and
- Issue status
Issue type buckets the issue as one of bug, feature, tech debt and question. Details are provided below
1. 'issue type' group
- type:bug
The issue is created to id, track and fix a bug identified in the system
- type:feature
This issue type is created for adding a new feature(enhancement) to the system
- type:techdebt
This will implement tech debt items like architecture or code clean up.
- Type:question
This is a query from a user and needs an answer. We don’t need to implement any changes. However it may trigger implementation via a new issue.
2. 'issue priority' group
- prio:low
- prio:normal
- prio:high
This is to help prioritise work. Issues with prio:high take precedence over prio:normal. prio:normal issues take priority over prio:low. A lower priority issue may be taken up if a higher priority issue is either blocked or deferred.
3. 'issue status' group
These labels describe an issue's state in a defined workflow. A new issue will have tag status:new. The dev team will change tag to status:confirmed if we are OK to pick up the change soon, status:deferred if we OK are to pick this issue but at a later date or status:rejected if we will not take this up or disapprove of this request.
- status:new
This is the status set by requestor initially.
- status:confirmed
The issue is accepted and implementation will be taken up at the earliest subject to priorities
- status:deferred
The issue is accepted however implementation will wait as it is deferred to a future date.
- status:in-progress
The issue has been accepted previously and now taken up for implementation
- status:incomplete
The issue has been in progress but not completed due to technical reasons. The implementation could be marked as incomplete because
- newer findings require more work that needs to done to fix the issue completely or
- the issue priority has been downgraded and implementation has to be deferred.
- status:rejected
The issue is rejected and will not be implemented
- status:resolved
The issue is completed and confirmed to be working as expected.
issue states status:rejected or status:resolved will be end states of all issues.