[Home]EditCategoriesBrainstorm

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Brainstorm page, rework useful content into EditCategories.

Problems

Current problems with the system, both as implemented and in general:

Comments

I've started on an Oddmuse extension to reimplement this feature in case we do move from Usemod to Oddmuse. [1] -- AlexSchroeder

Alternative edit form/mechanical implementation

I find the current code hard to understand, and the implementation hard to use here on Meatball. I don't like it, it's too complex for my simple, light-weight usage of a wiki. If we decide to dump it or replace it with something easier to understand, this might be the time to do it.

Here's a simpler proposal, based on the code I have:

  1. All clusters from the summary are collected. Example: [tech,fr] Nouvelle page sur le spam [CopyEdit] grammaire -> three clusters: tech, fr, CopyEdit, without any special grouping.
  2. If any of the clusters you chose on RecentChanges matches, you see the edit.

The features we currently have and which would be missing:

  1. The edit summary remains untouched. The current implementation shows you the parts of the summary that match what you are looking for. If you want to see copy edits only, the summary reads [CopyEdit] grammaire.
  2. No special groupings. The current implementation would not show the edit if you want to see either the tech or the fr cluster. You would only see the edit if you wanted to see both clusters.

-- AlexSchroeder

The code is hard to understand because I hacked it together to get things underway, using manic Perl (tm). It's not meant to be maintainable or understandable - sorry!

The "special" (AND) grouping is specifically in place to allow French pages to be CopyEdited without disturbing English-speaking peer reviewers or French-speaking visitors, at Helmut's request. Originally there was no comma support.

I find filtering out of unwanted parts of summaries very helpful, because then I don't need to filter them out mentally. If I want to see the major changes to MB, I don't get tedious CopyEdit trivia. Also, with this manic spamming, dropping WikiSpam information from pages being actively worked on is a huge bonus.

Do you find the RecentChanges front-end hard to use, or the way you must structure the digest hard to use? -- ChrisPurcell

OddMuse has language detection that may obviate a lot of this. -- SunirShah

Sure, in this case. I'm all for removing the extra baggage if Helmut's happy with it. For the general case, though, it's worth noting that the EditCategories system is more general, and can be extended by users to any language, while the OddMuse system is hard-coded (and slightly hackish in the way it detects language IIRC). -- ChrisPurcell

Good question: The interface is easy once you know it. The problem is knowing how to read the result and knowing how to do the right thing. For example, I did not know about the summary munging until you explained it again. I just forgot about it, if I ever knew it. Or if you are writing a summary after a copy-edit -- do you remove the old copy-edit? One of the Wiki:WikiDesignPrinciples: "Overt - The formatted (and printed) output will suggest the input required to reproduce it." This is the problem for me: Given the problem, I know neither the input required of me, nor the expected output. What if we just put a list of checkboxes below the summary field when editing and above recent changes when listing them and use simple OR? That would "guide" users. -- AlexSchroeder

Perhaps a better solution, rather than throwing out the intra-digest filtration benefits of the current system, would be to come up with better markup? While all I can think of at the moment is something like [CopyEdit: Fixed some grammar], I'm sure there's a solution out there.

That would still lack the Overt quality -- you cannot use the system without reading a manual somewhere. We can add flexibility to my counter-proposal by having the checkboxes available controlled from a page (my code already does that). In order to offer the kind of power you ask for, I suggest we add a summary field per checkbox. Then the mental mapping is absolutely clear. This has the benefit of making it clearer what you need to do, if you want to provide a summary. Unfortunately it introduces so much choice again that it is difficult to decide what to do if you edit a page that already has some summary information filled in. Do you remove the old stuff? Do remove only one checkbox, all of them, do you append to the summary text, do you replace it? That problem is not really related to EditCategories, however. It's a problem with the DigestedSummary feature. If we keep those two features firmly separated in our discussion, that would help. So with respect to the edit categories, my counter proposal is now to offer a big textarea (three lines) for the general stuff and a summary field (one line) per edit category. (Internally we can still save this using the current format.) The edit categories are controlled by an editable page so it will be flexible. This solution looses the ability to AND certain categories.

Example:

Summary: Sunir and Alex provide feedback
CopyEdit: Corrected grammar
WikiSpam: Reverted to r17
[[fr]]:

In order to easy the digested summary problem, we could now offer the old summary as before, but always show empty edit categories.

-- AlexSchroeder

I don't believe an HTML design will be as Overt and effective as you portray it. (1) It would still need a manual to understand it in the first place; the only benefit would be quicker use later, which a single line of exposition can achieve for a good choice of markup. (2) The temptation would be to fill the Summary as well as the other fields, totally defeating the point.

No Wiki markup is so Overt as to not require a manual to remind one of it, so why worry about the summary field? -- ChrisPurcell

Argument about social and design values

Confounding factors. We made two major changes at once: the DigestedSummary and EditCategories. I think our problems learning how to use DigestedSummary are confounding the potential value of EditCategories. Also, edit categorization is not the same as page categorization. Categorization is not the same as languages. That is, the French language indication should be against the page, not the edit, and either derived like OddMuse or obvious from the space where they occur.

Social values. If we are filtering, that strongly suggests that the changes are happening within the wrong group of people. Consider the PeerPart of PeerReview. The community of people reviewing the changes form a social boundary that allows them to self-organize (my Wikimania 2005 [talk] was about this). Our filtering system disempowers the French speakers on the site by denying them attention by the decision makers. I want them to have control over themselves. I still think a MultilingualWiki is best achieved with separate wikis with a ChangeAggregator.

