New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0036] Improving the RFC process #36

Open
wants to merge 8 commits into
base: master
from

Conversation

@globin
Member

globin commented Nov 22, 2018

Rendered RFC

This is the result of the discussion at the hackday at NixCon 2018.

Thanks to @grahamc for co-authoring it, @WilliButz mainly for the illustrations, but also sanity-checking and proof-reading, @Ekleog for the previous PR(#18) trying to improve the process and working with us on this RFC
Also @zimbatm, @domenkozar, @fpletz, @edolstra, @shlevy, @garbas, @Mic92, @flokli

Implementation PR will follow ASAP

0036-rfc-process-team-amendment: draft
Co-authored-by: Graham Christensen <graham@grahamc.com>
Show resolved Hide resolved rfcs/0036-rfc-process-team-amendment.md Outdated
Show resolved Hide resolved rfcs/0036-rfc-process-team-amendment.md Outdated
Show resolved Hide resolved rfcs/0036-rfc-process-team-amendment.md Outdated
0036-rfc-process-team-amendment: clarifications
Co-Authored-By: globin <mail@glob.in>
@grahamc

This comment has been minimized.

Member

grahamc commented Nov 22, 2018

I propose we manage this RFC under the process suggested by this RFC.

@7c6f434c

This comment has been minimized.

Member

7c6f434c commented Nov 22, 2018

I have a feeling that in some cases a non-biased Shepherd team has a risk of not being able to reach unanimity. SC stepping in might not have a consensus about the outcome either. Should this be explicitly mentioned as grounds for an explicit «postpone» decision?

doing its work the Steering Committee shall encourage them or step in and assign
new Shepherds. They also are in charge of merging accepted and rejected RFCs.
Generally by these expectations they should find time to meet once a week for
about an hour.

This comment has been minimized.

@grahamc

grahamc Nov 22, 2018

Member

I think we should add a paragraph about how to handle replacing members of the steering committee, in case they're not able to participate in the meetings. This would, ideally, include guidelines on when to replace members: for example, if they stop showing up.

This comment has been minimized.

@shlevy

shlevy Nov 22, 2018

Member

Agreed. We should flesh out future work to include more steering team policies beyond just how its members are decided.

@zimbatm

Nice work! Happy to see this moving forward.

Show resolved Hide resolved rfcs/0036-rfc-process-team-amendment.md Outdated
Show resolved Hide resolved rfcs/0036-rfc-process-team-amendment.md
Show resolved Hide resolved rfcs/0036-rfc-process-team-amendment.md
Show resolved Hide resolved rfcs/0036-rfc-process-team-amendment.md Outdated
@shlevy

This comment was marked as resolved.

Member

shlevy commented Nov 22, 2018

I propose we manage this RFC under the process suggested by this RFC.

👍 let's do it!

So I guess the first thing is: Nominations are open for the shepherding team for this RFC. So if you think you know someone (possibly yourself) who should be primarily driving and responsible for the outcome of this RFC, make a note here!

@edolstra @domenkozar @Mic92 @globin I'll reach out separately to coordinate an initial meeting of the steering team with respect to this RFC.

@domenkozar

This comment was marked as resolved.

Member

domenkozar commented Nov 22, 2018

I propose @zimbatm since he gets stuff done :)

@shlevy

This comment was marked as resolved.

Member

shlevy commented Nov 22, 2018

I nominate @edolstra as a shepherd, if he has bandwidth.

@shlevy

This comment was marked as resolved.

Member

shlevy commented Nov 22, 2018

I have a feeling that in some cases a non-biased Shepherd team has a risk of not being able to reach unanimity. SC stepping in might not have a consensus about the outcome either. Should this be explicitly mentioned as grounds for an explicit «postpone» decision?

I think this is potentially one of the roles of the shepherd leader.

@7c6f434c

This comment was marked as resolved.

Member

7c6f434c commented Nov 22, 2018

I have a feeling that in some cases a non-biased Shepherd team has a risk of not being able to reach unanimity. SC stepping in might not have a consensus about the outcome either. Should this be explicitly mentioned as grounds for an explicit «postpone» decision?

I think this is potentially one of the roles of the shepherd leader.

As RFC is written right now, Shepherd Committee Leader is responsible for making sure the process is not neglected, and the process calls for unanimity of FCP declaration.

I would expect that if the Shepherd Leader is responsible for tie-breaking, it might be clear in advance (the RFCs often appear after a few less formal discussions) for every reasonable nominee what is the likely final decision. In a way this is probably a worse policy, because we might not want the Steering Committee to be in a situation where they need to (de facto) pre-determine the outcome unanimously — that work is supposed to be offloaded to the specific Shepherd Committee.

@shlevy

This comment was marked as resolved.

Member

shlevy commented Nov 22, 2018

I have a feeling that in some cases a non-biased Shepherd team has a risk of not being able to reach unanimity. SC stepping in might not have a consensus about the outcome either. Should this be explicitly mentioned as grounds for an explicit «postpone» decision?

