Good First Issues

Good First Issues

Want to contribute to DevStream (or open-source in general), but not sure where to begin?

The “good first issue” Label

Items marked with the “good first issue” label are intended for first-time contributors.

For Contributors

After a contributor has completed one (or two) “good first issue” items, it’s recommended to move on to the “help wanted“ label, saving the remaining “good first issue” items for other new contributors.

For Reviewers

Keep an eye on pull requests for “good first issue” and guide the contributors through the pull request process.
Let them know what the next step is. For example:
- move on to another good first issue if they are not completely confident yet
- find “help wanted” issues
- join the community Slack channel, etc.
Proactively call out when there is a problem, and provide information on how to fix it.

All of these make new contributors feel welcome and valued and assure them that they will have an extra level of help with their first contribution.

Please make sure that new contributors should not be left to find a reviewer, ping for reviews or bump, understand why the CLA(Contributor License Agreement)/DCO(Developer Certificate of Origin) check failed, identify that their build failed due to a flake, etc._

Criteria for “good first issue” Items

A good test for “good first issue” is: that a new contributor should be able to claim and address the issue, submitting an acceptable pull request without requiring more help.

Part of an issue’s suitability comes from the nature of the issue itself, but the rest is determined by how much context you provide in the issue so that the new contributor can be successful. With that in mind, please do provide as much detail as possible.

No Barrier to entry: a new contributor can tackle without advanced setup, or domain knowledge.
Provides context: if background knowledge is required, this should be explicitly mentioned, and a list of suggested readings included. Do not apply the label to an issue without first editing it to add context.
Solution explained: the recommended solution is clearly described in the issue.
Gives examples: link to examples of similar implementations so new contributors have a reference guide for their changes.
Identifies relevant code: the relevant code and tests to be changed are linked in the issue.
Ready to test: there are existing tests that can be modified, or existing test cases suitable for copy-pasting. If the area of code doesn’t have tests, before labeling the issue, add a test. This prep often makes a great help wanted task!

Building a Passionate Community

If you make someone feel like a part of our community, that it’s safe to ask questions, that people will let them know the rules/norms, that their contributions are helpful and appreciated… they will stick around!

To make our community as welcoming as possible, the following action items are suggested:

Encourage new contributors to seek help on the appropriate Slack channels, introduce them, and include them in your conversations.
Invite them to your project’s meetings, introduce them when they attend, and give them a chance to participate.
Give credit to new contributors so that others get to know them, “Hey, would someone help give a second LGTM on @newperson’s first PR on chocolate bunnies?”. Mention their work in Slack or during a meeting, thank them on Twitter, etc.
Use all the emojis in your approval or LGTM comment. 💖 🚀
Acknowledge and thank them for submitting their first pull request and then let them know that you are here to help.
Suggest a related help wanted so that can build up experience in an area.
People are more likely to continue contributing when they know what to expect, what is an acceptable way to ask people for a review and nudge things along when a pull request is stalled. Demonstrate how your project works by helping move their first pull request along.
If you have time, let the contributor know that they can DM you with questions that they aren’t yet comfortable asking the wider group.