I think this is an important point. The documentation is written from the point of view of someone using Qubes OS. There should be newbie-friendly explanations. Not that I really know how to do it.
Good Point. Perhaps we could find some new comer users, to try out Qubes, from Install on, and who would write down every point they had to make a decision, and what should have been presented to them as information of how to make decision.
A table of possible error messages, how to get around them.
A better sense of new to Qubes —to come to the forum here, and say, 'How do I get this to work."
Someone sell laptops with Qubes installed, that do not offer all the options of a Certified Computer. We used to have a local Computer store of a fellow who sold refurbished Dell Business Laptops. Nice fellow, went out of business. However there are some computers like those, which could run Qubes, not have Core Boot/Heads. But scratch where some itch.
Perhaps convince re furbishers who sell refurbished Lenovo X-230, T430 and others to sell them with Qubes installed. I guess they must have 16 GB RAM. Not Core Boot, but, for a professional shop. Getting the BIOS set properly to use Qubes, and Loading Qubes with generic Passwords. Pretty easy for a computer shop person.
I found the Video with Micah Lee on the Qubes OS to be enlightening. I had to watch it more than once. I wonder if those who want more clear documentation have watched that, and some of the other Videos? Just knowing a little terminology can make one feel more comfortable.
I understand the point of a newcomer. They just want to use the Product, not spend hours reading about Qubes. We would have to emulate the Apple sense of, it just works, the mind directly goes to what it needs to do.
What about build a Qubes type OS that only installs Ubuntu VM, and Vault, Sys-USB. Qubes with Training Wheels. Less to see, less confusion. Faster to install.
Since today, yes:
If certain pieces of information should have been presented to them when they had to make certain decisions, then that information should be presented by the software. I don’t understand the inclination to put things in the documentation that belong in the software. That just makes it harder for users.
If the error messages are so inscrutable that you have to reference a table to figure out how to “get around them,” then the problem is with the error messages (or the software more generally), not the lack of documentation. Back in the olden days, computational resources were so limited on early devices that all they could display was a short cryptic error code, and then such reference tables were needed. Those days are long gone.
This is basically what I have been trying to do with many of my posts and github issues. When I come to something non-obvious, I post them even if i already found a solution.