Skip to content

Contribution Guidelines

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

Atlas uses GitHub to manage everything. See the GitHub quick start guide first if you're unfamiliar with GitHub. Apart from how to use GitHub, this page tells you everything else.

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, a Playbook file (.apbx) used with AME Wizard. It contains all the various scripts, configurations, and more that Atlas applies to people's systems.

If you're unsure where to start, read AME's documentation for help.

Consider using virtualization software like VMWare Workstation or Hyper-V to test. You can use 7-Zip or the included src\playbook\local-build.cmd script to build your Playbook.

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 repository on how to get started contributing.

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 is when there is an urgent change, which team members might directly commit to the primary branch of a repository.

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. This marks your commits as Verified, indicating commits have not been forged by someone else.

Check out this detailed guide on setting up verified commits. You can install GPG (used for signing) in Windows with Scoop: scoop 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 are a commit message format that helps to make the commit history more readable and easier to navigate.

Example: feat: ✨ add fAllowFullControl