-
Couldn't load subscription status.
- Fork 5
Pull Request Guidelines
(Credit where credit is due, this Pull Request Guidelines wiki page mostly comes from the extremely sensible, and informative, Yeoman.io Contribution Guide)
A Pull Request (PR) is the step where you submit patches to one of our repositories. To prevent any frustration, you should make sure to open an issue to discuss any new features before working on those features. This will prevent you from wasting time on a feature the core team doesn't see fit for the project scope and goals.
Once you've worked on a feature or a bug, it is then time to send a PR. Make sure to follow these steps along the way to make sure your patch lands as soon as possible!
Make sure your PR stays focused on a single feature. Don't change project configs or any files unrelated to the subject you're working. Open a single PR for each subject.
Checkout the project style guide, make sure your code is conformant and clean. Remove any debugging lines (debuggers, console.log).
Adding a feature? Make sure you add unit tests to support it.
Fixing a bug? Make sure you added a test reproducing the issue.
All our projects' unit tests can be run by typing yarn test at the root of the project. You may need to install dependencies like mocha, chai, or sinon.
In a large project, it is important to keep the git history clean and tidy. This helps to identify the causes of bugs and helps in identifying the best fixes.
Keeping the history clean means making one commit per feature. It also means squashing every fix you make on your branch after team review.
Write a convincing description of your PR and why we should land it.
It is important for us to keep the core code clean and consistent. This means we're pretty hard on code review!
Code reviews are the best way to improve ourselves as engineers. Don't take the reviews personally: they're there to help us improve.