[MG] Minimal start plan - inter-community network

[Michael Allan]

I have a design and plan to propose.  Very roughly:

DESIGN
------

Four new maps for crossforum theatre: [1]

   i. Communities

  ii. People

 iii. Topics

  iv. Polls

The structure is the same for each map.  The map consists of three
main visual components, from top to bottom:

  (d) Detailed view of selected item.

  (g) Graph of all items.

  (t) Table of all items.

(t) The table is the main component.  It lists each item in a paged
viewport (page up/down to see all).  For example, the table in the
community map will normally list all known communities.  The rows may
be sorted according to any columnar value.  Clicking on the 'size'
column in the community table, for example, will sort the rows by the
number of community members (i.e. subscribers to mailing list, or
whatever).  Clicking again reverses the order.

(g) The graph shows all items (x axis) and plots the value of the
currently sorted column (y axis).  For example, you might see a bar
graph of communities from the largest (left) to the smallest (right).
Items in the graph are highlighted by events in the feed, of
course. [2]

(d) The detailed view shows further details of the currently selected
item.  It includes links to other maps and views.

The scoping of any map may be resticted to a single item from one of
the other maps.  For example, you may restrict the community map to
show only the communities of a particular person, topic or poll.  And
so on for all combinations of the four maps.

By itself, this design does not meet all of the requirements [3].  But
I think we can meet them by adding sub-views, mini-tools and other
details to the basic design.  For example, to support lateral
extension (M.1-3) we might add a 'crossforum membership' column in the
community table that shows how many of your collaborators are members
of each community [4].  Vitality and vital rank (F.iii.c, d) can be
projected in a heads-up display over the graph component of the
community map - though only for certain views/scopes - and these can
be the views that are linked from the discussion medium (design
problem 4).

PLAN
----

Most of these tasks can be done in parallel:  (t) tech (s) social

    1. (t) Add support for communities (S.1, 2) to the pollwiki.

    2. (s) Decide which topics and issues to seed.  Create the
           necessary community pages.  Plan seeding.

    3. (t) Code the forum harvesters for the key communities in the
           seeding plans (2).  If we have new developers, maybe they
           could coordinate with C on this.

    4. (s) Organize outfit (H).

    5. (t) Code the new maps, beginning with the community map.

    6. (s) Execute seeding plans (2).


What do you think?


NOTES
-----
 [1] http://zelea.com/project/votorola/a/crossforum/theatrePlan.png

 [2] Items in the table are highlighted too, when they are visible in
     the viewport.

 [3] http://metagovernment.org/wiki/User:Michael_Allan/Seeding_an_inter-community_network

 [4] This would depend on the user listing his/her crossforum
     collaborators as a registration property.  You would then see the
     degree of cross-membership only with regard to the people who
     will actually collaborate with you in lateral ventures such as
     delegation, nomination or colonization (maybe voters and
     candidate by default).

     http://metagovernment.org/wiki/Template:Draft

-- 
Michael Allan

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



Originally posted to the mailing list of the Metagovernment Project:
http://metagovernment.org/mailman/listinfo/start_metagovernment.org