For the most up-to-date guide, please see [matrixfurry.com/common](https://tangled.org/@matrixfurry.com/common/blob/main/CONTRIBUTING.md). Development happens on [Tangled](https://tangled.org/did:plc:zmjoeu3stwcn44647rhxa44o). # Developer Certificate of Origin By 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) # 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.