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/17910 > > - 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. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ 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
