Re: proposed constitution and NEW: proposed voting procedure
> > As for "validating" the voting results, and keeping the interrumn count
> > secret, we should be able to deal with this in software. We would need a
> > proceedure that would collect the votes in an area we all agree is "safe"
> > and let the software "secure" the votes until the voting period ends; at
> How's about a developer-vote@lists.debian.org ... require each
> maintainer to mail a pgp-encrypted voting ballot (ballot rather like the
> Usenet voting ballot). Whatever script is the recipient of the
> mailinglist can (once a day or whatever) compare incoming mails to the
> developer keyring, put all the acceptable ballots (those matching an
> entry in the Debian keyring) in an "accepted ballots" bin (discarding or
> bouncing those that don't match any developer's keys), and at the end
> of the voting period it simply counts the ballots. This way:
> 1) Developers could change their votes, assuming the voting period has not
> ended, by simply sending a new ballot, and the script could discard
> any previous ballots from that pgpkey.
> 2) There's no tallying done until the voting period ends, and hence no
> intermediate results to worry about posting.
> 3) No person has to ever "touch" the ballots ... the Project Secretary
> could simply run a "close-voting-period" script and have the relevant
> information output to text/html/sgml/whatever.
>
How the voting is actually done is secondary to what is in the constitution
as long as the voting complies with it.
That said, I have been working on a system to automate most of the
procedure from proposing motions all the way through voting. All
interaction with the system is done through PGP signed mail (PGP keys must
be on the Debian keyring). This allows proposers of motions or amendments
to even do updates without the interaction of the secretary. Of course,
the secretary will be in charge of the system and be able to make changes
(by hand if needs be. Not every situation will be covered by scripts).
What you have proposed above is very close to what I have already worked
out for the voting except that the vote will be called by the proposer as
discussed in A.2 .
By automating most of the day to day workings of the entire procedure,
the job of secretary will become humanly feasible. They will only
have to intervene in disputes (as per the constitution) and take care
of a few odds and ends that may not be worth coding. For example,
dealing with A.3 . Handling withdrawals is easy, but the secretary will
need to work with the seconders to decide who, if any of them, will
take over as proposer. Yes, I could implement a system to automate even
this, but let's not go overboard. Besides, communication is especially
important when things get tense (which will often be the case when a proposer
steps down). If it turns out to be a good thing, it can be easily added later.
As I am going away for 3 days, I will post how I propose to implement this
next week. There are still a few issues that need to be worked out.
- Jay
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: