[arch-dev-public] RFC: Rename the Trusted User role
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. -- Regards, Konstantin
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
On Sat, Oct 09, 2021 at 22:03:55 +1000, Allan McRae via arch-dev-public wrote:
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.
Regarding your lack of access to the staff archive. AFAIU you removed the access yourself (correct me if I'm wrong), even though you could just have disabled "Mail delivery"[1] and maintained access to the archive. IMHO all staff should be subscribed to the staff list or at least have access to the archive, so if you want I can reinstate your access to the list with mail delivery disabled. [1] "Set this option to Enabled to receive messages posted to this mailing list. Set it to Disabled if you want to stay subscribed, but don't want mail delivered to you for a while [...]" Kristian
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
Hello, Anyone following the discussion on GitLab [1] can safely ignore this email, unless they are wishing to participate in the below proposal over email. In the latter case, please read below. The discussion on which specific term to use in the respective RFC [1] has stalled. After a brief discussion with anthraxx (Levente Polyak) and jelle (Jelle van der Waa), we decided to attempt to remedy the situation by an improvised vote. People are urged to choose between the following four options: - Option 1: Maintainer - Option 2: Packager - Option 3: Package Maintainer - Option 4: Package & Aur Maintainer If you wish you can cast your vote in the GitLab discussion or you can reply to this email with a signed email. You can also send me a signed email with your choice if you prefer not to vote publicly. The vote is open for two weeks from today. In the case where the vote does not produce a single majority, that will trigger the Two-round-system method [2]. The two options with the lowest popularity will be removed and the vote will repeat with the remaining two options only. -- Regards, Konstantin [1] - https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7 [2] - https://en.wikipedia.org/wiki/Two-round_system
Konstantin Gizdov via arch-dev-public wrote: People are urged to choose between the following
four options:
- Option 1: Maintainer - Option 2: Packager - Option 3: Package Maintainer - Option 4: Package & Aur Maintainer
I realize this is a little late but I want to suggest "Repo Maintainer". I've posted a comment with my reasoning on the merge request: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7#note_46970
Regards, Xyne
participants (4)
-
Allan McRae
-
Konstantin Gizdov
-
Kristian Klausen
-
Xyne