Skip to content
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

Merged
merged 9 commits into from Dec 25, 2018
Merged

Conversation

@globin
Copy link
Member

@globin 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

Co-authored-by: Graham Christensen <graham@grahamc.com>
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 Show resolved Hide resolved
Co-Authored-By: globin <mail@glob.in>
@grahamc
Copy link
Member

@grahamc grahamc commented Nov 22, 2018

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

@7c6f434c
Copy link
Member

@7c6f434c 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.

Copy link
Member

@zimbatm zimbatm left a comment

Nice work! Happy to see this moving forward.

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 Show resolved Hide resolved
@shlevy

This comment has been hidden.

@domenkozar

This comment has been hidden.

@shlevy

This comment has been hidden.

@shlevy

This comment has been hidden.

@7c6f434c

This comment has been hidden.

@shlevy

This comment has been hidden.

@7c6f434c
Copy link
Member

@7c6f434c 7c6f434c commented Nov 22, 2018

@shlevy
Copy link
Member

@shlevy 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 has been hidden.

@edolstra
Copy link
Member

@edolstra 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
Copy link
Member Author

@globin globin commented Dec 14, 2018

I've finally had the time to read what Python is doing. I miss two failure prevention mechanisms in the current form:

a) Conflict of interest - putting an upper cap of 2 persons to work for a single employer
b) Vote of no confidence - vote to disassemble the whole team or a single member

I'm happy to include those if there are no objections.

I'd propose to move this to a new amending RFC, so that this RFC and the process can get going, especially wrt other stalled RFCs. I don't think we'll have problems with this until we follow up with that. But I definitely agree that these points should be added at some point. So far we already had made sure to check that no more than 2 people of either Mayflower or Tweag would be members of the RFC Steering Committee.

@shlevy
Copy link
Member

@shlevy shlevy commented Dec 14, 2018

Re @domenkozar 's suggestion, I think these are things we should be thinking about but should not be overeager on up front process. IMO process should evolve in response to real needs facing our community... e.g. we do have quite a few industrial backers of Nix but so far most of them appear to seriously be engaging in appropriate community-centered behavior in good faith. Back to an earlier comment of mine, we should remember that at the end of the day there are several informal escape hatches from the formal structure we build here if things truly get out of hand.

@vcunat
Copy link
Member

@vcunat vcunat commented Dec 14, 2018

The a) and b) would be for the Committee, right? a) might also be a softer recommendation when choosing each Shepherd Team, but I wouldn't be so strict there, leaving that on the good judgement of the Committee and b) is there already IIRC.

EDIT: I forgot to add, a) holds for the currently proposed Committee AFAIK, so it will only really apply when it's next changed and doesn't need to slow us down now, as suggested.

@domenkozar
Copy link
Member

@domenkozar domenkozar commented Dec 14, 2018

@shlevy I have a few objections with that logic, but before we go too deep I'd like to ask @zimbatm, @edolstra, @Ekleog, and @samueldr for comments.

@vcunat yes, I'm talking about the committee.

@samueldr
Copy link
Member

@samueldr samueldr commented Dec 14, 2018

IMHO, (a) and (b) can and should either cause this RFC to go to Refine Idea, or those be added through RFC that amend this one. I strongly suggest going through RFCs, either one for both, or one per. One per is probably better for the fact that issues with either of the proposed amendments will not block the other, but at the same time, could cause RFC fatigue.

(Opinion is in bold only to make it obvious.)

@Ekleog
Copy link
Member

@Ekleog Ekleog commented Dec 14, 2018

@vcunat both (a) and (b) are currently left as future work as I understand it:

Define how the Steering Committee is picked in the future and how to replace members thereof if they are not able to participate in the meetings, including guidelines on when to replace members. (a timeline, not being active, etc.)

@domenkozar My opinion is summed up at #36 (comment). Honestly, if you feel like this is important, I think we should interrupt the FCP, discuss the ideas, amend the RFC and trigger a new FCP. I'd guess if the rate of discussion is as active as it is currently being, this would delay the merging of this RFC by 2-3 weeks. However, I am personally neutral on this question.

An alternative option would be to define the RFC process for other RFCs before this RFC is merged (and the RFC process is actually formally defined), and consider that when the current FCP ends (ie. in a few days) the current state of this RFC should be used to handle other RFCs, until this RFC is finalized and merged, at which point the merged RFC will become reference.

This way:

  • This RFC handles all the cases
  • We actually abide by “However, sometimes substantial new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into development mode.” -- I think @domenkozar's argument can be considered substantial, but as it is currently explicitly left as future work there is room for debate about whether it is new
  • Other RFCs can move forward in the mean time.

Deciding to go this way would require approval of the Steering Committee, though, given it will affect how all RFCs are handled until this RFC is merged.

