Contributing

To contribute you should read through our guidelines to make it easier to get pull requests approved.

The following specific topics are important:

Notifications

GitHub only notifies you about repositories you explicitly watch, and new repositories appear in the organization regularly, so your subscriptions drift out of date on their own. Reconcile them in one command:

git clone git@github.com:Cratis/Automation.git
cd Automation/Source/GitHub
./gh-subscribe.sh

It watches every repository in the organization, mutes archived repositories and forks, and follows organization members. It is idempotent, so run it again whenever new repositories show up. You do not have to be an organization member — non-members get the public repositories and public member list.

Turning on email delivery is a separate manual step. GitHub exposes no API for delivery preferences, so watching everything still only fills the web inbox until you tick the Email boxes under notification settings. The full recipe, including that step, is in the notifications guide in the Automation repository.

Size

Contributions, be it features or bug fixes should be small and digestible. The contribution will be reviewed before it can be accepted and the smaller it is, the faster it will be reviewed.

Branches

The main branch represents what is in production. When contributing, do so by creating a branch adhering to the following naming conventions:

feature/[name of feature]
fix/[name of fix]
chore/[chore description]

Branches are to be deleted once merged into main branch. There should be no long living branches other than main.

Note: If you’re not a member of the team, you’ll have to do a fork first. Public repositories have a different target audience and commitment to strong semantic versioning. This manifests itself in having branches that when there are breaking changes/major version releases, what goes into the release has to be more coordinated. This then results in long lived branches representing the specific target version. Branches are made from this and merged into the version branch. The version branch is then used as a pull request to main.

Pull Requests

All contributions to both private and public repositories are done through pull requests to the repository you’re contributing to. Anyone reviewing will keep in mind the guidelines described here.

General

Pull requests will run automated checks for verification, these typically include:

Static code analysis
Build
Automated tests

If all of the verifications steps pass, the code will be reviewed.

Versioning

A contribution can trigger a versioned release. The versioning is adhering to semantic versioning version 2 and leveraging our own release action for this. That means that the pull request will have to be labeled with what version change it constitutes:

Name	Description
Major	Breaking changes has been implemented in public APIs and/or behavior
Minor	New capabilities has been added
Patch	Bug fixes

If none of these labels are present, it isn’t considered to be a release.

The repositories are configured with the pull request template that will guide you through what to fill in.