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:
How you can contribute
- Atlas Playbook - The Atlas playbook (
.apbx) that is used in AME Wizard (GPL-3.0) ( CoC)
- Refer to the AME Wizard Documentation for help
- You can also contribute to the
README.mdand its translations, which is the only exclusion for committing to the
- Atlas Utilities - General tools used in Atlas like
filepicker.exe, made in Rust (GPLv3)
- Atlas Documentation - The website that you are looking at (CC-BY-SA-4.0) ( CoC)
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, your pull request could be closed.
How it works
Each repository has a
dev branch and a
master branch for development.
Make all of your changes to the
dev branch of the respective repositories!
Never commit or pull request directly to the
main branches, with the only exception being committing to the
main branch on the main repository for translations.
dev branch exists to ensure that only approved and high-quality changes are merged into the
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
People with write access
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
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.
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 changed, 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 organised. 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.detailed guide on setting up verified commits.
Conventional Commits are a type of commit message format that helps to make the commit history more readable and easier to navigate.
feat: ✨ add fAllowFullControl