Note |
---|
This proposal is now being implemented! If you have comments, please leave them on:
|
Table of Contents |
---|
Overview
We would like to have a standard set of labels available in every repo so that it’s easier to:
...
1. Proposal: Store labels in one central place
This will be implemented by: https://github.com/openedx/terraform-github/pull/60
Remove extraneous sources of cross-repo labels.
Delete all the repository default labels from the openedx org’s settings.
Remove the labels from the OSPR bot repo.
Remove the DEPR automation step that adds the
DEPR
label.
Add support for syncing label “descriptions” to EnsureLabels This should be very easy.
Either:
Store the labels in a new labels.jsonyml file in the same directory as repo_checks.py. Change EnsureLabels to pull labels from the json file.
Going forward, cross-repo labels would be managed by editing labels.json and re-running EnsureLabels.
Change EnsureLabels to pullthe labels via the API from one central repository: .github.
Going forward, cross-repo labels would be managed by editing the labels via the repo settings of .github and re-running EnsureLabels.
The benfit of this is that it’d be easier for non-coders to manage cross-repo labels. The drawback of this is that changes to our cross-repo labels would not be version-controlled.
Add a step to tCRIL’s “new repository” playbook: Execute repo_checks so that the new repository’s setting matches our standards, including its list of labels.
2. Proposal: List of starter labels
...
This will be implemented by: https://github.com/openedx/terraform-github/pull/61
Name | Description – one brief line that will be shown in the GitHub UI Notes are in italics |
---|---|
🎉 good first issue | Good for newcomers |
🙋♀️ help wanted | Ready to be picked up by anyone in the community |
🗺️ epic | Large unit of work, consisting of many tasks |
🌎 initiative | Huge unit of work, consisting of multiple epics |
🛠️ maintenance | Work that must be done for platform health |
🐛 bug | Something isn't working |
🔍 discovery | Pre-work to determine if idea is feasible |
🚀 enhancement | Update or improvement to an existing feature |
❔ |
Deleted as it seems that this is no longer used for intended purpose (indicating that the triager has a question for the author). Some issues use it to indicate “discovery” but we should just use the discovery label for that. We can always add this label back later. |
✔️ |
I’ve removed this from the list as it seems unused. |
⭐ feature | Addition of new functionality |
DEPR | Proposal for deprecation & removal. See OEP-21 |
⛔ wontfix | This will not be worked on |
🖨️ duplicate | This issue or pull request already exists |
👥 waiting on author | PR reviewers are waiting on the author to answer questions, fix tests, etc. Waiting for the author to respond to change requests, feedback, failing tests, etc. Usually this label is used for PRs in board statuses other than “Waiting for Author” (e.g. the pull request is “In Eng Review” column on the board, but the author needs to address review feedback). |
👥 inactive | PR author has been unresponsive for several months Used when the author has been unresponsive for several months. Typically author will be told “we might need to close this due to inactivity” and if there’s still no response we close it a couple weeks later. |
👥 closed-inactivity | PR was closed because the author abandoned it Closed due to PR being abandoned. Typically used after a PR has been abandoned and labeled as “inactive.” |
👥 needs test run | Author’s first PR to a repository, awaiting test authorization from tCRIL This means an author has not contributed to a particular repo before and needs authorization to be able to run tests on the PR. Currently, test authorization is handled by tCRIL. |
👥 core contributor | PR author is a Core Contributor to this repository (manually added) Currently manually applied on the Contributions board to flag to project managers that a CC is the author. |
👥 open-source-contribution | PR author is not from tCRIL or 2U Automatically added by bot to PRs coming from the community (not tCRIL or 2U). |
👥 blocked by other work | PR cannot be finished until other work is complete Notating that the PR is blocked. It should say in the PR why the work is blocked (e.g. waiting to merge a related PR first). |
👥 |
Deleting; we will use “Waiting on Author” instead. We should notify Michelle and Tim when this change happens so that they can update the board. |
👥 product review | PR requires product review (= it won’t be merged without review and approval from a product manager). Jenna Makowski / Ryan O’Connell will add this label to PRs labeled “open-source-contribution” that require Product Review. |
...