This page is aimed at members of the Mathesar team, since only they have the access to triage issues.
This guide describes how to properly triage new issues to work with Mathesar’s development process… It applies to both issues you’re creating or issues that have been created by community members.
All issues must:
New issues are automatically created with the
status: triage label and are automatically added to our GitHub project.
Any member of the Mathesar core or community team is encouraged to triage issues. If you’re making an issue, please ensure that it is triaged as well.
Each step in the triage process is detailed below.
All issues should have the following labels:
work:labels. These describe the kind of work involved in the issue (frontend, backend, documentation, design, etc.)
type:label. This describes the kind of problem that the issue is solving (bug, enhancement, etc.) This may be automatically present based on the issue template.
questionlabel for issues that are questions and not problems.
type: metaissues collect other issues and are not meant to be worked on directly.
status:label describing the current status of the issue.
There are also other labels you should consider applying:
prioritylabels for issues that are either urgent or are for future consideration.
restricted:labels for issues that are not open to the community.
work: designissues should also be marked
restricted: design teambecause only the design team can currently work on those.
good first issueand
help wantedlabels for issues that are particularly suitable for community contribution.
help wantedis applied to all issues of this type, but only apply
good first issuein addition to
help wantedif the issue is approachable for new and inexperienced contributors.
affects:labels for issues that touch technical debt, architecture, DX, or UX.
Applying the correct label should also sort the issue correctly in the Mathesar GitHub project.
The Mathesar GitHub project organizes our open issues. We need to ensure that the issue is in the project and the following fields are set correctly.
This process should be fully automated based on setting the correct labels in the previous step.
The project is only accessible to Team members, but all relevant information (such as status, priority, and milestone) should be available on individual issues. We will make this project public as soon as GitHub supports it.
All issues should have a milestone.
If an issue is directly associated with a feature, put it in the milestone for that feature. Otherwise, put it in a monthly improvement milestone (named like
YYYY-MD improvements) according to priority. More urgent issues should go in this month’s milestone, otherwise put it in a milestone in the next couple of months.
If you don’t know what milestone to put something in, talk to Kriti.
Do not create any new milestones.
Talk to Kriti.