Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
<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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux