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-...
> - 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.)
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.
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(a)fedoraproject.org>
Fedora Project Leader