On Mon, 2007-01-22 at 13:59 +0330, Roozbeh Pournader wrote: > On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: > > === Disputes === > > [...] > > I don't know what is it, but this part makes me worry to some degree. It > looks like too much bureaucracy, and the challenge-from-within thing is > rather scary, and may make some maintainers choose polite and accepting > co-maintainers instead of competent ones (although these attributes are > not mutually exclusive, the limited choice makes that kind of decisions > unavoidable sometimes). > If you and another person rub each other the wrong way there's a good chance you shouldn't make them a co-maintainer anyway. Competency is more than knowing how to code and package, it's also interpersonal skills and the ability to communicate with your peers. You don't want "yes men" but you also don't want people who will take any controversial decision as a chance to publicly argue with you. > I also tend to think that the suggested mechanism will push us toward a > democracy to some degree instead of a meritocracy. I guess I should bite > the bullet and say it: The bureaucracy looks too much like Debian to me. > There needs to be a dispute policy of some kind, though. And some method of challenge from within is good too. That way when you have a maintainer who is mismanaging their packages there is a documented way to get them into the hands of someone who can and wants to do a better job. If this kind of thing is left up to an ad hoc, when the situation arises, we'll do something about it policy, then the packager who loses control of the package will be sure that his situation is a special case of everybody else out to get him personally. That said, there could definitely be changes made to the dispute section to make it address your concerns. thl outlines two cases where disputes arise: 1) Comaintainer and owner disagree over how to solve a problem. 2) Comaintainers feel the owner is holding up the process of developing the package. Do you have some suggestions for minimizing bureaucracy and ensuring that decisions are based on merit in each of these cases? > I quite like other parts of the proposal, and the only other part that > makes me worry a little is the three-maintainers-per-package part. I > can't say much about other packages, with the kind of packages that I > am/was involved in maintaining, two is usually quite enough. Three or > more maintainers will only make things more complicated. I read that as two maintainers (one primary, one co-maintainer) but thl would need to clarify. In general, I think having more co-maintainers would be beneficial to most packages. thl outlines the benefits in the policy draft. The disadvantage is the increased chance of disputes between maintainers. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 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
