-
Notifications
You must be signed in to change notification settings - Fork 0
Bug Reporting
This page provides information about Github Issues and Bug Reporting.
- Author: Rachael Daly <rld5989@rit.edu>
Whenever a developer comes across something that is wrong, needs to be changed, or they are otherwise confused about they can create an issue to discuss it and perhaps remedy it. Here are the requirements for creating a github issue.
The title must properly describe the issue at hand. For example, if after a sprint merge logging in no longer works an appropriate title would be "Login not functioning after sprint# merge".
The description should encompass exactly what is wrong with the code, if it is a bug it must include step-by-step instructions on how to recreate the bug. If it is an enhancement request it should describe exactly what you want within the enhancement.
Every issue should have at least one label. Here are descriptions of what would go under the most common labels.
Something is broken or not working properly as according to the documentation.
The code is working as intended but additional functionality or improved organization is requested.
The code is working as intended but something is not returning or sending in the desired format or follows the proper user interaction flow.
Every issue needs to be addressed and therefore assigned to someone. The person assigned to the issue is in charge of keeping track of the issue's progress.
If there is an issue that is found in Person B's area of expertise and Person C finds it and assigns it to Person A (who works in a similar area to Person B), it is then the responsibility of Person A. Person A can assign the bug to Person B once they add a comment within the issue describing why they are reassigning Person B to the issue and @'ing that person.
Another scenario is that the issue falls into Person A and Person B's area and either one of them is able to solve the issue. In this instance since only one person can be assigned, assigning either Person A or Person B would be correct. It would then be up to whoever it is assigned to to make sure that the issue is eventually addressed. They can reassign the issue to the other if it is decided that the issue will be worked on that sprint and the specific person that will be working on it. Reassignment must be documented in comments on the issue. In this way issues will always have someone looking at them, even if that person is not necessarily the one who will fix the issue.
Comments can come from anyone on the team to address the issue. Planned fixes from the assignee must also be put into comments and any additional problems encountered. Related Pull Requests should have their number commented in the issue along with the issue itself being attached to the PR.
An issue can be closed once the fix is merged into a top level sprint branch or master. Once the merge is complete the issue can be closed with a comment relating to the PR or if already present, simply closed.
Stakeholders can report an issue via the google forms.
Then the issue must be migrated by the developers to the github issues with above steps, while also referencing the form itself.
- Requirements Gathering
- Templates
- Functional Requirements
- Non-Functional Requirements