[arch-dev-public] RFC: Rename the Trusted User role

[Konstantin Gizdov]

On 10/9/21 15:03, Allan McRae via arch-dev-public wrote:
> On 8/10/21 10:20 pm, Konstantin Gizdov via arch-dev-public wrote:
>> A new RFC (request for comment) has been opened here:
>>
>> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7
>>
>> Please visit the above link for discussion.
>>
>> Summary:
>> It is shown in some cases that the Trusted User role naming leads to
>> some confusion and misunderstanding in broader contexts outside Arch
>> Linux. It is furthermore recently been discussed that it also led to
>> similar confusion among members of Arch Linux as well internally. This
>> RFC aims to remedy that with a better suited term to reflect more
>> accurately upon TUs' roles and responsibilities as well as their
>> position in the Arch Linux Organisation.
>>
> 
> This is an interesting quote:
> 
> "It suggests Trusted Users are not full members of the project but
> external actors purely related by a trust-only relationship to the rest
> of the staff."
> 
> 
> Here is my understanding of the history of Arch Linux Trusted Users. I
> was not around at the very start, and some of this happened more than a
> decade ago so my memory may be foggy.
> 
> Trusted Users started as purely external actors.  The maintained their
> own infrastructure, and made decisions independent of the developers of
> the distribution.
> 
> At some stage (2009ish) it was decided that the [community] repository
> was an integral part of the distribution, and should be hosted with the
> rest of the Arch repos.  At this point, the main Arch repos were hosted
> in SVN, while the community repo was in CVS!
> 
> Merging infrastructure involved a decent amount of discussion.  One of
> the key points was that the TUs would remain an independent entity and
> be self governing according to the TU bylaws.  This independence was
> seen as critical.  Thus the Trusted Users determined they were not full
> members of the project in order to keep independence.
> 
> Over the years, the Trusted Users became more integrated.  Access was
> given to (some) developer only mailing lists. It was agreed that the
> Arch Linux Master Keys should sign Trusted User keys (discussion did
> occur whether this was acceptable given the independence of TUs).  TUs
> were given voting rights when determining the project leader (though a
> veto is held by the developers).  However, TUs never gave up their
> independence.
> 
> So the suggestion that Trusted Users are not full members of the project
> is technically correct!  In fact, according to the Trusted User Bylaws,
> I'm not sure the Project Leader or Arch Developers technically have the
> ability to make decisions affecting Trusted Users. That makes this RFC
> interesting!  I assume at a minimum, the TUs would need to vote for
> amendment to their bylaws if the RFC is accepted.
> 
> 
> FWIW, I do not think this RFC goes far enough.  There is effectively no
> distinction between people who package for [extra] and people who
> package for [community].  In fact, the distinction between those repos
> is moot.  I'd suggest removing this distinction completely, and formally
> integrating TUs into the Arch team in the same role as those who only
> package for the [extra].  Though this does leave the role of who should
> handle AUR maintenance to be determined.  And how the
> [extra]/[community] split should be defined moving forward.  And what
> happens to the TU bylaws.  And ...
> 
> There is potential you already discussed this on the private mailing
> list but I do not have access to the email archives that are linked in
> the RFC.  Nor do community members who are encouraged to comment on
> RFCs.  The fact changes like this are discussed in private is a
> detriment to a community orientated distribution.
> 
> Allan
> 
Thanks for the detailed overview. Indeed, some of the points were raised
in the staff mailing list, and some were not, so thanks for bringing
those up.

In any case, I think your overall point is very much aligned with that
discussion. Essentially, the conclusion was that there needed to be more
changes, and this RFC does not go far enough. In fact, we specifically
wanted this RFC to make as little as possible but still an impactful
change to lay the groundwork for initiating subsequent RFCs to bring the
rest of the appropriate changes.

We decided it would be appropriate to start at changing the name to a
more suitable one and then give a period of adjustment before bringing
more structural changes. That would allow us and the public a smoother
transition.

-- 
Regards,
Konstantin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20211025/c40dd4b5/attachment.sig>