Skip to content

Contribution Guidelines

This page provides guidelines on how to contribute to Atlas. All contributions are much appreciated!

Atlas uses Git to manage everything on the platform GitHub. To more easily interact with Git, you can use:

Alternatively, you can use the Git command-line. Use whichever Git interface you find most familiar and easiest. Before contributing, you should research about Git first.

How you can contribute

These are the three main repositories to contribute to. There might also may be other repositories that fits your expertise. Check out our GitHub organisation.

If a repository has a specified template for pull requests or issues, please use them. Otherwise, the maintainers reserve the right to close and lock your issue without further response.

How it works

Each repository has a dev branch and a main or master branch for development.

Warning

Make all of your changes to the dev branch of the respective repositories!

Never commit or pull request directly to the main branches.

The dev branch exists to ensure that only approved and high-quality changes are merged into the main branch.

A pull request every week will be automatically created to merge the dev branch into the main branch, where the changes can be properly reviewed by 5 contributors before the pull request is merged. The only exclusion to having less than 5 reviews is if there's not enough people reviewing, e.g. 4 reviews for documentation.

This ensures that all changes are thoroughly reviewed and agreed upon collectively, resulting in fewer bugs, improved code quality, and a more organized development process.

You will have to make your own fork of the respective Atlas repository, and then make a pull request to merge your modified fork's branch into the dev branch.

People with write access

Note

This only applies to people with direct access to commit to the repositories, without the need to do a pull request.

This list is from our GitHub organisation's member list.

For any significant changes, consider creating a pull request for the dev branch instead of committing directly.

This means less potential headache in the future if the change is disagreed upon, as you can avoid reverting all of the disliked changes for the automatic pull request every week.

If you want to, you can also manually trigger the automatic pull request to merge dev into main early, but the 5 reviews will still be in effect. As a note, if you need to urgently fix something, you can use the bypass label to bypass your pull request being automatically closed by the pull request filter.

For regular pull requests, you can make your own branch in the Atlas repository or make a fork, it is your choice.

Formatting

Before each commit, ensure that:

  • Your changes comply with the overall formatting of a repository
  • There are the most minimal amount of mistakes, check grammar and anything else important
    • For any YAML change, please verify that it is valid before committing with YAML Lint.
  • People would generally agree with the change

Making sure that your commits are already to a high standard means that development will be faster and more organized. However, keep in mind that it's okay to make mistakes sometimes, as people will give feedback/reviews in your pull requests, so don't worry about it too much.

Commit Signature Verification

We highly recommend setting up commit signature verification. This marks your commits as 'Verified', indicating they come from a trusted source.

You can install GPG (used for signing) in Windows with Scoop with the following command: 

scoop install gpg
Check out this detailed guide on setting up verified commits.

Conventional Commits

We recommend using Conventional Commits in Atlas repositories for consistency and more descriptive commits. You can also take a look at Angular's Conventional Commits for more guidance.

Conventional Commits are a type of commit message format that helps to make the commit history more readable and easier to navigate.

Example: feat: ✨ add fAllowFullControl