Labels

[afeld]

Branching off of #4 and a conversation w/ @ultrasaurus, @juliaelman, and some other coworkers: what labels are useful to apply to issues (or maybe even projects, if whatever platform had a mechanism for doing so) to help new OSS-ites figure out what to start with? Some conversation starters:

• help wanted
• beginner friendly
• low hanging fruit
• easy
• neweng
• starter
• design, documentation, and other non-coding-task labels (note: not implying that these are easy)
• https://github.com/girldevelopit/gdi-new-site/labels

Any conventions that we could establish?

[juliasolorzano]

@afeld thanks for posting this! It might also be good to add labels for specific coding asks where needed (e.g. JavaScript) to help target the specific asks from the issue.

[afeld]

As @juliaelman brought up in chat (and I was too slow to submit as a comment here before her), pairing of labels can be useful, e.g. beginner friendly + frontend.

We also discussed that "easy" and "beginner" are potentially ambiguous..."easy" to whom? A frontend task won't be easy to an experienced backend person, etc. "Beginner"...to coding? to open source?

[gboone]

I'm going to start moving through issues in 18f/18f.gsa.gov with these labels. Maybe we have a page in the 18f/18f.gsa.gov wiki or the Hub explaining what we mean?

[afeld]

Maybe we have a page in the 18f/18f.gsa.gov wiki or the Hub explaining what we mean?

@juliaelman's all over it: 18F/hub#229

[gboone]

😄 what I get for now following the whole conversation. Thanks for the pointer.

[andrew]

I did a fair bit of research on this when I was at GitHub, we added the help wanted label as a default because it was the best fit for "asking for outside assistance" without assuming too much. Anything based on skill level like "easy" assumes you know a certain amount, easy in Haskell compared to easy in HTML for example.

starter-issue is also a nice way of showing which issues are good for people new to the project to pick up, although on 24 Pull Requests I often saw 3 or 4 people all fix the issue and send pull requests within hours of each other, which only leads to dissapointment for anyone who's pr doesn't get merged, so there definitely needs to be more work done to educate and welcome new people than just labelling up issues.

[kytrinyx]

One really nice label that I've seen is bug?, which (presumably) helps encourage people to contribute by actually trying to reproduce it.

I also have a label called support which I use when it's basically just a back-and-forth about how to install some dependency and does it even work on Windows, etc. I don't know if this is good, but I like to make it clear that I'm happy to help people get things figured out, while also making it easy for people to not look at support issues if they're hunting for a good bug or small feature to work on.

[afeld]

@gabekneisley just told me that typeahead.js uses an entry-level label, which they seem to be getting good response to.

[gabekneisley]

I have also seen bitesized, bite-sized, bitesize, and bite-size

[jdaudier]

I wonder if foreigners would be confused with the slang low hanging fruit as a label.

[gabekneisley]

I don't see much value in using an idiomatic phrase for this kind of bug (including phrases like bite-sized). I think plain-language phrases like: beginner-friendly or easy are best. I also think it wouldn't be a bad idea overall to give all accepted bugs and features a qualitative rating such as: difficulty: easy, difficulty: moderate or difficulty: hard

[jdaudier]

agreed

[tute]

While we don't have a standard as a community for entry-level, help wanted and variations, what can we do to refer newcomers to appropriate issues?

• Create a list of links or other frontend to these different classifications
• Ask GitHub to define more default labels, and create some in repositories where there is none defined
• Ask maintainers to follow a single standard

All imply coming up with a document defining a good taxonomy, if there isn't one already written. what are good next steps on it?