Can you suggest a rough algorithm? I’m not convinced it is so easy.
It‘s not easy of course but my point is that you don‘t need an AI to do it. A rough algorithm can be a one that will detect tag, title e.t.c (easy part) changes and a script that will loop through the changed/added letters and count up the varities of letters changed. For example, I added 6 commas to someone‘s post and some 3 word fixes, the script can count up the the terms and decide.
If the the change and the words/letters change is above a certain threshold then the edit can also be classified as a major one. Rough idea.
1 Like
@weegee I fear that it will not be nearly so simple. The 6 commas are not a problem, but even a single word could turn out to be Major. Flip side: there could be 27 word fixes and still truly be Minor.
As far as author using “Minor marked as Major” to bump a post. That is potentially a problem, but (a) only an issue for Questions, not Answers (where the other issues of “who can/should edit’ do apply to Answers as well as (if not more so) to Questions”), (b) if we downplay the gamification aspects then there should be less of a concern of this triggering lots of extra votes because votes won’t matter as much, (c) if the Question has good answers then the Author won’t have any incentive to do this and (d) if the Question does not have good answers then “OK, this will be like a manual version of the Community bump in SE” and no real harm done.
And (e) if we didn’t have a “minor” marker to begin with, then the edit would have bumped the question anyway.
Indeed, I would make the ability to mark edits as minor a privilege. That way it would have to be earned, and it could be revoked by moderator if abused.
Also, the edit trust threshold for which minor edits don’t need approval might be higher than the edit trust threshold for major edits (that may seem counterintuitive, but basically marking an edit as minor allows it to stay under the radar of normal users).
And of course there are edits that can easily be determined not to be minor; those the system should simply reject to be submitted as minor edits.
2 Likes
I disagree. My concept has two key pieces, which are lost if “mark as minor” is an extra privilege:
- Since minor edits are spelling/grammar/etc., in theory any new user should be capable of making such changes, even if they are not yet that familiar with the particular community and/or do not have extensive knowledge of the topic domain. This lets new users be helpful right away with simple changes (though subject to ‘n’ approvals required) as they gradually learn what is/isn’t permitted in the content realm.
- This allows users who don’t have “Editor” privilege (which will be a fairly high level) still help on editing posts where “Major Edits” are blocked for all but Editor/Moderator/Author (i.e., to satisfy Olin’s concern about someone inappropriately editing an “expert’s” answer). If “no choice” meant “Major” then having “no choice” in this case mean “Minor” would be really confusing.
I really do think that a reasonable person on a new system will “get” the concept of Minor vs. Major. Plus all edits from new users will require at least one Approval. The Approval process can, in addition to the “usual” Approve/Reject/Edit, include the option of switch Minor ↔ Major. So if a new user gets it wrong, it can be fixed right away.
1 Like
Editing is essential, as is storing edit history and diffs. (In fact, maybe this is one example of task where a non-relational datastore would excel.) We’ll have it for MVP.
Restrictions/limits can be simple for MVP and then improved and refined as needed.
Reviewing is also essential. I dislike the idea of having separate review “queues” for trivial vs non-trivial edits, and am highly unfavorable to implementing any sort of algorithmic reviewing (that is, anything other than actual human review of some sort), at least for now.
Won’t comment on the specifics, but Manasseh’s suggested privileges look, at first glance, reasonable. I believe they can be made simpler. 
3 Likes
I think there shouldn’t be a way to prevent users from editing a post with major changes, except for locking down all/most interaction with that post (AKA “locked post” on SE), which would be a moderation tool. One of our goals is to build a high-value knowledge repository, and that (IMO) requires editing of posts.
If we decide on a “no major edits; separate answer”-policy, we should enforce that on a community-level and not on a software-level, as other people might want to create communities with different policies in that matter.
2 Likes
Edits are part of a relational database. They may seem different, but really they are a history table linked to the main (q/a/whatever) table. Totally straigtforward from a database perspective.
Me too. The Major Edit Approval and Editor users should see all edits in one queue. That avoids “having to look in 2 places” and also allows them to flip a Minor to Major or Major to Minor as part of the review process.
If done right, I think the user experience would be much simpler than the text I needed to describe. Each user would see what “makes sense” - e.g., if they can only make Minor Edits then they don’t have any option; if they can only Approve Minor Edits then they don’t see the Major Edits in the Edit Queue and don’t have the option to Approve when viewing the Q/A directly, etc.
1 Like
I just mean that the different revisions’ contents, specifically, could be stored by a non-relational engine. Hey, we could even query git for it (not that I believe it’ll actually work great for our intended purposes, but who knows). Didn’t mean to say “so hey, here’s a reason why a non-relational DB engine would have been better for the entire software implementation”. 
I’m sure it will, but, maybe the implementation itself can be simplified a bit? I don’t know, didn’t give it too much thought yet (so much on our plate as it is - this can be deferred a bit!) But also not saying it needs to, as if there was some major problem with the proposal. Not that I can see, no.
2 Likes