Notifications
Sign Up Sign In
Q&A

Moderation queues for questions and answers

+2
−0

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)

Why should this post be closed?

0 comments

1 answer

+1
−0

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.

4 comments

It's true that much of the functionality that is handled via queues on SE can be "emulated" with search/filter. This might become more difficult with more content or more different types of possible actions. In that sense, queues could be seen as a way to selectively "push" things to the curators, whereas search/filter requires them to "pull" the content (and things might more easily be overlooked) Marco13 14 days ago

Not directly related, but more general: The wireframes look like there is much more responsibility (and more direct interaction) for the author: Instead of the SE process, where people could only see the close votes pile up (and feel "unwelcome" when the Q is closed), the author could here be much more directly addressed and encouraged to engage in improvements. That sounds like a good thing. (Not sure how well this scales, but we might see that later) Marco13 14 days ago

@Marco13 agreed; we might need to change things with scale, and push vs pull is an important factor. I think suggested edits are important enough to be called out as I suggested, because good edits actively improve quality and people who get prompt responses to their contributions are more likely to offer more. Even on SE reviews are largely pull; yeah the icon might light up (or not) but you still have to go there. I'd like to see if a different approach improves things. If not we'll revise. Monica Cellio 14 days ago

More direct interaction for the author is intentional, yes. Some things only the author can fix, so send that signal early so the author can address it and get an answer. Even when a site is large, any particular question probably has only a few people interacting on it, so my hope is that they'll be able to do that whether today brought 10 other questions or 100 or 1000. And, fundamentally, the asker has to take the lead and should be the most invested in it. Monica Cellio 14 days ago

Sign up to answer this question »