feat: contributing to open commerce

docs/git-style-guide.md

@@ -0,0 +1,55 @@
+# Git Style Guide
+
+Git version control is how we work together as a team. Naming branches and writing commit messages helps us keep a easy-to-understand history of the changes in the project.
+
+## Naming Git branches
+
+Create a branch name, with the ID number of the GitHub issue, in the following style:
+`type-###-yourhandle-slug`. Example: `feat-123-impactmass-permissions`, `fix-222-spencern-shopify-hooks`
+
+## Writing commit messages
+
+Make atomic commits in the [Git commit message guidelines from Angular.js](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits), with a `(type):` followed by `subject`.
+
+All of the types:
+
+- _feat_: A new feature
+- _fix_: A bug fix
+- _docs_: Documentation only changes
+- _style_: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- _refactor_: A code change that neither fixes a bug nor adds a feature
+- _perf_: A code change that improves performance
+- _test_: Adding missing or correcting existing tests
+- _chore_: Changes to the build process or auxiliary tools and libraries such as documentation generation
+
+Note the following styles:
+
+- Use the imperative, present tense: use "change", not "changed" nor "changes"
+- Do not capitalize first letter
+- No dot (.) at the end
+- Use `BREAKING CHANGES:` to note breaking changes
+
+Examples:
+```sh
+    (feat): add sendEmail() job
+    (docs): add doc for sendEmailJob() method
+    (refactor): replace Blaze component with React component
+
+    BREAKING CHANGES: remove Header Blaze template. To migrate to the React component, use HeaderComponent.
+```
+See more [examples from Angular.js](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#heading=h.8sw072iehlhg).
+
+### Developer Certificate of Origin
+We use the [Developer Certificate of Origin (DCO)](https://developercertificate.org/) in lieu of a Contributor License Agreement for all contributions to Open Commerce open source projects. We request that contributors agree to the terms of the DCO and indicate that agreement by signing all commits made to Open Commerce projects by adding a line with your name and email address to every Git commit message contributed:
+```
+Signed-off-by: Jane Doe <[email protected]>
+```
+
+You can sign your commit automatically with Git by using `git commit -s` if you have your `user.name` and `user.email` set as part of your Git configuration.
+
+We ask that you use your real name (please no anonymous contributions or pseudonyms). By signing your commit you are 
+certifying that you have the right have the right to submit it under the open source license used by that particular Open Commerce project. You must use your real name (no pseudonyms or anonymous contributions are allowed.)
+
+We use the [Probot DCO GitHub app](https://github.com/apps/dco) to check for DCO signoffs of every commit.
+
+If you forget to sign your commits, the DCO bot will remind you and give you detailed instructions for how to amend your commits to add a signature.

guides/contributing-to-open-commerce.md

@@ -0,0 +1,75 @@
+## At A Glance
+
+At Mailchimp Open Commerce, we're dedicated to the open source community. In fact, we've designed our entire platform to grow from the passion and creativity that an open source community ignites. We've already attracted a small, dedicated team of open source contributors, and there's always room for more. If you'd like to join us, here's how to get started.
+
+## What you need
+
+Anyone can contribute, you just need a GitHub account, and the willingness to make the world a better place through open source.
+
+## Find or Open an Issue
+
+If we are talking about bugs, there are two places to start. Either find an existing open issue, or open a new issue. You can search issues by going to "Issues" on the appropriate repo and using the search box. Doing this is really critical as opening multiple issues for the same problem doesn't allow us to see that this issue is impacting multiple users which may change its priority.
+
+If you find that no one has opened an issue then you can create a new one. Be sure to fill out the entire issue template or your issue may be closed due to lack of information. Filling only the subject and none of the template almost guarantees that your issue will be closed immediately.
+
+If you want to add a new feature we also ask that you open an issue so that we have a clear understanding of what problem you are wanting to solve. Issues are great places to have discussions about implementation and approach whereas PRs are not.
+
+
+## Prepare a Pull Request
+
+**When at all possible avoid breaking changes without prior discussion or your PR will be kept on ice until a new major release is approved.**
+
+Make sure you branch off `trunk` to create your PR.
+
+**Use Git commit message conventions**
+
+You will need to follow the [Git Style guide](/developer/open-commerce/docs/git-style-guide/) for both your branch name and your commits. 
+We use the [semantic release](https://github. com/semantic-release/semantic-release) package to manage versioning so these commit messages are critical and not using the correct format will delay getting your PR merged.
+
+**Give your PR a good title**
+
+Make sure the PR title completely describes the new feature or bug fix.
+
+**Fill out the pull request template**
+Each of the items there is critical for us for to evaluate the code in your PR. If a section is completely irrelevant (e.g. Testing instructions for fixing a typo in the docs) just remove it.
+
+## Pass all tests
+
+We will never merge a PR that doesn't pass build checks and tests. You should be able to run most tests locally by just running `npm run test`. Typically we won't even begin the review process if tests do not pass.
+
+## Add a Changeset
+
+Open Commerce uses [changesets](https://github.com/changesets/changesets) to more intentionally manage versioning. 
+Changesets allow you to specify which plugins you want bump and how. Simply run `npx changeset` and follow the 
+onscreen instructions or read [the documentation](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md). 
+Changesets don't need to be created if the changes don't require bumping the package version (such as correcting a typo in a README)
+
+## Review Process Begins
+
+The team triages all new pull requests as soon as the PR is complete.
+
+**PR gets reviewed**
+
+The team reviews code quality rules including:
+
+  * **PR template**: If the PR doesn't follow our template, reject and point the author of the PR to this doc.
+  * **Issue description**: Use this information as the starting point for your review. If something is not clear, reject the PR and ask for clarity by requesting changes. While the original issue may have useful information, the PR should contain the most up to date representation of the issue.
+  * **Solution**: Use this information to help determine a path to test this PR. Research any included packages or techniques that may have been used that you're not familiar with. Ask questions if you're confused.
+  * **Breaking changes**: Test by applying this patch to an existing install of Open Commerce with existing users, orders, carts, etc. Specifically, test any parts of the app where the breaking change is involved and any data set that is involved in a migration.
+  * **Testing**: Run through the author's steps to verify that it works as they've tested it. Then run through the app on your own as you would test it. Run through the app as many times as you feel comfortable before approving or requesting changes.
+  * **Readability**: The linter will help with this, but call out anything that is difficult to understand or that you feel needs comments 
+  * **Documentation**: All code added or touched should have proper JSDoc, any new functionality should be documented, as outlined in JSDoc Style Guide. 
+  * **Security**: Code should only be usable by users with the correct permissions. Any data published should be filtered to ensure that only users with the correct permissions for the correct shops have access to it. Synk should not fail. Any failing automated tests should not be approved.
+  * **Performance**: Code should be written with performance in mind. Data publications should only publish data necessary to accomplish the specific goal at hand. 
+  * **Tests**: Any new functionality should include tests
+  * **Dependencies**: Any newly introduced dependencies should be updated to the latest version. 
+  * **Linting**: Pass all linting tests. If there are minor linting errors, the reviewer may fix them for speed.
+
+Reviewers will note any changes that they will want to QA in the app, even if they aren't listed in the testing steps (e.g. if the code changes a cart button, ensure that the button still works).
+
+
+## Congrats! It's approved. What happens next?
+The Open Commerce team reviewer is responsible for merging the PRs they approved, unless the PR submitter has 
+requested otherwise or marked at as draft.
+
+Now that your PR is merged and it's not a breaking change, the feature will be released in the next release.