User:Sj/coralline

(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 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.

One step towards resolution

A thought experiment

A group of friends, Stu, 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

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.

Recipients who read all of these lists have to compile their own filtering options, and have a limited number of simple choices between receiving and potentially reading all messages, filtering away messages by list until they have time to review (perhaps every week or month, perhaps never), or adding personal filters by keyword. There is no

By remedying this, readers can create their own reports without subscribing to all lists and having mail from all lists pushed to them. For instance, they can:

• isolate a chunk of messages across all lists by query, even after the fact

  messages sent by Tomi to any list during a given date range,

  all messages that were related to both 'server-devel' and 'testing',

• apply this sort of logic to trac updates and patch logs

A coralline system

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

• Define messages in terms of the type of service/site they come from (email, trac, wiki edits, &c), 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.

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
• Handle replies effectively : figure out how likely it is that the originator of a message

footnotes

[1] see related thoughts here.