Configure org level issue labels standards

[cereallarceny]

I'd like to migrate our labels to the following structure of hierarchy:

• Status: what's the status of the issue?
  • Abandoned - This issue was assigned to someone but is no longer being actively developed.
  • Stale - This issue hasn't really received any attention and likely needs to be triaged again.
  • Available - This issue is available for assignment.
  • Blocked - This issue is being stopped by another issue or series of issues (please list the blocking issues in the main description if this is the case).
  • In Progress - This issue is assigned and currently in development.
  • Review Needed - This issue has been finished and needs review from other team members.
  • Completed - This issue has been completed (in which case, it may also be closed).
• Type: what's the type of the issue?
  • Bug - This issue leads to some functionality not working in the codebase as intended.
  • Documentation - This issue means that we should write documentation for some file, feature, or codebase.
  • Epic - This issue is larger than a single issue and is more specifying a future series of issues that encompass a whole feature or milestone.
  • Improvement - This issue is a small improvement in the efficiency of the codebase, but not a refactor or a new feature.
  • New Feature - This issue designates a totally new addition in functionality to the codebase.
  • Question - This issue describes a question that a user has about implementation or a technical question about the codebase itself.
  • Refactor - This issue designates a refactor in a file, feature, or codebase. It is not meant to be a small improvement in efficiency, but rather a large change in functionality or format. The primary difference between an improvement and a refactor issue type is in the scale of the issue.
  • Research - This issue means that we need to spike out a particular area of research before creating issues for development. More information is needed before continuing.
• Priority: how important is it to have this issue fixed in a timely manner?
  • 4 - Immediate - This issue must be fixed immediately and cannot wait.
  • 3 - High - This issue is of high priority and should be fixed as quickly as possible, ideally within the current or following sprint.
  • 2 - Medium - This issue is of medium priority and should be fixed soon, but there may be other pressing matters that come first.
  • 1 - Low - This issue is of low priority and should only be scheduled if it's important relative to other issues. These issues are often good to delegate to beginners since they don't carry a sense of timeliness.
• Severity: how much damage is this issue describing?
  • 4 - Critical - This issue causes a failure of the complete software system, subsystem or a program within the system.
  • 3 - High - This issue does not cause a failure, but causes the system to produce incorrect, incomplete, inconsistent results or impairs the system usability.
  • 2 - Medium - This issue does not cause a failure, does not impair usability, and does not interfere in the fluent work of the system and programs.
  • 1 - Low - This issue is an aesthetic issue or is the result of non-conformance to a standard.
• Good first issue: An issue that's good for beginners

This would mean that issues would be displayed like the following:

• "Status: Available"
• "Type: Documentation"
• "Priority: 2 - Medium"
• "Severity: 1 - Low"

This is roughly based on the following two guides:

• https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63
• http://www.elementool.com/contact/articles/Bug_Tracking_severity_priority.html

Here's the full list of issues that would be added to all OpenMined repos:

• "Status: Abandoned"
• "Status: Stale"
• "Status: Available"
• "Status: Blocked"
• "Status: In Progress"
• "Status: Review Needed"
• "Status: Completed"
• "Type: Bug"
• "Type: Documentation"
• "Type: Epic"
• "Type: Improvement"
• "Type: New Feature"
• "Type: Question"
• "Type: Refactor"
• "Type: Research"
• "Priority: 4 - Immediate"
• "Priority: 3 - High"
• "Priority: 2 - Medium"
• "Priority: 1 - Low"
• "Severity: 4 - Critical"
• "Severity: 3 - High"
• "Severity: 2 - Medium"
• "Severity: 1 - Low"
• "Good first issue"

[cereallarceny]

I'd also like to organize these by color and add emojis to provide a visual description as closely related as possible.

[Nolski]

To me, priority and severity seem fairly interlinked and might be a bit redundant. It might be worthwhile having a "Status: To Triage" or something of the sort in order to determine the other lables needed. A couple of other helpful lables I've found are:

• Wontfix (is this abandoned?)
• Research (should result in a new ticket being created)
• Question (but perhaps we should discourage this in favor of slack/stackexchange)

I'm not sure they're super necessary given the list is already comprehensive but I figured I'd drop them here just in case.

[cereallarceny]

Priority and severity are inherently different. @simcof convinced me of this too. There's a difference between the importance of fixing an issue in a timely manner (priority) and how many parts of the codebase this issue affects (severity). Check out this chart for an explanation on how they're different: https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcSIf6OwCw0h-haE8uBDE6LMJKPgigEY6CbaVKCZMvrBNg89KsJn&usqp=CAU

• Wontfix - these issues can be closed because they're irrelevant. Abandoned means that we need to reassign something that's been claimed, but not done.
• Research we could do, I'll add that.
• Question I've added.