55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
# Contribution Guidelines for Amsterdam
|
|
|
|
## Introduction
|
|
|
|
This document explains how to contribute changes to the Amsterdam project.
|
|
|
|
## Development Location
|
|
|
|
While you may have found this project on GitHub or another site, the "source of truth" for the project will always
|
|
reside on [the Erbosoft code hosting site](https://git.erbosoft.com/amy/amsterdam). This is to ensure long-term
|
|
independence from platforms controlled by third parties; the mirrors to GitHub and/or other sites are for visibility.
|
|
|
|
Serious contributors should contact Amy Bowersox (amy@erbosoft.com or via a contact method listed in
|
|
[her LinkStack](https://links.inclusiveladyship.com/@amy)) for access.
|
|
|
|
## AI Contribution Policy
|
|
|
|
AI contributions are allowed, but _must_ follow the policy set out in our [Code of Conduct](CODE-OF-CONDUCT.md). Failure to do so
|
|
will result in summary rejection of contributions and possible restriction of participation in the project.
|
|
|
|
## Contribution Workflow
|
|
|
|
1. [Open an issue](https://git.erbosoft.com/amy/amsterdam/issues/new) describing the problem or proposed feature.
|
|
2. Discuss the design with [maintainers](MAINTAINERS).
|
|
3. Submit a pull request referencing the issue.
|
|
4. Participate in code review.
|
|
|
|
## Versioning
|
|
|
|
Amsterdam employs [semantic versioning](https://semver.org/), with version numbers in the "major.minor.bugfix" format. Please see
|
|
the linked specification for further details.
|
|
|
|
## Git Branching
|
|
|
|
Amsterdam employs the [GitHub Flow](https://docs.github.com/en/get-started/using-github/github-flow) style of branch management.
|
|
|
|
One thing to remember: when working on a feature branch, and seeking to merge new changes from `main` into your branch, _never_ use `git merge`,
|
|
but _always_ use `git rebase` to rebase your feature branch off the tip of `main`. The rule to remember is, changes flowing "inward"
|
|
_from_ feature branches _to_ `main` use `git merge`, but changes flowing "outward" _from_ `main` _to_ feature branches use `git rebase`.
|
|
|
|
## Dependencies
|
|
|
|
Dependencies are managed using [Go Modules](https://go.dev/cmd/go/#hdr-Module_maintenance).
|
|
You can find more details in the [go mod documentation](https://go.dev/ref/mod) and the [Go Modules Wiki](https://github.com/golang/go/wiki/Modules).
|
|
|
|
Pull requests should only modify `go.mod` or `go.sum` where it is related to the change at hand, whether a bug fix or a new feature.
|
|
Apart from that, these files should only be modified by pull requests whose only purpose is to update dependencies.
|
|
|
|
## Copyright
|
|
|
|
New code files should use one of the standard headers found in the `docs/templates` folder. Examples exist for Go (also works with CSS),
|
|
HTML, Jet, and YAML (also works with SQL).
|
|
|
|
The copyright range should be updated when a file is modified in a year later than the current end of the range.
|