Re: Gergely and Wouter: on the need of becoming a DPL
On Fri, Mar 16, 2012 at 10:05:06AM +1100, Ben Finney wrote: This indicates either that you don't have any concrete, specific ideas about what to do differently, Something like that; I do know what I want to focus on, but I don't have the details worked out, and so there aren't specific ideas for what I'll do. I expect to work out the details as I work myself in as DPL. or that you don't intend to discuss those ideas publicly with the people deciding whether to vote for you. Certainly not. I would find that unacceptable for a prospective DPL myself. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120320063536.gn...@grep.be
Re: Gergely and Wouter: on the need of becoming a DPL
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
Question to all candidates: In eight years...
Dear candidates, this is the echo of a question asked two years ago in the 2010 campaign. http://lists.debian.org/debian-vote/2010/03/msg00057.html In addition, do you see major changes happening in the recent or next years, and how do you think Debian should react to them ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120320102755.ga12...@falafel.plessy.net
Re: Gergely and Wouter: on the need of becoming a DPL
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 »
signature.asc
Description: Digital signature
Re: More votes in Debian? Any idea for improvement?
On Sat, Mar 17, 2012 at 04:19:46PM -0700, Russ Allbery wrote:
Stefano Zacchiroli z...@debian.org writes:
But in our practices, we tend to rely on the Technical Committee
only for issues that fall in the broad category of conflicts
(§6.1.2 Decide [...] where Developers' jurisdictions overlap).
I've the impression that this is partly due to the perceived risk of
slowing thing down forever if the Technical Committee fail to answer in
$reasonable_time_frame.
I'm sure that's a large part of it, but I think people also avoid doing
this because it means not making decision by consensus. When some central
body hands down a decision, it almost guarantees that the people on the
losing side of that decision aren't going to feel convinced and are
probably going to be at least somewhat demotivated.
Now, whether the consensus process does any better at this is at least
debatable. But my impression is that it does do somewhat better, at the
cost of taking a lot of time and energy and usually multiple (somewhat
repetitive) rounds of the discussion.
The drawback of only using consensus, of course, is that it's very easy to
decide on the status quo by default. Consensus-based decision-making is
heavily biased towards the status quo, so I can understand why people who
would like to see a faster pace of change in Debian are frustrated by it.
Yes, exactly, I agree with this analysis, even though we probably have
different perceptions of the various reasons why people would not be
willing to refer issues to the technical committee. I'm probably biased
by the fact that I've been used, as DPL, as interface for questions
like should I refer this to the tech-ctte?. As such, I'm probably more
aware of the negative part of the reason (delays) than of the positive
one (preferring consensus).
Still, it should be pointed out that there often are people on the
losing also for the status quo options. Those you mention as
frustrated by the status quo are the people on the losing side. No less
than the people who would be on the losing side for decisions taken with
methods other than consensus.
I don't want to argue against consensus-based decision making, because I
love it as a default mechanism. But I don't think it is correct to
believe it is immune from the losing side issue.
But I've the impression there are areas that do not quality as conflicts
and that, at the same time, are particularly bad suited for decision by
consensus. A specific area I've in mind are distribution wide defaults:
what is the default MTA? the default Desktop Environment? editor?
web-server? etc.
Do people feel like these decisions have been poorly made so far?
Personally, I think those are all cases where the project came to a fairly
reasonable conclusion, and I haven't seen a lot of lingering significant
unhappiness about them.
I don't have more than gut feelings to offer on this. But mine is that
there are technical decision chapters --- again, mostly in the area of
default picking --- where the bar for questioning past decisions is
perceived as too high. Nobody wants yet another inconclusive -devel
discussion on what is the default $this or $that, so we simply avoid
discussing those. The matter is simpler to settle when the jurisdiction
of the default picking is well defined (e.g. default settings for a
specific package), but it is not when jurisdiction overlaps.
The case of the default init system looks a bit different, but not
*that* much. In a lot of default picking scenarios, there is no clearly
technical superior solution and at the same time there are a lot of
religious battles. That is what make them difficult to be decided upon
by consensus.
I do think that the lack of a clearly superior solution is partly an
artifact of the fact that we're discussing all this in theory without much
practical experience with real Debian packages and the implications of a
transition or parallel support, which is one of the things that makes the
ongoing debian-devel threads frustrating.
In the specific case of init systems, I agree.
If you now allow me to twist a DPL candidate question to a Technical
Committee member question :-), do you think default picking topics would
be appropriate tech-ctte decisions under §6.1.1/§6.1.3 ? With all the
needed disclaimers, of course, e.g.: after substantial discussion
elsewhere, assuming the tech-ctte can decide in $reasonable_time_frame,
etc.
Yes, I do.
But I'm reluctant to put any weight on that until the tech-ctte is
resolving the issues that it's already dealing with in a more timely
fashion.
Fair enough. Thanks for sharing!
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 »
Re: More votes in Debian? Any idea for improvement?
Stefano Zacchiroli z...@debian.org writes: On Sat, Mar 17, 2012 at 04:19:46PM -0700, Russ Allbery wrote: I'm sure that's a large part of it, but I think people also avoid doing this because it means not making decision by consensus. When some central body hands down a decision, it almost guarantees that the people on the losing side of that decision aren't going to feel convinced and are probably going to be at least somewhat demotivated. Now, whether the consensus process does any better at this is at least debatable. But my impression is that it does do somewhat better, at the cost of taking a lot of time and energy and usually multiple (somewhat repetitive) rounds of the discussion. The drawback of only using consensus, of course, is that it's very easy to decide on the status quo by default. Consensus-based decision-making is heavily biased towards the status quo, so I can understand why people who would like to see a faster pace of change in Debian are frustrated by it. Yes, exactly, I agree with this analysis, even though we probably have different perceptions of the various reasons why people would not be willing to refer issues to the technical committee. I'm probably biased by the fact that I've been used, as DPL, as interface for questions like should I refer this to the tech-ctte?. As such, I'm probably more aware of the negative part of the reason (delays) than of the positive one (preferring consensus). That's good data to have. Thank you. Still, it should be pointed out that there often are people on the losing also for the status quo options. Those you mention as frustrated by the status quo are the people on the losing side. No less than the people who would be on the losing side for decisions taken with methods other than consensus. That's true. I think that the consensus process stands a better chance of making everyone happy with the eventual outcome, but it's important not to confuse exhausting some of the parties so that they go silent with making everyone happy, and I agree that the consensus process can do the former as much as the latter. And interminable discussions are also demotivating, and I can see plenty of situations where interminable discussions are more frustrating than having someone make a decision that one disagrees with but which at least has been made. I don't want to argue against consensus-based decision making, because I love it as a default mechanism. But I don't think it is correct to believe it is immune from the losing side issue. Agreed. I don't have more than gut feelings to offer on this. But mine is that there are technical decision chapters --- again, mostly in the area of default picking --- where the bar for questioning past decisions is perceived as too high. Nobody wants yet another inconclusive -devel discussion on what is the default $this or $that, so we simply avoid discussing those. The matter is simpler to settle when the jurisdiction of the default picking is well defined (e.g. default settings for a specific package), but it is not when jurisdiction overlaps. That does seem like a good place to add a somewhat more hierarchical process, such as a time-boxed discussion on debian-devel (say, a week or two) followed by a tech-ctte decision taking into account the debian-devel discussion. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3877xbq@windlord.stanford.edu
