We are testing a "New Common Issues" category and process

I think it proper that issues found in beta should be tagged as #beta, especially when they have already had a fix pushed. If still not resolved then they should go to common issues and remain active.

1 Like

@JV Yeah, definitely stay active if they haven’t been resolved.

PS: while you’re here, could you give a :bluethumb: to some of the Proposed Issues that look ready to go to you? I’m working on that part of my script right now and it’d be nice to have some examples that are at least 2 votes instead of just 1.

Got impatient :slight_smile: and dropped the threshold down to 1 vote, and that seems to work. I’m going to put it back to 3, though — hopefully a couple other people can go through the exercise in the next week. Please add a :bluethumb: to any of the #common-issues:common-issues-proposed that you feel are ready to go, and we’ll see if the bot get 'em properly.

1 Like

Also of note, @common-issues-triage team… I’m going to delete all non-solution comments on issues promoted to the main Common Issues category. Moderators should be able to see them as “hidden”, for reference. The plan is to have issuebot do that automatically, but it doesn’t yet.

This maps to the current wiki process where users don’t see a big back-and-forth about whether an issue qualifies, just a to-the-point summary and solution.

If we think we ought to preserve these conversations more publically somehow, I can think of some ideas, but don’t plan to experiment on any of them unless there’s a strong call.

Yeah, on purpose so we’d have something to work with.

Yes makes sense. I’ll review the PR.

Hey @mattdm , I can’t seem to understand the default sorting of topics in Common Issues - Ask Fedora . Latest is highlighted, but that certainly doesn’t seem to be the case. It seems to be completely random (I even tried a private browser profile, in case it’s caused by my account settings). Can you improve that somehow? I think it would make sense to sort Common Issues by Latest by default, and Proposed Common Issues by Top-Voted (and then by Latest) by default.

1 Like

@mattdm I found another issue. If I open Shipped versions of PHP and Zabbix (frontend) are incompatible there’s view 6 hidden replies link at the bottom (probably only available to people in the common-issues-triage group?). If I click it and scroll to the reply from Ben, there is 1 Reply button under it. But I can’t expand it, I can’t see what was in there. It seems it’s either a bug in Discourse or some privilege misconfiguration.

1

Edit: Actually, perhaps the latest comment from lruzicka is the reply to Ben? So the comment is not hidden, just the hyperlinking between them is broken?

This process should be documented here:

Currently is suggests that the acceptance is done by discussion and then a manual move from one of the team members.

I wonder if going just by the vote count automatically is a good solution, though. If there are 3 people in favor and 3 against, the bot will still promote the topic automatically, because the people against have no way to express their vote (in a way a bot would understand). And if this situation happens, you can’t even move it back to Proposed manually, because the bot would move it to Accepted immediately again, right? :slight_smile:

I had set it to display by votes by default, but apparently that actually changes the sorting of “Latest”, which is … weird. I’ll check with discourse about it. But anyway, since no-one seems to really vote on things very much (on Ask in general, let alone this category) I’ve changed it to “Created”. (Other options are “Activity” and “Likes”).

I’m not quite sure what the problem is there — when I use the tool to “select post and replies”, only that one post appears. So, probably a Discourse bug. I will report it.

On the first point: I changed the text to say “… Issuebot will move the topic …”.

We’ve intentionally not provided any negative reactions on this site, so there’s only upvotes. Team members can remove their votes (as I did here) if they change their minds (either completely or just temporarily).

You’re right that moving it back to proposed won’t work, for sure. :eureka: I could have issuebot remove the votes, but then it needs more privileges.

The bot could be changed to tally votes in replies instead of looking for :bluethumb:, I guess?

That seems to work for accepted common issues. But for proposed common issues, it seems that the sorting order is by activity reversed (most recent replies at the very bottom)?

This topic is a good example. Currently it has two :bluethumb: . Anyone from the triage team can add another one and it will get automatically promoted, even though we currently discuss whether it’s a good idea or not. And we can’t do anything about it. The more team members we have, the more likely it is that a topic gets promoted even when we want the discussion to continue first.

That reminds me of something :smiley: I think that’s unnecessarily complex for this use case. I think it would work well if we simply disabled automatic promotion and left it as a manual action by anyone from the triage team. We can still use the :bluethumb: votes to display support, but a human will also see whether there is something unresolved in the discussion, and decide whether the time for promotion is right, or whether we need to wait some more, or whether to close that topic. If somebody moves it to Accepted and we later have doubts, anyone can move it back to Proposed and restart that discussion. The deliberate human decision overall seems better to me in this case, than a bot action. Thoughts?

2 Likes

This comment seems to apply to the potential for having too many common issues entries which could easily occur with using the bot for promotion.

I’m absolutely okay with simplifying that. I wanted to demo the possibilities, and also to reduce the amount of human interaction required for the process to work — but I agree that this point is a pretty good one for human judgment.

(An alternative would be if the voting were really successful and we typically had in the dozens to hundreds of votes per post. Then we could consider dropping any team requirements and just have it go on some threshold of user attention. But, um, that seems to be fantasyland, as I think “six” is the highest any of the votes have ever gone.)

1 Like

I’m absolutely okay with simplifying that. I wanted to demo the possibilities, and also to reduce the amount of human interaction required for the process to work — but I agree that this point is a pretty good one for human judgment.

(An alternative would be if the voting were really successful and we typically had in the dozens to hundreds of votes per post. Then we could consider dropping any team requirements and just have it go on some threshold of user attention. But, um, that seems to be fantasyland.)

I’m generally fine with dropping it, as well as dropping some of the other unimplemented functionality that does similar things. :slight_smile:

My only concern is: do we think this can, pragmatically, be done asynchronously, or do we need a review meeting?

No, I don’t think this needs review meetings. A simple judgement call from a long-term triage member is OK. If the person is unsure, they can ask in comments and wait a day or two whether there are any further objections. If someone later thinks it should be demoted, we can again deal with it in the comments (the triage members should be Watching both categories).

1 Like

I’m ok with that, just afraid things will get neglected without at least a little process.

Well, we could make the bot add a nagging comment, if there’s no activity in e.g. 2 weeks. Or it could even autopromote the topic, if it has sufficient votes and no discussion occurred in that timeframe (or even better, announce that it’s going to autopromote it in 3 days if there’s no further discussion, and then do it). In that case though, it might be a good idea to support some keyword in comments that would prevent autopromotion, like DISABLE AUTOPROMOTION, or @issuebot, ignore this.

Do you think it’s better to start with the former or the latter?