Constitutional amendment: reduce the length of DPL election process

[Anthony Towns]

Oh, that reminds me.

I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
voting period to two weeks. In wdiff format:

=====
5.2. Appointment

1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Nominations this year were:

1st week (4th-10th):
Gustavo Franco (5th)
Wouter Verhelst (6th)
Sven Luther (6th)
Aigars Mahinovs (9th)
2nd week (11th-17th):
Sam Hocevar (14th)
3rd week (18th-24th):
Steve McIntyre (19th)
Raphael Hertzog (20th)
Anthony Towns (23rd)
Simon Richter (23rd)

Nominations in 2006 were:

1st week (5th - 11th)
Lars Wirzenius (10th - withdrawn on the 23rd)
2nd week (12th - 18th)
Ari Pollak (18th)
3rd week (19th - 26th)
Jeroen van Wolffelaar (19th)
Steve McIntyre (20th)
Anthony Towns (23rd)
Andreas Schuldei (23rd)
Ted Walther (25th)
Bill Allombert (26th)

Nominations in 2005 were:

1st week (7th - 13th)
Matthew Garrett (7th)
Andreas Schuldei (7th)
2nd week (14th - 20th)
3rd week (21st - 27th)
Angus Lees (24th)
Anthony Towns (25th)
Jonathan Walther (26th)
Branden Robinson (27th)

That seems to imply people nominate either more or less as soon as
nominations open, or a few days before they close (or, in Sam's case,
when the date's convenient for a bit of fun); so reducing it from three
weeks to one seems pretty feasible.

Likewise, all our other votes have only needed two weeks (or less in
the case of the recall votes) to resolve, so having an extra week for
DPL elections seems unnecessary.

Reducing the DPL election period from 17% of the year to 11% seems like
a win to me. YMMV.

Cheers,
aj

[Pierre Habouzit]

Post by Anthony Towns
Oh, that reminds me.
I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

I second that.

[Thijs Kinkhorst]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

I second this.


Thijs

[Steve McIntyre]

Post by Anthony Towns
Oh, that reminds me.
I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

[Neil McGovern]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded

[Ana Guerrero]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

Ana

[Julien Cristau]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

Cheers,
Julien

[Marc 'HE' Brockschmidt]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded. This was overdue.

Marc

[Andreas Barth]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

seconded.


Cheers,
Andi

[Wouter Verhelst]

Post by Anthony Towns
Oh, that reminds me.
I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====
Gustavo Franco (5th)
Wouter Verhelst (6th)
Sven Luther (6th)
Aigars Mahinovs (9th)
Sam Hocevar (14th)
Steve McIntyre (19th)
Raphael Hertzog (20th)
Anthony Towns (23rd)
Simon Richter (23rd)
1st week (5th - 11th)
Lars Wirzenius (10th - withdrawn on the 23rd)
2nd week (12th - 18th)
Ari Pollak (18th)
3rd week (19th - 26th)
Jeroen van Wolffelaar (19th)
Steve McIntyre (20th)
Anthony Towns (23rd)
Andreas Schuldei (23rd)
Ted Walther (25th)
Bill Allombert (26th)
1st week (7th - 13th)
Matthew Garrett (7th)
Andreas Schuldei (7th)
2nd week (14th - 20th)
3rd week (21st - 27th)
Angus Lees (24th)
Anthony Towns (25th)
Jonathan Walther (26th)
Branden Robinson (27th)
That seems to imply people nominate either more or less as soon as
nominations open, or a few days before they close (or, in Sam's case,
when the date's convenient for a bit of fun); so reducing it from three
weeks to one seems pretty feasible.
Likewise, all our other votes have only needed two weeks (or less in
the case of the recall votes) to resolve, so having an extra week for
DPL elections seems unnecessary.
Reducing the DPL election period from 17% of the year to 11% seems like
a win to me. YMMV.

I can only second this.

While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

But I don't feel too strong about this, and I'll second the above
anyhow.

[Russ Allbery]

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

I will definitely second such a proposal, unless former DPLs come forward
to say that this just wouldn't work for some reason. I've felt the same
thing for a while as well. One year isn't much time to get anything done;
it's barely enough time to build up the rapport required to start getting
things done.

[Pierre Habouzit]

Post by Russ Allbery

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

I will definitely second such a proposal, unless former DPLs come forward
to say that this just wouldn't work for some reason. I've felt the same
thing for a while as well. One year isn't much time to get anything done;
it's barely enough time to build up the rapport required to start getting
things done.

I'd prefer to see sth even a bit different: that the mandate is 2
years, and elections every 1.5 years, so that there is a 6 month overlap
to create some kind of continuation between DPLs. I've never been DPL
(AFAICT) and maybe those who have been can confirm/refute but I'd say
that I would love to have such an overlap to be able to continue things
the previous DPL started smoothly.

Okay some details like who is really in charge during the overlaps has
to be sorted out, but well ..

[Lars Wirzenius]

Post by Russ Allbery
I will definitely second such a proposal, unless former DPLs come forward
to say that this just wouldn't work for some reason.

I'd like to hear that, too.

Speaking as someone who once almost was a candidate, I would like to
point out that a two-year commitment is rather more difficult to make
for many people than a one-year commitment. That is not a reason to
avoid doing it, but it should be considered.

[Julien BLACHE]

Post by Lars Wirzenius
Speaking as someone who once almost was a candidate, I would like to
point out that a two-year commitment is rather more difficult to make
for many people than a one-year commitment. That is not a reason to
avoid doing it, but it should be considered.

Note that you're still free to step down after one year, so that's
hardly a problem (of course it's better if you announce your intention
to serve only for one year during the campaign...).

I'd rather see something added to the proposal that would allow us to
remove the DPL after one year without having to go through a recall. A
mid-term 2-week vote or something.

JB.

[Lars Wirzenius]

Post by Julien BLACHE

Post by Lars Wirzenius
Speaking as someone who once almost was a candidate, I would like to
point out that a two-year commitment is rather more difficult to make
for many people than a one-year commitment. That is not a reason to
avoid doing it, but it should be considered.

Note that you're still free to step down after one year, so that's
hardly a problem (of course it's better if you announce your intention
to serve only for one year during the campaign...).

"I know the job is for two years, but I only want to do half the job, so
please vote for me, I'm better than those others who are willing to do
the whole job."

I would not vote for such a candidate; I would not be such a candidate.
Your mileage may vary, of course: I am not suggesting my sense of doing
the right thing is the right one for everyone.

[Julien BLACHE]

Lars Wirzenius <***@liw.iki.fi> wrote:

Hi,

Post by Lars Wirzenius
"I know the job is for two years, but I only want to do half the job, so
please vote for me, I'm better than those others who are willing to do
the whole job."

I'd better have someone do the job for only one year than someone not
doing the job for two years, but YMMV :)

JB.

[Martin Michlmayr]

Post by Julien BLACHE
Note that you're still free to step down after one year, so that's
hardly a problem

I don't think anyone would do that. It takes quite a bit to convince
yourself to step down and then actually go through with it.

[Wouter Verhelst]

Post by Russ Allbery

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

I will definitely second such a proposal, unless former DPLs come forward
to say that this just wouldn't work for some reason.

Yes, indeed. One of the main reasons why I haven't brought this up
before is the understanding that being a DPL is a very demanding job,
and that perhaps two years might be too long. Add the observation that
Martin Michlmayr just wasn't very active anymore near the end of his
second term, as is the case for Wichter Akkerman, and you'll understand
why I do have second thoughts.

OTOH, probably a longer term sets other expectations, and it won't be so
much of a problem. Still, the input of some ex-DPL on that point is
surely valuable.

Post by Russ Allbery
I've felt the same thing for a while as well. One year isn't much
time to get anything done; it's barely enough time to build up the
rapport required to start getting things done.

Exactly.

[Martin Michlmayr]

Post by Russ Allbery
I will definitely second such a proposal, unless former DPLs come
forward to say that this just wouldn't work for some reason. I've
felt the same thing for a while as well.

I don't think it's a good idea to increase the time of a DPL term. As
Lars says, it's much harder to make a two-year commitment and from
personal experience I can tell you that being DPL takes a lot of
energy and time. I think a year is good and if the person wants to do
it again they can simply stand for re-election.

Post by Russ Allbery
One year isn't much time to get anything done; it's barely enough
time to build up the rapport required to start getting things done.

You really need to build up rapport and have good contacts before
running for DPL. Also, I think we've seen with a number of DPLs (if
not most) that they were more active at the beginning of their term,
so making it even longer wouldn't help. I also don't really buy the
argument that a year isn't enough to get things done. And there's
always the chance of getting re-elected if someone did a good job.