I think this is potentially one of the roles of the shepherd leader.

As RFC is written right now, Shepherd Committee Leader is responsible for making sure the process is not neglected, and the process calls for unanimity of FCP declaration.

I would expect that if the Shepherd Leader is responsible for tie-breaking, it might be clear in advance (the RFCs often appear after a few less formal discussions) for every reasonable nominee what is the likely final decision. In a way this is probably a worse policy, because we might not want the Steering Committee to be in a situation where they need to (de facto) pre-determine the outcome unanimously — that work is supposed to be offloaded to the specific Shepherd Committee.

Yeah, that's a fair point. I'm generally of the inclination that we should avoid front-loading process decisions as much as possible... If we're treating the steering team as having meta-responsibility for ensuring this process works maybe we should just leave it open for them to step in and make necessary callls (and propose necessary formal adjustments) if the process is not meeting its intended outcomes?

@7c6f434c

This comment has been minimized.

Member

7c6f434c commented Nov 22, 2018

@shlevy

This comment has been minimized.

Member

shlevy commented Nov 22, 2018

I'm generally of the inclination that we should avoid front-loading process decisions as much as possible... If we're treating the steering team as having meta-responsibility for ensuring this process works maybe we should just leave it open for them to step in and make necessary callls (and propose necessary formal adjustments) if the process is not meeting its intended outcomes?
I think when the process has a clear potential for a deadlock, it is good both to create more chances to avoid the deadlock after discussion, and to prepare a clear path of recognition of a deadlock. After all, we already know we are bad at this recognition.

Fair. Can you recommend a specific patch?

a summary comment trying to lay out the current state of the discussion
and major tradeoffs/points of disagreement.
* Before actually entering FCP, all members of the RFC Shepherd Team must
sign off the motion.

This comment has been minimized.

@7c6f434c

7c6f434c Nov 22, 2018

Member

Maybe add something like:

«
If the Shepherd Committee reaches unanimous agreement that the discussion is not producing new major substantial points, but cannot reach unanimous agreement about the disposition, it is normally advised that an FCP motion of postponing the RFC due to unresolved disagreement is proposed. It can be adopted by unanimous agreement of either the Shepherd committee or the Steering Committee.
»

closed. However, sometimes substantial new arguments or ideas are raised, the
FCP is canceled, and the RFC goes back into development mode.
12. In case of acceptance, the RFC Steering Committee merges the PR into the
`accepted`, in case of rejection into the `rejected` directory.

This comment has been minimized.

@7c6f434c

7c6f434c Nov 22, 2018

Member

What happens in case of postponing?

Maybe in case of postponing all the active participants of the discussion (including the authors and the Shepherd Committee) are encouraged to share if there is any example of evidence that would surprise them and decrease their confidence in the current position?

@7c6f434c

This comment was marked as resolved.

Member

7c6f434c commented Nov 22, 2018

Fair. Can you recommend a specific patch?

Commented inline.

@edolstra

This comment has been minimized.

Member

edolstra commented Nov 22, 2018

