Position pipes (design sketch)

[Michael Allan]

I have a rough design for position pipes.  As requested by Conseo,
I've posted a sketch below.  Next I plan to:

  1. Update the practice diagrams shown on the home page
  2. Create the necessary category pages and such in the pollwiki,
  3. Create a few test pipes in the wiki
  4. Code pipes into the count engine, difference bridge, etc.
     (this is where most of the work is)

Meantime, please have a look C, and anyone else who's interested.  Let
me know if you foresee problems, or better solutions.  There's still
lots of time to make changes.


Typology
--------

    Position
    --------
        http://zelea.com/w/Category:Position

        Pipe (new category)
        ----

            Category pipe includes the following type, which are not
            yet formalized as sub-categories:

                * Variant pipe - pipe with draft, such as Vu or Vb:
                  http://zelea.com/w/Stuff:Votorola/p/position_space_rationalization

                * Super-component pipes - such as Cs (link above).  I
                  won't code these yet.  Wait till they're needed.

            Category pipe also includes the following formal
            sub-category:

            Component pipe  (new category)
            --------------

                For normative issues (issue type = Category:Norm) a
                component pipe relates to a component of the norm,
                such as a part of a plan or law.  E.g. Vt's candidate:
                http://zelea.com/w/Stuff:Votorola/p/position_space_rationalization

                For power structures (issue type = Category:Executive
                office), a component pipe relates to an office under
                the control of an executive.  E.g. O, P, Q, etc:
                http://zelea.com/w/Stuff:Votorola/p/power_structuring


Form
----
A position pipe is formally a user, but an impersonal one.  It has a
user page with the following wiki properties:

    Title: User:Pipe-1138-ZeleaCom   (example)
    Category: Pipe

Plus the following semantic properties:

    Minder: Frank-FlippityNet        (example)
    Poll: Sys/p/sandbox               "
    User: User:Pipe-1138-ZeleaCom     "

If the category is actually component pipe, then it also has the
following semantic property:

    Content: User:Georgina-BeenaCom  (example)

        If this points to an immediate voter, then it designates the
        currently chosen content of the component.  Otherwise it means
        nothing.

For a normative component (issue norm), the content is the variant
chosen by the wider branch (or tree) for that particular component.
Patch proposals and patches will flow from the chosen variant (wild
allele), through the component pipe (gene), to the downstream
candidate (usually a super-variant), and thence propagate throughout
the branch.  For example (but note that pipes are omitted from this
diagram): http://zelea.com/w/Stuff:Votorola/p/patch_relaying

When the downstream candidate does a difference against the pipe, it
will be a difference against the upstream variant, and vice-versa.

For an office pipe, the content is the nominee for the office as named
by the controlling executive.  E.g. Cq names Cr for R:
http://zelea.com/w/Stuff:Votorola/p/power_structuring#SN

In the latter case, for offices that have multiple appointed officers,
such as committees, there may be multiple "contents".  This is
Conseo's idea.


Creation
--------
  1. Initial pipe minder logs in under dot-form "email address":

       .Pipe-1138-ZeleaCom   (for example)

     With the mailish username extension, that means literal username
     Pipe-1138-ZeleaCom and no actual email address is recorded

  2. He sets his own email address in the user prefs, and "confirms"
     it by replying to the challenge from the wiki.

  3. He sets the necessary properties.

  4. If a vote is needed (usually) he logs into the vote-server as the
     pipe, and casts the vote.


Transfer to new pipe minder
---------------------------
With cooperation of old pipe minder:

  1. Old changes account email for the pipe

  2. Old invites new minder to reset password via Special:UserLogin
     http://www.mediawiki.org/wiki/Manual:Resetting_passwords

  3. New receives temporary password

  4. New sets permanent password

Without cooperation:

  1. New minder creates new pipe, or salvages used one.

  2. Instructs immediate voters to shift votes to new pipe.


Reuse of pipes (salvaging)
--------------
Pipe minder can list all pipes he's minding, including inactive ones
(i.e. those not voting or somehow marked inactive).  He can choose one
of these to reuse instead of creating a new one.  Most users won't
ever mind more than two pipes.

With some delay (e.g. by request) a minder could easily transfer an
unused pipe to another minder.  In case he ends up with too many of
the things.


Change in pipe naming scheme
----------------------------
This design is sensitive to changes in the pipe naming scheme due to
changes in mail configuration on the pollwiki host.  A pipe with
mailish username Pipe-1138-ZeleaCom (for example) has an email address
pipe-1138 at zelea.com, which is to be administered by the pollwiki host
(forwarding to the pipe minder, I guess).  Should the invariant prefix
(pipe-) or domain name (zelea.com) be changed at some point, then
it'll be disruptive.  For each pipe in the pollwiki, the pipe minder
would have to:

  1. Create new pipe (i.e. using new naming scheme)

  2. Vote new pipe to match old

  3. Unvote old pipe

  4. Instruct immediate voters to shift votes to new pipe

-- 
Michael Allan

Toronto, +1 416-699-9528
http://zelea.com/