[Joey Hess]

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

I'd probably second that, but I'd really appreciate hearing from past
and present DPLs, as well as DPL candidates, to decide how to vote on
it.

PS, probably too obvious to mention, but such an amendment needs to only
take effect at the next election cycle.

[Wouter Verhelst]

Post by Joey Hess
PS, probably too obvious to mention, but such an amendment needs to only
take effect at the next election cycle.

Yes, no doubt about that.

[Sam Hocevar]

Post by Joey Hess

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

I'd probably second that, but I'd really appreciate hearing from past
and present DPLs, as well as DPL candidates, to decide how to vote on
it.

I fear that a two-year period might frighten away people who may have
done a great job for one year. And I really think we need the dynamism
provided by the short term we currently have. I already said several
times that I would not run again next year anyway because I feel new
ideas are needed.

And it's not like the newly elected DPL spends the beginning of the
term undoing what the previous one was doing: projects that were started
will not suddenly stop. There can be collaboration, 2ICs or any form of
delegation to continue the projects.

That's my 2 cents, I'll tell you in 6 months whether I still feel the
same.

Cheers,

[Raphael Hertzog]

Post by Joey Hess

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

I'd probably second that, but I'd really appreciate hearing from past
and present DPLs, as well as DPL candidates, to decide how to vote on
it.

I've been thinking a bit on that as well. While I'm all for some
continuity and to give some more time, it would be more difficult for me
to decide to stand if the goal is to stay in the position for two years.

IMHO it would only make sense if we switched to a team-based DPL position
because the requirement are then lowered for each individual. That said
nothing is preventing people like me to propose a team while others who
are more confident on their long-term availability/energy can stand alone.

In the end, while 2 years is really long, 18 months might be ok.
Furthermore it gives a reasonable chance to each DPL to have a release
within their terms.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

[Moritz Muehlenhoff]

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

Please formulate a GR and I'll second it immediately. 18-24 months seems
sensible, annual elections are a waste of everyone's time.

Cheers,
Moritz

[Steve Langasek]

Post by Moritz Muehlenhoff

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

Please formulate a GR and I'll second it immediately. 18-24 months seems
sensible, annual elections are a waste of everyone's time.

I know, we should set the DPL term to be equal to the release cycle; that
way the DPL will be suitably encouraged to make sure the release never
stalls out ;)

[Anthony Towns]

Post by Steve Langasek

Post by Moritz Muehlenhoff
Please formulate a GR and I'll second it immediately. 18-24 months seems
sensible, annual elections are a waste of everyone's time.

I know, we should set the DPL term to be equal to the release cycle; that
way the DPL will be suitably encouraged to make sure the release never
stalls out ;)

Or be encouraged to ensure it always stalls out -- malevolent dictator
for life!

But at least the DPL candidates for the next term would be so encouraged,
and there's more of them, so maybe it'd work out anyway!

Personally, I think annual elections are a good thing, pretty much for the
reasons outlined by Jeff in:

http://lists.linux.org.au/archives/linux-aus/2005-July/msg00030.html

That seems to work better elsewhere than in Debian; it might be to do
with electing a group rather than an individual, or it could be more
specific to Debian -- we at least tend to spend more time and effort on
the campaigning part than other groups do, from what I've seen, so that
might make a difference.

Having it be one year or two wouldn't have changed whether I'd run or
not. It might've let me spend two months on each thing rather than one
month, which might've been more effective; but I don't think it would've
changed the way dunc-tank or the release went. I imagine I'd've been more
comfortable continuing as DPL after the recall stuff had I been re-elected
this year, than if it'd just been a two-year term, but I don't know.

I think it's worth noting that the DPL terms so far have been routinely
short:

Ian Murdock: 2 years, 7 months
Bruce Perens: 1 year, 8 months
Ian Jackson: 1 year
Wichert Akkerman: 2 years, 2 months
Ben Collins: 1 year
Bdale Garbee: 1 year
Martin Michlmayr: 2 years
Branden Robinson: 1 year
Anthony Towns: 1 year
Sam Hocevar: 3 months and counting

Huh, going by the repeating 2-1-1 pattern, Sam's due for a two year stint.

Cheers,
aj

[Wouter Verhelst]

Post by Anthony Towns
Personally, I think annual elections are a good thing, pretty much for the
http://lists.linux.org.au/archives/linux-aus/2005-July/msg00030.html

I'll summarize those as "if people want continuity in people on (the
board/the DPL position/whatever), they can re-elect them".

