Proposals, discussions and announcements

Thomas Goirand | 11 Mar 2012 20:28

Picon

More votes in Debian? Any idea for improvement?

Hi,

If you see projects like Openstack or oVirt (sorry for the examples
taken from my area of expertise...), they have elections every 6 months
for project leaders in this or that area of the project.

In Debian, we just elect a DPL, and then we hope that he appoints people
who then can make decisions on the behalf of Debian.

I feel strange that such a big project as Debian appears to work in a
less democratic way than some software which has adopted open governance
(truth, this is the new hype, but still...).

I see no reason why we couldn't have more direct appointments for key
positions in Debian. I feel like it would be possible to have more
democratic, ways to do things, with direct votes.

Also, on the opposite side, the DPL is currently having to appoint
regularly others, which is only a formal thing and is sometimes a
useless loss of time (maybe Zack can tell a bit more about this in a
better English than mine...).

What are the improvements in this area that our 2012 candidates foresee?

Cheers,

Thomas Goirand (zigo)

Wouter Verhelst | 12 Mar 2012 09:04

Picon

Re: More votes in Debian? Any idea for improvement?

On Mon, Mar 12, 2012 at 03:28:53AM +0800, Thomas Goirand wrote:
> Hi,
> 
> If you see projects like Openstack or oVirt (sorry for the examples
> taken from my area of expertise...), they have elections every 6 months
> for project leaders in this or that area of the project.
> 
> In Debian, we just elect a DPL, and then we hope that he appoints people
> who then can make decisions on the behalf of Debian.
> 
> I feel strange that such a big project as Debian appears to work in a
> less democratic way than some software which has adopted open governance
> (truth, this is the new hype, but still...).

Debian is not a democracy, nor does it need to be.

We have one elected representative, whose job it is to make sure that
the project runs smoothly. But having an elected representative doesn't
necessarily mean that this person is the best for the job. Technical
tasks should have experts doing them, otherwise they'll not work; and
while an election can give you many things, experts in a particular job
is probably not one of them.

--

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a

(Continue reading)

Thomas Goirand | 15 Mar 2012 08:11

Picon

Re: More votes in Debian? Any idea for improvement?

On 03/12/2012 04:04 PM, Wouter Verhelst wrote:
> On Mon, Mar 12, 2012 at 03:28:53AM +0800, Thomas Goirand wrote:
>> Hi,
>>
>> If you see projects like Openstack or oVirt (sorry for the examples
>> taken from my area of expertise...), they have elections every 6 months
>> for project leaders in this or that area of the project.
>>
>> In Debian, we just elect a DPL, and then we hope that he appoints people
>> who then can make decisions on the behalf of Debian.
>>
>> I feel strange that such a big project as Debian appears to work in a
>> less democratic way than some software which has adopted open governance
>> (truth, this is the new hype, but still...).
> 
> Debian is not a democracy, nor does it need to be.
> 
> We have one elected representative, whose job it is to make sure that
> the project runs smoothly. But having an elected representative doesn't
> necessarily mean that this person is the best for the job. Technical
> tasks should have experts doing them, otherwise they'll not work; and
> while an election can give you many things, experts in a particular job
> is probably not one of them.

