DemocracyLab Project Portfolio Onboarding Survey (votorola at zelea.com)

Thu Apr 4 18:41:10 EDT 2013

Hi Mark,

> Thanks for your comments.  I agree that we'll want more description
> for each of the questions.  This was an initial outline, which will
> later get turned into something more user friendly.  I also agree
> about creating ways for the survey to change over time, though I
> think some thought has to be given to keeping the length manageable.
> I'm not sure how to do this yet, perhaps creating a way to add
> additional questions that gets submitted to a moderator for approval
> or to the group of current projects for discussion.  I'm open to
> ideas concerning how to balance these competing objectives.

You're welcome.  One possibility is to change the data scheme (survey
design) only as needed.  It's normal to rationalize data schemes over
time and nearly impossible to get them right on the first go.  Changes
don't necessarily mean additions that increase the overall size of
data, though often they do.  But the size need never be more than
whatever you yourself judge to be appropriate.

A larger problem is perhaps loss of information as you drop obsolete
forms of data in favour of new ones.  If you leave the new noticeably
blank in the aggregate data views (as I suggested earlier) so the
users can eventually fill them in, however, then the problem might be
manageable.

> I'm curious in particular what the team thought of the content of
> the "Dialogue and Deliberation" section.  Mike explained to me that
> this is the primary focus of Votorola, and I'm wondering if you feel
> the questions asked provide adequate means to express Votorola's
> functions and capabilities?  If not, what could be added to make
> that easier (without asking questions that would be relevant only to
> Votorola)?

Here's what I would enter:

> > VI. Dialogue and Deliberation
> >
> >    a. Dialogue and Deliberation Description (Text)

Votorola does not itself provide a discussion medium, but instead uses
existing media of various kinds.  Currently it is restricted to media
that support text.  Examples are mailing lists and web forums, which
are primarily text, and also voice media that allow for simultaneous
text chat on a secondary channel (e.g. Skype or Mumble).  The text
capability is necessary in order to allow for the occaisional pasting
of formalisms such as commands and URLs in public, where they serve in
turn as the minimum connections between the discussion medium and the
Votorola toolset external to it.  Optionally, we also support
embedding the toolset within the medium itself.  Toolset data
representations that relate to D&D include a "talk track".  It shows a
live view (twitter-like) of discussions across all media in
intersection with issue and consensus structures.  More generally,
Votorola uses the structural complexity of consensus and dissensus as
a kind of trellis on which to grow the equal complexity of rational
discourses.  This formal structuring of consensus also provides a
motive for engaging in discourses in the first place, because it holds
out the possibility not only of general agreement on issues, but also
of action in consequence of it.

> >    b. Survey Capabilities (Y/N)

N

> >    c. Data Representation (Y/N)

Y

> >    d. Consensus Mechanisms (Y/N)

Y

> >    e. Conflict Mapping Mechanisms (Y/N)

Y

> >    f. Time Limited (Y/N)

N

It's hard to imagine how this (heart of Votorola) could be summarized
in data-like fields.  But maybe the primary purpose of the data is
cross-project comparison, which is something different.  In that case,
we probably need to see some actual comparisons.  Then we could ask
how to improve on them.  Probably we (data schemers) would have to
mine the various textual descriptions, looking for the possibility of
interesting patterns to show in the comparative results.  This
dovetails with the issue of schema/survey changing as a process of
optimizing the inputs to produce what's of interest in the outputs.
Probably it comes down to trial and error.

Comparison is a critical process fraught with tension.  This might
present a problem; the tension has to be absorbed somewhere.  Several
years ago, I proposed something similar to the Designer Lounge for
OpenKollab.  Some of the tension was absorbed by entering data as
facts backed by references.  The bulk was absorbed, however, by
allowing users to design and construct their own comparative tables
(any number were allowed) and to freely choose which they would like
to view.  It was prototyped in a semantic wiki, which allows for this
kind of thing.  But there was insufficient interest in OpenKollab and
I never developed the idea further.

Mike

