Using this space to work on content for the Qubes FAQ page on the website.

This is the in-progress wiki page.

Some editorial principles I've been following & trends/remediations I've also been embracing...

1. Many of the live FAQs today, appear to have been written many years ago, when the primary audience for this site were folks interested in ≤3.0. Most of those folks were infosec folks; and as Qubes has aged, its audience has widened.

• Because of this dated-ness of many questions, a careful audit of what exists is important; either...
  • Preserve an answer 100% verbatim, and indicate as much
  • Slightly edit an answer, and indicate who did the edit
  • Totally re-write an answer, and indicate who/why
  • Totally scratch a question/answer, and indicate why
  • All of the above, so the past 10 years of work is properly accounted for, in this major overhaul.
• A strikethrough on a Question or Answer, is a device I have been using to indicate I'd like to scratch that item altogether.
• A blunt & sometimes snarky tone can work for a specific audience. It's since been intentionally moved away from, and similarly toned content should either be removed, or re-written.
• Many folks interested in Qubes, today, heard about it through Ed Snowden Tweeting; whereas back in the day, folks only heard about it through conference presentations by Joanna, or peers in security reasarch. Today's "Qubes curious" audience includes many infosec-curious but not fluent, or they are at-risk users with little tech knowledge; an/or, from outside the FOSS community.
• The intuition to first check "docs" to learn about something is not a natural behavior for either of these user types; so, some things obvious in the docs, need to be surfaced in far less detail, here (then, with a link to the docs)—while avoiding outright redundancy.
• Many new users are not even existing FOSS enthusiasts. Speaking to those folks in some of these answers, should be ok. Especially since more advanced users, are likely to skip reading those Answers. More of this will be important in earlier Q/As (such as in "General" and "Getting Started" sections).
• The more we manage new-to-FOSS folks' expectations and set them up for success, here, the less course-correction is necessary in forums, github, or email lists; and the more "learning" can happen vs feelings of shame or being imposters, on their end.
  • While contributing to those feelings is never the intention (especially among the amazing & thoughtful folks in the Qubes community), it is often an end-result of a person approaching a community with the wrong expectation—and even the gentlest of kid gloves, could not avoid those feelings happening. What can, is better up-front expectations management.

2. FAQs are the strongest opportunity to reduce noise/low-community-value stuff in emails and forums, and to get "dumb questions" out of the way—without burdening advanced users, and while also clearly positioning ourselves as a FOSS project, and what that means. Really great FAQ examples even function as a great narrative to explain some of the most important things about a project; how the "Answers" flow from one to the next in the Answers section, is important... as is ordering the Questions at the top, to catch the attention of folks in a panic or who truly know nothing.
3. Many of the more technical answers here, are intensely out of date. Andrew had a great suggestion in a chat, to keep highly-detailed technical answers that can change with releases, in a technical FAQ in the docs... that eventually could also be separated into release-specific FAQs.
4. Keep answers short, but not terse. Users typically dislike a simple hyperlink as an answer, or a "Read this article here: xx.com" as an answer. A 1-2 sentence TL;DR, that then has a link, is what historically tests the best. Lengthy responses with many examples or "too many words" also are better suited for articles, that the 1-2 sentence answer can direct to.