Currently when creating issues we add the tags like ‘bug’, ‘enhancement’ ‘documentation’ Additionally we have ‘Aggregation service’ and ‘Update Service’. 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 (https://github.com/ODIM-Project/ODIM/labels) 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.