Campaign Monitor gratefully welcomes contributions from the open-source community.
Be respectful to one another and keep reviews of GitHub Pull Request (PR) on topic and always constructive 👍.
🙌 How to perform a good code review 🙌
-
Create a GitHub issue (make sure it doesn't exist already) and be as detailed as possible (screenshots are good), and label it appropriately. It's a good idea to wait a few days for some feedback before writing any code.
-
Fork the Shell repository, make your changes, then create a PR back to the Shell
master
branch for review. Your PR title should use the same title as its corresponding GitHub issue but prefixed with the issue number, e.g.:Issue 71: Add a new Helper to remove responsive images
In the PR description include:
This fixes #71.
Once the PR is merged (let's say the PR is number 72) then add the following in the corresponding GitHub issue:
Fixed in #72.
-
If suitable for a visual test then create a test, see here.
-
Make sure all Sass compiles:
cd test
grunt testShell
-
Test in all supported browsers, see here.
-
Passes linting:
cd
into the root of Shellgulp lint
-
Update
CHANGELOG.md
. The format is always:-
A H2 heading (
##
in markdown) for the version number plus the date. -
A list item for each update, each item describes the update and references the corresponding Github issue as a link within brackets at the end.
An example:
## 1.3.0 (May 25, 2016) * Added a new Helper to remove responsive images ([#71](https://github.com/campaignmonitor/shell/issues/71)). * Added PR/Issue templates within a `.github` folder ([#70](https://github.com/campaignmonitor/shell/issues/70)).
-
Some of the above tasks will eventually be automated by CI, see: #19.
Shell is written in Sass, which provides a lot of incredibly powerful features. However, Shell does not want to become a platform to showcase Sass' capabilities; all code that comes into Shell should be as simple and CSS-like as possible. In fact we plan to move away from Sass in the not so distant future and use PostCSS instead.