MVP: Post editing

Codidact Platform Ideas
1

The new site will have psots. Those posts might hjave smoe typos. *Or things might occur to the author to add later. Other users might have ways to improve posts in the way the original author didn’t think of.

It would be helpful to have the ability to edit posts.

Proposal:

  • users should be able to edit their own posts (unless locked?)
  • other users should be able to edit posts, once they reach appropriate seniority

The wiki seed for this MVP proposal reads:

  • Anybody can edit. (Are edit reviews part of the MVP?) Reviews and/or minimum reputation is likely needed to avoid garbage edits and newbie edit wars. [1]

This also ties in with:

  • We should develop and maintain an editing culture. (source) [2]

Not MVP:

(personal view, please debate)

  • Proposed edits, and reviewing these proposals
  • Rollbacks (this may be trivial enough to implement that it can be MVP)
  • Automatic flagging of multiple edits/reverts
8 Likes
2

Yes. Editing is always necessary. We don’t want to put any limit on editing but the one thing we need to restrict is editing in the answer once finished (because it kind of ruins the point of a Q&A thread).

Yes. Insight from others is always helpful, and it helps maintain quality on the site. As for seniority - we should refrain from deciding exactly how we want to tackle seniority until we figure out how we want to tackle reputation, because the two play hand-in-hand.

Everyone should be able to suggest edits after they receive a trivial amount of “reputation” related to posting, probably the equivalent of posting one well-received question or one well-received answer. Just to prevent edit wars and spam.

Suggested edits should be MVP, because it’s going to be a large part of the system once we really get the ball rolling.

See above comments.

Rollbacks should be MVP but exclusive to site moderators, however we define those.

Probably not MVP but this would be a nice feature to have. Vandalism, while it hopefully won’t be a problem, needs to be handled efficiently.

Nice proposal! Overall, I agree with most of the points.

2 Likes
3

Stack Exchange allows anonymous suggested edits and it works well. There’s a bit of vandalism but the volume is manageable and they’re easy to sort out. It’s well worth it for the good ones, where someone has tried an almost-correct answer and suggests that little tweak that makes it actually correct.

3 Likes
4

One more minor thing (literally). There should be a “This is a minor edit” checkbox like on Wikipedia. Not a guarantee (since someone could make a major edit and still check that box) but I find it helpful if I want to review a bunch of edits on a post.

7 Likes
5

This is the greatest barrier to keeping lots of old posts updated, as otherwise the front page gets flooded and then people start complaining.

4 Likes
6

I think this is a good idea, however in my opinion we need some safeguard to prevent abuse.

Here’s what I propose: When you check this box, the system randomly decides, which of these events happens. I have added a suggested probability, however that should not be the main point of discussion for now:

  • the edit goes through without any human review/bumping (70%)
  • the edit will bump the post, although the edit is minor (20%)
  • the edit will need to be approved by a human (aka. suggested edit) (10%)

This should make it hard to manipulate a lot of posts with minor edits, because the possibility of being caught is quite high, but will also prevent homepage/review queue flooding by minor edits.

7

Are you sure that everyone who’s performing a “minor edit” will click that button? We should let the code decide if the edit is minor or major.
Every edit should go to human review. Like we decided that we’ll have different levels of moderation we can distribute workflow of minor and major edits to those levels.

Or if that’s not decided yet, still every edit should go to human review, be it minor or major, what if the edit abstracts away the actual intent of the post?

2 Likes
8

Sounds reasonable for the low rep/privilege users. A high-rep user should be able to do any edit without review, just like in SE.

9

Editing on Stack Exchange is never without review. Edited posts are bumped to the front page, allowing everyone to detect mistakes/abuse.

As I understood it, the idea of minor edits is, that they are not bumped. Hence I suggested some measurements to prevent bumping in the most cases, but still preventing abuse.

My idea is basing on the same principle as ticket controls in trains (at least in Berlin in Germany). It’s not possible to check everyone and every train, that’s why we use a sample. Therefore there is always the danger of being detected, resulting in users following the rules.

1 Like
10

Algorithmic doesn’t 100% work for minor vs. major. Review (minor or major) should be based on rep/privilege level.

However, we could have an algorithm coach the user - e.g., if < ‘x’ bytes total change and the changes split up (20 bytes in 10 places is spelling/punctuation, 20 bytes in one place is more likely adding something meaningful) and ask “Is this a minor edit?” (with an explanation below it) if the user clicks Save without checking the box.

2 Likes
11

To be honest, when I suggested the “minor edit” function, I wasn’t thinking of “doesn’t bump”. But that is a great idea and makes it well worth it. For example, a while back I went on a DIY SE spelling edit binge (I think it was “recepticle” (common but wrong) vs. “receptacle” (correct). After changing a bunch I realized it was bumping them all to the top, which was not fair to the recent questions. And yes, given that it won’t bump, which isn’t a true review queue but effectively works as one, there is a need to have some way to make sure that the changes are reasonable.

3 Likes
12

Edits without bumping are dangerous and are absolutely not necessary in the MVP.

The only use cases I’ve ever seen for edits without bumping are mass edits. They are not necessarily minor edits. Most of them are retags and retags are never minor since they have a major impact on who will pay attention to the post. A tool for non-bumping mass edits would be nice. But let’s discuss that in a few years’ time, when we start to need it.

7 Likes
13

What I think should be reasonable to do.

  1. Minor edits will have their queue and major edits too will have their own queue: The minor edit queue will not be more detailed and will show only the data which was changed and they can be approved by multiple users. Major edit queue will have a more detailed view of what is edited and what was the original post. It will need the same or more amount of approves that minor edits take
  2. Minor edits won’t bump the post but major edits will: minor edits don’t edit the question to improve its purpose but to improve its quality, bumping minor edits will be a disaster for sure.
  3. Editing just tags will be classified as a major edit: Tags can change the audience to whom the question is being displayed and thus change the possibility of the question getting answered, the edit should be bumped also.
  4. Editing the title will also classify as a major edit: For the same reason as the title carries weight and is important for the question, the edit should be bumped also.

The minor edit queue will have a different interface that facilitates quick approval of edits.

Edit votes

The minor edits should require more votes to approve and major edits should require fewer votes, that’s because we want the minor edits to be approved really quick and rigorously. we want more variety of votes on it and quick ones, so the votes require to approve minor edits should be more. The “vote on minor edits” privilege should be given to users that have rep around 500-1000.
The major edits should require fewer votes to approve than minor edits but the rep to actually vote on them should be above 1000. People can get banned from approving wrong major edits.

What do you guys think? Let me know

2 Likes
14

Considering how often people try to “help” by “fixing” US or UK spellings, even minor edits should still bump I think. But more tools for mass editing tags would be nice post MVP.

1 Like
15

I think minor edits should most always bump - it’s how posts get exposure - but in certain cases moderators can turn off bumping for certain tags, in the case of burnination and mass editing. Tags edits shouldn’t bump, those are too trivial.

I still agree with @gilles on this:

For the time being, let’s take edit bumping out of MVP and just assume that all edits bump. If it becomes a problem in the future we can work on that, but it’s not the most important thing at the current time.

4 Likes
17

We cannot afford that, if a post that was posted as javascript gets retagged to “java”, how will the java people know about the post? The post will just stay there, tag edits are really really important to bump and are a major edit.

Minor edits are edits to remove small typos, to indent code and other things, these are really trivial, minor edits are just improvement of the quality of the post.

4 Likes
18

Suggested Minor/Major Editing Privileges/Process

This is based on @weegee 's message here that I’m replying to, as well as a series of other messages from/to @Olin who has some very real concerns about when/how one user can edit another user’s post.

This is all the same for Questions and Answers (except of course that some pieces - tags, title - are only applicable to Questions).

Minor vs. Major Edits

  • Minor Edits include relatively small changes - spelling, grammar, punctuation, style, markdown (newbies often get confused by markdown syntax), etc. Code changes that are incidental (e.g., formatting, clearly missing pieces at start of end of pasted code).
  • Major Edits include tag changes, any content changes that add or remove significant meaning (which can be as small as a single word), rearranging of content in a way that changes meaning (“try a then b then c” → “try c then b then a”), code changes that affect the problem (e.g., correction of an obvious typo in a variable name might fix the problem - but that should be an answer (or a comment) and not a change to the original code).

I am torn about the question of “Title Changes”. The title is the most important item and therefore “any” change is “important”, but I think changing “MY HOT WATER HEETER LEEKS” to “My Hot Water Heater is Leaking” should be “minor” because it does not change the meaning. So if my process is approved we’ll have to get consensus on “Title” - Minor vs. Major.

  • Approvals Needed - Minor and Major will have separate, per community (default = per instance) values. This could be Minor = 2, Major = 2, could be Minor = 1 (since “minor”), Major = 2; etc. I suggest min 1 max 2 for Minor, min 1 max 4 for Major, but this can be worked out over time for each community.

NEW Optional Major Edit Restriction

This is to satisfy Olin’s concern about users making significant content changes to other people’s Q or A. The reasons for using this setting could include:

  • True “expert” users where the user is concerned about non-experts making innocent but inappropriate changes that affect the meaning of the post.
  • Controversial (e.g., Religion, Politics, etc.) posts where changes could be misconstrued in a way that significantly changes the author’s original intent (or even deliberately trying to sneak things past the Approval process).

This will be done using a new flag/boolean:

  • Provide a flag in each User’s Profile titled Allow Major Edits Default = True/Yes/Enabled
  • Provide a flag for each Q/A titled Allow Major Edits Default = From User’s Profile. Can be changed by Author at any time. Can not be changed by anyone else under normal circumstances.
  • If the Q/A is changed to “Community Wiki” (or equivalent, assuming we have such a thing) then for that Q/A only, the flag is forced to True/Yes/Enabled even if previously False/No/Disabled.
  • A change by a User to this setting in the Profile does not affect any already created Q or A.
  • Moderators and other users with full Editor privilege will always be able to make Major Edits. This is to allow for content changes that are either urgent (dangerous information (e.g., need to add a warning or make important corrections) or any sort of “bad” stuff that falls short of “Close/Delete”) as well as to allow later Major Edits if the user is no longer active but changes are considered necessary.

Privileges

The following privileges should be available. Names can be changed, of course, and the process (points, time on site, questions asked/answered/etc. - the whole “rep” discussion…elsewhere to decide).

  • Minor Edit Approval - Allows a user to review Minor Edits (queue and/or when viewing a Q/A) and make one of the required approvals.
  • Major Edit Approval - Allows a user to review Major Edits (queue and/or when viewing a Q/A) and make one of the required approvals.
  • Editor - Allows a user to review Minor Edits or Major Edits and approve immediately without any additional approvals needed. Also allows editing of a Q/A without requiring approval from anyone else.

While the above 3 privileges will normally be assigned automatically based on “rep/etc.”, there should be a way for a Moderator to revoke (or to assign - which we will need in the early days because otherwise all Approvals would need to be done by Moderators) any of these privileges as needed. There could easily be situations where a relatively new user is assigned Minor (or even Major) Edit Approval but be found to not do a good job of it and need to be demoted, but without losing all other privileges. Similarly, an Editor privilege may need to be revoked if a user is too quick to make content changes inappropriately (or perhaps just not very well - e.g., the Major Edits need too many Minor Edits for spelling/etc.) that do not necessarily reflect on that user’s capability with respect to other earned privileges.

Moderators will automatically have Editor privilege. However, well established users should have this privilege as well.

Authors will always have Editor privileges for their own posts. In other words, they can immediately approve or reject any edits proposed by others.

Process

  • Author creates Question or Answer
  • Another user clicks Edit.

If Allow Major Edits == True then:

  • Somewhere (not sure if top or bottom is best), a choice is shown of “Major Edit” vs. “Minor Edit”. Some limited information should be shown in mouseover, with additional information available via a ?/Help icon.
  • Approval requirements based on the user’s status and the site rules should be displayed next to Minor and Major. Some examples
    • Minor 2, Major 2:
      • New/Low Rep User: Minor Edit (2 Approvals required), Major Edit (2 Approvals Required)
      • Minor Edit Approval User: Minor Edit (1 Approval required), Major Edit (2 Approvals Required)
      • Major Edit Approval User: Minor Edit (1 Approval required), Major Edit (1 Approval Required)
      • Editor: Minor Edit, Major Edit (i.e., don’t say anything since no approvals needed)
    • Minor 1, Major 2:
      • New/Low Rep User: Minor Edit (1 Approval required), Major Edit (2 Approvals Required)
      • Minor Edit Approval User: Minor Edit (No Approval required), Major Edit (2 Approvals Required)
      • Major Edit Approval User: Minor Edit (No Approval required), Major Edit (1 Approval Required)
      • Editor: Minor Edit, Major Edit (i.e., don’t say anything since no approvals needed)

If Allow Major Edits == False then:

  • Show “Minor Edit” in the usual selection location but already “checked” and with a note next to it like: The Author has restricted Major Edits to this Question [Answer]. If you have additional content or significant changes, you may add a comment to suggest the information to the Author or include the information in your own Answer.

  • Moderators, users with Editor privilege and of course the Author still have Minor vs. Major as above because the restriction does not apply to them.

  • Approval requirements based on the user’s status and the site rules should be displayed next to “Minor Edit”. Only Minor is relevant. Some examples

    • Minor 2:
      • New/Low Rep User: Minor Edit (2 Approvals required)
      • Minor Edit Approval User: Minor Edit (1 Approval required)
      • Editor: Minor Edit, Major Edit (i.e., don’t say anything since no approvals needed)
    • Minor 1:
      • New/Low Rep User: Minor Edit (1 Approval required)
      • Minor Edit Approval User: Minor Edit (No Approval required)
      • Editor: Minor Edit, Major Edit (i.e., don’t say anything since no approvals needed)

  • If Approvals are needed:

    • Author is notified
    • Author can approve or reject any changes to their own Q or A.
    • Moderator or Editor can approve or reject any changes
    • Minor Edit Approval or Major Edit Approval users can approve or reject any [Minor or Major] changes. If additional approvals are needed then the edit stays “Pending” until sufficient Approvals (or rejects) are done.

  • After final Approval or Rejection:

    • User who proposed the edit is notified (and gets “rep” as appropriate)
    • Author is notified (unless Author did the Approval or Rejection)

  • If Approvals are not needed:

    • Author is notified
2 Likes
19

Some things that I would like to change here

This system of a checkbox that decides the nature of the edit is not reliable, we all know, we will have to let the code decide it and push it to the respective edit queue.

A tittle change from MY HOT WATER HEETER LEEKS to My Hot Water Heater is Leaking should be considered a major edit. The title affects the attention of the question, as we have decided that minor edits won’t bump, a title change should bump the question. The advantage of classifying edits into minor and major is that we’ll reduce a lot of useless clutter on the home page and display relevant results to our userbase. The title is pretty sensitive to a post. Even changing from that to a better title will only make the edit attract users. What if an ill-formed title is downvoted and later edited on and it makes the question answerable (point of editing though)? That’s why we should classify title edits into major edits

2 Likes
20

A checkbox doesn’t really work - it has a default which will be almost always kept “as is”. Some other, more obvious, UI is needed, without a default. In theory that would be Radio Buttons - no default is necessarily defined. In practice, I think under at least some circumstances browsers will effectively make a default and the UI is often not clear there either. However, let the code decide it is really not a good option - there are “small” edits that are Major and “big” edits that are “Minor”. Not that an AI can’t figure this out, but that would not be for MVP, where a simple required user selection could be MVP.

21

That‘s not a good option either, the author can trick the system into thinking that it‘s a major edit but actually it‘s a minor one and bump their question. Letting the code decide is the way to go. The question is, where does AI comes into this? We don‘t need an AI to do this.