I got some useful feedback in another discussion, but I though it would be more constructive to reply in this thread.
I linked to the ArchWiki as a basic source of truth with the assumption that most Fedora users would find it convenient to fact-check / check for article updates before committing to modifying their setups.
I actually got the gumption to create my first post when it was clear plenty of Fedora users either don’t use or know about ArchWiki. This includes both new Fedora users creating posts and not finding wiki information that’s written in plain text, and it also includes Fedora veterans with good intentions who provide outdated or questionable fixes.
This might have to do with Fedora achieving “Normie Status” (and Windows 10+ turning into a wrapper around a virtual Las Vegas strip-mall). It might actually be the case where the modern Zoomer has never heard of or Googled or TikTok trended the string “ArchWiki”, but you say “Fedora” and they say “Oh, isn’t that Linux? I heard the Linux guy uses Fedora.”
Discourse has helpfully created some metadata links to other users encountering the same issue in the post I created (scroll down to Related Topics).
If you follow the rabbit hole of these threads, you’ll see Fedora users asking for help, playing kernel parameter roulette, getting endlessly frustrated, and being told to stop thrashing around, nuke
dnf --allowerasing, and replacing it with
No, no, no!!!
It’s a single, 257 byte drop-in file. 20 additional bytes for the folder tree on btrfs. What a tragedy.
Yes, lots of fixes are available in places like ArchWiki, but ArchWiki is randomized through human error. Anyone who’s gone deep into ArchWiki knows it’s very easy to find yourself 3 hours in, totally overloaded with information, dozens of tabs open, and you just miss stuff like this.
I would argue yes, it is indeed, easy to miss ArchWiki article: PipeWire: section 5.1.13, and no, it’s not enough that ArchWiki exists, and Fedora exists, so therefore Fedora users will intuitively connect the two.
It needs more links and metadata on the fedoraproject.org side, so users who encounter this issue have at least a fighting chance of getting on with their day, with as little time wasted as possible.
Also, you’ll notice the fix for this actually is on the WirePlumber side, not the PipeWire side. If you don’t send the right strings to your search engine, they seem great at not picking up on these kind of basic connections. Also we’re assuming the Fedora user even knows or can figure out they are running the PipeWire audio server plus WirePlumber, or that they even know what an audio server is!
At the very least I’m hoping the post saves a few users from taking the drastic step of force-swapping their distro-recommended audio server just to stop popping noises!
I’m also on Immutable KDE and the thought of someone
pulseaudio in desperation actually triggers me.
I’ll just chime in here and say if there already were a Fedora Quick Docs or HOW-TO section, my intuition would have been to post the crackling audio issue to such a section. When I ended up picking Proposed Common Issues, it did not intuitively seem like the right place to post a snippet, but it seemed like the least bad place to get feedback, and the best place to get the post into the least bad sub-forum.
Ask Fedora kinda works if you squint, but people there are mostly getting individual problems solved and they move on. Having long back-and-forth threads mixed with short answer snippets in one sub-forum is clearly not the best UX.
I think a unsaid truth here is that somebody posting something on the Fedora forums is far from ideal compared to proper documentation, under source control, with an issue tracker and CI. As soon as I post my fix on the forums it’s technically outdated, I could get hit by a bus or retire and the post never gets updated, then it’s inaccurate, then it’s hurting instead helping.
I’ll also say having a bot that turns all Fedora Quick Doc entries into Discourse posts would be “nice”. I could contribute to the docs, close my Ask Fedora post, and know in the future if the problem changes or goes away, enough eyes will be on it to stay accurate.