How to Contribute
Setting Expectationsβ
We're laser-focused on two things:
- Helping minimalists manage their schedule and focus, so they can do more of what matters
- Being profitable, so that we can continue doing #1 for decades
We're only accepting contributions that help us reach those goals. If you submit a PR that doesn't align with our goals, it will be rejected. The best way to avoid this scenario is to confirm that your proposed changes align with our priorities. You can verify this by reviewing the Roadmap and timeline (more links and details on how to do this below).
If these goals align with your own, we'd love to work with you!
What's in it for youβ
π Recognition (GitHub, changelogs, etc)
What may be offered after consistent excellence*:
- π Reference for your next job
- π Compensation
- π Preference for future opportunities @ Switchback (the company behind Compass)
*These are the criteria we use to assess the quality of your work. If you don't meet these criteria, we may reject your PR.
- Code quality: Is the code readable, well-organized, and testable? Does it follow best practices? Does it provide good UX?
- Expertise: Does your work reflect your skill level? Did you need a lot of technical guidanceΒ in order toΒ get started? Were you able to make good judgments about the requirements and implementation?
- Communication: If you got blocked, did you reach out for help?Β Did you communicate your plans and progress clearly?Β Are your commits, PR descriptions, and comments easy to understand?
- Reliability: Did you submit your PR, update based on comments in a timely manner? If something came up that prevented you from completing a PR on time, did you let us know?
Workflowsβ
π You're ready to pick up a new taskβ
- Review the roadmap to confirm that the issue you'd like to work on is aligned with our goals
- Review the quarterly backlog. This is the view that shows each important issue by the quarter it's planned for.
- Review the timeline to confirm that you could finish the issue you'd like to work on before its deadline.
- If this is your first time contributing, pick an issue in the
Ready
state for the next quarter that has aGood first issue
tag. Working on an issue in the next quarter gives you time to familiarize yourself with the codebase while still working on a priority change. It also gives us the chance to assess the quality of work and your reliability before giving you more responsibility. - Find an issue you'd like to work on. If you can submit a PR for it before the
End
date assigned to it: ask to have the issue reassigned to you in the issue comments. If you can't finish it on time, find another issue in the next quarter that you could. - Ask any clarifying questions in the issue thread.
- Start working on the issue. (If you're a new contributor, we will NOT assign the issue to you before a PR is submitted. This helps us avoid holding an issue for an extended period of time.)
- Fork the repository
- Create a new branch with a descriptive name
- Make your changes, following the coding conventions
- Manually test your changes. See the testing guide for more info on how to do this sufficiently.
- Push your branch to your fork
- Create a pull request
- Link the PR to the issue it solves by including the issue number in the PR description. For example:
Fixes #123
- Wait for feedback. You can continue this process with another issue while waiting for feedback.
π You found an undocumented bugβ
- If the bug is a security vulnerability, please report it here.
- Ensure the bug was not already reported by searching under the issues
- If it's a new bug, open a new issue, including as much relevant information as possible.
βοΈ You want to add a new feature or dramatically change an existing oneβ
Larger features or changes that are not already on our Roadmap or in the backlog will most likely be rejected. If you're unsure, open a GitHub issue before you start working. This will help ensure that your work is aligned with the project's goals and that you don't spend time on something that won't be prioritized.
π You fixed whitespace, formatted code, or made a purely cosmetic patchβ
Changes that are cosmetic in nature and do not add anything substantial to the stability, functionality, or testability will generally not be accepted.
Quality Assessmentβ
It can be hard to