|
|
| Line 1: |
Line 1: |
| | == What is VoteWrap? == | | == What is VoteWrap? == |
| | | | |
| − | [[Votewrap Process Flow - Detailed|VoteWrap]] is an open source method that handles contention in collaborative environments. | + | [[Votewrap Process Flow - Detailed|VoteWrap]] is an open source method that has been developed to improve the handling of contention in real or virtual collaborative environments by introducing a variable consensus level calculated from how important and urgent an issue is to each voter. And, by dynamically integrating all the following formal and informal elements of voting: |
| − | | + | |
| − | === Contention Handling in Collaborative Spaces ===
| + | |
| − | | + | |
| − | Traditionally most real-time group business required a common physical forum. Now with the Internet and its many collaborative spaces groups no longer need to meet in the same physical location. Examples of such collaborative spaces are Lotus Notes, Wikis, Blogs, SharePoint, Forums, Bulletin Boards, Shared Excel Spreadsheets, Google Docs and Facebook to name a few.
| + | |
| − | | + | |
| − | Collaborative spaces have certainly made it easier to have your say. But, it is now harder to be heard as their are so many more people raising and commenting on issues. And when the collaborative space participants disagree about all or part of an issue none of the collaborative spaces have adequate methods to resolve the contention. At best differences are highlighted and participants are given the option to accept or reject changes. Evidence and merit all too regularly take second place to raw politics and unfortunately flawed decisions are usually the result. The jokes about the decisions made by committees highlight this only too well.
| + | |
| − | | + | |
| − | The [[Votewrap Process Flow - Detailed|VoteWrap Method]] has been developed to improve the handling of contention by introducing a variable consensus level calculated from how important and urgent an issue is to each voter. And, by dynamically integrating all the following formal and informal elements of voting:
| + | |
| | | | |
| | * Issue Proposal | | * Issue Proposal |
| Line 32: |
Line 24: |
| | | | |
| | * Undecided Votes | | * Undecided Votes |
| − |
| |
| − | * Relative priority to other issues
| |
| | | | |
| | * Associated sub-issues | | * Associated sub-issues |
| | | | |
| | + | * Relative priority to other issues |
| | | | |
| − | Complexity is reduced and time saved as [[Votewrap Process Flow - Detailed|VoteWrap]] carries each voter's default settings into each new vote so for most Issue's you'll only need to vote for:
| |
| − |
| |
| − | * Importance - Low, Medium or High
| |
| − |
| |
| − | * Urgency - Low, Medium or High
| |
| − |
| |
| − | * Actual vote - No, Undecided-No, Undecided, Undecided–Yes or Yes
| |
| − |
| |
| − | * Confidence Level - Low, Medium or High
| |
| − |
| |
| − | * Voting Finalisation - Yes or No
| |
| − |
| |
| − |
| |
| − | With [[Votewrap Process Flow - Detailed|VoteWrap]] you can either vote for the whole issue or, if you’re not happy, propose amendments by VoteWraping dependent sub-issues for resolution.
| |
| − |
| |
| − | Visual pattern recognition is a human strong point so by viewing your real time prioritised VoteWrap issues in your favourite [[data visualisation format]] you’ll know more, sooner.
| |
| − |
| |
| − |
| |
| − |
| |
| − | This problem can be solved by applying the 'Object Oriented' method of software development to the creation and management of documentation. In other words, 'Object Oriented Documentation' or 'OO Doco' for short. An example of 'OO Doco' is the specification of the [[Votewrap Process Flow - Detailed|VoteWrap Method]].
| |
| − |
| |
| − |
| |
| − | ==== 'News Forum' Example ====
| |
| − |
| |
| − | When news items appear online and are opened for comment there will often be a large number of respondents having their say. Most of the comments will be either for, against or some degree of undecided. If you have ever tried to read all the comments you will know that it quickly becomes very tedious after the first couple of dozen and most people just give up.
| |
| − |
| |
| − | The [[Votewrap Process Flow - Detailed|VoteWrap]] / 'OO Doco' solution is to take the the thousands of words written by hundreds of people and reduce them to tens of words with the 'for', 'undecided' and 'against' positions noted against the chosen words for the issue. So instead of having to read all the relevant and irrelevant comments to understand the issue and what the collective position of all participants is you only need to read the distilled set of words and view the aggregated position of all participants.
| |
| − |
| |
| − | ==== 'Software Development Life Cycle' Example ====
| |
| − |
| |
| − | Traditionally many documents are produced that give a particular view of the same element depending upon which phase of the SDLC it is being viewed from. For example in a simple SDLC a 'user requirements' document is written, this is then expanded into 'functional requirements', then the 'technical specification' is produced after which the actual software code is created. Then a 'test plan' is written which is then elaborated into 'test cases'. Out of testing there are 'defects' & 'Issues' documented and interim and final 'test summary' reports. Almost always there will be 'change requests'. Further on there will be 'training guides', 'user manuals' and 'marketing' documents.
| |
| − |
| |
| − | The complexity is increased further as each document goes through its own cycle of producing draft copies for review. Then the review comments have to be merged back into the next draft. Where there are differences in the review comments these need to be resolved with the reviewers. This is usually a time consuming process especially as reviewers are making comments in isolation and they do not know that other reviewers may have already fixed an issue or that they have information that would influence how they see the issue. Furthermore in the process of resolving issues usually many emails are generated which often contain valuable information that does not make its way into the final documents. And this is just to produce the first draft! No wonder documentation is usually poorly done ( if at all ) and is almost always out of synch with the code and the real requirements of the system.
| |
| − |
| |
| − | And it gets worse because when a change is found or introduced in one document it often has to be propagated into other documents. And just by having so many documents there is usually the overhead of some sort of reference codes to link requirements to specifications to test cases to defects to change requests ... etc.
| |
| − |
| |
| − | The 'OO Doco' solution for the SDLC is to use a collaborative space to document each element once in a 'Boolean logic' workflow that replicates the way real users interact with the system. Where relationships exist between elements hyperlinks are made between them. If more detail is required on an element just add a linked page. Document change control is not required as each page in the collaborative space has a full revision history. Special codes to link elements are also not required as any links use the full text description. Emails are not required as the collaborative space can accept a dump of information that can then be fitted into the overall information structure at a later time. Changes to an element in one document does not have to be propagated into another document as their is only one document. All participants in the domain can see all other comments made about an element so there is minimal lag in transferring information between participants. Furthermore, as all the information about an element exists in one place there is no need for one group in the SDLC to decide what they should or should not put into their view of the element.
| |
| − |
| |
| − | Normally control in a collaborative space over who can make changes to the document is granted by controlling user access via security permissions. Whilst better than a free for all this is still quite a crude way of controlling how consensus is reached on any contentious issues. By implementing the [[Votewrap Process Flow - Detailed|VoteWrap]] method complete and effective control is gained over any contention.
| |
| − |
| |
| − | The resultant 'OO Doco' is then usable by all the participants in the SDLC and is the only document that would be required to describe the system. Another benefit of this approach is that all the 'business scenarios' of a system can be explicitly described and as a result exhaustively tested which then allows a 100% guarantee to be given that if these system paths are used then the application will be virtually defect free. This then allows for very clear 'Service Level Agreements' to be struck.
| |
| | | | |
| − | ==== 'Political Cooperation & Competition' Example ====
| + | The VoteWrap Method exists as a [[Votewrap Process Flow - Detailed|documented specification]] and as a set of fully functional Excel prototypes. |
| | | | |
| − | In any group there will be competition and cooperation. Politically this translates to right wing and left wing. In business it is free enterprise and public service. And the supporters of each side usually claim that their way is the best. However, any thoughtful analysis must eventually come to the conclusion that both are needed in the right balance for the happy, healthy, effective and efficient functioning of any group. After all have you ever seen a bird with one wing fly? Competition without cooperation ends up with disparities in wealth and opportunity. Cooperation without competition results in complacency and mediocrity. And like any system that is out of balance it is not stable and will fluctuate to a lesser or greater extent from one extreme to the other trying to find an equilibrium.
| + | The next stage in the development of VoteWrap is to implement the method into a real collaborative space such as MediaWiki. |
| | | | |
| − | Almost all the current forms of Democracy are out of balance as they are inherently more competitive than cooperative. Just look at political parties, they are like sporting teams or waring tribes who battle each other and the truth is usually injured in the first five minutes of play and has to be stretchered off the field. Once you join a political party you can't be the member of another party. To be a candidate for a political party you have to win preselection which is often a no holds barred fight. If you don't join a political party and run as an independent you still have to compete with all the other candidates to win a seat in an electorate. Each political party has a person called a 'whip' to keep the elected representatives in line. So it is not surprising that our political system is out of balance. And, this is also true of the business world where competition is considered a key element for success. This is reflected in words such as 'hard ball' and 'aggressive time frames'. At best cooperation is mostly seen as a luxury that can only be afforded when the competition is not too strong and at worst something for wimps.
| + | In practice VoteWrap is most effective when applied to 'Object Oriented Documentation' (a.k.a. 'OO Doco'). An example of 'OO Doco' is the specification of the [[Votewrap Process Flow - Detailed|VoteWrap Method]] itself. And here are some examples of how VoteWrap and OO Doco integrate together to create real world benefits. |
| | | | |
| − | The 'OO Doco' approach is used to more effectively and efficiently identify and manage the common issues in an electorate.
| |
| | | | |
| − | Then by implementing [[Votewrap Process Flow - Detailed|VoteWrap]] into the traditional political process the balance between competition and cooperation can be restored.
| |
| | | | |
| | | | |
| Line 94: |
Line 42: |
| | *[[Votewrap Process Flow - Detailed|VoteWrap Process Flow]] | | *[[Votewrap Process Flow - Detailed|VoteWrap Process Flow]] |
| | *[[VoteWrap Copyright|(C) Copyright 2008-10 - Thor Prohaska]][[Image:gplv3-88x31.png]] | | *[[VoteWrap Copyright|(C) Copyright 2008-10 - Thor Prohaska]][[Image:gplv3-88x31.png]] |
| | + | * [[data visualisation format|Data Visualisation]] |
| | | | |
| | ====VoteWrap Archive==== | | ====VoteWrap Archive==== |
The next stage in the development of VoteWrap is to implement the method into a real collaborative space such as MediaWiki.
In practice VoteWrap is most effective when applied to 'Object Oriented Documentation' (a.k.a. 'OO Doco'). An example of 'OO Doco' is the specification of the VoteWrap Method itself. And here are some examples of how VoteWrap and OO Doco integrate together to create real world benefits.
