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

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

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

grahamc commented Nov 22, 2018

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

@7c6f434c
Copy link
Member

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 minimized.

@domenkozar

This comment has been minimized.

@shlevy

This comment has been minimized.

@shlevy

This comment has been minimized.

@7c6f434c

This comment has been minimized.

@shlevy

This comment has been minimized.

@7c6f434c
Copy link
Member

7c6f434c commented Nov 22, 2018 via email

@shlevy
Copy link
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 minimized.

@edolstra
Copy link
Member

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.

@samueldr
Copy link
Member

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

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

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 commented Dec 25, 2018 via email

globin added a commit to mayflower/nixos-rfcs that referenced this pull request Jan 7, 2019
@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 pushed 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 improve-rfc-rfc branch January 10, 2019 15:15
@nixos-discourse
Copy link

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

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

@7c6f434c 7c6f434c mentioned this pull request Jul 27, 2022
KAction pushed a commit to KAction/rfcs that referenced this pull request Apr 13, 2024
* 0036-rfc-process-team-amendment: draft

Co-authored-by: Graham Christensen <[email protected]>

* 0036-rfc-process-team-amendment: clarifications

Co-Authored-By: globin <[email protected]>

* 0036-rfc-process-team-amendment: remove typo recommendation

The github UI has improved since this was written and we should no
longer discourage this.

* 0036-rfc-process-team-amendment: Glossary -> Terminology

* 0036-rfc-process-team-amendment: disallow author/co-author as Shepherds

* 0036-rfc-process-team-amendment: incorporate feedback from discussion

* 0036-rfc-process-team-amendment: update rfc process graph

* 0036-rfc-process-team-amendment: merge postpone and reject

* 0036-rfc-process-team-amendment: improve Shepherd Leader paragraph
KAction pushed a commit to KAction/rfcs that referenced this pull request Apr 13, 2024
* Implementation of RFC 36

see NixOS#36

* Fix reference to 'this RFC' -> RFC NixOS#36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.