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-07 23:39:02 +00:00
date: 2024-05-07T23:39:00.653Z
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.
- The README should include a badge of who the repository is maintained by
2024-05-06 01:27:56 +00:00
- A CONTRIBUTING.
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
2024-05-07 23:39:02 +00:00
# Merging to main with bugs
There are a few reasonable expectations for merges, one is that any change that is made in the project should not include bugs except in extremely rare cases where bugs are unable to be fixed without upstream changes. In this case a bug should be added to the projects kanban board (or similar) with relevant information like the file & code section the bug is in and which upstream issue is causing the bug (if known).