So if I understand well, you're saying that the DPL knows better than a
majority that would vote (which may be right, I'm not sure).

In this case, how will you choose well how to delegate? Don't you think
there's the risk that you will choose mostly the ones that you know
better? Do you think you know well enough groups of people that aren't

(Continue reading)

Wouter Verhelst | 15 Mar 2012 15:10

Picon

Re: More votes in Debian? Any idea for improvement?

On Thu, Mar 15, 2012 at 03:11:28PM +0800, Thomas Goirand wrote:
> On 03/12/2012 04:04 PM, Wouter Verhelst wrote:
> > On Mon, Mar 12, 2012 at 03:28:53AM +0800, Thomas Goirand wrote:
> >> Hi,
> >>
> >> If you see projects like Openstack or oVirt (sorry for the examples
> >> taken from my area of expertise...), they have elections every 6 months
> >> for project leaders in this or that area of the project.
> >>
> >> In Debian, we just elect a DPL, and then we hope that he appoints people
> >> who then can make decisions on the behalf of Debian.
> >>
> >> I feel strange that such a big project as Debian appears to work in a
> >> less democratic way than some software which has adopted open governance
> >> (truth, this is the new hype, but still...).
> > 
> > Debian is not a democracy, nor does it need to be.
> > 
> > We have one elected representative, whose job it is to make sure that
> > the project runs smoothly. But having an elected representative doesn't
> > necessarily mean that this person is the best for the job. Technical
> > tasks should have experts doing them, otherwise they'll not work; and
> > while an election can give you many things, experts in a particular job
> > is probably not one of them.
> 
> So if I understand well, you're saying that the DPL knows better than a
> majority that would vote

Absolutely not. I'm not sure how you derive that from my above
statement. I said "having an elected representative doesn't [...] mean

(Continue reading)

Thomas Goirand | 15 Mar 2012 18:27

Picon

Re: More votes in Debian? Any idea for improvement?

On 03/15/2012 10:10 PM, Wouter Verhelst wrote:
> On Thu, Mar 15, 2012 at 03:11:28PM +0800, Thomas Goirand wrote:
>> On 03/12/2012 04:04 PM, Wouter Verhelst wrote:
>>> On Mon, Mar 12, 2012 at 03:28:53AM +0800, Thomas Goirand wrote:
>>>> Hi,
>>>>
>>>> If you see projects like Openstack or oVirt (sorry for the examples
>>>> taken from my area of expertise...), they have elections every 6 months
>>>> for project leaders in this or that area of the project.
>>>>
>>>> In Debian, we just elect a DPL, and then we hope that he appoints people
>>>> who then can make decisions on the behalf of Debian.
>>>>
>>>> I feel strange that such a big project as Debian appears to work in a
>>>> less democratic way than some software which has adopted open governance
>>>> (truth, this is the new hype, but still...).
>>>
>>> Debian is not a democracy, nor does it need to be.
>>>
>>> We have one elected representative, whose job it is to make sure that
>>> the project runs smoothly. But having an elected representative doesn't
>>> necessarily mean that this person is the best for the job. Technical
>>> tasks should have experts doing them, otherwise they'll not work; and
>>> while an election can give you many things, experts in a particular job
>>> is probably not one of them.
>>
>> So if I understand well, you're saying that the DPL knows better than a
>> majority that would vote
> 
> Absolutely not. I'm not sure how you derive that from my above

(Continue reading)

Wouter Verhelst | 15 Mar 2012 19:10

Picon

Re: More votes in Debian? Any idea for improvement?

On Fri, Mar 16, 2012 at 01:27:07AM +0800, Thomas Goirand wrote:
> On 03/15/2012 10:10 PM, Wouter Verhelst wrote:
> > On Thu, Mar 15, 2012 at 03:11:28PM +0800, Thomas Goirand wrote:
> >> On 03/12/2012 04:04 PM, Wouter Verhelst wrote:
> >>> Debian is not a democracy, nor does it need to be.
> >>>
> >>> We have one elected representative, whose job it is to make sure that
> >>> the project runs smoothly. But having an elected representative doesn't
> >>> necessarily mean that this person is the best for the job. Technical
> >>> tasks should have experts doing them, otherwise they'll not work; and
> >>> while an election can give you many things, experts in a particular job
> >>> is probably not one of them.
> >>
> >> So if I understand well, you're saying that the DPL knows better than a
> >> majority that would vote
> > 
> > Absolutely not. I'm not sure how you derive that from my above
> > statement. I said "having an elected representative doesn't [...] mean
> > this person is the best for the job", which seems like exactly the
> > opposite.
> 
> Well, there's only 2 choices here. However you put it, we need a way to
> appoint. Either the DPL knows better (maybe thanks to a relationship
> with the team we're talking about, but it's not always about teams...),
> either the majority knows better. There's no 3rd option here, so please
> make a choice between these 2! :)

Oh, _that_ way. Right, I misunderstood you then, sorry.

No, I don't think the DPL knows better than the majority of people. The

(Continue reading)

Stefano Zacchiroli | 12 Mar 2012 21:33

Picon

Re: More votes in Debian? Any idea for improvement?

