436 views
owned this note
# Nix Governance track
by Jonas Chevalier and Ron Efroni
> Open-source projects are a human entreprise, based on volunary participation.
In this track we will be exploring ways to better organize ourselves; how can we make the process more enjoyable and efficient.
## The process
In order to make this productive, here is the process that I propose we follow:
We have a list of topics to go over.
For each topic we have:
1. A short intro to set the context.
2. Ask the public to add possible solutions to the topic.
3. Pick interesting ideas to dig further.
4. Once the conversation has settled, record any consensus that has formed.
FIXME: Try to put your ego aside so we can explore the whole realm of possibilites before zooming on a particular idea.
My role is mainly to direct the conversation so that everybody can speak.
The conclusion will then be recorded and published on Discourse so that people that didn't get a chance to participate to NixCon can also have a say.
## Participating members
Here are some of us that already opted in for the chat. Everybody is welcome to participate.
* Jonas Chevalier (zimbatm) - Role: Lead
* Ron Efroni - Role: Co/lead
* Infinisil - Role: Note taking
* Raito - Role: co note taking
* Domen Kožar
* Linus Heckermann
* Tomberek
* fricklerhandwerk - Role: representing the documentation team
## Topics
### What are the reasons flakes are not stable yet?
Objective: Agree on a constructive statement that we can work on top of. The documentation team published a [brief summary of the status quo](https://nix.dev/concepts/flakes) that we could start off with.
How are decisions made for Nix changes and how are experiments carried out?
+1: @asymmetric
### What mechanisms do we use to make large decisions in the ecosystem?
+1: @infinisil, zimbatm
+ron
Using flakes as an example of what not to do :)
* RFC
* Community teams
### How does the Nix maintainer team deal with community feedback?
What is the direction of the Nix team?
There is a tension between the health of the codebase and adding new features.
### How do we make experiments in Nix?
Assuming that all these experiments are made with good intentions, they still turn out bad.
Can we clarify the process, in a quantitative way, before accepting new features?
Currently features are never removed, even when experimental. Also how to deal with sunk-cost fallacy? Should a timeout be added?
### When is something official?
+1: @infinisil @fricklerhandwerk @ron
see below! (last section)
### What do we make projects become official/unofficial?
+1: @fricklerhandwerk, @infinisil, @ron, @raitobezarius
same, last section
### How can we encourage a praxicracy?
+1: @ron
People should not limit their thinking to a team structure.
We want to minimize friction to make meaningful contributions.
### How can we allocate resources in a more predictable manner?
+1: @ron, @tomberek, @raitobezarius, @fricklerhandwerk, @asymmetric, @thufschmitt
- [ ] @ron and @fricklerhandwerk: Prepare draft proposal for discussion
- https://pad.lassul.us/CC3TJEG2S7G9rJxJ0wtWGQ#
Teams already work in principle, but need stable, sustainable funding for at least one person doing at least part-time ongoing work: accept contributions, take care of administrative tasks, keep coherence.
Need to supply those resources at the strategic level and allocate them according to an explicit agenda in a predictable manner. Have to align the ideas that are out there with the means to implement them and the people to do the work required.
Examples:
- Documentation team made significant progress with 5h/week leadership, 17kEUR of budget and countless volunteer hours
- Nixpkgs Architecure Team designed and implemented a large change within a year, essentially carried by @infinisil alone and supported by various volunteers
- Nix maintainers do part-time work to keep the pipeline running, but are clearly constrained with actually implementing things by neither having more time allocated nor a budget to spend
- Summer of Nix is capable of delivering tangible results with 90kEUR within a few months, having a proper set of goals and oversight and administrative support
### ryan's problems
+1: zimbatm
#### nixpkgs
* nixpkgs CI is a disaster
* Darwin Tier-2 but hard to debug
* no security tracker for nixpkgs
+1: @asymmetric (on all the points), @tomberek
#### infra
* infra team has no nixos email addresses
* no nextcloud to share files
=> missing strategic views
### Tom's proposal
Having an allocated budget for various teams is a way to have teams dependable / accountable.
Wants to add formal responsibility.
* Boards for strategic things
* Teams for tactical things
+1: @tomberek @fricklerhandwerk
### How can we diversify the community in terms of skillsets?
### Where is the line between the community and commercial entities?
+1: @fricklerhandwerk, @infinisil, @asymmetric, @domenkozar, @raitobezarius
=> Domen
One of the successes of the NixOS project is that we have a good relationship with commercial entities like Equinix Metal and Fastly that give us free resources. On the other hand, commercial interests don't necessarily align with ours.
* How can we make sure that companies feel welcome participating in the community?
* Where do we place the line when it's going too far?
* For example: we don't necessarily want to be plastered with ads. Or too dependent on one entity.
* Debian says "community first". What do we say?
* Who is calling the shots in the ecosystem?
* What are our values and incentives?
### Is the RFC process the right tool for community decisions? (zimbatm)
+1: @asymmetric, @tomberek, @domenkozar
Historically we switched from Eelco making all of the decisions, to having a RFC process to make far-reaching decisions collectively. Is the RFC process the right tool for all types of decisions or is it better suited only to a subset of those? And if so, what alternatives do we see?
### Large PRs
How can we better accompany large PRs, so that the contributors don't burn out?
Preparation: Please bring your own examples.
### Where is the line between perfection and getting things done?
This is a cultural issue that I see; not everybody agrees on how perfect some work should be.
Let's discuss the various aspects of this.
Preparation: Please bring your own examples.
### How can we empower people that want to do things?
+1: @thufschmitt, @ron, @tomberek, @raitobezarius
It's not always clear who to speak to when you want to do something.
What structures could we put in place to empower people, to maximize people's autonomy?
### How to communicate effectively what is an endorsed or actively supported piece of the platform/ecosystem
+1: @infinisil @fricklerhandwerk @thufschmitt @asymmetric, @tomberek, @raitobezarius, @domenkozar
- [ ] @fricklerhandwerk and @tomberek: prepare a draft for discussion
- https://pad.lassul.us/31op7LenTyGoZP_bNiEs-A
Beginners have a hard time to evaluate what they can rely on, while stability and maturity is one of the major reasons to choose Nix.
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
Preparation: Collect proposals for communication strategies or processes how to transition projects between different states of formal endorsement
---
Those topics were inspired by reading https://discourse.nixos.org/t/where-did-you-get-stuck-in-the-nix-ecosystem-tell-me-your-story/31415