Fedora Developer Ranking System v1

[Havoc Pennington]

Christopher Blizzard wrote:
> I think the specific proposal is too complex.  (It _is_ a strawman,
> after all!)  But I like the idea of doing something like this.  The
> incentives are nice, but I'm more interested in allowing people to
> choose their level of participation in a particular part of the project.
> For example, there are a large number of packages that I care about, but
> I don't need to own.  I just want to be informed when there are changes.
> Or if someone is doing translations for a particular package, they
> should be able to watch that package for changes and jump in when that
> happens.  As near as I can tell that's not easy right now.

When we did the Red-Hat-internal study/design-recommendations on 
bugzilla and related systems, one of the big guidelines was visibility 
rather than enforcement.

That is, the important thing is that the right people see the right 
things, while most "fix the system" discussion seem to focus on either 
making people do the right things or keeping people from doing the wrong 
things. (Or imagining that people will fill out dozens of little 
bugzilla fields then keep them up to date, but that's another issue - 
maybe just someone's OCD or love of policy-writing.)

If you try to encode a bunch of policies in software tools you just get 
a nightmare. It's much better to design the tools so they are simple for 
intelligent people to use to do what they want, and people can easily 
and accurately see what's going on, and then allow social mechanisms 
(including the "flame", "cluebat", and other time-tested tools) to take 
care of the rest.

Think wiki, not Enterprise Workflow.

ACLs are fine as a broad thing to keep total strangers from putting a 
virus in a package - but getting too fine-grained with security 
clearances and policies within a community of people who are supposed to 
be working together is just overhead that sucks energy - implementation, 
administration, and endless policy debates.

Look at the current kernel system with git - I've never used it, but my 
impression is that it's centered on accountability (being able to see 
where stuff came from). Similarly, for years GNOME CVS/SVN was pretty 
much one big unified commit access, and the security policy was mailing 
all the changes to cvs-commits-list where people could see them.

bugzilla "points" works relatively well because it's simple and 
transparent, requires no extra work, but most importantly because the 
points are interpreted by humans and not computers. If I have a lot of 
bugzilla points it just means people know I spent a lot of time in 
bugzilla, and then they use that knowledge wisely.

For example, if you want someone to patch a package but not build it, 
why not just ask them; and if they build it anyway, kick them out of 
your package. There's no reason to have a complicated policy about it.

Or if you want long-term developers to have more weight, just show how 
long someone has been a developer or how many packages they own 
somewhere prominent. Those developers will automatically pull more 
weight when appropriate because people will know they are experienced 
developers.

Havoc