More votes in Debian? Any idea for improvement?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

More votes in Debian? Any idea for improvement?

Thomas Goirand-3
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)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4F5CFCF5.5050904@...

Reply | Threaded
Open this post in threaded view
|

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

Wouter Verhelst
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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120312080405.GZ22670@...

Reply | Threaded
Open this post in threaded view
|

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

Stefano Zacchiroli
In reply to this post by Thomas Goirand-3
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
> 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

There are problem with delegations, yes. We have two kinds of them
"permanent" (i.e. until step down or recall) and time-based and both
have issues:

- permanent delegations do not encourage periodic self-assessment of
  delegates on whether they are still motivated to do the job; they also
  risk to create power niches that require a lot of energy to fix, due
  to social awkwardness.

- time-based delegations do not have those issues, but put the burden on
  the DPL who periodically needs to renew them, and hence risk to become
  a bottleneck

Delegations are a bit of an archaic device. It made a lot of sense in
the era of Free Software "benevolent dictators", but that era seems to
be fading away more and more, at least for large projects. And indeed we
have adapted our use of delegations over time. The fact the elected DPL
can recall or appoint delegates is very useful, as it balances power,
and has indeed saves us in the past. But these days, and outside those
exceptional situations, no one would expect the DPL to, say, appoint or
recall a "core team" member without the team consent. Those teams are
already self regulating a lot. IME the DPL "simply" watches out for
teams who are in need of re-staffing or staff change and actively
proposes that, possibly looking for candidates, if the team is not doing
that in autonomy.

But the above is quite a burden and in the end makes the DPL job not
particularly scalable and highly dependent on experience and "people
skills". There are established alternative solutions these days and I
think we should learn from them. For instance, other projects have
various kinds of self-determining boards with non-synchronized
time-limited membership. At each expiry a new member can get in or the
old one can try again; who gets in depend on the collective decision of
the others, non-expired, members.

The above can be done in very lightweight ways, would encourage periodic
self-assessment of motivations, would discourage the formation of power
niches, and still would not be prone to choosing the "more popular" (but
possibly unfit for the team in question) among wannabe members. I've
been studying what others projects have been doing on this front and I
look with favor at similar micro-governance models.

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 (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Stefano Zacchiroli <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87aa3lxv8v.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Anthony Towns-2
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
thing...

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...), or "what does Constantly
Usable Testing actually mean" (afaict resolved by effectively leaving
that project on hold so it doesn't have to be answered).

But maybe I've just missed a bunch of interesting contentious issues
Debian's resolved without a vote over the past few years?

Cheers,
aj


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120313095108.GA27905@...

Reply | Threaded
Open this post in threaded view
|

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

Gergely Nagy-8
In reply to this post by Thomas Goirand-3
Hi!

Thomas Goirand <[hidden email]> 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
   for, I believe, no real gain.

> 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...).

There are things that work for other projects, but don't work for
us. Excessive voting is one of those things. It works well if you have a
small core of about a dozen people or thereabouts. If you have close to
a thousand, even if only a third of those actively participate in
voting, that's still a huge number.

We also have a lot of teams, who just get the job done. I see no reason
to hinder their performance by making their position a matter of voting:
most likely, they'd be appointed anyway, and we wates time and effort of
both the team members, and of the voters too.

> 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.

I disagree. I believe in do-ocracy, and that it has served us well over
the years, and I'm confident it will work in the future too. On the
other hand, I've seen projects that strived to be openly governed fall
flat to their face and accomplish nothing.

Direct votes introduce an unneccessary burden and a bit too much
politics into what is almost entirely a technical decision best left to
be made by those who work in or close to that area.

> 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...).

I believe it still takes less time, and only from a handful of people,
than a vote would, and the results would be pretty much the same.

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

There are of course, shortcomings of the current system (see Zack's
explanation), which might be improved upon.

The idea of self-determining, non-synchronized time-limited memberships
is interesting, but for that to work, we'd need a slightly larger pool
of people to work with. That happens to be very much in scope for my
plan of encouraging people to work with the core teams, and to make
those key positions and teams more attractive.

In summary, I find project-wide voting boring and unneccessary. Once or
twice a year is more than enough, more would be counter
productive. Smaller-scale votes, within teams is another thing, that can
work, and can result in improvement, but that has a few prerequisites to
function well - see above!

--
|8]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87obs0hheb.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
In reply to this post by Anthony Towns-2
Anthony Towns <[hidden email]> 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.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87k42otq82.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Stefano Zacchiroli
In reply to this post by Anthony Towns-2
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.

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. The Release
Team play in a similar playground for picking some defaults, but we
similarly have the habit of not asking them to do it "too much" either.

If you look at other projects, younger than Debian, who have probably
chosen to do differently in the above matters "learning" from us, you'll
notice that they have some sort of Technical Board. Those boards have
periodical meetings and make pro-active, project-wide technical
decisions on behalf of their projects.

