Wcp Use Cases

The software behind WikiChangeProposal is intended to support all the usecases supported by traditional software for public wiki forums like C2. So it will be backward compatible.

There are a few usecases that are intended to be added in trying to find a practical and convenient resolution to WikiProblems without betraying the spirit of wikis in any fundamental way. The new wiki will be able to cover all cases of free online expression, ranging from blogs all the way to the initial vision of WardCunningham (more or less EgolessWiki).

The usecase described should serve consolidating the following goals/ideals:

Wikis should be open
Wikis should be democratic
Wikis should be fair
Wikis should avoid any politics
Wikis should primarily serve WikiReaders.
Wikis should allow contributors to collaborate effectively.
Wikis should allow motivated individuals and teams to create high quality content on par with traditional forms of publications, similarly to how open source software competes in quality with commercial software.

I don't know of any public wiki software that has the right mechanism to attain all of the above. The counter argument is that the goals above should and could be attained purely through social mechanisms.

Editorial teams

Editorial teams will form spontaneously and democratically in the sense that anybody can form his own team or several teams. A team is just a collection of people who have the right to use their team name in promoting editorial branches (i.e. alternative views of a particular topic).

The initial design is that every team will have an owner - the guy who created the team - and the owner will add or exclude people from the team. There will always be a team "0" that cannot be changed and that includes everybody automatically. If nobody else creates teams and the only team on a wiki is the 0 team, then we have the classical wiki.

open problem: It is very possible that an owner may attract people to work for his "team" and then relations can turn sour, in which case the result is a fairness problem: the team may continue to benefit from the value of the now excluded contributor while pursuing values and points of view that are no longer compatible.
- My initial design is betting that after so many years of wiki experience people know each other well and the teams to be formed will be small enough and close enough for this not to be a really important problem. One possible solution to this problem would be for any team member once inside to be given a one-time option, upon leaving, to close the editorial team.

Editorial branches

Editorial branches are special "versions" of a WikiPage, having the same name as the page they are branched off, and being disambiguated by the name of the team that created them. Editorial branches are intended to be a useful tool on topics where discussion cannot converge for objective or subjective reasons. Then different ViewPoints can be expressed as strongly as possible (without the need to compromise for a NeutralPointOfView) in editorial branches of the team.

For example, take a page such as StaticVsDynamicTyping. There can be an URL (page=StaticVsDynamic & team=static_typing_advocates) and a separate URL (page=StaticVsDynamic & team=dynamic_advocates). This would ensure that both points of view are as clearly and as forcefully expressed, without the never-ending conflict between them to alter the quality of the reading experience. Many people should know by now that every year, at least one huge troll/flame-fest bursts out on various online forums on StaticVsDynamicTyping; occasionally in such wars of arguments somebody on either side posts something insightful and worth reading, but for readers to select such quality content lost in a sea of junk is like searching for a needle in the haystack.

Editorial RecentChanges

Other than page branches (or ViewPoints) teams will be able to edit a collection of recent changes by marking which of them they consider important/insightful or otherwise worthy of the attention of WikiReaders. This I think is an important service to the readers which I currently miss.

You mean something like the moderation done on SlashDot and KuroShin? -- WouterCoene

Yes, something close to moderation, but a little bit better in the sense that moderation (as in moderated newsgroups mailing list or sites) conflicts with the ideas of openness and fairness and also may introduce some political friction. So yes, it will be a filtering but because there are any number of teams producing competing filtered views nobody can complain of lack of fairness. Plus there will be the global recent changes where everything is visible.

The principle involved is that the quality of a forum and of the content produced depends crucially on closing the feedback loop and having the OpenPeerReview? work. Except that now it generally doesn't, as suggested recently by the survey WhoIsActiveOnWiki. The phenomenon was previously discussed as SilenceImpliesFatigue. In order for peer review to work, people on various topics and willing to donate time, and energy have to monitor the global changes. Or this is an exhausting activity. In a normal day, >90% of the changes are not worth the attention of 99.99% of the readers. Deciding which ones are worth attention and which ones aren't is an activity that every reviewer has to do it on its own resulting in duplication and waste of effort. I'd like to be able to trust one or two teams of fair editors so that I can read a summary maybe once a week, without the danger that if somebody has something interesting to say and he can use my feedback or I can use the insight then that connection is made without my having to sift through the tons of chaff that shows up on RecentChanges. It will be like a magazine of what's cool on wiki.

