OK, from all these contributions I made a generic representation of what people want (with some comments). Basically I just mashed all opinions together:
Working
Verified by at least two users How to prove that you have completed a guide?
Working system versions specified
Well explained
Can be followed without understanding the topic
Is this the same as “can be followed verbatim”?
Further specification required. How dumb high quality guide user is?
Well documented
Unnecessary details are hidden in formatting
i.e. references / see also header, “hide detail” feature
Consistent create templates?
Can be followed verbatim
Well formatted
Proper usage of headers Specification required
As visual as possible
Screenshots or code fields (where applicable)
Security implications must be specified
If there are none, it must say so.
Impacts wide range of users Why leave niche guides out?
I think it is mostly possible to work around this problem. Instead of explaining the basics, just don’t explain them, but provide instructions.
Unless there is a specific SOP standard you want to use, I suggest looking in general direction of already existing high quality documentation. I really like gentoo wiki, how about we take their guidelines and adapt them?
p.s. It doesn’t mean we cannot follow the spirit of SOPs, we just need to start from something.
Great idea! Although it would be hard to manage it as the size of community changes. Also mediocre guide may just be there long enough.
Is it possible to make it proportion of upvotes against number of views + maybe some time restriction (just so the guide wouldn’t be marked high-quality with the first votes and views immediately)?
Do you have a link of an example of what you like? The reason I recommended SOPs is because they are specifically designed to solve the huge problem we have regarding Qubes’s seriously steep learning curve. Qubes is hands down the best operating system in existence by far, the problem is the % of people capable of using it effectively is tiny and mostly comprised of programmers. I think if usability and documentation was improved, it would open things up to the huge number of people in other technical fields like engineering, sciences, etc and would cause the number of Qubes users to skyrocket
I think we should stop making it heavy to ourselves unnecessarily claiming using Qubes OS is hard. Creating one’s threat model, then installing Qubes and put it in a deployment phase is a challenge, I’d agree, but using it from that point is as easy as Windows, or Android.
Any OS is hard to learn when you start with it, not to mention to install it. Qubes OS is no exception to this by any mean.
This may be true from a subjective standpoint, but you underestimate the depth to which people are trained to their OS, how relatively fundamentally different Qubes is, and how big of a learning curve that results in. I don’t think too many people are complaining about the difficulty after getting past the curve. (Even then, Qubes isn’t exactly intuitive, and this isn’t as much a UI/dev issue as it is that Qubes as a concept is just so fundamentally different from what people expect.)
I think the biggest issue with Qubes OS for people starting using it is that their knowledge from other OS is not directly applicable (only partially in AppVM). So they have to learn a new OS and new way of thinking.
How that differs Qubes from any other OS? “Hey, where to click to get internet browser”? I think you are looking at the things from self perspective: as an advanced user you’re thinking on a regular Windows user. Nope. Advanced users of any OS will adjust easily for their needs (@GWeck for example, me…). Regular users will adjust easily for their needs (“where is browser, where is Word, where is TikTok…”) - just offer them default installation, from the whole OS they will most likely customize wallpapers, either under Windows or Qubes.
By asking to provide the logs, as I mentioned in my original post.
I don’t think that all other requirements are so important, apart from this one. People will probably not be able to reproduce the result with a not well documented, inconsistent guide. It the guide is working, it is relatively easy to improve its visible representation. Other users can do it themselves.