I don't know... a secure webapp for votes seems overkill for most situations.
I like the informal nature of the voting on the lists. It encourages participation. People can vote with non-binding votes, which is a good thing, I think -- they get to express their opinion and influence the discussion (as long as it's clear who counts and who doesn't). Voting can also be used for small issues (such as a new capability) as well as big issues (releases)-- there's a continuum. Has there ever been a case of a fraudulent emailed vote? The public nature of the voting means that as long as the real person is reading email, such a vote would be quickly noted. WILL On 12/21/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
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]
-- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
