From a226f7d9eb9c8c3e1b919c3ef1dbcbcaa82b74eb Mon Sep 17 00:00:00 2001 From: "@matrixfurry.com" Date: Fri, 17 Oct 2025 02:32:24 -0500 Subject: [PATCH] Add contributing guidelines Signed-off-by: @matrixfurry.com --- CONTRIBUTING.md | 73 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..6e6954e --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,73 @@ +# Contributing guide +Development happens on [Tangled](https://tangled.org/did:plc:zmjoeu3stwcn44647rhxa44o). + +# Reporting issues +Yes, issues are contributions. + +First, look around in the opened and closed issues, someone might have reported the same issue. + +If you're not sure an issue is the same or not, especially an older closed issue, open a new issue and mention that you suspect it could be related. + +# Commit guidelines + +We follow a similar commit style to Tangled. Please keep your commits: +- **atomic**: each commit should represent one logical change +- **descriptive**: the commit message should clearly describe what the change does and why it's needed + +## Message format +We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) guidelines for commit messages. At present, it's not strictly enforced, but is preferred. + +Notes: +- Keep commits lowercased with no trailing period, following the Conventional Commits style. +- Use the imperative mood in the summary line (e.g., "fix bug" not "fixed bug" or "fixes bug"). +- Try to keep the summary line under 72 characters. +- Follow the same formatting for PR titles if filled manually. +- Don't include unrelated changes in the same commit (keep commits atomic). +- Avoid noisy commit messages like "wip" or "final fix". + +## Commit signing + +Commit signing is optional but highly recommended. Once you make your first signed commit, all future commits must be signed. + +Please see the [security policy](./SECURITY.md) for more information. + +## Submitting changes + +Opening a Pull Request on Tangled is the preferred contribution workflow. + +We reccomend using [Jujutsu](https://github.com/jj-vcs/jj) if you're comfortable with it. This way you can take advantage of Tangled's [stacked PRs](https://blog.tangled.org/stacking). + +PRs get merged "as-is" (fast-forward) -- like applying a patch-series using `git am`. At present, there is no squashing -- so please author your commits as they would appear on `main`, following the above guidelines. Rewrite history before submitting if necessary. + +# "AI"-assisted contributions +> NOTE: Using pre-existing boilerplate, snippets, or syntax suggestions from your IDE or standard Language Server are not considered AI-assisted changes. You're welcome to use those features. + +Contributions written largely with help of LLMs (Large Language Models), Generative AI, or similar systems are not welcome. + +These systems are generally using statistical models built on content acquired without the author's consent, and with disregard of the content's license and attribution. They also consume a huge amount of energy, and have a very large impact on the environment. + +This includes, but is not limited to: +- Comments +- Documentation +- Code +- Issues +- Images, Videos, Audio, or other Assets + +Contributions should be largely authored by the people in the commit information, e.g. the `Committer`, `Author`, `Signed-off-by`, and `Co-authored-by` fields. + +If you are unsure, or you had help from automated AI-generation in part of your contribution, please tell us when contributing. It does not mean the contribution will be rejected outright. We will evaluate on a case-by-case basis. We value honesty, and take it into consideration. + +# Security +Please see the [security policy](./SECURITY.md) + +# Maintainers + +## Releases +We use [Semantic Versioning](https://semver.org/) for our version numbers. + +Given a version number `MAJOR.MINOR.PATCH`, increment the: +- `MAJOR` version when you make incompatible API changes +- `MINOR` version when you add functionality in a backward compatible manner +- `PATCH` version when you make backward compatible bug fixes + +Additional labels for pre-release and build metadata are available as extensions to the `MAJOR.MINOR.PATCH` format. -- 2.51.2