I don't think it works that way. Given an apparently non-active
incumbent and a much-promising challenger, people are more likely to
vote for the much-promising challenger (provided this challenger is
promising what the electorate wants, of course). It doesn't matter
whether the incumbent is really non-active, or whether they've had to do
much behind-the-scenes work to be able to get something done. Having a
two-year term allows them a bit more leeway in that regard. But that's
just my opinion; YMMV, and I never got any classes in anything related
to political sciences.

Additionally, I do think that having a vote about a new leader every
year gets old rather quickly, with the electorate having hardly
forgotten the previous elections as the next already start.

[Don Armstrong]

Post by Wouter Verhelst

Post by Anthony Towns
Personally, I think annual elections are a good thing, pretty much for the
http://lists.linux.org.au/archives/linux-aus/2005-July/msg00030.html

I'll summarize those as "if people want continuity in people on (the
board/the DPL position/whatever), they can re-elect them".
I don't think it works that way. Given an apparently non-active
incumbent and a much-promising challenger, people are more likely to
vote for the much-promising challenger (provided this challenger is
promising what the electorate wants, of course).

Part of this really comes down to communication, though. It's often
only at election time that we start to get an inkling of the
constraints which have been placed on the end-of-term DPL and what
needs to be done to actually realize the goals initially promised.

Not communicating successfully what is happening as the DPL (and often
more importantly, what is blocking and/or stoping things from
happening) is one of the reasons why incumbant DPLs have a hard time
getting re-elected.

I've no real problem with failing to re-elect in these cases.


Don Armstrong

[Anthony Towns]

Post by Wouter Verhelst

Post by Anthony Towns
Personally, I think annual elections are a good thing, pretty much for the
http://lists.linux.org.au/archives/linux-aus/2005-July/msg00030.html

I'll summarize those as "if people want continuity in people on (the
board/the DPL position/whatever), they can re-elect them".
I don't think it works that way.

Well, it does elsewhere. On the other hand, there were a couple of
assumptions in Jeff's message that don't seem to apply to Debian:

] We don't have a lot of churn and we don't have too many people standing for
] the committee. Thus, elections are more of a checkpoint than an earthquake.
] They give the committee the opportunity to step back, reassess, take new
] ideas into account, and move on. Plus, it's unlikely that former members
] would completely disappear - they can always help the transition.

I mean: we do have a fair bit of churn, we do have a bunch of people
standing for DPL (eight or nine people per position, as opposed to SPI's
latest election which had 2.2 people per position, eg), elections do
have a bit of a tendency towards being earthquakes, and former members
often do disappear...

Cheers,
aj

[Paul Cager]

Post by Steve Langasek
I know, we should set the DPL term to be equal to the release cycle; that
way the DPL will be suitably encouraged to make sure the release never
stalls out ;)

"How long will you be DPL?"
"I'll go when I'm ready to go..."

[Martin Schulze]

Post by Moritz Muehlenhoff

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

Please formulate a GR and I'll second it immediately. 18-24 months seems
sensible, annual elections are a waste of everyone's time.

FWIW, I believe that 2 years is too long, both for the DPL who may have
to assign much more time to it than now, and for the project that may
suffer under one DPL and would suffer even longer.

Regards,

Joey

[Marc Haber]

Post by Martin Schulze
FWIW, I believe that 2 years is too long, both for the DPL who may have
to assign much more time to it than now, and for the project that may
suffer under one DPL and would suffer even longer.

If the project realls suffers, there could be a mechanism to impeach
the DPL.

I think that a longer term could be a good idea. There must be a
reason why DPLs are usually invisible and unable to address the real
problems in the project.

Greetings
Marc

[Martin Schulze]

Post by Marc Haber
I think that a longer term could be a good idea. There must be a
reason why DPLs are usually invisible and unable to address the real
problems in the project.

Which, of course and quite naturally, simply vanish when they take the
burdon of being DPL another year.

Regards,

Joey

[Marc Haber]

Post by Martin Schulze

Post by Marc Haber
I think that a longer term could be a good idea. There must be a
reason why DPLs are usually invisible and unable to address the real
problems in the project.

Which, of course and quite naturally, simply vanish when they take the
burdon of being DPL another year.

I didn't say that. I just suggested that it might be easier to do big
changes if one has adequate time to prepare.

Greetings
Marc

[Wouter Verhelst]

Post by Martin Schulze

Post by Moritz Muehlenhoff
Please formulate a GR and I'll second it immediately. 18-24 months seems
sensible, annual elections are a waste of everyone's time.

FWIW, I believe that 2 years is too long, both for the DPL who may have
to assign much more time to it than now, and for the project that may
suffer under one DPL and would suffer even longer.

I don't think "suffer" under a DPL is the right word. Never the less, I
do not intend to touch the recall vote procedure, so I don't think this
could go too far.

[Mike Bird]

Post by Martin Schulze
FWIW, I believe that 2 years is too long, both for the DPL who may have
to assign much more time to it than now, and for the project that may
suffer under one DPL and would suffer even longer.

I wonder if a better course might not be to keep the term at one year
but move the election forward three months. Not many people can commit
to a year of being DPL on short notice. Being DPL-in-waiting for a few
months allows people to organize their personal lives and also provides
time to prepare for the major projects they intend to pursue as DPL.

--Mike Bird, non-DD

[Wouter Verhelst]

Post by Wouter Verhelst
While we're at it, I've long felt that a one-year DPL term is just too
short (because a DPL needs to spend a few months to get worked in, and
can't do all that much when the next election is about to turn up for
fear of being accused to be campaigning, often leaving only slightly
over half a year or so of time for real work to be done). If more people
feel like it, I'll draft up an amendment that turns it into a two-year
term, or so.

Since this mail, I've asked Martin Michlmayr, Wichert Akkerman, Bdale
Garbee and Branden Robinson about their opinion regarding this post; and
we've also seen replies from Sam Hocevar and Anthony Towns. Some have
replied on-list, others only through IRC.

The most supportive response was Bdale's, who said he had "mixed
feelings" about it; everyone else thought it was a bad idea.

In that light, I do not think it would be very smart to force this
issue, so I'm not going to make it a formal amendment.

Regards,

[Russ Allbery]

Post by Wouter Verhelst
Since this mail, I've asked Martin Michlmayr, Wichert Akkerman, Bdale
Garbee and Branden Robinson about their opinion regarding this post; and
we've also seen replies from Sam Hocevar and Anthony Towns. Some have
replied on-list, others only through IRC.
The most supportive response was Bdale's, who said he had "mixed
feelings" about it; everyone else thought it was a bad idea.
In that light, I do not think it would be very smart to force this
issue, so I'm not going to make it a formal amendment.

Thank you for doing the research for this, Wouter. I've been wondering
for a while whether this would be a good idea, and it's very good to get
concrete information.

