Thank you for helping ArchZFS provide ZFS packages for Arch Linux. Start by choosing the repository that controls the behavior you want to change. Small fixes are welcome; a PKGBUILD correction or documentation improvement is a fine first contribution.

• Use archzfs/archzfs for package templates, OpenZFS versions and hashes, kernel definitions, build logic, release workflows, and the production Pacman repository.
• Do not treat repositories such as zfs-utils, zfs-dkms, or zfs-linux* as independent sources. Their PKGBUILDs are generated from archzfs; propose the source change there unless a maintainer directs otherwise.
• Use archzfs/archzfs-keyring for key material and keyring tooling. Its local contribution guide takes precedence over this organization default.
• Use archzfs/archzfs-mirror for reusable mirror synchronization tooling.
• archzfs-testing is shared staging infrastructure for release-workflow changes, not the normal destination for user-facing fixes.

Search existing issues, pull requests, and Discussions before starting work. Discuss changes to release architecture, signing, trust, or shared staging infrastructure with maintainers before operating on those resources.

Follow the build and validation instructions in the target repository. Never include private signing material, access tokens, or other secrets, and coordinate with maintainers before publishing, signing, force-syncing, or deleting shared resources.

Keep commits focused. A pull request should briefly explain what changes, why it is useful, any relevant user or operational impact, the validation performed, and anything important that could not be tested.