Related issues
#1
Estimated hours: 2 hour
Description
It would be nice if the GitHub labels had a consistent color palette so it would be easier to identify issues/pull requests at a glance.
https://github.com/sudokrew/.github/labels
Issue Types
🖊 Features
Categories: Documentation
High-level documentation that has already been approved by the client to be worked on. All issues should lead back to a Feature issue.
If a Feature is open it means that there is still open work that needs to be done. A Feature may be reopened if more work is needed to be made in the future.
✍️ User Story
Categories: Documentation, Quality Assurance
A User Story contains user expectations while using the application. This could contain implementation details of a feature, edge cases that must be handled, etc. QA can reference these stories to validate that the application is behaving within the scope that we've set with the client.
A User Story is closed once it has been verified to be working as expected by QA.
☑️ Task
Categories: Actionable
A task is a general issue that means that something needs to be worked on. If a task is unassigned it either means no one has picked it up yet.
When a task is closed, it means that it is ready to be checked by QA. Tasks should always reference at least one User Story.
🐛 Bug
Categories: Quality Assurance
Bugs are for keeping track of defects that have been reported. Ideally these should only come up due to oversights in the implementation details. They should reference the related Feature and/or User Story.
Satisfactory Conditions
Related issues
#1
Estimated hours: 2 hour
Description
It would be nice if the GitHub labels had a consistent color palette so it would be easier to identify issues/pull requests at a glance.
https://github.com/sudokrew/.github/labels
Issue Types
🖊 Features
Categories: Documentation
High-level documentation that has already been approved by the client to be worked on. All issues should lead back to a Feature issue.
If a Feature is open it means that there is still open work that needs to be done. A Feature may be reopened if more work is needed to be made in the future.
✍️ User Story
Categories: Documentation, Quality Assurance
A User Story contains user expectations while using the application. This could contain implementation details of a feature, edge cases that must be handled, etc. QA can reference these stories to validate that the application is behaving within the scope that we've set with the client.
A User Story is closed once it has been verified to be working as expected by QA.
☑️ Task
Categories: Actionable
A task is a general issue that means that something needs to be worked on. If a task is unassigned it either means no one has picked it up yet.
When a task is closed, it means that it is ready to be checked by QA. Tasks should always reference at least one User Story.
🐛 Bug
Categories: Quality Assurance
Bugs are for keeping track of defects that have been reported. Ideally these should only come up due to oversights in the implementation details. They should reference the related Feature and/or User Story.
Satisfactory Conditions