NixCon Governance Workshop

fricklerhandwerk · September 11, 2023, 9:03am

NixCon Governance track: offical projects (discussion draft)

Goal

Beginners have a hard time to evaluate what they can rely on in the Nix ecosystem, while stability and maturity is one of the major reasons to choose Nix. The goal of this discussion is to decide on measures to significantly reduce the cognitive overhead for new and existing users.

There are many ways to approach this:

A branding policy that defines what’s “official”
Having dedicated code owners with clear authority, responsibilities, obligations
Recommending particular projects in documentation
Simply saying to figure it out for yourself because this is how it works

Open issue on the foundation board’s tracker:

decide what is an official project in the Nix ecosystem · Issue #39 · NixOS/foundation · GitHub

Proposal

Tiers

Mentioned (third party)

Code that works and solves a known problem

Endorsed (third party)

Significant user base
Software is usable and approachable
You don’t have to read the code to work with it

Recommended (community project)

Large user base
Maintained and accepting contributions

Official

Vital to the ecosystem
Actively developed by at least two people and with enough resources in the long run
High standards of code quality, collaboration, and documentation

The nix-community GitHub organisation can be an “incubator”, a staging area from which potential official projects can graduate.

Implementation

Decide on criteria
Define processes for state transitions
Determine responsibilities for implementing the policy
Take inventory
Update status of existing projects

Given this is a significant undertaking with substantial impact on outward perception of the ecosystem, we need a trusted community member with dedicated time to drive the design process and implement it.

We propose to install an Executive Director for the NixOS Foundation (following the example of the Haskell Foundation). A proposal for a similar role has been signed off by the board in February 2023. Add to the role’s responsibilities:

Creating a plan to be signed off by the board
Incremental implementation, communicating with project owners, maintainers, community, …
Driving the decision-making process on controversial items to conclusion

Examples

Make Home Manager official
- It is widely relied upon and actively maintained
Make NixOps a community project
- It has one maintainer but is not actively developed
Make Hydra third-party
- It is effectively unmaintained
Make the experimental installer a community project
- It’s actively developed but not widely agreed-upon
Make npm2nix a community project and archive it
- It’s unmaintained for years and should not pollute the top-level

General idea: The NixOS GitHub org should have at most a page worth of projects total that all clearly signal “this is what you should know and care about”. Everything else goes somewhere else.

Alternatives

Some other (e.g. more limited role) is created to implement the proposal
- We are short on trusted community members who can make new long-term commitments
The foundation board delegates subtasks to particular teams
- Teams are already busy with their own scope
- Team-leads would have to be empowered to make the necessary changes
- Still someone has to break down the full problem and see it through to the end
A new team is formed for this and similar purposes
- This has been discussed repeatedly in the past
- We are still short on trusted community members who can invest the amount of time required
- Teams tend to discuss a lot if no one is driving the process
The foundation board makes case-by-case decisions
- Infeasible due to time constraints. We recommend delegation.
Some combination of the above
- Example: the foundation executive develops a plan, runs a to revise it and sign it off, with the foundation board prepared to break ties, then delegates and supervises implementation by people responsible.

Next steps

The common part of the proposal and each alternative is that the foundation board needs to make a decision how to proceed. The board must:

Delegate to someone who is empowered to make the decisions and is expected to carry them out, and provide them with the necessary resources and permissions.
Clarify that the board will oversee the activity, serving as a final recourse.

This discussion draft was developed by @fricklerhandwerk and @tomberek, and proofread by @proofconstruction.

Conflict of interest disclosure: as above

2023-09-10 NixCon Governance Workshop Session #3

Lead: @ron
Participants: Chair circle, starting out with 8 people, ending up with 14
Notes: @fricklerhandwerk

Introduction

@fricklerhandwerk introducing the discussion draft

Questions and considerations

@garbas: Hydra is unmaintained but crucial
- @edolstra: it’s just not actively developed
- have to maintain it or figure out something for the future
- something that helps us maintain the cache, which is a common good, must be official
- definitely agree on having an “official” brand
  - certain projects may need some funding to make it happen though
- @janik: we should consider spending money on Hydra, refactoring or replacing it or whatever
  - we need to figure out a solution for the future
  - there are many companies who have their own Hydra clone because it’s untenable
@ron: we may want to minimise the number of tiers to keep it simple to figure out what goes where
- it’s not just about having maintainers, but also public image
- last year’s survey showed 50% had <3y experience, now we have 70%
  - new people should expect things to work as promised
Hippie Hacker: we use a tool called devstats that we use to gauge project health
- there is also more than just the person, also the release cycle
- is there a process, is there governance structure?
- we use: sandbox, incubated, graduaded, archived
  - graduation criteria
  - @fricklerhandwerk: that sounds very reasonable but looks like a lot of bureaucracy, we don’t have that degree of structure
- @adisbladis: we have nix-community that was originally intended for that, but no project has ever graduaded because there are no criteria
@garbas: we can learn a lot from the Rust community. they have a problem graduating things
- if a third-party project becomes very successful and the maintainer doesn’t want to put it under the brand, there will be tension
@ron: should also talk about de-officialising
@janik: what if more than one project does the same thing?
- e.g. sops-nix, agenix
- @ron: that’s what distinguishes open source from a company, we can’t necessarily choose one
- Hippie Hacker: we in fact fund multiple implementations to see how it goes
- @phaer: that should be part of onboarding to make reasonable overview and comparison
- @ron: this becomes a documentation challenge
@Mic92: NixOps is dead
- @adisbladis: on life support
- @edolstra: @roberth may disagree
- Hippie Hacker: we had etcd going down to one maintainer, and ended up having companies donating to maintain critical software
  - but it has taken 2 years to get back to 4 developers, only one of them having 5 years of experience with the project
- @garbas: the problem with NixOps is that there are a number of contenders, each very opinionated
- Hippie Hacker: have been thinking about Hydra
  - must figure out the surface area, what is there to take care of?
@garbas: who would want to write a CI?
- @janik: @lilly actually would, but doesn’t have time
- @fricklerhandwerk: how do we make sure it ends up replacing Hydra instead of ending up on the pile of good ideas
  - @brianmcgee: it has to be blessed
    - choice overload is a real problem for beginners
  - @tomberek: it also has to be used
    - needs a dry run before graduating
  - @adisbladis: we could launch it in the nix-community org as a testbed
@0x4A6F: we also have widely used community services such as @lassulus’ pad or the wiki, how would we integrate that?
- put it under the official domain or host it on foundation infrastructure
- @ron: good point, we had the same kind of issues with nix.dev
- @janik: the same goes for GitHub
  - comments on RFCs got obliterated when user accounts were disappeared
  - we should mirror everything we have to hedge against such things
- Hippie Hacker: there needs to be a working group to figure these things out, make decisions, and implement it
  - @ron: this ties into discussions we had about code ownership
@fricklerhandwerk: how do we determine the state transition? who decides?
- @bmg: could do it like the Apache Foundation, who have a process, but don’t know what that is

Proposals

@adisbladis: use nix-community org as a staging area
- @fricklerhandwerk: actually need to follow the rules once set up
- @tomberek: this is the role nix-community can serve and we want it to be, but we have to start and do it
@ron: ideally it would be an objectively verifiable checklist a workgroup could propose in an RFC
- @garbas: we should run a test with one project for each part of the process:
  - it should follow the structure of an RFC process
    - someone has to suggest it, someone to second it
      - should talk to the project author first; they should be one of those
  - @adisbladis: it can happen that project authors might not agree with making their project official
    - @phaer: there may be projects we want official but are not maintained
    - @tomberek: this came up in RFC 101, there is some precedence
@janik: projects that have to be demoted from official may even go outside of nix-community if they don’t fit the criteria
- @fricklerhandwerk: if there is no one to adopt them one can still archive them
@ron: need an initial working group to go through the process
- should start before formalising any roles
- @tomberek: yes, just get started and wait for veto
@fricklerhandwerk: the problem is not making design decisions, because we have enough people capable of doing this in a limited amount of time, but with implementing them
- a lot of these discussions really boil down to people having the time to make things
- @garbas: the person doing it should also decide what to do
  - @fricklerhandwerk: how to have them have more time?
  - @tomberek: teams needs their own budget
  - @ron: if proposals come in, and there are no alternative proposals and we have the funds, this is what we’re going to support
@tomberek: another approach is by delegation
- e.g. “hey infra team, we need that resolved”
- @janik: getting people on the infra team is difficult because they need access to secrets
  - also we’ve seen that the deployment process was broken for months
- the request should come from some governing body, so it can’t be ignored
@ron: volunteers for the working group?
- @0x4A6F: whoever is driving this would need permissions for both repositories
  - @ron: would like to remove the requirement of getting blessing every time. if you’re on that working group that means you have the power to decide things
    - unless there is some outcry of strong objections
  - @adisbladis: a working group will have the gravitas that people with permission will follow suit
@fricklerhandwerk: proposal to balance against the committee idea:
- one person drives the process and does the bulk of the work, including carrying out execution, getting feedback or conflict resolution by a group
- @garbas: how is this different from the RFC?
  - @tomberek: there are more decision-oriented and action-oriented RFC shepherd groups
    - this proposal is distinct from that though
@tomberek: there is the proposal for a community program manager to facilitate and implement such things
- @ron: convinced that would help a lot
  - this is largely a budget and bootstrap issue
- @janik: we can start fundraising with Open Collective and people can buy others the time to make things
  - @ron: this is how we ran the documentation project, but for eventually we need more like 500k-1M EUR overall
  - @janik: there is also NLnet grants
    - @ron: we should support people doing fundraising as well
    - @adisbladis: we should not focus on greenfield projects for the official parts though
  - @tomberek offers to support fundraising efforts
  - also Google Summer of Code for smaller projects
@ron: provide regular fundraising training or office hours
- can bring in professional fundraisers to share knowledge

Action items

@tomberek will write Discourse post with call to action
@tomberek and @fricklerhandwerk will compile a list of funding avenues for different types of projects
- find a place to publish that information
- provide contact details where people can ask for help and get mentoring