📝 docs(procedures): Document org-level label schema for issue triage
All checks were successful
Antora docs CI / Build pages (main, mindshare namespace) (pull_request) Has been skipped
Antora docs CI / Build preview (PR) (pull_request) Successful in 9s

The Mindshare Committee introduced charter areas in the previous term.
Now, we have Forgejo labels (`charter/events`, `charter/recognition`,
`charter/ambassadorship`) to triage work against any of the three
charter areas.

The labels have also been retroactively applied across both the
`mindshare/docs` and `mindshare/tickets` repositories. Without docs, new
members and contributors have no reference for which labels to use or
what the exclusive prefix groups mean. This page serves as the canonical
reference so label usage stays consistent as the team grows.

Assisted-by: Claude Opus 4.6 (1M context)
Signed-off-by: Justin Wheeler <jwheel@redhat.com>
This commit is contained in:
Justin Wheeler 2026-07-13 15:19:44 -04:00
commit 53d93927ae
Signed by: jflory7
GPG key ID: 7748B15FA8FA4C7E
2 changed files with 159 additions and 0 deletions

View file

@ -9,6 +9,7 @@
** xref:procedures/mentored_project_rep.adoc[Mentored Project Representative]
** xref:procedures/quarterly_report.adoc[Quarterly Report]
** xref:procedures/council_rep.adoc[Council Representative]
** xref:procedures/labels.adoc[Issue & PR Labels]
** xref:procedures/limesurvey.adoc[LimeSurvey]
* Infographics
** xref:infographics/2019.adoc[2019]

View file

@ -0,0 +1,158 @@
include::ROOT:partial$attributes.adoc[]
= Issue & PR Labels on Fedora Forge
:description: Fedora Forge Issue & PR Labels used by the Fedora Mindshare Committee across all repositories.
:revdate: 2026-07-13
The {team_name} uses a shared set of labels across all repositories in the https://forge.fedoraproject.org/mindshare[Fedora Forge "mindshare" organization].
These labels are defined at the organization level and are inherited by every repository.
Labels that share a prefix (e.g., `scope/`) are _exclusive_: only one label from that group can be applied to an issue at a time.
This prevents conflicting states like an issue being both `state/approved` and `state/blocked`.
[[charter]]
== Charter area (`charter/`)
These labels identify which pillar of the xref:ROOT:index.adoc#responsibilities[{team_name} charter] an issue or pull request supports.
Not every issue needs a charter label.
Apply one when the issue targets how the Committee works on, plans, or budgets within a charter area.
Individual event requests and funding proposals do not need a charter label.
[cols="1,3"]
|===
| Label | Description
| `charter/events`
| xref:ROOT:index.adoc#responsibilities-regional-events[Regional Event Support]: process, planning, and budgeting for events
| `charter/recognition`
| xref:ROOT:index.adoc#responsibilities-recognition[Recognition Service]: contributor recognition programs and awards
| `charter/ambassadorship`
| xref:ROOT:index.adoc#responsibilities-ambassadorship[Digital Ambassadorship]: online community engagement and outreach
|===
[[needs]]
== Needs (`needs/`)
These labels indicate what an issue is waiting on before it can move forward.
[cols="1,3"]
|===
| Label | Description
| `needs/event report`
| An event request that needs a published event report before closing as complete
| `needs/reporter feedback`
| Additional feedback or information from the reporter is needed to advance
| `needs/vote`
| A vote is required from {team_name} members in order to advance
|===
[[scope]]
== Scope (`scope/`)
These labels describe the nature of the request.
[cols="1,3"]
|===
| Label | Description
| `scope/bug`
| Something is not working
| `scope/improvement`
| Repeating or improving something that already exists
| `scope/new`
| Something brand new that has not been done before
|===
[[state]]
== State (`state/`)
These labels track the current status of an issue.
[cols="1,3"]
|===
| Label | Description
| `state/approved`
| Approved by the {team_name}
| `state/blocked`
| Cannot move forward: blocked by feedback, other tickets, or external dependencies
| `state/duplicate`
| This issue or pull request already exists
| `state/invalid`
| This does not seem right
| `state/wontfix`
| This will not be worked on
|===
[[team]]
== Team (`team/`)
These labels identify which Fedora team is most relevant to an issue.
[cols="1,3"]
|===
| Label | Description
| `team/advocates`
| Fedora Advocates
| `team/ambassadors`
| Fedora Ambassadors
| `team/commops`
| Fedora Community Operations (CommOps)
| `team/council`
| Fedora Council
| `team/design`
| Fedora Design Team
| `team/docs`
| Fedora Documentation Team
| `team/g11n`
| Fedora Globalization Team (Localization and Internationalization)
| `team/marketing`
| Fedora Marketing Team
| `team/mindshare`
| {team_name} itself
| `team/websites-apps`
| Fedora Websites & Apps Team
|===
[[other]]
== Other
These labels are not exclusive and can be combined with any of the above.
[cols="1,3"]
|===
| Label | Description
| `good first issue`
| Good for newcomers who want to get involved
| `help wanted`
| Needs help or feedback from the wider Fedora community
|===