We expect contributors to abide by our underlying code of conduct. All conversations and discussions on GitHub (issues, pull requests) and across dev.to must be respectful and harassment-free.
All issues labeled with help wanted are up for grabs.
good first issueare issues meant for newer developers.type: discussionare issues we haven't decided to move forward with, or need more information before proceeding.
While PRs without an associated help wanted issue may still be merged, please note that the core team will prioritize PRs that solve existing issues first. We strongly encourage creating an issue before working on a PR!
When in doubt, ask a core team member by mentioning us on the issue.
Refactoring code, e.g. improving the code without modifying the behavior is an area that can probably be done based on intuition and may not require much communication to be merged.
Fixing bugs may also not require a lot of communication, but the more the better. Please surround bug fixes with ample tests. Bugs are magnets for other bugs. Write tests near bugs!
Building features is the area which will require the most communication and/or negotiation. Every feature is subjective and open for debate. If your feature involves user-facing design changes, please provide a mockup first so we can all get on the same page. As always, when in doubt, ask!
- Fork the project & clone locally. Follow the initial setup here.
- Create a branch, naming it either a feature or bug:
git checkout -b feature/that-new-featureorbug/fixing-that-bug - Code and commit your changes. Bonus points if you write a good commit message:
git commit -m 'Add some feature' - Push to the branch:
git push origin feature/that-new-feature - Create a pull request for your branch 🎉
Nobody's perfect. Something doesn't work? Or could be done better? Check to see if the issue already exists and if it does, leave a comment to get our attention! And if the issue doesn't exist already, feel free to create a new one. A core team member will triage incoming issues.
Please note: core team members may update the title of an issue to more accurately reflect the request/bug.
Some existing code may be poorly written or untested, so we must have more scrutiny going forward. We test with rspec.
- Try to keep the pull requests small. A pull request should try its very best to address only a single concern.
- Make sure all tests pass and add additional tests for the code you submit. More info here.
- Document your reasoning behind the changes. Explain why you wrote the code in the way you did. The code should explain what it does.
- If there's an existing issue related to the pull request, reference to it by adding something like
References/Closes/Fixes/Resolves #305, where 305 is the issue number. More info here. - Please fill out the PR Template when making a PR.
- All commits in a pull request will be squashed when merged, but when your PR is approved and passes our CI, it will be live on production!
Please note: a core team member may close your PR if it has gone stale or if we don't plan to merge the code.
After you submit your pull request (PR) one of the members of the core team or core contributors will likely do a review of the code accepting it or giving feedback.
If feedback or suggestions are provided, any following modifications on your part should happen in separate commits added to the existing ones.
Force pushing, though understandable for reasons of wanting to keep the history clean, has some drawbacks:
- it removes the review history of the code
- forces the reviewer to start from scratch when adding possible further comments
PRs will be squashed and merged into master so there's no need to use force push.
Please avoid force pushing unless you are in need to do a rebase from master.
We are all humans trying to work together to improve the community. Always be kind and appreciate the need for tradeoffs. ❤️