Culture

• The project’s goal is to joyfully improve the world through technology. Its greatest asset are its community and talent pool of primarily volunteer developers, and they must be protected.

• We explicitly design for mentoring and contributors growth.

  • Reviewers are teachers, and help new contributors with onboarding.
  • Not all occasional contributors necessarily want to grow into more active roles in the project, and that’s also okay.
  • Some contributors may be unfit for positions of increased responsibility, this does not necessarily make them unfit for contributing altogether.

• Institutional knowledge should be persisted in documentation, processes, and automation.

  • Getting into the project or a team should never require extensively asking around questions

• Our software is meant to build critical infrastructure, and we consider our own infrastructure as critical as well. Reliability and correctness are primary goals of our code, and not to be compromised on.

• We aim for a blameless culture, holding people accountable only to the extent of their responsibilities.

• We facilitate for reviewers not being around 100% of the time, without having to give up their opportunity to have input on changes.

• We recognize the need to improve accessibility on all levels, both in the software we write and in our social spaces

Community

• We are an independent community within the wider Nix and NixOS ecosystem. We are not under the umbrella of the NixOS foundation.

  • Many of us have a foot in both communities; we are not interested in software tribalism.
  • We choose to inherit all NixOS community bans, extending them into our community spaces.

• We aim to provide a safe space for people of all marginalized backgrounds.

  • We do not tolerate racism, sexism, ableism, transphobia, queerphobia, etc.

• We are free to decide who gets to be part of this community at our own discretion. This is a community, not a government.

  • We may deem people unfit or unsafe for this community based on their actions outside of our own spaces.

• We eagerly and preemptively moderate our community spaces. At the same time, we value talking to people and helping them improve.

  • All moderation actions are meant to protect the community, and never as punishment of individuals.

Code

• We strive to use tooling and automation as much as possible to save time for our developers.

  • Rote work and churn should always be minimized where possible.

• We value doing things properly. We prefer going the extra mile over quick hacks.

  • Cooperation with upstream projects should always be preferred over local patches.
  • We aspire to keep our code clean, readable and well documented. We especially value code comments as in-band documentation.

• We explicitly define our stability boundaries, and don’t shy away from making improvements through breaking changes while clearly communicating them.

  • There is no “implicit” stability of nominally unstable features through their momentum of usage.

• At scale, breakage on development branches is inevitable to happen. We strive to find an efficient balance between preventing breakages and managing regressions.

• We do not want to gatekeep the usage of unfree software, however its support is largely done on a “best-effort” basis. We acknowledge that unfree software is an unfortunate necessity of everyday life for many, but also that contributors may be reluctant to do effectively free work for corporations who do not share back.

Governance

• We want our discussions and decision making processes to be transparent and open. Constructive criticism is welcome.

• Every piece of code, documentation and infrastructure should be owned by someone, who if not responsible at least is responsive to issues and questions.

• We strive to have clear policies about what we prioritize when different approaches have conflicting benefits, and a clear process for applying those policies, so we don’t end up with changes deadlocked.

• We recognize that authority comes with responsibilities, and we strive to balance these.

  • We are mindful of concentrating responsibilities, because people only have so much bandwidth.

• Companies interact with the community through their individual employees as community members.

  • Community members in positions of responsibility should disclose their employers if there may be a conflict of interest.

Infrastructure

• We view self-hosting and dogfooding as explicit virtues.

  • We strive to not rely on cloud services wherever possible.

• We build infrastructure in a sustainable way, taking into account monetary and personal costs.

  • Getting sponsored resources is fine, but a plan B for that sponsorship going away is a must.

• Our infrastructure should be as open as possible, contributing to it should not require lots of special permissions.