changed:
-
.. contents::

=======
purpose
=======

provide online services supporting coordination of grass-roots,
activity-based community groups across group activities at various scopes,
from local to various levels of regional to global.

problem
=======
conventional online services used by grass-roots groups - eg, mailing
lists, calendars, wikis, blogs - generally fail to address the needs of the
communities when it comes to coordinating regional scaling - accommodating
coordination of the groups' activities across regional collections of local
groups.

grass-roots communities (eg, clubs, leagues, etc [#]_) increasingly use
online facilities to coordinate their activities.  many grass-roots
communities engage in activities that include not only local gatherings,
but also less frequent, larger-scale gatherings which span regions -
festivals, national conclaves, big-time workshops, regional jams, league
play-offs, concert and book tours, and so on.  there often are multiple
layers of scopes, ranging from local group's frequent gatherings to less
frequent regional conclaves to national and international mega-meetings,
for instance.

conventional online resources provide meagerly or not at all for
cooperation across distinct local groups involved in the same activities.
addressing this issue well would enable greater coordination and
organization across the range of the communities' activities.  this would
be valuable to large numbers of people (myself included).

solution
========
[this was written before i had any experience with google's "applications
for your domain", which at least provide one scope layering.  seeing
continuing emerging integration of various google services services, i
think there's a lot of potential usefulness in extending and elaborating
this layering.  some of the ideas below may be unnecessary in the context
of a corporation like google, but even alternative funding models wouldn't
mitigate the activity regulating utility of something like fees for
region-spanning usage.]

my goal is to develop a model which directly addresses cooperation across
various scales of regional scopes, as well as within local groups, and
develop and provide services which support cohesive coordination of
activities across various scopes.  i mean to do so in a way that
distributes cost of the services to those producing and seeking wider
involvement, in exchange for access to exactly the audience for those
activities.

value proposition
-----------------
the value proposition here is matchmaking of organized peers - bringing
together those looking for activities to join and those producing
activities to be joined.  we would support conduct of local community
activities by providing online coordination facilities.  the local
communities would also be reachable by those producing larger community
events, who would have an avenue for reliably reaching those interested in
the larger events.

to support that value, the costs for using the system, as a simple
participant, would be scaled to be zero for minimal participation -
enrollment and active participation in one local event - and increase as
the scope of usage spans localities.

some central charges in the system would be for notification outreach that
extends across localities, in proportion to the size of the target
audience.  this funding helps assure the quality of the outreach, providing
disincentive for those looking to abuse the channels (spammers), and
increasing the attractiveness of those channels' signal quality for event
producers and participants seeking well-focused venues.

charges for local sites would depend on the services being used.  purely
local services would just be the cost of hosting services.  services that
extend across more than one ongoing local event will incur some central
charges.

the basic locality package will include a membership roster, a self-service
entry for details about an ongoing local meeting, and discussion forums for
conduct of the local community.

a membership that extends across more than one ongoing local meeting will
incur some nominal fee.

notifications that extend across members of more than one local meeting
will incur a fee, proportional to the audience scope.

the global community will support a site which presents a comprehensive view
of the community, for discovery of the community events for members and
non-members alike.  non-members can find events in order to join in the
activities and perhaps become ongoing members.  people who are already
members can discover events happening outside their localities, for visits
and/or for collaboration.  (this would correspond to contactimprov.net.)

in this way, local communities will benefit from coordination support for
their local activities, discovery of the activities in other localities for
visits and coordination, and access to notifications for larger activities.
regional event producers will enjoy essentially the same facilities, and,
also, will have access to exactly the audience for their activities for
notification and enlistment.

==========
precedents
==========
i have many personal itches that make me well motivated to pursue these
goals.  one clear example is in my involvement in organization of contact
improvisation activities:

- dc contact improv community - i tend the jam, mailing list, and web pages for
  one of the local jams
  (http://myriadicity.net/Sundry/DCContactImprovJams)
- eastcoastjam.com - i tend one of the two yearly jams, the mailing lists,
  and web presence for this extended-region jam (http://eastcoastjam.com)
- contactimprov.net - there is a real need to enhance this under-resourced
  web presence for the international contact improv community
  (http://contactimprov.net)
- contact quarterly - the quarterly has served though much of contact
  improv's history as a hub for the attention of the ci community.  i'm
  connected with efforts to reframe this journal's structure, and should be
  able to credibly offer services to, eg, offload locality contacts
  (http://contactquarterly.com/cq/contactq.html)

this collection of resources embody the kind scope scaling that i'd like to
address in a systematic way.  there are many such real-world examples, but
it's handy to have some actual, personally-connected ones to as reality
checks for designs and as testbeds for incremental development.  (in fact,
i used the local dc contact improv community for one of my two trail
mailing lists, when i was bringing mailman from a prototype to a production
system.  we're still using that mailing list, and it's still on python.org.)

also, i've been instrumental in creating and developing various `tools
supporting community collaboration`_ that have seen substantial use.  in
the process i've developed a sense of the deep potential usefulness of more
interoperable tools with the kind of scope scaling i describe above.

.. _`tools supporting community collaboration`:
   http://myriadicity.net/Sundry/SoftwareDevelopment#community-collaboration-tools

==================
Principle Features
==================

- outreach facilities

  - cascading regions

  - access/privacy

    - audience available to event producers via outreach

    - audience can regulate access to them

      - filters - accept and/or deny by:

        - sender
        - participant-extensible topic trees

      - audience can register complaints against a sender

        - actions depend on traceability, described below

        - complaints percolate to predecessor on access route - local jam
          shepherd, if from a jammer

        - shepherd can close down access to sender, or just raise a complaint

        - in cases of deliberate misconduct, shepherds can escalate
          complaints to host operators

        - lattice system tallies all prohibition actions, enabling lattice
          operators to notice hot-spots, likely miscreant hot-beds

  - projected and actual recipient tallies

    - producers get estimates of how many likely recipients (and cost)
      for their target region/topic, can refine the region/topic to suit
      their budget

    - estimates cost nothing, but repeated requests gradually are satisfied
      less quickly, to avoid denial-of-service attacks

    - some approach ensures that actual costs don't exceed final estimate

      whether it's use of snapshot for actual cost or use up to estimate
      and then confirmation request to exceed, etc.

- participant-based agency

  - self-service accounts

  - community-based latticed regulation:

    - users "administer" their own accounts
    - local shepherd (jam contact, weekly contradance organizer, etc)
      vouches for/regulates access to local membership
    - local shepherds vouch for regional event organizer's authenticity -
      known quantity
    - anyone can raise an objection (complaint) to some misconduct, eg

      - bogus outreach (spam)
      - misuse of forum (abusive, spam)
      - harrassment (aggressive unwanted pursuit of contact)

    - shepherds and regional organizers have recourse to prohibit
      membership

    - every local site has a canonical system host

    - every system host that joins the network must identify to a known
      established host

    - all membership is traceable to member/host sponsor, so spam cabals
      are traceable and prohibitable, ie

      - their sponsors as well as the offending members are traceable and
        can be held accountable

      - and sponsoring hosts can be noticed and prohibited from network
        participation

==============
Implementation
==============

the risks of a project are the areas of uncertainty that pose the greatest
threat to the project's success.  some risks reveal crucial architectural
design and implementation issues, and in some cases - as here - can be
pivotal forcing factors in the designs.  RisksAndCountermeasures elaborates
the specific considerations driving this implementation design, while the
entries here distill and consolidate those entries.  the item header lines
link to the elaborated entries.

`tailoring usability to our purposes and audience`_
  the target audience includes non-technical groups, requiring particular
  care that the purpose of the system always clearly informs the
  functionality, and that the user interfaces are simple without being
  simplistic.

.. _`tailoring usability to our purposes and audience`:
   RisksAndCountermeasures#tailoring-usability-to-our-purposes-and-audience

`scaling coordination`_
  the essential value of coordination grows as the number of participants
  increases.  scalability is necessary both to enable and to accommodate
  that growth potential.  the particular focus on coordination across
  moderately sized localites presents a clear framing for federation of
  resources organized around those localities.

  components in terms of explicit communication protocols and policies, the
  services can be federated across many servers.  the only components which
  incur costs proportional to the regions encompassing many local groups
  would be the components providing the communications "glue" for
  federating authentication, authorization, and audience relevance for
  notifications, and the sites presenting consolidated views of the
  activities across the groups.

.. _`scaling coordination`:
   RisksAndCountermeasures#scaling-coordination

==========================
key component requirements
==========================
[this is so preliminary - much remains to be culled and built upon from the
risk/countermeasures.]

membership
==========

- scalable:

  so single identity can be used at all regional tiers, local to global

  (could an existing, open public service for identification, like
  google accounts, work here?)

  and so authority can be delegated to members to administer and delegate
  authority for their group(s)

  - federatable, so any authorized service provider can provide identity creds
  - accountable, so that the revenue model can be distributed across providers
  - traceable, so that accountability for actions can be maintained, for

    - revenue distribution - which providers are owed how much for what
      portion of notifications fees
    - and mischief - what member, group and providers are responsible for
      inappropriate messages and/or inadequate moderation

aspects of membership may fall into the category of identity management.
there are some interesting, possibly relevant articles at networkworld,
starting with `Seven ID mgmt. project risks and how to avoid them`_ and
leading to a `discovering identity`_ collection of observations on the
identity management projects.

brainstorm thoughts -
  zope's Pluggable Authorization Service should be shapable to these
  concerns.

  could we use existing, open public services for identification and/or
  data storage, like google base/accounts/payments for our purposes?

.. _`Seven ID mgmt. project risks and how to avoid them`:
 http://www.networkworld.com/newsletters/dir/2006/0130id1.html
.. _`discovering identity`: http://blogs.sun.com/identity/

protocols
=========
authentication, authorization, and content communication

policies
========
posting fees, privileges, and moderation, fee distribution, privacy,
qualifying as a franchisee, ...

activities information
======================
- background details
- scheduling
- contacts
- activity log

  - ongoing discussion
  - historic log

    - official details
    - media artifacts

      - personal accounts and communications
      - pictures
      - videos
      - audio

brainstorm thoughts -
  could we get some good mileage on zwiki-as-content-management, perhaps
  just for the near-term implementation?

  what does silva offer here?  and/or in combination w/zwiki?

notifications
=============
- topical categorization
- cascading scope

  - by nested regions
  - by nested topics
  - maybe also with collaborative filtering, ie "subscriptions" to
    other's subscriptions

fee assessment
==============
brainstorm thoughts -
  would we get benefit from hooking up with mailman's email delivery
  facilities?  perhaps by creating virtual lists that have computed
  members?

  collaboration on estimation and distribution of notifications,
  distribution of fees, etc, will depend on reliable authentication of
  (federation) peer systems, and not just authentication of users.

=========
footnotes
=========
.. [#]
   by activity-based communities i mean groups that gather casually to
   play or work together - clubs.  Some examples:

   - participatory arts like folk or contact improv dancing, choir, band, ...
   - sports leagues, martial arts
   - outdoors and wilderness clubs
   - grass-roots civics and political organizations
   - fan clubs and artist-support teams
   - specialized hobbyists/enthusiasts
   - open source developers
   - etc, etc

.. figure:: ribbon_stream.jpg
   :target: ribbon_stream.jpg
   :height: 200
   :width: 500
   :align: center


From unknown Sat Sep 13 12:47:28 -0400 2008
From: 
Date: Sat, 13 Sep 2008 12:47:28 -0400
Subject: OpenPlans
Message-ID: <20080913124728-0400@myriadicity.net>

Hi Ken - thanks for sharing this proposal. Are you familiar with Openplans.org? It seems to satisfy most of the requirements you've outlined here, and is also freely available as open source. http://www.openplans.org
- Nate