*If* we want to tackle the "default picking" and similar choices
properly, technical board is likely the way to go. But that would be a
fundamental change in how we do things and it will have some negative
effects. Whether we want to go there or not is something I've been
asking myself since quite a while, without a clearly winning answer (yet
:-)).

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 (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Stefano Zacchiroli <[hidden email]> 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
was less of a failure than a GR would have been, though.

> If you look at other projects, younger than Debian, who have probably
> chosen to do differently in the above matters "learning" from us, you'll
> notice that they have some sort of Technical Board. Those boards have
> periodical meetings and make pro-active, project-wide technical
> decisions on behalf of their projects.

> *If* we want to tackle the "default picking" and similar choices
> properly, technical board is likely the way to go. But that would be a
> fundamental change in how we do things and it will have some negative
> effects. Whether we want to go there or not is something I've been
> asking myself since quite a while, without a clearly winning answer (yet
> :-)).

My gut feeling is that it would lose a lot of what makes Debian special.
But I tend to be a fairly conservative sort of person about changes like
this, which is why I work on standards documents.  :)

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87vcm6c1p9.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Thomas Goirand-3
In reply to this post by Wouter Verhelst
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
around you physically (for example, our friends from Latin America)?

Thomas


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4F619620.9050805@...

Reply | Threaded
Open this post in threaded view
|

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

Wouter Verhelst
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
this person is the best for the job", which seems like exactly the
opposite.

I'm saying there are a number of jobs that require experts, not elected
representatives. These people should know better than other people what
they're doing (precisely because they are experts).

Now, while an elected representative can theoretically be an expert in a
specific field, this will never be by virtue of being elected.
Therefore, we should not put elected representatives in jobs that
require experts; and while it may be that there are other jobs than just
the one of the DPL that would benefit from elected representatives, I
don't think there are that many.

--
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120315141012.GA12264@...

Reply | Threaded
Open this post in threaded view
|

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

Thomas Goirand-3
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
> 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! :)

So, in case you think the DPL should know better, please answer my
questions about it.

> I'm saying there are a number of jobs that require experts, not elected
> representatives.

IMO, there are key positions that we (I mean, all DDs) all should be
able to appoint, because we all understand what the work is (for
example, ftp team, release team, etc.), and some where we know less (for
example DSA...). Thoughts?

Thomas


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4F62266B.7070505@...

Reply | Threaded
Open this post in threaded view
|

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

Wouter Verhelst
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
very idea behind elections is that the electorate selects someone whom
they think will represent their best interests; whom the electorate
believes will make decisions that are in line with what they, as a
group, think is necessary. This is why there's a need for campaigning:
it should allow voters to gauge whether the candidates' opinions are in
line with your own (or at least, which candidate's opinion is most in
line with yours).

So, the DPL is supposed to represent the electorate's opinion; he
doesn't know better or worse than the electorate; he knows exactly as
well as the electorate.

At least, that's the theory. Of course, in practice, things don't go
that black and white, and thus it's the elected person's responsibility
to make a reasonable effort to get some consensus about the possible
choices, before making a decision. We even have that in our
constitution.

In even more practice, in Debian usually the choice of whom to appoint
as a delegate is a choice between 'Person A' or 'Nobody'. The choice
there is usually fairly obvious. Also, the point in time where a DPL
appoints a delegate is usually far beyond the point where the delegate
started doing the work, anyway.

And at any rate, even if that isn't the case currently, I think it
should be; so if I am elected as DPL, I don't think I will appoint
people as delegates who're not already doing the work in question,
except in extreme circumstances.

> > I'm saying there are a number of jobs that require experts, not elected
> > representatives.
>
> IMO, there are key positions that we (I mean, all DDs) all should be
> able to appoint, because we all understand what the work is (for
> example, ftp team, release team, etc.), and some where we know less (for
> example DSA...). Thoughts?

I think I understand what you mean now, but I disagree with it, for
reasons as stated above.

--
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120315181053.GD22316@...

Reply | Threaded
Open this post in threaded view
|

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

Stefano Zacchiroli
In reply to this post by Russ Allbery-2
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
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. 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.

We don't seem to have the right devices to decide on those issue
either. Discussion on -devel are not particularly good to give the
feeling of consensus for instance, even when the consensus might exist
among project members: they're too easy to polarize. Thanks to people
like you, we manage to have useful discussions, but I can't help the
feeling that there is a disproportion in the energy we put into those
discussions and the actual results.

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.

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 (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Stefano Zacchiroli <[hidden email]> 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.

> 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.

> 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.

> 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.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/878viyq0h9.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Stefano Zacchiroli
On Sat, Mar 17, 2012 at 04:19:46PM -0700, Russ Allbery wrote:

> Stefano Zacchiroli <[hidden email]> 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 »

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
Stefano Zacchiroli <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87d3877xbq.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Mark brown-22
In reply to this post by Russ Allbery-2
On Tue, Mar 13, 2012 at 09:34:05AM -0700, Russ Allbery wrote:
> Anthony Towns <[hidden email]> 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.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120328154919.GC23005@...