Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
How should we approach large numbers of edits made all at once?
If edits are made to a large number of posts in a short period, they will push everything else off the front page, taking visibility away from recent questions and answers. They will also take visibility away from each other, so malicious or accidentally detrimental edits are less likely to be spotted by the community.
Is it better to spread such edits over a longer period of time, so they only show on the front page one at a time? Is it better to make them all at once and accept the cost today, to avoid having the small distractions of edits spread over days or weeks?
I would like to see your advice for several groups:
- Direct editors (people with the Edit Posts ability or post authors).
- Suggesting editors (people without the Edit Posts ability, making suggested edits).
- Reviewers (people with the Edit Posts ability, or post authors, deciding whether to accept or reject suggested edits).
In particular, when faced with a long list of edits suggested by one user, should a reviewer accept any they see as useful immediately, or accept them only gradually over time to avoid flooding the front page, or reject them with a message to say there are too many?
Related
This discussion is about large numbers of edits made all at once. There are also closely related discussions:
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
The problem with this question, and overall discussion, is that we're only having it because the post activity update system is broken. If we can't make minor edits without causing a lot of disruption on the platform, we have a serious issue, as a curated and maintained repository. We have the tools and availability to review these edits, so it all boils down to the effect of committing an edit to a post: the post gets bumped in all locations ordering posts by their activity.
There's already a much better solution that's been proposed, than not permitting editing old content, or making a large amount of edits at once: Could we have a way to edit without bumping posts? Sadly, nobody has yet gotten around to actually implement the changes required in order to solve this issue. One may argue that until then, we must have different rules for which edits are allowed, or how they are made. I disagree. The result is that we are blocked from maintaining and curating our repository in the meantime, and it puts an unnecessary burden on the users. For an editor that wishes to spend their time and contribute useful edits to our repository, it is counter-productive to impose these restrictions.
You ask for advice for editors skipping review, editors sending edits to review, and for reviewers, but it makes no sense to split them up. The eventual effect of an accepted edit is the same; it passing through review makes no difference here; it will mark the post with new activity anyway. Reviewers cannot follow different advice here, either, as they must review based on the same rules that edits are suggested within.
In particular, when faced with a long list of edits suggested by one user, should a reviewer accept any they see as useful immediately, or accept them only gradually over time to avoid flooding the front page, or reject them with a message to say there are too many?
But this shouldn't matter. It's an external factor, and edits should be judged by their own merits, not who suggested them. It's irrelevant. Reviewers are supposed to be fair, and judge what they review based on the content of the suggestion, not who is responsible for it.
Not just that, but what if multiple different people review these edits from the same user? Codidact doesn't have appropriate tools for these reviewers to communicate, nor does it pick up what's happening, and reporting it to the reviewers.
Declining good edits if there are too many, is quite a paradox. It's like punishing people for doing many good things. It honestly doesn't make much sense. As a new contributor having my useful edits committed in good faith, declined for this reason, I'd end up being demotivated, and consider walking away. Is this worth my time? I know that this sounds ridiculous to the ones of us that live on the site (me included), but it isn't so strange for new users to consider it.
0 comment threads
New information or critical edits
Adding new information or making edits which need to be done as soon as possible (maybe to remove dangerous information or something).
-> go for it!
Useful, but not critical edits
Like adding tags, fixing typos in title or in other important words which will make the post easier to search for.
Such edits should be spread out to not overwhelm the front page. This should be the responsibility of the direct and suggesting editors. If one of the suggesting editors fails to spread them out, the reviewers can also delay their reviews.
Finding a good frequency for edits will depend on how busy a community is (on powerusers we recently had a case of serial tag edits and I tried to spread out my reviews to one per day, busier communities like meta, can probably cope with more edits).
Unnecessary edits
Fixing typos like teh -> the.
While such edits can make a post easier to read, especially for non-native speakers, I don't think they justify serial bumping old posts to the front page. Editing a post which is anyway on the front page or a one-off is ok, but please don't serial edit such cases, that's not worth taking away attention from other questions on the front page.
As reviewer, I would reject them if I would come across several of such edits at once.
Special cases
There can be special cases which require a large number of edits. I think they should be discussed on the per-site meta on a case-by-case basis.
For example on TopAnswers/tex, I recently wanted to update many of my answers to replace a library with a more modern fork. As this amassed to about 10 % of all post on the page, I discussed this first with the other users of the site to see if they preferred a one-and-be-done approach or spread out over time.
0 comment threads
0 comment threads