[arch-dev-public] RFC: Using RFCs

[Morten Linderud]

On Tue, Feb 16, 2021 at 01:38:06PM -0300, Giancarlo Razzolini wrote:
> Em fevereiro 15, 2021 18:54 Morten Linderud escreveu:
> > On Mon, Feb 15, 2021 at 06:45:02PM -0300, Giancarlo Razzolini wrote:
> > > Em fevereiro 15, 2021 15:27 Morten Linderud via arch-dev-public escreveu:
> > > > > A general concern is "who has access to the repository"? Can
> > > anyone take the
> > > > template and submit an RFC that we'd need to consider on the mailing list after
> > > > a subsequent discussion? I can see it clear as sky the day Gitlab opens and
> > > > someone figures they'll submit an RFC to move away from systemd to
> > > > sysvinit/openrc/runit clear as day.
> > > >
> > > 
> > > We discussed this and I think eventually anyone should be able to propose a RFC. But,
> > > since as our gitlab isn't open and, the rfc requires an a-d-p announcement, this is limited
> > > to staff members for now.
> > > 
> > > The repository currently allows anyone with access to create MR's, but it can be restricted to
> > > members only, if needed.
> > 
> > This doesn't address the issue and just reiterated the points? Gitlab is going
> > to be opened within the next months and we have users on Gitlab today. It's not
> > limited to staff.
> > 
> > Is it our obligation to propose any user-made RFC to a-d-p on behalf of them? Do
> > we want that?
> > 
> > The process is not clear and either assumes the RFC proposer can announce it, or
> > makes it implicit that it will be announced.
> > 
> 
> It's my understanding that Allan made some amendments that address this issue specifically.
> But basically I think that a TU/Dev/Staff should be the one doing the post to a-d-p after
> vetting/sponsoring the RFC. But I maintain that I think anyone should eventually be able to
> create RFC's.

Yep!

My thinking after I went to bed is that if we do want user contribution it
should be explicitly handled in the process. I saw two suggestions:

    1. A form of RFC sherparding where the person or a team ensures the
       submitted RFC are vetted and proposed properly.

    2. Some form of explicit sponsoring by Devs and/or TUs.

If we don't have this the RFCs that can't be proposed by the submitter probably
wont be if the queue catches up to us. See the AUR requests piling up and
sometimes dealt with by a few people (or the bugtracker).

The first idea is essentially what NixOS does for all their RFCs[1]. But Allan
also came up with the second idea after reading this thread (I assume). I like
that amendment as we are probably not there yet where we need a sherparding
team.

Link for the folks following the thread:
https://gitlab.archlinux.org/allan/rfcs/-/commit/23dae7a83ea79f3b5da1e5c3b6c598266ae89b65

[1]: https://github.com/NixOS/rfcs/

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20210216/5f68f743/attachment.sig>