[Nico Golde]

Hi,

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the

[...]
I second this.
Kind regards
Nico

[Aníbal Monsalve Salazar]

Post by Thijs Kinkhorst
Hi,

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the

[...]
I second this.

According to § 3 of the "Procedures for submitting a General
Resolution proposal or amendment" [¹] you are _only_ seconding items
5.2.1 trough 5.2.3 and part of 5.2.4.

Is that what you would like to do?

¹ http://www.debian.org/vote/howto_proposal

Post by Thijs Kinkhorst
Kind regards
Nico
--
For security reasons, all text in this mail is double-rot13 encrypted.

Met vriendelijke groet,

Aníbal Monsalve Salazar

[Thijs Kinkhorst]

Post by Aníbal Monsalve Salazar

Post by Nico Golde
For security reasons, all text in this mail is double-rot13 encrypted.

Met vriendelijke groet,

Your Dutch seems up to par, but why are you talking Dutch to a German guy? Or
am I splitting West Germanic hairs here?


Thijs

[Nico Golde]

Hi,

Post by Aníbal Monsalve Salazar

Post by Thijs Kinkhorst
Hi,
[...]
I second this.

According to § 3 of the "Procedures for submitting a General
Resolution proposal or amendment" [¹] you are _only_ seconding items
5.2.1 trough 5.2.3 and part of 5.2.4.
Is that what you would like to do?
¹ http://www.debian.org/vote/howto_proposal

Thanks for pointing me out to this, I wanted to second all
items.
Kind regards
Nico

[Steffen Joeris]

Post by Anthony Towns
I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

Cheers
Steffen

[Amaya]

I fully second the quoted text

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

[Joerg Jaspert]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

[Frederik Schueler]

Hello,

Post by Anthony Towns
I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.


Best regards
Frederik Schüler

[Joey Hess]

Post by Anthony Towns
Reducing the DPL election period from 17% of the year to 11% seems like
a win to me. YMMV.

Well, you could get to 5.5% then by only electing the DPL once every 2
years.

[Don Armstrong]

Post by Anthony Towns
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.

Is there any reason to reduce this time period? Having a buffer zone
of three weeks is useful for continuity and/or cases where the
nomination period must be extended (though it leads to a short lame
duck period).


Don Armstrong

[MJ Ray]

Post by Don Armstrong

Post by Anthony Towns
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.

Is there any reason to reduce this time period? Having a buffer zone
of three weeks is useful for continuity and/or cases where the
nomination period must be extended (though it leads to a short lame
duck period).

I agree. No reason was given AFAICS, so I propose:

==== AMENDMENT PROPOSAL ====
Point 2 remains as before; that is, it will still read:
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====

and I ask for seconds.

Regards,
- --
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

[Aníbal Monsalve Salazar]

Post by MJ Ray
==== AMENDMENT PROPOSAL ====
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====

Seconded.

Aníbal Monsalve Salazar

[Simon Richter]

Hi,

Post by MJ Ray
==== AMENDMENT PROPOSAL ====
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====

Seconded.

Simon

[Felipe Augusto van de Wiel (faw)]

Post by MJ Ray
==== AMENDMENT PROPOSAL ====
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====

Seconded.

Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"

[Wesley J. Landaker]

Post by MJ Ray
==== AMENDMENT PROPOSAL ====
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====
and I ask for seconds.

Seconded.

