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 <mat...@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. > > ---- > > [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/175606 > [5]: > https://ask.fedoraproject.org/t/proposal-migrate-common-bugs-from-the-wiki-to-ask-fedora/17794?u=mattdm > > -- > Matthew Miller > <mat...@fedoraproject.org> > Fedora Project Leader > _______________________________________________ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@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 > -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