On Mon, Mar 12, 2012 at 03:28:53AM +0800, Thomas Goirand wrote:
> If you see projects like Openstack or oVirt (sorry for the examples
> taken from my area of expertise...), they have elections every 6 months
> for project leaders in this or that area of the project.
> 
> In Debian, we just elect a DPL, and then we hope that he appoints people
> who then can make decisions on the behalf of Debian.
> 
> I feel strange that such a big project as Debian appears to work in a
> less democratic way than some software which has adopted open governance
> (truth, this is the new hype, but still...).

In talks about Debian, I always mention decision making in Debian as one
of the distinguishing features of our project. But I always also points
out that democracy is just one ingredient of it and that we have a
culture of using votes only for "political" issues and not for technical
issues.

Voting on technical matters, or to elect technical bodies, works well
for projects that have a more narrow scope than Debian. There are Free
Software *development* projects that use vote among developers as a way
to decide whether to give commit access to someone or not, for instance.

But at the Debian scale, I don't think vote should be used to decide on
technical merits, to choose technical solutions, or to elect technical
bodies. It will be democracy, sure, but I believe it will be less
effective than our current mechanisms at guaranteeing technical quality.

> I see no reason why we couldn't have more direct appointments for key
> positions in Debian. I feel like it would be possible to have more

(Continue reading)

Russ Allbery | 13 Mar 2012 00:19

Picon

Re: More votes in Debian? Any idea for improvement?

Stefano Zacchiroli <zack <at> debian.org> writes:

> Voting on technical matters, or to elect technical bodies, works well
> for projects that have a more narrow scope than Debian. There are Free
> Software *development* projects that use vote among developers as a way
> to decide whether to give commit access to someone or not, for instance.

> But at the Debian scale, I don't think vote should be used to decide on
> technical merits, to choose technical solutions, or to elect technical
> bodies. It will be democracy, sure, but I believe it will be less
> effective than our current mechanisms at guaranteeing technical quality.

To make this concrete, we had a spat of GRs to decide various technical
and social issues in Debian some years back, and that practice has died
out almost completely.  I know I at least much prefer the current
situation to when lots of contentious decisions involved GRs; the current
situation seems like a clear improvement over the more democratic one that
prevailed earlier.

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>

Anthony Towns | 13 Mar 2012 10:51

Picon

Re: More votes in Debian? Any idea for improvement?

On Mon, Mar 12, 2012 at 04:19:44PM -0700, Russ Allbery wrote:
> To make this concrete, we had a spat of GRs to decide various technical
> and social issues in Debian some years back, and that practice has died
> out almost completely.  I know I at least much prefer the current
> situation to when lots of contentious decisions involved GRs; [...]

Personally, I would put this down to Debian simply not having any
contentious decisions to make. I haven't been following Debian as closely
as I once did, though, so perhaps I just haven't seen them.

I wonder if anyone can name three "big" controversies over the past few
years that have gotten resolved within Debian?

To be more specific: something "important" where there's (at least)
two different choices that groups of different developers want to make,
and some resolution has been arrived at beyond "ignore the whole issue"
or "everyone who thinks X has given up/gone away, therefore Y" or "wait
and see what other distros do"?

A resolution might be winner vs loser (we package stuff in deb, not rpm;
we continue with the non-free section of the archive), but it doesn't have
to be; sometimes everyone gets convinced that's there's a best way to do
things; other times there are technical solution that makes both things
possible (alternatives making vim and nvi both work as the default vi,
Provides:/Conflicts: for MTAs, packaging both Gnome and KDE).

The biggest controversies in free software that I've seen just aren't
happening within Debian from what I've seen: Unity vs Gnome3 is an
Ubuntu/Gnome thing; upstart vs systemd is an Ubuntu/Fedora thing; funding
open source development is a Red Hat/Google/Intel/IBM/HP/Oracle/buxy

(Continue reading)

Russ Allbery | 13 Mar 2012 17:34

Picon

Re: More votes in Debian? Any idea for improvement?

Anthony Towns <ajt <at> master.debian.org> writes:
> On Mon, Mar 12, 2012 at 04:19:44PM -0700, Russ Allbery wrote:

>> To make this concrete, we had a spat of GRs to decide various technical
>> and social issues in Debian some years back, and that practice has died
>> out almost completely.  I know I at least much prefer the current
>> situation to when lots of contentious decisions involved GRs; [...]

