What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 122 Stack Exchange communities.

Every edit, no matter how minor, bumps a question to the frontpage of an SE site. This behaviour is important to allow the community to review edits, but it also creates significant problems when a lot of edits are performed at once. What I propose is to allow minor edits that are not bumped to the frontpage. There is one huge and some minor problems with idea:

  • Bumping the question allows the community to review the edit, without review a user could edit obscenities into old posts without anyone noticing it for a while
  • Having users mark their edit as minor (e.g. with a checkbox) adds clutter to the edit page and might confuse users
  • A user going onto a misguided edit spree is very visible now that the edits are all on the frontpage, if they are not bumped the edit spree will not be caught as easily while it's still ongoing.

So, why would we want to change the bumping behaviour and allow non-bumping minor edits?

The problem with the current bump-always approach

The current behaviour causes significant problems when a lot of edits are performed in a small amount of time. The edits tend to completely overwhelm the homepage, drowning out the newer questions on there and depriving them of the attention they deserve. On slower sites such an edit-spree can easily break the frontpage for more than a day, many SE sites have a pretty low question volume.

It also makes bigger retagging options a pain, you have to perform them in small batches if you want to avoid breaking the frontpage entirely.

Very large mass edits also obliviate the main reason why edits are bumped to the frontpage, once the mass edit is larger than the frontpage capacity, most users likely won't review the changes that were made. The edits are off the frontpage again before someone takes the time to check if they actually improve the post.

Bumping to the frontpage is also not the most efficient way of ensuring that edits get reviewed. To actually see what was changed in an edit you have to explicitly click on the edit history, something I suspect most users generally don't do. So if an edit makes a post just slightly worse, but doesn't deface it completely, it might be easily missed by the users looking at the post.

Solutions to the drawbacks of allowing non-bumping edits

Allow for adequate review of minor edits

We already have a tool for reviewing posts that are likely to deserve some attention, the /review page. It has received significant attention recently, so we should make use of this tool to provide the necessary peer review of minor edits.

Minor edits should go into a tab on the /review page, this would allow the community to review them even when they're not bumped to the frontpage. The reviewing should work similar to the other review tabs, once enough experienced users have reviewed the edit, it should be considered a good edit and removed from the list.

Another improvement would be to directly show the edit diff there, not just the post itself. This would make it quicker to see what the edit actually changed. A dedicated interface for reviewing edits would be far more effective, and we already have one for the suggested edits, so all the needed parts should already be there.

Make the minor edit detection automatic, not a checkbox

The determination which edits are minor should be entirely automated, avoiding the additional clutter of an extra checkbox on the edit page. I think it should be possible to define a few simple rules that determine whether an edit is minor.

If an edit fulfills any of the following criteria I would consider it minor:

  • It is only a retag
  • It only changes the title
  • It changes less than x characters of the post

An additional improvement of the detection rules would be to distinguish between continuous changed characters and single-character edits. An edit that changes only a single character at a time at many places in a post is likely just fixing spelling, an edit that changes the same number of characters by adding another sentence might alter the meaning of the post more significantly.

Allow mods to "rewind" user actions

When moderators see on the frontpage that a user is performing a misguided mass edit, it is likely already too late and a lot of damage is already done. The easiest way to limit the impact of such misguided or malicious mass edits would be to allow moderators to undo all edits of a certain user in a specific timeframe at once.

Side effect on intentional bumping

As Adam Davis mentioned in a comment, using edits to bump your question in order to get some more attention for it is a common practice. This would obviously be affected significantly by this change.

My take on this practice was always that you were free to bump your questions, but the edits should actually be reasonably substantial. They should ideally represent your continuing efforts of solving the problem yourself and add more information to your question. So in this regard I think the change would actually be positive as it would encourage users to make more substantial changes when they want to bump their questions. It can be obviously gamed by just making some rearrangements in the question to fake a substantial edit, but the current system has even less protection against gaming it, the only one is the automatic CW conversion.

The automatic CW conversion after 10 edits is not a good solution to preventing excessive bumping, it's more an ugly hack that misuses a feature meant for something else entirely. If minor edits wouldn't bump a post and also wouldn't count against the CW threshold, it would drastically reduce the number of times the automatic conversion would kick in. It might even obsolete it as a mechanism against excessive bumping entirely.

This change would likely drastically reduce the amount of bumping new questions receive, it might make sense to increase the amount of bumping the community user does to balance that. Community could bump questions that haven't received much attention once much earlier in addition to the current bumping behaviour.

share|improve this question
5  
Worth noting: On Stack Overflow, a "proportional bump" happens when an edit is made. That is, an algorithm is applied that determines the significance of the edit (probably in terms of the amount of text edited), and decides what precedence is applied to the bump relative to other, newer questions on the front page. I don't know if that's how it works on the smaller sites, but it's less effective there because, when edits take place on one of the smaller sites, that's typically the only activity that is occurring at that moment, and so the bumping effect is more noticeable. –  Robert Harvey Feb 16 '12 at 18:00
    
Didn't know about that, though I wonder where to are the questions bumped on SO? The frontpage operates in a completely different way on SO than on all the other SE sites. –  Mad Scientist Feb 16 '12 at 18:24
    
The code could be different. The main point is that, on the slower SE sites, there is less material to "mix" with. On SO, edited questions only get bumped to the top of the page if it's a "big" edit, and they don't stay there long. –  Robert Harvey Feb 16 '12 at 18:28
    
