Detail how GitHub labels are used - set up specific ones

[Lextuga007]

Following Carpentries Handbook https://docs.carpentries.org/topic_folders/maintainers/github_labels.html

https://beta.carpentries.org/blog/2018/04/2018-04-05-github-labels/

[Lextuga007]

The page (currently broken) details how to apply labels across the organisation using an R script but also https://github.com/carpentries/github-skill-up-maintainers/blob/e0644550ee370dc46c5f52e0cc41247b13875b47/files/generate_example_repositories.py#L63 helps with setting up new repositories and using gh via Python

[Lextuga007]

To set up labels for new repositories https://docs.github.com/en/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization

[Lextuga007]

From Carpentries:

good first issue - Good issue for first-time contributors
help wanted - Looking for contributors
high priority - Need to be addressed ASAP
invalid - PR considered as spam
status:blocked - Progress on addressing issue blocked
status:duplicate - Issue or PR already exists
status:in progress - Contributor working on issue
status:need more info - More information needed
status:out of scope - Proposed changes are out of scope
status:refer to cac - Curriculum Advisory Committee input needed
status:wait - Progress dependent on another issue or conversation
status:wait - Waiting for Contributor to respond to maintainers comments or update PR
type:accessibility - improve content compatibility with assistive technology as well as unassisted access
type:bug - Content in the lesson needs to be fixed
type:clarification - Suggest change for make lesson clearer
type:discussion - Discussion or feedback about the lesson
type:enhancement - Propose enhancement to the lesson
type:formatting - Formatting needs to be fixed
type:instructor guide - Issue with the instructor guide
type:teaching example - PR showing how lesson was modified in a workshop
type:template and tools - Issue about template and tools
type:typo text - Typo in text for the lesson

But not all are required for NHS-R and proposed useful labels would be:

type:content - Changes or suggested corrections to content or text
type:discussion - Discussion or feedback about content or the community
type:clarification - Suggest change to make content or documentation clearer
type:accessibility - improve content compatibility with assistive technology as well as unassisted access
status:waiting for response - Waiting for Contributor to respond to maintainers comments or update PR
status:wait - Progress dependent on another issue or conversation
status:out of scope - Proposed changes are out of scope
status:need more info - More information needed
status:in progress - Contributor working on issue
status:blocked - Progress on addressing issue blocked
status:duplicate - Issue or PR already exists
high priority - Need to be addressed ASAP
type:bug - Something needs to be fixed
type:enhancement - Propose enhancement
documentation - Improvements or additions to documentation
good first issue - Good issue for first-time contributors
help wanted - Looking for contributors
invalid - PR considered as spam
question - Further information is requested

Along with existing:
hacktoberfest
hacktoberfest-accepted

[Lextuga007]

It's not clear if there is a reason why there is no space between the semi colon and the next word as there are labels with spaces later like status:in progress.

As there are only currently two repositories with these labels, this and assets it's a good time to agree the format for the labels which might be better using dashes like the current hacktoberfest-accepted.

[matt-dray]

As requested on Slack, just some thoughts on labels. We (The-Strategy-Unit) have set some defaults at org level: bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question and tech debt, as well as the priorities must, should, could and won't. But the exact label set differs between repos depending on the choices of the repo owner (a repo containing a Quarto documentation website will have different needs vs one for a Shiny app). Typically I like to use a 'type' label (e.g. enhancement, bug, techdebt, documentation) + a priority label (must, should, could, won't). This is light touch (I don't want to spend all day corralling labels) but provides enough info for efficient triaging. We handle issue status in a GitHub Project, so we don't need labels for things like 'blocked' or 'in progress'.

[Lextuga007]

That reminded me, Turing Way shared this project for Infrastructure Working Group.