Issues Triaging and Resolving

Issues Triaging

General issue triaging process for all repos.

Triaging Process

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.

Categorizing Issues

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

Issues Resolving

General issue resolving process for all repos.

Resolving Process

Issues that are picked up should be added to the corresponding projects, and tracked according to project setup.

feature request

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].(https://matters.news/) 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 and design labels can be added if needed.

bug

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.

enhancement

Enhancement should not have any side effects on performance or functionality.

• If the issue author 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.

community

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