Develop issue labels to be used across lesson repositories

[fmichonneau]

• Problem that needs to be solved: To improve the experience of contributing to and maintaining Carpentries lessons, and gain more meaningful contributions, it would be good to have a consistent set of issue tags across all of the lessons.

[fmichonneau]

A draft of a proposal for this is available. Don't forget to sign in if you'd like to have your name associated with your comments.

[rgaiacs]

Don't miss https://github.com/blog/2505-label-improvements-emoji-descriptions-and-more.

[fmichonneau]

Blog post announcing GitHub labels we are testing across repositories: https://software-carpentry.org/blog/2018/04/github-labels.html

[katrinleinweber]

For completeness sake:

• List of issues that discuss the new labels in the respective repos: Pilotting the new GitHub labels swcarpentry/r-novice-gapminder#355, Pilotting the new GitHub labels swcarpentry/python-novice-gapminder#286 & Pilotting the new GitHub labels swcarpentry/git-novice#483.
• Alternative, lightweight suggestion: Avoid label fatigue/overload docs.carpentries.org#134
• Procedural question whether existing labels will be deleted or not: What happens to existing labels? fmichonneau/chisel#1

[katrinleinweber]

swcarpentry/r-novice-gapminder#355 (comment) highlighted another point I'd take as an argument in favour of sticking to the GitHub default. good first issue and help wanted trigger a "X issues need help"-link on an organisation's repo overview. Prepending status: seems to break this.

---

I wonder why supporters of an almost completely new, self-made and Carpentries-specific label set:

1. agree to stop diverging those labels from the standard, that provide a clear standard benefit (like shortcuts), see Pilotting the new GitHub labels swcarpentry/r-novice-gapminder#355 (comment), but
2. still want to diverge other labels, which currently are not linked to a standard benefit?

It's not a difficult prediction that GitHub will further streamline labeling workflows, based on the usage patterns they see across millions of projects. Will you agree to adjust now diverged labels back one-by-one then? If yes, why diverge in the first place?

---

BTW, there is decade-old name for "new, self-made and XYZ-specific": the "not invented here" anti-pattern / syndrome.

[fmichonneau]

• Re: "procedural question whether existing labels will be deleted or nor": see What happens to existing labels? fmichonneau/chisel#1 (comment)
• Re: "good first issue" and "help wanted", see: Pilotting the new GitHub labels swcarpentry/r-novice-gapminder#355 (comment)

[fmichonneau]

The lesson infrastructure committee approved the proposal of using the same set of labels across all our repositories during its last meeting on May 23rd, 2018.

We'll evaluate adoption and use of the labels with the maintainers in 3 months or later. In the meantime, this issue remains open to collect feedback and concerns.

[katrinleinweber]

What data is available from the pioneering repos that the goal "improve the experience of contributing to and maintaining Carpentries lessons, and gain more meaningful contributions" has been met?

My qualitative impression from the last weeks is that both even actionable issues are abundantly labelled, rather than actually acted upon. The large choice of eloquently described labels seems to encourage acte de substitution (the German term does not translate well into English).

Maybe a more effective issue management strategy would be to encourage

a) PRs over issues, so there in actual change suggestion to review, and
b) closing stale issues to keep the open list always as short as possible.

[raynamharris]

Thanks @fmichonneau . These labels are working very well.

I'm wondering if I can request some other standard labels or if I should only make them in my own repositories. I would like something along the lines of translation when it related to initial translations or improving translations.

[remram44]

It seems that "official" repositories are using custom labels already: carpentries/instructor-training has its own "pr-requested", "pr-submitted", "stale", "quickfix", "policy" which seem to conflict with the "standardized" (i.e. François's) set of labels.

[katrinleinweber]

I hope other projects will learn from this lesson in labeling: stick to the default, then introduce actually needed, additional labels gradually, and per repo (like policy maybe). AKA: driven by actual needs, instead of preemptive micromanagement, which is what we see failing here.

Some thoughts on those individual labels:

• pr-requested: Doesn't that essentially express help wanted?
• pr-submitted should be indicated by the PR lining back to the issue, or a commit using a closing keyword
• stale: Is that really needed? Doesn't page 2 and below representing that well?
• quickfix: Where those maybe bug, if they needed to be fixed quickly?