Each editorial team could have their own WikiDigest? or NewsPaper. That wouldn't require any special features from the software, simply create a "WikiDigest?" page and file each team's version under a viewpoint.
In addition, editorial teams could maybe mark the comments they're using in producing their viewpoints. Provided that comments are special (see below), you could fairly easily build an automatic check which determines which comments have never been integrated into a viewpoint. Those comments would then either be crap (spam, insults, swordfighting or off-topic) and in need of pruning, or may need to be integrated into a viewpoint.
Obviously it can be done manually, that's why it's not high on my priority list. Actually, CliffordAdams, who first thought of ViewPoint did such an activity on C2 until some point at which he gave up. My idea was to make it extremely easy and convenient for editors (like a checkbox that marks a change as "interesting"/"insightful" and I thought also of marking something as "junk").
The main problem with any rating system is that it almost always leads to the establishment of some form of an in-crowd, and those are usually no good at allowing minority opinions. If you want to go in this direction I really suggest reading about KuroShin's moderating policies (http://www.google.com/search?&q=site:www.kuro5hin.org+moderation). Some of the discussions on it are pretty insightful. -- WouterCoene
The antidote to the in-crowd forming (it obviously crossed my mind) is that such a team will not be able to hide alternative views from their readers. And any two people (or even one, in which case we have a blog ) can form a new team. I expect there will be a team defending the dynamic typing point of view and another defending static typing, both of those will be "mainstream". Furthermore, say am in-crowd team forms and decides to totally exclude the views of an outsider (obviously RK would be a candidate example, just for the sake of discussion). So most of the readers will not bother to click the link towards the alternative view on say, OperatingSystemsDesign so RK doesn't get as much exposure as the mainstream and in the beginning maybe his opinion will hardly be read by anybody. But still, if his views have any value at all it's impossible not to find a few people paying some attention to his ideas, and those people through "word of mouth", by posting explicit references in other pages, may attract more readers. An underground culture will be formed just like in the mainstream culture. And in the end if RK's vision really produces valuable results, in a fair and democratic system the value will rise to the surface, eventually, but not before it's able to prove itself. The same things that happen in off-line cultures are likely to happen on-line. My motto vis-à-vis wikis is there's nothing new under the sun.
That's a good point. However, consider a situation whereby theory A has been generally accepted by all major editorial teams. Some new people come along who are proponents of theory B. Because none of the teams particularly like theory B, it doesn't get talked about much. Now there's two things that can happen here: the scenario you describe above, whereby everybody behaves like rational beings and the new theory gradually gets accepted, or the proponents of theory B simply don't feel heard, give up and move on.
This obviously needs to be studied, but IhaveThisFeeling? the latter is going to be more likely. Now, this is not just a bad thing, it will simply mean it will take a bit longer for new theories to become generally written about. One could argue that this is simply the burden of someone introducing a new theory.
Typing this made me finally realize the import of your last statement. When done properly, with measures that correct the currently badly slanted AttentionEconomy, a wiki should be nothing new under the sun. -- WouterCoene

Since I must be the record holder for going from delurking to all-out flamewar here, I thought I'd philosophize a bit about this. I apologize in advance for the length. There's a summary at the bottom for people who want a quick overview.

Main Text

What I gather from the WCP proposal is that the basic idea is to allow for multiple viewpoints on this site without the current broken AttentionEconomy. Thus, each page will have multiple versions of it, all edited (and only editable) by one team of editors. In addition, there will be a raw page on which people can comment. These comments can be integrated into the viewpoints by viewpoint editors. The WikiReaders can then vote with their feet regarding the popularity of editorial clans.

There is, however, the subject of the ThreadMess. Once a particular subject degrades into a flamewar, it becomes much harder for non-participants to actually follow what is being said. The recent AimingForMediocrity page illustrates this perfectly: even I get confused about who said what, and I've been there from the very start.

