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
Re: Jakarta Voting
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]
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
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: POI TLP -- constructively
Thanx for your reply :) See inline for one comment.. Nick Burch wrote: > On Mon, 18 Dec 2006, Martin van den Bemt wrote: > > What I'm not a fan of are the "one user and one dev list for jakarta" type > proposals. If the option was that, or TLP, I'd start writing the TLP > supporting docs right now. Oh, but that's not an invition to suggest it, > just to get us out ;-) > This wasn't being proposed, but something along those lines is (probably) going to be proposed for at least some Jakarta subprojects (you could think of ORO, Regexp, ECS). But those project actually have about 3 messages a month combined.. But I will wait with new proposals till the next year. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POI TLP -- constructively
On Mon, 18 Dec 2006, Martin van den Bemt wrote: > If poi committers agree with this proposal, I like to "hear" them :) We had a discussion on something like this on the poi-dev list back in the summer. To save everyone having to trawl back, here's basically what I had to say. I it is felt that POI should migrate to a TLP, I'd be happy with that. I've had a chat with Henri, and I have an idea of what that'd entail. I'm happy to do some of the work on gaining TLP status, such as helping with the various documents and charters. If POI doesn't go for TLP, then I think it does need to integrate better with Jakarta. I think it would be good if more of our committers also submitted the odd patch to other Jakarta sub-projects, and if the odd jakarta committer contributed some code or advice to us. I think the easiest way to facilitate this is: 1) get all poi committers subscribed to [EMAIL PROTECTED] 2) get more poi committers to attend apachecons, party@ events etc, and meet more jakarta committers. (I found it very helpful to meet other jakarta people in person) What I'm not a fan of are the "one user and one dev list for jakarta" type proposals. If the option was that, or TLP, I'd start writing the TLP supporting docs right now. Oh, but that's not an invition to suggest it, just to get us out ;-) On a related note, I feel I ought to stand up a bit for the POI support for the recent release. I was given some advice, made use of the same build tasks as last time etc. The problem wasn't so much that I wasn't fully supported, it was more that the advice and build process was out of date. In future, we'll do POI releases according to the latest advice, as two votes (one for the idea of a release, and one to approve the files for the release). So, we'll be able to get advice from the rest of Jakarta if we ever fall behind on release best pratices :) Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Voting
Hi, > I think that Jakarta needs a voting application that can include PMC > quorum requirements, direct email vote requests, committer approval, > etc. do you really expect people to click at a link in an email and vote via webinterface when they don't press reply and write +1? :-) Cheers, Chris P.S.: for archiving reasons it may be good - 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]
