Harmonize GitHub labels and usage

[Manuel]

The proposal has been adopted.

Next steps:
Update Parse Server repository labels
[] Update stale bot for new labels (after 6 months without stale bot, it seems actually beneficial to not add it; to give more control over closing of issues)
Classify severity of all existing bugs (triage team)
Set up bots for automated labelling
Collect feedback and improve
Update other repositories

I will go ahead and begin by updating the Parse Server repository labels in the coming days as a model for the other repositories. @Tom if I may I will approach you for guidance with your Github expertise.

[Manuel]

Potential future improvements to discuss:

• Remove label “troubleshooting”:

  • It actually covers a subset of what can be covered by the more general label “question”.
  • It does not seem necessary nor does it seem to provide any practical benefit to distinguish between general questions and code-level questions.

• Remove label “up for grabs”:

  • Given the amount of “feature” and “enhancement” issues without recent activity, the “up for grabs” label would be applied to the vast amount of these issues, to the point where it may loose its significance.

• Add label “Next release”:

  • There may be PRs that need to be merged before a new release, e.g. bug fixes or other important changes.

[Manuel]

@Manuel

Bug severity (S1-S4) can only be assigned by a triage team to ensure proper classification of and attention to critical issues. This triage team will be formed from the core team members. The purpose of restricting severity classification is to prevent inflationary severity use and ensure timely detection of critical issues.

To tackle the task of classifying the issues, my suggestion is:

1. set up a GitHub Action that runs when the label bug is applied to an issue
2. action assigns the issue to all core team members (or 2 distinct core team members per repo?)
3. core team member classifies the bug and removes the issue assignment

We are not really using issue assignments on GitHub currently, nor have we specified what it means procedurally. This could be a use case. I think that 1 core team member is sufficient for classification.

Maybe the process can be improved, I am not keen on the core team members having to manually un-assign. Any suggestions?

The next step would be to apply the process to all existing bugs that are not classified yet. Maybe the severity classes need more explanation, we can improve as we go along.

[Manuel]

In addition, we could add a CI check that fails if there are unclassified bugs. The purpose being that unclassified bugs pose an unknown risk which should at least be evaluated before releasing a new version. That‘s a last straw solution, because bugs should be classified within days, but at least there is a hard stop somewhere in the process.

To avoid the complexity of issue assignment as proposed in the previous comment, it could be sufficient to add a bot that posts an issue comment if a issue classified as bug has not been assigned a severity level after n days. The comment can tag the core contributors group. These comments can repeat until someone look at it eventually. It would be less intrusive, easy, and no fixed assignment per person, whoever looks at it first goes ahead and classifies it.

[Manuel]

Suggestion for next improvement: Merge labels question and troubleshooting into guidance as differentiation has proven to be unnecessary; there have virtually been no question labels applied since the new labels were introduced.

[Manuel]

Suggestion for policy addition: do not use a stale bot. The stale bot has been deactivated half a year ago for the Parse Server repo which forces us to look at issues. Manual closing makes more sense, I continue to stumble upon issues that were previously closed by the bot, are still relevant and people ask for the issue status.

[Manuel]

I suggest to change the following labels in the parse-server repo:

• Remove labels Merge On Green, greenkeeper
  Greenkeeper bot doesn’t exist anymore

• Merge labels question and troubleshooting into question
  Differentiation has proven to be unnecessary; there have virtually been no question labels applied since the new labels were introduced, only troubleshooting. question can be anything, so as a merged label guidance is more specific than question but general enough to include troubleshooting. Edit: It should not be guidance, because guidance is what may or may not be provided and doesn’t belong into GH issues, but question (for lack of a better term) is what the opened issue is.

• Remove label up for grabs
  Given the amount of feature and enhancement issues without recent activity, the up for grabs label would be applied to the vast amount of these issues, to the point where it may loose its significance. In addition, it doesn’t provide much value, because anything is up for grabs if someone wants to contribute, even if that means collaborating on a PR that is actively being worked on through code, feedback or (non-binding) review.

• Remove label stale
  Stale bot has been disabled for almost a year now on the parse-server repo. It has proven to mitigate confusion among community members when seeing closed issues that are still relevant. So I suggest to keep the stale bot disabled and remove the label.

According to the adopted governance for label changes, they require a voting:

@Manuel

(…) any future changes of the labels or the framework governing their usage requires a majority vote by the core team members.

@davimacedo @dplewis @davimacedo If there are no objections to the changes above, I will go ahead and open a voting in a few days.

[Manuel]

Voting on the following changes to the GitHub labels for parse-server repo:

• Remove labels Merge On Green, greenkeeper
  Greenkeeper bot doesn’t exist anymore
• Merge label troubleshooting into question
  Differentiation has proven to be unnecessary; there have virtually been no question labels applied since the new labels were introduced, only troubleshooting. Since question has a broader meaning, it makes sense to use that term going forward.
• Remove label up for grabs
  Given the amount of feature and enhancement issues without recent activity, the up for grabs label would be applied to the vast amount of these issues, to the point where it may loose its significance. In addition, it doesn’t provide much value, because anything is up for grabs if someone wants to contribute, even if that means collaborating on a PR that is actively being worked on through code, feedback or (non-binding) review.
• Remove label stale
  Stale bot has been disabled for almost a year now on the parse-server repo. It has proven to mitigate confusion among community members when seeing closed issues that are still relevant. So I suggest to keep the stale bot disabled and remove the label.

Adoption of changes requires a majority vote by the core team members. The poll will be closed once all PMC members have cast their vote, but latest 7 days from now (Sun, July 11).
cc @davimacedo @dplewis @Tom

Should the changes be adopted?

• Yea
• Nay