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
--
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
