There is currently no way to highlight issues that should be fixed with high priority.
- We have a common
buglabel for Parse Server issues.
- We have an additional
unbreak nowlabel in other repos (Parse Android SDK) for critical bugs.
- We have a distinct process to expedite security issues, no applicable to non-security bugs.
Issue 6728 breaks the Instagram auth adapter due to API endpoint deprecation. It already generates duplicate entries. This issue has the potential to impact production systems. The deprecation of the API endpoint has been published in 2018 and several times since then until being disabled on June 29, 2020.
- Define a uniform set of Github issue labels across all repos, with maybe minor modification for special repos like
- Introduce bug severity levels in Github issue labels to increase awareness for important issues, expedite fixing these issues and merging associated PRs.
- Introduce a guideline for team members on when to apply which priority level to prevent inflationary prioritization.
(The following part is continuously updated to show the latest consensus)
Uniform Github issue labels
1. Initial status
- no label (issue has not yet been look at by a Parse team member)
- needs more info (more info is needed to classify the issue)
2. Issue classifiers:
- bug (impairs a documented feature or a functionality that is not explicitly documented but one would strongly expect the general user to infer from a documented feature)
- feature (a new feature that does not exist yet)
- enhancement (performance improvement or functional enhancement of existing feature)
- question (not an issue but a question; should be in Community Forum but we can’t easily transfer, so we refer the author to the Community Forum)
- troubleshooting (not an issue but asking a code-level question; should be in StackOverflow; for simple issues we may give a quick tip / solution to the author, in general we refer to StackOverflow to educate the author about where to post code-level questions)
- meta (issues regarding CI and tests or pinned calls for high visibility like “maintainers wanted”; other meta discussions are preferably held in the Community Forum)
2.1 Augmenting labels for
- S1 (catastrophic - blocks development/testing, may impact more than 25% of users, causes data loss, no workaround available, potential chemspill although we forward the issue into our distinct process for security related issues if found to be so)
- S2 (serious - major functionality / product severely impaired and a satisfactory workaround doesn’t exist)
- S3 (normal - blocks non-critical functionality and a work around exists)
- S4 (small / trivial - minor significance, cosmetic issues, low or no impact to users
2.2 Augmenting labels for any classifier
- duplicate (duplicate of already reported issue; references and closes the issue to encourage discussion in one place)
- documentation (requires a change in the docs; since docs tend to be neglected, an distinct label could bring more attention to keeping the docs updated)
- up for grabs (a bug, enhancement or feature that is not in the works; once a feature is being actively worked on, it is expected to infer that from the comments and the label can be removed; the label will be reapplied after prolonged time of inactivity)
- on hold (the issue cannot be resolved anytime soon because it depends on a 3rd party or another issue that needs to be resolved first)
- won’t fix (the issue won’t be fixed, e.g. due to low priority)
Remove all other existing labels (non exhaustive list)
- discussion, because every thread is essentially a discussion and every discussion is either regarding a bug, an enhancement, a feature or a question.
- in the works, because we can never be sure whether a feature is still actively being worked on and we rather have more people looking at an open issue than less (see “up for grabs” label); the current status of an issue should be inferred from the last comments, not from a label that is likely to be outdated.
- good first issue, because it seems to be rare that someone picks up an issue just to make a PR; more often an issue is picked up because someone faces the same roadblock.
- long term, because it is unclear what it means; fixing a bug is long-term when no-one is working on it; other issues that currently use that label are not parse server issues and would be better placed in the community forum; if an issue cannot be solved because of an external dependency then a distinct “on hold” label makes it more clear.
- needs investigation, because an issue usually needs investigation and it is a temporary label that needs to be removed at some point anyway.
- pr submitted, because a PR is referenced in the thread anyway and a submitted PR doesn’t say anything about it’s viability or readiness for merge (sometimes PRs are submitted even before opening an issue and asking for community feedback).
- Bug severity (S1-S4) can only be assigned by a “triage team” to ensure proper classification of and attention to critical issues.
- A bot requires an issue to be classified (as bug, enhancement, feature, etc) after n days of being opened, to mitigate the risk of missing a critical bug.
- A bot requires an issue that is classified as bug to have a severity level assigned by the triage team within n days, to mitigate the risk of missing a critical bug.
- A bot that adds the “up for grabs” to “feature” / “enhancement” after n days of inactivity.
- Issue transfers between repos team members who have write access to the target repo, otherwise by asking
@parse-community/core-maintainersin the comments.
- Adding, editing, deleting labels is restricted by guideline (cannot be restricted by repo permission)