Proposal: Migrate "Common Bugs" from the wiki to Ask Fedora

Background

Every release since possibly the dawn of time (or, at least, Fedora Core 5), we make a Common Bugs page 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 up 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 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 :eureka:

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 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 here on Ask and on the Fedora Test mailing list. Discuss where you feel most comfortable and I’ll try to link the results.

3 Likes

+1 on this initiative from your part, $USER can find here if their problems are present there after installing or upgrading their system, like a first wall to search before asking.

we also can create a category for that purpose… I think

Regards.,

More advantages I’ve thought of in the seconds after hitting “send”:

  • If an issue spans multiple releases, we can easily tag the same issue in both, rather than copying and pasting between wiki pages and possibly getting information out of sync.

  • We have a wiki-post topic “https://discussion.fedoraproject.org/t/this-is-a-list-of-commonly-asked-questions/76986”, but that’s maintained somewhat arbitrarily and sporadically by hand. The proposed approach would be:

    • more systematic
    • open to more involvement
4 Likes

Binging the “change set” of a version to ask.fedora, or at least a pinned link, would be very useful, that things keeping together.

This is a great idea.

1 Like

2 posts were split to a new topic: Quick Docs in Ask?

I vote for this proposal to get this things into a bigger arena. I would also suggest that we should introduce also bug-charts (bugzilla) for the most important bugs which have not found a solution. The reason for this proposal is, that bug reporting can be very frustrating without any feedback or a solution, fix etc. . So the community members are knowing what are most important bugs and maybe they will motivated to add more manpower into the project, if it’s possible and useful.

1 Like

Here’s another example, by the way, with Fedora Linux 34 this time: https://discussion.fedoraproject.org/t/i-cant-upgrade-from-fedora-33-to-fedora-34-kde-spin-via-command-line/68767?u=mattdm

I don’t blame people at all — we don’t make this visible enough.

Oooh, another advantage, actually: the “Common Issues” category could be marked as “Very High” in search priority, hopefully helping with visibility, both when people actively search and in the similar topics feature.

1 Like

Okay, so, the folks over on the QA team list are a bit skeptical but willing to try it out, especially if it means more people interested in helping.

Specifically, I came up with this list of features of the new process we need in order to make this an improvement from the QA team perspective. It’s fair that the new process needs to be an improvement from the old, not a step backwards.

So here’s the list:

  1. The new process needs to make sure that Bugzilla entries with the CommonBugs keyword are triaged in a timely manner. This is currently helped by a script, the commonbugs-update tool, which QA team members run by hand periodically.
  2. When proposed Common Issues are accepted, the whiteboard field in Bugzilla is updated. (Also handled by the script.)
  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 thisdoesn’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 committed 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.

I’m playing around with some things on the site now (not public yet). If you’re interested in being part of the team working on this … well, hold on for a little bit, but when I’m ready I’ll start a new thread asking for volunteers (both for working on the process and tooling, and for helping maintain the list in the future).

1 Like

Moving on to the next steps: casperbiering/test