I agree with this, but I'm worried about an algorithm deciding what's important and what's not. Perhaps have a checkbox for minor edits appear at 5k? –  John Feb 17 '12 at 3:27
6  
By changing a single "word", you can replace an image (http://i.stack.imgur.com/... stays the same). This can either be a very minor, cosmetic change, or completely change a post's contents. I don't think that it's possible to determine whether an edit is minor automatically with any reliability. –  Daniel Beck Feb 17 '12 at 17:06
3  
One issue you don't address is that bumping is a feature of editing, and we do allow users to perform minor edits in order to bump their question to the front page. You should consider how your proposal affects that feature. –  Adam Davis Feb 17 '12 at 17:51
    
@AdamDavis I've added a section about that to my proposal –  Mad Scientist Feb 19 '12 at 17:00
1  
@DanielBeck Changes inside urls or code could be excluded from being declared minor, my ideas for automatic detection were not meant to cover all possibilities. The filter should err on the side of declaring an edit a major one if there is any doubt. –  Mad Scientist Feb 19 '12 at 17:05
add comment

2 Answers

I agree that we need a "minor edit" feature, and that it should use the /review facilities. I'd prefer another approach though, since I don't think a single checkbox is overloading the UI. We have community wiki already, and it's not that difficult to handle.

The following is taken from an earlier post, with sections in square brackets added in this version.


Give users the option to check "This is a minor edit" when editing.

Atlassian Confluence wiki software does not notify others about an edit in this case. For us, the equivalent action is to not put the post on the front page.

I am aware that Jeff rejected this idea before, but in the context of hiding these edits, as they were too insubstantial. My suggestion works differently: I'd use /review and a suggested edits mechanism to allow community review without pushing the topics to the front page.


For all users, checking the minor edit checkmark this will place the edit in review, and requires two [on sites with usually one reviewer, maybe more on SO] high-rep users to decide:

  • This really is a minor edit
  • This is a bad edit or a major change to the post's contents

It could have the following options for review actions:

  • It really is a minor edit
  • It's a useful, major edit, handled just like approval of a regular edit: Put on front page
  • Reject, handled just like rejection of a regular edit

If all three (the original editor and 2+ reviewers) agree that the edit is useful and minor, it will be applied but not push the topic to the front page, as sufficient community review already happened.

[If at least one reviewer thinks it's useful but major, it will still bump.]

This way, minor grammar/spelling edits, as well as image reuploads will not pollute the front page, but will still happen after reviews.

To prevent abuse of this new feature, any of the following could also be implemented:

  • These edits do not award reputation
  • These edits do not count towards any of the editor badges
  • These edits count towards new cleanup themed badges
share|improve this answer
1  
So a minor edit would require more approval? That seems backward. And why would the editor tick the minor edit box? –  Gilles Feb 19 '12 at 21:45
2  
@gilles if the first reviewer approves but thinks its major, it's the same as a regular suggestion and stops there, likewise with rejection. It requires more approval since not bumping takes away review by other random users when the topic shows up at the front page. Reviewers who intend to only change insignificant things (obvious typo, image reupload, code indentation perhaps) can tick the box to prevent front page flooding. They're not forced by the feature, and every site community can decide what is expected behaviour for editors. –  Daniel Beck Feb 20 '12 at 5:27
    
Daniel, I think you mischaracterize the objections to a "minor edit" checkbox: every time this has been proposed, it's been suggested as a solution to the problems of too many trivial revisions polluting revision history OR too many bumped questions - but remove the "too many" qualification, and both of these behaviors are by design: edits (unlike, say, edits on Wikipedia) are always intended to do as much as possible, and all edits are meant for community review. If folks get upset because you're filling the front page with too many inconsequential edits, the solution is: STOP DOING THAT. –  Shog9 Feb 27 '12 at 2:40
2  
@Shog great idea in theory. With many suggested edits on SU the problem is that they are useful but very specific. Users fix the most obvious problem and move on, be it just the grammar, just the indentation of code, or just removing thanks at the end. The result is rarely a really good post, but the changes are significant enough inmost cases to be accepted IMO. None of these is significant enough to bump. Note that what might work elsewhere might not work for SO due to volume, but they already have e.g. Two. Reviewers, so different behaviour might be an option if necessary. –  Daniel Beck Feb 27 '12 at 6:37
add comment

It also makes bigger retagging options a pain, you have to perform them in small batches if you want to avoid breaking the frontpage entirely.

If you're re-tagging a vast number of questions, doing it in small batches is probably a good idea anyway. Take the opportunity to perform other helpful edits instead of trying to be a human machine.

Alternately, use the tools already in the system to merge or rename tags en masse rather than editing them one at a time. These are limited to moderators to prevent abuse, and do not bump or modify the affected questions' revision histories.

If neither of these options work for some reason, ask for help from the SE staff. We might be able to suggest an alternate method, or simply do it ourselves. If that becomes too much of burden, it's possible we'll consider more advanced retagging tools.

If an edit fulfills any of the following criteria I would consider it minor:

  • It is only a retag
  • It only changes the title
  • It changes less than x characters of the post

Uh... You're suggesting that if I post a question, come back 5 minutes later and notice a small typo somewhere and correct it, I should have to wait for someone to approve that edit, while re-writing the entire question goes through immediately?

Or if I see a new question asked, and jump in to add the missing tags (because... there are always missing tags), that change also sits in the queue?

This would almost certainly cause the edit queue to explode, at least on the busier sites. Of course, on the quieter sites, suggested edits often sit around for a good while already, waiting for a moderator or one of the few high-rep users to find them. A post with a pending edit can't be edited by anyone else... So now that little tag or typo fix change prevents anyone from jumping in to fix the formatting, or the numerous spelling and punctuation errors.

And I'm not even gonna get started on the problems with using "x characters changed" as a metric for detecting "minor" edits, since that's already been covered in the comments. If you can come up with an algorithm for differentiating between small benign changes and small but critical changes... Let's see it.

The "rewind" idea might have some merit; see also: Provide a bulk-rollback mechanism for all features that can be bulk-approved

share|improve this answer
1  
I don't meant that the edits should be treated like suggested edits, they would take direct effect like all edits for a 2k user. I mean review here like 2k edits are reviewed now, if someone notices you making a bad edit, they'll roll back. And I think you underestimate how few retags you can do on slower sites without seriously disturbing the frontpage for days. –  Mad Scientist Feb 27 '12 at 7:28
    
No algorithm would be able to distinguish small benign from malicious edits, but that's also not necessary. The minor edits are still getting reviewed. I don't have the data, but how good is the reviewing of such edits on the frontpage currently anyway? How many users actually take a look at the edit history of bumped posts and check the edit? If you only look at the post itself, not the edit how would you notice a minor, but harmful edit? –  Mad Scientist Feb 27 '12 at 8:45
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .