“Good first issues” ¶
“Good first issues” are a good way to start on an OSS project, and an official GitHub initiative. Several GitHub repositories use this label to encourage new contributors to start helping the project without the necessity, in most cases, of contacting one of the project’s contributors in advance or having a deep knowledge of the project’s architecture or content.
How can I identify a good first issue? ¶
Good first issues are usually flagged that way in GitHub projects’ issues lists, and are normally simple tasks that a contributor can accomplishe separately from other dependencies. It can be a small code enhancement, documenting internal functions, creating small APIs to connect services, user testing, and similar contributions.
Rather than simply tagging the issue as a “good first issue”, consider taking time to explain in detail exactly what the contributor will need to do, and give suggestions about how you might do it.
Wouldn’t it be easier to fix it myself? ¶
The point of the “good first issue” is that it is an investment in future contributors and, thus, in the sustainability of the project. While it would, indeed, probably be easier to fix it yourself, investing the time to document what needs to be done, and how it might be done, is a way to engage a potential new contributor.
It’s a good idea to put contact information in the ticket, so that someone who wants to work on it, but lacks the confidence to do it, can get in touch with you and ask for help. Remember that this is not primarily about fixing the issue, but is about mentoring a new contributor in small ways, so that they can, eventually, become a productive member of the project.
Example good first issues ¶
Here are some Apache projects that regularly post “good first issues”: