Mana Mana And Wcp
Mana Mana And WcpManaMana is an interesting idea. How does it compare to WikiChangeProposal? -- DaveVoorhis
ManaMana seems to me simpler and more general and open than WCP. No voting, no one policing anything, no old-boys club, nothing but quantity and quality of content to distinguish one continuation from another. No one is compelled to close out an unpopular continuation and there is neither a necessary representation of all views, nor a necessary contraction on just a few views. Also no wiki blacklists and no necessity for passwords or other kinds of authentication. Just pure content evolution as the WikiNature always intended. --Pete.
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
One trivial response is because they would be banned from that particular branch. Or because the mere possibility of the guy who created the branch banning them and therefore making them look bad in public, will be enough of a deterrent for such people to stay away from branches where it's clear that they're not welcome, so one would not necessarily ban certain users immediately as a branch is open. It's all detailed in WikiChangeProposal and WcpUseCases, but I guess it's better that people like to write more than they care to read, maybe Pete et. comp. is able to come up with some more ingenious idea for the same problems. --Costin
I understand WCP. I'm talking about Pete's idea. --EH
No banning, that's not necessary here. You continue your own line of development and I continue mine. Folk who are interested in us do likewise, respectively, and maybe some of the more conciliatory ones help develop both conversations. Or merge some of our changesets to produce continuations of their own. One of the cute things about this idea is it lets the gnomes get stuck in with a proper SCM client ... or maybe that's making a simple idea too complicated?
Now I read the WCP proposal again I think I understand it better. I think the difference is similar to the difference between a modern SCM (svn, darcs) and an old file-oriented non-branching one like the old VisualSourceSafe.--Pete.
That's fine, Pete. You can push your vaporware all you like, but if you actually took time to write down this scenario as an unambiguous use case, that can be understood by a mere programmer, you'd see that you reinvent the same thing. You name it "ignoring" or "killfile" to avoid the ugly name of "banning". But effectively that's the same thing, excluding one person from certain branches of topical discussion.
I suspect you misunderstand. No person is excluded from any branch of topical discussion. Anyone can continue any branch. But anyone can filter the set of branches they experience. The effect, to the snubber, is that the snubbee ceases to exist. The effect, to the snubbee, is that the snubber doesn't follow up to their edit. If you are the kind of person who generates a lot of ill will you'll see many people snub you, and not many continue your edits. If, on the other hand, you're more of a polarized person, someone who has strong views but otherwise plays nice, then just a portion of the community - those who can't abide your views - will snub you. And if you're someone who finds that everyone snubs you, you'll either change your ways or get bored quickly.
In any case, if you feel like it, I look forward to collaborate with you even for something as small as brainstorming and refining use cases. --Costin
That's awfully kind of you Costin, but I wouldn't want my ugly, stupid vaporware cluttering up your brilliant scientific advances ;-) I look forward to your success.
Technicalities of Branching and Merging
As far as I am concerned, ManaMana is really the same thing as WikiChangeProposal , minus a lot of details that are still to be reinvented by Pete, also minus a lot of wilful misunderstanding and drivel pushed against WCP. Any functionality talked about here is currently supported in the head version of the CVS of Wcp, which I'm sad to say is still in alpha stage. But I'll be happy to see ManaMana implemented first or implemented better. By the way, to clear up any further misunderstanding WikiChangeProposal is identical with ViewPoint, this much I confirmed with CliffordAdams. They're two labels for exactly the same vision. --CostinCozianu
I think that last bit is settled. But I invite you to respond to the "I suspect you misunderstand" para above. --Pete.
The best to think about the equivalence is not to think about implementation details (like branches and editing teams versus "continuations" and the likes, but see it from the point of view of end users and what they experience in very concrete terms. So if you take the WikiReader first, what will he see when he types in the name of a contended page ? If you are a wiki contributor and you want to deal with a contentious topic, how will the things work ? If you make this analysis, you'll see that both proposals are identical (modulo some unimportant terminology).
For example it is your misunderstanding that WCP implies "banning" and "banning" is a bug to be avoided. Well, it implies banning no more and no less than your proposal implies shunting. In the end, the reader will see that there's page_X/branch_A and page_X/branch_B and readers which have a problem with people who developped branch_B may choose not to see branch_B at all, and vice versa, while contributors at large may choose to contribute at either branch_B or branch_A. --Costin
The misunderstanding may be mine, but I'm not convinced yet. How does WCP do merging? How does it represent the distinction between changes and branches to the WikiReader? And how have you implemented killfiles? --Pete.
Merges: In WCP, merges are not the concern of server software. A wikignome with a browser should do, because merges are, in my opinion, not the problem to be addressed -- at best merges can be an implementation detail of addressing a larger problem. If you make the merging of arbitrary versions on arbitrary branches a problem then it may be intractable. A page to highlight the diff between any two revisions on any two branches is on my TODO list.
Merging is not intractable - any reasonable SCM will do it. Moreover ManaMana wouldn't have page_X/branch_A and page_X/branch_B but branch_A/changesetX and branch_B/changesetY, where the changesets may include multiple edits to multiple pages.
That's fine if you think any SCM will do it, but I think any SCM will not do it without serious work on the human driving the process. That kind of effort would be OK if you want to merge a few RedHat's bug fixes into the latest kernel.org sources, but I don't see why you'd need it on a wiki. Do you miss change sets from this wiki or do you miss the option of having a conversation without somebody shouting "you cretin" in the middle of it ? The thing that needs to be added is ComfortableSpaceForDisagreement and TSTTCPW for adding that does not include installing DARCS or PerForce? with a wiki.
Yes, I assume a gnome is driving the SCM. The SCMs I know all need humans to drive. As to why, well, consider DefinitionOfLife. A lot of people I respect sallied against RK on that page, and he did his usual schtick on 'em all. If I snubbed RK I'd have seen none of that stuff under ManaMana. Well, unless I tolerated people in my krewe who were daffy enough to followup to RK, which I would not. But, RK having a fan club, I'd be exposed to all of it under WCP. Hence WCP is too simple to work for me.
Yes, but as a gnome would you want something as complicated as an SCM?
Um, Yes. Wikis are not less complex than codebases. SCMs are tools for dealing with multi-person edits of complex structures - no reason to dispense with them, is there?
The whole point of WCP is that branching should be the exception, and not the rule.
The idea of ManaMana is to permit easy branching, merging, and filtering. No unnecessary constraints.
Teams and Consensus
DefinitionOfLife is a perfect example for this. So the problem there is that mostly everybody else can work together on that page and even agree to disagree peacefully, except RK who insists on having his POV enshrined. The mechanism under WCP is that Peter creates a branch under say, "Peter" editorial team (each user is his own team as well). At that point this doesn't mean that you excluded anybody, just that you took responsibility for creating a branch. If RK insists on ruining your branch you can ban him from your branch and remove the damage.
Under ManaMana you cannot exclude RK from your branch. You can ignore him instead. The advantage of this is that you neither offend RK nor experience him, and anyone who is interested in any clique of the editors of the branch, including RK or not, can work with their chosen collaborators, or whatever sub-portion of their edits they find acceptable.
Under WCP, otoh, I must choose a clique based on its membership. If, for example, Peter decides to work in RK's team, then Costin can't very well work with Peter unless he also works with RK, nor exclude RK without also excluding Peter.
Now everybody sees that there are 2 versions: the raw version (anything goes) and a "team" version under the team name "Peter". They can contribute to whichever version they see fit. At this point, as any "team" version takes precedence over the raw version and appears first to readers without explicit preferences, RK, presumably will set up a "RK" team branch of DefinitionOfLife. And you'll both "compete" (in quality, presumably) for the attention of the readers.
I don't see why we need to keep these 2 versions separate. Moreover, with such a complex topic, and with so many worldviews possible, the job of merging to a consensus becomes very difficult without real SCM support. I humbly submit that's one reason why c2 is such a mess today - take a page like MemesShmemes as an example of a mess that has defied mortal gnomes for years.
You don't need to keep these two versions separately. But if the proponents of such views come to the conclusion that their views are better promoted separately they can freely chose to do so. Pressure for premature consensus and "debate" is what ruined the atmosphere in the early wiki, when all that was needed was ComfortableSpaceForDisagreement. If you software will come with the same ideology that people should be drawn into debate and debate under the mythical consensus version (aka DocumentMode ) will occur, it'll suffer the same problem.
Under ManaMana that's a decision for the readers, not the authors. Presuming some author merges the two branches, a reader may choose to continue that merge. Or they may snub it along with none, one, or both of the original contentious viewpoints. And they may snub/join any combination of the editors of all three. And they may rearrange this from time to time and revisit the same material under any combination of snubs that suits them in the WikiNow.
I know you allude to a killfile below, but does it provide such flexibility? And if it does, then why bother with teams and banning?
Think of worldviews as broader than a single page - imagine, for example, that we had hindus, moslems, jews, and a dozen other relatively mutually exclusive views vying for attention on a huge range of topics. Imagine, for example, that WikiPedia gave up its faux-objectivist tone and enabled debate. I feel ManaMana would be generative and supportive of new kinds of interaction and society among these views where WCP would tend to polarize them. --Pete.
This view is rooted in the mistaken belief that debate can solve problems. That there's this "consensus" to be reached on subject like static_vs_dynamic_typing, xp_vs_design_by_contract, richard_gabriel_vs_dijkstra, smalltalk_vs_haskell_vs_lisp, if only people discussed these things some more. I have news for you: there's no consensus to be debated, no final conclusion to be reached. There's no meaningful NeutralPointOfView either. Actually I should write NeutralPointOfViewIsNonsense?. The history will settle all these petty disputes years later, we cannot do it now due to the strictly limited size of our own skulls. Until then the best we can do is to present the alternatives as well as we can possibly do, so that people can place their bets and invest themselves in one versus the other, based on educated guesses. And a wiki software should reflect that. That's what WCP is trying to do. I do not believe in consensus. If consensus is what it is good, then it should emerge naturally from the free choices of people who are not constrained in any way to evolve towards a premature consensus. --Costin
I don't believe in premature consensus any more than you do, nor have I suggested such a thing. I'm suggesting instead that ManaMana enables many different worldviews to exists side by side, merged where they are equivalent, and generating interaction where they are associated. I suggest WCP, by promoting teaming over merging, encourages duplication of the equivalent parts of the worldviews and makes the work of interrelating them less coordinated and more contentious.
To build on the example, moslem, christians, and jews agree on many points of dogma. But they don't talk with each-other about these equivalencies when they're on different teams; they talk among themselves and turn their minds to competition and disagreement. "Us and Them" stuff. By instead encouraging individuals to focus more on their commonalities than their differences, indeed to trade with each other and learn from each other on the basis of their commonalities, we'd avoid unnecessary tension and generate reconciliations and profitable interwork between individual adherents of these dogmata.
Branching, Ranking, Snubbing
The WikiReader has access to the "preferred" branch of the page he types in (and the preferrence algorithm, when fully implemented will have ranking that can). From there he has one link access to all the alternatives (meaning the latest version in all the branches). --Costin
I don't care for ranking at all - what if there are two groups of people who rank using different criteria? The sum of the ranks won't satisfy anyone. But managing multiple ranking criteria would get very complicated I suspect. And ranking others work is socially disruptive, onerous, and error-prone.
No, ranking is up to each individual users if he cares to. For users who do not care to say "I prefer Pete as an editor better than Costin", there is a default global ranking based on page views. The important thing though, that even if they get access to Costin's edition (should Costin and Peter chose to part branches on a particular subject they disagree on) they will be only one click away from Pete's point of view.
I dig that, but it's not the problem. Let's assume that many users actually like to read both Costin and Pete except when the two of them get to fighting each other and making noise. Under ManaMana they can simply snub the continuation of the fight, or any continuation where C follows P or P follows C; under WCP they have no choice but to either miss the otherwise excellent signal the two create together or to tolerate the nonsense.
Under WCP they also have access to all revisions of all branches, but they are not burdened with it. But if P and C are reasonable editors and see that they cannot converge, they will agree to part ways agreebly and make branches. C being reasonable, he will, in his branch, refer to the significant points of P's branch, even quote P, etc, and state why he disagrees with alternative points of view. If only one of the two is reasonable branching will happen and everything will go smoothly. If none is reasonable and insist on messing up something that is globally important (like ObjectOrientation) then a third party can step in and create a reasonable branch. Readers will have access to everything of they want to, but they will not be incovenienced with the details of the whole mess.
What if the pattern of edits does not naturally fall into two distinct groups of editors? Temporal dependencies in viewpoint are common in many domains. Nothing suggests the graph of editors and their relationships naturally forms tidy groups, nor that any such grouping need be persistent over time. Moreover, forced splitting of the graph into disparate teams of editors removes many possibilities of rapprochement.
Nothing is forced, and nothing is split forcefully. If somebody (or a team) wants to split a particular ViewPoint from the rest of the pack, they should be free to do so, and promote their point of view in a free marketplace of ideas, visions, approaches.
The reader is forced to pick one or the other ViewPoint. Under ManaMana the reader would be free to do this, but not required to do it. They could read whatever clique of editors and/or subportions of editors' work they like irrespective of the editors ViewPoints. Cliquing and filtering then is the readers' choice, not the writers'.
If there are several versions (branches), then obviously the reader can look one at a time. What I feel you want to do is shift the effort to the reader. Because editing has to be a logically consistent activity, you cannot in general cherry pick "edits" (eventually from different branches) by arbitrary criteria, and get a consistent version. So, if, for example you blacklist RK and accept me, but I do an edit that only makes sense if RK's edit is also included, then your system (at least the way that I understand it) will produce an inconsistent version. So editing is an important activity in generating quality content. That's why editors and editing team should be empowered to take responsibility and create quality output that reflect the best of their judgement. Then readers can chose among consistent branches.
If I snub RK, or at least his edit on a particular branch, I snub all continuations of those edits. Doing this creates no inconsistency - it eliminates from view the inevitable offended responses to RK's shenanigans. If I consider RK as an inconsistent editor - sometimes producing signal, sometimes spiralling into noise - and so I snub just particular branches - I get the benefit of followups to his signal edits without seeing more than the first continuation of his noise edits. This same strategy would allow me to interact with anyone whose edits were contentious enough to give rise to heated responses. Contrariwise, if the editor is RA or any vandal/spammer, I'd kill all their continuations preemptively - and that would include all followups to their edits. This does make a fine point when it comes to merges; if an RK edit led to noise, but then a gnome skilled in diplomacy, say DM, healed the noise, I'd certainly like to see the result. But this is a simple matter of snub-logic - I may create a "white-list" in my snub file whose continuations I'd always experience, even in the case of a prior snub. In de-snubbing such a continuation I would have to experience all the edits on the forgoing branch(es), for consistency, just as you say. I'd be putting a great deal of trust in the healing gnome ... but if it turned up their diplomatic skills didn't merit (sorry!) that trust I could take them out of my white-list without further effect.
If, after a branching, two teams discover they can later converge, they can merge the points of view. This is to be done freely, it's not the business of any software mechanism to impose neither branching nor lack of branching, neither warfare, nor rapprochement. The software mechanism is there to ensure that the marketplace is free, and no group can take prisoners (as for example is the current case with RK). I do not care what's the characeristic iof the graph of groups, friendships, coteries, killfiles and other such things will be. There can be a bazzar of tiny groups, or there can be a few big groups with dominant authority, competing with each other. The software mechanism should not care. It will be whatever wiki readers and wiki contributors will want. If the software doesn't allow this freedom, people will vote with their feet anyways, as they actually did. --Costin
But once your editors form their teams, that constrains the structure of the resulting content, doesn't it?
No, you can be a member of as many teams as you wish.
Unless they ban you?
The fact that you are a member of a team does not automatically branch your edits towards your team. You have to manually select when and if you want to create an "edited" branch.
This bit isn't clear to me. What does "branch toward your team" mean? Can't you tag a branch with any number of team identifiers - presuming you're on the identified teams? And does "creating an edited branch" mean that branch and all its continuations are forever restricted to edits by its respective team(s)?''
Actually, I have not thought of this feature, but it would be possible to add this behavior (creating a version that is part of several branches). The behavior vis-a-vis outsiders depends on that team's settings. If the team doesn't change anything the default is that the branches are just labels to distinguish from the global version, which means everybody can edit on that branch. This "label" should be enough to deter abusers, but if somebody is actively preventing a team from developing that branch, than that somebody can be explicitly banned.
Just to be clear, this is still page-oriented, right? You don't have your teams banning folk on multiple pages simultaneously?
No, it's not page oriented, a team ban if for all the pages branched by that team. KISS and all that jazz. One thing though, within one branch you have the possibility to tag "released" versions, which means the reader will generally see by default the released version while susequent versions will be the team (and their collaborators) wikipad, until a team member decides a subsequent version is ready for another release. So for somebody to get banned he has to work really hard at messing with other people's work, knowing full well that the best he can achieve is a team ban and ditched reputation. Highly unlikely. I bet somebody like RK will create his own team, or get along with one of the established teams, etc.
I know you really want this to be NoPolitics?, but it seems like HighPolitics? to me. People negotiating behind the scenes to coordinate teams, arrange coups, schisms, juntas, rebellions, and so on. I'm honestly trying to see WCP as promoting harmony and signal - but mostly what I'm hearing is a vehicle for polarization and contention.
Teams and Consensus, again
When you edit something on a team's branch you agree that they may have (at their discretion) the ultimate saying into how that branch will look like. Of course, even if you create a version 1000 on branch team_X, and they override you creating version 1001 rejecting your comments, nobody prevents you from copying and pasting version 1000 into your branch or into another team's branch.
How does a team reach such a decision? Do they vote or is it at the team leader's discretion?
No, there's no vote. Within one team full SoftSecurity is in effect. Any decision taken by a team member represents the team. Probably in extreme cases when consensus is ruined within a team, the team should be discontinued. So better be careful whom you chose as your friends and accept in your team. One of the main goal of wcp is NoPolitics?, and KISS.
So, in the case of RK, team members butt heads and create noise steward-style while they try to arrange a quiet deposition? This doesn't sound like it's gonna be pretty ...
Why continuations?
I guess I don't get why is this "continuation" stuff needed at all.
To put more choices in the lap of the readers, to simplify the mechanism, to leverage existing tools, to encourage merging as a communal refactoring discipline, and probably a bunch of other things I can't predict because there is no ManaMana to experiment with yet.
Does it occur to you that you shouldn't make the reader work for a reading (i.e. make choices) unless positively absolutely have to ?
KillFile(s) worked great on UseNet. It was ThreadMess killed the beast. NuffSaid.
Red Tape and Social Distinctions
To my mind you're introducing a bureaucratic mechanism - teams, leaders, and banning - and so enforcing a rigid social distinction. Feudalism, in fact. None of this is necessary when ordinary SCM semantics provide a well tried and general alternative.
There's nothing bureaucratic, it's just a mechanism that is available (not imposed) for people to use freely, as they see fit. It's marketplace. You cannot impose virtue on people. If people use these mechanisms well, they will be rewarded with a vibrant wiki, if people use this mechanism to abuse or to isolate from each other and perpetuate prejudices, the wiki will suck. Virtue cannot arise from software. Presumably, given the premises underlying SoftSecurity and WikiDesignPrinciples, there will be many more peopl who will work nicely. And if this is what pleases WikiReaders those people will be rewarded. And I tend to think that SCM semantics is not a tried and true solution for the problems of wikis, they are a solution for a fundamentally different problem. --Costin
Many things are possible. I think we've formed a clearer picture of the distinctions between these two ideas - and I think we agree they are different. Let's build both and see how things pan out.
Snubbing vs. Teaming
ManaMana neither needs nor uses ranking - though it's likely someone will still generate ranking scores by running statistics on the various snubfiles.
There are legitimate differences of opinion and ComfortableSpaceForDisagreement that are not the subject of snub files, but may be a matter of preferences. For example, I wouldn't care to hit every time I read something about types to see the point of view that static typing is broken and dynamic typing is the way to go. But on the other hand, I wouldn't want to put dynamic typing advocates in my kill file.
Not certain I understand this one. Clarify?
Say you have a page static_vs_dynamic_typing. There are reasonable static typing advocates and there are reasonable dynamic typing advocates. They don't have to killfile each other, yet they need to work separately to present their point of view as clearly as possible and let the readers chose. So there will be two branches on the static_vs_dynamic page one belonging to the_static_team, other belonging to the_dynamic_team. Readers will be directed first to the team they prefer, or to the team that is the most popular, but even a malevolent team cannot hide the existence of an opposite point of view.
How about a third team representing TOP, and a fourth representing COP, and many members flitting between the various camps, bringing news of new advances? I actually like all these ideas and make the best use of them I can depending on context. Do you believe I am unusual in this?
It all depends on the marketplace of idea. If topmind feels that his point of view is interesting enough and atracts readers and colaborators, then he can bite the bullet and create his own "label" and his own branches of important topics. He can do that foolishly and later his branches could wither away for lack of interest. A third possibility for topmind is that he can submit his contribution to a third editorial team, say "the_balance_and_open_minded_gnomes", and those will edit it appropriately and presnted it in a balanced way in contrast with other approaches. And the reader is free to choose. If you Pete, think that a wiki should evolve along the lines of "the_balance_and_open_minded_gnomes", then you can help them, spread the word around, be part of them. If this perspective on the world of wikis will be the most meritorious, then it will be without anybody trying to impose his pre-conceived vision on the wiki at large, through politics, maneuvering, sometimes abuse as it happens now.
I am certainly sympathetic to your intent! But again I see your mechanism as unnecessary. People express on wikis as individuals; teams are temporary and opportunistic affairs and need not be labelled or treated as first-order objects. To do so introduces ontologies that will generate their own tensions and compromises.
Killfile Implementation
And you still haven't answered my question on killfiles. If the mechanisms are equivalent as you suggest, how do you implement those?
You as user Pete, will put user Costin in your killfile. Therefore you won't see any branches under the user Costin's authority.
And what if I want to see branches that are edited by members of your team, but not you? You won't be able to [under WCP], because there's no such thing, unless those members make up a separate team that excludes me. The number of sub-cliques of a team increases exponentially with the number of members of the team. The PatternOfBabel. This is why merging is so important to me.
I don't mean to re-open this issue, but after reading this whole page, not once did I see any mention of official position come up. For example, C2, whose full name is Portland Pattern Repository, is a valuable source for software (anti-)patterns. Relative objectivity is of paramount importance here; most of the content on this wiki is hardly 100% objective, but it is good enough through the efforts of many who read and edit content. The resulting content is a consensus (contrary to Costin's concerns that it doesn't exist) by definition. Yet, in either ManaMana or WikiChangeProposal, there is serious cause for concern of precisely which viewpoint is considered the most widely accepted viewpoint of the site. Can we guarantee that a WikiGnome will remain objective enough to maintain the relative consensus?
For example, suppose I suggest UseParserGeneratorsToParseConfigFiles? as a software anti-pattern. I firmly believe it is, when you consider how trivial it is to map most any configuration file format into RPN. However, not everyone feels this way, and will debate it. Some of the debates will inevitably get quite heated, and this forms a scism in the views of the page. TopMind will want to advocate a table-oriented alternative. I'm all about ForthLanguage. Someone like Ward might advocate the use of Perl or Lua as a standard configuration interpreter. MartinFowler will prefer DSLs purpose built. The thing is, to advocate their views to others, they'll post their respective views on their respective blogs or whatever. This is because everyone sees what they want to see, which to me seems unrealistic and dishonest. "See? It's on C2, so it must be valid, right?" And, why shouldn't I? I'm pro-Forth, so why shouldn't I post my view on my blog?
Now, the question is, which view is C2's own view? It seems to me that the WikiGnome is responsible for determining this, which means that the official view ends up being the gnome's view. Isn't this the exact opposite of what is intended with these proposals? I honestly have to admit that a WikiStoneSociety would excel here, and neither ManaMana nor WikiChangeProposal will adequately resolve the issue. When a page is edited, a preference item for that edit is listed. RecentChanges lists not individual page edits, but rather, recently changed auctions. Only officers of the wiki may vote, and stones are allocated meritocratically based on editorial content and peer review. Anyone can edit or create a page; however, folks only get stones/merit by how often their changes are voted into quanta by other, established users. In this way, wiki becomes peer reviewed, while still being free for anyone to contribute at any time.
The only disadvantage that I can immediately think of is that you don't have the instant gratification of responding to other contributors same-day in a variation of ThreadMess I like to call ChatMess.
This necessarily means, by the way, that more real-time discussions and banter should occur on so-called "Discussion" pages. E.g., for AnyGivenTopic, the system is smart enough to not allow someone to enable peer-review mode for AnyGivenTopicDiscussion. This will enable folks to duke it out in a page that is clearly labeled as being a potential mess to the reader. Go ahead and do your edit wars there, if you must. Just let me, as a user, add SharkBot (or anyone/anything else) to a configuration setting to filter it out of the RecentChanges.
In summary, since I see these things as attempts to solve both EditWar issues as well as establish improved editorial signal:
EditText of this page
(last edited August 20, 2014)
or FindPage with title or text search