Skip to content

Contribution Guidelines

This page provides guidelines on how to contribute to Atlas. We highly appreciate your contributions!

Our contribution platform

Atlas uses GitHub to manage everything. Please note that our documentation does not contain instructions on how to use GitHub or Git; if you're unfamiliar with them, see the GitHub quick-start guide first.

Areas of contribution

A Code of Conduct applies to each Atlas repository. Please read this before contributing.

Atlas Playbook

GitHub Repository License (GPLv3) Releases

This repository contains Atlas' central source code, which is eventually packaged into a Playbook file (.apbx) used with AME Wizard. It contains all the various scripts, configurations, and more that Atlas applies to people's systems.

See the Playbook contribution guide on how to get started.

Atlas Documentation

GitHub Repository License (CC-BY-SA-4.0)

The website that you are looking at. We made the Atlas documentation in MkDocs Material, a documentation framework that uses markdown.

See the documentation contribution guide on how to get started.

How our GitHub Issues work

For transparency with users, we keep issues that affect the current release open and label them with the fixed next release.

How to make changes

Unsure if people like your change?

Consider proposing the change to people in the Discord or GitHub issues first.

Regardless, remember that it's okay to make mistakes. People will give feedback in your pull requests anyway; don't worry about it too much.

  1. Make a fork, or for team members, a branch in the repository
  2. Make your changes, then make a pull request to the primary branch of the repository
  3. Wait for at least two reviews, depending on the size of the change
    • For team members, we only require one review
  4. When it's merged, it will be squash-merged into the primary branch of the repository
    • This means all commits from the branch will be combined into one

The only exclusion to this system is for team members not using pull requests when there is an uncontroversial and well-tested change.

Formatting

Before a pull request, ensure that:

  • Your changes comply with the general formatting of a repository
  • There's a minimal amount of mistakes; check grammar and anything else important
    • For YAML changes, verify that they are valid using a linter

Commit Signature Verification

We highly recommend setting up commit signature verification. It marks your commits as Verified, indicating that someone else has not forged commits.

Check out this detailed guide on setting up verified commits.

Installing GPG/GnuPG (used for signing)

Use your distro's package manager to install GPG.

Conventional Commits

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

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

Example: feat: ✨ add fAllowFullControl

Extension for Visual Studio Code ->