-
Notifications
You must be signed in to change notification settings - Fork 8
Issues Triaging and Resolving
General issue triaging process for all repos.
Issues should be labeled as soon as possible, displaying issue category and whether more information is needed. Issues verified and prioritized by product manager will be included in one of the projects.
The following labels categorize basic types of issues. See next section for the resolving process.
Type | Description |
---|---|
question |
general questions, can be closed if answered or documentation added |
bug |
the implementation of a feature is not correct |
feature request |
request for a new feature |
enhancement |
improving existing functionalities or performances |
community |
issues related to our community rules or collaboration processes |
The following labels are also used to provide additional classification.
Type | Description |
---|---|
needs more info |
not possible to assign a type label due to missing information |
design |
design needed or design related issue |
under discussion |
not decided whether the issue is a bug or feature |
documentation |
documentation needed |
help wanted |
worth implementing but not picked up by core team due to bandwidth etc. |
good first issues |
issues easy to pickup for a first time contributor |
General issue resolving process for all repos.
Issues that are picked up should be added to the corresponding projects, and tracked according to project setup.
Feature requests needs to be reviewed by product manager.
- If the feature is already under design and development, product manager should share the related documents, and add the issue to a project for tracking.
- If the feature is against general design principal or product direction, product manager should explain the rationale and close the issue.
- If the feature is not against principals but not yet discussed, the issue author should discuss the feature on Matters first. If there are contributors willing to take on design and development, or general support for this feature, product manager should prioritize accordingly.
help wanted
anddesign
labels can be added if needed.
Bugs should have descriptions on how to reproduce, otherwise should be labeled as needs more info
. If a bug can be verified:
- If it is a serious bug, it should be added to the project for bug tracking.
- If it is not a serious bug and exceeds the current bandwidth of Matters team, it should be labeled as
help wanted
. - If it requires a simple fix, it should also be labeled
good first issues
for first time contributors. - If the issue author or other contributors submitted a corresponding Pull Request, review of the Pull Request should be prioritized by development team.
Enhancement should not have any side effects on performance or functionality.
- If the issue author or other contributors submitted a corresponding Pull Request, review of the Pull Request should be prioritized by development team.
- If the issue author does not have a corresponding Pull Request, development team should evaluate it similar with other development task. If the enhancement is desirable but exceeds current bandwidth, it should be labeled as
help wanted
.
Change of community rules needs decision from product manager. If consensus is reached, it should be labeled documentation
and closed after documentation added.
- If the rules does not involve decisions on new features, then it should be reviewed by development team and product manager, and discussions can take place on GitHub.
- If the rules involve decisions on new features, then it should be reviewed by community content team and product manager, and discussion should be moved to Matters