> Personally, I would put this down to Debian simply not having any
> contentious decisions to make. I haven't been following Debian as
> closely as I once did, though, so perhaps I just haven't seen them.

> I wonder if anyone can name three "big" controversies over the past few
> years that have gotten resolved within Debian?

Multiarch.  (Okay, we're not done yet, but we're a lot of the way along.)
The DEP5 copyright format.  Build hardening flags.  How to implement
build-arch (again, not done yet, but we do have a decision that I expect
to be implemented shortly).

My guess is that at least multiarch and build hardening would have become
GRs about five years ago.

> The biggest controversies I've seen in Debian have been things like
> "when should dpkg multiarch get uploaded to experimental/unstable"
> (resolved by a vote though not a GR...),

A very non-democratic vote.

--

--

(Continue reading)

Mark Brown | 28 Mar 2012 17:49

Picon

Re: More votes in Debian? Any idea for improvement?

On Tue, Mar 13, 2012 at 09:34:05AM -0700, Russ Allbery wrote:
> Anthony Towns <ajt <at> master.debian.org> writes:

> > Personally, I would put this down to Debian simply not having any
> > contentious decisions to make. I haven't been following Debian as
> > closely as I once did, though, so perhaps I just haven't seen them.

> > I wonder if anyone can name three "big" controversies over the past few
> > years that have gotten resolved within Debian?

> Multiarch.  (Okay, we're not done yet, but we're a lot of the way along.)
> The DEP5 copyright format.  Build hardening flags.  How to implement
> build-arch (again, not done yet, but we do have a decision that I expect
> to be implemented shortly).

> My guess is that at least multiarch and build hardening would have become
> GRs about five years ago.

None of these except possibly build-arch (which I don't think many
people actually care about) seem at all controversial.  The issues with
all these things seem to be more to do with actually getting the work
done rather than any great debates.

Stefano Zacchiroli | 14 Mar 2012 09:43

Picon

Re: More votes in Debian? Any idea for improvement?

On Tue, Mar 13, 2012 at 09:51:08AM +0000, Anthony Towns wrote:
> I wonder if anyone can name three "big" controversies over the past few
> years that have gotten resolved within Debian?

To the examples provided by Russ, I'd like to add time-based freezes,
which we are doing for Wheezy. I think it fits your "not winner vs
loser" category, although it has been a quite sensitive controversy.

> The biggest controversies in free software that I've seen just aren't
> happening within Debian from what I've seen: Unity vs Gnome3 is an
> Ubuntu/Gnome thing; upstart vs systemd is an Ubuntu/Fedora thing; funding
> open source development is a Red Hat/Google/Intel/IBM/HP/Oracle/buxy
> thing...

Right, but all this are mostly upstream controversies. Some of them are
reified at the distribution level (e.g. Unity vs GNOME 3), but it is so
because Canonical is playing both in the upstream and distribution camp,
with a high level of interdependencies among the two. As of now, Debian
is not. We do have Debian Developers who are upstreams for popular
pieces of software, but they clearly distinguish their roles as upstream
and as packagers.

All this is not to say that we are necessarily good at resolving
technical conflicts. We are fairly good at doing so only when they are
clearly denotated as technical conflicts, via consensus or the Technical
Committee. But we are not particularly good at picking distribution wide
defaults (what is the default init system? what is the default desktop
experience? etc). This is, I believe, by construction of our decisions
mechanisms which are made to solve conflicts and not imposing a
technical lead to the project.

(Continue reading)

Russ Allbery | 14 Mar 2012 22:28

Picon

Re: More votes in Debian? Any idea for improvement?

Stefano Zacchiroli <zack <at> debian.org> writes:

> According to the constitution we can ask the Technical Committee to make
> such decisions. But we don't have the habit of doing so and I don't
> think the committee would scale if we would start doing so.

I believe the Technical Committee can do better, but I don't want to say
more than that unless I can actually make it happen, since words are
cheap.  :)

But that aside, the problem with having decisions made by a committee like
that is that it's the opposite of consensus-based decision-making, and
while it's much more expedient, my impression is that the decision quality
isn't quite as high and the project buy-in is *nowhere* near as high.  The
advantage of our messy and protracted decision-making process is that by
the time a decision finally gets spit out the other end, it's usually
rather uncontroversial and the project moves with remarkable unanimity.

