Skip to content

Latest commit

 

History

History
90 lines (65 loc) · 3.15 KB

CONTRIBUTING.md

File metadata and controls

90 lines (65 loc) · 3.15 KB

Contributing guidelines

Please take some time and review the contributing guidelines below. These should be followed when working with any projects in Shout It ecosystem.

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The term merge request and pull request are used interchangeably for the purposes of this document.

GitHub flow

We practice GitHub Flow to maintain a consistent workflow across all projects.

  1. Clone the project
  2. Create a feature branch based on the main branch
  3. Write and push your code
  4. Test, test, test
  5. Submit a merge request for your branch into the main branch

Creating issues

All code changes SHOULD start with an issue. When creating a new issue please use one of the predefined templates that best fits your request, if one isn't available please reach out to a project maintainer to request one. Please make sure to be as detailed as possible when filing an issue, so we don't have to track you down later for more information. When possible you should practice user stories and acceptance criteria to set clear requirements.

Remember, even if you aren't contributing code, opening feature requests, reporting bugs, or even just discussing ideas are all ways to make this project better.

Commit messages

We follow the Conventional Commit Specification with a few additional requirements.

<type>(<scope>): <subject>

<optional body>

<optional footer>

Additional Requirements:

  • Breaking changes must include a ! in the subject and BREAKING CHANGE: in the footer as described by the specification
  • The scope property MUST be set to the package being worked on, or left blank when working outside of packages

Merge requests

Every merge request should start with an issue, if you don't have an issue, you can't do much. When you open a merge request make sure to use an issue template when available.

If your merge request is created before it's complete, please make sure to flag it as a draft by putting Draft: at the start of the title.

Once your code is complete, the pipelines are passing, and it's ready for review, you should make sure to indicate this. You can do this by removing the Draft: flag if set, changing the label to Workflow::Needs Review and assigning a reviewer.

Code style

When working within our repositories you should do your best to ad-hear to our code style guidelines. By following these guidelines we can create clean, easy to maintain projects.