Fedora Developer Ranking System v1

[Bryan Clark]

Havoc Pennington wrote:
>
>
> Warren Togami wrote:
>>
>> I suspect a points system would be good, but we could perhaps improve 
>> on this...
>>
>> - Points in itself is not a hard indicator of merit or promotion 
>> eligibility, just a strong hint of the contributor's value to the 
>> project.
>> - Earning points is logarithmic.  You shouldn't earn a super high 
>> score by doing an inordinate amount of one thing.  Points should 
>> perhaps reward doing different things more than plenty of the same 
>> thing.
>> - Points shouldn't be just for Bugzilla activity, there other 
>> potential sources.
>> - Points might accrue for consistent activity, and gradually fall if 
>> you stop participating.  (Note, points have no relation with access 
>> levels, so people who participate without care for points to maintain 
>> only specific packages don't need to care about maintaining 
>> consistent activity.)
>>
>
> Remember this stuff is for human interpretation. So basing just on 
> bugzilla is fine; high points means "does a lot of bugzilla stuff." 
> Having also "years as fedora contributor" or "number of packages 
> owned" would also be easy to understand, but to me probably easier if 
> they are separate metrics.
>
> Any kind of complex formula and nobody knows what the number means.
>
> But really, define the problem... for me bugzilla points are so people 
> jumping into the community can tell who is just a drive-by commentator 
> and who is a contributor. They seem to work fine for that.
>
> I don't see why you'd want some single rank metric to measure 
> someone's global Fedora coolness.

Wanted to reply to this in order to understand it a little better and 
maybe help moving forward.  Starting with a clear definition of the 
problem.  Pulling from your earlier email here's what I've gathered are 
the problems you're seeing, but I need help understanding what they are.

- Definition of the issues -

Easier way for people to gain more responsibility and do the things they 
want to do.
    - What are those things specifically?  (they should be listed so we 
can guess how to fix them)

The community is getting too big and the top ranked developers are 
spending too much time administrating?  If this is a problem, what are 
the specific issues related?

As the community is expanding people are becoming specialized, 
decentralized, and thus more anonymous to others.  It sounds like you 
want to stop this, but we should list reasons why even if they are 
obvious (like we all want to be friends).

The community is expanding to accommodate the expanding community? 

Visibility is probably a key component to solving each of the problems, 
used in conjunction with some broad and standard controls you can easily 
avoid lots of overhead of tight controls by making a process more 
visible to the right people. 

Think of "With enough eyes all bugs are shallow" and how it could apply 
to security / process issues.  Strict ACLs are the closed and cumbersome 
way of handling security, open security through visibility and loose 
controls is the best way to allow people freedom to act and the 
accountability that is also required by their actions.  Should also be 
mentioned that it's necessary to have an "undo" for this system, 
wikipedia would be no where if people could easily destroy data and it 
was lost forever.

Remember the problems are not "We need a tiered system to scale the 
community", that's a solution / meta-issue and since both are vaguely 
defined it's difficult to know where to start and what to do.  Once it's 
clear what the real issues are, it's a lot easier to address them with 
some tools or solutions.

- Tools -

A points system is just a tool.  The points system lets people know when 
a bug is triaged or closed by someone, how much bugzilla work the person 
has done.  If they have a high point value they can probably be trusted 
to be doing a good job, if they have a low point value you might want to 
check their work.

Relative identity is another tool the GNOME bugzilla has now. The 
identity shows who's a developer of what package, so when commenting on 
a bug you can see that I'm the developer or contributor to a certain 
bugzilla product.  This helps to know if I say "We're not doing this" on 
a bug where you can see I'm also listed as the maintainer then what I 
say is probably true.  The identity is relative because it doesn't know 
my home address, only the identity that's relevant to the system.

Buckets is another tool offered in the report that might be useful 
here.  Used to help control the flow of processes you can create buckets 
for people to work in, if something falls into their bucket it's their 
job to act on it and move it along to the next appropriate person's 
bucket (kind of like hot potato).  The flow from one bucket to the next 
has an automatic motion where a person can just press "done" and it 
moves to the next bucket, yet it also allows people to move items to any 
bucket available.

And there are lots of other tools to help, but it's more important to 
use the right tools than have lots of them.  But in order to have the 
right tools we need to know what the exact problems are.

Cheers,
~ Bryan