From WikiWikiSystemNotice:
I've abandoned the notion of MinorEdits. This was introduced when HelmutLeitner undertook the awesome task of reading every wiki page, found a lot of little typos along the way and didn't want to pollute RecentChanges with their correction. It is not saving us from pollution and just adds complexity when trying to understand posting activity. -- WardCunningham
That's probably not a good idea in relation to those who introduce commercial spam. It was convenient to remove such spam using a minor edit. The spammer's ip address then remained in RecentChanges. Also, from time to time, someone changes the name of a page and can change all the references to it using minor edits, instead of clogging up RecentChanges. Removing minor edits will simply lead to more editing of RecentChanges to alter/remove entries there. A similar point applies when a spelling error is corrected - such corrections can easily affect 20 - 100 pages at a time. I don't recall anyone complaining about the minor edits feature, and it is present in many other wikis and has been requested as a feature on some wikis which do not have it.
Some points:
Could minor edits be indicated on RecentChanges somehow, perhaps something like the way WikiPedia does it?
I've been using minor edits a lot lately to remove spam. I figured that this would minimize noise on RecentChanges, and make it less obvious to a spammer that his work had just been undone. However, I realize that the feature might cause problems in other areas. -- DanMuller
Thanks for disabling MinorEdits. I think this is definitely a good thing. By the way: using an edit to remove spam is not a good idea, since one cannot see who edited the page last. If you want to check the changes for reasonableness, you soon gets a list of "trusted" ip addresses which you don't have to check. -- ThomasHolenstein?
I want to know what other pages the spammer edited, not who edited a page last. Minor editing to remove spam made that easier.
Maybe there should be support for automatic refactorings? Some of the typical uses of MinorEdits are good candidates for automatic refactoring support. (page renames are a good example)
I just peeked at NewRecentChanges and found it usable... but hardly friendly. I think the functionality on http:RecentChanges and http:quickChanges?days=1 should be made more accessible. -- BenTremblay
Ward, can you reintroduce MinorEdit, now that wiki is under supervision? In absence of that, wiki is pretty much unreadable these days (or readable but with a lot of wasted effort). -- CostinCozianu
Won't http://c2.com/cgi/RecentChanges?days=1&min=100 work for you? I find it pretty easy to spot the minor edits, there, and it doesn't require the editor to remember to check the box.)
Really? Can anyone explain the differences that using "min=100" causes?
See the explanation on the NewRecentChanges page. If a page doesn't have any edits with > 100 characters size delta in the queried time range (given with the 'days' parameter), then the entire history for that page is hidden. If there is one qualifying edit in the given time range, then the entire history for that page is displayed.
I've read the theory, but the results don't seem to be in accord with it. For example, why does page order change? Also, how on earth does hiding edits as described allow one to spot minor edits?
It looks like the results are sorted based on the timestamp of the most recent edit that has > min characters delta, which is not necessarily the most recent edit overall for each page. To verify this, look at the filtered output and go through each listing in sequence. Find the most recent edit for each page that has > min characters delta. Look at the timestamp for each of those edits. Verify that those timestamps are in decreasing order.
NewRecentChanges doesn't allow one to spot only minor edits. Can you confirm that is what you want to do? If so, why? If you want to go back and check the minor edits for possible acts of vandalism, then surely you will want to check the major edits as well. The MinorEdits feature mainly served the purpose of hiding minor edits from users who weren't concerned with them. NewRecentChanges still meets that need.
Still, http://c2.com/cgi/RecentChanges?days=1 is relatively a pain and an unnecessary usability hurdle. I think MinorEdit was a very good feature for both readers and gnomes and Ward had to disable only because of abuse. Now if abuse is relatively under control I was hoping we can get it back, but it's just a suggestion.
MinorEdits is an outdated tool. NewRecentChanges shows each and every change whether minor or not, and one can choose to ignore changes they feel are minor. MinorEdits was a way to hide small edit changes, both good and bad. The only use I see for MinorEdits now, is for those who want to sneak by changes without others noticing, and this is perhaps not a good thing. Really, in my opinion, even RecentChanges would be now outdated if it wasn't needed for archive history. Of course, NewRecentChanges was much more useful before it was hack edited.
RecentChanges and the old MinorEdits are not outdated in comparison with NewRecentChanges. What is significant about each is what patterns the user can spot at a glance, without mouse hovers and clicks.
See also TooMinorEditsConsideredHarmful