121

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.

9
  • 12
    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.
    – user102937
    Feb 16, 2012 at 18:00
  • 1
    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. Feb 16, 2012 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.
    – user102937
    Feb 16, 2012 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, 2012 at 3:27
  • 9
    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. Feb 17, 2012 at 17:06
  • 2
    @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. Feb 19, 2012 at 17:05
  • Do y'all have a group that compares SE features with other sites, such as Wikipedia? There is a feature at Wikipedia called 'rollback'. Admins and other enabled users can 'rollback' editor actions to a certain point in the past. Enthusiasm comes in many forms and, um, urgencies... It's really quite nice to not have to be screaming and purple when you approach someone about their last 177 edits.
    – Shenme
    Apr 2, 2015 at 23:28
  • 1
    There is a list of 50 or so related questions in this post: The system for adding a new tag to old questions is broken Aug 26, 2022 at 5:26
  • 1
    "Bumping the question allows the community to review the edit" - this doesn't apply well for highly active communities, such as Mathematics.SE, where the front page only goes back about 4 hours due to a high rate of activity. Only a small percentage of the community will ever see such bumps on highly active communities, compounded by the fact that some topic (tags) total number of posts represent less than 5% of the total number of all posts in a popular community.
    – rcgldr
    Mar 8 at 0:57

3 Answers 3

45
+200

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
6
  • 1
    So a minor edit would require more approval? That seems backward. And why would the editor tick the minor edit box? Feb 19, 2012 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. Feb 20, 2012 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, 2012 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. Feb 27, 2012 at 6:37
  • Note, the "minor edit" checkbox is very useful but used very inconsistently on most Wikimedia projects. Some just mark all minor, some nothing, etc. Would probably be useful to study their patterns better and see what can be learnt.
    – Nemo
    May 2, 2015 at 7:39
  • @Gilles'SO-stopbeingevil' What if, after 1 review approved as minor, the edit were to go through but not bump the question and stay in the queue, and then a second approve-as-minor review would remove it from the queue? Jun 22, 2020 at 23:56
11
+25

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

2
  • 3
    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. Feb 27, 2012 at 7:28
  • 2
    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? Feb 27, 2012 at 8:45
3

It should be our goal to have the best quality of both questions and answers, not only in terms of content but also in presentation.

Consider the number of items that could be improved in quality by corrections to spelling or grammar that don't affect their actual meaning.

  • Where I don't have sufficient reputation, I almost always refrain from making the improvement to avoid bothering those that have to approve it.
  • Where I do have sufficient reputation, I sometimes refrain because I don't want to bump the item, especially if I'm correcting several at the same time.

Would it not solve the problem for the vast majority of cases to put beside the Save Edits button, a Save Without Bumping button?

Even if this cosmetics-only button were implemented for users with pre-approved editing privileges (over 2000 reputation I think), it would certainly increase the number of improvements that get made. And that would be good.

You must log in to answer this question.

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