2.7 KiB
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. 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) for access.
AI Contribution Policy
AI contributions are allowed, but must follow the policy set out in our Code of Conduct. Failure to do so will result in summary rejection of contributions and possible restriction of participation in the project.
Contribution Workflow
- Open an issue describing the problem or proposed feature.
- Discuss the design with maintainers.
- Submit a pull request referencing the issue.
- Participate in code review.
Versioning
Amsterdam employs semantic versioning, with version numbers in the "major.minor.bugfix" format. Please see the linked specification for further details.
Git Branching
Amsterdam employs the 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. You can find more details in the go mod documentation and the Go Modules Wiki.
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.