User:Sj/coralline: Difference between revisions

From OLPC
Jump to navigation Jump to search
(..)
No edit summary
Line 1: Line 1:
(link from [[user:sj/internal]])
(link from [[user:sj/internal]])


It is common for a shared thought to reach the wrong audience. Either too few people, or too many, or simply the right people in the wrong context. (for instance, reaching a close friend with a piece of important information conveyed via a high-traffic list may result in its being filtered for much later review, rather than heard/read immediately).
It is common for a shared thought to reach the wrong audience because the tools by which senders and receivers cooperate to exchange messages are crudely discrete. This results in both sins of omission:


: ''messages fail to reach people who would like to read them''
It is also common for it to be difficult to set up preferences for receiving new ideas. Either because the process of choosing a subset of 100 [[mailing lists]] is difficult, or because the details of updating that many distinct profiels or away-states is hard, or because there are actually 15 different types of services, groups, and tools all sending out messages.


and of and of commission:
== One step towards resolution ==


: ''messages reach people who would prefer not to receive them''.
=== A thought experiment ===


It is also common to regard the audience of a message as something fixed when the message is first sent or published. This attitude belies the ways that messages are used in practice.
A group of friends, Sari, Tomi, and Umaru, each subscribe to and send mail to a subset of mailing lists:
: devel, sugar-devel, server-devel; localization, testing, accessibility; grassroots, olpc-open, support-gang; peru, nigeria, and india.


== A ''coralline'' system ==
Their decisions about which lists to send email to are guided in part by practicality (not wanting to spam recipients who get multiple copies for each list), in part by technical limitations (mailman discourages sending to more than 2 or 3 lists and automatically holds messages for moderation otherwise), and in part by haste - sending to the first few lists that seem appropriate.


# Let Flows be transcoding Message queues.
S/T/U want to be able to tag messages for relevance to many or all of these lists; to create new lists (such as the haiti list) on the fly by defining a new interesting tag [rather than debating whether or not to make a new list, and going through related overhead]; and to reply to messages with similar simplicity (without worrying about whether to reply to all or to the sender alone or to a single list... and potentially adding a new relevant list to the thread).
# Let Messages evince Features.

# Let each Message's Features be initialized by a Classifier defined on the Flow from which the Message became known.
Rather than continuing to subscribe to all lists and apply their own filters after the fact to make sense of the resulting deluge of messages, they would like to define filters that will sort out what mail comes to them -- and they want more than the 9 binary options of subscribe/dont-subscribe for each of these entire lists.
# Let Audiences

## search for and browse Messages by Features,

## create synthetic Flows by Comprehension, and
They want a system through which they can create their own reports without subscribing to all lists and having mail from all lists pushed to them. For instance, they want to:
## create new bindings (e.g. of features to a message, of a classifier to a flow) at will or subject to notification, confirmation, or capability as appropriate.
* isolate a chunk of messages across all lists by query, even after the fact, such as:
# Let typical Flows consist of mailboxes and feeds. (Fancier interfaces, e.g. to bug trackers, review systems, etc. can come later.)
*: messages sent by Tomi to any list during a given date range,
# Let every Flow carry with it an optional opposite reply Flow.
*: all messages that were related to both 'server-devel' and 'testing',
* define a name for a new topic, perhaps come up with an appropriate name after writing the message, and use that as the hook that ties together that and related future discussions (without any more "list-structure" than necessary).

They also want to be able to use a similar system to track updates to their favorite feed-generating tools and services, such as trac and git. Among other things, they would like to
* map the above sort of tagging and logic to trac updates and patch logs
* include posts from selected blogs and other publishing sites -- which will often come with their own named categories
* reply semi-transparently to any of the above sorts of messages
* modify the topics associated with a message or its kin after it is first published
* generate a view of existing messages, and share that view with others (have a permanent link to what may be a dynamic view)

Finally, they would like to know more clearly who is following a given conversation. So, some combination of online viewers and commenters, and recipients of mail... though this is of secondary interest.




Revision as of 02:29, 19 March 2009

(link from user:sj/internal)

It is common for a shared thought to reach the wrong audience because the tools by which senders and receivers cooperate to exchange messages are crudely discrete. This results in both sins of omission:

messages fail to reach people who would like to read them

and of and of commission:

messages reach people who would prefer not to receive them.

It is also common to regard the audience of a message as something fixed when the message is first sent or published. This attitude belies the ways that messages are used in practice.

A coralline system

  1. Let Flows be transcoding Message queues.
  2. Let Messages evince Features.
  3. Let each Message's Features be initialized by a Classifier defined on the Flow from which the Message became known.
  4. Let Audiences
    1. search for and browse Messages by Features,
    2. create synthetic Flows by Comprehension, and
    3. create new bindings (e.g. of features to a message, of a classifier to a flow) at will or subject to notification, confirmation, or capability as appropriate.
  5. Let typical Flows consist of mailboxes and feeds. (Fancier interfaces, e.g. to bug trackers, review systems, etc. can come later.)
  6. Let every Flow carry with it an optional opposite reply Flow.


A coralline system

Here is an coral-like broadcasting system in line with principles that capture and preserve the intent of the creator[1]:

  • Define messages in terms of topical tags defining their subject, origin, &c
  • Define the type of service/site a message comes from (email, trac, wiki edits, &c), along with their originator and a set of tags describing their content / context / originating intent.
  • Define recipient profiles (similar to mailing list user preferences) according to what tags and tag-sets a recipient wants to find out about, and how aggressively updates are desired. (for instance : all topics related to XMPP and Sugar should be flagged in weekly summary-format for online review; all topics from or to Zdenek related to languages or dictionaries should be sent in their entirety without delay.)
  • Automatically produce tags for each current named mailing list.
    automatically produce from-foo tags for senders? an advantage here would be defining the equivalence class of addresses which belong to a single sender and unifying their tags.
  • Provide interfaces for
    • defining memberships and receipt/email-preferences for individuals
    • setting up a tag tree, indicating where a specific tag implies a more general tag as well
      • and the related detailed authority file associating tags with one another; recipients could indicate narrow vs. broad interest in a given tag
    • reviewing 'replies' that haven't been successfully passed on to the originator in question : because there was not yet a way provided to post pingbacks, for instance
    • defining a new source of input, scripts to extract messages and their metadata, and the proper way to send back notice of any replies

There are many ways in which this system can be recursive for maintenance : generating internal messages about events noticed that bear acting upon (including dealing with unsent replies, system bug and abuse reports, &c).


Some interesting features

  • Support drawing in tags from external sources. Define a few privileged prefixes. For instance x-TAG could indicate a tag that came from some outside repository -- two different messages with that tag could have been tagged in different contexts. So x-library could apply to both book libraries, code libraries, and other ideas or terms referred to on some site with that name.
  • Extract entries by polling and other mechanisms from sources that are not explicitly set up to produce tagged messages.
  • Handle replies effectively : figure out how likely it is that the originator of a message wants a reply, and the level of detail that will be interesting : both from the level of significance of the reply and how normal anonymous or bot-generated replies are in the source context.
  • add yours here...



footnotes

[1] see related thoughts here.

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=User:Sj/coralline&oldid=199569"