Therefore, flag EditCategories by adding them to the summary:
[CopyEdit: Corrected grammar.] [PageTranslation: Translation of EditCategories.] [WikiSpam: Revert to r34.]
Often, an update will include several types of change; each can be included and described separately:
[CopyEdit: Corrected grammar] [WikiSpam: Reverted to r17]
While categories as described are non-overlapping, the system can also be used for tagging (and filtering out) content that is objectively irrelevant for known portions of the audience, such as changes made in a foreign language. To enhance this usage, several EditCategories can be combined to narrow the audience for a change down further:
[fr,CopyEdit: Grammaire améliorée] [WikiSpam: Spam enlevé]
EditCategories are an attempt to increase the relevance of RecentChanges for a wider audience. Unlike PageClusters, they are not an attempt to preserve GlobalResources; unlike CategoryFilteredRecentChanges, they do not shoehorn existing categorization into an inappropriate usage. EditCategories supersede MinorEdits, and have a similar vulnerability to abuse. If DigestedSummary is used, inappropriate categorization can and should be corrected by PeerReview.
EditCategories primarily allow RecentChanges to support two audiences: the "interested reader", looking for significant new content plus precis; and the PeerReviewer, catching the mistakes of fellow editors in technical aspects, such as copy-editing.
Tagging has also turned out to be a great way to identify unsupported interests that emerge from the bottom-up, such as the fr (changes written in French) and PageTranslation (direct translation from one language to another) tags. We will always need to keep learning about needed functions. 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. The next step is to consider how to support those interests more directly. Overt technology, like MandrakeClubImplementation and OddMuse's language detection, are one possibility; improving the tagging system to support both PeerReview and EnlargeSpace may be another.
Chris, I made an edit to GreyAlbum, and now it does not show up since StephenGilbert changed the digest to [CopyEdit:...]. This behaviour is inconsistent with the behaviour of MinorEdit. The correct behaviour would to display the last change within the time period of RecentChanges that had an non-filtered DigestedSummary. I corrected this instance, but I can show you again with the SandBox. -- SunirShah
What's the greater evil? Spam or hiding community activity? -- SunirShah
Well, it wasn't PeerReview. Presumably, only two people knew about the edit, only two people can detect the error. This also means that an attacker can wipe out our RecentChanges (in whole or in part) by editing all the DigestedSummary entries. However, that being said, the spammers can also attack the other system. What's needed is a way to know that you are missing something. Either having a count of masked entries by EditCategory (e.g. [ ] CopyEdit (4), [ ] WikiSpam (3)) and/or a list of pages that have changed in the RecentChanges period but are not shown, but without any additional meta information, perhaps in a column on the right (admittedly, graphic design is not my forté). -- SunirShah
Essentially, the wiki looks dead to non-expert users if entries start disappearing. The best way to attract new people is to ShowLife?. One way to ShowLife? is through PageChurn. Spammers, like earthworms, have a useful purpose in turning over soil. (Hiding activity is my main objection to removing the last edit timestamp as well.) -- SunirShah
Actually, the correct behavour would have been for me to learn how the edit categories worked. I didn't realize at the time that I could put in a [CopyEdit] comment without wiping out the current edit summary. We may need to clarify the documentation. -- StephenGilbert
Could the brief explanation on the edit page do with clarifying? Hiding the correct description of the behaviour BehindTheFold? may not be ideal, if it's as confusing as newbies often appear to find it. I've been thinking about something like: "Portions of the digest bracketed with [CopyEdit: …] or [WikiSpam: …] will be hidden by default on RecentChanges. Bracketing the entire digest will hide the edit completely." Would that work better? -- ChrisPurcell
That's a better explanation. However, I think newbies are going to find the DigestedSummary confusing no matter how good the explanation is. Only experience will cure it. -- StephenGilbert
I think EditCategories is a bad feature. It exposes the system design to the user and makes the user do a lot of thinking to get the right behaviour. If the fundamental issue is that RecentChanges is flooded with minor changes, the right idea is to have a way of marking a change as minor. We used to have a checkbox for this. However, this overrode the DigestedSummary.
A simpler solution is to have two digest summary. One for the overall major changes, and one for any minor changes that don't need to show up in RecentChanges. Also it should be clear the summary will show up in RecentChanges.
Update the summary of the recent changes to show in RecentChanges:
EditCategories (7 changes) by SunirShah, JohnDoe?, JaneRoe? A debate of whether or not EditCategories are worthwhile continues with new ideas and designs.
Is this a minor update not worth showing in RecentChanges? What kind is it ______________________
We can use an Autocomplete combo box for minor updates. For example https://material-ui.com/components/autocomplete/