2024-05-05 21:22:32 +00:00
---
2024-05-06 01:28:57 +00:00
title: Project Standards
description:
2024-05-05 21:22:32 +00:00
published: true
2024-05-06 20:10:50 +00:00
date: 2024-05-06T20:10:49.577Z
2024-05-05 21:22:32 +00:00
tags:
editor: markdown
dateCreated: 2024-05-05T21:22:30.441Z
---
2024-05-06 01:28:20 +00:00
# Naming
2024-05-06 01:27:43 +00:00
All names, including but not limited to CI Actions, Respositories, and folder names inside the project, must follow lower-kebab-case except in cases where a program requires something else.
2024-05-06 01:20:04 +00:00
2024-05-06 01:28:20 +00:00
# Structure
2024-05-06 01:27:43 +00:00
All projects should provide:
2024-05-06 02:03:28 +00:00
- A devenv when applicable, preferably in the form of direnv.
2024-05-06 01:31:53 +00:00
- If devenv is applicable also provide a flake.lock
2024-05-06 01:27:43 +00:00
- A short summary of what the project does, as well as how to use the project in a top level README. md
- The README should include a badge of who the repository is maintained by
2024-05-06 01:27:56 +00:00
- A CONTRIBUTING. md file top level that tells people how to contribute to said project
2024-05-06 20:03:05 +00:00
- A top level LICENSE file or folder of which includes the License or Licenses used in the project
# Commit Messages
- First line of the commit message should be a short (< 50 chars ) description of the purpose of the commit
- First word should be one of: `feat:` for feature, `fix:` for bugfixes, or `break:` for breaking changes
2024-05-06 20:10:50 +00:00
- First line and main message should have 1 blank newline in between them for ease of reading
- Main messages
- **Features** should have a reason to include the feature, as well as an example of the feature in use (if applicable)
- **Fixes** should have what the original bug was, as well as a short summary of the steps that were required to fix it
- **Breaking Changes** should have what it breaks, how it breaks it, and a short transition guide