Views
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 [1]) 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.
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
- filters - accept and/or deny by:
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. Risks And Countermeasures 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.
- 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.
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?
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
| [1] | by activity-based communities i mean groups that gather casually to play or work together - clubs. Some examples:
|
Open Plans? --Sat, 13 Sep 2008 12:47:28 -0400 reply
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
yet another logo