So why not go all the way? Why not make discussions special? There's plenty of experience doing this with traditional forums ["fora"?]. This would result in a WikiByProxy? situation, where knowledgeable or interested people would discuss a certain subject and editorial teams would figure out which bits they like and compose those into their separate viewpoint-pages. One of the important things this would solve is attribution. Because it's a special structure rather than a generic wiki-page it suddenly becomes very easy to for instance search for all comments by author "foo" where (s)he mentions "bar" (each author could even have his/her own "groupie"-page, which could show his/her latest comments).

Note that it should be possible to move (part of) a discussion to a separate subject, in case the discussion goes wildly off topic.

This leaves open the case of factual pages. Take for instance CounterInManyProgrammingLanguages and friends. Very little discussion there, just factual statements. It would be rather silly to have multiple viewpoints of this page, as it would be equally silly to have just one team of editors deciding what goes on there. This is one of the (many) pages where the wiki concept actually works very well. No sense in throwing the baby out with the bathwater.

So in addition to its viewpoints and discussion, a subject should also have a community viewpoint. In case of a very contentious issue, this would simply consist of a statement to that fact. If some form of consensus can be reached, it could contain a DocumentMode overview of that, making separate viewpoints less necessary. I think this is very important, to prevent the kind of intellectual inbreeding that follows from people only acquiring information from a very limited group of other people; I think the goal should still be the kind of consensus that resulted in the very good DocumentMode articles on this site.

However, I think a special case should be authors' WikiHomePages. These pages are not merely about a particular subject, but about a person that contributes here. I don't think it would be appropriate to allow separate viewpoints on a person; that can only turn out nasty. Thus, an author's homepage should consist of one viewpoint (only editable by the author in question?) and a discussion area.

I'm also wondering about membership of an editorial clan. Someone may want to side with the Lisp clan on typing issues yet be totally opposed to ExtremeProgramming and very much into WesternPhilosophy?. If a user could only choose for one editorial clan, this would quickly result in clans-of-one. I'd suggest making it possible for users to be a member of more than one editorial clan and simply have the clans work out internally what range of subjects they're going to cover.

Summary

Thus, to summarize I'd suggest the following:

each subject has a community viewpoint;
a discussion area for each subject, being a genuine forum instead of a wiki page
zero or more viewpoints on a subject
unless it's a WikiHomePage, in which case there should be only one viewpoint
allow a user to be a member of multiple editorial clans

Thanks for your attention.

-- WouterCoene

You got mostly everything right. I didn't think that homepages should be special, maybe they should. And there's another twist. I thought a while whether the teams should be formed by inclusion or exclusion. If they are formed by exclusion the advantage can be that it can be more open (just deny the attack of troublemakers while keeping everyone else as first class citizens of an edited branches). But my current thinking is the following:

