RFCSC Meeting 2025-05-12

Development RFCs
1

General business

Present in the meeting: @GetPsyched @infinisil @asymmetric

RFCSC process going forward

  • Maybe in addition to shrinking the RFCSC, we could make the RFCSC on-demand instead of holding bi-weekly meetings; the RFCSC can be pinged as and when needed:
    • To assign shepherds and shepherd leader
    • Resolve general conflicts
  • Waiting for the remaining RFCSC members to share their thoughts.

Unlabelled and New RFCs

None

RFCs Open for Nominations

None

RFCs in Discussion

RFCs in FCP

None

Leader of next meeting

@asymmetric will lead the next meeting on 2025-05-26

3 Likes
2

Okay, so of the three RFCs currently under discussion, I’m the author of one and the shepherd leader for another, and honestly I don’t know what I can/should be doing in either role to move them forward.

I’ve done the technical implementation work for both; it’s the part where the community comes together, offers feedback, and converges on a coherent opinion that doesn’t seem to be happening. I don’t know how to make that happen, and I don’t know what sort of metrics would need to be hit for that to be judged a success.

It’d be easy to say ‘the RFC process is broken’ but maybe it’s me? What should I be doing differently?

OTOH, if the RFC process is broken such that RFCs can’t currently advance, it doesn’t seem fair to move forward with the broken process and push those two RFCs back into draft.

3 Likes
3

Nah don’t blame yourself, you’re doing great work. I don’t think there’s anybody in particular to blame.

Personal generic RFC rant incoming…

I think as a community we’ve collectively realised that the RFC process really doesn’t work that well, I’ve (at least privately) complained about this for years. I believe one of the main reasons for the RFC process being created was to make substantial decisions that might have many differing opinions by assigning ad-hoc decision-makers (shepherds), especially when there’s no clear ownership (such as Nixpkgs). While nice in theory, in practice it leads to various problems:

  • The expectation to reach consensus in the discussion means shepherds aren’t very empowered, while having a lot of responsibility at the same time → burnout as discussions stretch out
  • This in turn discourages people to even nominate as shepherd in the first place, leaving only very few to go for it, if enough shepherds can be found at all (originally the RFCSC was meant to have a choice in picking shepherds!).
  • Shepherds being potentially distinct from actual code owners makes it unclear who’s actually authorative, especially if you just barely have enough shepherds to even get a shepherd team (where does the authority come from if any person is accepted as shepherd?)
  • Then you also get non-controversial decisions where barely any discussion is necessary, but you also can’t get enough shepherds just to make it move forward.

I think this all boils down to: We need clear ownership for everything. If I point to any official byte, everybody should be able to agree who can change it. And until recently, there was a big void in overall ownership, which is now filled with the Steering Committee: It acts as the fallback authority for any technical/social decisions, and can delegate/reclaim that authority as desired. Even if the SC isn’t being very visible, they’re handling various issues that might’ve required RFCs before.

While I still view RFC documents as incredibly useful, as well as broad community discussions around them, I’d want the decision power to be in the hands of a team with the appropriate authority, as affirmed via the SC (and if anybody doesn’t like what the SC does, cast your vote as such in the next election!).

Concretely, imo we should use something akin to Architectural Decision Records in the respective repos, therefore putting the repo owners in charge of deciding it by default. And if ownership is contended (e.g. Nixpkgs), we can propose to the SC to make a call by opening a PR to the org repo with a concrete proposal as to who should own what, to be approved/merged by the SC, or if you think it’s a more sensitive manner, in private.

@rhendric So, even more concretely for the Nix language change you’re proposing, I’d suggest just opening a PR to Nix with one of the patches that you think is best and the RFC document included. Of course this is probably going to run into the Nix team’s limited availability (would love for them to get more support), but it’s much closer to being implemented than if we pretend that the shepherds (none of which are Nix team members) will bring the RFC to conclusion in a satisfying manner.

9 Likes
4

I agree that it would likely help a lot if it was clear who’s responsible for what. One way to expedite and (up to some point) decentralizing allocation of ownership could be homesteading the noosphere.

We had that public discussion around governance and ownership multiple times now, and phrases like “whoever does the work is in charge”, “a maintainer is who stays around to clean up their own mess” seem to reflect a general sentiment along long-term contributors, and some of that has even made it into the official community values. So, what if we institutionalize that, with a strong emphasis on making ownership explicit and the rules behind that legible? It’s already an established culture around package maintenance, nix-community has the [maintainers= annotation, and it seems that for other components one barrier is the lack of obvious and predictable ways to obtain, express, and transfer ownership. The org repo and recent efforts to enable declarative permission management for GitHub resource is a strong move towards addressing that.

What if we just wrote all that down in a place that has many pointers to it? Something like:

Anyone can become owner of unmaintained official resources by assigning themselves as maintainer. This comes with personal responsibility for our collective success and reputation. Existing maintainers can accept new maintainers who share that responsibility. Ownership can be contested if maintainers violate community values, and withdrawn by ruling of the steering committee.

5 Likes