Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Conventions and Guidelines

Note: this page applies to contributing to AFNix itself, not to projects hosted by AFNix, which may operate under different rules and expectations.

Contributors to AFNix are encouraged to familiarize themselves with the following guidelines and conventions that the project follows. These are not strict rules, but going against these guidelines warrants careful consideration and should ideally be justified.

General Information

  • AFNix projects are hosted on git.afnix.fr/afnix.

  • Contributors should be familiar with the Code of Conduct as well as the AI Usage Policy.

  • We encourage most changes to get code reviewed by another contributor, but do not require it for experienced contributors that have been given write access to a repository. We still expect complex, controversial, or interesting changes to get reviewed - but small or time-sensitive changes can be pushed directly.

  • When a repository has CI enabled, passing CI is a requirement for changes to be merged. Exceptions can be made if justified due to e.g. flakiness, infrastructure issues, time sensitivity, etc.

  • Project discussions are to happen in the open, not in private messages or private chat rooms. This does not mean everyone should be listened to - we in fact explicitly discourage this, and the AFNix Zulip is designed to only allow contributors and/or trusted users to talk in work-focused channels.

Velocity / Agility

  • We optimize for quick decision making, not perfect and/or consensus-based decision making. If a decision can be rolled back later, we tend to accept the risk of taking the wrong decision and having to change our minds later. Strong opinions should be expressed, but preferences are just preferences - not everyone will agree on them, and it's ok to ignore them, especially when following them requires significant work (e.g. rewriting a change).

  • We favor doing something now over blocking something until later. Small improvements can wait and be sent later as followup commits (by the author or by a reviewer). Blocking a change on technical grounds should never be done without offering a clear way forward.

  • When possible, we try to avoid roundtrips. Nitpicks and/or requests for small fixes can be given along with an approval to merge. We trust each other and do not require everything to be double-checked. Conversely, an approval means that the author of a change should feel free to merge their changes; wasting reviewer time by requiring a re-review on a typo fix is not useful to anyone.

Infrastructure Access

Access to the AFNix infrastructure comes with additional requirements in order to properly safeguard user data. We aim to keep the access control list small, adding only contributors who commit to being active contributors and have a track record proving the quality of their work.

  • Only members of the AFNix Association can be granted infrastructure-level access.
  • Members with infrastructure-level access are to sign a confidentiality charter reminding them of rules surrounding data access and the consequences of violating said rules.
  • Access to infrastructure is granted on a temporary, renewable basis and will be regularly re-evaluated and withdrawn if unused.