Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
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

  1. Remove extraneous sources of cross-repo labels.

    1. Delete all the repository default labels from the openedx org’s settings.

    2. Remove the labels from the OSPR bot repo.

    3. Remove the DEPR automation step that adds the DEPR label.

  2. Add support for syncing label “descriptions” to EnsureLabels This should be very easy.

  3. Either:

    1. 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.

    2. 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.

  4. 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

...

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

question

Further information is requested from the author

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.

✔️ requirement

Condition that must be met for a project or MVP

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).

👥 changes requested

PR reviewers are waiting on author to apply feedback

A reviewer or reviewers have taken a look at the PR and requested the author make changes.

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.

...