Following on from John K.'s post and some others, I think it is about time that the community took a hard look at some technology from the dawn of the Web, Hurwitz and Mallery's Open Meeting which they ran for Vice President Al Gore in 1994:
As with many technologies (e.g. threshold cryptography), these ideas came before the audience was ready to absorb them. A similar effect was seen in early film. Only after the basic vocabulary of motion picture signs such as establishing shots was understood, could film progress to more complex narratives. The reason Facebook, a very late entrant in the social media wars could win them (for a time at least) was that the audience had progressed to the point where it could consume the technology.
I have seen groups trying to use git and I really wish they would stop. Using git to run a WG provides a small amount of tool support for issues tracking which is useful. But the tool is designed to do a very different job and has its own bizarre vocabulary. Telling people to enter comments as 'Pull Requests' causes most people's mental gears to grind. The result is WGs whose activities are unhappily split between a Web site and a mailing list with no cohesion between the two. My conclusion is that for this approach to work, there has to be a purpose written tool that absorbs the lessons from the github experience and provides a means of following the WG from the mailing list as well. (Which is how the open meeting worked.)
What Mallery and Hurwitz developed was a discussion forum in which comments were organized according to a constrained vocabulary of moves that provided a set of lightweight semantics allowing topics to be efficiently navigated.
Facebook's reaction emoticons provide a similar capability except that they are replacements for comments rather than labels for comments. Also, since the objective of Facebook is to maximize engagement, only positive reactions are permitted. It is not possible to disagree (except by posting haha to laugh in their faces). What we need most for our work is constructive criticism. The type of comments that get us to the next level.
I still have about a month worth of effort on the first phase of the Mesh. The second phase will include an online comment forum allowing people to comment on the Mesh specifications. For this particular purpose, the comment forums will of course be open and unencrypted. But part of the point here is to provide a demonstration of the Mesh technology which allows the discussion to be end-to-end encrypted. So a group of lawyers working on a case could upload the case files to a cloud service and comment on them secure in the knowledge that the cloud service provider cannot read either the documents or the comments. Accessing end-to-end encrypted social media will of course require a specialist client, the non encrypted version can be presented through a Web browser interface in the same way that Facebook, Twitter, etc. are commonly accessed.
Different types of discussion will require different sets of lightweight semantics. For example, a forum serving a replica prop building community (e.g. dalek building) might have semantics such as 'original', 'plans', 'techniques', etc. Someone who is going through the source video capturing images might tag them 'original', someone who has converted that material to plans might tag their images, plans. etc. etc.
So what is the difference between this approach and a hashtag?
There are two major differences. The first is that since hashtags come from an infinite vocabulary, there is inevitable variation in use. Forcing people to pick from a small number of tags makes those tags more useful as search terms.
The second difference is process. consider a strawman IETF forum.
A forum consists of a set of documents. Each document has a status (active, inactive, published). A pre-WG activity has a statement of scope. A WG activity has a charter. There are also drafts, RFCs etc.
It should be possible to scan through a document and annotate individual paragraphs with comments tagged with lightweight semantics such as:
agree
disagree
nit [typographic issues, spelling etc.]
vocabulary [use/choice of defined terms]
requirement
use-case
interop
The open meeting vocabulary was limited to six moves. It is possible that we could make use of a slightly larger vocabulary. But it is probably best to start out constrained and add slowly.
The process part comes in when an editor is creating a new version of the document. We might assign an editor a separate set of moves:
accept
reject
assign-issue
So if I am editing a document and someone has given me a list of typos, I just go through and clear them. But some comments might well require more discussion. And we can write rules that identify those comments.
Anyway, that is what I plan to build for the Mesh. If other IETFers wish to apply the same technology, I am always open to collaborators. At this point, I have the majority of the components that I need to build this tool. In particular I have the document preparation tool that accepts either markdown or Word as either an input or an output.
