Mana Mana
Mana ManaConsider 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 KillFiles. 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 WikiGnomes 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
ManaMana...
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 ...
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
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.
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:
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.
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
EditText of this page
(last edited May 11, 2014)
or FindPage with title or text search