If the Steering Committee is in favor of this, I am in favor of cancelling the FCP and polishing this RFC. Otherwise, I think this RFC should continue its way forward so that we have an agreed-upon basis, but will not try to defend this thought should anyone strongly want to examine these ideas (because of the aforementioned sentence in the RFC text about “substantial new ideas”)

Currently the FCP is ticking, so absent answer of the Steering Committee agreeing to this idea or someone expressing strong will to examine these ideas within the context of this RFC (and not subsequent ones), if the FCP runs to its end this RFC will be approved.

@domenkozar
Copy link
Member

@domenkozar domenkozar commented Dec 14, 2018

I have only seen Python proposal two days ago otherwise I'd be happy to flag myself as slow to respond in this particular case.

If we're building rules for the next few years, I'd say 2-3 weeks is a minor bump and is expected - otherwise what's the point of RFC process having FCP be broadcasted? RFC process has substantial overhead though - we need another meeting of steering committee, pick shephard team again, etc. At the end it's going to be more work.

Honestly, if you feel like this is important, I think we should interrupt the FCP, discuss the ideas, amend the RFC and trigger a new FCP

I'm still +0 to address these - @shlevy raised a valid point that this is a bigger issue for nixos foundation than the steering committee itself.

Shephards should vote if my concern is valid (maybe the process needs to be amended how FCP can actually be "canceled, and the RFC goes back into development mode"?).

@shlevy
Copy link
Member

@shlevy shlevy commented Dec 14, 2018

@Ekleog Not sure I understand, are you proposing that we start using the steering/shepherd model for other RFCs now before this one is merged, and in the mean time take this one out of FCP to visit the issues @domenkozar raises? If so, I'd personally prefer we get this one in and spend the polishing time on a separate amendment RFC, but I'm willing to participate in steering team work if we decide to go that route.

@shlevy
Copy link
Member

@shlevy shlevy commented Dec 14, 2018

(Note that the "personal preference" above only applies if people are anxious about getting started shepherding soon. I'm personally fine with this taking longer as well).

@Ekleog
Copy link
Member

@Ekleog Ekleog commented Dec 14, 2018

@domenkozar The FCP being cancelled, in my understanding, just means that we do like it never existed, it doesn't mean that the RFC is rejected and starts from scratch.

As for shepherds voting, a single shepherd willing to stop the FCP can do it, so there is no need for a vote (as entering the FCP is made by unanimity, it is logical that leaving it can be done by a single person, as the idea is that the end result must be unanimous).

Currently, my reading is @samueldr is -1, and I am -0 (and ready to switch to +1 should someone voice a strong desire to discuss these now and not in amendment RFCs)

@shlevy That's exactly what I am saying indeed, as an alternative to either going the amending-RFC or the second-FCP route. Without a strong preference for this new idea either, but I wanted to point out that we could still handle @domenkozar's concerns now while not delaying further pending RFCs.

@zimbatm
Copy link
Member

@zimbatm zimbatm commented Dec 14, 2018

@domenkozar I would rather us go forward at this point. The RFC is clear enough for me to follow as a process. I don't think that it needs to be treated like a legal document. Now the next thing to do is to actually do the work and exercise that process and then we can adjust it with real data.

@zimbatm
Copy link
Member

@zimbatm zimbatm commented Dec 25, 2018

The 10 days period has elapsed with no major disagreement. Declaring the @NixOS/rfc-steering-committee to be official!

@zimbatm zimbatm merged commit b8b0622 into NixOS:master Dec 25, 2018
@7c6f434c
Copy link
Member

@7c6f434c 7c6f434c commented Dec 25, 2018

Now some of the «future work» can start without creating confusion.

Does anyone want to start the discussion (on Discourse, probably?) about long-term plans for SC composition update rules, or should I start something then see where it goes?

Should this discussion include the Foundation positions too?

@grahamc
Copy link
Member

@grahamc grahamc commented Dec 25, 2018

globin added a commit to mayflower/nixos-rfcs that referenced this pull request Jan 7, 2019
see NixOS#36
@globin globin mentioned this pull request Jan 7, 2019
globin added a commit to mayflower/nixos-rfcs that referenced this pull request Jan 7, 2019
zimbatm added a commit that referenced this pull request Jan 8, 2019
* Implementation of RFC 36

see #36

* Fix reference to 'this RFC' -> RFC #36
@globin globin deleted the mayflower:improve-rfc-rfc branch Jan 10, 2019
@nixos-discourse
Copy link

@nixos-discourse nixos-discourse commented Aug 22, 2019

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/new-rfc-50-merge-bot-for-maintainers/3795/1

@nixos-discourse
Copy link

@nixos-discourse nixos-discourse commented Sep 5, 2019

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/new-rfc-52-away-from-static-ids/3931/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet