[bug#74736] [PATCH v2 0/1] Add Request-For-Comment process.

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi all,

Thanks Noé!  I added you as co-supporter; someone definitively
required. ;-)

Thanks Steve for reaching me some weeks end ago.

Well, based on Noé’s v2, I polished some comments and sent v3; based on
what my follow up started weeks (months?) ago.


On Thu, 12 Dec 2024 at 19:14, Ludovic Courtès <ludo@gnu.org> wrote:

> These are changes from the past that may long be forgotten by the time
> we read them.  Perhaps we can abstract it a bit, like:
>
>   - changing the <package> record type and/or its interfaces;
>   - adding or removing a ‘guix’ sub-command;
>   - changing the channel mechanism;
>   - changing project policy such as teams, decision-making, the
>     deprecation policy or this very document;
>   - changing the contributor workflow and related infrastructure
>     (mailing lists, source code repository and forge, continuous
>     integration, etc.)
>
> This list seems redundant with and similar to that under “When To Follow
> This Process”; maybe just keep it in one place, under “When To Follow…”?

I think it helps to understand.  Concrete examples always help, IMHO.

Therefore, I propose what your wording.  Then, past examples where this
RFC process would have been helpful, I guess.

>> +  1. Clone https://git.savannah.gnu.org/git/guix.git
>
> I would suggest a separate repo.

Bah since we are putting all there… When you see etc/ ;-)


>> +** Decision making: consensus
>
> … and drop this.

I think it makes more sense to have the Decision Making as RFC and then
the manual refers to it, and not the converse. ;-)

Therefore, I would keep the section here.  And once we are done, letting
the manual as-is, I would link to RFC.

What defines the Decision Making *is* RFC and not the manual. ;-)


> Maybe we should define the role of “RFC editors” (or “RFC team”?), which
> would be the people responsible for doing those changes.

I’ve drop this “RFC teams“ or “RFC editors” because in my initial idea,
this is the aim of “co-supporter(s)”.  See the relevant section; does it
need to be improved?


>> +** Backward Compatibility
>> +
>> +None.
>> +
>> +** Forward compatibility
>
> I’m not sure what’s expected in these sections.  Maybe “Compatibility
> Considerations” would be more appropriate?

Yes, maybe “Compatibility Consideration”.  It needs to be in agreement
with the template.

>> +* Unresolved questions
>
> I think these two sections in the context of this foundational document
> look a bit ridiculous.  :-)  But maybe that’s okay?

I think that the first RFC must respects what it asks to other RFC. ;-)

And if the consensus is not reached, we need a place to summarize the
unresolved discussion, no?


Again, thanks Noé and Steve for taking care of that!

Cheers,
simon