📄
Guidelines
Before sending out your pull requests, make sure you followed this list.
We especially welcome contributions from people from groups underrepresented in free and open source software! 🏳️🌈.Our community aspires to be a respectful place, before proceeding please read and abide by our Code of Conduct.
Steps to follow before opening a pull request.
- Make sure your PR's description contains GitHub's special keyword references that automatically close the related issue when the PR is merged. (Check this for more info)
- Create a new branch for the ticket you are willing to work on, rather than working directly on
master. - Rebase your work onto the latest version from
masterand resolve any merge conflicts. - Check that only the relevant files are being changed, there should be no unintended changes to the schema or dependency files. 📄
- If you have added any external libraries through a package manager, ensure that you have updated the proper dependency list (
package.json) and corresponding lock file.
Steps to follow after opening a pull request.
- Check the
travis-cicontinuous integration build once it completes. This usually takes about 10 minutes ⏱, and if any tests fail you can find details in the build log. - If you don't get reviewer feedback in couple of days ⏱, or you're waiting for followup, ping someone.
Do, we have to follow any code conventions?
Do, we have to write unit tests for every new feature we add?
Ideally, pull requests should include new tests for any new features, as well, but it is an optional requirement.
Do, we have our own design system?
We do, to keep our designs consistent, we have created UI kit that contain many of our commonly used styles. http://www.ignitus.org/interface, please use
buttons, typography, colors, navigation components etc. defined in the design-kit. if you are building a whole new section, try to divide that into atoms, molecules, etc and add them in the design kit and use it from there.
Last modified 1yr ago