[Gaudenz Steinlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Don Armstrong

Post by Anthony Towns
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.

Is there any reason to reduce this time period? Having a buffer zone
of three weeks is useful for continuity and/or cases where the
nomination period must be extended (though it leads to a short lame
duck period).

==== AMENDMENT PROPOSAL ====
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====
and I ask for seconds.

seconded.

Regards,
- --
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGtv1tmUY5euFC5vQRAhiYAJ4+xFCBeWWsx3/a4vYgawPczh8R2QCgjPUs
IdfLHM6ubbxd9NHnmGmyv4A=
=Jv11
-----END PGP SIGNATURE-----
--

[Lucas Nussbaum]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Don Armstrong

Post by Anthony Towns
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.

Is there any reason to reduce this time period? Having a buffer zone
of three weeks is useful for continuity and/or cases where the
nomination period must be extended (though it leads to a short lame
duck period).

==== AMENDMENT PROPOSAL ====
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====
and I ask for seconds.

I'm not sure if the formulation proposed by your amendment is totally
clear. It would be better to clarify who is the DPL during the 3 buffer
weeks at the end of the election process (between the end of the votes
and the end of the election).

I see a conflict between:
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
and:
8. The Project Leader serves for one year from their election.

Could you please clarify when the new elected DD effectively becomes the
DPL ?

Lucas

[MJ Ray]

Post by Lucas Nussbaum
I'm not sure if the formulation proposed by your amendment is totally
clear. [...]

It's as clear as it is now: DPL (not DPL-elect). The end of the
polling period is not necessarily the election date.

Notice polling closed before the DPL's election for a few years now:
http://www.fr.debian.org/vote/2007/vote_001
http://www.fr.debian.org/vote/2006/vote_002
http://www.fr.debian.org/vote/2005/vote_001
http://www.fr.debian.org/vote/2004/vote_001

This is not something new in the amendment I proposed.

Hope that explains,

[Steve McIntyre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Don Armstrong

Post by Anthony Towns
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.

Is there any reason to reduce this time period? Having a buffer zone
of three weeks is useful for continuity and/or cases where the
nomination period must be extended (though it leads to a short lame
duck period).

From AJ's original mail:

...

Likewise, all our other votes have only needed two weeks (or less in
the case of the recall votes) to resolve, so having an extra week for
DPL elections seems unnecessary.
Reducing the DPL election period from 17% of the year to 11% seems
like a win to me. YMMV.

[MJ Ray]

...

Post by Anthony Towns
Likewise, all our other votes have only needed two weeks (or less in
the case of the recall votes) to resolve, so having an extra week for
DPL elections seems unnecessary.

I see that as a reason to reduce the voting period, not the election.

Post by Anthony Towns
Reducing the DPL election period from 17% of the year to 11% seems
like a win to me. YMMV.

Such arbitrary calculations aren't reasons. One can just as well note
that the DPL election period is only approximately 0% of the period
where the DPL's decisions can have effects.

Regards,

[Wouter Verhelst]

Post by Don Armstrong

Post by Anthony Towns
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.

Is there any reason to reduce this time period? Having a buffer zone
of three weeks is useful for continuity and/or cases where the
nomination period must be extended (though it leads to a short lame
duck period).

Here's a reason: to reduce the period during which there is uncertainty
about the DPL's powers.

During elections, it's hard for an incumbent DPL to use his powers, for
fear of stuff like
http://lists.debian.org/debian-vote/2007/02/msg00162.html happening.

Right after the election (or vote, if you please), if the DPL-elect is
not the incumbent DPL and was elected on a platform that is sufficiently
different from the incumbent DPL's platform and/or conduct as DPL, then
having the incumbent DPL stay in office for too long is questionable.

The election period does not end when the vote ends, and so your
amendment defeats the whole purpose of aj's proposal.

[Don Armstrong]

Post by Wouter Verhelst
Here's a reason: to reduce the period during which there is
uncertainty about the DPL's powers.

There's really no uncertainty about them, though. The outgoing DPL is
still in power until the post becomes vacant at the end of the term.

Post by Wouter Verhelst
During elections, it's hard for an incumbent DPL to use his powers, for
fear of stuff like
http://lists.debian.org/debian-vote/2007/02/msg00162.html happening.

Reactions to doing your job during the entirely of your term are just
going to happen, some well thought out, some merely gut responses.
[That particular message isn't such a good example though, because
it's a reaction to something which was done which isn't a power of the
DPL by someone who was not the DPL.]

Post by Wouter Verhelst
Right after the election (or vote, if you please), if the DPL-elect
is not the incumbent DPL and was elected on a platform that is
sufficiently different from the incumbent DPL's platform and/or
conduct as DPL, then having the incumbent DPL stay in office for too
long is questionable.

I'm of the opinion that three weeks to bring all currently open
projects to a position where they can be smoothly transfered to the
DPL-elect is desirable.

Post by Wouter Verhelst
The election period does not end when the vote ends, and so your
amendment defeats the whole purpose of aj's proposal.

The election period does end, though. Only a transition period is
added in which can be used as a buffer zone in case the nomination
period and/or voting period needs to be extended.


Don Armstrong

[MJ Ray]

Post by Wouter Verhelst
Here's a reason: to reduce the period during which there is uncertainty
about the DPL's powers.

There is no uncertainty about the period of DPL powers. The power
transfer date has been clearly stated in recent years, hasn't it?

Post by Wouter Verhelst
During elections, it's hard for an incumbent DPL to use his powers, for
fear of stuff like
http://lists.debian.org/debian-vote/2007/02/msg00162.html happening.

Posting to d-d-a is power of ~all DDs. In fact, that's not the DPL
I'm complaining about. It would not have hurt for the 2IC to delay
that announcement, or at least part of it, for a week. That's just
one example of campaigning happening outside the campaign-only period,
which is the motivation for the other amendment I proposed.

[...]

Post by Wouter Verhelst
Right after the election (or vote, if you please), if the DPL-elect is
not the incumbent DPL and was elected on a platform that is sufficiently
different from the incumbent DPL's platform and/or conduct as DPL, then
having the incumbent DPL stay in office for too long is questionable.
The election period does not end when the vote ends, and so your
amendment defeats the whole purpose of aj's proposal.

The DPL-elect has not taken office when the vote ends for years now,
and that hasn't been a problem, has it? It would take a really petty
DPL to use their powers to sabotage the DPL-elect in the way being
suggested. Indeed, such acts are probably against the DPL procedures.
If we ever elect a really petty DPL, we've far bigger problems than
the handover weeks!

This amendment merely normalises the handover. Please support it.

Regards,

[Manoj Srivastava]

Hi,

Darn. I totally spaced out on the successful amendment to keep a
buffer zone of three weeks between the end of elections and the new
DPL's term. Could one of amendment proposers supply wording for the
ballot option? I hate my current wording.

Also, could one of the sponsors or seconds of the original
proposal supply WML for the web page, please? The amendment sponsors
have already done so for the amendment.

manoj


Voting period starts 00:00:01 UTC on Sunday, 23rd Sep 2007
Votes must be received by 23:59:59 UTC on Saturday, 06th Oct 2007

The following ballot is for voting on a Constitutional amendment:
reduce the length of DPL election process. The vote is being
conducted in accordance with the policy delineated in Section A,
Standard Resolution Procedure, of the Debian Constitution.

The details of the general resolution can be found at:
http://www.debian.org/vote/2007/vote_004

You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions contact ***@debian.org.

HOW TO VOTE

First, read the full text of the GR. The proposal is to change section
5.2 of the constitution concerning appointment of the Project Leader
to reduce the nomination period to a week, and the voting period to
two weeks. In wdiff format:
===========================================================================
5.2. Appointment

1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
===========================================================================

There has been one amendment proposed, which is identical to the
original proposal, except that it does not change section 5.2.2, and
thus creates a three week buffer between the end of the election and
the start of the new project leaders term:
==== AMENDMENT PROPOSAL ====
Point 2 remains as before; that is, it will still read:
2. The election begins nine weeks before the leadership post
becomes vacant, or (if it is too late already) immediately.
==== AMENDMENT PROPOSAL ====


Do not erase anything between the lines below and do not change the
choice names.

In the brackets next to your preferred choice, place a 1. Place a 2 in
the brackets next to your next choice. Do not enter a number smaller
than 1 or larger than 2. You may skip numbers. You may rank options
equally (as long as all choices X you make fall in the range 1<= X <= 2).

To vote "no, no matter what" rank "Further discussion" as more
desirable than the unacceptable choices, or You may rank the "Further
discussion" choice, and leave choices you consider unacceptable
blank. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices. (Note: if the Further
Discussion choice is unranked, then it is equal to all other unranked
choices, if any -- no special consideration is given to the Further
discussion choice by the voting software).

Then mail the ballot to: ***@vote.debian.org. Don't worry
about spacing of the columns or any quote characters (">") that your
reply inserts. NOTE: The vote must be GPG signed (or PGP signed)
with your key that is in the Debian keyring. You may optionally encrypt
your ballot using the public key included below. Also, note that you can
get a fresh ballot any time by sending a mail to ***@vote.debian.org
with the subject "gr_dm"


- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
acf05695-2c74-4751-a58a-ab7eb8282300
[ ] Choice 1: Reduce the length of DPL election process
[ ] Choice 2: As above, but keep the start 9 weeks before the end of current term
[ ] Choice 3: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

----------------------------------------------------------------------

The responses to a valid vote shall be signed by Devotee (DEbian VOTe
EnginE) using the vote key created for this vote. The public key
for the vote, signed by the Project secretary, is appended below.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)

mQGiBEb0n2ERBAD861UWYoMSoOcPyyc0Vp+MLIPPWXTKSvP3rWqs8suKywuMcZI5
Vl5JBm7D+vPkdKopoEPZVPLFx1k8keu3XQbWp6y+08aSrU5EYE5nrWPRgdRge7G6
lSdyWSAWbuQQLbplNhGczsonUBdvTsgS1SS0Dwhv7KtOX9bbfTjyUTSpHwCg5zVu
Oa0XYTXQdY3QvuwrOlHSZTsD/RWvWG8gdy+gvllPPjW4xKFxIGKjxx7dOfuizLDN
z/XDb/045Rv66b6EHXu1byU4d0presKx+Y0SYJNkF8nC2tRfCuUK4Ljngu9r2i6k
Tq2rNJG6CrjZiCV6Xpfn/Wbg5AonytVEo7hmaWamqMKt0VZjiLd8MQCasDLHjzCA
059YA/9TEKIEZ8kGrJC1q+n+woEcShy3vR3l3Bp8dlh5AaRVoGMfKxbTTAPbHYyW
zkmJ+nJrov4kiqc8TdgyvWCZ1EHyLqur6pt0G+Dk8LePsZBuTaD6lmAUO7niLbkL
OTSrC7eTPXQJM6/UL74nCZ382TfGhILfGT9OYzBjeWpootlmIbRRVGhlIERQTCBF
bGVjdGlvbiBwZXJpb2QgR1Igdm90ZSBLZXkgKEVwaGVtZXJhbCBLZXkpIDxncl9l
bGVjdGlvbkB2b3RlLmRlYmlhbi5vcmc+iGYEExECACYFAkb0n2ECGwMFCQAbr4AG
CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRDsAyjMizihr4/4AKCkAYTtNm+ICf68
jC91F4pI1xwXqgCfSWXLLatkSDXdNl8Z956TmFQMOFiIRgQQEQIABgUCRvSfwAAK
CRAhutq7vyRCTCSzAKD2RQ6A9tkG7tv0mNr8t7BfgKGzFQCg1tOTBzMjj3eNUikF
jcIWJoZUK3a5Ag0ERvSfZxAIAId2YkLYvk+TmcuzIeVJrTc5+2s0Nd0KSKxGsLys
HjEa1tw/hTVL1gJ5nSukWHdHWEYEUIGm0n7JDCvkavj0o83ya66lxM96DlRJc4bO
KWuKW3X7k99kFq7ZmOpqADZ7V+Tixm7WwDOPeXlnLOh1W9FwU+Lllu15OkMwDU6q
IydN4NYEqd1BbUHNZz5vbsHlXHAAXxiQScXtnf+zeKdCbmsSmZYk65bZo8hIwZC8
lYWNpP34SMJDevVBI7W2mNkE76vtp7GjceslLYFq5BE4wu9AEjuw0oQXeqv/xiCp
JxV9XTJw9T1/22FbqcsmwDOVBvVpHpZybkTn7CKjQScZFVsAAwUH/jRTDOkJeoa8
0zc0Xzi+dX5ut2qAim73k6Iyw6GY8rTiMM3UveRoDWfXl1ReCrAsXbIengEc1hRX
gcyfSsJhvG5091lE66xCYcAg3t9qGtwiPCDSHAjRXPMZPW6F+SyOM9l0mVrDmeiR
AqTs/yQ43I9VYSELlEUbT/KJ8TKX0+2QGhr0kWZMzt5lr40dEaRE1tiF1NY0JQQ1
2JR9WgVWrLev7UnnZD6TLcmAOAr6sNy7a7FwPoyzdbGXBAVm44daEFMGLszRlRta
dFxor+J7X3wvGJsFliEc50TzjYtqzRF5q8fG2/oUG8OPDVQdNuzf4ZchFGYGzg6I
F1283M/dFJWITwQYEQIADwUCRvSfZwIbDAUJABuvgAAKCRDsAyjMizihr1YyAKCq
STnjBvffJkCCFMGws9HUJTC5RwCeKgyg2BF5CtSBLxbSToxANubxNBg=
=7nE7
-----END PGP PUBLIC KEY BLOCK-----

[Aníbal Monsalve Salazar]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

Aníbal Monsalve Salazar

[Luk Claes]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

Cheers

Luk

[Alexander Schmehl]

Post by Anthony Towns
I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.


Yours sincerely,
Alexander

[Aurelien Jarno]

Post by Anthony Towns
Oh, that reminds me.
I propose we change section 5.2 of the constitution concerning appointment
of the Project Leader to reduce the nomination period to a week, and the
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

Cheers,
Aurelien

[Antti-Juhani Kaijanaho]

Post by Anthony Towns
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the leadership
post becomes vacant, or (if it is too late already) immediately.
3. For the [-following three weeks-] {+first week+} any Developer
may nominate themselves as a candidate Project [-Leader.-]
{+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there
are no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period during
which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished.
6. The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in section
A.6 of the Standard Resolution Procedure. The quorum is the same
as for a General Resolution (4.2) and the default option is "None
Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

[Konstantinos Margaritis]

Post by Anthony Towns
Oh, that reminds me.
I propose we change section 5.2 of the constitution concerning
appointment of the Project Leader to reduce the nomination period
=====
5.2. Appointment
1. The Project Leader is elected by the Developers.
2. The election begins [-nine-] {+six+} weeks before the
leadership post becomes vacant, or (if it is too late already)
immediately. 3. For the [-following three weeks-] {+first week+}
any Developer may nominate themselves as a candidate Project
[-Leader.-] {+Leader, and summarise their plans for their term.+}
4. For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning [-(to make their
identities-] and [-positions known).-] {+discussion.+} If there are
no candidates at the end of the nomination period then the
nomination period is extended for [-three further weeks,-] {+an
additional week,+} repeatedly if necessary.
5. The next [-three-] {+two+} weeks are the polling period
during which Developers may cast their votes. Votes in leadership
elections are kept secret, even after the election is finished. 6.
The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
Above. If None Of The Above wins the election then the election
procedure is repeated, many times if necessary.
7. The decision will be made using the method specified in
section A.6 of the Standard Resolution Procedure. The quorum is the
same as for a General Resolution (4.2) and the default option is
"None Of The Above".
8. The Project Leader serves for one year from their election.
=====

Seconded.

[Raphael Hertzog]

Post by Steve McIntyre
Seconded.

Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)

That said, once we reached the 5 DD who seconded (+2/3 more just to be
sure in case of bad signatures), it doesn't bring much to send further
seconds IMO.

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

[Julien Danjou]

Post by Raphael Hertzog
That said, once we reached the 5 DD who seconded (+2/3 more just to be
sure in case of bad signatures), it doesn't bring much to send further
seconds IMO.

Seconded.

Cheers,

[cobaco (aka Bart Cornelis)]

Post by Raphael Hertzog

Post by Steve McIntyre
Seconded.

Thank you for the 542th "Seconded." on this proposal. We don't even need
to vote any more :-)
That said, once we reached the 5 DD who seconded (+2/3 more just to be
sure in case of bad signatures), it doesn't bring much to send further
seconds IMO.

It's a rare display of unanumous agreement amongst DD's, surely that has
value in end of itself :-O

(though sadly I have to admit that the usual flamewars make for more
interesting reading :)

[Holger Levsen]

Hi,

Post by Raphael Hertzog
Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)

Seriously, could we have this change without voting?


regards,
Holger (to lazy to read up in the constitution...)

[Ana Guerrero]

Post by Holger Levsen
Hi,

Post by Raphael Hertzog
Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)

Seriously, could we have this change without voting?

I was wondering the same...

Ana

[Wouter Verhelst]

Post by Holger Levsen
Hi,

Post by Raphael Hertzog
Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)

Seriously, could we have this change without voting?

No. And that's a good thing.

[Kalle Kivimaa]

Post by Wouter Verhelst
No. And that's a good thing.

Actually, *if* each and every developer formally seconds the
resolution, I think the secretary could forego the actual voting
procedure as blatantly obvious.

[Cyril Brulebois]

Post by Kalle Kivimaa
Actually, *if* each and every developer formally seconds the
resolution, I think the secretary could forego the actual voting
procedure as blatantly obvious.

``Seconding a GR'' = ``Voting in favour of a GR''? I don't think so.

Cheers,

[Bastian Venthur]

Post by Kalle Kivimaa

Post by Wouter Verhelst
No. And that's a good thing.

