Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop issue labels to be used across lesson repositories #1

Open
fmichonneau opened this issue Feb 14, 2018 · 11 comments

Comments

@fmichonneau
Copy link
Member

commented Feb 14, 2018

  • 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 fmichonneau added this to the 2018-03 meeting milestone Feb 14, 2018

@fmichonneau fmichonneau changed the title Develop issue tags to be used across lesson repositories Develop issue labels to be used across lesson repositories Feb 20, 2018

@fmichonneau

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2018

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

This comment has been minimized.

@fmichonneau

This comment has been minimized.

Copy link
Member Author

commented Apr 5, 2018

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

@katrinleinweber

This comment has been minimized.

Copy link

commented Apr 6, 2018

For completeness sake:

@katrinleinweber

This comment has been minimized.

Copy link

commented Apr 11, 2018

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 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

This comment has been minimized.

Copy link
Member Author

commented Apr 11, 2018

@fmichonneau

This comment has been minimized.

Copy link
Member Author

commented Jun 8, 2018

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

This comment has been minimized.

Copy link

commented Jun 9, 2018

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.

This was referenced Jun 11, 2018
@raynamharris

This comment has been minimized.

Copy link

commented Jul 6, 2018

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

This comment has been minimized.

Copy link

commented Aug 9, 2018

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

This comment has been minimized.

Copy link

commented Aug 9, 2018

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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.