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

GitHub labels pilot #651

Closed
fmichonneau opened this issue Mar 21, 2018 · 10 comments

Comments

@fmichonneau
Copy link
Member

commented Mar 21, 2018

I just added the prototype github labels to the repository. Please let me know how they work for you and any feedback you might have. For reference the current definitions of the labels are in Carpentries handbook: http://docs.carpentries.org/topic_folders/lesson_development/github_labels.html

We are going to test them first in a few repositories including this one until the end of the month, and we are planning to have a revised version of these labels ready in time for the Bug BBQ on April 12-13.

To test these labels, it would be great if you could assign at least 2 labels to each issue: one in the "status" category, and on the "type" category. Depending on the context, you may also want to add the "bug-bbq", the "good first issue" or the "high-priority" labels.

I'd really like your feedback on how well these labels capture the type of issues that are currently in the repository, or that we have or can receive. If you feel that some labels don't capture the nature of the issue, or if the meaning of the labels is too unclear to make a call, I'd really like to hear about it.

There is also a little more information about these labels in the proposal: https://docs.google.com/document/d/1b3nIZ6N4IHY24JmLNQ5rkwUACEVS9Hls3auzZD7zHqk/edit

Feel free to ping me on Slack, by email or here if you have any questions or with your comments/feedback. Thanks!

@karenword

This comment has been minimized.

Copy link
Collaborator

commented Mar 21, 2018

Thanks @fmichonneau -- we'll give it a try!

@remram44

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2018

I see that both old and new labels are set. That's somewhat confusing, but that also means you will have to remove the old ones and add the new ones to all issues, whereas they would have stayed set if you had just renamed them.

On the labels themselves, I see a couple issues:

  • status:help-wanted means it won't show up for people looking for GitHub's default help wanted label
  • There is no point having status:completed when you can just close the issue. I think the feedback on the Google Doc was pretty clear we didn't want this, I'm surprised you added it against our will
  • status:need-contributor and status:help-wanted are duplicates
  • The type:teaching-example is a very weird idea. Filing PRs that are not meant to be merged? Might be the right way to point to a fork, but are those PRs supposed to stay open? Just tag it and close it? (IIRC closed PRs can't be updated)

Overall I think there might be too many labels. I'm not sure we need to categorize issues between "typo", "formatting", "enhancement", "clarification". Contributors are very unlikely to search for a specific type they want to address anyway. Do we need to add this classification burden on maintainers?

Thanks

@ChristinaLK

This comment has been minimized.

Copy link
Collaborator

commented Mar 21, 2018

Thanks @fmichonneau! We'll see how it goes. :)
Is there a process for giving feedback on the labels, if we run into some of @remram44's or our own concerns?

@fmichonneau

This comment has been minimized.

Copy link
Member Author

commented Mar 21, 2018

@remram44 Yes, at this time both old and new labels are set. As you mentioned, deleting the old set of labels before deploying the new set would have meant that previous work put into tagging the issues would have been lost. There isn't a one-to-one correspondence between old and new set, so renaming wasn't an option. The label overview makes it relatively clear which labels are new given that they have a short description (which the old labels don't have).

As mentioned in today's call, we might rename the "status:help-wanted" to something that signals that this issue needs expertise. No decision has been made on this, and I also agree with your point that this can be too vague to be useful. Regarding GitHub's default, we'll have "good first issue".

I added a note in the google doc proposal to explain why having "status:completed" is different from relying on merged and closed issues. Let me know what you think.

We've gotten several teaching examples pull requests for instance: datacarpentry/R-ecology-lesson#342 I think they are useful when revamping the content of the lesson to see how other Instructors approach the lesson. Adding the label and closing seems reasonable to me.

As for the number of labels, several maintainers echoed Naupaka's comment that it helps them process the nature of the issue. Being able to categorize issues was requested by many maintainers in the interviews Erin conducted a few months ago. I think finding the right balance to make these labels useful to both maintainers and contributors will take a few iterations.

@ChristinaLK You can add comments here or on the Google doc: https://docs.google.com/document/d/1b3nIZ6N4IHY24JmLNQ5rkwUACEVS9Hls3auzZD7zHqk

@remram44

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2018

GitHub added this handy little button, making it yet more important to use the standard "help wanted" label:

screenshot_20180321_222222

@karenword

This comment has been minimized.

Copy link
Collaborator

commented Apr 13, 2018

It would be useful to have a label for items that, if changed, would require associated changes to be propagated to other materials. In the case of this curriculum this would be mainly the Etherpad and/or Google Doc templates. However, this could also include changes to data files etc. more relevant to other curricula.

@katrinleinweber

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2018

That use-case can also be covered by adding checkboxes to the original post of an issue. Like:

- [ ] update pad... with ...

It needs to be made explicit anyway, at some place what the exact changes are, and GitHub transforms such a task list to a little progress bar on the issue overview page as screen shot 2018-04-14 at 09 37 20 for example.

@remram44

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2018

I would still very much like to know what the purpose of those labels are:

  • Is it to help maintainers maintain, tagging issues to indicate what the next step is, and who needs to take a look? (so "help wanted", "in progress", "discussion", etc)
  • Or is it for the Carpentries staff to derive statistics from? ("completed", "typo", "bug-bbq", distinction between wait/blocked/need-more-info is useless to contributors)

We have spent multiple meetings discussing those labels and yet it still seems that we are charging ahead (well, @fmichonneau is charging ahead...) without any direction.

@fmichonneau

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2018

The main purpose is to help maintainers and contributors. The type and the status of the issue are useful for both, and for people within the community to step in when needed (e.g., status:refer to cac). We might derive statistics on them in the future, but it's not implemented yet.

I'm sorry you feel that I'm "charging ahead without any direction" given that:

  • I incorporated feedback from the community including yours (e.g.; I removed the completed label) in the labels that are currently in use
  • Most of the feedback we have gotten on the labels has been positive.
@remram44

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2018

Thanks for clarifying the purpose.

Apologies for the harsh words, I did not know an update had been made at all. This definitely looks better.

I see that a CSV file is included, is there an easy way to create labels in a repository from it? I am mostly concerned about datacarpentry/sql-ecology-lesson/labels which has very unusual labels.

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.