Contributing to GorangoCSS
We are all humans trying to work together to improve the community. Always be kind and appreciate the need for tradeoffs.
We expect contributors to abide by our underlying Code of Conduct. All discussions about this project must be respectful and harassment-free.
Remember that communication is the lifeblood of any Open Source project. We are all working on this together, and we are all benefiting from this software.
It's very easy to misunderstand one another in asynchronous, text-based conversations. When in doubt, assume everyone has the best intentions.
If you feel anyone has violated our Code of Conduct, you should anonymously contact the team with our abuse report form.
Guidelines
How to contribute
Fork the project and clone it to your local machine.
Create a branch with your GitHub username and the ID of the issue, for example:
git checkout -b USERNAME/some-new-feature-1234
Code and commit your changes. Bonus points if you write a good commit message:
git commit -m 'Add some feature 1234'
Push to the branch:
git push -u origin USERNAME/some-new-feature-1234
Create a pull request for your branch.
Create an issue
Nobody's perfect. Something doesn't work? Something could be better? Check to see if the issue already exists, and if it does, leave a comment to get our attention! If the issue doesn't already exist, 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 reflect the discussion.
Please use inclusive language
Inclusion and respect are core tenets of our Code of Conduct. We expect thoughtful language all the way down to the code. Some technical metaphors are alienating or triggering. We ask that contributors go the extra mile to submit code which is inclusive in nature.
If you unintentionally use language deemed harmful, there is no shame. We will work together to find a better alternative. Being thoughtful about language also encourages more thoughtful code!
Create a pull request
Try to keep the pull requests small. A pull request should try its very best to address only a single concern.
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, reference to it by adding something like
References/Closes/Fixes/Resolves #123
, where123
is the issue number. More info here.All commits in a pull request will be squashed when merged.
Last updated