(This question is a feature-request on the site infrastructure, i.e. interaction mechanics, not on the edit/review policy.)
The issue of minor edits often crop up in various ways:
- When can I reject a suggested edit for being minor?
- Why reject as too minor?
- Are micro edits on new posts insignificant?
On one hand, many minor edits are well-intentioned, i.e. they improve the question or answer, and these improvements accumulate.
On the other hand, when minor edits and major edits are put into the same review queue, it overburdens reviewers. For this reason, the current practice (for some people) is to summarily reject minor edits, to discourage people from making minor edits in the future.
I would argue that:
- Discouraging people from making minor edits is ineffective, since they were not being told why it was rejected - they only knew it was rejected. To discourage effectively, the message need to be seen by the prospective edit submitter before they begin editing.
- Discouraging people from making minor edits, in general, is a negative user experience (negative emotions), even if well-intentioned.
I am proposing a technical solution to the reviewer over-burdening problem: to put them into different queues, and to let reviewers choose what kind of edits (minor / major) they want to work on.
In the beginning, we let edit submitters self-indicate whether this edit shall be flagged as being minor. In parallel to this, we can also implement statistical means (in the backend) to classify an edit as being minor or major.
(Please migrate, or copy-paste-delete this to the appropriate meta forum. Thanks.)