Verified Commit e63cd390 authored by Konstantin Gizdov's avatar Konstantin Gizdov
Browse files

update TU renaming proposal with all current changes and finalise first draft

parent 23e7e84b
Pipeline #11805 failed with stage
in 12 seconds
......@@ -26,42 +26,92 @@ list about the "Trusted User" naming (later referred to simply by
Some relevant points of the discussion:
- The naming, i.e. "Trusted User", puts an unnecessary boundary between
Trusted Users and the rest of Arch Linux Staff, sometimes purely conceptually
but sometimes proved pivotally a burden. It suggests Trusted Users are
not full members of the project but external actors purely related on a
trust-only relationship to the rest of the staff. While this is important
during the application process, it becomes detrimental to developing stronger
and closer relationships between team members.
- The name should represent being a full member of and having a stake at Arch
Linux.
- The name
- Are there any previous discussions? Link to them and summarize them (don't
force your readers to read them though!).
- Is there any precedent set by other software? If so, link to resources.
Trusted Users and the rest of Arch Linux Staff, sometimes purely
conceptually but sometimes proved pivotally a burden. 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.
While this is important during the application process, it becomes
detrimental to developing more meaningful and closer relationships
between team members.
- The name should represent being a full member of and having a stake
at Arch Linux.
- The name is also confusing when interpreted publicly by third parties,
e.g. on CVs, public profiles and pages. The naming cannot be directly
understood as a position with real work and responsibilities involved.
- There are also situations where the naming cannot represent the
contribution/work made by TUs themselves very well. TUs are shown as
the "user" of such work rather than the main body involved in the R&D
and implementation.
- The name impedes conveying the due diligence needed to become a TU:
the public tend to assume that a TU is just a user that happens to
know an Arch Linux Developer in person.
Specification
-------------
Rename the "Trusted User" role as is to become "Maintainer". As such, all
Arch Linux Trusted Users will become Arch Linux Maintainers. No other changes
about the role in question are included in this proposal.
Arch Linux Trusted Users would become Arch Linux Maintainers. No other changes
about the position in question are included in this proposal.
Drawbacks
---------
TO-DO: Carefully consider every possible objection and issue with your proposal. This
section should be updated as feedback comes in from discussion.
The simple name change should have minimal impact internally and externally
for Arch Linux. In terms of their responsibilities and descriptions,
the roles remain unchanged making this the minimal incremental change
given the ideas discussed (Sections #Motivation and #Alternatives-Considered).
Possible difficulties exist in amending the legal documentation and making
sure all relevant Wiki and other public and private information is updated
timely to mitigate any confusion.
It should also be noted that this change should be allowed to propagate
internally and externally for enough time so that members and the public
become accustomed to the naming before allowing any further re-structuring
of the relevant roles. The drawback here is that any more considerable role
re-design will have to be delayed by some time. Judging by previous such
changes with significant impact, Arch Linux has usually provided about 6
months for everyone to adjust.
Unresolved Questions
--------------------
TO-DO: Are there any portions of your proposal which need to be discussed with the
community before the RFC can proceed? Be careful here -- an RFC with a lot of
remaining questions is likely to be stalled. If your RFC is mostly unresolved
questions and not too much substance, it may not be ready.
There should be no specific outstanding and unresolved questions. The new
naming has been chosen based on a semi-broad set of comments from TUs and
other Arch Linux members both on IRC and the mailing list. The broader
non-member community of Arch Linux and the public should possibly have
no impact on this decision. Unless, of course, there is a specific reason
raised to re-think this point.
Alternatives Considered
-----------------------
TO-DO: A list of alternatives, that have been considered and offer equal or similar
features to the proposed change.
There have been multiple other suggestions that have been considered before
the above selection in the #Specification section, e.g.:
- Member
- Package Maintainer
- Proponent
- Paladin
Furthermore, there have been ideas towards renaming the role of "Developer"
to "Core Maintainer", the role of "Trusted User" to simply "Maintainer" and
creating a new role called "Developer" solely reserved for members of Arch
Linux who do code development work directly relevant to Arch Linux.
Another similar idea was to keep the role structure as is but rename the
current "Developer" role into "Core Developer" and re-labelling the
"Trusted User" role to "Developer".
Finally, this proposal has been seen by some as the first step towards
a larger, more meaningful re-design as so ("->" is to be read as "becomes"):
- package maintenance, in [core]/[extra] (Developer only)
and [community] (everyone, especially TU)
-> (Core) Maintainer
- sysadmin (including dedicated tooling), which is partly dev but not only,
and even non-TU
-> Devops (currently in Support Staff)
- tooling development, be it pacman, archweb, devtools
-> Developers, or (Core) Maintainer
- Wiki, forum, IRC/Matrix, bug wrangler, (...)
-> Support Staff
- AUR handling, especially PRQ
-> Trusted Users
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment