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


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.

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.


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


CategoryWikiChangeProposal

EditText of this page (last edited June 12, 2012) or FindPage with title or text search