From ef1726b4fb01d5bcb055abd3c9c625ffb96a6ebf Mon Sep 17 00:00:00 2001 From: ccgargantua Date: Wed, 11 Feb 2026 09:20:24 -0500 Subject: [PATCH] Added details for tagging and branching --- .vscode/ltex.dictionary.en-US.txt | 1 + .vscode/ltex.hiddenFalsePositives.en-US.txt | 1 + doc/CONTRIBUTING.md | 36 ++++++++++++++++++--- 3 files changed, 34 insertions(+), 4 deletions(-) create mode 100644 .vscode/ltex.dictionary.en-US.txt create mode 100644 .vscode/ltex.hiddenFalsePositives.en-US.txt diff --git a/.vscode/ltex.dictionary.en-US.txt b/.vscode/ltex.dictionary.en-US.txt new file mode 100644 index 0000000..7a8088a --- /dev/null +++ b/.vscode/ltex.dictionary.en-US.txt @@ -0,0 +1 @@ +ASEI diff --git a/.vscode/ltex.hiddenFalsePositives.en-US.txt b/.vscode/ltex.hiddenFalsePositives.en-US.txt new file mode 100644 index 0000000..d53ff19 --- /dev/null +++ b/.vscode/ltex.hiddenFalsePositives.en-US.txt @@ -0,0 +1 @@ +{"rule":"ENGLISH_WORD_REPEAT_BEGINNING_RULE","sentence":"^\\QMust directly address an issue.\\E$"} diff --git a/doc/CONTRIBUTING.md b/doc/CONTRIBUTING.md index 653b7ad..e953a88 100644 --- a/doc/CONTRIBUTING.md +++ b/doc/CONTRIBUTING.md @@ -2,12 +2,16 @@ ## Issues +### External Contributions Must Address an Issue + +If you are not internal to ASEI, your contribution must address an existing issue. If what you are hoping to contribute does not have an existing issue, then you are welcome to open an issue in accordance with the rules outlined below. + ### Labelling Issues must be labelled as one of the following: * `bug` for bug reports. * `enhancement` for feature requests or improvement to existing code. -* `documentation` for requesting new documenation or changes to existing documenation. +* `documentation` for requesting new documentation or changes to existing documentation. ### Bug Reports @@ -21,6 +25,30 @@ Bug reports **must** provide: * Browser (if applicable). * Minimal required steps to reproduce the issue. +## Branching + +ASEI uses [Trunk Based Development](https://trunkbaseddevelopment.com/) for branching strategy in our VC. + +### The `main` Branch + +The `main` branch is reserved for the most up-to-date version of the code. If anybody wants a rolling release, they grab the software from the `main` branch. + +### Development Branches + +All work is done in ephemeral branches known as development branches. All development branches should be prefixed with one of the following: + +* `bugfix/` for bug reports. +* `feature/` for new features. +* `enhancement/` for improvement to existing code. +* `documentation/` for new documentation or changes to existing documentation. + +### Tagging + +Tags in development branches should not be included in a PR to `main`. + +Tags in `main` should follow every single pull request in accordance with [semantic versioning](https://semver.org/). In short, this takes the form of vX.Y.Z where X is incremented with the introduction of MAJOR changes, Y is incremented with MINOR changes, and Z is incremented with PATCHED changes. + +For example, a software at version v1.0.0 gets a bugfix. It would then be v1.0.1. If it got a new feature, it would be v1.1.0. Note how the patch digit resets to 0. After so many MINOR increments (say, v1.12.0), you may decide it's now in a state that warrants a new MAJOR increment. This would now change to v2.0.0. ## Pull Requests @@ -29,14 +57,14 @@ Bug reports **must** provide: In most cases, pull requests must fulfill the requirements described below in order to be considered by ASEI reviewers. * Must pass all automated tests. -* Must follow code style of the relevant exisitng codebase. +* Must follow code style of the relevant existing codebase. * Must directly address an issue. ### Title The title must be in the format "[Label]: [Brief heading]" where `[Label]` is one of the main labels discussed in the [labelling section under Issues](#labelling). Examples: -* Enhancement: Updated touchpanel driver code with debug flags +* Enhancement: Updated touch panel driver code with debug flags * Bugfix: Fixed button misalignment in settings menu UI * Documentation: Added documenation for fuzzing tests @@ -55,6 +83,6 @@ If there is nothing to be said for one of the above sections, leave the heading If you are a community contributor, disregard. If you are a verified reviewer within the organization, this section applies to you. Before merging a PR, ensure that: * All pipelines pass successfully or, in relevant cases, are re-written to run successfully. -* You have thoroughly reviewed every single change made within the PR and verified that nothing is implemented poorly or outside of the required code style. +* You have thoroughly reviewed every single change made within the PR and verified that nothing is implemented poorly or outside the required code style. * The PR directly addresses an open issue. * If AI is used in the contribution, that the contributor has made a genuine effort in their contribution and has not just mindlessly hacked AI slop into production code. While AI is fine if used correctly, lazy contributions are **unacceptable**.