If the outcome of edit categorization is to eliminate a set of people from the community, I will subvert this by giving them a sibling community and subjugating my FirstServant role to them as well. However, the goal of edit categorization stated above is about the function of the change, not the type of person. So, let's consider the French changes a problem of social organization, and out of scope here. I seriously would prefer giving them a full SisterSite, and then consider how to grant them full attention in decision-making as peers rather than what is amounting to, I fear, second class citizens. WikiPedia enjoys this structure quite effectively.

Design values. A reasonable question then for this scope is how many functional types of changes are there? And then how much detail will be useful for the ReviewPart? And then, how often will we need a new code? And how many of these types can be reconstructed with better information architecture. For instance, the OddMuse spam system will make a lot of the spam reverts automatic.

We will always need to keep learning about needed functions. Therefore, I am still also strongly in favour of EditCategories. As people discover a new failure in our information architecture, they will use manual labour and CommunityExpectations to solve the problem, and EditCategories empowers people to do this. Hence, they are an ideal way to learn from real action. However, this is painful to preserve. Once the manual practice is well understood, we can think about restructuring our system to obviate the need for manual labour or cognitive work.

To reiterate some trival examples. A lot of CopyEdit tags suggest a MinorEdit checkbox to pave the path. Another more complex example would be a lot of PageTranslation tags that suggest we aren't handling multilingual issues correctly.

Thus the ideal solution is one that moves gradually from small manual labour towards more complex manual labour to new development that will DevolvePower over the wider information architecture (e.g. developing the ability to automatically create child wikis that are SisterSites, with aggregation of common resources). -- SunirShah

I'm just going to address the language question here. I'm not sure that the French subcommunity is disempowered by EditCategories; rather, there is a constant reminder that they exist, in the Fr category on the RecentChanges page. A sister community would have a separate RecentChanges that we may never visit, and newcomers may well never know about. I feel we are tied closer together now than we were when PageTranslation was hidden under the MinorEdit system, or than we would be with separate sites.

While I'm here, categorization is not the same as languages, but edits certainly can be classified by the language they are written in, with more validity than pages can. The smattering of bilingual pages - like CopyEdit - are testament to that. -- ChrisPurcell

It's disempowering because we don't tag changes with [en]. Obviously English is in power and French is not in power, and so we create a PricklyHedge to discourage French (manual labour). It's not intended, perhaps, but it is a consequence. My interpretation of the MeatballMission is that this is bad.

Note, we are having this discussion on their behalf, which is also bad, although we already had this discussion before. I thought we reached a consensus that we would do work to make them a SisterSite somehow (I really have to reread all of that discussion again). I agree that it's better than MinorEdit, but an even better solution is to promote them to a true sibling community, and then given them the same or more prominence in our global resources. EnlargeSpace! Bigger tent. -- SunirShah

Interesting: tagging English changes with [en] was exactly what I was thinking of proposing. The mechanics of how to pick a default language for a given page are interesting, and presumably off-topic while we struggle with the basics - I suggest we do not discuss them yet. Whether we choose to mark [en] or not, though, the categorization system can cope. The only questions would be in the user interface for such a venture - what categories to present by default and how to demonstrate alternatives - and again, I suggest we set them aside until the current crisis is resolved. -- ChrisPurcell

Right; more tags. ;) I think I can summarize my point (for the future refactorer) as "tagging has turned out to be a great way to identify unsupported interests that emerge from the bottom-up. The next step after that is to consider how to support those interests more directly." -- SunirShah

I'm unsure what the current status is. Are we at an impasse and need more information? -- AlexSchroeder

I'd like to continue with the current system unless it becomes clear we cannot simply tweak the formatting. I would like to try the markup suggested above, namely [CopyEdit: ... ] or [PageTranslation,fr: ...], though if Helmut responds that the OddMuse language system would suit his needs we don't need the AND pattern once we switch. (My arguments for all of this are above, if you missed them.) Is this information-gathering okay with you? -- ChrisPurcell

I've been enjoying Chris' efforts playing with RecentChanges. I sense we are having this discussion because, despite the fact we all have opinions, only one of us is implementing them. I would be greatly excited to see some alternative RecentChanges deployed. http://meatballwiki.org/wiki/action=rcsimple&all=1 provides a MachineInterface to a RecentChanges dump one can load in real time, even off-site. I recognize we are all primarily interested in what the default RecentChanges is, and I also recognize not everyone has time nor ability to do this work. However, that being said, I think since we are trying to radically alter RecentChanges to be more usable, the best way to solve the problem is to build several prototype alternatives and play with them all, moving ideas back and forth until we get something we like. (Anyone up for WikiCircles? ;) I don't propose we revert back to the old RecentChanges, though, just to head that off at the pass. A "crisis" is good for the blood. ;) -- SunirShah

I'll be away for at least a week, so I won't be working on this. Unfortunately the loop that constructs RecentChanges has changed a bit from Usemod to Oddmuse, so I can't just copy Chris' code over. -- AlexSchroeder

Unfortunately, the question at hand is in the Edit page interface, not the RecentChanges interface, so we can't simply have prototypes, we have to actually run them for a length of time and see how people adapt. Information gathering seems in order :)

I'd also love to take my CacheableCustomizability AJAX code and stick it on top of MB. It's entirely disjoint from the underlying engine (apart from some customization things), so that would be easily possible. Maybe later! -- ChrisPurcell

I've changed the pattern used, as promised. Hopefully that'll limit the number of newbie mistakes. Also no need for "prefix your change" any more - yay! -- ChrisPurcell

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: