This is a legacy post, originally posted at correntewire.com, here, on 8/6/2015
Update: Announcements regarding this project will be tweeted at @votersrevenge7, and facebooked at “Voter’s Revenge”. (Also, found out yesterday I have to move within 8 days, which will impact posting of design artifacts.)he
Update 2 Aug. 22, 2015: (the last update on this diary; for future updates, see twitter feed @votersrevenge7) . A mind map of a Use Case typology is here. The underlying document behind that image was initially created with xmind, and is here. If you download and install xmind, you can pan around the xmind document.
Also, I have changed the terminology. A “hound” type user is now referred to as a “wrangler”, and a “local posse” is now referred to as a “buddy posse”.
==============================================================
This document is a User Requirements Design Document for a new Web Application, still to be designed and coded, which has the purpose of empowering voters to get rid of incumbents who serve the plutocracy more than their constituents. For the ill-informed among us, the need for such an application is well motivated, as the corruption of the US political system is beyond any serious question (Reference: Corruption is Legal in America )
The announcement of an “official”, open source project to support this effort is to be expected, next week. In the meantime, readers are asked to query their contacts for civic minded software developers, who would be willing to contribute their efforts to the open source project. For that matter, volunteers that would be willing to contact programmers and programming shops which they are not acquainted with, and solicit vounteers, would be appreciated.
Core Ideas
• A “transpartisan negative vote bloc” is a group of concerned citizens, that easily spans partisan boundaries, and that looks to regain control of the elected government, away from the plutocracy, ultimately by credibly threatening to vote them out of office. “Transpartisan Negative Vote Blocs” do not necessarily back any particular alternative candidate for office, and indeed should be almost as active outside the election cycle (when alternative candidates have not even announced), as they are during the election cycle.
• The “Transpartisan Negative Vote Bloc” web application described below will be designed to facilitate the formation and rapid growth of transpartisan negative vote blocs, and also look to facilitate their cooperative and social behavior at a face-to-face, local level.
• The “Transpartisan Negative Vote Bloc” web application will never recommend any alternative candidate, but will suggest one for primary elections, on a purely random basis, so as to avoid vote splitting.
Glossary
• “Transpartisan Negative Vote Bloc” will be abbreviated TNVB
• A vote bloc will be synonomously referred to as a “posse”
• A posse “redline” is a condition which will trigger the posse’s punitive behavior.
• “The system” means “this Transpartisan Negative Vote Bloc system”
• “Sheriff” refers to a leader of a “local posse”.
• A “local posse” is one that has a smaller granularity than a “super posse” and that may, or may not, be a child of a super posse.
• A member of Congress who is a target of a posse may be referred to as a “Congress Critter”
• An incumbent who crosses the redline of a Voter’s Revenge Posse may be referred to as a “varmint”
• A Voter’s Revenge Posse member who is legally able to vote consistent with a posse’s goal and legal residence requirements, and has pledged to do so, will be referred to as a “voteslinger” (analogous to an Old West “gunslinger”). Posse members who cannot fulfill this criteria are referred to as “hounds”. (The will hound Congress critters and varmints, even if they can’t vote against them. Git it?)
• Western metaphors abound, like it or not – Yee ha!!
MindMaps and Grid
These three mind maps should prove useful in understanding the rest of this document
• Posse Breakdown
• Posse Member Types
• List Views
I’ve started work on other design artifacts. Here is a link to a “Posse Type Property Grid”. (not quite done).
Introduction
• To get an excellent idea of a finished example of what I would call a web-based Voting Bloc application, which exploits social networks for recruitment and reinforcement of voting behavior, would look like (but focused on positive campaigns), please see this youtube video interview of the former CEO of votizen.com, David Binetti: Votizen is using social to disrupt how you’ll vote on next election
• Unfortunately, votizen.com was acquired by causes.com, which is basically little more than a petition engine (though one which leverages social networks). While significant synergies were anticipated at the time of the acquisition, I not only see no evidence of any, I fail to detect even the basic capability (voter recruitment for real world political campaigns) and leveraging of key asset (voter database of over 200 million Americans) that votizen.com had, that made it so promising.
• According to a very recent communication from causes.com, Jason Putorti, a co-founder of votizen.com, has some involvement in his current startup (brigade.com) re-acquiring causes.com (and thus, presumably, the votizen.com codebase as well as the voter database). I think this has to be taken as positive news; however, when I asked for a roadmap, and specifically whether or not the votizen.com features would be recreated, I was asked to “stay tuned”. They are in some sort of transition phase, which, it is suggested, makes answering my requests a non-priority or difficult.
• In no way am I going to wait around for brigade.com/causes.com to come to our rescue, though I wish them well, and note that, should they proceed in a direction to genuinely empower voters (as well as create a sustainable business), then they may end up becoming the number 1 host of transpartisan negative vote blocs. I am hoping to see the software encompassing my vision created ASAP, and while I have the skills to eventually write every line of code, myself, I certainly hope to avoid that; that is the main reason for going open-source. But, I don’t have any resources for hosting the web application that is to be created, assuming that it grows to meaningful size (10’s of millions of voters). Should the recently acquired causes.com get serious about disrupting the US electoral process, and empowering non-plutocratic-funded candidates, then hosting a transpartisan negative vote bloc technology would not only nicely complement their main offering, it could help promote it during the off-political season. The Transpartisan Negative Vote Bloc application focuses on incumbents, and potentially can draw just as much attention outside the electoral cycle, as in it. So, there is no need to wait for all candidates to be known before organizing and building political muscle takes place.
• Posses will always be used to remove incumbents from office, or to prevent a candidate for a vacated office from being successful. I.e., posses are punitive, first and foremost.
• Punitive voting emphasis will be on primaries (as that is when incumbents and candidates are most vulnerable to removal or defeat, respectively). The system will discourage users from only making pledges to vote in a general election (as opposed to voting in a primary against an incumbent, as their first electoral ‘weapon of choice’ ).
On Day 1, TNVB (“the System”) Will and Will Not Do the Following:
• The system will not favor any alternative candidates, except on a purely random basis. (The reason to favor a single, alternative candidate, on a random basis, is to avoid vote splitting.) Randomness will be guaranteed via an algorithm which is published well before the determining, random event which it will use to seed the algorithm, and thus select a challenger. (An example of such an algorithm: the integer remainder of the Dow Jones Industrial Average, at closing time, on the 5th business day before Primary Day, divided by the number of official challengers in a given race. The candidates will be ranked alphabetically, and the candidate whose alphabetical rank matches the integer remainder of the DJIA will be the randomly selected favorite challenger of the system.)
• The system will not attempt to prohibit discussions by posse members to favor a particular challenger, but may segregate such discussions (if, indeed, it supports such discussion within the system at all, say via forum or threaded comment section). Of course, the system has nothing to say about what discussions posse members have outside the system, respecting their freedom of speech, and freedom of association.
• Posses will be partly defined by the type of redline the embrace.
• A posse’s punitive behavior will be comprised of at least 1 mandatory pledge. Individual members of a posse may declare additional punitive pledges, for themselves.
• There are 2 main types of redlines: One involves a defining vote by an incumbent(e.g., a vote for passage of TPP, the Trans Pacific Partnership).
• A second type of redline can be anything that it would make sense to punish an incumbent for, other than a defining vote. Example of this 2nd type of redline could be:
- Failure to publicly declare for or against an issue, or legislation, by a date stipulated by the redline
• e.g. “Congressman Jones must condemn the sovereignty destroying aspects of the TPP, by Oct 15, 2015, in a videotaped segment to be posted on his website and on youtube, including this exact phrase “I condemn the sovereignty destroying aspects of TPP”.
- Failure to publicly condemn the political party that an incumbent belongs to (chiefly, the Democratic or Republican Party), due to that party not declaring for or against an issue or legislation, by a date stipulated by the redline.
• e.g., assuming Congressman Jones is a Republican: “Congressman Jones must condemn the the Republican party for not condemning the sovereignty destroying aspects of the TPP, by Oct 15, 2015, in a videotaped segment to be posted on his website and on youtube, including this exact phrase “I condemn the Republican party for not condemning the sovereignty destroying aspects of TPP”.
- Failure to publicly condemn the President of the United States , due to the President not declaring for or against an issue or legislation, by a date stipulated by the redline
• e.g. “Congressman Jones must condemn the President of the United State, for not condemning the sovereignty destroying aspects of TPP, by Oct 15, 2015, in a videotaped segment to be posted on his website and on youtube, including this exact phrase “I condemn the President of the United States for not condeming the sovereignty destroying aspects of TPP”
• Posses which are defined by the first type of redline will be referred to as a “Voter’s Revenge Posse”. A Voter’s Revenge Posse most important members, referred to as “voteslingers”, must be committed to voting against their target politician, who must be an incumbent, if he/she crossed the redline. A Voter’s Revenge Posse may also contain “hound” members, who are unable (due, e.g., to legal constraints) or unwilling to make the signature vote pledge. “Hound” members must still make an alternate pledge, not involving their personal vote, but still meant to punish redline transgressions in a significant way.
• On Day 1, the system will be hard-coded such that all super posse redlines will be “Vote Against the TPP”. All redlines for corralin’ posses will be expected to be related to defeating TPP.
• Posses will be partly defined by their government level. In the US, the levels are: national government, state government, county government, municipal government. (The phrase “local government” is avoided, so as not to confuse it with a “local posse”, defined below) A Day 1 implementation should at least support posses which target national government (i.e., US Congress) incumbents, and US Presidential candidates.
• Posses will be partly defined by their posse granularity. There are 2 types of posse granularity. The first type is that of a Super Posse. There will be only 1 such posse per incumbent, per redline topic, in the system. (On Day 1, as the only redline topic is the TPP vote, there will only be 1 Super Posse per incumbent.) There will be no Super Posse for any challenger, only for an incumbent. All Super Posses are also Voter’s Revenge Posses. A Super Posse is essentially for all citizens within the system who are willing to punish an incumbent for crossing a critical vote redline.
- A Super Posse can contain the posses of the 2nd type of posse granularity, viz., local posses. Local posses are typically redundant – a citizen is able to join as many local posses as he/she can faithfully honor pledges to, and meaningfully participate in. A local posse encompasses a smaller granularity than a Super Posse, but not all members of a local posse need reside in the same local area. (So, the word “local” is unfortunately ambiguous, absent consideration of context.)
- Since a local posse might be confused with a posse whose government level property is that of local government, posses targeting government level consisting of local government will be referred to as municipal level posses.
- Not all local posses are contained within (or “children”) of super posses. In particular, all Voter’s Revenge local posses are children of a Super Posse, with which they share the same target politician and key redline. However, all corralin’ posses are local posses, and these corralin’, local posses have neither parents nor children in the system. Their redlines will be more varied, as will their mandatory pledges.
• A system wide, Voter’s Revenge Super Posse will only require a single voting pledge (by its voteslinger constituents) to deal with redline violations.
• A Voter’s Revenge Local Posse, while still requiring a negative vote pledge as a condition of voteslinger posse membership, may embrace additional mandatory punitive pledges. The decision about additional requirements, peculiar to any particular Voter’s Revenge Local Posse, will be determined by the posse sheriff, preferably after consulting with members of the posse.
• Posses which are defined by the second type of redline will be referred to as a “Corralin’ Posse”. Corralin’ is derived from the noun and verb, “corral”. Posse members are attempting to corral (i.e., constrain) an incumbent’s behavior, but still allow for the possibility of voting for their target. A Voter’s Revenge Posse is completely unforgiving on Primary Day or Election Day, but a Coralin’ Posse does not have such a strict requirement regarding voting by members.
• The system will track and readily display numerical totals of both voteslinger posse members, as well as hound posse members.
• The system will calculate “Political Muscle” scores of Super Posses, so that members of the system will be motivated, via feedback effects, to increase and/or sustain their efforts to recruit into the system, sufficiently to make a difference in the real world. These will be admittedly crude calculations, but which, it is hoped, nevertheless provide highly significant predictive ability as to how likely the Super Posse is to succeed. The two main inputs to the “Political Muscle” score are (assuming we are dealing with a primary)
- how many registered Republicans or Democrats normally vote in the primary
- how many vote-capable members of the Super Posse there are, who are dedicated to voting against the incumbent, and have high credibility scores. (Credibility score is explained, below.) If 2) exceeds 1), and posse members have agreed to avoid vote splitting, we will assume the odds of success are 100%, and so the Super Posse will have a “Political Muscle” score of 100%.
• The system will calculate Credibility Scores for individuals, as well as aggregate those scores for entire posses. Credibility scores will have inputs determined from social network feedback endorsing the reliability of a posse member to follow through with redline pledges. (Votizen indirectly revealed credibility via it’s ability to query it’s voter roll database, cross matched with its membership database. AFAIK, it did not actually compute any type of credibility score.) As far as the author knows, only Facebook and LinkedIn offer such capabilties.
• A posse sheriff is expected to contact his local posse members at strategic times, to remind them to keep their pledges. (E.g., a week before a vote, or a week before a required party registration deadline)
• While a negative vote is the main sort of pledge that a Voter’s Revenge Posse embraces, Corralin’ Posse pledges are expected to typically punish their target by undertaking actions to
- educate the public in the target politician’s constituency about the redline issue
- educate the public in the target politician’s constituency about the failure of the target to honor the redline
- publicly confront the target (such as at town halls) about the target’s failure to honor the redline
- “adopt” additional local organizations within the target’s constituency to inject memes, in a personal way, that educate’s that organization’s members about the target’s failure to honor the redline, or about the redline issue, in general. (This adoption process will eventually be somewhat automated via another pro-democracy web based tool that the author is looking to create.)
• The system will contact all system member’s who belong to Super Posses, at strategic times, relevant to their voting pledges (so, preceeding Primary Day or Election Day).
• The system will automatically enroll new members of Voter’s Revenge Local Posses into the Voter’s Revenge Super Posses, which is the parent of the Local Posse.
• The system will automatically invite new members of Voter’s Revenge Super Posses to consider requesting admittance to at least one child Voter’s Revenge Local Posse. The system will attempt to steer suggestions towards a Local Posse whose members are physically close to the user. (So as to facilitate the formation of face-to-face relationships.)
• The system will feature the following main views:
- All Super Posses
- All Local Posses
- My Posses (i.e., posses that the logged in user is a member of, both Super Posses and Local Posses)
• To inhibit spamming and trolling, it is anticipated that all members of the system must log in via Facebook or LinkedIn (also, eventually perhaps other social networks that make some effort to filter out fake identities. Votizen used to cross check users with their voter roll database, but the system is not anticipated to have any such asset until well beyond a Day 1 implementation, if ever. )
• Members of the system can add voluntary pledges, of their own choosing, to their list of pledges to any given posse.
• The system allows and expects members to update their pledge information with completion/failed-to-complete status.
• Members can modestly increase their credibility score by posting youtube videos a) affirming their intention to carry out their pledges, before the redline is crossed b) affirming their having fulfilled their pledge, after the redline is crossed. Members will be highly encouraged to increase their credibility this way, but their credibility scores will only be modestly increased, due to the fact that there is no way to automate the checking of said actions.
• The system will encourage users to submit approximate residence information. (E.g., accurate to within a zip code.)
• The system will use this geographic information to encourage members who live near each other to physically meet and undertake civic-related actions together.
• To this end, the system will encourage users to form and utilize local meetup.com meetup groups.
• The system will display a view (and frequently, partial views within other types of views) of local meetup.com groups related to posse activities.
• The system will encourage posses to make use of the tool loomio.org, to help make cooperative group decision making efficient.
• The system will enourage posses to make use of an online kanban tool to distribute and plan workload tasks related to their activities that require such. (Some possible candidates: trello.com, agilezen.com, mykanzen.com)
On Day 2, TNVB (“the System”) Will and Will Not Do the Following:
Note: in the following, the word “local”, preceeding the word “chapter”, is taken in the usual sense of “nearby”, as opposed to the concept of local in the small posse granularity aspect, which will be referred to as a “local posse”.
• The system will allow for the formation of local chapters, which of course will be more amenable to face-to-face meetings and action.
• While the system will attempt to facilitate the formation of local chapters, it will also attempt to suppress an over-proliferation of local chapters. One possible algorithm to be investigated, towards this end, is as follows: A user of the system may form an “official” local chapter of a posse no closer than 4 miles to another “official”, local chapter of a posse. “Official” local chapters are to be considered preferable to “unofficial” local chapters, unless they are found out to be abandoned and/or misused by their founders.
• The system will display both “official” local chapters of posses, as well as “unofficial” local chapters. The system will discourage frivolous proliferation of “unofficial” local chapters, by requiring their creators to state a reason as to why they believe the competing official local chapter is unsuitable.
• The system will display contact information for both official and unofficial local chapters, including facebook page information, meetup.com name and URL, as well as upcoming meeting information.
• The system will encourage users to join local chapters, by frequently incorporating partial views of local chapters.
• The system will encourage local chapters to make use of the tool loomio.org, to help make cooperative group decision making efficient.
• The system will enourage local chapters to make use of an online kanban tool to distribute and plan workload tasks related to their activities that require such. (Some possible candidates: agilezen.com, trello.com, mykanzen.com)
On Day 3, TNVB (“the System”) Will and Will Not Do the Following:
• Redlines other than anti-TPP ones will become allowed, but subject to approval by system administrators.
• A survey for determining “degree of transpartisan support” will be undertaken, and a ranked view of various proposed super posse redlines will be displayed, together with the numerical rank of “degree of transpartisan support”
• Iniitial super possee redlines must have a transpartisan support ranking suggestive of “large majority” support. I will assume, at this time, that means a baseline of 66% approval across a transpartisan base.
• A phased rollout of new redlines should be done, perhaps on a schedule of one new redline every 2-3 months, working from most popularly supported super posse redlines, to less popularly supported ones.