That's why, for things like init systems, I'd much rather enable people to
poke at them and see if that helps consensus develop before trying
something more hierarchical.  Yes, it means that we don't move fast on
project-wide things, which means that we're not on the cutting edge of
development of such systems.  You can be more nimble with a hierarchical
structure and central decision-making.  But Debian isn't just about that;
it's also about being fun and being an engaged part of a volunteer
community, and the community properties of consensus decision-making are a
lot nicer, I think.

On that front, for example, I still think that the multiarch outcome was a
project failure.  Possibly an inevitable failure, but still a failure.  It

(Continue reading)

Stefano Zacchiroli | 15 Mar 2012 22:20

Picon

Re: More votes in Debian? Any idea for improvement?

On Wed, Mar 14, 2012 at 02:28:02PM -0700, Russ Allbery wrote:
> > According to the constitution we can ask the Technical Committee to make
> > such decisions. But we don't have the habit of doing so and I don't
> > think the committee would scale if we would start doing so.
> 
> I believe the Technical Committee can do better, but I don't want to say
> more than that unless I can actually make it happen, since words are
> cheap.  :)

Well, this is actually a very important point for this discussion 

On the paper of the Constitution, the Technical Committee is already all
we need to "cover up" for cases where decision by consensus does not
work (I'm specifically thinking at §6.1.1 "Deciding on any matter of
technical policy" and §6.1.3 "Make a decision when asked to do so"
here). 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. We're ready to "take the risk" when there is a
conflict which seems impossible to solve otherwise, but not otherwise.
No matter all the negative aspects of the recent multiarch conflict, I
hope people have appreciated that the Technical Committee has been able
to decide in a *very* timely manner. And I also understand that, for
conflicts, letting things linger might actually be a feature, rather
than a bug.

But I've the impression there are areas that do not quality as conflicts

(Continue reading)

Russ Allbery | 18 Mar 2012 00:19

Picon

Re: More votes in Debian? Any idea for improvement?

Stefano Zacchiroli <zack <at> debian.org> writes:

> On the paper of the Constitution, the Technical Committee is already all
> we need to "cover up" for cases where decision by consensus does not
> work (I'm specifically thinking at §6.1.1 "Deciding on any matter of
> technical policy" and §6.1.3 "Make a decision when asked to do so"
> here). 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.

(Continue reading)

Stefano Zacchiroli | 20 Mar 2012 22:10

Picon

Re: More votes in Debian? Any idea for improvement?

On Sat, Mar 17, 2012 at 04:19:46PM -0700, Russ Allbery wrote:
> Stefano Zacchiroli <zack <at> 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

(Continue reading)

Russ Allbery | 20 Mar 2012 22:54

Picon

Re: More votes in Debian? Any idea for improvement?

Stefano Zacchiroli <zack <at> 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.

(Continue reading)

Gergely Nagy | 13 Mar 2012 12:25

Picon

Re: More votes in Debian? Any idea for improvement?

Hi!

Thomas Goirand <zigo <at> debian.org> writes:

> If you see projects like Openstack or oVirt (sorry for the examples
> taken from my area of expertise...), they have elections every 6 months
> for project leaders in this or that area of the project.
>
> In Debian, we just elect a DPL, and then we hope that he appoints people
> who then can make decisions on the behalf of Debian.

My opinion on this is very similar to Zack's and Wouters: technical
decisions should be made by the appropriate teams, not by voting, unless
absolutely neccessary.

There are multiple reasons for that, including, but not limited to:

 * The teams having more insight into their job than the project as a
   whole allows them to make better informed decisions more quickly.
 * We should not bring politics into technical decisions, that's never
   good. Appointing delegates is often a technical decision, and even if
   it has other components, the tech part of it is still significant.
 * Debian is a do-ocracy in many areas, recognising that with delegation
   is, in my opinion, the right way to do it. Turn it into a vote, and
   then it will quickly become a talk-ocracy.
 * Generally, we should trust our teams to do their jobs well. In case
   of problems, we have ways to fix it (revoking delegations,
   etc). Reassuring team member positions by a project-wide wrote every
   year (every 6 months would be even worse!) would just put extra
   burden on both the Developer body as a whole, and the team members

(Continue reading)

Return

Return to gmane.linux.debian.devel.vote.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane