I am not sure what to do about moving from Proposed to “Accepted”. Anyone on the team should be able to do that — go ahead and try if you want, just put the topic back if you’re not really ready.
My current idea for official “promotion” is to key off of the reaction — if there are, say, three of those from members of the triage team, Issuebot will automatically move them — and also mark all replies, except any from Issuebot itself or any solution, as hidden, so as not to distract.
What do you think?
- Let’s try that idea
- No, something else I will explain
It is an timely update.
I am wondering what I can do regarding those new entries .
It sound like for those entries discovered and created by the bot, the bot will keep an “eye” in them.
How about …
(OK. I can ask about those … when those happens. Sorry for always lost of focus from my part )
PS: I noticed the bug where the titles Issuebot makes get HTML escapes. I will fix that.
Since the titles all need to be edited anyway, it’s not the worst bug!
Just a clarification.
Let’s say No sound after upgrade
Team member should go to Common F35 bugs - Fedora Project Wiki
And copy the text from the wiki?
And what about this one?
On bugzilla I don’t see the commonbug keyword. And it is not in the wiki.
So I took a stab at it and did the sound issue.
I’d welcome feedback on whether this is what @mattdm had in mind and whether this looks good to others.
Yes, that’s great! I think it’s an interesting example of one user issue / problem (“sound isn’t working”) with two possible causes / bugs. In this case, they both happen to have one bugzilla entry, but we could actually do this when there are separate bugs. I’ll make a note to teach Issuebot that if there are two bugzilla links, to adjust the automatic comment to say that one of the linked bugs may be fixed.
If there were two separate bugs, Issuebot would create proposed issues for both, and we would:
- pick one and explain both bugs, and edit the second bug link into the chosen issue topic
- close the other one.
- either manually adjust the Whiteboard in bugzilla for the un-chosen one to now point to the chosen topic instead of the original — or, have some sort of way to indicate that Issuebot should do that.
I’m not sure that combining is the right thing, though — what if one problem gets solved but the other doesn’t? Do we still mark the issue as solved? Not sure! Definitely need all of your thoughts for what this should look like. And it’s definitely worth trying a few different ideas to see what comes out in practice.
On this specific edit, a few notes:
- Remove “New proposed issue found:” from the title. Among other things that makes it easy to see in the list that a human has edited it.
- Along the same lines, remove Issuebot’s boilerplate in italics at the top
- Tag as #audio
- My idea for the “Cause” part was to give a few, hopefully-not-too-technical explanation for what we know about why this is an issue. Like:
In the first situation, hte upgrade process should have automatically enabled the new WirePlumber session manager, but in some cases it did not. In the second situation, WirePlumber is running correctly, but the older PulseAudio system is also enabled, and this combination does not work.
- Then, the actual “what to do about it?” part would go in Workarounds (replacing “none yet”, of course.
- Markdown formatting with numbered lists with long paragraphs is hard. If we do want to have issues with combined possible causes (and, yeah, I think it’s worth testing!), maybe it’d be easier and cleaner to, instead of lists, use headings like “Cause (Situation One)” and “Workaround (Situation One)”?
Also, hmmm, as I ook into the https://bodhi.fedoraproject.org/updates/FEDORA-2021-3c4c454c98 update Issuebot linked, its really unclear to me if this update will solve one or both problems, and for whom the problem is solved (like, will it retroactively fix systems, or just prevent new upgrades from being broken)? This may be a case where we need to contact the full QA team and/or the developer to get details. We should also develop a process for that!!!
Copy and maybe change a little bit as needed.
If all goes well with this experiment, there won’t be a wiki for F36 and forward. Copying the existing wiki entries is really a way for us to look at real examples and consider how they work in this format. And, also, of course, to fill out this category to the point where we can make it open to the public and make it really useful (and a practical demo.)
Ah, you’ve discovered something interesting. It does have the CommonBugs keyword:
… the light gray just means you don’t have permission to change it, and it actually IS on the wiki — it’s this Common F35 bugs: In Discover, packages can’t be installed and immediately removed, or removed and immediately re-installed, without restarting the application. But, that one is erroneously to bug #2011774 instead — but that’s a different CommonBug which has its own entry.
So anyway, I’ll edit the wiki to fix that.
Correct. It does. I was on mobile, and I didn’t spot it. Sorry for the trouble.
It was no trouble. And you were correct in noticing that something was strange with that bug.
Hi all! I made Issuebot a little smarter — it will now give different messages for different types of update messages (candidate to testing, released to stable) in bugzilla.
Instead of hard-coding the text, Issuebot reads it from Ask Fedora — specifically, from this hidden topic: Issuebot Templates
Everyone in the triage team group should be able to edit those messages, if you see a typo or if the wording should be improved. (We should probably discuss first in the second case, though.)
As you may have noticed, the templates include the strings $BUG_ID and $UPDATE_ID. Those will be replaced. There aren’t any other replacements right now, although theoretically we could create them.
And that’s all for tonight, I think!
Sorry for all the notification noise while I’m working on this. Theoretically when the system is in place and running as planned, updates will be far less frequent — and connected to something actually happening.
Hey @mattdm, Common Isssues Bot has three “s” in its name. Is it on purpose?
Question for all @common-issues-triage — should we close and unlist issues that were resolved during the beta, or should we move them to the #common-issues:common-issues-archived category?
(Close-and-hide would be the same as the procedure for declined issues. Moving them to the Archive would de-prioritize them in search results but the issue would be more easily found.)
- Close and Hide
- Move to Archive
- Other (I will explain)
also… should we tag these with #beta?
Also, note to self: I’m going to move all of the policy discussion in this topic to Site Feedback, once this is public.
I’ve gone through all the issues @alciregi worked on, and they look great. (Thanks again for doing all that!) I have provided votes to most of them, but the rest of you have not. If you have a chance, can you look and if the issues look good, do so?
I think once that’s underway, we’re ready to open this up to public preview.
I know right now it’s Kind of A Lot All At Once, but that’s becasue we’re converting from an existing process with a lot of issues there already. In real use (like, for upcoming Fedora Linux 36), they should come in at a more manageable rate as the issues are identified.
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.
@JV Yeah, definitely stay active if they haven’t been resolved.
PS: while you’re here, could you give a 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 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 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.
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.