The PolliteLens is a SoftwarePattern, like the WikiPattern.

An example of something the PolliteLens does well that 
Wiki does not do well yet is drive consensus on complex,
divisive issues.  However, Wiki is clearly the substrate
of agreed simple points that I have been looking for.
I am very excited about reconstructing the PolliteLens
as grounded in Wikipedia and Wiktionary.  

The "classic" website is at http://www.pollite.org.

Note that the polling mechanism allows not just voting, but taking of a Position
that includes Reasons for your vote.  Each Reason is a pointer to another Claim that
can be voted on (where a Claim is basically a Wiki Article).  The intent is to encourage 
formation of coalitions
of folks who vote the same way, but for different reasons.  The polls are also intended
to be long term, so that you can change your Position on as you learn more and change your views.

Also note that the polling in this scheme is never anonymous.  The user is taking a public position, as part of a public platform.

''I'll take a public position: I'd like to see Pollite in action in a (/this?) wiki. I wonder whether some here would consider this mechanism a rival to the processes that maintain and shape this wiki now. I may be biased by recent events that made a big impression on me (pages deleted with no explanation), but it seems that there is a tacit understanding here that taciturnity is a virtue that protects the (underlyingly democratic) process. Providing a (presumably lightweight) voting mechanism would be like documenting code, which of course has its champions and detractors here (ProblemsWithDocumentation). -- TomRossen''
----
Documentation is an excellent comparison.  One huge difference between the PolliteLens (as originally implemented) and the dominant Wiki mode is that the P.L. does not allow editing of documents (claims) once they have been submitted.  This mean you are always voting on a fixed claim.  To revise a claim you can VOTE to revise it which serves as a flag to other users that an alternative phrasing has been offered.  This mechanism is cumbersome and formal in comparison with the WikiWay, however it ensures a certain kind of fairness.  No one can edit a claim that you have voted on (i.e. change the code you have already documented).  They have to create a new claim and encourage you to vote on it.   Naturally,
the software should notify you when someone proposes a revision to a claim you have voted on, and maybe we can adapt existing wiki change notification mechanisms to do this.

The intentional freezing of claims slows everything down, of course.  The question is how to use the Wiki paradigm to supplement the Lens paradigm (or vice-versa).  

	1. It seems you could at any moment snapshot a Wiki page and turn it into a Lens claim, then request that people vote on it.  The claim can retain a pointer to the still-editable Wiki page that formed the basis for the claim.  I guess it's like a tagged version in CVS that forms a branch.

-- StuBaurmann