On Tue, Mar 20, 2012 at 07:55:56AM +0100, Wouter Verhelst wrote:
> 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.
I'm not sure I follow you, but I think I disagree :-). If I'm reading
the above correctly, you're saying that not having job descriptions for
delegated tasks will reduce the conflict space, because there will be
disagreements on the interpretation of the job descriptions.
But job descriptions exists precisely to *reduce* the space of possible
interpretations. They will therefore reduce the number of times the DPL
is called to judge upon whether something is within the realm of the
delegation or outside of it.
They also increase the transparency of what is being delegated, which is
particularly important considering that delegations have the power of
creating disparity of powers among project members.
Finally, it has the benefit of depending less on the "judge" (i.e. the
DPL) than the scenario without descriptions. And that is particularly
good because the DPL is moving target, year after year. As a Debian
Developer, I wouldn't be happy to know that the interpretation of a
delegation with the current DPL might change with the next one.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature