I wonder if we should have a (sub-)category for guides that are meant to be used with applications provided with Qubes OS, but that are not specific to Qubes OS…
I see the interest of guides like this one, and tips and tricks more generally that make a Qubes OS experience better (by some definition of better). But I’m also well aware that they’re not specific to Qubes OS, like in this case, and I don’t think that accumulating general advice in community guides is a good thing in general.
Maybe I’m thinking of some category like “All around Qubes” but for community guides.
The whole forum is full of very useful information which one cannot find in documentation. I would even go further and suggest to organize a system through which this information goes into community provided docs (properly edited and formatted).
I’m inclined to disagree here. This is a potential can of worms. We’ve had as a long-time policy to have all the forum exclusively for Qubes-related content. So if some advice has no Qubes-specific answers it should not be posted here.
Otherwise it becomes very hard to moderate. This is especially true for guides which theoretically have to be maintained. If we open it to any guide, the deprecation potential is immense.
carification": “configuiring WiFi” is fine even though NetworkManager is not Qubes-specific. But by default it’s available so it can help anyone with Qubes. On the opposite side, configuring customizing a specific custom text editor (e.g. VIM) would not.
I suggest that the community guides should state clear details of the Qubes release, templates and tools used, and any other relevant info. This will prevent lots threads from people trying to apply iptables instead of nft, using the wrong template for the job, and generally feeling lost.
This info has to be updated, of course, if possible - at least for every successful implementation with subsequent templates, releases, etc.
Ex. “Qubes 4.2 Wireguard sys-vpn [R4.2rc4][fedora-38][Network-Manager]”
followed by (also as an example):
“Qubes 4.2 Wireguard sys-vpn [R4.2rc4][fedora-38][fedora-39][Network-Manager]”
(when and if the Guide applies to fedora-39 templates too)
I think this is a great idea, and the post by @solene provides a good example. I was already implementing her idea before I read this post. Guides like this one make Qubes more useful, which makes them relevant to Qubes.
Placing a new Community Guides category under All Around Qubes mitigates some of the concern about content moderation, since the category already restricts access. Perhaps there a way to restrict creation of new posts to those with a track record of providing Community Guides more directly related to Qubes.
My bad, about the QR code guide, I initially thought about doing something directly in the clipboard sharing system, but I realized this wouldn’t be ideal. Then I started to think at making a dedicated VM to generate the QR code, but I quickly realized this was really pointless to move the data from a qube to another with no benefit.
So I ended up writing a stripped down text that works, but in the end it’s really not Qubes OS specific. In fact, I wrote about this idea 5 years ago
The thing with this is that requires an arbitration, which requires moderator work. And that is a scarce resource. Furthermore, if barriers are not clear people will be confused as to why they can’t do something. Or feel moderators are bing unfair. And I’d like to reduce situations like this as much as possible.
Perhaps one could simply move that guide to All Around Qubes and not create Guides sub-Category. I don’t expect a lot of guides like that anyway, but they might indeed make Qubes more useful.
On this one I’ll align with @deeplow who not only has the experience of managing all of this concretely, but is also making a persuasive point IMHO.
What I’d like us to do
With that in mind, my preferred outcome would be for you @solene to relocate the guide to, for example, your personal blog / website / notes, for the forum topic to be closed (I can do that part), and finally to for us all (moderation team, guide authors) to use it as a real-world reference scenario going forward.
Why this would be a good reference scenario/story
I think it is a good reference story because:
no one can seriously refute the usefulness of @solene’s contributions to this forum
there is a broad agreement among the participants in the thread that the tip was interesting and useful
so that makes for a very cleanly principled decision regarding the on-topic / off-topic boundary
Why looking for reference stories in the first place?
Since what is on and off-topic will always be a matter of judgment call, I think it is useful to have a reference framework against which the consistency of moderation decisions can be evaluated for all the cases where, talking about myself here, an initial judgment may come biased in detriment of the guide author. (I won’t hide that I may have had many less doubts if the guide had been created by a 30-min-old account, rather than by @solene in this case.)
There were some posts i saw that seemed to be around people making some more steps in understanding more of network related matters. That is perhaps not directly qubes os related, although i do find that qubes lends itself for experimentalist/hands-on learning.
I thought about “tagging” the title with #qubes-agnostic or something like that…, before i came across this post.
To me, it seems to be rather nice to come together as a community(can the Q-image replace the Q in the text Qubes? ) here on this forum, sharing what we feel like sharing. However, i understand very well that there are heavy weighing concerns regarding maintenance/moderation.
Regarding the tagging of guides for specific versions …, to me it would make more sense to attempt canonicalized entries, that document differences between versions, if that is an option (some times the guides might be waaay to long and would probably be better of as split posts, preferably with a “canonical” post that lists the guides).
(the thing right beside the category name when creating or editing a post/wiki page)
) here on this forum, sharing what we feel like sharing. However, i understand very well that there are heavy weighing concerns regarding maintenance/moderation.