Common documentation and files across my projects
matrixfurry.com
1For the most up-to-date guide, please see [matrixfurry.com/common](https://tangled.org/@matrixfurry.com/common/blob/main/CONTRIBUTING.md).
2
3Development happens on [Tangled](https://tangled.org/did:plc:zmjoeu3stwcn44647rhxa44o).
4
5# Developer Certificate of Origin
6By submitting code contributions as an individual or on behalf of a corporation to any directory in this repository, you agree to the [Developer Certificate of Origin](./legal/DCO.txt)
7
8# Reporting issues
9Yes, issues are contributions.
10
11First, look around in the opened and closed issues, someone might have reported the same issue.
12
13If 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.
14
15# Commit guidelines
16
17We follow a similar commit style to Tangled. Please keep your commits:
18- **atomic**: each commit should represent one logical change
19- **descriptive**: the commit message should clearly describe what the change does and why it's needed
20
21## Message format
22We 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.
23
24Notes:
25- Keep commits lowercased with no trailing period, following the Conventional Commits style.
26- Use the imperative mood in the summary line (e.g., "fix bug" not "fixed bug" or "fixes bug").
27- Try to keep the summary line under 72 characters.
28- Follow the same formatting for PR titles if filled manually.
29- Don't include unrelated changes in the same commit (keep commits atomic).
30- Avoid noisy commit messages like "wip" or "final fix".
31
32## Commit signing
33
34Commit signing is optional but highly recommended. Once you make your first signed commit, all future commits must be signed.
35
36Please see the [security policy](./security.md) for more information.
37
38## Submitting changes
39<!--TODO: Provide more documentation on how pull requests work on Tangled-->
40Opening a Pull Request on Tangled is the preferred contribution workflow.
41
42We 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).
43
44PRs 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.
45
46# "AI"-assisted contributions
47> 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.
48
49Contributions written largely with help of LLMs (Large Language Models), Generative AI, or similar systems are not welcome.
50
51These 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.
52
53This includes, but is not limited to:
54- Comments
55- Documentation
56- Code
57- Issues
58- Images, Videos, Audio, or other Assets
59
60Contributions should be largely authored by the people in the commit information, e.g. the `Committer`, `Author`, `Signed-off-by`, and `Co-authored-by` fields.
61
62If 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.
63
64# Security
65Please see the [security policy](./security.md)
66
67# Maintainers
68
69## Releases
70We use [Semantic Versioning](https://semver.org/) for our version numbers.
71
72Given a version number `MAJOR.MINOR.PATCH`, increment the:
73- `MAJOR` version when you make incompatible API changes
74- `MINOR` version when you add functionality in a backward compatible manner
75- `PATCH` version when you make backward compatible bug fixes
76
77Additional labels for pre-release and build metadata are available as extensions to the `MAJOR.MINOR.PATCH` format.