Re: Jakarta Voting
As we get more and more into auth, it becomes tempting to auth the whole thing. Vote through the webapp and not an email, You could sign your mail with a key you register for the purpose. listens to emails and a script that sends out emails in a particular format. Might work, but parsing replies would probably suck. You'd be suprised.. If the rule is that everyone must return a signed reply to the original mail and enclose their vote in [] ensuring that there's only one [] it mightn't be too hard. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
Hi Danny, As we get more and more into auth, it becomes tempting to auth the whole thing. Vote through the webapp and not an email, You could sign your mail with a key you register for the purpose. that's a big hurdle for a guest voter. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
Roland Weber [EMAIL PROTECTED] wrote on 22/12/2006 09:21:51: Hi Danny, As we get more and more into auth, it becomes tempting to auth the whole thing. Vote through the webapp and not an email, You could sign your mail with a key you register for the purpose. that's a big hurdle for a guest voter. It would only be necessary for binding votes to be signed. No? *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
Hi Danny, It would only be necessary for binding votes to be signed. No? That's a possibility. On the other hand, that could send a wrong signal to the non-binding voters: you don't have to sign your votes, they're not important anyway. I'd be very careful with such distinctions. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Voting
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 ;-) Regards, Dave Fisher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
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]
Re: Jakarta Voting
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]
Re: Jakarta Voting
Hi Henri, [...] I was mostly thinking about it because I felt like writing something new rather than maintaining code): That's the best reason of all :-) * 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. * Complicates casting a vote Thoughts on implementation. [...] It needs to be listening to emails, [...] Vote through the webapp and not an email, [...] People often comment with a vote though [...] 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. Correct me if I am wrong: the actual collecting of the votes from a vote thread is not that time-consuming, or is it? The following sorting and checking for binding/non-binding status is the really tedious work? If somebody feels like simplifying the voting by coding, I would rather suggest to define a simple text input format for votes. The one who called the vote goes through the replies and collects all votes into a text file, in random (or chronological) order. That could look like this: # allowed votes +1 +0 -0 -1 # cast votes -0 [EMAIL PROTECTED] +1 [EMAIL PROTECTED] ... That text file can then be processed by a script which: - checks for invalid votes (like -0 if only +1, -1 are allowed) - checks for duplicates (somebody changing his or her vote) - checks for binding/non-binding status based on email address - sorts the cast votes into groups - generates a text summary for pasting into an email That alone is tricky enough, if one should consider MailAliases.txt for the binding/non-binding check and maybe also the duplicate check. With a plain text format as the input, it is also easier to create an exhaustive set of unit test cases. Compare that to setting up a new mailing list plus generating emails there just for testing the voting application. But what I like most about this approach is that the voter experience doesn't change. You can still reply by email using informal language. The original mail can be quoted internet style, or TOFU, or not at all. You can write your +1 above the quote, or below, or you put your X into the line the lists the appropriate vote option, or you embed it in natural language. If the mails are parsed automatically, expect communications like this: Here's my +1. Could you write that again with just the +1 in a single line, with an empty line before and after? or if the parser is more flexible: I would have voted +1, but I'd like to get an answer to the following question first: [...] Oh, sorry, that was counted as +1 by the voting application. Could you send another mail with the text 1-- to undo that? Such syntactical ambiguities are easily enough resolved by an HVC preprocessor (Human Vote Collector) before the script ever gets to see the data. Mandating that votes be cast through a web application would solve the input format problem. But it would also require the voter to change from the email application to a web browser, and maybe from the keyboard to the mouse, to cast the vote. That may not be much of a problem (except for accessibility), but it is surely not an improvement of the voter experience. Vote casting by email encourages the lively discussions that are so important for community building ;-) Once such a script is done and thoroughly tested, there is still time to think about an automated input interface. I would suggest connecting to the mailing list archive rather than to the mailing list though. Since vote threads run for several days, you can't expect the voting application to run through without interruption. To allow for regular shutdown and startup, you'd need a persistent data store for the votes that have already been counted. Even so, if there is a crash and the server needs to be restored from a backup, the mails that came in between the backup and the crash would not be counted. And I guess no automated tool can deal with off-thread votes. Consider a controversial vote that is started, and people joining the mailing list afterwards just to cast their votes. These folks will not have the original mail to reply to. They might reply to another mail in that thread, or they might just type the subject line into a new mail. In the latter case, the mail would not be considered as belonging to the vote thread, or would it? In summary: if somebody wants to spend time on simplifying vote counting, I recommend to focus on the actual counting while leaving it to the human who called for the vote to collect the input. That should also help to keep the number of vote calls in check :-) cheers, Roland
