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.
Post History
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 disrupt...
Answer
#3: Post edited
by
Andreas witnessed the end of the world today
·
2024-02-18T04:15:03Z (9 months ago)
- 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?](https://meta.codidact.com/posts/281610) 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.
- 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.
- 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?](https://meta.codidact.com/posts/281610) 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.
#2: Post edited
by
Andreas witnessed the end of the world today
·
2024-02-17T16:59:32Z (9 months ago)
- 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?](https://meta.codidact.com/posts/281610) 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.
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.
- 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?](https://meta.codidact.com/posts/281610) 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.
- 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.
#1: Initial revision
by
Andreas witnessed the end of the world today
·
2024-02-17T16:56:41Z (9 months ago)
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?](https://meta.codidact.com/posts/281610) 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. 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.