[RFC 0093] Propose RFC Categories

[blaggacao]

Rendered

---

Classifying previous RFCs into their correct categories in 986d268 aptly demonstrates that this RFC is long overdue and only makes it obvious what already is the reality (albeit disguised in some sense as "feature" RFC).

---

For future shepherds and meta-chat for all interested parties, I set up: https://matrix.to/#/#nix-rfc93-backchannel:matrix.org?via=matrix.org

[asymmetric]

What's not clear to me is how adding categories leads to better outcomes.

• Is it because right now, discussions are not being drafted into RFCs because they're not purely technical?
• Is it because the different categories would follow different rules?

I assume, though, one of the goals is to make more, better decisions, ie to somehow scale the governance process of the project.

Is this correct? I feel it would be helpful to provide some more "meat" to this proposal.

[nixos-discourse]

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

https://discourse.nixos.org/t/rfc-process-inspiration-from-bors/13084/2

[fricklerhandwerk]

I appreciate your effort, and can empathize with the stated motivation: RFC process definition focuses on technical aspects, raising doubt whether process proposals even belong here.

I disagree with your proposed solution: I don't see the need for more formalism. We don't have that many RFCs going on. I don't see how categorizing them would help with any of the stated difficulties you perceive. This may be in part wishful thinking on my side, and there are caveats, but in general, legitimacy of proposals is based on community response.

Why not specifically clarify the RFC process definition to explicitly mention processes?

[fricklerhandwerk]

@fricklerhandwerk I think your feedback counts as support? (Not 100% clear to me, so I ask) 😉

I don't support this specific advance, as it introduces too much cognitive overhead for my taste. I would support a careful clarification of existing material. Feel free to bounce ideas off me privately.

[roberth]

I believe this RFC elicits a disproportional sense of "heavy process" just by being an RFC.
Unlike the proposal, the change itself is actually minuscule.
It also seems to exemplify the problem it intends to alleviate.

The RFC process already mentions

In case your RFC is a technical proposal

so at least two categories already "exist".

@blaggacao Perhaps you could clarify the change to the template (perhaps a diff) and add an example interaction to 'Examples and Interactions' in the RFC text. It might feel "too trivial", but presenting the solution in concrete terms is helpful.

To sense if this addresses a valid issue in the community, I'll leave this in draft for a while to see what people think on a general level and without going into too much details.

I believe this is a minor change, so having more detail is feasible.

If it actually receives a little positive feedback, I'd revise it and un-draft, hopefully together with a co-author and a shepherd team, etc.

If it doesn't receive positive feedback, I'd find that rather concerning. It is well-intended and un-drafting will let shepherds guide you to a good outcome. Wasn't that the main goal of the RFC process?
Sadly I'm not qualified to shepherd this RFC, because I have too little experience with the process. I suppose it shouldn't be hard to convince someone more qualified to shepherd this RFC, when they are open to small incremental changes. (Isn't that what open source is about?)

Off-topic moderation

@sumnerevans Please treat other contributors with respect, by at least providing an explanation for your 👎, if you even want to use that reaction at all.

[sumnerevans]

@roberth @blaggacao I appologise for my usage of the -1 emoji (:-1:), I did not know it had such a harsh connotation in this community. I used that reaction to mean that "I am not in favor of this", and I chose not to add a comment because I felt that other contributors (especially here: #93 (comment) and here: #93 (comment)) had done a good job of explaining my concerns already. Thus, I did not want to clutter the comments section with superfluous "I agree with X and Y on this" comments. That said, I do sincerely apologize. No disrespect was meant, and I'm sorry that it came across that way.

[asymmetric]

@sumnerevans FWIW, I think it’s sometimes OK to use 👎, namely in the situation you describe, ie as a succinct way to express disapproval for a proposal when you simply agree with what others have said. I don’t think there’s any consensus in the community on its usage, and so IMO @roberth ’s remark should be interpreted as a personal preference.

Just my 2 cents, back to the topic at hand :)

[roberth]

@sumnerevans I understand that you intended no harm.

Another problem with 👎 besides the lack of constructive info, which as you point out may not always apply, is that it sticks around. There was a good chance that you would never revisit the pr, because you wouldn't be notified when the author improves it to a point where it's acceptable or even useful for you.

Of course, none of this is obvious, so I don't blame anyone for it.

I also feel like my tone was wrong, so I've worked on it and next time in a similar situation, I'll comment this:

---

@ handle While I'm sure you intend well, please read why no -1?

[blaggacao]

I differentiated the RFC templates in: 141b575

This RFC does not seek to change the fundamental process (RFC Steering Commitee, Shepherds to make the "final" judgment and guide the discussion, etc.).

Classifying previous RFCs into their correct categories in 986d268 aptly demonstrates that this RFC is long overdue and only makes it obvious what already happens (albeit disguised in some sense as "feature" RFC).

---

May I also remind prior meta/moderation commentators to mark their comments or parts thereof as "off-topic" (in github terms).

[gytis-ivaskevicius]

At first, I saw this RFC as a low-cost nice to have little feature but at this point, my thoughts are as follows:

• I am quite in favor of multiple changes in the readme.md
• The idea of Stakeholders is great. Maybe we could add it as part of the feature template as well?
• I find usage of markdown comments a little bothersome. Shall we return back to normal paragraphs?
• Templates aside, is the whole categorization really bringing any value? The fact that category is part of the document itself (and not a folder or part of some other grouped structure like a separate markdown file with the list of RFCs) does not seem to bring much if any improvement 😕

All in all, I am not 100% up for this RFC but here is a little idea:
Maybe while this is in progress we could get a partial changeset of this pushed to master (Updated readme + updated template)? Basically bit of a refresh to existing stuff

[fricklerhandwerk]

I agree with splicing out the unrelated fixups/clarifications. Let's work with small improvements wherever possible.

[Mic92]

@blaggacao could we have another meeting on this to discuss the updates?

[blaggacao]

Ok, I'll try to commit on implementing feedback-in-inventory this weekend and then we can schedule something.

[blaggacao]

Ok, I guess this is another version that we can iterate on...

[Mic92]

I think we should meet again to discuss the new version and comments made here.

[lheckemann]

@Mic92 is anything happening here?

[blaggacao]

This has fallen off the cliff over the time. Closing. If somebody wants to take possession, please do.