Have the team be formed strictly by inclusion (enumerating the people). It's less administrative overhead (and less programming for me).
Anybody can edit the pages that are "owned" by a team. Such that a SmallTalk fan can edit the JavaLanguage "branch" that is "owned" by the "java" team and express his complaints. However, at some point after the ensuing conversation, a member of an editorial team will mark some particular version of that branch with a tag ,and thus will create a milestone (something like a DocumentMode). In default viewing mode, WikiReader's will not see the latest version of editorially controlled pages, just the latest milestone. So that the grunt of the editorial activity (taking input from everybody who has something to say, trying to summarize, refine, etc) will not bother the reader, and when the editors are happy enough that the page converged towards an acceptable form (DocumentMode, OpinionMode,etc) they will promote it.
- [I had a different comment here but after reading it I found that it wasn't appropriate.] So, basically, someone passionate about a subject can basically flood an editorial team with nonsense, without anyone outside of the editorial team noticing. That does make being member of an editorial team a rather thankless job... I mean, all this would offload quite a lot on editors, and they should still like doing it. -- W.
- See the point just below. If you do it like that you can be explicitly excluded so you won't be able to offload anything any more against that team. So a team will have an inclusion list of editors and an exclusion list of "persona non-grata".
If somebody insists in denying the SoftSecurity of a team's editorial discussion, only then, that person can be specifically excluded by that team so he will no longer be able to send input towards that team.

Also I expect a lot of other things should happen by social convention so that I could be spared programming. Because troublemakers cannot enforce their stubbornness upon everybody else, I'd expect they'll have more incentives to behave, such that editorial branching on many pages should not be necessary, unless as a defense mechanism, or when it improves the content because it. As for "discussion" or "comment" pages, I think they're valuable but I hoped I can get away by not having to implement them. Either because of social conventions , or because I hope I'll expose editable templates that will make the wiki semi-programmable so that the users themselves will be able to create templates for discussion pages. -- Costin

[Deleted my remark because I changed my opinion: templates are definitely more at home on a wiki -- W.]

It dawned on me that templates are absolutely needed and a sound design decision. Here's why: I am lazy, I think laziness is a supreme virtue in software development. So this project being run by squeezing one hour here and one hour there was always minimal (following my favorite DesignPattern: PutTheDamnDataOnTheDamnScreen?). The initial prototype available demoed at WikiSym is ugly as sin (bare HTML, no fonts, no colors, no nothing ). Then I had to implement very quickly the RecentChanges page. Because I already have a problem writing good HTML, I simply run a SQL query and convert data to S-expressions, which are transformed to page S-Expression: (table (tr (td (a page_name)) (td change_date) ... and sent to the Display Servlet that generates HTML like for any other page.

It still looks unsatisfactory and there's very little purpose to muddle Java code with more HTML niceties. I could do it that way, but then it would be slow and boorish for me as well as a maintenance nightmare. So the good way is that the Java code proper will simply spit out the data behind special pages or even wiki pages. That data is unified through PatternMatching with the page template. So I can write the SQL query for RecentChanges, provide a minimally usable template to make it render in a broswer (albeit ugly or at least frugal), and because templates will use the same (WcpEssExpression?) basic syntax as wiki pages, any user could contribute to the look and feel.

So not all users need to be smart about templates, but if some advanced users (especially developers) have gripes with the look and feel and the HTML aspects of it, they should not depend on engine developer releasing another version in order to fix that. I hope that the template "language" will turn out attractive enough for HTML gurus to use, otherwise I have to learn HTML + CSS myself and my head is already exploding. -- CostinCozianu

One fun thing about my sketch of WikiChangeProposal is that its flexibility can be made to address very unexpected needs that weren't even considered initially.

For example, what caught my attention recently is that I've seen in academic papers references to the on-line world, and specifically to wikis, that look like:

   "http://c2.com/cgi/wiki?DocumentMode as read on September 2, 2005".

Now that to me looked absolutely funny if not outright deplorable. What's a reader supposed to do about that reference? Hope that that day is archived somewhere on a WaybackMachine? On the other hand, I can understand that somebody cites something like ObjectRelationalMapping with the idea to support one point of view, and before the paper is even published that page says something else altogether. Having editorial branches and labels for milestones allows one to properly cite wiki content.

The other thing that I think Ward got it mostly right is WikiNow. Page versions older than a given time (say a week or a month) should simply be deleted. Not only because of storage waste on the hard-drive but also because of information overload. Trying to follow the history of some contested page on WikiPedia may get you dizzy. There's simply too much stuff being kept around. But on the other hand it would be interesting to read the views on topix_x in 2000 versus 2005. By enforcing a strict WikiNow the HistoryOfIdeas is prejudiced, so milestones provide a nice balance: only versions marked as milestones by editorial teams are kept in the long-term history of wiki.

You're going to explicitly expose milestones, similar to Wikipedia's "permanent link"? -- W.
Yes. It will be like that, except that the engine will not keep the full history. Only "milestones" will be kept. Now WikiPedia runs on 100 servers or so. My intent is to allow any Joe Average to run a site of < 100000 pages on his home computer, and maybe (if I have time) to explore FailSafeWiki to allow a peer-to-peer network of volunteers to run any imaginable size.

CategoryWikiChangeProposal