I chair a process improvement group, and one of my advisors recommended that the group vote to prioritize our proposed process improvements. I couldn't find any information on such a process in MegaCorp's internal website (so far), so I'm checking external sources.
This one's overkill for us, but it's interesting nonetheless. From Open For Business (OF4Biz):
OFBiz Feature Voting Site
We are excited to introduce a new level of opportunity for community involvement in the progress of OFBiz: the OFBiz Feature Voting Site. This tool will help to fund the continuation of the project and at the same time provide a mechanism for focusing and utilizing community feedback and priorities.
The site is built using components from OFBiz including the eCommerce and Work Effort applications. As votes are purchased for specific tasks those tasks and the tasks that they depend on will rise to the top of the priority list. As tasks from this list are worked on and completed status updates and comments will be attached to them to that everyone can see how things are progressing, and approximately when specific features will be implemented.
We will create new tasks from requests submitted in the request area of the voting site. This provides a way for you to get your own needs into the system as tasks in addition to being able to prioritize existing tasks.
Please check back soon for a status update on the voting site. It should be up early this year (2003).
Obviously "update the website" didn't rank highly, but the idea of having a specific number of votes which have to be allocated is inspiring.
But let's move back to 1995 to see how MetroGIS prioritized items:
The final activity of the December 14, 1995, strategic planning retreat required each participant to "vote" for the concepts that they believed to be critical to successful implementation of the MetroGIS. Each participant was given five green dots to illustrate their short-term priorities (completed in one year or less) and five orange dots for their long term high priority concepts. The priority ranking exercise concluded at 5:15 p.m.
This one's interesting because it encompassed both short-term and long-term actions.
OnBoard (at SourceForge) chartered this process for code changes:
When someone wishes for one or more of the programs or documentation entries in the OnBoard Suite to be changed, they add an entry to the OnBoard Suite's bug list or feature list. The item can be moved to the task list (the "Data Type" of the item is changed to 'Tasks') in one of the following ways.
A regular vote. This process is as follows.
A developer (other than the one that made the entry) attaches a comment to the entry 'seconding' the call for vote before the vote can proceed.
Next, an administrator posts on the Developers' Private Forum, a ballot.
All developers get one vote per feature (though, any developer can register an I-abstain-unless-I-explicitly-vote with the administrators).
A regular vote lasts for a minimum of 48 hours. After that period of time, the vote lasts for a week or until the majority of non-abstaining developers (that is, all of the I-want-to-vote-explicitly-in-every-vote developers plus anyone else who votes) agree (for or against the task), whichever is shorter.
If a majority of non-abstaining developers vote for the task and at least two votes are cast, the administrators will move the item to the task list. Otherwise, the status will be changed to 'closed' with a resoultion of 'rejected'.
A 'Quickfix' vote. Administrators can call for a 24-hour approval process for certain "quickfixes" that are not expected to create conflicts with upcoming tasks. This process proceeds as follows.
An administrator posts on the Developers' Private Forum, a ballot stating 'QUICKFIX' in the title.
Each developer gets one vote per feature (rules for abstaining developers apply).
A quickfix vote lasts for 24 hours.
As long as there are not 2 dissenting votes within the 24 hours (and dissent could be either with the task as proposed or with classifying it as a quickfix) the task will be approved.
If the task is approved, administrators will move the item to the task list. Otherwise, the status will be changed to 'closed' with a resoultion of 'rejected'.
Administrative action. An administrator can modify any item on any of the lists including moving or adding an item to the task list.
Alternatively (heh), there's Krist Novoselic's Instant Runoff Voting solution. One update from my 2004 post: fixour.us now redirects to FairVote.
Posts
Tom Petty's second and third breakdowns
-
I just authored a post on my "JEBredCal" blog entitled "Breakouts, go ahead
and give them to me." I doubt that many people will realize why the title
was...
3 years ago
1 comments:
While it's clear that our traditional "vote for one" (plurality) voting system is inexcusable, Instant Runoff Voting is not much better - and there are many better simpler solutions. There is also a great deal of public misunderstanding and misinformation surrounding IRV, largely the result of the IRV propaganda organization, FairVote.
One common myth is that IRV elects "majority winners". But IRV can lead to the election of candidate X, even when candidate Y is preferred to X by a huge majority. Consider this hypothetical IRV election.
#voters - their vote
10 G > C > P > M
3 C > G > P > M
5 C > P > M > G
6 M > P > C > G
4 P > M > C > G
C is the clear Condorcet (condor-SAY) winner, meaning he is preferred by a landslide majority over all his individual rivals. He is preferred over G, P, and M all by an 18-10 margin.
But... M wins, even though he also has fewer first-place votes (6 voters) than C with 8.
Also:
1. P is preferred to M by 22 of the 28 voters, yet he's the first candidate eliminated.
2. G also has more first-place votes (10) than M's 6.
3. So M either loses pairwise to, or has fewer first-place votes than (or both) every rival, but still IRV elects M.
Notice that the first group of voters could have caused C to win if they had only "lied", and put him first in their list. That would mean they'd get their second favorite instead of their fourth favorite. Statistical analysis reveals that this strategy is advised for all candidates who don't appear to have at least a 20% chance of winning. That means that, contrary to FairVote propaganda, IRV does not let you "vote your hopes, not your fears". And this means that IRV effectively degrades toward plain old plurality (vote-for-one) voting. This is explained in more detail here, by math experts:
http://rangevoting.org/TarrIrv.html
Election integrity experts and activists, like computer science Ph.D. Rebecca Mercuri disapprove of IRV because it is conducive to the adoption of fraud-susceptible electronic voting machines. IRV is also more susceptible to fraud because it is not countable in precincts. That is, candidate A could win every individual precinct, but bizarrely lose when the ballots are all summed together - which enforces centralized tabulation, which is more susceptible to central fraud conspiracy. And IRV typically causes spoiled ballots to go up by a factor of about 7.
http://rangevoting.org/SPRates.html
A much simpler and far better system is Approval Voting. It's just like the current system, except that there is no limit on the number of candidates one may vote for. While it may seem initially less intuitive than ranking choices, deep scrutiny shows that Approval Voting produces a far more representative outcome, and is less harmed by problems like strategic voting. This is shown through an objective economic measure called Bayesian regret, which shows how well a particular voting method tends to satisfy the preferences of the voters. The improvement gotten by Approval Voting relative to IRV is especially large if the voters are strategic, as was described above (although FairVote promoters will often falsely claim that the best strategy with Approval Voting is to "bullet vote"). See:
http://rangevoting.org/BayRegDum.html
If we don't mind a somewhat more cluttered ballot, we can upgrade to Range Voting, which uses a ratings scale, like Olympics scoring. It is arguably more intuitive, and produces phenomenal Bayesian regret results, meaning more satisfied voters, and more competitive nominees if used for a party's nomination process (i.e. a big strategic advantage).
For a look at how the major parties could become dramatically more competitive by merely adopting Range Voting or Approval Voting, see:
http://rangevoting.org/ForDems.html
http://rangevoting.org/ForReps.html
Election reformers must be diligent and do their research. Don't be misled by FairVote's clever marketing. Look at what Ivy League mathematicians and political science experts such as Steve Brams, who write entire books on this stuff, say. FairVote has an agenda, and it's definitely not in the pubic's best interest.
Clay Shentrup
San Francisco, CA
415.240.1973
clay@electopia.org
P.S. Krist Novoselic is a spokesman for IRV, not an election methods expert by any stretch of the imagination. Here's a video of a talk he gave in Seattle in 2007, in which I asked him a question about IRV's anti-majority (Condorcet criterion) failure - which he confused with the monotonicity criterion. God bless him for the amazing grunge music he made, but what business does he think he has talking about a subject on which he's utterly clueless and incompetent?
Post a Comment