Consider the future history of a wiki as its continuation. Lots of pages start off rather well I think, but then flames, trolls, and spam make them nearly useless. ---- '''Try ManaMana (the AntiSocialWiki)''' ManaMana would permit an arbitrary number of branch points, not for a page, but for the wiki as a whole. To do this, we start with the WayBackMode of CvWiki but do the thing on SubVersion because CVS doesn't branch branches very well. Now every time one of the JoylessPeople comes and futzes up a page, all a community member needs to do is to peel a previous continuation off the RecentContinuations page and callcc it. Let the noisy pots continue on as they will, it only takes a few happy personalities to continue on the joyful continuations and generate the real content. What's more the continuation wiki can do KillFile''''''s. You just filter out continuations that have any of your least favourite people in them. If this is successful, it's likely that several continuations at a time will have content forming. Given that they have a common ancestor back in time some place, it falls to our good old WikiGnome''''''s to merge the good continuations to form ... well, unified good continuations. Since gnomes generally get off on that sort of thing, I daresay they'd regularly announce their exciting new stable merged releases at least once every week or two. See? Not so hard after all, is it? I suggest Ward dig out his backup of wiki as it was on the exact day before the day when the RichardKulisz homepage was first created - I know he has an email flamewar with RK that should date the thing precisely - or if he doesn't I do some place - and dip himself in SeasideFramework this weekend to get it done. Oh, and since I guess I have naming rights I suggest it be called ManaMana, after the Hawaiian for "appendages, claws, branches, rays, forks; to branch out". Or maybe OliOli - Hawaiian for joyful. -- PeterMerel ---- http://www.bastisoft.de/comics/rzw/manamana.jpg ''ManaMana...'' : Doo doo, doodoodoo ''ManaMana...'' : Doo doodoo doo! ''ManaMana...'' : Doo doo, doodoodoo, doodoodoo, doodoodoo, : Doodoodoodoodoo '''doo doo doodoo doo!''' ''ManaMana...'' : "Windischeschenbach here. What's that?" : "Shuttle here! Ah - the spacesuit radio was successfully tested." (Windischeschenbach is a small city in Germany where space control is located.) ''The cartoon is right, the "translation is wrong". It's "bi bi bidibi" (as in the image) not "doo doo dodoodoo". At least, that's the way Piero Umiliani "wrote" it ...'' ---- * Versioning/merging: ManaManaVersioning * Similarities and differences between ManaMana and WikiChangeProposal: ManaManaAndWcp ---- You could also call it ManyWorlds, for obvious reasons. -- EM ''ManaMana seems to adequately riff that.'' Advanced DungeonsAndDragons has a polyverse notion, where multiple Prime Material Planes support various different physics. Some enable science like ours appears too, and some enable magic. The ones with "too much magic" tend to fragment into independent realms, containing only those individuals who get along with each other and allow each other to manifest. Such would be a ManaMana world. WikiWiki has too much magic, so we will perfect the art of fissioning our tribes. -- PhlIp (who cannot believe he's actually following bits of this discussion!) ---- I must have missed the part that keeps the agonists from following everyone else to new continuations and prevents continuation wars from replacing edit wars. How does that work? -- EricHodges ''Oh, that's easy - you just pick up the continuation from just before the joyless ones followed up. If the joyless ones keep on dogging you, you KillFile them - and that's that... you never see their continuations anywhere after that.'' I'm still missing something. It sounds like the kill file just filters continuations with certain contributors. What prevents them from joining all continuations? -- EH ''Um, not ''the'' killfile. ''Your'' killfile. Oh I imagine you might publish it on a wikipage. And it might be inclusive or exclusive - you could set it to include just your homies and their homies, or you could set it to exclude particular noisy/joyless pots and let in the rest. Back in usenet people would share parts of killfiles just to be sociable.'' ''Or you could skip the killfiles and just continue opportunistically. For example, if I were on ManaMana, and if I hadn't already killed them, I'd just continue here from the point before CC & RK showed up. No problem with them continuing to rant as they did, nor with them picking my new continuation and ranting on that - the wiki would branch. The result would be several continuations of wiki, one with my changesets and the changesets of anyone I personally felt inclined to respond to, and the other with the short, thready, noisy, joyless peoples' changesets. Evolution - the tendency of signal to outdevelop noise - would take care of the them.'' ''You might worry that I'd also ignore people who followed up to the joyless people. But I wouldn't worry about it - anyone who follows up to one of them deserves what they get.'' I don't see it. The agonists will copy their content to every continuation you make, just like edit wars now. You can't escape them by branching unless you secure the branch. I think you assume they want to branch away from you as much as you want to branch away from them. -- EH ''I don't care if they're all over me like hairs on a duck. I'll never see them because they're in my killfile. The moment someone interacts with them, they'll do likewise. Onwards and upwards.'' Eric, as I understand it, when they reply to your branch, they create a branch. Since you have them killfiled, you never see that branch. -- EarleMartin So every change creates a new branch? I didn't see that in Pete's proposal. I saw him say "peel a continuation off the RecentContinuations page and callcc it" - an interaction distinct from normal changes. It seems to me that anyone is free to contribute to the any continuation. If so, I predict that those one wishes to exclude will "not go quietly into that good branch", so to speak. -- EH ''Every edit is the root of a branch - which is for the sake of this page an equivalent concept with a continuation. We filter your view of RecentChanges so that only edits of the continuations that fit your snubfile (killfile is too trollish a term) turn up there. If you're snubbing me, say, then when I contribute an edit it simply won't turn up in your RecentChanges. If you view the page I edited on my continuation, you won't see my edit there either - you'll see the edits that correspond with whatever continuation fits your snubfile. If there are multiple growing continuations that fit your snubfile you'd be able to navigate to them all. If one of them happened to be noisy you could snub it or its author. If you're a gnome you could also kick off an SVN client with the ability to merge the continuations. This would be super-empowering for gnomes ...'' -- Pete I think I have it now. The "callcc" reference above is misleading. Community members don't have to peel anything. Each edit branches the page. I'm trying to get my head around how the leaves will be merged. If I haven't snubbed anyone and there are branches leading to n different versions of a page, then I ought to see all of the information on all n versions, right? -- EH ''Right, but it's not the page that branches; each edit branches the wiki. Except it's only a virtual branch - nothing is created until someone continues the branch. As for the merge technique, it's nothing but an ordinary svn merge in an svn client. Or similar - I have yet to rtfm darcs and so on. An interesting possibility is that this branch/merge process could be used by gnomes to spawn wikis for special purpose/aspect-oriented discussions. Such as, for example, a stewards wiki where various automated refactoring schemes and so on could be tried out to heal the WikiAtFortyThousand content rather than revert to W@10K. And if there were programmatic content on the wiki - the original intention of wikibase after all - then this would finally enable it to develop without the joyless people screwing it all up with clueless checkins. Maybe the thing to start with to enable this is TracWiki ...'' -- Pete I don't see how a svn merge will work here. Imagine Bob and Larry have each other snubbed. They each edit page A, creating AB and AL respectively. (The rest of the wiki may be "virtually branched", but since nothing else has been edited the only difference is AB and AL.) A was: "Love is the law." AB is: "Love is a many splendoured thing." AL is: "I fought the law." Now Stan shows up. Stan has neither Bob nor Larry snubbed. What does he see when he looks at page A? And when Stan edits whatever he sees, how do Bob and Larry see his edits (neither of whom have snubbed Stan)? Svn can't automatically resolve these kinds of conflicts. -- EH * I don't think Stan sees "page A" - he sees A-Jim-2006-03-02:14:45 (the original) ''and'' A-Bob-2006-03-02:14:48 ''and'' A-Larry-2006-03-02:14:49. It's up to him which to edit. You're right in that some conflicts can't be automatically resolved, and this is where the WikiGnome''''''s come in. A gnome can create another, refactored/merged, continuation - and it's up to the other users to decide whether it was a good piece of gnoming. If not, forget it and start another continuation. On the other hand, I'm not sure what to expect if Stan creates a new version incorporating material from both Bob and Larry. What would they see, Pete? -- EarleMartin ''I am disturbingly reminded of the little cats in TheCatInTheHatComesBack. But never mind that. In Stan's RecentChanges he sees page A has recently changed with 2 continuations, AB and AL. At this point he has 4 choices: (a) he can read/ignore 'em and let them eventually slide off his RecentChanges as time goes by; (b) he can edit one or both; (c) he can decide to snub one or both; (d) he can merge and edit the result. Cases a-c don't seem controversial, so I'm just worrying about (d).'' * (b) Also presents interesting quandaries. With all these edits showing up (in combinatorial fashion), it is extremely unlikely Stan will bother editing 'both', so if he just edits one - say Bob's - it advances the RecentChanges, and is thus more likely to be edited again in the future. Chances are good that, Larry will never, ever see updates again, simply because a third party chose first to edit Bob's and was too lazy to contribute to two or more branches. ''Stan sees many edits slip into place without issue - TS's concerns notwithstanding - but here's this line where there's a conflict flagged by the merge tool - using the usual <<<--->>> syntax qua cvs/svn I expect. Stan resolves this just as if he's editing code; he may prefer B or L's formulation, or use both, or extract both to separate wikipages and link them as suits him, or delete them, and so on.'' ''When Stan's satisfied with his merge he commits his edits as a new continuation, AS. Both Bob and Larry will see AS in their RecentChanges as the continuation of their respective edits even though neither one can see the other's original edit. One or both may be offended by AS, in which case they may snub it and/or Stan and continue on regardless. Or both may continue from AS.'' ''If this cycle repeats, Stan may want to suggest B and L unsnub eachother - but that would be a rare event. At least I don't recall often un-killfiling someone back in usenet days.'' But what does Stan see on the page itself? Ignore recent changes and focus on page A. -- EH ''Looking at AB or AL Stan sees what B or L edited into being. Looking at the merge he sees a pretty coloured 3-way diff.'' How pretty will that merge be if every edit creates a branch? I assume Stan will see the merge when he clicks the link to A. -- EH ''Which link to A? Remember, the whole wiki branches, not just a single page. If Stan is in AB or AL he sees no merge. He generates the merge voluntarily with an SVN client. This suggests the concept of a RecentContinuations page giving access to per-continuation RecentChanges pages. But I prefer the idea of continuations and changes laid out on a single RC page.'' Any link to A. You said that the wiki branches were virtual until an edit was made. Stan is in neither AB nor AL. Stan is on some other page with a link to A. He clicks that link. It sounds like he will see a merge of every branch of A (since he has no one in his snubfile), and since there's a branch for every edit, he's see a merge of the entire history of A. Do you see the problems we run into? -- EH ''"Stan is on some other page with a link to A". Let's call that page Z. Which continuation is page Z in? If it's in continuation B (it's page ZB) then Stan will see page AB. If Stan is in ZL and he clicks A he'll see page AL. That's just WayBackMode.'' ''It'd obviously be nice to put a header on all of these A pages that would include links to the other A pages available under the conditions of Stan's snubfile. But there's no need to represent some confused history of these continuations - just the growing tips, from any of which you could generate an individual page history. Really it's just a view of an svn-style SCM. So I don't see any problems yet.'' Then I'm misunderstanding your notion of virtual branching. Z doesn't have to be in any of those continuations until an edit is made on it, right? -- EH ''Z is just some page on the wiki that refers to A. In my answer to you I assumed such a page existed in both continuations B and L. Most likely it existed in some common root continuation.'' That common root is the problem. Perhaps another example is called for. Let's say Z1 has a link to A1. Bob edits A1, which creates A11. When Stan clicks on Z1's link to A he should see A11 (since Bob is not in Stan's snubfile.) Then Larry (who has Bob in his snubfile) edits A1 (after Bob) and creates A12. Now what does Stan see when he clicks on Z1's link to A? There is no Z11 or Z12 yet, since it hasn't been edited since A11 and A12 were created. Would Stan see the original A1? Are page edits invisible until someone edits all the backlinks and realizes the virtually branched wiki? Or would Stan see a merged view of A11 and A12? ''Ah, now I see your point! I diagrammed this as a set intersection with Z1 and A1 inside, A11 in continuation B, and A12 in continuation L.'' ''I think I'd like Stan to be presented with one of those pretty coloured diff pages I'm so fond of. WhyClublet did something a little like that at one stage. But scaling the diff past 3-ways ain't pretty. If continuation 1 (containing Z1 and A1) was somewhere back in the dawn of time, there's a potential for thousands of variegated diffs.'' ''Seems like if Stan wants to make sense of this he has some snubbing he '''has''' to do. Or at least selecting. I think, if there's more than a half-dozen (primary colours per continuation diff, naturally) we present Stan with a list of all the growing continuations leading from A1 and let him pick a set of 1-6 he'd like to view.'' But when Stan first arrives he has no context for snubbing or selecting. He wants to explore the pages and build wisdom before he decides to ignore Richard. (Stan is a super guy that way.) -- EH ''As mentioned I'd start all newbies off with a copy of Ward's snubfile. Or start them off with just the major continuations - that's to say, if two branches share a common ancestor, prune away the shorter. This would serve as a significant motivation to factor and merge short branches.'' I wouldn't assume that Ward (or whoever owned the wiki) had a snubfile, or that they would want it made public. ''I don't assume that. I just suggested it. And an alternative. Lots of other alternatives seem plausible. Make up one you prefer if you like.'' I don't understand how a branch can be "major" (or minor). All branches share a common ancestor, don't they? ''Sure, but some of them are longer than others. To show the major branches you could provide a pathlength-based criterion, or you could say you only wanted the N longest branches - or lots of other criteria may be more suitable for particular purposes.'' And isn't a merge just a new branch? Perhaps you should explicitly define the operations that can be performed on pages. So far I've seen "edit", "merge" and "continue", but they all look like edits to me. -- EH ''A merge is a new continuation. If more than one person builds on one continuation in parallel, as for example (1) above, then that continuation has branched. If someone joins the edits of two continuations, they have merged into a new continuation. To any reader all continuations look like edits, just as you say.'' ---- And when you speak of "growing tips", which tips aren't growing? It seems to me that every edit creates a branch and every branch is growing. Hence my conclusion that un-snubbed merges will have to show the entire history of each page. -- EH ''Recency and/or length of continuation since branching could make a fairly tidy arrangement here, I think. When you walk through a garden, after all, you don't much care about what's inside the shrubs. You're there for the flowers.'' If branching was a distinct interaction from editing (as you implied at the top of the page) then one continuation could grow longer than another, but there is no "length of continuation since branching" when every edit creates a branch. The model you've described to me is nothing but shrubs where their insides and outsides all have potentially equal value. -- EH ''Every edit creates a continuation, a branch point from which any number of branches may spring. But no branch springs from that point until someone continues it. And given a reasonable motivation to refactor and merge substantial branches, creating diamond shapes rather than trees, the tendency of the overall continuation tree to "shrub" doesn't seem significant to me.'' What does "someone continues it" mean? Is "continuing" a branch different from editing a page? It sounds like merging branches is different from editing a page. Is it? -- EH ''A continuation may involve many edits to many pages. RTFM any modern SCM.'' I have (if you consider Subversion a modern SCM). I still don't know what you mean by "continuing" a branch. When you first created this page it sounded like branching was distinct from editing. Then you said every edit creates a branch. ''Um, no, I said, "Every edit creates a continuation, a branch point from which any number of branches may spring". That's not a branch; it's the potential to branch. I'm not certain how else I can say this. Um, imagine bamboo growing, where every joint is a continuation. Now imagine that from any joint a twig can grow. Well, okay, it's not very bamboo-like, but I want a tree where there are growth demarcations every inch or two, so you can see them.'' ''Every one of those growth demarcations, whether at the tip of the bamboo or anywhere along it, is a continuation, the result of application of a changeset in SubVersion terms. If two or more people create two or more different continuations from one of those demarcations, we have a branch.'' ''Now each branch has a continuation at its tip. If one of them gets continued a few times, and the other does not, then plainly one is longer than the other. Still SubVersion has the ability to merge a smaller branch into a longer one, so if there's any point in that then someone will likely do it.'' ''They may do it because there's valuable content on the smaller branch they want to see developed. Or they may do it out of ego. If the former, and if they factor well, they'll likely not end up in anyone's snubfile. If the latter, then a casual reader, let's say Roger, might snub 'em. That's to say, after snubbing, Roger won't see the merge continuation; for him the continuation of the longer branch, just before the merge, would be the continuation's growing tip.'' ''I admit this terminology is clumsy. If you can think of a better way to put it, I'd be much relieved. I hope as ever that what I'm saying makes sense to you.'' If branching is a distinct operation then someone can edit a page without creating a new branch. If every edit creates a branch then I don't see how you end up with anything but edits (or anything but branches). -- EH ''Every edit creates a continuation. Whether that continuation will be used as the base of a branch or not depends on further edits as above. It's worth noting that Roger, snubbing the merge, may continue the big bamboo from the point before the merge, thereby creating a branch himself.'' I see now. Every edit creates a node. The 2nd edit on a node creates a branch. -- EH ---- Since every edit creates a branch then looking at A wouldn't show A, it would show the entire edit history of all branches of A. That would be overwhelming and less than useful. This sounds a lot like C. S. Lewis's vision of hell in "The Great Divorce". Every citizen could have anything he wanted. Each one eventually became isolated by walls of stuff they never used. When I look at a page I should see a page, not a tree of pages. -- EH ''All you'd show is the growing tips of A; with a reasonable snubfile to "shave the hairs off the duck", there won't be many of these tips, and each should either be distinguished by aspect or quite readily mergeable.'' There will be as many tips as there are edits. -- EH ''No, the structure is the same as that of a codebase under an SCM - it forms a DirectedAcyclicGraph, not necessarily a lattice.'' ---- A few questions. * What does the first-time visitor to a ManaMana site see? The blizzard of continuations created by "the joyless ones" (nice phrase) could be overwhelming. * ''Ah, we must fight the AttentionEconomy ... well, I think it depends on where in ManaMana we want the newbie to land. I personally would warp them to whichever continuation was Ward's last contribution. Not because I'm fond of Ward's content - he's kind of dry for my taste - but because I trust him to be mobbed up with a good krewe. And because this is WardsWiki, after all.'' * ''Landing there they'd read the FrontPage (unmarred by threads and spam, of course) along with whatever other EtiquetteDriver''''''s were about. They'd then do the newbie orientation process for a few months and commence getting stuck in. Bumping their noses they'd wind up in a few killfiles, but if they were of good cheer they'd soon find their own krewe to hang with. On the RecentContinuations (maybe RecentChangesets is a nicer WikiWord) page they could see all the developing tips of Mana and explore the RecentChanges of each ...'' * Would SearchEngine''''''s index everything? * ''Poor google, obsoleted by the non-deterministic web! Um, pass.'' * Following on from that, how would WikiSpam be approached? I suppose you could have a default KillFile something like the one at http://www.communitywiki.org/BannedContent, plus some of the other WikiSpamSolutions. * ''I myself would identify members of my krewe and ask them to publish their killfiles on their homepages. I'd do likewise. I'd automatically glom these killfiles together to generate the one I'd actually use - making it as inclusive as logic allows. But a less complex WikiSpamSolution would probably be best for a newbie.'' * What's to stop an inexperienced new visitor starting a bunch of activity on an older continuation from which everyone else has moved on? Presumably a gnome could merge their text into the current continuation, and leave a note on the old one... * ''Yep.'' Hmm. You could have some form of listing of various continuations ranked by popularity, where the ones with the most activity (heat) rise to the top ("above the fold"). Which ones become hot would be, to mix metaphors brutally, a result of the users voting with their feet. ''Yep.'' The more I think about it, the more I like this. It reminds me of NomicGame. Good work, Pete. -- EarleMartin More thoughts: everyone has a public snubfile. So, generate statistics on snubbing for new visitors - "Most Snubbed". Allow users to view through other people's sunglasses (snub settings) to try out different perspectives. -- EM ---- I like this. A lot. Enough to poke around in MoinMoin and see how hard it is to accomplish. Very cool, Pete, very cool. -- TomStambaugh ''I'm unlikely to implement this idea soon myself, Tom, so do feel free to go for it if you have time.'' ---- Peet, WhatYouResistPersists. --the persistent PhlIp ''But we don't resist. We accept - and choose when to followup.'' -- Pete Snarl snarl gnash yap yap yap! Chest thumping! Satisfied grunt. -- Phlip ---- The same idea, over and over again. See ViewPoint, from CliffordAdams years and years ago. Just build it. See if it works. It's not impossible to build a filter on top of c2 itself. -- SunirShah Hi Sunir, long time no see here. It's not really the same thing: * "Each viewpoint is a complete wiki, controlled by an editor. Only the editor (and later, anyone they authorize) has any permission to change pages within the viewpoint." Peter's ManaMana proposal doesn't have any concept of permissions. The following is similar, * "No edits will be forced on any editor, but editors can edit the output of other editors to an arbitrary degree. (The output of any editing is also a submission, which can be copied/branched and edited.)" but ViewPoint is much more like WikiChangeProposal as you well know. I think the main difference is that ViewPoint operates on a whitelist (subscription) model while ManaMana operates on a blacklist (KillFile) model. Which is interesting as it takes the mirror approach to the same goal. Some of the "compromises" listed on ViewPoint are quite applicable to ManaMana as well. -- EarleMartin ''See: ManaManaAndWcp'' ---- ''Here in 2014, ManaMana has been implemented as something called GitHub. Well, via the combination of git, github, jekyll and github pages, but you get the idea. One of these days Pete is going to actually implement something he dreams up before someone else does. And stop talking about himself in the third person. --Pete.'' ---- * http://members.tripod.com/Tiny_Dancer/mahna.html ---- FebruaryZeroSix (wow, this must be the most powerful topic I have seen since the beginning of ImplicitTopics) CategoryWikiImplementation, CategoryWebThreePointZero, or after trying everything else, consider: The SmallestFederatedWiki