Open
Description
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?
Activity
juliasolorzano commentedon Mar 18, 2015
@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 commentedon Mar 18, 2015
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 commentedon Mar 19, 2015
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 commentedon Mar 19, 2015
@juliaelman's all over it: 18F/hub#229
gboone commentedon Mar 19, 2015
😄 what I get for now following the whole conversation. Thanks for the pointer.
andrew commentedon Mar 20, 2015
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 commentedon Mar 22, 2015
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 commentedon Mar 29, 2015
@gabekneisley just told me that typeahead.js uses an
entry-level
label, which they seem to be getting good response to.Mention entry-level issues in the README.
gabekneisley commentedon Mar 29, 2015
I have also seen
bitesized
,bite-sized
,bitesize
, andbite-size
jdaudier commentedon Apr 12, 2015
I wonder if foreigners would be confused with the slang
low hanging fruit
as a label.gabekneisley commentedon Apr 12, 2015
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
ordifficulty: hard
jdaudier commentedon Apr 12, 2015
agreed
tute commentedon Nov 16, 2015
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?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?