-
Notifications
You must be signed in to change notification settings - Fork 26
Open
Labels
scope: support-infraChanges related to the support-infra product.Changes related to the support-infra product.type: new featureExpand the scope of the product to solve a new problem.Expand the scope of the product to solve a new problem.umbrellaFor grouping multiple issues to provide a holistic viewFor grouping multiple issues to provide a holistic view
Description
Steps to reproduce
In https://www.notion.so/mui-org/GitHub-issues-Product-backlog-c1d7072e0c2545b0beb43b115f6030f6?pvs=4#139cbfe7b66080c69573d56038aefe62 we define the different issues label categories that we use. Having all issues & PRs with a clear "scope" and "type" feels critical to be able to properly work as a team of product engineers.
How do we know if it's correctly labeled?
- Issue "scope": based on the database https://www.notion.so/mui-org/GitHub-labels-af1ef18d3f534f1dbc086aac87b819e8
- Issue "type": based on the database https://www.notion.so/mui-org/GitHub-labels-af1ef18d3f534f1dbc086aac87b819e8
Examples of annoyance:
How to implement it?
Issues. scope.
- A.1 Reapply the
status: waiting for maintainer
label if it was removed without a scope label. - A.2 Reopen issues when closed if they are closed without a proper scope label or still has
status: waiting for maintainer
, or add some kind of invalid label. - A.3 Once we have A.2, https://www.notion.so/mui-org/product-GitHub-community-issues-PRs-Tier-1-12a84fdf50e44595afc55343dac00fca?source=copy_link#d6680f5abf8b4e3ab132cb8e336bb5bc should not be needed anymore; we should be able to delete it.
Issues. type.
- A.4 Reapply the "status: waiting for maintainer" label if it was removed without a type label.
- A.5 Reopen issues when closed if they are closed without a proper type label, or add some kind of invalid label.
- A.6. Remove so that we can reopen automatically the issues that have the "status: waiting for maintainer" label
mui-public/.github/workflows/scripts/issues/addClosingMessage.js
Lines 68 to 75 in 914ab48
const labelName = 'status: waiting for maintainer'; core.info(`>>> Trying to remove label: ${labelName}`); await github.rest.issues.removeLabel({ owner, repo, issue_number: issueNumber, name: labelName,
Also so we can remove https://www.notion.so/mui-org/product-GitHub-community-issues-PRs-Tier-1-12a84fdf50e44595afc55343dac00fca?source=copy_link#553d3ddfd15e4daa87875997b2924271
PRs, scope.
- B.1 We could create a GitHub Action that fails the PR if no “scope” label is applied.
- B.2 Then adopt it in all repositories.
- B.3 Once we have B.2, https://www.notion.so/mui-org/product-GitHub-community-issues-PRs-Tier-1-12a84fdf50e44595afc55343dac00fca#d97e5e8b4f394dec95de36668dbf81d2 should not be needed anymore; we should be able to delete it.
PRs, type.
- B.4. We could create a GitHub Action that fails the PR if no “type” label is applied.
- mui-x [support-infra] Enforce type labels on PRs #275. Remove the
check-if-pr-has-label.yml
action (it replaces it). - other repositories
- mui-x [support-infra] Enforce type labels on PRs #275. Remove the
- B.5 Then adopt it in all repositories.
- B.6 Once we have B.5, https://www.notion.so/mui-org/Pull-request-types-1abcbfe7b66080f4a5a6e593e0a90ce4 should not be needed anymore; we should be able to delete it.
- B.7 We can remove "Check if PR has label" action, legacy
Monitor
To monitor the effectiveness of the policy, we could update GitHub PRs/issues without labels 📊 to not only cover when there are no labels, but also when there aren’t enough.
oliviertassinari
Metadata
Metadata
Assignees
Labels
scope: support-infraChanges related to the support-infra product.Changes related to the support-infra product.type: new featureExpand the scope of the product to solve a new problem.Expand the scope of the product to solve a new problem.umbrellaFor grouping multiple issues to provide a holistic viewFor grouping multiple issues to provide a holistic view