Rules

To keep consistency and readability throughout documentation, a few rules are enforced. Most of the rules are explained in The Linter documentation.

Local Testing

In addition, we also require local testing. This is important as testing your changes locally serves as a visual way of proofreading, which can help with readability, clarity, and consistency.

If needed, refer back to the Testing Locally documentation.

Pull Requests and Branches

Finally, this repository enforces a pull-request workflow instead of committing to main directly, by creating a new branch. All this means is that, in order for your changes to get pushed to the main website, it must be approved first. This ensures high quality documentation and is more akin to industry workflows.

It is also important to note that general convention is that you commit changes regularly on a branch. Do not have a giant commit. Rather, commit once a single “unit” or code is written. This helps keep commit history readable and helps if a revision or revert is needed.

Now that you know all the rules, move on to how to Push your Changes.

AI Policy

It is the firm belief of the programming team leadership that generative AI, while sometimes helpful, can be easily overused and end up creating slop that’s more damaging than helpful. Additionally, the process of writing documentation and explaining it to people helps build knowledge, understanding, communication skills, and looks better on a resume. Because of these reasons, writing documentation with generative AI is prohibited. It is acceptable to use generative AI as a research aid, or to assist in creating example code or graphs (it’s pretty good at mermaid). No text should be written by AI. At minimum, information gathered with the use of generative AI should be paraphrased after thoughtful review of what it’s actually telling you, as it is frequently wrong or misleading.

Author: Aiden Kimmerling https://github.com/TheKing349