On 12/20/06, David Fisher <[EMAIL PROTECTED]> wrote:
Hi Jakarta Board-
A suggestion after reading with interest the recent POI vs. Jakarta
smoke and flames threads.
I think that Jakarta needs a voting application that can include PMC
quorum requirements, direct email vote requests, committer approval,
etc.
Maybe it already exists?
Anyone want to +1 this ;-)
Was pondering on this a little while ago.
Problems it solves (and they're not very big, so I was mostly thinking
about it because I felt like writing something new rather than
maintaining code):
* Simplifies calling a vote.
* Adds a better audit trail.
* Can know about the binding votes and it can decide whether a vote is
successful or not.
* Enforces things - so having an end date to a vote for example.
Problems it causes:
* Might make us vote more often rather than just agree consensus has
been reached.
Problems it shouldn't solve:
* Security. We're not currently secure - I could send an email as
someone else's name to the list and vote for them. It's hard to get
secure and yet still encourage contributors to throw in their +1s or
-1s.
------
Thoughts on implementation.
It needs to use some svn files behind the scenes to know that someone
is in a PMC (and thus binding). That's easy enough - there's a file
that contains that, though the formatting sucks.
It needs to be listening to emails, and communicate with a mailing
list. It needs to offer archival view via a webapp, and a current
state view through a webapp. Calling a vote is interesting - ideally
we'd limit that to committers simply to stop from getting spammed,
however that means the webapp (presuming the webapp would be the one
that held the admin system) would need to know about auth.
As we get more and more into auth, it becomes tempting to auth the
whole thing. Vote through the webapp and not an email, put it behind
SSL and the svnpasswd file (which is just htaccess from memory -
though getting access to that file might be tricky). Still allow a
guest vote.
Allowing a guest vote still raises spam as a possibility if we have
each vote be sent to the list. Possibly the solution is for the voting
tool to send voting summaries rather than votes themselves. Daily it
could send out the current state. People often comment with a vote
though - so that would be weak to not send it to the list.
Another option is to tie into the list management - let emails who are
subscribed vote. Painful dealing with ezmlm I suspect.
Another would be to just monitor the mailing list. Create a bot that
listens to emails and a script that sends out emails in a particular
format. Might work, but parsing replies would probably suck. That
could be completely webapp-less; more like an IRC bot for an email
list.
The only existing vote stuff at the ASF is for member/board voting
each year, but that's ssh/email and defined to be secure and private.
Not much use for us.
Think that's about where my thinking got...
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
