TeaTime

MeatballWiki | RecentChanges | Random Page | Indices | Categories

---

TeaTime is a software project focused on extending meatball paradigms to a scale at which community processes break down -- where the group of people using the software is too large for each active participant to have a PersonalRelationship with each other active participant.

Eventually, the aim is to explore the concept of LiquidityOfTrust. Some related ideas are described on WebOfTrust, TrustMetric, WebOfTrustModeration, FunctionalAccessTrustMetric, and there's also an early external [exposition]. The basic idea is to create an accounting system up to the task of recording and communicating the information needed for people to make informed decisions about whom they can trust, and in what ways they can trust them.

In addition to pages on this wiki, there is a ConceptMap [here]; a blog [here]; a dormant wiki [here]; and post about a possible implementation of TeaRoom?s on FriendFeed? [here].

The first project was a wiki which uses BranchedHistory? for its pages instead of the LinearHistory? model used in other wikis; a test wiki is [online] (it's a proof-of-concept, missing some necessary features).

In the aftermath of the first project, it introduced some new ideas for discussion. To be clear, these concepts are not yet implemented, with the exception of BranchedHistory?.

BranchedHistory?

Instead of having a linear history which is a function of time, history can branch -- when a revert is made, it "routes around" the rejected edit. One consequence is that there is an AuthorizedCopy of the page, which can advance in a heavily-edited page, as long as nobody reverts far back in time. An edit can be viewed in two ways -- as a whole page in its own right, and also as a set of changes from its parent page. The underlying implementation in an advanced revision control system makes it easy to apply the changes to another version of the page (most of the time).

PendingEdit?s

In addition to the normal two states for edits (accepted and rejected/reverted), there's a third state, "pending". A pending edit isn't merged into the page, nor is it scheduled for deletion; instead, it's kept indefinitely.

TeaRoom?s

These are mini-wikis, complete with RecentChanges, reversion, peer review, etc., and TeaRoom?s of their own. UserIDs? are shared between the various TeaRooms?, as is the underlying branched page database (each TeaRoom? has its own view about which branch is current). TeaRoom?s are hierarchical, like a file system -- all TeaRoom?s on the wiki depend, directly or indirectly, on the "root" TeaRoom?. It's easy to move versions of a page between TeaRoom?s. The proof-of-concept wiki has a [page] discussing implementation of the TeaRoom?.

WeightedConsensusVoting

A flexible voting procedure. There's a list of who can vote, and the maximum weight they may use in their vote; and people can vote as many times as they like, each vote overriding their previoius vote. The VotingPower? page is edited like any other page, and goes into effect after a ratification period has elapsed (similar to file replacement). Used properly, people use small weights (e.g., voting with zero weight says that anyone on the list can override you) -- use only as much "force" as you think is needed to work around excess noise generated by people who don't yet fully understand the consensus process.

WikiPublication?

A procedure by which a wiki which uses a restrictive copyright license (e.g., Meatball) can arrange for more widespread distribution of its polished documents. The idea is that each contributing individual grants a copyright license for publication to the community, through the normal community consensus process. As the community nears an agreement that a particular work is nearing publication quality, a proposal is made to publish the collaborative work. The terms of the publication could be very limited, or could be as broad as granting a GPL or CC license to the work. The only right that is given away up-front is to the community process -- individual contributors agree to be bound by a community consensus, specifically including the case where they remained silent during the consensus process.

These concepts facilitate:

RevisionWarTruce?

by marking a controversial edit as "pending", neither side surrenders. Instead, the conflict is frozen, giving as much time as is desired for discussion while the edit is kept in limbo.

MassRevert?

since the whole wiki is represented as a single commit, it's possible to revert the whole wiki to a prior state (many edits ago) by resetting the branch pointer. The only changes which can't be mass-reverted in this way are votes and ratification of voting power.

CitizenArrest

this procedure is de-fanged. With TeaRoom?s and MassRevert?, it's possible to put a whole collection of unwanted edits in a place of their own, reducing their prominence without destroying anything, making it not as important to use HardBans. The WeightedConsensusVoting process is used for banning users, and it is, I think, a more stable process than the proposed CitizenArrest procedure.

ForestFire defense

TeaRooms? offer a neat solution to the proven defense to ForestFires of moving stuff on to a single page -- instead of moving them on to a page, simply move them to the ForestFire TeaRoom?. That way, nothing is permanently lost (it's just as easy to relink them back to where they came from). It's even possible to have a friendly ForestFire, if the people having the conflict voluntarily confine it to the agreed TeaRoom?.

HijackingRecentChanges

a particularly lively discussion that threatens to overwhelm peer reviewers can be put into a separate TeaRoom?. In this way, the people involved in the discussion wouldn't have to worry about touching or creating lots of pages, and the peers who aren't interested in the details could wait until the discussion has been refactored into DocumentMode. When this happens, the completed document could be "pushed up" into the general-interest TeaRoom? for more widespread peer review.

FAQ

• Who's invited?

Anyone who who wants to help, and with whom working is pleasurable.

• What is the source of the name 'TeaTime'.

The name TeaTime originates from the departmental tea time hosted by various math departments; the ones I'm most familiar with are those at Princeton, Berkeley, and Warwick. It's unusual in that it mixes socialization with rigorous work in a way that people seem to enjoy -- I was reminded of how much it's missed by my college and grad-school colleague and roommate, who started a LinkedIn? group in an attempt to re-create the atmosphere. I like the name because it's unpretentious and low-key, which serves to DefendAgainstPassion.

• I am groping somewhat to condense what the purpose of TeaTime is, which seems to be Liquidity of Trust. Or is it? I am wondering if the broader purpose in community enablement or something along those lines.

I see community enablement and liquidity of trust as intertwined -- you could say that liquidity of trust is ultimately about enablement of community for the global village. In any case, I want to focus on the local aspects first.

• I like the idea of this Liquidity of Trust which might prove useful in this global world of so many faces it's hard to keep up at a personal level. Therefore enabling connection through your connections can be powerful. Lijit does something vaguely along these lines as a search engine. How do you intend to connect communities together in order to transfer such trust? I have concerns of Liquidity of Trust which relates to the way it will need to depend on other person perception. In some ways it could become a kind of popularity measure instead of a measure of trustworthiness or capability. I have seen such in some places before. Such issues as discrimination may come into play. I am not trying to dampen this merely flagging the real issues trust networks often have.

These are important concerns. The idea is to assemble a community to address these issues -- I have only the barest sketch of a solution.

• I am trying to relate this with ExtremeOpenBusiness and TheThing?. Is it intended that TeaTime is a medium to conduct OpenBusiness and TeaTime is an online enactment of TheThing??

Yes -- TeaTime could be seen as TheThing? v2.0. I still like the idea of having a physical meeting place, to complement the online activities.

• How do you see the power structure going? The broader philosophy?

I see it as a hierarchical/anarchic mix, along the lines of Groklaw, Linux, Meatball, the sadly defunct [Chaordic Commons], or the design for The Thing. The key is to tease apart authority and power, allowing effective decision-making without enabling abuses.

• Do you want people involved at this stage? I will ask Fridemar what he thinks, it looks promising to me.

Yes!

Discussion

You might consider to integrate ConceptMaps to master the ThreadMess problem, even to outsource threads completely to Cmaps... and concentrate on wikifying Cmaps. -- FridemarPache

What I really meant was a BranchMess?, where the different branches get too disorganized to contemplate; in any case, ConceptMaps seem like a valuable tool. What I'm currently contemplating is that the viewer should be able to choose his or her own visualization solution, and that it makes a lot of sense for the server to simply present the raw data, and to have the summarization and visualization be done client-side. The data should be in machine- and human- readable format, so for a small or inactive wiki just reading the raw data would be feasible. I've written more on the [TeaTime wiki page], while Meatball was down, but it's a little disorganized and scattered. -- NathanielThurston

Nathaniel...

Your statement that... ...it makes a lot of sense for the server to simply present the raw data, and to have the summarization and visualization be done client-side... resonates with some of the (AjAx?) TiddlyWiki concepts I've been working during the past couple of years. Combined with meta-data (and MicroContent?) techniques, I've become quite committed to pushing the envelop I find constraining most of the data processing systems I encounter, out a bit further.

In the long term, I think it inevitable that Individuals will take custody of their own data, rather than relying on data stores owned and managed by Corporate or Goverment third parties with conflicting vested interests. I expect the first application systems that will move in this direction will be the Health and Medical applications, if only because it is increasingly evident that Electronic Heath Records combined with Expert Systems technologies, can outperform the traditional medical practitioner who relies merely on paper, personal experience and mental faculties. I even expect this trend to accelerate as the costs of "traditional" approach continue to escalate and financial resources continue to become ever more constrained. If medical records follow this path, the switch to "electronic" financial records and assets will also accelerate. Obviously, I believe the next couple of decades are going to be quite fascinating to watch.

I certainly agree with you that a "BranchMess?" could develop quite easily, but then managing that kind of complexity is precisely why once should strive to automate the process.

I'm not at all sure that these comments will appear to be anything other than a bit of a "ramble", but it seemed to me that I should at least offer a bit of encouragement to you in your pursuit of TeaTme?.

-- HansWobbe

Hans, thanks for the encouragement.

Regarding custody of data, my speculation is that this will wind up being a community effort rather than an individual one, with a small and technically-competent group within the community taking responsibility for security, system maintenance, and keeping current with technology. I also imagine that the switch will take place in just a year or two, once there is a technology platform with all of the right properties (easy-to-use, attractive, ultra-compatible, and free software all seem necessary).

I'm in the throes of throwing together a basic implementation, based on the UseMod wiki. I'm looking for a place to host it; the main requirement is to have a public git repository which can be used from the perl CGI script.

-- NathanielThurston

Nathaniel...

I suspect that the issue of "individual"" versus "community" is not material, especially if one allows for a very small group. The distinction I was trying to make is that the current "large" corporate and government repositories are not likely to be the ultimate repositories of anything other than one (of many) copies of the "authoritative" data. There are many independent forces actively pushing things in this direction, but that is unlikely to be appropriate content within this page. I, for one, do not want to trust the current custodians of data about me. They make far too many mistakes and take far too many liberties with it, for my comfort. But then, having worked for one of the largest banks in the world, I learned just how important it is to check each and every one of the transactions they process against my account(s)! I'll add a smilie :-) because I know most people simply don't bother and simply think that I'm either strange or paranoid.

I've been watching a couple of wiki-git projects for the past few months (especially the OddMuse based effort) and I do get the impression that it's sufficiently promising to attract quite a bit more attention. Good luck with your endeavors!

-- HansWobbe

I'm thinking about a 'Revert' button to use for de-spamming for the TeaTime wiki, and I was intrigued by Radomir's comment about its non-advisability. The way I imagine it working:

1. It would only be available some of the time.
2. If your user id has substantially more "weight" than the combined "weight" of all of the user ids in the branch in question, then two buttons are presented: "mark as link spam" and "mark as vandalism"
   1. "weight" = total # of edits by your user id which are parents of the edit branch in question.
3. You can do manual reversions regardless of weight; it's just a convenience.
4. Each reader can choose his or her criteria for which reversions to accept, which to review, and which to reject.

Would such a scheme be an improvement?

-- NathanielThurston

Nathaniel, yes, it is a pleasure to see how your scheme can help to reduce Spam and Vandalism by a TechnologySolution. To fire up the motivation of Wikizens to actually use these technological gems, I suggest to give vested/weighted users the opportunity to incorporate their free Google:PaypalFrontstore on their WikiHomepage (perhaps even additionally on dedicated SharedOpenbusinessWikipages?). The social Mega-community http://MySpace.com already offers such widgets on profile-pages of their members. Benefit: WikiNomics aware and practising wikizens will defend their Wiki with much more commitment, then casual/part-time/hobby wikizens. -- FridemarPache

 PS.: There is even a Wiki:GoogleStorefront lurking in the grass.

Fridemar, this would certainly be an acid test of TeaTime, as it seems to me that the front store would be a prime target for vandals, trolls, and thieves (modify the storefront to point it elsewhere...). I'm not sure I like the notion of classifying who's vested and who's not; what's the harm in allowing anyone to have a storefront? Also, I'd suggest that any payments made be voluntary gifts, after the service has been performed, in the spirit of PredominantlyGiftEconomy (also to ease legal concerns). On balance, I think I like the idea, and I'm contemplating an implementation with DalPay? soon after the public launch of the branched wiki software. -- NathanielThurston

I've been thinking about directions to take the TeaTime implementation project, and the lead I've been following is toward client-side processing of public (and possibly shared) algorithms and data. I'm imagining a kind of "view page" on the wiki, with pointers to the JavaScript code, the trusted members of the community, the categories, etc., so that in effect what you see is determined by a publicly-visible algorithm. It would be up to the individual whether to use static (manually-advanced) or dynamic (automatically-advanced) links.

-- NathanielThurston

With all the extra documentation floating around (especially the cmap), I'm finally getting this concept. I see it as similar to PageClusters, except one clusters page history branches instead of pages. Very intriguing. -- ChrisPurcell

Chris, I'm delighted you're starting to get it. The concept has been taking shape (EditClusters? aka TeaRoom?s are a recent addition). I'm still in the process of teasing out some other concepts, including PendingEdits? and WeightedConsensusVoting. -- NathanielThurston

I've created AuthorizedCopy/AuthorizedView, to distinguish from StableCopy/StableView, as TeaTime is not using the StableCopy authorization mechanism. I like the way a TeaRoom? is providing a way for a small set of authors to collaborate and authorize a set of changes together, before (or possibly instead of) moving them through a more weighty authority process.

Is there ever SilentAgreement in a TeaRoom?, a la StableCopy? Is there a way to customize the approval mechanism? For instance, a small group of authors may decide to collaborate on a long-term subproject; would they be able to have pages they're not interested in (i.e. have no pending edits to) "auto-approve" whenever the main TeaRoom? community approves them? If a small group of authors decided to "fork" the wiki, creating a new TeaRoom? with no intention of remerging back to the main TeaRoom?, could they do so? (I'm thinking aloud here, so this is probably a bit fuzzy.) -- ChrisPurcell

Chris, thanks for AuthorizedCopy/AuthorizedView.

I think I may have chosen poorly with the name "PendingEdits?" -- it's not that the edit starts out "pending", but that it's possible to move an edit to the pending state, as "needing more discussion". The idea is that SilentAgreement in a TeaRoom? is the usual practice, and that the voting procedure is only used on rare occasions. There's no way to customize the approval mechanism, but each TeaRoom? has its own AuthorizedCopy of the VotingPower? page, and so the voting power can be adjusted. Thinking it over, I now realize that it might be wise to have a policy page (subject to AuthorizedCopy) which specifies whether everyone can post edits into the "Yes" state, or just people with voting rights... this gets more complex than I first thought; see below.

A TeaRoom? contains only modified pages, and is backed by implicit links to the parent TeaRoom?, so changes to unmodified pages are automatically seen. TeaRoom?s exist with the assent of the parent TeaRoom?, so the existence of an ongoing fork would be a matter of community policy and/or decision. In the wiki I'm designing for my own use, there will be a number of "disconnected" TeaRoom?s, with TeaRoom?s for various mostly-unrelated projects I'm working on.

Finally, I hope that the "AuthorizedCopy" in the exposition of BranchedHistory? will, in most cases, be "StableCopy". The consensus mechanism is different -- to disagree, you must revert the change (or mark it as pending, or move the change into a child TeaRoom? for discussion), but the intent is that consensus should be present before the edit is accepted. The difference is that it becomes possible to make edits after the agreed edit without upsetting the consensus process. -- NathanielThurston

So what happens if: person A makes an edit; person B likes person A's edit, and makes an unrelated edit on the same page; person C likes person B's edit, but not person A's edit? What if there were many other edits after person A's edit that person C approves of? Do they have to trawl the whole page history and revert every change because they all contain parts they don't approve? -- ChrisPurcell

These are problems with wiki in general, and TeaTime doesn't provide a complete answer. Two possibilities:

1. Accept both edits, and manually reverse person A's edit using copy-and-paste. In this case, person A's undesired edit remains part of the page history.
2. Reject person A's edit, and use a "cherry-pick" to create a new edit in which person B's changes are incorporated into the original version. In the "many edits" case, create a summary edit which combines all of the desired edits, and cherry-pick the summary edit.

Less-contentious alternatives are to make a side TeaRoom? in which A didn't make the original edit, effectively creating an alternate universe in which A didn't speak (softer version of option 2); or to put the change tree into a side TeaRoom? if you're fairly certain that the community will agree with your censorship (softer version of option 1). It's probably best to avoid censorship (option 1) when in doubt -- let person A speak for himself, unless person A's behavior is out of line... especially since B (and the others) have given their implied agreement to person A's changes.

Another solution is to mark the disputed edit as "pending" (would "undecided" be a better name?), and start a meta-discussion explaining your point of view and why the community might agree with your opinion that the edit should be reversed. In this way, you can say that you personally disagree with the edit without expressing an opinion about what the community will wind up deciding. How often does this sort of thing come up? -- NathanielThurston

About the "permission to speak" questions: "who is permitted to post a pending edit?" and "who is permitted to move an edit from pending to accepted?", Chris started a train of thought: In the long run, I imagine having a MinimumSalience? setting for a TeaRoom? or a page in a TeaRoom?, so that only edits which were prepared in a subroom and had been "voted salient" to a specified threshold (using the WeightedConsensusVoting procedure) were granted entry -- and if a TeaTime wiki grew to the size of Wikipedia, this may be appropriate. However, I'm worried about creating yet another flawed TrustMetric, and I think we can safely ignore this possibility when thinking about coding the next iteration of implementation. -- NathanielThurston

Nathaniel, your CherryPicking? alternative minimizes the bureaucratical overhead, especially if we work on super-lean wiki-pages, aka cmaps. This reminds me faintly of ViewPoint. -- FridemarPache PS.: By the way, a modern wiki should make the cmap protocol links clickable and imbeddable in bracket notation :-)

BiLinks <->

• [CmappersHtml:TeaTime]
• cmap://cmaps.cmappers.net/rid=1243511575068_1139443639_1039/TeaTime.cmap if you have installed Cmap Tools, copy-paste this into your browser address field and you can edit immediately

---

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: