Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Ben Finney]

Charles Plessy  writes:

> in light of the painful firmware GR this year, I think that the
> following ideas can help to avoid such a situation to happen again.
> 
> - Restrict the use of 3:1 supermajority to GRs proposing changes of
> our fundation documents.

This restriction would not address the perceived problems with the
gr_lenny_firmware ballot. Recall that “changes to the foundation
documents” was the very justification for why the 3:1 supermajority
requirements were applied as they were.

What it seems is that some people (including you?) disagree with some
others on *what* constitutes a change to foundation documents. That
seems to be the point that needs better clarification.

> - Ask the GR proposer to take part of the work load, for instance by
> gathering and counting the PGP-signed secondings and writing the
> vote.debian.org page.

I like this idea for its “share the load” effect, but I can see a
change in conflict of interest if the person who proposes the GR also
gets to write up the formal vote document.

-- 
 \“I installed a skylight in my apartment. The people who live |
  `\ above me are furious!” —Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Charles Plessy]

Dear all,

since it is rare that a GR is rejected by a majority of persons ranking
"Further discussion" above all, I do not think that there is a need to make it
more difficult to propose a GR. Nevertheless, in light of the painful firmware
GR this year, I think that the following ideas can help to avoid such a
situation to happen again.

- Restrict the use of 3:1 supermajority to GRs proposing changes of our 
fundation
  documents.

- Authorise the proposer of a GR to call for a vote on a subset of the 
amendments. 

- Authorise the Secretary to use non-email methods, as email voting seems to be
  is a repeated source of problems. Programs like Selectricity look like
  interesting alternative (http://selectricity.org/).

- Ask the GR proposer to take part of the work load, for instance by gathering
  and counting the PGP-signed secondings and writing the vote.debian.org page.


If despite this the Project would require ~15 seconders per GR and amendments,
I suggest to think about a new place and/or method to handle the formal
PGP-signed emails of the GR preparation procedure, otherwise debian-vote can
really become unreadable.


Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[MJ Ray]

Frans Pop  wrote:
> On Tuesday 30 December 2008, MJ Ray wrote:
> > I add the outcomes to the start of the line:-
> > Proposal F chosen > - Proposal F on the last vote; 17 seconds
>
> Eh, that's incorrect.

Eh, that's unhelpful.  I found both the email's terms and some of
the more recent vote pages a bit confusing.  I'm pretty sure I've
suggested an improved layout to the secretary in the past, but it
was ignored.

Please correct any goofs if you've spotted them.  Anyway, that's
two out of seven, which makes the point I took stronger, not weaker.

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


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Matthew Johnson]

On Tue Dec 30 09:31, Russ Allbery wrote:
> Ben Finney  writes:
> 
> > I think it can be a good idea to propose an option that one wants to
> > see voted on, especially if one honestly thinks that option could
> > represent the opinion of other people in the vote.
> 
> This is what I disagree with for all the reasons that I already stated
> (and which I won't reiterate again).  The formal proposal is essentially
> the first second towards putting it on the ballot.  If you don't actually
> agree with the proposal, I don't think you should be doing either.

I'd also add that sometimes it seems like a good idea to make sure that
an opinion which has been voiced but not yet proposed is there so you
can demonstrate that the project really doesn't want it and you can cite
this next time it's raised rather than have the possible ambiguity. Note
that I don't think that's a good reason to call a vote, but to propose
an amendment... maybe.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Adeodato Simó]

* Wouter Verhelst [Tue, 30 Dec 2008 18:21:58 +0100]:

I'm still undecided whether I'm for Q, 2Q, or what. But:

> Well, I disagree on that point. I just had a look at the vote.debian.org
> pages, checking those votes where the number of seconds exceeded 10, and
> found only the following ones:

I don't think that's a fair consideration. We all know a proposal needs
5 seconds, so if we see one we'd second has the 5 already, I think it's
natural to pass. The popular proposal notwithstanding.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A hacker does for love what other would not do for money.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Peter Samuelson]

[Stephen Gran]
> That just means that the number of people who think the vote is even
> worth having is not that different to the number of votes required to
> make it valid.  That's probably not all that bad a thing, IMHO.

If that is sound reasoning, then it is also a reason to have a higher
number of required sponsors for amendments to foundation documents.
That said, I think I agree that 2Q is too high but current K is too
low.  (Split the difference?  Q + K/2)

Another issue with raising the bar is that if you formally propose
something before it is fully ready, such that it will need two or three
small modifications, it would get very confusing who has seconded what
versions of the text - guaranteed great fun for the Secretary role.
Not a new issue, but it would get worse.  I suppose this would serve as
social engineering to encourage people to circulate drafts for awhile
before proposing them.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: PATCH for spamass-milter to solve Debian list spam->bounce issue (Was:- Spamming the World through Open Debian Mailinglists....)

[Michelle Konzack]

Guten Abend Cord,

Am 2008-12-30 19:00:41, schrieb Cord Beermann:
> svn://svn.alioth.debian.org/svn/pkg-listmaster

Hmmm, I can not connect...
It seems, Telefonica/O2 and Bougues Telecom are blocking something

> >(Wo bekommet man das Script oben rechts für die VORRATSDATENSPEICHERUNG?)
> 
> http://wiki.vorratsdatenspeicherung.de/Online-Demo

Danke... installiert.  

> >> I also understood that people want to have information about how many
> >> bounces we counted for them. I'm just thinking about how to implement
> >> that and will include that in the bounce-warning-message.
> 
> this is now implemented. I hope this helps.

WOW!!!  You are realy fast...

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
   
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Frans Pop]

On Tuesday 30 December 2008, MJ Ray wrote:
> I add the outcomes to the start of the line:-
> Proposal F chosen > - Proposal F on the last vote; 17 seconds

Eh, that's incorrect.


signature.asc
Description: This is a digitally signed message part.

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[MJ Ray]

Wouter Verhelst  wrote: [...]
> Well, I disagree on that point. I just had a look at the vote.debian.org
> pages, checking those votes where the number of seconds exceeded 10, and
> found only the following ones:

I add the outcomes to the start of the line:-

Proposal F chosen > - Proposal F on the last vote; 17 seconds
Proposal A chosen > - Proposal A on 2008_002 (membership); 21 seconds
Proposal A chosen > - Proposal A on 2007_004 (length DPL election); 20 seconds
Amendment A chosen > - Amendment A on 2006_001 (GFDL); 15 seconds
Proposal B chosen > - Proposal E on 2004_004 (sarge release after 2004_003): 16 
seconds
Amendment chosen > - Amendment on 2004_002 (status of non-free): 12 seconds

So, in one case, the outcome was different to the most-seconded option.

[...]
> Now I do realize and agree that many people will probably not second
> something anymore once a sufficient number of seconds has been issued;
> but I think that, all things considered, 30 may be too much.

Yes and more generally: I think there are obviously some interactions
between being the first proposal, the number of seconds gathered, the
voting preferences (and so the outcome) and the current required
number of seconds.  It's this last element which makes this analysis
so unreliable, but the others play a part.

> [...] However, raising the bar sixfold in one go is pushing it, IMO.

I agree.  There seems little rationale to support it.  The more I've
looked, the more places I've not found evidence for such a large
seconding requirement and I know a few anecdotes about raising numbers
too high and accidentally killing an organisation...  Was 30 proposed
as a "let's propose something extreme and see if we can get something
less-but-sufficient-to-kill-nearly-all-GRs through" vanguard?

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


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 30, 2008 at 11:21:34AM +0100, Joerg Jaspert wrote:
>
>>> this will mean that future GRs would need 30 other people to support 
>>> your idea. While that does seem a lot (6times more than now),
>> Actually, 31 (depending on where you do the rounding/truncation which 
>> would have to be specified or there will be arguments).
>
>floor() in this case. Well, my idea was just to "drop everything behind 
>the .". So floor(), int(), whatever it is in your favorite language. :)

I believe you wrote that Q is approx 15.9765453086705, so...

floor(2Q) = 31

2(floor(Q)) = 30

:-)


   - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

   [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklaYJ4ACgkQn7DbMsAkQLgWVgCgppAnjR3lNkz4iA0sLzMb9j6X
BggAoJmJYHiqW/aYAtTG5jGHSda+WheF
=orLI
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: PATCH for spamass-milter to solve Debian list spam->bounce issue (Was:- Spamming the World through Open Debian Mailinglists....)

[Cord Beermann]

Hallo! Du (Michelle Konzack) hast geschrieben:

>> yes. we do that already. see
>> http://alioth.debian.org/projects/pkg-listmaster/ which represents our
>> running Amavis/SA-setup.
>
>For three seconds I was on the link above, but there is nothing visibel.
>I was looking in the CVS...  Checked the Mailinglists...  :-/

svn://svn.alioth.debian.org/svn/pkg-listmaster

>(Wo bekommet man das Script oben rechts für die VORRATSDATENSPEICHERUNG?)

http://wiki.vorratsdatenspeicherung.de/Online-Demo

>> I also understood that people want to have information about how many
>> bounces we counted for them. I'm just thinking about how to implement
>> that and will include that in the bounce-warning-message.

this is now implemented. I hope this helps.

Cord


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Russ Allbery]

Joerg Jaspert  writes:

>>> this will mean that future GRs would need 30 other people to support
>>> your idea. While that does seem a lot (6times more than now),
>> Actually, 31 (depending on where you do the rounding/truncation which would
>> have to be specified or there will be arguments).
>
> floor() in this case. Well, my idea was just to "drop everything behind
> the .". So floor(), int(), whatever it is in your favorite language. :)

It's not so much the function as it is the order of operations.  It sounds
like you meant 2 * floor(Q) instead of floor(2Q).  :)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Russ Allbery]

Ben Finney  writes:

> I think it can be a good idea to propose an option that one wants to
> see voted on, especially if one honestly thinks that option could
> represent the opinion of other people in the vote.

This is what I disagree with for all the reasons that I already stated
(and which I won't reiterate again).  The formal proposal is essentially
the first second towards putting it on the ballot.  If you don't actually
agree with the proposal, I don't think you should be doing either.

I suspect we'll have to agree to disagree on this.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Wouter Verhelst]

On Tue, Dec 30, 2008 at 12:54:41AM +0100, Joerg Jaspert wrote:
> Practical changes: Taking the definitions of the latest GR we had,
> 
>  Current Developer Count = 1021
>  Q ( sqrt(#devel) / 2 ) = 15.9765453086705
>  Quorum  (3 x Q )   = 47.9296359260114
> 
> this will mean that future GRs would need 30 other people to support
> your idea. While that does seem a lot (6times more than now),
> considering that a GR affects more than 1000 official Developers and
> uncounted amounts of other people doing work for Debian, I think its not
> too much.

Well, I disagree on that point. I just had a look at the vote.debian.org
pages, checking those votes where the number of seconds exceeded 10, and
found only the following ones:
- Proposal F on the last vote; 17 seconds
- Proposal A on 2008_002 (membership); 21 seconds
- Proposal A on 2007_004 (length DPL election); 20 seconds
- Amendment A on 2006_001 (GFDL); 15 seconds
- Proposal E on 2004_004 (sarge release after 2004_003): 16 seconds
- Amendment on 2004_002 (status of non-free): 12 seconds

That's 6 out of 16 votes where _one_ amendment or proposal had more
than 10 seconds; many of them had more than one amendment or proposal,
but none of them had two amendments or proposals with more than 10
seconds.

Now I do realize and agree that many people will probably not second
something anymore once a sufficient number of seconds has been issued;
but I think that, all things considered, 30 may be too much.

I'm not saying that raising the bar a bit isn't a good idea; and I also
fully agree that having this number depend on the number of developers
is a good idea. However, raising the bar sixfold in one go is pushing
it, IMO.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: PATCH for spamass-milter to solve Debian list spam->bounce issue (Was:- Spamming the World through Open Debian Mailinglists....)

[Michelle Konzack]

Good evening Cord,
Guten Abend Cord,

Am 2008-12-29 14:20:10, schrieb Cord Beermann:
> Hallo! Du (Michelle Konzack) hast geschrieben:
> >Tried to educate "spamassassin" for this kind of languages?
> 
> yes. we do that already. see
> http://alioth.debian.org/projects/pkg-listmaster/ which represents our
> running Amavis/SA-setup.

For three seconds I was on the link above, but there is nothing visibel.
I was looking in the CVS...  Checked the Mailinglists...  :-/

However, I had to disabel the language checks in spamassassin  since  it
gaved me to many false-positive.

> I tried to describe the kick-policy at
> http://cord.de/blog/index.php?entry=entry080126-001137

OK...

(Wo bekommet man das Script oben rechts für die VORRATSDATENSPEICHERUNG?)

> I also understood that people want to have information about how many
> bounces we counted for them. I'm just thinking about how to implement
> that and will include that in the bounce-warning-message.

Thanks for your efforts
Michelle

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
   
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Henrique de Moraes Holschuh]

On Tue, 30 Dec 2008, MJ Ray wrote:
> What are the consequences of setting the bar too high?  Well, I
> think it would favour organised campaign groups, it encourages
> clustering around flags too early rather than seeking compromises

This is a very compelling argument, and it convinced me that I shouldn't
vote even for 1.5Q.  I'd go for floor(Q) or less, but not more.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Henrique de Moraes Holschuh]

On Tue, 30 Dec 2008, Joerg Jaspert wrote:
> >> Therefore the Debian project resolves that
> >>  a) The constitution gets changed to not require K developers to sponsor
> >> a resolution, but floor(2Q). [see §4.2(1)]
> > not sure if we need floor(2Q) here, but at least floor(Q).
> 
> It is 2Q as I do want a seperation to the one in b) (to stop a
> delegate/DPL/the TC). And I dislike going below Q for any option, so b)
> has the lower, Q, and a is 2Q.
> Besides, its only 30 people with floor(2Q)...

I'd find 1.5Q more palatable.

30 people is not much when you compare it with 1000.  But the ammount of
people that are interested enough in Debian processes to actually notice
there is something they would like to "second" is a lot less...

In fact, while I find floor(1.5Q) acceptable, I'd rather have it at
floor(Q).

> > d) If a resolution will affect an upcoming release which is already frozen,
> > the resolution needs twice the number of sponsors as defined in a).
> 
> While I dislike the GR we just had so short before release I don't think
> making a special case for a release is good. If it is I want a special

Agreed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Guido Trotter]

On Mon, Dec 29, 2008 at 04:18:02PM -0800, Don Armstrong wrote:

Hi,

> 1: I'd be happier, though, if those proposing and seconding options
> would be more careful about the effects that their options may have,
> and be more vigilant about withdrawing options when more palletable
> options exist. You should not be proposing or seconding an option that
> you don't plan on ranking first.

Well, let's say you should not propose or second an option you don't plan to
rank above "further discussion"... Maybe you'll rank it lower than another
option, but that's what the condorcet voting system allows us to (provide order
of preference among acceptable options). An option that is not "your favorite"
might still be "very good" for you as an outcome... :)

Thanks,

Guido


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 30, 2008 at 09:52:37AM +0100, Bernd Zeimetz wrote:
>Jonas Smedegaard wrote:
>> On Tue, Dec 30, 2008 at 01:50:37AM +0100, Bernd Zeimetz wrote:
  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
 as well as resolutions against a shortening of discussion/voting
 period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
 developers to sponsor the resolution.
  c) the definition of K gets erased from the constitution. [§4.2(7)]
>>> what I'd like to add here is something in the lines of
>> 
>>> d) If a resolution will affect an upcoming release which is already 
>>>   frozen, the resolution needs twice the number of sponsors as defined 
>>>   in a).
>> 
>>> This should help to avoid that some random people try to stop a release 
>>> in the latest moment if there's not a really good reason to do so. If 
>>> we want Debian to be used in business ("enterprise" *gasp*) 
>>> installations, we should at least be able to tell people when we're 
>>> about to release, without having them to fear a delay for months or 
>>> years due to a GR.
>> 
>> I disagree: Debian release when ready, not in time. Which is good!
>> 
>> If anyone creates a vote close to (expected) release, then they have a 
>> good reason to do that. Which we should not suppress by designing our 
>> rules to favor releasing "in time".
>
>If there's a good reason to create the GR I'm sure they'd find enough
>sponsors. Realeasing in time becomes more and more important these days - so I
>can't see anything wrong here.

What I find wrong is to design the fundamental rules so that release 
schedule is implicitly favored.

Why require the double amount of sponsors for GRs close to release, if 
not because the release itself is considered valuable in itself?


  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklaJ+IACgkQn7DbMsAkQLiv9ACbBXLpWBEHxs9vGCppCbtwK9zF
h8sAmgLhHcFg4sHAcAt9pEPU1+4aiXVH
=GK8O
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[MJ Ray]

Joerg Jaspert  wrote:
>
> this will mean that future GRs would need 30 other people to support
> your idea. While that does seem a lot (6times more than now),
> considering that a GR affects more than 1000 official Developers and
> uncounted amounts of other people doing work for Debian, I think its not
> too much. Especially as point b only requires 15 people, 3 times the
> amount than now, in case there is a disagreement with the DPL, TC or
> a Delegate.

I think that's too much.  A quick count of discussions around the
recent GR suggests that only 79 people participated and I'm sure
that included many non-DDs.  Given that a reasonable ballot would
have 4 alternatives (one-off exception, permanent exception, no
exceptions ever and release team discretion) as well as
compromise options (which rarely appear at the minute), I think
finding 4 groups of 30 DDs from 79 posters is unlikely.  If the
recent criticism of DDs who second worthy-but-not-preferred
options succeeds in discouraging them, it would be impossible.

What are the consequences of setting the bar too high?  Well, I
think it would favour organised campaign groups, it encourages
clustering around flags too early rather than seeking compromises
and the first hint of voter fatigue will probably result in no
further options being added to the ballot.  That would be fine if
people sought compromise *before* calling for seconds (as is
happening now) but there is no requirement for that and it
doesn't seem to have happened often in the archives.

What number of seconds do other systems require for a proposal?

If I remember rightly, my local council (3200 inhabitants - maybe
2400 eligible voters?) requires no seconds to put a question to a
council meeting (which must be addressed), one elected second to
propose a solution, something like 9 seconds to call an election
and one second to stand for election.  It seems a remarkably
stable council.

My largest company (3 million voters) requires one elected second
to put a question to some meetings and I think five seconds for
others and two seconds to stand for election to the first
level (I don't know about higher levels).

I'd welcome other examples - or especially expert analysis.

In the absence of that, my current view is that floor(Q) for a GR
and floor(Q/2) for disagreements would be reasonable as the next
step.  Why should it be more?


Note: I counted number of participants with the rc shell command:
; curl -s http://lists.debian.org/debian-vote/2008/^(10 11 12)^/ \
| sed -n -e '/DFSG/{;s/^.*//;s/<.*$//;p;}' | sort | uniq -c | wc -l
79

Hope that helps,
-- 
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Kalle Kivimaa]

Joerg Jaspert  writes:
> Or we have 2 vote options, one for 2Q, one for Q. What makes more sense?
> Guess changing mine, to avoid confusion/too many options?! (All just
> dreaming ahead to a possible vote :) )

I don't think having options for 2Q and Q for resolution sponsoring
makes the ballot too confusing, provided we don't end up with dozens
of options.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Joerg Jaspert]

>> Therefore the Debian project resolves that
>>  a) The constitution gets changed to not require K developers to sponsor
>> a resolution, but floor(2Q). [see §4.2(1)]
>>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
>> as well as resolutions against a shortening of discussion/voting
>> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
>> developers to sponsor the resolution.
>>  c) the definition of K gets erased from the constitution. [§4.2(7)]
> Thanks for bringing this up. I feel that 2Q is possibly too large
> however. I'd suggest:

> Therefore the Debian project resolves that:
>   a) Section 4.2 of the Debian Constitution is amended, replacing all
>   references to K with Q.
>   b) 4.2.7 is reworded to state:
>  Q is half of the square root of the number of current Developers.
>Q need not be an integer and is not rounded.

Interesting, that makes it harder to stop a delegate as compared to my
proposal. Not that thats bad. :)

> Reasoning:
> a) Q people should be enough to start a GR. The use of the "override a
>delegate's decision immediately" is something that should not be
>taken lightly. This should still require 2Q.

Ok. Fine.

> b) No more reference to K, tidy up. Keep the non-rounded float nature
> of Q.

Hm. Fine.


So, those that spoke up yet mostly think Q instead of 2Q for normal GRs.
Could change my text, its at least 3 times the size as of now, yes.
Or we have 2 vote options, one for 2Q, one for Q. What makes more sense?
Guess changing mine, to avoid confusion/too many options?! (All just
dreaming ahead to a possible vote :) )

-- 
bye, Joerg
* libpng2 no libpng3 no why ? because no yes no yes no yes bullshit no yes
  no yes no yes stop ? no when someday beep beep beep beep (Closes: #157011)
 -- Christian Marillat   Thu, 29 Aug 2002 16:41:58 +0200


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Neil McGovern]

On Tue, Dec 30, 2008 at 12:54:41AM +0100, Joerg Jaspert wrote:
> General Resolutions are an important framework within the Debian
> Project. Yet, in a project the size of Debian, the current requirements
> to initiate one are too small.
> 
> Therefore the Debian project resolves that
>  a) The constitution gets changed to not require K developers to sponsor
> a resolution, but floor(2Q). [see §4.2(1)]
>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
> as well as resolutions against a shortening of discussion/voting
> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
> developers to sponsor the resolution.
>  c) the definition of K gets erased from the constitution. [§4.2(7)]
> 

Hi Joerg,

Thanks for bringing this up. I feel that 2Q is possibly too large
however. I'd suggest:

Therefore the Debian project resolves that:
  a) Section 4.2 of the Debian Constitution is amended, replacing all
  references to K with Q.
  b) 4.2.7 is reworded to state:
 Q is half of the square root of the number of current Developers.
 Q need not be an integer and is not rounded.

Reasoning:
a) Q people should be enough to start a GR. The use of the "override a
   delegate's decision immediately" is something that should not be
   taken lightly. This should still require 2Q.
b) No more reference to K, tidy up. Keep the non-rounded float nature of
   Q.

Cheers,
Neil
-- 
i get an error... i forget what it is ... but definitely an error, well, maybe
a warning... or an informational message... but definitely an output
   Verbatim quote from #debian, irc.freenode.net, Sat Jan 12 00:31:16 GMT 2008


signature.asc
Description: Digital signature

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Joerg Jaspert]

>> this will mean that future GRs would need 30 other people to support
>> your idea. While that does seem a lot (6times more than now),
> Actually, 31 (depending on where you do the rounding/truncation which would
> have to be specified or there will be arguments).

floor() in this case. Well, my idea was just to "drop everything behind
the .". So floor(), int(), whatever it is in your favorite language. :)

-- 
bye, Joerg
Oh mann, beim Backlog-Lesen sollte man weder essen noch trinken. Ihr schweine.
-- Jörg Jaspert


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Joerg Jaspert]

>> I have felt for some time that the low requirement for seconds on General
>> Resolutions is something that should be fixed. We are over 1000
>> Developers, if you can't find more than 5 people supporting your idea,
>> its most probably not worth it taking time of everyone. Various IRC
> Why are you saying 5 ? Your proposal requires 30.

Oh well. Imagine I wrote 30 there. :)

> Recent votes have shown that some options tended to have more
> seconds than the others but we never reached 30. We had 17 for
> "Exclude source requirements for firmware" and 21 for 
> "Invite the DAM to further discuss until vote or consensus, leading to a
> new proposal.".

We never reached 30 as it wasn't neccessary, so people did not second an
option after it got lots of seconders already.

> Note that with those new requirements some interesting
> amendments/alternate choices would not have made it in several of the votes
> (although different rules would have probably lead more people to second).

If they had been so interesting they sure would have reached 30
seconders, no?

> Anyway 2Q is too much in my opinion. Q would be much more reasonable.

See my reply to Bernd why I think its not.

> It would be also be good to add a sentence inviting the seconders to
> explain why they second the proposal. At least it would make the many
> formal mails to second proposals somewhat interesting to read
> (they could even be linked from the vote web page so that voters who have
> not taken part in the discussion can refer to the reasoning of those who
> have brought the option to the vote).

As a must or as a should? A should would probably work.

-- 
bye, Joerg
 meebey: Ich kanns Dir remote machen;)
 oh mann... erst denken dann schreiben


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Joerg Jaspert]

>> Therefore the Debian project resolves that
>>  a) The constitution gets changed to not require K developers to sponsor
>> a resolution, but floor(2Q). [see §4.2(1)]
> not sure if we need floor(2Q) here, but at least floor(Q).

It is 2Q as I do want a seperation to the one in b) (to stop a
delegate/DPL/the TC). And I dislike going below Q for any option, so b)
has the lower, Q, and a is 2Q.
Besides, its only 30 people with floor(2Q)...

> d) If a resolution will affect an upcoming release which is already frozen,
> the resolution needs twice the number of sponsors as defined in a).

While I dislike the GR we just had so short before release I don't think
making a special case for a release is good. If it is I want a special
case for DAM too, every override of a DAM decision takes 6Q at least!
Well, joking, the point is just that its an exception for one special
case which I dislike.

> This should help to avoid that some random people try to stop a release in the
> latest moment if there's not a really good reason to do so. If we want Debian
> to be used in business ("enterprise" *gasp*) installations, we should at least
> be able to tell people when we're about to release, without having them to
> fear a delay for months or years due to a GR.

Now, this proposal changes it from "some random people" counting to 5 up
to 30. I think thats enough, if you find so many supporters for your GR,
then yes, even a release might have to wait.

-- 
bye, Joerg
 And mind you, I have always been respectful to every debian
  developer EXCEPT Branden.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Colin Tuckley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joerg Jaspert wrote:

> I have felt for some time that the low requirement for seconds on General
> Resolutions is something that should be fixed. We are over 1000
> Developers, if you can't find more than 5 people supporting your idea,
> its most probably not worth it taking time of everyone.

Agreed, as you mentioned it's been talked about on IRC a few times recently.

>  a) The constitution gets changed to not require K developers to sponsor
> a resolution, but floor(2Q). [see §4.2(1)]

In my opinion that's too high. I'd be more comfortable with K = Q.

> this will mean that future GRs would need 30 other people to support
> your idea. While that does seem a lot (6times more than now),

Actually, 31 (depending on where you do the rounding/truncation which would
have to be specified or there will be arguments).

regards,

Colin

- --
Colin Tuckley  |  +44(0)1903 236872  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x1B3045CE

Error 1232: Windows has run out of errors.  Run Windows Update to download more.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklZ8GwACgkQj2OPlhswRc5VDACeIOiS1PqtAV2UHnbL6PBvY5Zx
H+YAoOu3jVtcVDhN/LnaKzUL59KoDB/i
=h6uM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Bernd Zeimetz]

Jonas Smedegaard wrote:
> On Tue, Dec 30, 2008 at 01:50:37AM +0100, Bernd Zeimetz wrote:
>>>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
>>> as well as resolutions against a shortening of discussion/voting
>>> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
>>> developers to sponsor the resolution.
>>>  c) the definition of K gets erased from the constitution. [§4.2(7)]
>> what I'd like to add here is something in the lines of
> 
>> d) If a resolution will affect an upcoming release which is already 
>>   frozen, the resolution needs twice the number of sponsors as defined 
>>   in a).
> 
>> This should help to avoid that some random people try to stop a release 
>> in the latest moment if there's not a really good reason to do so. If 
>> we want Debian to be used in business ("enterprise" *gasp*) 
>> installations, we should at least be able to tell people when we're 
>> about to release, without having them to fear a delay for months or 
>> years due to a GR.
> 
> I disagree: Debian release when ready, not in time. Which is good!
> 
> If anyone creates a vote close to (expected) release, then they have a 
> good reason to do that. Which we should not suppress by designing our 
> rules to favor releasing "in time".

If there's a good reason to create the GR I'm sure they'd find enough
sponsors. Realeasing in time becomes more and more important these days - so I
can't see anything wrong here.

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Discussion: Possible GR: Enhance requirements for General Resolutions

[Frans Pop]

On Tuesday 30 December 2008, Joerg Jaspert wrote:
> this will mean that future GRs would need 30 other people to support
> your idea. While that does seem a lot (6times more than now),

The main reason I'm somewhat uncomfortable with this is that in practice 
not all 1000 developers participate in a vote, but only about 300 (367 in 
last vote) or so. The number of developers following d-vote is also a lot 
lower than the total number of DDs.

So effectively requiring 30 supporters means that you'll need support from 
a substantial portion of DDs following d-vote. I personally feel it is 
important that minority opinions do have a chance to be reflected on a 
ballot: there has to be something to choose.

Could/should we distinguish between the number of supporters needed to 
propose a GR (i.e. for the initial proposal) and the number of supporters 
needed for amendments? Problem there is of course the fact that proposals 
may end up as amendments and vice versa.


The last vote has also shown one other issue. In some cases it turns out 
that proposed amendments should really e voted on separately. In that 
case it would be good if the secretary could propose a "voting order" 
when splitting a ballot, but currently there is no mechanism by which a 
vote can be delayed.

Example: first vote on whether or not to release Lenny and then hold a 
separate vote on "Exclude source requirements for firmware" and "Empower 
release team" proposals (probably with a new discussion period to allow 
proposal of suitable amendments).

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.