On Wed, Nov 10, 2021 at 1:04 AM Matthew Miller <mat...@fedoraproject.org>
wrote:
> I think the topic titles will be the same as with Common Bugs now, like
> "Configured repositories in Discover jump around in the list" or "Clipboard
> is not shared with KDE virtual machines".
>
> The site name, "Ask Fedora", makes me _want_ to force them into the form of
> a question just... to make it all nice... but in practice most topic tiles
> are in the form of a problem summary already. ("Closing the laptop lid does
> not turn off the screen", "2-finger scroll occasionally disabled".) So I
> think that keeping to the current title format is good.
>
The topic titles wouldn't work as questions, I think. Imagine "Why do I
have no sound in F35?". There can be several different issues related to
sound, and so you need to distinguish them right in the title, to allow
people to find the right one. So e.g. "F33->F35 upgrade might break sound",
"Creative sound cards don't work in F35", "HDMI sound redirection is broken
in F35", etc. The title is only created after the problem is well
understood.
> I can go either way on whether the first post in the topic should also
> provide the solution, or whether we should used the answer-solution format.
>
> As I'm reviewing some of the previous wiki pages now, I actually am kind of
> inclined to think that it's better to have stronger problem/solution
> separation. But I could be convinced either way.
>
I feel a bit like wasting the reader's time to let them first read through
a question, and then follow a link to a marked solution. I know this is how
it would look if it was a regular question-answer topic in the forum. But
the wiki style provides a more efficient and readable way to learn about
high-profile issues (straight to the point, exact), and going to a forum
style would be a downgrade.
>
> > 2. In the Common Issues category, will the topics look the same as in 1)
> > (we'll simply re-tag them there), or differently? (e.g. a question-style
> in
> > Proposed, a solution-style in actual Common Issues).
>
> I was thinking just move them, yeah.
>
So in order to provide good readable descriptions to our users
(solution-style), they would either need to be written in this style also
in Proposed Common Issues, or rewritten into a new topic. So the actual
"why is X broken? - have you tried Y? - and what about Z?" discussion would
occur probably elsewhere, in some generic Ask category, and once properly
discovered, somebody would rewrite it into a solution-style topic into
Proposed Common Issues, where we would verify it and promote it (move it)
into Common Issues if it's good enough. Does it make sense, am I imagining
it correctly?
>
> > 3. Can we easily move a topic (or add a tag to it) into the Proposed
> Common
> > Issues category, when it is currently in a completely different one? And
> > similarly, we can easily move out a topic from Proposed Common Issues to
> > some generic "Ask" category?
>
> Yes to both. And URLs for topics do not include the category, so moving
> them
> will not break any existing external links.
>
What about changes to topic titles, do they change the URL? (That would be
very inconvenient, perhaps even a deal-breaker).
> > 4. The solution text often needs maintenance. Some clarifications, newly
> > discovered workarounds, etc. If the original solution text was created
> by a
> > community member, is it expected that we'll simply edit his/her post? Or
> > what do we do? On wiki, it is owner-less, which avoids the problem
> > "somebody edited my post, and it's still displayed under my name, but
> those
> > aren't my words, and I don't like it".
> So the process
> There is a setting "Make new topics wikis by default" which we would enable
> for these categories. It doesn't make the post ownerless, though. I think
> we
> could set these expectations reasonably in the description of the category.
>
That might work. I think it also implies that you'll not simply take some
topic from a general Ask category and tag it into Proposed Common Issues,
because that wouldn't convert it into wiki style, wouldn't be in a
solution-style text, and also the topic authors might be negatively
surprised.
So, we'll need a way to tag interesting topics in general categories as
"look, this might be a frequent and important bug", and then a set of
volunteers who sift them and convert selected ones into Proposed Common
Issues, and then QA goes through those and promotes some of them into
Common Issues. Ugh, is it too complex?
> Overall, I don't have strong opinions on the proposal. A wiki is easier
> for
> > us, but otoh more community involvement would definitely be nice. We
> could
> > try a different approach as an experiment. If we do, it might be good to
> > start it right away, so that some initial problems are resolved before
> the
> > F36 cycle runs in full swing.
>
>
> That does seem like a good idea. Maybe not quite _right away_, but soon.
> Would you suggest duplicating the F35 Common Bugs, or making some
> _possible_
> F36 ones based on Rawhide issues?
>
I'd start with F36. There won't be many users complaining about F36 before
F36 Branched/Beta in there, but that's OK, we can at least experiment with
the process.
Just to be clear, I'm still not convinced this is a good idea :-) But why
not try it. Perhaps we'll then come up with some mixture of both
approaches, or at least realize some shortcomings.
_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
