I find myself coming back again and again to this blog post by Scott Hanselman on the importance of kindness in open source communities, and the experiences and attitudes that prevent contributors from joining a project:
The Community Health Toolkit is fortunate to have one of the most patient and dedicated communities I’ve encountered, but I’m curious about ways we can foster an even more inviting and safe spaces for new contributors.
I’d love your thoughts; have you contributed to another open source project before? What was your experience like? And if you’ve contributed to the CHT or Medic Mobile, what could we improve or stream line?
The very first thing is says is “Make people feel welcome” - so is something I’d really endorse (not like the example you gave @francesca!).
Getting involved in a dev community (esp. an established one) can be daunting for a new contributor, so for sure being made welcome is a very good first step.
Something that for me is very helpful is to have keep some ‘easy’ bug/issues, specifically for new devs to be able to address, and feel like they’re contributing, even when they don;t know (yet) all the ins/outs/details of the full code base.
I manage an open source project, and it can be hard for me to leave these ‘easy’ things - often I feel I can just fix them in a few mins, but actually it’s better for me not to fix them and give others the chance to contribute and get some recognition for their involvement.
Totally agree @alex! We’ve been using the help wanted tag to prioritize issues that might be better for a newer developer. The upcoming 3.8 release of the CHT core framework has 6 open issues with that tag.
With Oppia Mobile it looks like you’re using the good first issue tag for that purpose, is that right? Looks like you have 8 open issues with that tag.
If there are any new potential contributors following this post, it would be great to see you take up one of these issues!
Yes, we use the ‘good-first-issue’ tag (although of course there are many different ways to represent/tag these issues). I tend to use this tag for issues that:
Probably only require a couple of code line changes in 1 or 2 files
Are not critical/blocker bug type issues
Of course, very happy if new devs want to take on some of the more substantial/complicated issues!
We’re also looking at the possibility for engaging with computer science/ed tech master students, as part of an internship or student thesis project, and we’ll use these good first issues as a way of assessing which students would be suitable to work with - i.e. asking them to tackle one of these first issues before we work with them in more substantial way.
Something else that I think is useful to consider here is that there are many ways in which non-devs can also make valuable contributions to these OS projects… for example:
documentation updates/reviews
translations
code refactoring suggestions (to make the code easier to read/maintain)
QA reviews
UI/UX suggestions
You don’t necessarily need to be a programmer/developer to contribute, but sometimes these types of contributions aren’t always able to be represented well in GitHub issue lists etc.
For OppiaMobile, we have a section in the docs (here: Contributing to OppiaMobile — OppiaMobile 0.14.9 documentation) that describes some of these other opportunities, but likely this page is a bit hidden away for people to easily come across it and it still a little technical at the moment.
