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

Hey @mattdm , I can’t seem to understand the default sorting of topics in https://discussion.fedoraproject.org/c/common-issues/141/none . 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.

a119d4419e5412bfa04fe7147dbfd29588ce1d80.png

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.
https://discussion.fedoraproject.org/t/selinux-denials-related-to-sss-cache-while-installing-software/64076/7

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?

@kparal Sorry for the much-delayed response here! I still care about this, just have lots going on. I think adding nagging — and the “@issuebot ignore” comments are good.

@kparal (and all) Welllll, I didn’t get to this before PTO. I’m gone next week, but maybe let’s meet to talk about where we want to go with this when I get back?

It seems we’re quite low on people giving thumbs-up to proposed common issues :slightly_frowning_face: I had to manually promote all proposed ones, they had basically zero votes.

@grumpey Hi, please note that common issues voting is done with :bluethumb: and not :heart: . (I’d send you a private message, but it seems you disabled that for your profile, so at least I’m tagging you like this). Thanks!

Yeah, I kind of think we might need to resort to having a regular review meeting to make it work.

But I could also spend the time that would be in a meeting adding a bit to ask people for votes?

Sorry for my lack of inputs to the “New Common Issues”.

I am thinking I should give a up-vote when I can reproduce the bug myself.

What is the typical condition to be meet for one to give a up-vote?

My Fedora machines are broken which I cannot do triage at the moment. I hope I can have another machine running Fedora soon.

@kparal is this formalized somewhere?

I don’t think you need to reproduce yourself if it reasonably looks like a problem a lot a people are likely to encounter.

1 Like

If you can reproduce the issue and play with it a little, that’s great, but that’s not needed. We’re basically looking for feedback whether the issue description looks reasonable, whether general audience will understand it or it should be rephrased somehow, etc. If you know or can figure out an additional workaround, or find relevant upstream reports, that’s very useful. But overall just a general ‘sanity check’ is fine. Thanks :slight_smile:

3 Likes

I wonder what should we do about issues which were fixed before F36 Final release. It’s helpful to have them, because F36 Beta testers might still be affected and would like to read how to resolve the issue. At the same time, they really obscure the view, see here. The top 10 items in the list are resolved issues, and that’s not great for regular users who will visit that page after F36 is released and want to see which bugs actually affect F36 Final. The problem is that we can’t manually order issues in that list.

I think the easiest solution is to move those resolved pre-release issues to Archived Common Issues, shortly before F36 is released. But I’m not sure if that category doesn’t have search disabled. It would probably be helpful if people could search for issues even in the archive, otherwise they won’t find them.

@mattdm Thoughts?

1 Like