Host Qubes Community Documentation on Qubes Website and Relax Qubes Website Merge Policy

[adrelanos]

I usually get the feedback that Kicksecure, Whonix, Arch, Gentoo, Wikipedia wiki is excellent but Qubes website not so much. CSS / style aside, which is subjective. Talking about content only.

I am pretty sure this is because of its rigid merge policy. Every change is an uphill battle that requires a pull request with discussion, revisions, long review delays, etc. Because of this, I contribute less than I otherwise would.

This is not how above example Wiki's have been built. To have a wiki, editors need to be bold and have some level of creative freedom. Those who get offended by imperfections such as style, wording, typos and other inaccuracies are great but are also better off just adding edits on top to improve. Doing the edit is easier than explaining, debating it. Documentation is an iterative process but it needs to iterate faster.

As long as an edit suggestion is non-malicious, mostly correct, not harmful, some very simple criteria, it should be quickly merged. Only in case wiki edit wars emerge (which are rare), admins need to step in.

There's some obvious reasons for rejections such as spam, illegal, off-topic, bad language, whatnot, no need to mention.

It seems to me, Qubes somewhat recognized its documentation issue. Slow to review, quality check too much work, volume, whatnot.

I guess therefore documentation was moved to Qubes community and now to Qubes forums community guides. Hence the issue could somewhat be redirected elsewhere with added disclaimers. I see your issue that you don't want to host inaccurate contents on the Qubes website but forums really aren't a suitable replacement for documentation. Forums are even worse. Because then as a community guide needs clarification, updates, the forum thread gets longer and longer. Then only the original poster can update it. Should the original poster be unavailable, no longer interested, etc. then nobody else can easily contribute to update it.

Qubes website review is in high quality source code review mode. That's very important for security critical source code but the wrong mode for documentation.

If you need disclaimers such as "community", then just add the disclaimer to specific websites on the website. No need to redirect it to the forums. Any disclaimer you need "This looks non-malicious but untested by Qubes developers", "This hasn't been tested in a while / since R4.1. It might work. Please contribute, test and remove this notice if still functional." then just add it.

There is no reason the community documentation cannot be hosted on the Qubes website. Of course, you can have arbitrary criteria to reserve the right to refuse any content without reason if it seems controversial but such cases will be very rare. A different related policy discussion would be if documentation for non-freedom software (teamviewer, skype, zoom) should be permissible or forbidden but that should either just be decided or be discussed in a separate ticket.

Usability of Qubes website edits will still be lower than MediaWiki based Wiki's, which will lead to less contributions but Qubes website. That's not so easy to fix but the merge policy is easier to fix.

[andrewdavidwong]

This issue seems to combine two separate matters.

Relax Qubes Website Merge Policy

This part looks like a duplicate of your #3629.

Host Qubes Community Documentation on Qubes Website

This part looks like a duplicate of #4693.

[github-actions]

This issue has been closed as a "duplicate." This means that another issue exists that is very similar to or subsumes this one. If any useful information on this issue is not already present on the other issue, please add it in a comment on the other issue. Here are some common cases of duplicate issues:

• The other issue is closed. The other issue being closed does not prevent this issue from duplicating it. We will examine the closed issue and, if appropriate, reopen it.
• The other issue is for a different Qubes release. We usually maintain only one issue for all affected Qubes releases.
• The other issue is very old. The mere age of an issue is not, by itself, a relevant factor when determining duplicates.

By default, the newer issue will be closed in favor of the older issue. However, we make exceptions when we determine that it would be significantly more useful to keep the newer issue open instead of the older one.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "duplicate" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.