On Tue, Mar 13, 2012 at 06:15:04PM +0100, Stefano Zacchiroli wrote: > Since you've repeatedly mentioned my "bureaucracy" and "procedures" (not > to mention "bureaucrat" referred to my person, which doesn't feel as > nice, at least in popular connotations :-)),
Sorry 'bout that :-) > I'd like to point out that > procedures are just a mean to an end. They are incentives. They are > implementations of changes that we think are good for the project. Just > a few of concrete examples: > > - I've been routinely asking delegates to provide a sort of "tasks > description" before renewing, or creating from scratch, delegations. > All those descriptions have been stored under (or at the very list > indexed from) http://wiki.debian.org/Teams/ . Is that bureaucratic? > Yes. But it allows to find out what is the scope of a delegation > rather than relying on folklore. And *that* is very useful in conflict > solving (been there). I understand that. However, the problem with detailed job descriptions, as it were, is that you run the risk of having people argue over whether or not something is their responsibility. This would introduce a conflict. In the absense of such detail, it's the DPL's responsibility to just interpret the delegation and make a judgement call on whether something is one person's job or not. If done carefully (after weighing all the arguments), such a judgement call can be as effective in resolving conflict as are detailed job descriptions, without running the risk of introducing inflexibility. (for clarity, I'm not likely to remove these job descriptions. Now that they're there, I'll leave them. Also, if new delegates join a team where everyone else has a detailed job description, without having one like that themselves, I doubt that'd be a good idea, so I'll probably have to stick by this rule. I just won't introduce any such rules myself) > - I've been routinely asking sprint participants to document their > sprints under http://wiki.debian.org/Sprints before asking for budget > approval and of sending public sprint reports before asking for > reimbursements. Is that bureaucratic? Yes. But is useful in many ways: > 1/ it shows what we do with money and it helps in attracting sponsors > (see recent thread on -project); 2/ it dispels the risk of "cabals > meeting in secret on Debian money" (we have been there already, we've > had enough) and gives transparency on how Debian money are used; 3/ it > provides a flow of information about what is going on in various areas > of the project, increasing the permeability among teams. This is not something I oppose. Like I said, bureaucracy has its place; and when dealing with other people's money, the clarity and transparency that a set of rules will introduce is definitely a plus. > Just examples, I'll be happy to provide similar rationales for every > single procedure I've encouraged. That won't be needed. I believe (or rather, would hope) that you have rationales for each and every one you introduced. The point is not that you're doing it without cause, but rather, that if you introduce new rules, you always run the risk of introducing inflexibility, which is something that needs to be weighed against the benefits the new rule brings. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a
signature.asc
Description: Digital signature