> On Tue, Apr 2, 2013 at 3:20 PM, Michael Allan <mike at zelea.com> wrote:
> 
> > Hi Mark,
> >
> > Thanks for sharing the draft survey.  For anyone who has trouble with
> > the scrubbed HTML attachment, I've pasted a text version below.
> >
> > One suggestion I have is to add to each survey question an explanation
> > of the information sought.  Just a short explanation, little more than
> > a tooltip.
> >
> > Another suggestion is to allow for on-fly changes to the survey
> > design.  Probably you already thought of this.  Basically it means
> > allowing for the addition of new survey questions.  Maybe also
> > indicating in the views that are compiled from the results (tables and
> > what not) the questions that were left unanswered.  Then new questions
> > would advertise their presence and the answers would eventually
> > trickle in, updating the views.  The aim ofc is to allow the design to
> > adapt instead of being set up-front.
> >
> > Please CC Mark for replies, as he's not subscribed.  Again, the text
> > is below.
> >
> > Mike
> >
> >
> > DemocracyLab Project Portfolio Onboarding Survey
> > ------------------------------------------------
> >
> > I. Project Basics
> >
> >    a. Purpose and Summary of App (Text)
> >
> >    b. Functional Status
> >
> >       i. Active Community (Y/N, Link)
> >
> >       ii. Beta Demo (Y/N, Link)
> >
> >       iii. Development Timeline/Priorities (Text)
> >
> >    c. Documentation of Engagement Results (Y/N, Link)
> >
> > II. Identity
> >
> >    a. Identity Description (Y/N, Text)
> >
> >    b. Login Mechanisms
> >
> >       i. Email/Username and Password (Y/N)
> >
> >       ii. OAuth Login (Y/N)
> >
> >          1. Facebook
> >
> >          2. Google
> >
> >          3. Twitter
> >
> >          4. LinkedIn
> >
> >          5. OpenID (is this OAuth or something different?)
> >
> >    c. Demographic Information
> >
> >       i. Demographic Info Required (Y/N)
> >
> >       ii. Demographic Info Optional (Y/N)
> >
> >       iii. Description of Uses of Demographic Info (Text)
> >
> >    d. Public Persona
> >
> >       i. User Profile (Y/N)
> >
> >       ii. Anonymous (Y/N)
> >
> >       iii. Pseudonames (Y/N)
> >
> >       iv. Real Names (Y/N)
> >
> >       v. Authenticated Identity (Y/N)
> >
> >    e. Reputation Systems
> >
> >       i. Enabled (Y/N)
> >
> >       ii. Description of Uses of Reputation Systems (Text)
> >
> > III. Community
> >
> >    a. Community Description (Y/N, Text)
> >
> >    b. Open Communities (Y/N)
> >
> >    c. Restricted Communities (Y/N)
> >
> >       i. Membership approved by moderator (Y/N)
> >
> >       ii. Membership list preloaded (Y/N)
> >
> > IV. Communication
> >
> >    a. Communication Description (Y/N, Text)
> >
> >    b. Intra-site Communications
> >
> >       i. Forums
> >
> >          1. Commenting System (Y/N)
> >
> >          2. Threaded Discussions (Y/N)
> >
> >          3. Comment Rating System (Y/N)
> >
> >          4. Comment Tagging System (Y/N)
> >
> >          5. Comment Filtering System (Y/N
> >
> >       ii. Messaging
> >
> >          1. Private messages to other users (Y/N)
> >
> >          2. Private messages to groups (Y/N)
> >
> >    c. External Communications
> >
> >       i. Mailing List (Y/N)
> >
> >       ii. Integration with Social Media (Y/N)
> >
> >       iii. SMS (Y/N)
> >
> > V. Issue Framing and Exploration
> >
> >    a. Issue Framing Description (Y/N, Text)
> >
> >    b. Moderator Controlled (Y/N)
> >
> >    c. Community Generated (Y/N)
> >
> >       i. Vetting Process (Y/N)
> >
> >       ii. Collaborative Drafting Mechanism (Y/N)
> >
> > VI. Dialogue and Deliberation
> >
> >    a. Dialogue and Deliberation Description (Text)
> >
> >    b. Survey Capabilities (Y/N)
> >
> >    c. Data Representation (Y/N)
> >
> >    d. Consensus Mechanisms (Y/N)
> >
> >    e. Conflict Mapping Mechanisms (Y/N)
> >
> >    f. Time Limited (Y/N)
> >
> > VII. Decision Making
> >
> >    a. Decision Making Description (Y/N, Text)
> >
> >    b. Voting Capabilities (Y/N)
> >
> >       i. Iterative Voting (Y/N)
> >
> >       ii. Delegated Voting (Y/N)
> >
> >       iii. Time Limited (Y/N)
> >
> >    c. Adoption by Authority (Y/N)
> >
> >       i. Binding Decision Based on Online Outcome (Y/N)
> >
> >       ii. Authority Agrees to Consider Online Outcomes (Y/N)
> >
> >       iii. Online Process Disconnected from Real-world Authority (Y/N)
> >
> > VIII. Collaborative Action
> >
> >    a. Collaborative Action Description (Y/N, Text)
> >
> >    b. Project Management (Y/N)
> >
> >    c. Asynchronous Collaboration (Y/N)
> >
> >       i. Volunteer Pledges (Y/N)
> >
> >       ii. Resource Pledges (Y/N)
> >
> >    d. Synchronous Events (Y/N)
> >
> > IX. Technology Architecture
> >
> >    a. Technology Architecture Description (Text)
> >
> >    b. Software License
> >
> >       i. Open Source (Y/N)
> >
> >          1. License (Link)
> >
> >          2. Source Code (Link)
> >
> >       ii. API (Y/N)
> >
> >    c. Details of Technology Utilized (Text)