-
Notifications
You must be signed in to change notification settings - Fork 685
Good first issues
Kunal Mehta edited this page Oct 5, 2022
·
1 revision
Good first issues should roughly meet the following criteria:
- Issues should take no longer than two or three days for someone new to our code base.
- Remember that people still need to set up the development environment, etc. If you, an experienced contributor, can do the entire task in under an hour, that's probably a good candidate.
- Issues are self-contained, non-controversial issues with a clear approach.
- Sometimes I'll do 50-80% of the task myself just to make sure there are no unexpected roadblocks or pitfalls that a new contributor would hit. (Or call them out in the issue description if they can be safely skipped over)
- Issues do not require any special permissions in order to test the contribution or to fix the task. Anyone should be able to reproduce.
- We are targeting contributors that don't have SecureDrop hardware or probably the resources to set up a staging environment. Ideally it is all testable in the dev environment/CI.
- Issues should be well-described with pointers to help an absolute newcomer (and preferably don't leave questions).
You should add the following to the top of a good first issue:
*This is a good first issue for new contributors to take on, if you have any questions, please ask on the task or in our [Gitter room](https://gitter.im/freedomofpress/securedrop)!*
External resources:
- Why Good-First-Bugs often aren't
- Wikimedia's good-first-task instructions, from which most of this is copied from (CC-BY-SA 3.0)