Mini-pollwiki

[Alex Rollin]

Mike and all,

I think attempting a focus on a 20 (smallworld) user groups is a great  
idea.

This was also the imagined size of my test case, P2P Housing, that I  
setup and tested on the pollwiki.

It seems to me that you are now working to abstract the entire  
pollwiki interface for small groups.

I think this is a laudable goal: yay!

It seems to me that the project has gone a long way around back to a  
central issue:

The centrality of the pollwiki and then the interface with the  
pollserver.

Here's my stab at what the pollwiki does:

User logins
User "grouping"
Drafting
Rectification of login with draft
Rectification of login with pollserver
Data exchange with pollserver

It seems to me that these are the basic functions of any "pollwiki".   
What am I
Missing?

What I am wondering is, why not just make the pollserver work better  
with services and thereby define a general set of requirements for a  
pollwiki type app.  Call it an API for front end apps like the  
pollwiki.  It seems this is getting jumped over with a project to  
abstract the cross-forum.

I still just want to be able to build a Drupal based app that talks  
directly to the pollserver and other votorola services servers,  
replacing any need for me to deal with the pollwiki and pollwiki  
related issues.

I want to
Register and group my own users in my own app
Draft my own petitions in my own app
Submit draft urls to the pollserver
Submit login approve/deny/grouping information to the pollserver or  
other utilities

I tried very hard to push this forward before.  I am quite capable of  
building such an app on my own.  I just needed to know where to push  
the data.  The answer I kept getting was that I had to go through the  
pollwiki.  Then and now this added to much complexity.

What I understand now (and surely I am wrong in some ways and not  
using the correct language) is that you are planning to build yet  
another customized front end, and that you, the core deceloper, will  
be able to make it , the new app, talk to the pollwiki but I won't.  I  
can't simply clone out that function and rebuild it in my own tools  
because you are building a special case that will again talk to or  
through the pollwiki or other tools that don't yet have a clear API.

My request:

Let the end users build their own front end.  Focus on the spec for  
how that can work and call it an API.  Build an API for all the  
servers you are running.

We out here with communities with build front ends to meet the needs  
of our communities.  Please help us by making yoir APIs useable.

We, the user communities, want:

Global login IDs that are federated
Our own access control lists
Our own front end
Our user user management tools
Our own vote tally algorithms thay access our own voter access lists
Global vote mirroring services (anyone can vote but not all votes are  
tallied)
Access to render vote trees filtered for access lists

These are simple things and no doubt yoi will be using these functiobs  
in te cross forum interface.  What I see is that this group could be  
organized in some way as a consensus group that votes and resources  
API services.  Instead I see a group trying to build attractive user  
interfaces to lure alpha testers when there is no services API.

Alex





On Jan 11, 2012, at 2:04 AM, Michael Allan <mike at zelea.com> wrote:

> Dear all,
>
> The attempt to initiate alpha trials + vote mirroring (Open Voting
> Network) in Occupy Wall Street is dying in the NYCGA.  If it weren't
> for Stephen Coffman's generous help, it would be completely lifeless
> already.  As it stands, I doubt it can survive past January 19, which
> is the deadline to arrange on-ground meetings in New York as required
> under the new NYCGA rules.
>
> So I want to propose another plan.  This one is centered on Votorola
> in the short term:
>
>  1. Code a mini-beta.
>
>     The development target is ease of use for small-group
>     consensus-making practices of up to 20 participants.  Here are
>     the main tasks:
>
>     a) Place the Crossforum Theatre toolbar as a kind of common
>        dashboard atop all primary service/tools and pages:
>
>          * Difference bridge: (as it already is)
>            http://zelea.com:8080/v/w/D?a=5208&b=5206
>          * Votespace:
>            http://zelea.com:8080/v/w/Votespace?p=G!p!govn&u=Mike-ZeleaCom
>          * Pollwiki: http://zelea.com/w/User:Mike-ZeleaCom/G/p/govn
>
>        The toolbar will carry the common controls, especially those
>        for navigation among the various service/tool pages.  There'll
>        be no actual Crossforum Theatre app anywhere, of course,
>        because it's not finished, and also because it's not needed
>        for small groups.  We'll pull it in later, as needed.
>
>     b) Improve the navigation controls for the bridge footings.
>        http://zelea.com/w/User:Test-bg-ZeleaCom/G/p/sandbox
>        (see the doo-hickies floating near top left)
>
>        A bunch of minor changes are needed, and one important one:
>        add co-voters.  Differencing among co-voters is very common.
>
>     c) Automate the creation of initial position drafts.
>
>        This is what happens when the user clicks on "My position" or
>        whatever and there's no actual position.  We'll query the user
>        for creation parameters and confirmation of intent.  We'll
>        include an option to cast an initial vote (so there's no need
>        to mess with a pin-up in that case).  Then we'll place the
>        user on the newly created draft page, with initial content,
>        etc, ready to go.
>
>     d) Single sign-on.
>
>        Implement a single login to cover all servers (pollwiki,
>        vote-servers, etc.) of the local network cluster.
>
>        This is left either for last, or for another developer to take
>        up in parallel.
>
>  2. Conduct alpha trials using the mini-beta release.
>
>     Note these will be alpha trials, not beta.  A core group of
>     superusers will push the practice beyond the small-group
>     boundaries of the mini-beta, and thus push the development of
>     Crossforum Theatre. http://zelea.com/project/votorola/a/xf/
>
>     So Crossforum Theatre remains the platform on which the full beta
>     will unfold.  We won't get there in a single leap, that's all.
>
> Please let me know if this conflicts with anyone else's plans. I can't
> start for roughly a week, so I'm still open to alternatives.
>
> -- 
> Michael Allan
>
> Toronto, +1 416-699-9528
> http://zelea.com/
> _______________________________________________
> Votorola mailing list
> Votorola at zelea.com
> http://mail.zelea.com/mailman/listinfo/votorola