Maybe someone could just create a script of some sort to parse out the vote tallies from a group of emails? ..
On 12/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
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]
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