A slightly parenthetical issue (but relevant since we should avoid having too much bureaucracy) is whether the nix-core team (https://github.com/NixOS/rfcs/blob/master/rfcs/0025-nix-core-team.md) is still necessary under the new RFC process. Its main purpose was evaluating Nix changes and getting proposals unstuck, but that's also covered by this PR.

@globin

This comment was marked as resolved.

Member

globin commented Nov 23, 2018

I'd like to additionally propose @Ekleog and @samueldr as Shepherds.

@oxij

This comment has been minimized.

oxij commented Nov 24, 2018

@7c6f434c

This comment has been minimized.

Member

7c6f434c commented Nov 24, 2018

There are some subtle changes that might change the outcome. We learn more by trying smaller steps than by changing everything then finding out it also doesn't work.

(Your points about Discourse — I guess I should create a Discourse thread about the parts where there is a hope to improve things)

@globin globin referenced this pull request Nov 26, 2018

Merged

Call for Content: 2018/13 #71

globin added some commits Nov 29, 2018

@globin

This comment has been minimized.

Member

globin commented Nov 29, 2018

I've just reworked some parts, mostly in order to clarify (non-)responsibilities and add a few points that were brought up in the discussion. I think I've succeeded to keep the spirit and idea that was the result from the discussions at NixCon, objections are welcome as always!

I'm not sure I want to expand too much on "stalled discussions" in the RFC. I firmly believe that due to there being 3-4 people per RFC whose job it is to make sure progress is made in the discussion and a team that supervises that happens, a too controversial RFC will not stall but rather be improved on until it either it gets accepted or it gets rejected for not being feasible at that point in time. Obviously circumstances can change and a similar RFC be opened at a later point in time with more chances of being accepted.

@globin

This comment was marked as resolved.

Member

globin commented Nov 29, 2018

In further news, @zimbatm, @Ekleog, @samueldr, have accepted their nominations. Is there anyone else interested in shepherding this RFC?

We will be meeting tomorrow at 1600UTC, so please shout out your name (or your nominee's) until then!

The resposibility of the team is to guide the discussion as long as it is
constructive, new points are brought up and the RFC is iterated on and from time
to time summarise the current state of discussion. If this is the case no longer,
then the Shepherd Team shall step in with a motion for FCP.

This comment has been minimized.

@7c6f434c

7c6f434c Nov 29, 2018

Member

Is the main decision point accept/reject the FCP motion disposition? Maybe it would be a good idea then to add that the Shepherd Team also has to unanimously decide, after studying all the points raised during the discussion, whether to recommend accepting the RFC?

@7c6f434c

This comment has been minimized.

Member

7c6f434c commented Nov 29, 2018

Re: "stalled discussion" — I think there are situations where failure to reach unanimity even in a group of three-four people with diverse points of views is a real risk; if there is no such risk, things usually get decided even without an RFC…

@Ekleog

This comment has been minimized.

Member

Ekleog commented Nov 30, 2018

Just had an idea coming from the Rust process: experimental RFCs. These are RFCs accepted on a “let's try this” basis. In Rust this is technically enforced by not allowing stabilization of those without another RFC to validate them. In Nixpkgs, it could be “we'll try this but promise nothing about whether it stays in”. I'm thinking it could be useful for things like “Support <arch>”, where we might want to say “OK let's try, but not promise anything”.

I'm not totally sure whether this should get in this RFC or in a separate one, though.

Unrelatedly, as this RFC amends RFC0001, I think a link to it should be added towards the top of RFC0001.

@7c6f434c

This comment has been minimized.

Member

7c6f434c commented Nov 30, 2018

Re: experimental RFCs: I guess with our process we have less separation of stable releases from the experimental development. I think it would be a risky scope creep for the current RFC.

@globin

This comment has been minimized.

Member

globin commented Nov 30, 2018

@Ekleog

Just had an idea coming from the Rust process: experimental RFCs. These are RFCs accepted on a “let's try this” basis. In Rust this is technically enforced by not allowing stabilization of those without another RFC to validate them. In Nixpkgs, it could be “we'll try this but promise nothing about whether it stays in”. I'm thinking it could be useful for things like “Support <arch>”, where we might want to say “OK let's try, but not promise anything”.

I'm not totally sure whether this should get in this RFC or in a separate one, though.

I'd prefer looking at this in a seperate RFC, I want to keep this rather small and uncontroversial.

Unrelatedly, as this RFC amends RFC0001, I think a link to it should be added towards the top of RFC0001.

I'll add that in the upcoming implementation PR.

@shlevy

This comment has been minimized.

Member

shlevy commented Nov 30, 2018

Shepherd team for this RFC is @zimbatm, @edolstra, @Ekleog, and @samueldr, with @zimbatm serving as shepherd leader.

@globin

This comment has been minimized.

Member

globin commented Dec 5, 2018

I think I've addressed the postponing/rejected issue that was the largest remaining discussion point.

WRT the Nix Core Team RFC, do all of you @NixOS/nix-core agree that this supersedes it? If this needs more discussion I'd like to postpone that issue to another RFC as it only partly fits into this RFC and I'd like to keep this as small and uncontroversial as possible.

Are there any further open issues I've missed?

@shlevy

This comment has been minimized.

Member

shlevy commented Dec 5, 2018

@globin Personally happy to count this as superseding the core team if there are no objections.

@7c6f434c

I, personally, like this RFC in the current state and consider all of the issues I had with the wording «resolved enough».

@oxij

This comment has been minimized.

oxij commented Dec 7, 2018

@zimbatm zimbatm changed the title from Improving the RFC process to [RFC 0036] Improving the RFC process Dec 9, 2018

@zimbatm

zimbatm approved these changes Dec 9, 2018

Entering the Final Comment Period of 10 days

@nixos-discourse

This comment has been minimized.

nixos-discourse commented Dec 9, 2018

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/rfc-0036-improving-the-rfc-process/1638/1

@vcunat

This comment has been minimized.

Member

vcunat commented Dec 9, 2018

@globin me too. This RFC doesn't really touch any workflow around the Nix repo, but I'm afraid I've been so far unable to find significant amount of time for it anyway.

@shlevy

shlevy approved these changes Dec 9, 2018

Excellent work!

@Ekleog

Ekleog approved these changes Dec 9, 2018

All good with me for entering the FCP of 10 days with a disposition of merge! 🎉

Obsoleting the Nix Core Team RFC (by adding a header to it pointing to this RFC) can be done in the implementation PR (that would also be against this repo with the changes to the README to at least link to this RFC), I guess.

@samueldr

+1

@timokau

timokau approved these changes Dec 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment