==================================================
= Strawman of Fedora Developer Ranking System v1 =
==================================================
This concept document contains only *IDEAS* of why we would want a
ranking system, and how a ranking system might be useful. Below are
only examples. Please add your ideas to this thread.
Any ranking system would be automated as part of augmentations to FAS2
and PackageDB.
FAQ
===
1) Why ranks?
- Merit
Ranks provide a visible and better defined way for contributors to
"earn" their way up the ladder and gain more responsibilities.
- Lower Overhead of Scaling
A ranking system enables opportunities for the project to scale
without requiring the top ranked developers to be involved in or pay
attention to all activities. Lower ranks could have the ability to
recognize merit and promote ranks below them.
- Who Are You?
As the project grows, you can't possibly know all contributors on the
other side of the project. Viewing that member's stat page gives you a
convenient snapshot of what they are working on, who they work with, who
sponsored, who promoted, etc.
2) Isn't this just silly and unnecessary?
It depends. Much of the ranking system is just meaningless earning of
"gold stars". Many members may happily choose to just ignore the
ranking system because the default ranks give them enough permissions to
do their jobs. It is important that the interface and policies driving
the ranking system do not get in the way of getting things done. I
believe the below theoretical system achieves this level of inobtrusiveness.
Fedora Developer Ranks
======================
These are only EXAMPLES of ranks and associated permissions. This could
be reorganized with additional permissions, fewer permissions,
re-arranged permissions, fewer or more ranks, etc. Some of the
permissions may be a bad idea. Some of this may be implementable
sooner, and others later.
FD6: Elder Sponsor
(rank of more experienced sponsors)
(any better name for this? Chief?)
FD5: Sponsor
Write access to own packages, open ACL, orphan, and sponsoree
ACL control over sponsoree [1]
May grant unowned package to anybody (i.e. FD0) [2]
FD4:
FD3: May invite anybody to fedora-maintainers [3]
Write access to own packages, open ACL, orphan [4]
Take ownership of orphaned packages
FD2: Write access to own packages, open ACL [5]
FD1: Package Maintainer (currently cvsextras)
May subscribe to fedora-maintainers
May orphan your own package
FD0: Probationary/Training
Write access to own packages only
---: Read-Only Access to Package SCM
Please add your ideas of what other responsibilities could be given at
the different ranks of trust.
Rank Notes
==========
- FD0 is new, allowing a safe and convenient way to ease new
contributors into the project. They are allowed to touch only what they
own. This makes it easy for a sponsor to allow unproven/uncertain new
members in, while containing potential damage they might cause by
accident or otherwise. NOTE: *ALL* members with any write access at all
still require a sponsor.
- Sponsors may decide for new members to begin at FD1 because they don't
need hand-holding at FD0.
- FD1 or FD2 is all you really need if you are interested in maintaining
only your own packages, and not other aspects of the project
(governance, teamwork, etc). For example, many RH engineers or upstream
authors may fall into this category.
- FD2 is the equivalent of the current cvsextras. The varying grades
FD1 through FD4 are to allow finger grained permissions and a merit
earning path within what is currently known as cvsextras.
- FESCO is not a rank on the scale, because FESCO has permissions
granted by election, and those permissions may be taken away when they
step down from FESCO later. Additionally, a FESCO seat does not
automatically mean they have more merit than other members (although in
many cases they do.)
- Additional ranks and definitions may be added later if needed.
Promotion
=========
Each rank will have formal written description of rough requirements and
responsibilities. (Example: FD3 requires 17 quality reviews or 9 owned
packages and shows clear competence in package guidelines. FD4 requires
a history of giving opinions or helping others when needed in addition
to other technical requirements...) These descriptions however are only
to serve as examples, not hard requirements. Promotions in general are
the decision of higher ranked members, who may or may not choose to
follow those suggested requirements. Higher ranks however, have higher
bars of entry, and all members should hold promoters accountable to
their decisions.
Promotion Examples (specifics of which should be discussed):
- Elder Sponsor is FD6.
- Sponsor rank is FD5.
- FD5 (using some process) may be promoted to FD6. [6]
- FESCO group vote required to promote anybody to FD5.
- FESCO members may promote anybody to FD4, unilaterally.
- FD6 may promote anybody to FD4, unilaterally.
- FD5 may promote anybody to FD4, if three FD5 members agree (in database).
- FD5 may promote anybody to FD3, unilaterally.
- FD4 may promote anybody to FD3, if three FD4 members agree (in database).
- FD4 may promote anybody to FD2, unilaterally.
- FD3 may promote anybody to FD2, if two FD3 members agree (in database).
- FD2 can't promote anybody.
- FD1 can't promote anybody.
- FD0 can't promote anybody.
What do you think should be requirements and responsibilities of each rank?
Demotion Examples
=================
- FESCO group decides to demote, with cause.
- Sponsor decides to demote (or expel) their sponsored FD0 or FD1
member, with cause. (Although after they have been promoted to FD2+,
only FESCO may demote or expel a member.)
- Inactivity and AWOL status, per the written guidelines, can lead to
losing all ranks as well as package ownership by the decision of FESCO.
Things Made Possible by Ranks
=============================
- FD ranks can be used in elections.
Theoretical Example: Eligible FESCO candidates must be FD3+, but next
year FD4+ will be the minimum because our membership pool would have
grown. FD1+ may vote in FESCO elections.
- Optional Rank-Based ACL
As a package owner, I may choose most of my packages to be "open" to
FD1 write, because I think it is unnecessary to be so protective. But I
may want squirrelmail to be FD3+, or spamassassin to be only me and
specific people or other groups that I specify. Package owners should
be able to make these kinds of choices.
- Paper Trail
All sponsorships and promotions are logged in the database. When FESCO
wants to look into the merits of a nominated new sponsor, they have
convenient and timely access to information by simply viewing the
member's status page. At a glance, they can see how many packages they
have owned, how many reviews they have done, links to those reviews, who
sponsored their membership, who promoted them up the ladder, what other
project groups they belong to, etc.
- Any other arbitrary policy may be easily created by requiring
membership in a FAS2 group. A member of FD4 would also be a member of
FD3, FD2, FD1, and FD0. This allows a great deal of flexibility in
future automation.
Theoretical Groups Outside of FD Ranks
======================================
Other groups will (eventually) exist in FAS2, where permissions can be
granted when appropriate. Such groups could also used in optional
package ACL's if the owner chooses to make it so. In some cases other
parts of Fedora may want to create their own ranking ladder, but that is
outside the scope of this concept document. (For example,
Infrastructure might choose to have simple ranks, and FI1 may subscribe
to fedora-maintainers, while FI3 may invite anybody to fedora-maintainers.)
Special Groups
--------------
FESCO - voted in by Fedora Developer membership.
Security - TBD
CVSAdmin - decided by FI
Signers - decided by FPB
Fedora Sub-Projects
-------------------
Infrastructure
Docs
Translators
Package Ownership Groups
------------------------
gecko-maint
kernel-maint
xorg-maint
desktop-maint
kde-sig
games-sig
perl-sig
Footnotes
=========
[1]
- We probably need to define where a sponsor may no longer exert control
over a sponsoree. For example, if they have reached FD3, they probably
no longer need guardianship, and a group with more authority (like
FESCO) should exert decisions if necessary.
- RH engineers probably don't want sponsors to be able to modify their
packages, like kernel or glibc... although in practice a sponsor
wouldn't be so stupid to actually do that. Worthwhile to encode a
special enforcement case for such an unlikely event?
[2]
FD5 being able to grant an unowned package to anybody, especially to a
new member that they sponsor, is a powerful way to lower overhead in the
project in a safe and controlled manner.
[3]
We need a low overhead way to let qualified people into
fedora-maintainers list. Anybody who has passed the "training" and a
sponsor has judged that they understand the guidelines (FD1) may
subscribe. Additionally, sufficiently empowered users (FD3?) should at
their own discretion be able to invite anybody else to
fedora-maintainers. An invitee could include someone who is not a
member in the project (no CLA required), but is useful to us in some
capacity.
[4]
IMHO, protecting orphans with ACL is really unnecessary. How is this
different than all of the other "open ACL" packages?
[5]
"open ACL" means any package where the owner chooses not to protect with
an ACL. I suspect write access to this belongs in either FD1 or FD2,
but I am leaning toward FD2. Why? Because new members in FD1 really
have no business touching someone else's package. Most existing
cvsextras members would probably land at FD2+ levels, and it is easy
enough to become FD2, so is this really an issue?
[6]
It might be cool if "Sponsors" may be promoted to "Elder Sponsors" not
from above, but from below. For example, if fifteen FD3+ members like
the work a sponsor is doing, they can become an Elder Sponsor. The
difference between FD5 and FD6 (like most other ranks) would be mostly
meaningless other than a vote of confidence from peers.
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