Actually, *if* each and every developer formally seconds the
resolution, I think the secretary could forego the actual voting
procedure as blatantly obvious.

I think even if only "each and every developer"/2 + 1 would second this,
we could be fine without a vote, couldn't we?

Besides the fact this is never going to happen, I agree with Wouter and
think it's generally a bad idea.


Cheers,

Bastian

[Wouter Verhelst]

Post by Bastian Venthur

Post by Kalle Kivimaa

Post by Wouter Verhelst
No. And that's a good thing.

Actually, *if* each and every developer formally seconds the
resolution, I think the secretary could forego the actual voting
procedure as blatantly obvious.

I think even if only "each and every developer"/2 + 1 would second this,
we could be fine without a vote, couldn't we?

No. "I second this" means "I want to see this come to a vote", not
necessarily "I think this is a good idea".

Consider that Anthony Towns formally seconded
<http://www.debian.org/vote/2006/vote_005>, his own recall vote.

[Manoj Srivastava]

Post by Bastian Venthur

Post by Kalle Kivimaa

Post by Wouter Verhelst
No. And that's a good thing.

Actually, *if* each and every developer formally seconds the
resolution, I think the secretary could forego the actual voting
procedure as blatantly obvious.

I think even if only "each and every developer"/2 + 1 would second
this, we could be fine without a vote, couldn't we?

Well, since this is a constitutional amendment, you need more
than a 50% majority ....

Post by Bastian Venthur
Besides the fact this is never going to happen, I agree with Wouter
and think it's generally a bad idea.

manoj

[Andreas Barth]

Post by Wouter Verhelst

Post by Holger Levsen
Hi,

Post by Raphael Hertzog
Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)

Seriously, could we have this change without voting?

No. And that's a good thing.

Agreed (to the second, the first is just a fact).


Cheers,
Andi

[Holger Levsen]

Hi,

Post by Andreas Barth

Post by Wouter Verhelst

Post by Holger Levsen
Seriously, could we have this change without voting?

No. And that's a good thing.

Agreed (to the second, the first is just a fact).

Agreed.

And I felt a bit silly yesterday, when I re-thought about my question - even
looking at the subject would have been enough to answer my question ;-)


regards,
Holger

[Joerg Jaspert]

Post by Holger Levsen

Post by Raphael Hertzog
Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)

Seriously, could we have this change without voting?

Sure, if everyone with a key in the current keyring, ie. including those
MIA, sends a "seconded" (and annoys buxy with it), then, MAYBE, then, one
could think about such a stunt. Otherwise its changing the constitution,
so nice thought but not possible imo.

[Hamish Moffatt]

Post by Holger Levsen
Hi,

Post by Raphael Hertzog
Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)

Seriously, could we have this change without voting?

Indeed. Reducing our GR rate seems more important than changing the DPL
election process.

Minor GRs cause reduced interest from the electorate, resulting in less
scrutiny. Dare I suggest that the end result is that "editorial changes"
get passed?

Hamish

[Raphael Hertzog]

Post by Hamish Moffatt

Post by Holger Levsen
Seriously, could we have this change without voting?

Indeed. Reducing our GR rate seems more important than changing the DPL
election process.

I don't agree. I think quite the contrary. We often tend to not address
issues and let them consume our energy in endless discussions. I believe
that having GR is useful to re-forge ourselves a clearer identity.

Of course, this administrative GR doesn't count as something that helps us
forge an identity. :)

Post by Hamish Moffatt
Minor GRs cause reduced interest from the electorate, resulting in less
scrutiny. Dare I suggest that the end result is that "editorial changes"
get passed?

I remember. And I think most people remember and will think twice before
voting. :-)

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

[Pierre Habouzit]

Post by Raphael Hertzog

Post by Hamish Moffatt

Post by Holger Levsen
Seriously, could we have this change without voting?

Indeed. Reducing our GR rate seems more important than changing the DPL
election process.

I don't agree. I think quite the contrary. We often tend to not address
issues and let them consume our energy in endless discussions. I believe
that having GR is useful to re-forge ourselves a clearer identity.

A GR is the poorest way to "agree" on anything. I think I'm not so
surprised to see you claim that, even after some not so old history.

GRs do not unite, they divide. They divide the DDs in two: the one
the losers and the winners. And the identity you claim to forge, is just
the identity of the winning camp, not Debian's.

[Andreas Barth]

Post by Pierre Habouzit
GRs do not unite, they divide. They divide the DDs in two: the one
the losers and the winners. And the identity you claim to forge, is just
the identity of the winning camp, not Debian's.

Of course, with exceptions like "formal GRs", e.g. in cases where we
want an GR to make it obvious the project wants something (which is e.g.
required for constitutional changes even if we all seem to agree, for
good reasons IMHO). I think this is the case with "reducing the length
of DPL election process".



Cheers,
Andi

[Raphael Hertzog]

Post by Pierre Habouzit

Post by Raphael Hertzog
I don't agree. I think quite the contrary. We often tend to not address
issues and let them consume our energy in endless discussions. I believe
that having GR is useful to re-forge ourselves a clearer identity.

