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. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
