Issues management
Issues are managed in built-in issues tracking system that uses Kanban.
Issues labels categorized and explained:
- type - each issue shall have assigned at least one label from this group:
- bug - malfunction report of the product which is unrelated to security (this is guideline to report security issues)
- enhancement - feature request for code improvement
- documentation - feature request for documentation improvement
- question - user question
- bus impact - labels group used to mark issues related to certain bus types:
- CAN - related to CAN specific implementation or characterstic
- LIN - related to CAN specific implementation or characterstic
- Ethernet - related to Ethernet specific implementation or characterstic
- FlexRay - related to FlexRay specific implementation or characterstic
- K-Line - related to K-Line specific implementation or characterstic
- closure reason - use labels from these group to mark issues that are closed without resolution:
- duplicate - another simlar issue is already created
- invalid - either not enough information is provided (even after a request for clarification) or it is classified as unrelated to this project
- wontfix - even though we accept that the issue is valid, we decide to acknowledge the risk and consciously ignore it
- others:
- dependecies - issues created by dependabot
- help wanted - use it if you are assigned to an issue, but you stack and do not know what to do next
Description is the most important part of the good issue. If we do it properly we will avoid ambiguity and unnecessary implementation.
Issue description shall contain following information:
- What features/functionalities is issue meant to provide for users?
- What existing functionalities does this change affect (e.g. Server, Client, CAN Transport Interface)?
- How would we test the change?
- What kind of dynamic tests would we perform to make sure that the change does not introduce critical bugs?
- How would we check that the feature/functionality is integrated and can be used with already existing software?
- Are there any new system tests required/desired to test this feature/functionality?
- Acceptance criteria (how do we know that the task is completed)
Tip: To make good issues, you can follow INVEST guidelines.
Each milestone is meant to describe one release. It must contain description what is the intention of the release and what value does it carry.
Development project is used to track progress and current status of the stories. On the picture below, you can see the workflow of the isssues. It is rather intuitive, but if you have any doubts, you would probably find missing information in Software Development Life Cycle article.
