Open fmichonneau opened 6 years ago
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.
Blog post announcing GitHub labels we are testing across repositories: https://software-carpentry.org/blog/2018/04/github-labels.html
For completeness sake:
https://github.com/swcarpentry/r-novice-gapminder/issues/355#issuecomment-380188431 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:
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.
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.
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.
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.
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.
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 keywordstale
: 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?