headers
Debian Project Secretary | 1 Oct 2007 03:39
X-Face
Face
Picon
Favicon

Second Call for votes for Constitutional amendment: reduce the length of DPL election process

Hi,

        We are now in the second and final week of this vote. At the
 time of writing, 132 people have voted, out of a potential 1049. This
 is somewhat of an record for low participation.

        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 secretary <at> 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. <URL:http://lists.debian.org/debian-vote/2007/07/msg00178.html>
In wdiff format:
===========================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Duboc | 3 Oct 2007 15:30
Picon
Favicon

Unclear license status for prospective package ht2html

   Hi,

 I'm considering packaging ht2html [1] for Debian, mainly because the
Jython package I'm working on uses it to build its documentation.

 The ht2html tarball doesn't include any license text file and no
copyright notice is found in source files.

 But according to the SourceForge project page [2] the "Python License
(CNRI Python License)" applies. Also the README file of the tarball
references Barry Warsaw as the upstream author.

 I anticipate that it won't be sufficiently clear to allow inclusion of
ht2html in Debian. I'm going to contact Barry Warsow to ask him a
clarification but, as ht2html is rather an old and not really active
project, I fear he won't be inclined to release a new version.

 Is a new tarball with clear copyright notices mandatory for Debian ?

 Would an email stating the copyright and licensing status of ht2html be
sufficient ?

 Is there any other solution ?

 Thanks,

[1] http://ht2html.sourceforge.net
[2] http://sourceforge.net/projects/ht2html

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julien Cristau | 3 Oct 2007 16:42
Picon
Favicon

Re: Unclear license status for prospective package ht2html

On Wed, Oct  3, 2007 at 15:30:34 +0200, Nicolas Duboc wrote:

>    Hi,
> 
>  I'm considering packaging ht2html [1] for Debian, mainly because the
> Jython package I'm working on uses it to build its documentation.
> 
Did you mean to send this to -legal?

Cheers,
Julien
Permalink | Reply | 0 comments |
headers
Nicolas Duboc | 3 Oct 2007 16:43
Picon
Favicon

Re: Unclear license status for prospective package ht2html


  Sorry this mail was of course for debian-legal.

--

-- 
Nicolas Duboc <nduboc <at> debian.org>
Permalink | Reply | 0 comments |
headers
Debian Project Secretary | 7 Oct 2007 05:50
X-Face
Face
Picon
Favicon

Results for Constitutional amendment: reduce the length of DPL election process

Hi,

        The resolution that passed is (in wdiff format)
--8<---------------cut here---------------start------------->8---
  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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Josip Rodin | 8 Oct 2007 17:33

electing multiple people

Hi,

During the discussion on the proposed social committee, I proposed that we
elect (all) the members of that committee. The Debian Constitution currently
doesn't provide for a way to do so - it only describes how a single winner
is decided.

So, I proposed the following addition to the section A.6. Vote Counting
(part of appendix A Standard Resolution Procedure):

+        If the election requires multiple winners, the list of winners is
+        created by sorting the list of options by ascending strength.
+        If there are multiple winners with the same ranking which exceed
+        the desired length of the list, the length of the list is extended
+        to include the entire last set of multiple winners.

Is this technically sound? I don't know voting method syntax.

[I posted this on -project, but nobody really commented on it, that's why
I'm re-posting to -vote.]

By "sorting the list of options by ascending strength" I refer to that list
we get from the beat matrix, such as in:

http://www.debian.org/vote/2007/vote_001#outcome

If for example in that outcome we wanted to pick four candidates, it
seems to me that they would be Hocever, McIntyre, Herzog, Verhelst.
If for example we wanted to pick seven, we couldn't go past the first six.
(Continue reading)

Permalink | Reply | 49 comments |
headers
Lucas Nussbaum | 8 Oct 2007 18:08

Re: electing multiple people

On 08/10/07 at 17:33 +0200, Josip Rodin wrote:
> Hi,
> 
> During the discussion on the proposed social committee, I proposed that we
> elect (all) the members of that committee. The Debian Constitution currently
> doesn't provide for a way to do so - it only describes how a single winner
> is decided.
> 
> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):
> 
> +        If the election requires multiple winners, the list of winners is
> +        created by sorting the list of options by ascending strength.
> +        If there are multiple winners with the same ranking which exceed
> +        the desired length of the list, the length of the list is extended
> +        to include the entire last set of multiple winners.
> 
> Is this technically sound? I don't know voting method syntax.

couldn't we get cycles using that? Alternatively, we could iteratively
elect:
- winner1: the winner with all candidates
- winner2: the winner with all candidates minus winner1
- winner3: the winner with all candidates minus [winner1, winner2]
- etc
using the same tally sheet

Or, we could elect a list directly (ie each option is a list of people
willing to work together as SC), which would allow to elect a SC which
is actually representative for Debian. It's probably better than the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Josip Rodin | 8 Oct 2007 18:24

Re: electing multiple people

On Mon, Oct 08, 2007 at 06:08:41PM +0200, Lucas Nussbaum wrote:
> couldn't we get cycles using that? Alternatively, we could iteratively
> elect:
> - winner1: the winner with all candidates
> - winner2: the winner with all candidates minus winner1
> - winner3: the winner with all candidates minus [winner1, winner2]
> - etc
> using the same tally sheet

You can't do that and keep all the 'goodness' of our voting system, because
doing that loses the interdependencies of votes. I don't know how to explain
it properly :), please see:
http://lists.debian.org/debian-project/2007/06/msg00318.html

> Or, we could elect a list directly (ie each option is a list of people
> willing to work together as SC), which would allow to elect a SC which
> is actually representative for Debian.

This means parties, and I don't see any proof that this would help with
being representative?

> It's probably better than the first solution, as the first solution isn't
> clone-proof: we could have elected n Sams!! ;)

There should be some sentence in the constitution that can be interpreted as
a rule against cloning... :)

--

-- 
     2. That which causes joy or happiness.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Antti-Juhani Kaijanaho | 8 Oct 2007 18:26
Picon

Re: electing multiple people

On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote:
> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):

The method you suggest suffers from not delivering proportional results.
See discussion in
  http://lists.debian.org/debian-project/2007/06/msg00318.html
and
  http://lists.debian.org/debian-project/2007/06/msg00261.html

Let's not invent our own bad voting systems.

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/
Permalink | Reply | 7 comments |
headers
Anthony Towns | 8 Oct 2007 18:29
Picon

Re: electing multiple people

On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote:
> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):
> +        If the election requires multiple winners, the list of winners is
> +        created by sorting the list of options by ascending strength. ...
> Is this technically sound? I don't know voting method syntax.

Even if you get the wording right for that, it might not be a *sound*
method if you're trying to get a representative selection of winners,
rather than the 1st best, 2nd best, 3rd best, etc, for whatever people
happen to think "best" means.

To select "events coordinators", for example, we might want to have
five people each on a different continent, even though three of the
best events coordinators happen to be in Europe, on the basis that one
European, one North American and one South/Latin American would be more
useful than three Europeans.

Basically, the question is: if you've got, say, five positions, then do
you want 20% of people to be able to get together and guarantee one of
the positions goes to someone they like, or do you want 51% of people
to be able to get together and guarantee that none of the positions go
to someone they don't like? 

The latter's probably more likely to result in a good functioning
consensus amongst the elected members, the former's probably more likely
to result in (significant) minority views getting representation. It
really depends on what you're trying to achieve as to which is better,
afaics.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane