Background ----------
Every release since possibly the dawn of time (or, at least, [Fedora Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where we document things that we judge not to be blockers but are concerned many people might run into on upgrade or first install of a new Fedora Linux release — or, would-be blockers we decide we have to waive because we don’t have time or resources to fix. Or, just common issues that crop after the release.
Problem -------
This time around, based on my anecdotal impression from social media, Ask Fedora questions, and even comments on the release announcement, [No sound after upgrade][3] appears to be the … winner. Lots of people are hitting this.
This leads me to several observations:
- The given solution works for most people, but clearly many are not seeing it. - We have no way of telling how many people *did* find a solution and therefore say nothing. - For that matter, we have no really good way of telling if there’s actually a *different* issue more people are affected by, but just less loud about. - The bug linked from the Common Bugs page gets cluttered up with: - People for whom the workaround didn’t work and resulting discussion - Reports of similar issues which are not, in fact, that issue. - Alternate suggestions which may or may not be good advice.
Proposal 💡 -----------
I suggest that for the Fedora Linux 36 release, we move to an Ask Fedora–based replacement for this wiki page.
Now, to put my cards on the table here:
- I don’t *actually* hate the wiki, but I do think we shouldn’t be sending unwitting end-users there. - I *do* love Discourse. There. I said it. - And, I love Ask Fedora in particular. It’s a community success.
Specifics ---------
We’d create a new top-level category, “Common Issues”. Posting directly in the category would not be allowed. Instead, there would be a *subcategory*, “Proposed Common Issues”.
New topics in “Proposed Common Issues” would use the template feature, prompting for the necessarily information and keeping the format consistent. Unfortunately, there are no macros to do the fancy things the current wiki process uses, which I will freely admit is a drawback.
Each topic would be tagged with the release that it corresponds to (and, ideally other tags, like the installation / upgrade / workstation / etc. sections on the wiki — we could make that mandatory or just by convention).
Members of the QA team (based on group membership, automatically once [Does `sso overrides groups` work with Oauth2? - sso - Discourse Meta][4] is fixed upstream) and possibly other volunteers will be marked as category moderators, and so can promote topics to the higher-level “Common Issues” after vetting them.
And, we’d turn on voting, and ask people to vote for issues that they have also experienced. Not scientific, but gives a measure that we don’t have now.
Advantages ----------
- More visible to end users. (I think, at least.) - Directly linked to where we’re telling people to go for help, and where people are talking about their problems. - Gives a place to comment on and discuss the problem *other* than cluttering the bug in bugzilla. - Right now, *Lots* of people on Ask coming in with new questions about the no-sound-on-upgrade issue. Even if they don’t find it and avoid needing to ask, we can easily merge those into the main topic. - Conversely, when a person has a *different* issue, it’s easy to split that into its own help thread. - And we can moderate and organize response in general to make sure people are seeing the most helpful advice and not getting misdirected. - Right now, the release-cycle QA process is the primary source of Common Bugs. But… maybe we’re missing things that users are finding? - Discourse’s notify-by-mail feature is nicer than following wiki page changes by mail. - Moves us towards Ask Fedora as a first-top issue triage center, reducing Bugzilla load for maintainers *and* reducing end-user frustration with unmet expectations about Bugzilla response.
Disadvantages -------------
- No fancy formatting macros - New thing for QA team folks to take on and I know there’s already a lot - Other?
Discussion? -----------
I’m posting this both [Ask][5] and here on the Fedora Test mailing list. Discuss where you feel most comfortable and I’ll try to link the results.
----
[1]: https://fedoraproject.org/wiki/Common_FC5_bugs [2]: https://fedoraproject.org/wiki/Common_F35_bugs [3]: https://fedoraproject.org/wiki/Common_F35_bugs#No_sound_after_upgrade [4]: https://meta.discourse.org/t/does-sso-overrides-groups-work-with-oauth2/1756... [5]: https://ask.fedoraproject.org/t/proposal-migrate-common-bugs-from-the-wiki-t...
I am speaking for myself and not on Fedora QE's behalf, but I believe that this might work. Maintaining one Common Bug page should not be a problem, even if it is on another platform.
I also like the idea to make this the support and triage page of the first instance, as we need to increase the community input on bug reporting.
So I am +1 to this proposal.
Lukas
On Thu, Nov 4, 2021 at 4:44 PM Matthew Miller mattdm@fedoraproject.org wrote:
Background
Every release since possibly the dawn of time (or, at least, [Fedora Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where we document things that we judge not to be blockers but are concerned many people might run into on upgrade or first install of a new Fedora Linux release — or, would-be blockers we decide we have to waive because we don’t have time or resources to fix. Or, just common issues that crop after the release.
Problem
This time around, based on my anecdotal impression from social media, Ask Fedora questions, and even comments on the release announcement, [No sound after upgrade][3] appears to be the … winner. Lots of people are hitting this.
This leads me to several observations:
- The given solution works for most people, but clearly many are not seeing it.
- We have no way of telling how many people *did* find a solution and therefore say nothing.
- For that matter, we have no really good way of telling if there’s actually a *different* issue more people are affected by, but just less loud about.
- The bug linked from the Common Bugs page gets cluttered up with:
- People for whom the workaround didn’t work and resulting discussion
- Reports of similar issues which are not, in fact, that issue.
- Alternate suggestions which may or may not be good advice.
Proposal 💡
I suggest that for the Fedora Linux 36 release, we move to an Ask Fedora–based replacement for this wiki page.
Now, to put my cards on the table here:
- I don’t *actually* hate the wiki, but I do think we shouldn’t be sending unwitting end-users there.
- I *do* love Discourse. There. I said it.
- And, I love Ask Fedora in particular. It’s a community success.
Specifics
We’d create a new top-level category, “Common Issues”. Posting directly in the category would not be allowed. Instead, there would be a *subcategory*, “Proposed Common Issues”.
New topics in “Proposed Common Issues” would use the template feature, prompting for the necessarily information and keeping the format consistent. Unfortunately, there are no macros to do the fancy things the current wiki process uses, which I will freely admit is a drawback.
Each topic would be tagged with the release that it corresponds to (and, ideally other tags, like the installation / upgrade / workstation / etc. sections on the wiki — we could make that mandatory or just by convention).
Members of the QA team (based on group membership, automatically once [Does `sso overrides groups` work with Oauth2? - sso - Discourse Meta][4] is fixed upstream) and possibly other volunteers will be marked as category moderators, and so can promote topics to the higher-level “Common Issues” after vetting them.
And, we’d turn on voting, and ask people to vote for issues that they have also experienced. Not scientific, but gives a measure that we don’t have now.
Advantages
- More visible to end users. (I think, at least.)
- Directly linked to where we’re telling people to go for help, and where people are talking about their problems.
- Gives a place to comment on and discuss the problem *other* than cluttering the bug in bugzilla.
- Right now, *Lots* of people on Ask coming in with new questions about the no-sound-on-upgrade issue. Even if they don’t find it and avoid needing to ask, we can easily merge those into the main topic.
- Conversely, when a person has a *different* issue, it’s easy to split that into its own help thread.
- And we can moderate and organize response in general to make sure
people are seeing the most helpful advice and not getting misdirected.
- Right now, the release-cycle QA process is the primary source of Common Bugs. But… maybe we’re missing things that users are finding?
- Discourse’s notify-by-mail feature is nicer than following wiki page changes by mail.
- Moves us towards Ask Fedora as a first-top issue triage center,
reducing Bugzilla load for maintainers *and* reducing end-user frustration with unmet expectations about Bugzilla response.
Disadvantages
- No fancy formatting macros
- New thing for QA team folks to take on and I know there’s already a lot
- Other?
Discussion?
I’m posting this both [Ask][5] and here on the Fedora Test mailing list. Discuss where you feel most comfortable and I’ll try to link the results.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, 2021-11-04 at 11:43 -0400, Matthew Miller wrote:
Background
Every release since possibly the dawn of time (or, at least, [Fedora Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where we document things that we judge not to be blockers but are concerned many people might run into on upgrade or first install of a new Fedora Linux release — or, would-be blockers we decide we have to waive because we don’t have time or resources to fix. Or, just common issues that crop after the release.
Problem
This time around, based on my anecdotal impression from social media, Ask Fedora questions, and even comments on the release announcement, [No sound after upgrade][3] appears to be the … winner. Lots of people are hitting this.
This leads me to several observations:
- The given solution works for most people, but clearly many are not seeing it.
I suspect this is more of a universal truth than something easily improvable. We could fly a plane above every town on Earth and some people wouldn't see it. We could hire Mark Zuckerberg to transmit it direct to the eyeballs of everyone in the world (you know he can!) and someone would still manage not to see it. People are *really good* at not seeing documentation. :D
- We have no way of telling how many people *did* find a solution and therefore say nothing.
- For that matter, we have no really good way of telling if there’s actually a *different* issue more people are affected by, but just less loud about.
- The bug linked from the Common Bugs page gets cluttered up with:
- People for whom the workaround didn’t work and resulting discussion
- Reports of similar issues which are not, in fact, that issue.
- Alternate suggestions which may or may not be good advice.
Proposal 💡
I suggest that for the Fedora Linux 36 release, we move to an Ask Fedora–based replacement for this wiki page.
Now, to put my cards on the table here:
- I don’t *actually* hate the wiki, but I do think we shouldn’t be sending unwitting end-users there.
- I *do* love Discourse. There. I said it.
- And, I love Ask Fedora in particular. It’s a community success.
Specifics
We’d create a new top-level category, “Common Issues”. Posting directly in the category would not be allowed. Instead, there would be a *subcategory*, “Proposed Common Issues”.
New topics in “Proposed Common Issues” would use the template feature, prompting for the necessarily information and keeping the format consistent. Unfortunately, there are no macros to do the fancy things the current wiki process uses, which I will freely admit is a drawback.
Each topic would be tagged with the release that it corresponds to (and, ideally other tags, like the installation / upgrade / workstation / etc. sections on the wiki — we could make that mandatory or just by convention).
Members of the QA team (based on group membership, automatically once [Does `sso overrides groups` work with Oauth2? - sso - Discourse Meta][4] is fixed upstream) and possibly other volunteers will be marked as category moderators, and so can promote topics to the higher-level “Common Issues” after vetting them.
And, we’d turn on voting, and ask people to vote for issues that they have also experienced. Not scientific, but gives a measure that we don’t have now.
Advantages
- More visible to end users. (I think, at least.)
- Directly linked to where we’re telling people to go for help, and where people are talking about their problems.
This seems trivial. We invented hyperlinks a long time ago, and the account system for the wiki and Ask is the same account system.
- Gives a place to comment on and discuss the problem *other* than cluttering the bug in bugzilla.
This could equally be phrased as "encourages splitting the discussion of the bugs to a place where people already following them, notably including the maintainers, may never see it".
- Right now, *Lots* of people on Ask coming in with new questions about the no-sound-on-upgrade issue. Even if they don’t find it and avoid needing to ask, we can easily merge those into the main topic.
But you could also merge them into a single topic for the bug which has a prominent link to the common bugs page. Is that really a big difference?
- Conversely, when a person has a *different* issue, it’s easy to split that into its own help thread.
I don't really see where this is an advantage compared to the current system. In the current system there is no discussion, so there's nothing to split off. If people discuss different problems in a bug report, it's easy enough to ask them to file a new bug too. We could hide or delete their comments if we wanted to, but we tend not to do that sort of thing in Bugzilla as a matter of policy.
- And we can moderate and organize response in general to make sure people are seeing the most helpful advice and not getting misdirected.
Again, this doesn't seem like something you can't do right now. To me, we have two functions: documentation and discussion. The Common Bugs pages are documentation. Discourse is for discussion. The discussion is already happening on Discourse, so...what's the issue? I quite like that there *is* this distinction, honestly. I like common bugs entries to be clear, distinct and ideally authoritative. I don't think it would be *more* helpful for people to see a whole forum thread for every documented issue. It would just muddy the waters.
- Right now, the release-cycle QA process is the primary source of Common Bugs. But… maybe we’re missing things that users are finding?
Possibly? But I don't see how moving the information to Discourse helps with that. I used to read fedoraforum.org more or less cover-to-cover, in part as a source for common bugs. I don't do it any more because I don't have the time (and it's less a part of my job). Right now, I could read ask.fp.o as a source of things to put in common bugs, if I wanted. I don't because...I don't have the time and it's not really part of my job. Anyone else who wants to help could do so as well, though. The common bugs pages do not need to be in Discourse for this to happen.
We set up a convenience mechanism in Bugzilla to 'nominate' things for common bugs (the CommonBugs keyword and special searches that key off that keyword and whiteboard contents). We could probably do something similar in ask.fp.o easily enough, to make it more convenient to 'flag' things there for inclusion. Again, without moving the common bugs pages themselves at all.
- Discourse’s notify-by-mail feature is nicer than following wiki page changes by mail.
- Moves us towards Ask Fedora as a first-top issue triage center, reducing Bugzilla load for maintainers *and* reducing end-user frustration with unmet expectations about Bugzilla response.
If what we're worried about is people discussing things in Bugzilla, we could probably come up with closer integration between the common bugs pages as they are and a discussion thread for each in Ask, for instance, without actually having the canonical common bugs information itself be part of a discussion thread.
Disadvantages
- No fancy formatting macros
- New thing for QA team folks to take on and I know there’s already a lot
- Other?
Discussion?
I’m posting this both [Ask][5] and here on the Fedora Test mailing list. Discuss where you feel most comfortable and I’ll try to link the results.
Broader take:
So, it's mainly Kamil and I who maintain these pages these days. I wrote a lot of the template stuff.
I'm honestly fairly reluctant to support this change unless someone intends to recreate all the things I've already done to make it convenient to work on, or let me take paid time to recreate them all for Discourse, honestly.
There are templates used to create the pages at Beta time and then update them for Final:
https://fedoraproject.org/wiki/Template:Common_bugs_header_prerelease https://fedoraproject.org/wiki/Template:Common_bugs_header_stable_release
there are templates used to provide accurate information and instructions when a bug is addressed by an update:
https://fedoraproject.org/wiki/Template:Common_bugs_update_testing https://fedoraproject.org/wiki/Template:Common_bugs_update_released
and, perhaps least obviously but most *usefully*, there's a fairly capable script I use for actually maintaining the pages:
https://pagure.io/fedora-qa/qa-misc/blob/master/f/commonbugs-update
this processes the page for a given release, parses it one issue at a time, and detects whether the issue is now addressed by an update, and lets you modify the page appropriately (adding the right template and moving the issue to the 'resolved' section if it's stable) if so. It saves a lot of tedious work doing this manually.
Or, more to the point, without this script I would almost never do the tedious manual work because I'd always find something less tedious to do, and nobody else does it either, so the pages don't get updated. Even *with* the script I only get around to updating them a few times per release, but it beats them never getting updated at all.
I suppose the other way I'd support this change is if someone else was volunteering to take over all the work of writing and maintaining these pages. But only if they were going to do it at least as well as Kamil and I do.
On Fri, Nov 5, 2021 at 8:36 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2021-11-04 at 11:43 -0400, Matthew Miller wrote:
Background
Every release since possibly the dawn of time (or, at least, [Fedora Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where we document things that we judge not to be blockers but are concerned many people might run into on upgrade or first install of a new Fedora Linux release — or, would-be blockers we decide we have to waive because we don’t have time or resources to fix. Or, just common issues that crop after the release.
Problem
This time around, based on my anecdotal impression from social media, Ask Fedora questions, and even comments on the release announcement, [No sound after upgrade][3] appears to be the … winner. Lots of people are hitting this.
To be blunt, I try my hardest to avoid the Discourse system. I would rather us just make the CommonBugs page linked from Ask in a prominent way for people to see it. People using the Ask system should be made aware of CommonBugs before posting, so you could add an overlay on the "new topic" post page so people are notified of it before creating a topic.
On Fri, Nov 05, 2021 at 05:35:03PM -0700, Adam Williamson wrote:
- The given solution works for most people, but clearly many are not seeing it.
I suspect this is more of a universal truth than something easily improvable. We could fly a plane above every town on Earth and some people wouldn't see it. We could hire Mark Zuckerberg to transmit it direct to the eyeballs of everyone in the world (you know he can!) and someone would still manage not to see it. People are *really good* at not seeing documentation. :D
Heh. Probably true. But I'm _definitely_ seeing a lot of folks not finding this doc in specific.
- Directly linked to where we’re telling people to go for help, and where people are talking about their problems.
This seems trivial. We invented hyperlinks a long time ago, and the account system for the wiki and Ask is the same account system.
I guess I mean "linked" in a deeper sense. Found in (or at least very near) the same place, same kind of user experience. And, the wiki continues to be a minefield of outdated information. Like, the Common Bugs page prominently links to https://fedoraproject.org/wiki/Bugs_and_feature_requests, which links to https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow, which is... more than somewhat outdated.
- Gives a place to comment on and discuss the problem *other* than cluttering the bug in bugzilla.
This could equally be phrased as "encourages splitting the discussion of the bugs to a place where people already following them, notably including the maintainers, may never see it".
I think this kind of split is Good, Actually™! It separates initial triage (which we know from long sad experience is futile in bugzilla; RIP BugZappers) and user support / response from the business of solving the probem. I (not coincidentally) just wrote a whole long thing about this. https://ask.fedoraproject.org/t/questions-bugs-incidents-and-problems-oh-my/...
- Right now, *Lots* of people on Ask coming in with new questions about the no-sound-on-upgrade issue. Even if they don’t find it and avoid needing to ask, we can easily merge those into the main topic.
But you could also merge them into a single topic for the bug which has a prominent link to the common bugs page. Is that really a big difference?
We could do that, but then we're redirecting people twice, first to the single topic and then to the separate doc. And, I have a sense, as a user of other support services / forums, that having a post merged into "big general thing" can feel dismissive, whereas having it merged into "oh, yes, that's precisely a duplicate" does not.
That approach also doesn't have some of the other advantages, like voting on issues and measuring their individual activity.
- Conversely, when a person has a *different* issue, it’s easy to split that into its own help thread.
I don't really see where this is an advantage compared to the current system. In the current system there is no discussion, so there's nothing to split off. If people discuss different problems in a bug report, it's easy enough to ask them to file a new bug too. We could hide or delete their comments if we wanted to, but we tend not to do that sort of thing in Bugzilla as a matter of policy.
Yeah, Bugzilla doesn't have good tools for this -- there's no split, only "duplicate and clean up".
- And we can moderate and organize response in general to make sure people are seeing the most helpful advice and not getting misdirected.
Again, this doesn't seem like something you can't do right now. To me, we have two functions: documentation and discussion. The Common Bugs pages are documentation. Discourse is for discussion. The discussion is already happening on Discourse, so...what's the issue? I quite like that there *is* this distinction, honestly. I like common bugs entries to be clear, distinct and ideally authoritative. I don't think it would be *more* helpful for people to see a whole forum thread for every documented issue. It would just muddy the waters.
This is why I propose the separate category; that category can have more stringent rules. There's still a distinction between the first post in the topic and the comments, and we could make that stronger in several ways for this category (theming).
We _could_ do what Discourse does with posts in some of their own support categories (like https://meta.discourse.org/t/discourse-voting/40121/237) — they set it so replies are automatically deleted after a month, but move particularly useful or relevant replies to their own topics (and then those links persist). I'm not sure that's the best for this, but it's one possibility.
As I'm thinking about this, I guess maybe I just disagree with you about whether a forum thread would be helpful or muddy the waters. And I have no _particular_ data or experience either way to help decide who is right. :)
- Right now, the release-cycle QA process is the primary source of Common Bugs. But… maybe we’re missing things that users are finding?
Possibly? But I don't see how moving the information to Discourse helps with that. I used to read fedoraforum.org more or less cover-to-cover, in part as a source for common bugs. I don't do it any more because I don't have the time (and it's less a part of my job). Right now, I could read ask.fp.o as a source of things to put in common bugs, if I wanted. I don't because...I don't have the time and it's not really part of my job. Anyone else who wants to help could do so as well, though. The common bugs pages do not need to be in Discourse for this to happen.
That's true. I think, though, that this will make it easier for _more_ people to help identifiy things, and specifically the active Ask Fedora folks.
We set up a convenience mechanism in Bugzilla to 'nominate' things for common bugs (the CommonBugs keyword and special searches that key off that keyword and whiteboard contents). We could probably do something similar in ask.fp.o easily enough, to make it more convenient to 'flag' things there for inclusion. Again, without moving the common bugs pages themselves at all.
Yeah, absolutely. I read this whole post before starting to reply, but there's a lot, and I just now totally wrote almost exactly the thing you did here in a paragraph above which I have now deleted. :)
- Discourse’s notify-by-mail feature is nicer than following wiki page changes by mail.
- Moves us towards Ask Fedora as a first-top issue triage center, reducing Bugzilla load for maintainers *and* reducing end-user frustration with unmet expectations about Bugzilla response.
If what we're worried about is people discussing things in Bugzilla, we could probably come up with closer integration between the common bugs pages as they are and a discussion thread for each in Ask, for instance, without actually having the canonical common bugs information itself be part of a discussion thread.
That's not _the_ worry, just _a_ thing.
But yeah, there are definitely a lot of ways we could do that. See for example the Copr integration https://discussion.fedoraproject.org/c/projects-in-copr/54 with the Fedora Discussion instance.
Broader take:
So, it's mainly Kamil and I who maintain these pages these days. I wrote a lot of the template stuff.
Yes, making this belong to a broader group seems like a good goal to me.
I'm honestly fairly reluctant to support this change unless someone intends to recreate all the things I've already done to make it convenient to work on, or let me take paid time to recreate them all for Discourse, honestly.
I think we'd want it to be _at least_ as convenient, yes. And I guess I can see about finding you paid time, if we get to general agreement that it's a thing we want to do. (For what it's worth, over on the Ask thread, the response has been very positive.)
There are templates used to create the pages at Beta time and then update them for Final:
https://fedoraproject.org/wiki/Template:Common_bugs_header_prerelease https://fedoraproject.org/wiki/Template:Common_bugs_header_stable_release
As I'm picturing it, the category would be a standing thing, and we'd not make a new page every release. So the equivalent would just go in the category description and header, one time. Individual issues would be tagged with the corresponding release.
Oooh, another advantage, actually: this category could be marked as "Very High" in search priority, hopefully helping with the initial observation about visibility. (This also influences the posts that come up as "maybe you meant....?" when writing a new one.)
Right now, there's not a mechanism for automatically archiving issues tagged with older release numbers, but I'm already thinking about that, as it applies to the rest of Ask Fedora as well. We could do [several options for various possible] manual things as Ask Fedora moderators every six months, or we could just leave the older ones in the backscroll of the category.
there are templates used to provide accurate information and instructions when a bug is addressed by an update:
https://fedoraproject.org/wiki/Template:Common_bugs_update_testing https://fedoraproject.org/wiki/Template:Common_bugs_update_released
My thought is that we would use the Discourse Canned Replies feature https://meta.discourse.org/t/discourse-canned-replies/48296 to insert text in consistent way. It does not have a variable-substitution feature, though, so one would have to manually put the right ADVISORY in the right places. And rather than the cleverness in the updates_testing macro for the "noupdate" case, we'd probably just use different canned replies.
I'm thinking we'd use the "Add Staff Color" feature to highlight "official" replies, and also mark the answer as the "Solution" once the update is released (which would look similar to for example https://ask.fedoraproject.org/t/discover-is-always-asking-for-reboot/17888).
Or, we could edit these things into the first post in the topic. (Canned replies are available there too, despite "replies" in the feature name.)
(There exist other Discourse plugins that could do more, or we could even write our own, but I'd like to stay away from that.)
and, perhaps least obviously but most *usefully*, there's a fairly capable script I use for actually maintaining the pages:
https://pagure.io/fedora-qa/qa-misc/blob/master/f/commonbugs-update
this processes the page for a given release, parses it one issue at a time, and detects whether the issue is now addressed by an update, and lets you modify the page appropriately (adding the right template and moving the issue to the 'resolved' section if it's stable) if so. It saves a lot of tedious work doing this manually.
Of course, this is a double-edged blade, because it also significantly increases the esoterica of the whole thing, and also makes me more scared than I already am of editing the wiki page for fear of breaking your script.
BUT that said, if we get to the situation where you're on board with this as at least an experiment, and I can make the case for the value of your time directed to this, Discourse has an API https://docs.discourse.org/ that the script could be ported to, and maybe even made to run automatically and more frequently. (Or have it message bus triggered, whenever a bug with the "CommonBugs" keyword is updated?)
That script could handle the "ADVISORY" substitution issue, too, right? That is, fill out the full expanded text, rather than a template.
It could construct the initial post in the "Proposed Common Issues" category if someone tags a bug in the right way, and move it to the top-level if the bug is updated to "graduate" it. Or, the process could go the other way around, with the script updating bugzilla metadata based on the post in Discourse. (But I am getting ahead of things here, clearly.)
I suppose the other way I'd support this change is if someone else was volunteering to take over all the work of writing and maintaining these pages. But only if they were going to do it at least as well as Kamil and I do.
Yes, absolutely. My goal is to make it better not worse, and overall less work shared among more people.
On Sat, 2021-11-06 at 17:09 -0400, Matthew Miller wrote:
Yes, absolutely. My goal is to make it better not worse, and overall less work shared among more people.
So instead of going point-by-point, I'll just say this would be fine, but I'd feel rather better about it if the proposal:
* Acknowledged and had a definite plan to replace the existing tooling and practices at least at the same level as currently. * Came with people attached who are definitely committed to working on the implementation and all the work of writing issues, wrangling replies, tagging things, aging things out...
On Sat, Nov 06, 2021 at 11:55:39PM -0700, Adam Williamson wrote:
- Acknowledged and had a definite plan to replace the existing tooling
and practices at least at the same level as currently.
Okay, cool. Can you help me better define the "at the same level" benchmark? My stab at things that needed to make sure the new way meshes with the current process:
1. The new process needs to make sure that Bugzilla entries with CommonBugs keyword are triaged in a timely manner. 2. When proposed Common Issues* are accepted, the whiteboard field in Bugzilla is updated. 3. All accepted entries need to follow a consistent format, ideally using some form of templating. 4. We need templates to deal with special cases like those which require installer images, or where a workaround is needed even when an update is available. 5. Entries need to be updated with instructions when a candidate fix is available. 6. And further updated when a fix is released. 7. We figure out something to do about archiving at EOL time. (Although this doesn't necessarily need to be in place until... F38. Could be part of a general plan to archive older topics on Ask Fedora.) 8. We have new documentation covering the new procedures. 9. We have tooling in place and/or people commited to cover all of the above. 10. More automation would be lovely, but at least we don't want it _less_ automated than the current state.
Does that cover it? What did I miss.
- Came with people attached who are definitely committed to working on
the implementation and all the work of writing issues, wrangling replies, tagging things, aging things out...
Definitely have people _interested_. I'll see about _committed_. :)
I'm not proposing we do this until we hit the appropriate time in the F36 schedule, so I guess ~ beta freeze. That gives some time to line things up. Adam, would you be _interested_ in helping update the scripts and creating automation, if you had work time to do it? What would the tradeoffs be?
Also: although this isn't a change to Fedora Linux... maybe I should run this through the Changes process?
* Bikeshedding tangent: I prefer "Common Issues" to "Common Bugs", because it's broader and there's less potential for conflict between different possible technical and less-technical definitions of "bug". Like, I'm seeing some people On The Internet say, with apparent straight faces, that "bugs" are found during the testing phase and that once it's in production, it's a "defect" not a "bug".
On Sun, 2021-11-07 at 15:46 -0500, Matthew Miller wrote:
On Sat, Nov 06, 2021 at 11:55:39PM -0700, Adam Williamson wrote:
- Acknowledged and had a definite plan to replace the existing tooling
and practices at least at the same level as currently.
Okay, cool. Can you help me better define the "at the same level" benchmark? My stab at things that needed to make sure the new way meshes with the current process:
- The new process needs to make sure that Bugzilla entries with CommonBugs keyword are triaged in a timely manner.
- When proposed Common Issues* are accepted, the whiteboard field in Bugzilla is updated.
- All accepted entries need to follow a consistent format, ideally using some form of templating.
- We need templates to deal with special cases like those which require installer images, or where a workaround is needed even when an update is available.
- Entries need to be updated with instructions when a candidate fix is available.
- And further updated when a fix is released.
- We figure out something to do about archiving at EOL time. (Although this doesn't necessarily need to be in place until... F38. Could be part of a general plan to archive older topics on Ask Fedora.)
- We have new documentation covering the new procedures.
- We have tooling in place and/or people commited to cover all of the above.
- More automation would be lovely, but at least we don't want it _less_ automated than the current state.
Does that cover it? What did I miss.
That's more or less it, except that it doesn't cover how update- commonbugs helps a *lot* with points 5 and 6. Doing that manually is a drag.
- Came with people attached who are definitely committed to working on
the implementation and all the work of writing issues, wrangling replies, tagging things, aging things out...
Definitely have people _interested_. I'll see about _committed_. :)
Yeah, see, this is a fairly significant distinction. ;) Honestly, if people are crazy enough for this and you can get to the point where there's a system that will work and just give Kamil and I the user's guide, that would be fine too. I just don't want to get stuck in a bind at F36 Beta time where someone's decided moving common bugs would be a great idea but we have to figure out how to actually do that as we go along.
I'm not proposing we do this until we hit the appropriate time in the F36 schedule, so I guess ~ beta freeze. That gives some time to line things up. Adam, would you be _interested_ in helping update the scripts and creating automation, if you had work time to do it? What would the tradeoffs be?
The prospect doesn't exactly fill me with excitement, honestly, but if nobody else wants to do it yet this is still somehow super desirable, maybe. The tradeoffs would be with all the other stuff I have to do in the pre-F36 Beta time, like proposing criteria changes, updating the openQA packages to recent snapshots, adapting the openQA resultsdb reporting code to handle authentication, making openQA job scheduling handle Bodhi 're-trigger requests' messages once they're fixed, writing new tests for openQA (we have a backlog of test request tickets some of which are over a year old), finally getting somewhere with releasestream...
Also: although this isn't a change to Fedora Linux... maybe I should run this through the Changes process?
Hmm, I dunno if that'd help or just add bureaucracy, really.
- Bikeshedding tangent: I prefer "Common Issues" to "Common Bugs", because it's broader and there's less potential for conflict between different possible technical and less-technical definitions of "bug". Like, I'm seeing some people On The Internet say, with apparent straight faces, that "bugs" are found during the testing phase and that once it's in production, it's a "defect" not a "bug".
I don't really care a lot. I think the purpose of the page is pretty clear with either title, including the current one.
On Mon, Nov 08, 2021 at 08:54:04AM -0800, Adam Williamson wrote:
That's more or less it, except that it doesn't cover how update- commonbugs helps a *lot* with points 5 and 6. Doing that manually is a drag.
Ack. I will restate with greater emphasis there.
Definitely have people _interested_. I'll see about _committed_. :)
Yeah, see, this is a fairly significant distinction. ;) Honestly, if people are crazy enough for this and you can get to the point where there's a system that will work and just give Kamil and I the user's guide, that would be fine too. I just don't want to get stuck in a bind at F36 Beta time where someone's decided moving common bugs would be a great idea but we have to figure out how to actually do that as we go along.
Fair!
Adam, would you be _interested_ in helping update the scripts and creating automation, if you had work time to do it? What would the tradeoffs be?
The prospect doesn't exactly fill me with excitement, honestly, but if nobody else wants to do it yet this is still somehow super desirable, maybe. The tradeoffs would be with all the other stuff I have to do in the pre-F36 Beta time, like proposing criteria changes, updating the openQA packages to recent snapshots, adapting the openQA resultsdb reporting code to handle authentication, making openQA job scheduling handle Bodhi 're-trigger requests' messages once they're fixed, writing new tests for openQA (we have a backlog of test request tickets some of which are over a year old), finally getting somewhere with releasestream...
Okay. Let me see if I can find someone who does feel like this fills them with excitement. Because, yeah, that's a lot. :)
On Mon, Nov 08, 2021 at 08:54:04AM -0800, Adam Williamson wrote:
- The new process needs to make sure that Bugzilla entries with CommonBugs keyword are triaged in a timely manner.
- When proposed Common Issues* are accepted, the whiteboard field in Bugzilla is updated.
- All accepted entries need to follow a consistent format, ideally using some form of templating.
- We need templates to deal with special cases like those which require installer images, or where a workaround is needed even when an update is available.
- Entries need to be updated with instructions when a candidate fix is available.
- And further updated when a fix is released.
- We figure out something to do about archiving at EOL time. (Although this doesn't necessarily need to be in place until... F38. Could be part of a general plan to archive older topics on Ask Fedora.)
- We have new documentation covering the new procedures.
- We have tooling in place and/or people commited to cover all of the above.
- More automation would be lovely, but at least we don't want it _less_ automated than the current state.
Does that cover it? What did I miss.
That's more or less it, except that it doesn't cover how update- commonbugs helps a *lot* with points 5 and 6. Doing that manually is a drag.
What I'm thinking it would do for 5 and 6 is:
* For each topic in the Common Issues (including Proposed) category that isn't marked as solved,
* check periodically for bodhi updates (I think by looking for the Fedora Update System messages in bugzilla?),
* and if those updates were posted after the last such reply,
* post a reply to the topic with (filled-in) boilerplate appropriate to the candidate or expected fix state (and possibly other metadata from the topic itself).
(This bot would have permissions to reply in the Common Issues category, as would QA team members.)
I _think_ we would rely on humans to mark the issues as definitely "solved".
Okay, hmmm, before I go further with this, let me check something:
Package updates aside, how important is it for this process to be bugzilla-driven at the start? Or, in bugzilla at all? Is it:
- "migration requirement for with least possible change and annoyance", or - "bugzilla adds an important tracking element", or - "since these issues are _bugs_, bugzilla is inherent to the whole concept" - something else?
?
If we made the process for "nominate a bug" be "post in the Proposed Common Issues category" rather than "add CommonBugs to the bugzilla keyword field", what would we lose?
Advantages would be:
* More laziness for me (not needing to do steps 1 or 2 of the list above) (probably would still want automation to help with 5 and 6 though). This is non-trivial laziness, as 2 at least requires _writing_ to bugzilla, while 5 and 6 could just read.
* As I understand the semantics now, "CommonBugs" keyword means "maybe common bug?" and "CommonBugs + properly-formatted URL in the whiteboard field" means "actually common bug". Which is... kind of arcane. It seems like "is issue in Proposed category or the accepted one" is a lot more obvious.
On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote:
- As I understand the semantics now, "CommonBugs" keyword means "maybe common bug?" and "CommonBugs + properly-formatted URL in the whiteboard field" means "actually common bug". Which is... kind of arcane. It seems like "is issue in Proposed category or the accepted one" is a lot more obvious.
Addendum: I did the query for proposed common bugs http://bit.ly/fedora-commonbugs-proposed and while there are definitely good-faith proposals there, there also seem to be at least _some_ cases where someone has a bug that is important and urgent to them and therefore they have set a bunch of random keywords because they can.
If we instead make the entry-point on Ask, we at least have some opportunity to present the basic concept.
On Sun, 2021-11-21 at 17:18 -0500, Matthew Miller wrote:
On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote:
- As I understand the semantics now, "CommonBugs" keyword means "maybe common bug?" and "CommonBugs + properly-formatted URL in the whiteboard field" means "actually common bug". Which is... kind of arcane. It seems like "is issue in Proposed category or the accepted one" is a lot more obvious.
Addendum: I did the query for proposed common bugs http://bit.ly/fedora-commonbugs-proposed and while there are definitely good-faith proposals there, there also seem to be at least _some_ cases where someone has a bug that is important and urgent to them and therefore they have set a bunch of random keywords because they can.
Yeah, it happens occasionally. It's a two second fix, though. :D
On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote:
- More laziness for me (not needing to do steps 1 or 2 of the list above)
Well, forget laziness. I made a script[1] that does these things. And a bunch of other stuff, some of which is only partly done, but I think well enough along to invite others to look.
Please see https://ask.fedoraproject.org/t/new-common-issues-process-trial-next-steps/1... for the next phase of the experiment here, and let me know what you think (and if anyone is interested in helping)!
[1] https://pagure.io/issuebot/blob/main/f/issuebot.py
On Thu, Nov 4, 2021 at 4:43 PM Matthew Miller mattdm@fedoraproject.org wrote:
Specifics
We’d create a new top-level category, “Common Issues”. Posting directly in the category would not be allowed. Instead, there would be a *subcategory*, “Proposed Common Issues”.
New topics in “Proposed Common Issues” would use the template feature, prompting for the necessarily information and keeping the format consistent. Unfortunately, there are no macros to do the fancy things the current wiki process uses, which I will freely admit is a drawback.
Each topic would be tagged with the release that it corresponds to (and, ideally other tags, like the installation / upgrade / workstation / etc. sections on the wiki — we could make that mandatory or just by convention).
Members of the QA team (based on group membership, automatically once [Does `sso overrides groups` work with Oauth2? - sso - Discourse Meta][4] is fixed upstream) and possibly other volunteers will be marked as category moderators, and so can promote topics to the higher-level “Common Issues” after vetting them.
And, we’d turn on voting, and ask people to vote for issues that they have also experienced. Not scientific, but gives a measure that we don’t have now.
Soo... I finally had time to read this. I need a few things clarified: 1. In the Proposed Common Issues category, how are the topics intended to look like? Will the initial topic description be a question ("my sound is broken, how do I fix it?") and then somebody will provide a solution which will get marked as such, or will the initial topic description be already a solution (i.e. a similar text to what is currently on the CommonBugs wiki)? 2. In the Common Issues category, will the topics look the same as in 1) (we'll simply re-tag them there), or differently? (e.g. a question-style in Proposed, a solution-style in actual Common Issues). 3. Can we easily move a topic (or add a tag to it) into the Proposed Common Issues category, when it is currently in a completely different one? And similarly, we can easily move out a topic from Proposed Common Issues to some generic "Ask" category? 4. The solution text often needs maintenance. Some clarifications, newly discovered workarounds, etc. If the original solution text was created by a community member, is it expected that we'll simply edit his/her post? Or what do we do? On wiki, it is owner-less, which avoids the problem "somebody edited my post, and it's still displayed under my name, but those aren't my words, and I don't like it".
I'm sure I'll have more questions after I think about it a bit more :-)
Overall, I don't have strong opinions on the proposal. A wiki is easier for us, but otoh more community involvement would definitely be nice. We could try a different approach as an experiment. If we do, it might be good to start it right away, so that some initial problems are resolved before the F36 cycle runs in full swing.
On Tue, Nov 09, 2021 at 02:38:59PM +0100, Kamil Paral wrote:
- In the Proposed Common Issues category, how are the topics intended to
look like? Will the initial topic description be a question ("my sound is broken, how do I fix it?") and then somebody will provide a solution which will get marked as such, or will the initial topic description be already a solution (i.e. a similar text to what is currently on the CommonBugs wiki)?
I think the topic titles will be the same as with Common Bugs now, like "Configured repositories in Discover jump around in the list" or "Clipboard is not shared with KDE virtual machines".
The site name, "Ask Fedora", makes me _want_ to force them into the form of a question just... to make it all nice... but in practice most topic tiles are in the form of a problem summary already. ("Closing the laptop lid does not turn off the screen", "2-finger scroll occasionally disabled".) So I think that keeping to the current title format is good.
I can go either way on whether the first post in the topic should also provide the solution, or whether we should used the answer-solution format.
As I'm reviewing some of the previous wiki pages now, I actually am kind of inclined to think that it's better to have stronger problem/solution separation. But I could be convinced either way.
- In the Common Issues category, will the topics look the same as in 1)
(we'll simply re-tag them there), or differently? (e.g. a question-style in Proposed, a solution-style in actual Common Issues).
I was thinking just move them, yeah.
- Can we easily move a topic (or add a tag to it) into the Proposed Common
Issues category, when it is currently in a completely different one? And similarly, we can easily move out a topic from Proposed Common Issues to some generic "Ask" category?
Yes to both. And URLs for topics do not include the category, so moving them will not break any existing external links.
- The solution text often needs maintenance. Some clarifications, newly
discovered workarounds, etc. If the original solution text was created by a community member, is it expected that we'll simply edit his/her post? Or what do we do? On wiki, it is owner-less, which avoids the problem "somebody edited my post, and it's still displayed under my name, but those aren't my words, and I don't like it".
There is a setting "Make new topics wikis by default" which we would enable for these categories. It doesn't make the post ownerless, though. I think we could set these expectations reasonably in the description of the category. And if someone at some point really doesn't want their name attached, we can always move the Solved check.
I'm sure I'll have more questions after I think about it a bit more :-)
Sure. :)
Overall, I don't have strong opinions on the proposal. A wiki is easier for us, but otoh more community involvement would definitely be nice. We could try a different approach as an experiment. If we do, it might be good to start it right away, so that some initial problems are resolved before the F36 cycle runs in full swing.
That does seem like a good idea. Maybe not quite _right away_, but soon. Would you suggest duplicating the F35 Common Bugs, or making some _possible_ F36 ones based on Rawhide issues?
On Wed, Nov 10, 2021 at 1:04 AM Matthew Miller mattdm@fedoraproject.org wrote:
I think the topic titles will be the same as with Common Bugs now, like "Configured repositories in Discover jump around in the list" or "Clipboard is not shared with KDE virtual machines".
The site name, "Ask Fedora", makes me _want_ to force them into the form of a question just... to make it all nice... but in practice most topic tiles are in the form of a problem summary already. ("Closing the laptop lid does not turn off the screen", "2-finger scroll occasionally disabled".) So I think that keeping to the current title format is good.
The topic titles wouldn't work as questions, I think. Imagine "Why do I have no sound in F35?". There can be several different issues related to sound, and so you need to distinguish them right in the title, to allow people to find the right one. So e.g. "F33->F35 upgrade might break sound", "Creative sound cards don't work in F35", "HDMI sound redirection is broken in F35", etc. The title is only created after the problem is well understood.
I can go either way on whether the first post in the topic should also provide the solution, or whether we should used the answer-solution format.
As I'm reviewing some of the previous wiki pages now, I actually am kind of inclined to think that it's better to have stronger problem/solution separation. But I could be convinced either way.
I feel a bit like wasting the reader's time to let them first read through a question, and then follow a link to a marked solution. I know this is how it would look if it was a regular question-answer topic in the forum. But the wiki style provides a more efficient and readable way to learn about high-profile issues (straight to the point, exact), and going to a forum style would be a downgrade.
- In the Common Issues category, will the topics look the same as in 1)
(we'll simply re-tag them there), or differently? (e.g. a question-style
in
Proposed, a solution-style in actual Common Issues).
I was thinking just move them, yeah.
So in order to provide good readable descriptions to our users (solution-style), they would either need to be written in this style also in Proposed Common Issues, or rewritten into a new topic. So the actual "why is X broken? - have you tried Y? - and what about Z?" discussion would occur probably elsewhere, in some generic Ask category, and once properly discovered, somebody would rewrite it into a solution-style topic into Proposed Common Issues, where we would verify it and promote it (move it) into Common Issues if it's good enough. Does it make sense, am I imagining it correctly?
- Can we easily move a topic (or add a tag to it) into the Proposed
Common
Issues category, when it is currently in a completely different one? And similarly, we can easily move out a topic from Proposed Common Issues to some generic "Ask" category?
Yes to both. And URLs for topics do not include the category, so moving them will not break any existing external links.
What about changes to topic titles, do they change the URL? (That would be very inconvenient, perhaps even a deal-breaker).
- The solution text often needs maintenance. Some clarifications, newly
discovered workarounds, etc. If the original solution text was created
by a
community member, is it expected that we'll simply edit his/her post? Or what do we do? On wiki, it is owner-less, which avoids the problem "somebody edited my post, and it's still displayed under my name, but
those
aren't my words, and I don't like it".
So the process There is a setting "Make new topics wikis by default" which we would enable for these categories. It doesn't make the post ownerless, though. I think we could set these expectations reasonably in the description of the category.
That might work. I think it also implies that you'll not simply take some topic from a general Ask category and tag it into Proposed Common Issues, because that wouldn't convert it into wiki style, wouldn't be in a solution-style text, and also the topic authors might be negatively surprised.
So, we'll need a way to tag interesting topics in general categories as "look, this might be a frequent and important bug", and then a set of volunteers who sift them and convert selected ones into Proposed Common Issues, and then QA goes through those and promotes some of them into Common Issues. Ugh, is it too complex?
Overall, I don't have strong opinions on the proposal. A wiki is easier for
us, but otoh more community involvement would definitely be nice. We
could
try a different approach as an experiment. If we do, it might be good to start it right away, so that some initial problems are resolved before
the
F36 cycle runs in full swing.
That does seem like a good idea. Maybe not quite _right away_, but soon. Would you suggest duplicating the F35 Common Bugs, or making some _possible_ F36 ones based on Rawhide issues?
I'd start with F36. There won't be many users complaining about F36 before F36 Branched/Beta in there, but that's OK, we can at least experiment with the process.
Just to be clear, I'm still not convinced this is a good idea :-) But why not try it. Perhaps we'll then come up with some mixture of both approaches, or at least realize some shortcomings.
On Thu, 2021-11-11 at 12:20 +0100, Kamil Paral wrote:
- Can we easily move a topic (or add a tag to it) into the Proposed
Common
Issues category, when it is currently in a completely different one? And similarly, we can easily move out a topic from Proposed Common Issues to some generic "Ask" category?
Yes to both. And URLs for topics do not include the category, so moving them will not break any existing external links.
What about changes to topic titles, do they change the URL? (That would be very inconvenient, perhaps even a deal-breaker).
Oh, yeah, this is one possibly-subtle feature of the wiki approach: the common bugs issue template includes an anchor. In e.g.:
{{Common bugs issue|no-sound-on-upgrade|No sound after upgrade|2016253}}
the 'no-sound-on-upgrade' text is used as the anchor title, and the "link to this item" link it generates uses that anchor. So we can change the human-readable title - "No sound after upgrade" - without changing the anchor link, which is what we put in the bug whiteboard and what should be used when linking to the issue from anywhere else.
As I'm reviewing some of the previous wiki pages now, I actually am kind of inclined to think that it's better to have stronger problem/solution separation. But I could be convinced either way.
I feel a bit like wasting the reader's time to let them first read through a question, and then follow a link to a marked solution. I know this is how it would look if it was a regular question-answer topic in the forum. But the wiki style provides a more efficient and readable way to learn about high-profile issues (straight to the point, exact), and going to a forum style would be a downgrade.
I created a test topic to play aruond with what this would look like. Take a look:
https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35/18...
In most cases, I think the solution part will be concise enough that it should be entirely displayed within the solution box in the first post. The main problem I see is that "code" formatting is lost in the solution quote.
So in order to provide good readable descriptions to our users (solution-style), they would either need to be written in this style also in Proposed Common Issues, or rewritten into a new topic. So the actual "why is X broken? - have you tried Y? - and what about Z?" discussion would occur probably elsewhere, in some generic Ask category, and once properly discovered, somebody would rewrite it into a solution-style topic into Proposed Common Issues, where we would verify it and promote it (move it) into Common Issues if it's good enough. Does it make sense, am I imagining it correctly?
Yeah. As I'm imagining it, we'd allow replies in the Proposed Common Issues topics, but they'd be limited to discussion about the text of the problem, whether it should be promoted, etc. If someone replies about the bug itself, we can move the reply (easily done) to a new or existing topic.
Then, when we promote the topic, we'd hide any remaining replies. (Still there for history but regular users wouldn't see them.)
What about changes to topic titles, do they change the URL? (That would be very inconvenient, perhaps even a deal-breaker).
The "real" identifier is a number. The above link works as
* https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35/18...
but also
* https://ask.fedoraproject.org/t/18243
or
* https://ask.fedoraproject.org/t/something-else-altogether/18243
It _also_ works as
* https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35
without the number, but... our tools obviously should avoid that.
There is a setting "Make new topics wikis by default" which we would enable for these categories. It doesn't make the post ownerless, though. I think we could set these expectations reasonably in the description of the category.
That might work. I think it also implies that you'll not simply take some topic from a general Ask category and tag it into Proposed Common Issues, because that wouldn't convert it into wiki style, wouldn't be in a solution-style text, and also the topic authors might be negatively surprised.
True.
So, we'll need a way to tag interesting topics in general categories as "look, this might be a frequent and important bug", and then a set of volunteers who sift them and convert selected ones into Proposed Common Issues, and then QA goes through those and promotes some of them into Common Issues. Ugh, is it too complex?
I think the "tag" process and "convert into proposed" can be combined. Basically all you'd do is reply-as-linked-topic from the proposed topic and put your reply in the Proposed Common Issues category. Then that's what QA (including, in my mind, new volunteers from Ask) would consider to promote.
Just to be clear, I'm still not convinced this is a good idea :-) But why not try it. Perhaps we'll then come up with some mixture of both approaches, or at least realize some shortcomings.
Yes, thanks. I'm also not sure it's the _best_ way, but I think it _might_ be better. We can see!
On Sat, Nov 13, 2021 at 07:41:53PM -0500, Matthew Miller wrote:
I created a test topic to play aruond with what this would look like. Take a look:
https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35/18...
In most cases, I think the solution part will be concise enough that it should be entirely displayed within the solution box in the first post. The main problem I see is that "code" formatting is lost in the solution quote.
The more I think about it, the more I think that we should leave "solution" for the state when the issue is actually resolved, and put work-arounds and other helpful information the top post.
Then, when a release goes EOL, we should (programmatically) mark all of the Common Issues topics related to a release as Archived. I guess probably also any still-pending Proposed ones. Possibly also move these to an Archived Common Issues topic, but I'm not sure about that.
Anyway. Enough for today. I'll post about this on Ask next week sometime :)
Hi,
I suggest just to post Booting related Bugs on the Web and implement a "F.H.B." tool ( Frequently Hit Bugs ) in the Distro.
You may ask "Why?"
If the system boots, but i.e. it's a network problem occurs, a local Bugs-and-theire-Solutions List would help to solve it fast.
How do we get this?
It does not need to be fancy, a simple onepage Website presented in the Defaultbrowser would be enough. This also gives a good connectivity to "Ask Fedora" as that content is already HTML.
The script that creates this, just needs to stich some HTML&CSS headers together and combines selected Bugs & Solutions into the page. Simple approach. Simple Solution.
On Mon, Nov 29, 2021 at 06:29:37PM -0000, Marius Schwarz wrote:
I suggest just to post Booting related Bugs on the Web and implement a "F.H.B." tool ( Frequently Hit Bugs ) in the Distro.
You may ask "Why?"
If the system boots, but i.e. it's a network problem occurs, a local Bugs-and-theire-Solutions List would help to solve it fast.
Maybe. I'm assuming that at this point most people with a computer also have another device (a phone, at least) with internet access.
How do we get this?
It does not need to be fancy, a simple onepage Website presented in the Defaultbrowser would be enough.
But how does the content get there?
This also gives a good connectivity to "Ask Fedora" as that content is already HTML.
The script that creates this, just needs to stich some HTML&CSS headers together and combines selected Bugs & Solutions into the page. Simple approach. Simple Solution.
What is it stitching it _from_? How does it get into the install media? How do we update it? What if it's a problem discovered after we go "gold"? Do we pull back the release?