A GR is the poorest way to "agree" on anything. I think I'm not so
surprised to see you claim that, even after some not so old history.
GRs do not unite, they divide. They divide the DDs in two: the one
the losers and the winners. And the identity you claim to forge, is just
the identity of the winning camp, not Debian's.

That's because you only take into account controversial GR. Not all GR
need to be controversial. Sometimes I'm tempted to use GRs to try have some
official position statements from Debian on some topics.

And at least, they give us some real figures of Debian instead of
unverifiable statements quoting the 'the silent majority' (which probably
exists in most cases, but whose opinion is difficult to know).

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

[Pierre Habouzit]

Post by Raphael Hertzog

Post by Pierre Habouzit

Post by Raphael Hertzog
I don't agree. I think quite the contrary. We often tend to not address
issues and let them consume our energy in endless discussions. I believe
that having GR is useful to re-forge ourselves a clearer identity.

A GR is the poorest way to "agree" on anything. I think I'm not so
surprised to see you claim that, even after some not so old history.
GRs do not unite, they divide. They divide the DDs in two: the one
the losers and the winners. And the identity you claim to forge, is just
the identity of the winning camp, not Debian's.

That's because you only take into account controversial GR. Not all GR
need to be controversial.

Then it's useless administrivia. (And no I'm not talking about
Anthony's proposal, like Andi said, here it's the constitution that
makes it necessary).

Post by Raphael Hertzog
Sometimes I'm tempted to use GRs to try have some official position
statements from Debian on some topics.

And the point would be ? Have you an example in mind ? That sounds
like a way to impose some views to the project to avoid having to
discuss some issues. Damn, it does not sounds like it, you said it was
the goal, I get it !

Post by Raphael Hertzog
And at least, they give us some real figures of Debian instead of
unverifiable statements quoting the 'the silent majority' (which
probably exists in most cases, but whose opinion is difficult to
know).

Handwaving. If the silent majority wants to oppose an apparent
consensus, they should not be silent in the first place. Voting brings
decisions into the hands of people that did not necessarily followed
discussions, or are unaware of some of the issues. If the decision
matters to them, then maybe we should work on a way to be sure that
everyone can participate to every choice....

Wait...

Doh, it's already the case, debian-***@ldo is the place. Sorry, I
disagree completely here, I think we already have what we need. But
maybe we should do a GR about it, just to be sure ?

[Andreas Barth]

Post by Pierre Habouzit
Handwaving. If the silent majority wants to oppose an apparent
consensus, they should not be silent in the first place. Voting brings
decisions into the hands of people that did not necessarily followed
discussions, or are unaware of some of the issues.

Though I agree on most parts, I consider it necessary that all
Developers together can pull any decision into their hands - even if
that might yield suboptimal results in some cases. But as someone else
already said, democracy is the best of all bad governance methods but
unfortunatly there is not a single good governance method. (And I'm
going to fight for that right, btw - in Debian and outside.)

Having said that, I agree that in most cases calling for GR is
contraproductive, and having an overemphasize on GRs is hurting the
project. GRs don't magically fix things, and often leave wounds.

I know there are exceptions, e.g. I consider one of the votes of the
tech ctte on the question whether something is RC or not as helpful, as
all reasonings were said, and Steve and I disagreed, so that was the
"fastest" way out, and we both welcomed that we will have a decision
(and voted "further discussion" lowest).

So, in cases where the project needs to have a common opinion, but we
have a wide range of opinions even though all reasons are said, a vote
might finish the discussion - this of course helps only really good in
case all sides accept that the vote is "the final decision" (and in that
case, we could equally well e.g. use the TC for a decision, or anything
else as long as all involved people are accepting the result in the
end).



Cheers,
Andi

[Josselin Mouette]

Post by Raphael Hertzog
That's because you only take into account controversial GR. Not all GR
need to be controversial. Sometimes I'm tempted to use GRs to try have some
official position statements from Debian on some topics.

And this is what GRs are meant to be. Using a GR as a decision process,
like what happened several times recently, is utterly wrong and each
such vote that is taken weakens the project a little more. Each of them
brings more resentment and disagreement instead of making people work
together like you'd like them so much to do.

[MJ Ray]

Post by Raphael Hertzog
That's because you only take into account controversial GR. Not all GR
need to be controversial. Sometimes I'm tempted to use GRs to try have some
official position statements from Debian on some topics.

Unfortunately, recent GRs seem to have reached a vote as
proposal || alternate || alternate || alternate
with very little overlap between the alternatives. I don't think
that's a good way to find a compromise, but DDs seem reluctant to
second and put more options on the ballot. Condorcet works better
with several overlapping options, IMO.

I think we need to be more liberal at putting options on the ballot.
One way to do that is more practice.

Regards,

[Anthony Towns]

Post by Pierre Habouzit
GRs do not unite, they divide. They divide the DDs in two: the one
the losers and the winners.

Just because your argument doesn't win the day doesn't mean you're a
loser, or divided off from the rest of the project.

Cheers,
aj, who's lost lots of votes

[Lars Wirzenius]

Post by Anthony Towns

Post by Pierre Habouzit
GRs do not unite, they divide. They divide the DDs in two: the one
the losers and the winners.

Just because your argument doesn't win the day doesn't mean you're a
loser, or divided off from the rest of the project.

FULL AGREEMENT STOP GRACEFULLY ACCEPTING LOSS VITAL STOP COME TO
BLANDINGS NEXT WEEKEND STOP ANATOLE IN TOP FORM STOP

[Joerg Jaspert]

Post by Raphael Hertzog

Post by Steve McIntyre
Seconded.

Thank you for the 542th "Seconded." on this proposal. We don't even need to
vote any more :-)
That said, once we reached the 5 DD who seconded (+2/3 more just to be
sure in case of bad signatures), it doesn't bring much to send further
seconds IMO.

But they also don't hurt to have, and its nice to see lots of people
agreeing to something.

Ok, they may hurt the secretary, Manoj will have a fun time listing all
of us seconders. :)

[Adeodato Simó]

Post by Joerg Jaspert
Ok, they may hurt the secretary, Manoj will have a fun time listing all
of us seconders. :)

Nothing prevents him from just choosing the first 5 seconds, or 5 at
random, TTBOMK.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org

Listening to: Amon Tobin - Kitchen Sink

[Milan Zamazal]

AT> Likewise, all our other votes have only needed two weeks (or
AT> less in the case of the recall votes) to resolve, so having an
AT> extra week for DPL elections seems unnecessary.

DPL elections is the most complicated voting with many options
(candidates) and many documents to study (platforms, rebuttals +
discussion). Perhaps I'm not the only one who would prefer to retain
the extra week to get better opportunity to participate in DPL voting?

Regards,

Milan Zamazal