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.
Moderation queues for questions and answers
There currently seems to be no concept of "queues" for questions or answers. I also looked at the old discourse forum, and it seems like different kinds of queues are causally mentioned, for different purposes, but their actual implementation has not really been discussed.
It's not entirely clear whether they are simply not implemented yet (and I can imagine that this is challenging and probably not strictly necessary to get started, and thus, had low priority), or whether there is an intention behind that - maybe to foster a different way of participation or self-moderation (?)
We have also seen on other sites that such queues may cause difficulties: When 100 questions are added to some queue per day, then 10 people might work them off. But when there are 1000 questions, these 10 people might say "That's too much. Why me? Why bother?", and the queue will never be drained.
But I think that queues can serve several important purposes.
First of all, they offer the possibility to systematically review content. Preferably, the implementation should already allow filtering queues by tags, support configurable actions that may be applied to the entries, maybe have some sort of "dispatching mechanism" to split queues among multiple reviewers, and maybe also support things like a priorization.
(Yes, too many wishes, I know - these are rather "features that might be useful for certain tasks in the future", and should be kept in mind when planning the implementation).
Another important purpose could be: Finding a consensus. This is something that cannot be handled with voting. I'm thinking about things like "Should this question be migrated to another site?": It's not ideal when a single person decides that, even with a high trust level. But when 4 out of 5 persons vote for a migration (maybe also taking the trust level into account), this can offer some resilience against wrong decisions.
More generally and abstractly: Queues can help to distribute workload and decisions over the community, and I think that this can be really helpful for many different kinds of tasks.
(An aside: There already is the concept of "suggested edits", which was implemented in https://github.com/codidact/qpixel/pull/85 , but the general concept of queues goes a bit beyond that)
1 answer
By queues I assume you mean review queues like on SE. We haven't designed anything like that yet, though we've discussed the need specifically for a way to see pending suggested edits. (A lot of forum discussions were treating the SE interface as a starting point.) In general, I have been thinking less of queues (where you're presented with some content and asked to make a decision) and more about search or filters (which would show you all the X and then you interact with them normally from there). We haven't spent much time thinking through how that would work yet, or at least I haven't. Let me sketch out some things that we -- and primarily I mean "I, and people haven't objected" -- have been thinking about that have some of the same motivations as reviews.
-
Suggested edits: These are shown prominently on the post itself, and the author receives a notification. People with the privilege can review the suggested edit, either approving or rejecting it. This is a good start; I'd like to add a link -- I'm thinking in the right column, near other curation links -- to a page that lists all posts with pending edit suggestions. This wouldn't be a queue and there wouldn't be special buttons and stuff; it'd be a list of links that you could click to go to the posts where, as already noted, the edit suggestion is prominent. (Maybe we'd tweak that to take you straight to the review page, but passing through the original page means you get context, so I'd start by doing that.)
-
Duplicate suggestions: Today duplicates are part of the close workflow, because that code was written years ago based on SE, but we've designed a different process for duplicates. Basically, anybody can suggest a duplicate; askers can either agree or edit, and other users can review (including post-edit -- "did that fix it?"). There's a wireframe for part of this to show how it would work. These interactions are on the question itself; I haven't been thinking of a queue for these because a potential duplicate doesn't really affect people who aren't interacting with the question.
-
Hold (close) suggestions: On SE, the usual flow is: five people put a question on hold, maybe the author edits it, maybe (rarely) five people reopen it, all of this takes a while (especially reopening), and many of the people involved get frustrated. I believe SE implemented close (and reopen) queues to mitigate some of that, but people still get frustrated. We have a different approach: alert the author as soon as someone raises an issue, allow people who see the question (and have the privilege) to directly vote in either direction, and react to author edits. This, too, is all happening directly on the question page, at least for now. Here's a wireframe for how the voting part of this would work.
SE has some other review queues -- suspected low-quality posts, posts from new contributors, and new answers to old questions. On large, active sites these might make sense, especially if there are few curators, but I think we'll do pretty well with the fact that all of these activities bump posts and we're not huge yet. By the time we're getting large enough that new content might not be seen, we'll also have a better idea of how we want to curate that. It might be sufficient to be able to write richer search queries, so that somebody who wants to review the work of new contributors or find new answers to old questions can do it that way. Or maybe we'll pre-define some filters. Or maybe it will be important enough that we'll need to do something else. I don't think we have enough information yet. An approach like SE's might end up being best (it's not like they just made it up out of whole cloth; it was probably based on something), or we might need something very different.
0 comment threads