depreciate torvm, add Whonix templates (at minimum whonix-gw) to Qubes installer

[mfc]

given the issues that users continue to have with torvm (like #1196) and the reduced feature set compared to whonix-gw, I would suggest depreciating torvm in favor of whonix-gw.

the intention of porting whonix to qubes was exactly to do this, I would view this as fulfilling this goal.

to signify this, I would recommend:

• adding whonix-gw at minimum to the Qubes installer
• adding whonix-ws to Qubes installer
• porting whonix template documentation from whonix.org to qubes-os.org
• remove/redirect/modify torvm documentation to whonix-gw documentation

[adrelanos]

Is it important to move Whonix documentation? I don't see advantages by it. Where does porting whonix.org start, where does it stop? It would likely still have lots of references to whonix.org.

To move to qubes-os.org feels like a step backwards to me. No auto generated table of contents per page. No wiki templates [importing wiki markup from a wiki template]? Less agile and user friendly to anonymous fly-by editors. Git pull requests (qubes-os.org, high bar) vs anonymous wiki edits (whonix.org, very low bar).

[adrelanos]

Is it important to move Whonix documentation? I don't see advantages by it. Where does porting whonix.org start, where does it stop? It would likely still have lots of references to whonix.org.

To move to qubes-os.org feels like a step backwards to me. No auto generated table of contents per page. No wiki templates [importing wiki markup from a wiki template]? Less agile and user friendly to anonymous fly-by editors. Git pull requests (qubes-os.org, high bar) vs anonymous wiki edits (whonix.org, very low bar).

[marmarek]

FWIW I also don't see any sense in moving Whonix documentation to Qubes OS site. It should be on Whonix website (also), and having it duplicated doesn't make sense (will surely lead to synchronization issues).

Maybe we should just have "Whonix quick start" guide and linked to whonix.org for detailed instructions.

[marmarek]

FWIW I also don't see any sense in moving Whonix documentation to Qubes OS site. It should be on Whonix website (also), and having it duplicated doesn't make sense (will surely lead to synchronization issues).

Maybe we should just have "Whonix quick start" guide and linked to whonix.org for detailed instructions.

[bnvk]

@marmarek from a user experience standpoint, having unified documentation that has a similar style, flow, and terminology is tremendously better. If Whonix was never going to ship with / have the depth of integration with Qubes, then it might not make as much sense, but just seems like a clear huge win to me.

Maybe we should just have "Whonix quick start" guide and linked to whonix.org for detailed instructions

I'm not aiming for superl deep details about how or what Whonix does, but rather clear, short instructions on how to make Whonix work within Qubes!

[bnvk]

@marmarek from a user experience standpoint, having unified documentation that has a similar style, flow, and terminology is tremendously better. If Whonix was never going to ship with / have the depth of integration with Qubes, then it might not make as much sense, but just seems like a clear huge win to me.

Maybe we should just have "Whonix quick start" guide and linked to whonix.org for detailed instructions

I'm not aiming for superl deep details about how or what Whonix does, but rather clear, short instructions on how to make Whonix work within Qubes!

[unman]

@mfc
The issue you cite (#1196) isnt torvm specific - the errors are 404 and 500 errors, just the same as those you'll find cited on the whonix site. These errors are more prevalent when updating through Tor - whether you use torvm, whonix-gw or some other Tor proxy.
It isn't necessary to deprecate torVM to whonix - both should be available for those who want them, and we should recognise that some users wont want either.

[unman]

@mfc
The issue you cite (#1196) isnt torvm specific - the errors are 404 and 500 errors, just the same as those you'll find cited on the whonix site. These errors are more prevalent when updating through Tor - whether you use torvm, whonix-gw or some other Tor proxy.
It isn't necessary to deprecate torVM to whonix - both should be available for those who want them, and we should recognise that some users wont want either.

[mfc]

clear, short instructions on how to make Whonix work within Qubes!

exactly! just the "how to install / setup" info, with a link to the whonix webpage for more info. so not moving the documentation, just mirroring/copying a subset of it.

@unman I agree that both should be available to users -- torvm documentation for power users who want to create them and whonix-gw for everyone else. the idea being that instead of splitting dev time on two different implementations of the same thing, we should clearly focus on one (the one with more functionality) and communicate that to the average user. whonix-gw could just be framed as torvm 2.0.

#1196 is just the most recent example of a use-case where torvm does not work as expected while whonix-gw does. marek mentions in that issue some other instances where torvm lacks functionality compared to whonix-gw.

[mfc]

clear, short instructions on how to make Whonix work within Qubes!

exactly! just the "how to install / setup" info, with a link to the whonix webpage for more info. so not moving the documentation, just mirroring/copying a subset of it.

@unman I agree that both should be available to users -- torvm documentation for power users who want to create them and whonix-gw for everyone else. the idea being that instead of splitting dev time on two different implementations of the same thing, we should clearly focus on one (the one with more functionality) and communicate that to the average user. whonix-gw could just be framed as torvm 2.0.

#1196 is just the most recent example of a use-case where torvm does not work as expected while whonix-gw does. marek mentions in that issue some other instances where torvm lacks functionality compared to whonix-gw.

[bnvk]

@adrelanos to elaborate why I strongly believe in porting over the "Qubes/Whonix specific documentation" from whonix.org since @marmarek also voiced concern not seeing the value in it, I'll further elaborate:

1. Instead of needing to learn how two different site's information architecture and flow, unifying significantly improves a user's chance of understanding (thus using documentation to reach their goals). Currently, the Qubes docs are already quite decent.
2. This allows us to bundle the documentation for offline use, which would be very helpful if a user can't get online due to misconfigured / NetVM issues.
3. This page on the Whonix site is geared towards explaining "why to use Qubes on top of Whonix" which makes little sense for a user coming from the Qubes site as they already use & like Qubes- this info is not what I would consider "documentation" and should stay on the Whonix site as it is aimed at Whonix community.
4. Numerous parts of that overview page still read "TODO" which seems a bit rough and unfinished.
5. The Whonix site & docs are poorly organized & designed- a user currently has to scroll 2+ full browser windows to find a bunch of columns and then visually parse "Primary Guides -> Install -> Binary Install Guide" to get to any actionable steps and (even on that page) it is disorienting and requires a full scroll to get to any useful information.

No auto generated table of contents per page. No wiki templates [importing wiki markup from a wiki template]?

Jekyll can totally generate this and it's super easy to do. I see this as a feature and desirable. Wiki syntax & templates are not user friendly or universally the same. And the templates are very hard to style well- see my above notes about the current site design.

1. Gives us (me) a fresh slate to redesign / improve the Qubes / Whonix documentation as I'm working through that on the site redesign

Does that help clarify make sense to you both? I don't think duplicating this information on both sites makes sense.

As far as @adrelanos point about:

Less agile and user friendly to anonymous fly-by editors. Git pull requests (qubes-os.org, high bar) vs anonymous wiki edits (whonix.org, very low bar).

This can be made quite easy (arguably, much easier than MediaWiki) using prose.io which we can link to or self host (if we ever wanted to do that). Additionally, you can edit through Github's website, which I think is at least on par with MediaWiki's usability. Lastly, i'm going to go out on a limb here and say: people who can probably help us improve the Whonix / Qubes docs are pretty tech saavy and can probably use Git and edit markdown files.

[bnvk]

@adrelanos to elaborate why I strongly believe in porting over the "Qubes/Whonix specific documentation" from whonix.org since @marmarek also voiced concern not seeing the value in it, I'll further elaborate:

1. Instead of needing to learn how two different site's information architecture and flow, unifying significantly improves a user's chance of understanding (thus using documentation to reach their goals). Currently, the Qubes docs are already quite decent.
2. This allows us to bundle the documentation for offline use, which would be very helpful if a user can't get online due to misconfigured / NetVM issues.
3. This page on the Whonix site is geared towards explaining "why to use Qubes on top of Whonix" which makes little sense for a user coming from the Qubes site as they already use & like Qubes- this info is not what I would consider "documentation" and should stay on the Whonix site as it is aimed at Whonix community.
4. Numerous parts of that overview page still read "TODO" which seems a bit rough and unfinished.
5. The Whonix site & docs are poorly organized & designed- a user currently has to scroll 2+ full browser windows to find a bunch of columns and then visually parse "Primary Guides -> Install -> Binary Install Guide" to get to any actionable steps and (even on that page) it is disorienting and requires a full scroll to get to any useful information.

No auto generated table of contents per page. No wiki templates [importing wiki markup from a wiki template]?

Jekyll can totally generate this and it's super easy to do. I see this as a feature and desirable. Wiki syntax & templates are not user friendly or universally the same. And the templates are very hard to style well- see my above notes about the current site design.

1. Gives us (me) a fresh slate to redesign / improve the Qubes / Whonix documentation as I'm working through that on the site redesign

Does that help clarify make sense to you both? I don't think duplicating this information on both sites makes sense.

As far as @adrelanos point about:

Less agile and user friendly to anonymous fly-by editors. Git pull requests (qubes-os.org, high bar) vs anonymous wiki edits (whonix.org, very low bar).

This can be made quite easy (arguably, much easier than MediaWiki) using prose.io which we can link to or self host (if we ever wanted to do that). Additionally, you can edit through Github's website, which I think is at least on par with MediaWiki's usability. Lastly, i'm going to go out on a limb here and say: people who can probably help us improve the Whonix / Qubes docs are pretty tech saavy and can probably use Git and edit markdown files.

[mfc]

Just to provide a different but supportive argument, we want the documentation for all the Qubes Templates to be standardized.

So this means not having some Template pages having instructions directly on the webpage and others just having links to external websites or to the Google Groups lists.

This will make sure there is a unified level of quality and instruction for all Templates. It will also make sure the instructions are included in offline documentation #1019 as previously mentioned.

So it's not just something for Whonix Templates, it's something that needs to be done for all Templates documentation.

[mfc]

Just to provide a different but supportive argument, we want the documentation for all the Qubes Templates to be standardized.

So this means not having some Template pages having instructions directly on the webpage and others just having links to external websites or to the Google Groups lists.

This will make sure there is a unified level of quality and instruction for all Templates. It will also make sure the instructions are included in offline documentation #1019 as previously mentioned.

So it's not just something for Whonix Templates, it's something that needs to be done for all Templates documentation.

[adrelanos]

TLDR Whonix documentation moving to Qubes website:

Talked to @bnvk at the Tor summer dev meeting. Agreed to move
Qubes-Whonix quick start instructions to the Qubes website. @bnvk wanted
to take this task. Feel free to reassign the task back to me.

The following long answer is not a rebuttal. Because the reasons for
doing this weight more than reasons not doing this. Skippable. Just for
better mutual understanding.

Long:

Brennan Novak:

@marmarek from a user experience standpoint, having unified
documentation that has a similar style, flow, and terminology is
tremendously better. If Whonix was never going to ship with / have
the depth of integration with Qubes, then it might not make as much
sense, but just seems like a clear huge win to me.

Ok.

Maybe we should just have "Whonix quick start" guide and linked to
whonix.org for detailed instructions

I'm not aiming for superl deep details about how or what Whonix does,
but rather clear, short instructions on how to make Whonix work
within Qubes!

Ok.

Brennan Novak:

1. Instead of needing to learn how two different site's information
   architecture and flow, unifying significantly improves a user's
   chance of understanding (thus using documentation to reach their
   goals). Currently, the Qubes docs are already quite decent.
2. This allows us to bundle the documentation for offline use, which
   would be very helpful if a user can't get online due to misconfigured
   / NetVM issues.

Ok.

1. This page on the Whonix site
   is geared towards explaining "why to use Qubes on top of Whonix"
   which makes little sense for a user coming from the Qubes site as
   they already use & like Qubes- this info is not what I would
   consider "documentation" and should stay on the Whonix site as it is
   aimed at Whonix community.

This would be a non-reason: because it would be easier to fix the page.

1. Numerous parts of that overview page still read "TODO" which seems
   a bit rough and unfinished.

[The TODO's were there to advertise/encourage contributions for lower
priority items.]

This would be a non-reason: because it would be easier to fix the page.

1. The Whonix site & docs are poorly organized & designed- a user
   currently has to scroll 2+ full browser windows to find a bunch of
   columns and then visually parse "Primary Guides -> Install ->
   Binary Install Guide" to get to any actionable steps and (even on
   that page) it is disorienting and requires a full scroll to get to
   any useful information.

This would be a non-reason: because it would be easier to fix the page.

No auto generated table of contents per page. No wiki templates
[importing wiki markup from a wiki template]?

Jekyll can totally generate this and it's super easy to do. I see
this as a feature and desirable. Wiki syntax & templates are not user
friendly or universally the same. And the templates are very hard to
style well- see my above notes about the current site design.

Need a ticket for that.

1. Gives us (me) a fresh slate to redesign / improve the Qubes /
   Whonix documentation as I'm working through that on the site
   redesign

Ok.

Does that help clarify make sense to you both? I don't think
duplicating this information on both sites makes sense.

Yes.

As far as @adrelanos point about:

Less agile and user friendly to anonymous fly-by editors. Git pull
requests (qubes-os.org, high bar) vs anonymous wiki edits
(whonix.org, very low bar).

This can be made quite easy (arguably, much easier than MediaWiki)
using prose.io which we can link to or self host
(if we ever wanted to do that). Additionally, you can edit through
Github's website, which I think is at least on par with MediaWiki's
usability.

These are workarounds and not as obvious and encouraging as MediaWiki's
EDIT button. The ability of editing MediaWiki is somewhat popular thanks
to Wikipedia.

Lastly, i'm going to go out on a limb here and say: people
who can probably help us improve the Whonix / Qubes docs are pretty
tech saavy and can probably use Git and edit markdown files.

Experience with Whonix development has shown, that this is not the case.
Two examples coming to my mind first:

• A hardcore technical issue that no one else figured out for years was
  solved by an anonymous wiki contribution.
  (https://www.whonix.org/wiki/Higher_Screen_Resolution)
• The Bridges page ( https://www.whonix.org/wiki/Bridges ) was recently
  modified by privacyguy. (
  https://www.whonix.org/w/index.php?title=Bridges&diff=16979&oldid=16807
  ) From a bad state without Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=16807 ) To a
  better state including Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=17624 ) To my
  knowledge, privacyguy does not speak git.

[adrelanos]

TLDR Whonix documentation moving to Qubes website:

Talked to @bnvk at the Tor summer dev meeting. Agreed to move
Qubes-Whonix quick start instructions to the Qubes website. @bnvk wanted
to take this task. Feel free to reassign the task back to me.

The following long answer is not a rebuttal. Because the reasons for
doing this weight more than reasons not doing this. Skippable. Just for
better mutual understanding.

Long:

Brennan Novak:

@marmarek from a user experience standpoint, having unified
documentation that has a similar style, flow, and terminology is
tremendously better. If Whonix was never going to ship with / have
the depth of integration with Qubes, then it might not make as much
sense, but just seems like a clear huge win to me.

Ok.

Maybe we should just have "Whonix quick start" guide and linked to
whonix.org for detailed instructions

I'm not aiming for superl deep details about how or what Whonix does,
but rather clear, short instructions on how to make Whonix work
within Qubes!

Ok.

Brennan Novak:

1. Instead of needing to learn how two different site's information
   architecture and flow, unifying significantly improves a user's
   chance of understanding (thus using documentation to reach their
   goals). Currently, the Qubes docs are already quite decent.
2. This allows us to bundle the documentation for offline use, which
   would be very helpful if a user can't get online due to misconfigured
   / NetVM issues.

Ok.

1. This page on the Whonix site
   is geared towards explaining "why to use Qubes on top of Whonix"
   which makes little sense for a user coming from the Qubes site as
   they already use & like Qubes- this info is not what I would
   consider "documentation" and should stay on the Whonix site as it is
   aimed at Whonix community.

This would be a non-reason: because it would be easier to fix the page.

1. Numerous parts of that overview page still read "TODO" which seems
   a bit rough and unfinished.

[The TODO's were there to advertise/encourage contributions for lower
priority items.]

This would be a non-reason: because it would be easier to fix the page.

1. The Whonix site & docs are poorly organized & designed- a user
   currently has to scroll 2+ full browser windows to find a bunch of
   columns and then visually parse "Primary Guides -> Install ->
   Binary Install Guide" to get to any actionable steps and (even on
   that page) it is disorienting and requires a full scroll to get to
   any useful information.

This would be a non-reason: because it would be easier to fix the page.

No auto generated table of contents per page. No wiki templates
[importing wiki markup from a wiki template]?

Jekyll can totally generate this and it's super easy to do. I see
this as a feature and desirable. Wiki syntax & templates are not user
friendly or universally the same. And the templates are very hard to
style well- see my above notes about the current site design.

Need a ticket for that.

1. Gives us (me) a fresh slate to redesign / improve the Qubes /
   Whonix documentation as I'm working through that on the site
   redesign

Ok.

Does that help clarify make sense to you both? I don't think
duplicating this information on both sites makes sense.

Yes.

As far as @adrelanos point about:

Less agile and user friendly to anonymous fly-by editors. Git pull
requests (qubes-os.org, high bar) vs anonymous wiki edits
(whonix.org, very low bar).

This can be made quite easy (arguably, much easier than MediaWiki)
using prose.io which we can link to or self host
(if we ever wanted to do that). Additionally, you can edit through
Github's website, which I think is at least on par with MediaWiki's
usability.

These are workarounds and not as obvious and encouraging as MediaWiki's
EDIT button. The ability of editing MediaWiki is somewhat popular thanks
to Wikipedia.

Lastly, i'm going to go out on a limb here and say: people
who can probably help us improve the Whonix / Qubes docs are pretty
tech saavy and can probably use Git and edit markdown files.

Experience with Whonix development has shown, that this is not the case.
Two examples coming to my mind first:

• A hardcore technical issue that no one else figured out for years was
  solved by an anonymous wiki contribution.
  (https://www.whonix.org/wiki/Higher_Screen_Resolution)
• The Bridges page ( https://www.whonix.org/wiki/Bridges ) was recently
  modified by privacyguy. (
  https://www.whonix.org/w/index.php?title=Bridges&diff=16979&oldid=16807
  ) From a bad state without Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=16807 ) To a
  better state including Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=17624 ) To my
  knowledge, privacyguy does not speak git.

[marmarek]

On Tue, Oct 06, 2015 at 11:06:27AM -0700, Patrick Schleizer wrote:

As far as @adrelanos point about:

Less agile and user friendly to anonymous fly-by editors. Git pull
requests (qubes-os.org, high bar) vs anonymous wiki edits
(whonix.org, very low bar).

This can be made quite easy (arguably, much easier than MediaWiki)
using prose.io which we can link to or self host
(if we ever wanted to do that). Additionally, you can edit through
Github's website, which I think is at least on par with MediaWiki's
usability.

These are workarounds and not as obvious and encouraging as MediaWiki's
EDIT button. The ability of editing MediaWiki is somewhat popular thanks
to Wikipedia.

Lastly, i'm going to go out on a limb here and say: people
who can probably help us improve the Whonix / Qubes docs are pretty
tech saavy and can probably use Git and edit markdown files.

Experience with Whonix development has shown, that this is not the case.
Two examples coming to my mind first:

• A hardcore technical issue that no one else figured out for years was
  solved by an anonymous wiki contribution.
  (https://www.whonix.org/wiki/Higher_Screen_Resolution)
• The Bridges page ( https://www.whonix.org/wiki/Bridges ) was recently
  modified by privacyguy. (
  https://www.whonix.org/w/index.php?title=Bridges&diff=16979&oldid=16807
  ) From a bad state without Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=16807 ) To a
  better state including Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=17624 ) To my
  knowledge, privacyguy does not speak git.

Somehow offtopic, but we had "edit" button on doc pages, linked to
github built-in editor.

QubesOS/qubesos.github.io@e87babd

Maybe we should restore it? @bnvk, what do you think?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Tue, Oct 06, 2015 at 11:06:27AM -0700, Patrick Schleizer wrote:

As far as @adrelanos point about:

Less agile and user friendly to anonymous fly-by editors. Git pull
requests (qubes-os.org, high bar) vs anonymous wiki edits
(whonix.org, very low bar).

This can be made quite easy (arguably, much easier than MediaWiki)
using prose.io which we can link to or self host
(if we ever wanted to do that). Additionally, you can edit through
Github's website, which I think is at least on par with MediaWiki's
usability.

These are workarounds and not as obvious and encouraging as MediaWiki's
EDIT button. The ability of editing MediaWiki is somewhat popular thanks
to Wikipedia.

Lastly, i'm going to go out on a limb here and say: people
who can probably help us improve the Whonix / Qubes docs are pretty
tech saavy and can probably use Git and edit markdown files.

Experience with Whonix development has shown, that this is not the case.
Two examples coming to my mind first:

• A hardcore technical issue that no one else figured out for years was
  solved by an anonymous wiki contribution.
  (https://www.whonix.org/wiki/Higher_Screen_Resolution)
• The Bridges page ( https://www.whonix.org/wiki/Bridges ) was recently
  modified by privacyguy. (
  https://www.whonix.org/w/index.php?title=Bridges&diff=16979&oldid=16807
  ) From a bad state without Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=16807 ) To a
  better state including Qubes specific instructions. (
  https://www.whonix.org/w/index.php?title=Bridges&oldid=17624 ) To my
  knowledge, privacyguy does not speak git.

Somehow offtopic, but we had "edit" button on doc pages, linked to
github built-in editor.

QubesOS/qubesos.github.io@e87babd

Maybe we should restore it? @bnvk, what do you think?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Sounds good to me. I would use it myself also.

[adrelanos]

Sounds good to me. I would use it myself also.

[bnvk]

Somehow offtopic, but we had "edit" button on doc pages, linked to github built-in editor

Yes! I'm a big fan of this thing!

[bnvk]

Somehow offtopic, but we had "edit" button on doc pages, linked to github built-in editor

Yes! I'm a big fan of this thing!

[marmarek]

On Fri, Oct 09, 2015 at 09:37:59AM -0700, Brennan Novak wrote:

Somehow offtopic, but we had "edit" button on doc pages, linked to github built-in editor

Yes! I'm a big fan of this thing!

Can you provide some design for it? Especially where it should be placed
in our current page layout. Most preferably just some patch for the
layout, with '' tag, which I would fill with the correct address.
The button we had previously looked awful and this was the reason for
removing it.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Fri, Oct 09, 2015 at 09:37:59AM -0700, Brennan Novak wrote:

Somehow offtopic, but we had "edit" button on doc pages, linked to github built-in editor

Yes! I'm a big fan of this thing!

Can you provide some design for it? Especially where it should be placed
in our current page layout. Most preferably just some patch for the
layout, with '' tag, which I would fill with the correct address.
The button we had previously looked awful and this was the reason for
removing it.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

Experience with Whonix development has shown, that this is not the case. Two examples coming to my mind first: [...]

@adrelanos, do you remember the old TracWiki site? Are you thinking that moving away from that system (and to the current Git-based doc system) was a bad move?

[andrewdavidwong]

Experience with Whonix development has shown, that this is not the case. Two examples coming to my mind first: [...]

@adrelanos, do you remember the old TracWiki site? Are you thinking that moving away from that system (and to the current Git-based doc system) was a bad move?

[adrelanos]

@adrelanos, do you remember the old TracWiki site?

Yes.

Are you thinking that moving away from that system (and to the current Git-based doc system) was a bad move?

I think the trac issue tracker is better suited than github issues for a project of this size. For the website I am not sure. While trac wiki makes contributions simpler (edit/preview/save buttons), the new website looks better than trac wiki. For websites of Libre Software projects I prefer mediawiki as content generator. It's the best tool for accepting contributions and has the lowest bar for editing. You can even accept anonymous edits by moderating those (extension: flagged revisions). The mediawiki default skin looks awful indeed. But you can make mediawiki look like just a normal website. See these skins http://www.mediawikibootstrapskin.co.uk.

[adrelanos]

@adrelanos, do you remember the old TracWiki site?

Yes.

Are you thinking that moving away from that system (and to the current Git-based doc system) was a bad move?

I think the trac issue tracker is better suited than github issues for a project of this size. For the website I am not sure. While trac wiki makes contributions simpler (edit/preview/save buttons), the new website looks better than trac wiki. For websites of Libre Software projects I prefer mediawiki as content generator. It's the best tool for accepting contributions and has the lowest bar for editing. You can even accept anonymous edits by moderating those (extension: flagged revisions). The mediawiki default skin looks awful indeed. But you can make mediawiki look like just a normal website. See these skins http://www.mediawikibootstrapskin.co.uk.

[marmarek]

On Sun, Oct 11, 2015 at 04:15:07AM -0700, Patrick Schleizer wrote:

I think the trac issue tracker is better suited than github issues for a project of this size.

I don't think so. There were two major problems with trac:

1. Poor / lack of multiple repositories support. We can't refer easily
   from tickets to code (other than manually pasting links) and from code
   to tickets (links, closing tickets). When you forget to paste a link in
   the ticket, later it require some time to search for all the commits
   related to a given ticket.
2. Really poor anti-spam mechanisms. This was a main reason why we
   had no open registration there (which require additional labor, like
   copy&paste bug reports). When we've tried to open the registration, with
   everything trac offed (CAPTCHA, moderation etc), we've got a tons of
   spam tickets, spam users creation requests and so on. Another issue of
   similar type was DoS attacks. This probably applies to any self-hosted,
   user-editable service. But the great thing about github is that it isn't
   our problem now!

I'm not saying that github issues is the best tool in the world. Just
saying it's better than trac.

As for the website, I don't have any strong opinion. Great thing about
github paget is that it's backed by git repository, which nicely fit in
our not-trusting-the-infrastructure attitude. But we've also done the
same with trac. And probably can be done with any other tool.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Sun, Oct 11, 2015 at 04:15:07AM -0700, Patrick Schleizer wrote:

I think the trac issue tracker is better suited than github issues for a project of this size.

I don't think so. There were two major problems with trac:

1. Poor / lack of multiple repositories support. We can't refer easily
   from tickets to code (other than manually pasting links) and from code
   to tickets (links, closing tickets). When you forget to paste a link in
   the ticket, later it require some time to search for all the commits
   related to a given ticket.
2. Really poor anti-spam mechanisms. This was a main reason why we
   had no open registration there (which require additional labor, like
   copy&paste bug reports). When we've tried to open the registration, with
   everything trac offed (CAPTCHA, moderation etc), we've got a tons of
   spam tickets, spam users creation requests and so on. Another issue of
   similar type was DoS attacks. This probably applies to any self-hosted,
   user-editable service. But the great thing about github is that it isn't
   our problem now!

I'm not saying that github issues is the best tool in the world. Just
saying it's better than trac.

As for the website, I don't have any strong opinion. Great thing about
github paget is that it's backed by git repository, which nicely fit in
our not-trusting-the-infrastructure attitude. But we've also done the
same with trac. And probably can be done with any other tool.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[mfc]

Talked to @bnvk at the Tor summer dev meeting. Agreed to move
Qubes-Whonix quick start instructions to the Qubes website. @bnvk wanted
to take this task. Feel free to reassign the task back to me.

What's the status of this? @bnvk @adrelanos

tired of folks emailing qubes-users failing at setting up torvm, not realizing whonix-gw exists. maybe we need to rename whonix-gw as torvm and just replace torvm documentation entirely.

[mfc]

Talked to @bnvk at the Tor summer dev meeting. Agreed to move
Qubes-Whonix quick start instructions to the Qubes website. @bnvk wanted
to take this task. Feel free to reassign the task back to me.

What's the status of this? @bnvk @adrelanos

tired of folks emailing qubes-users failing at setting up torvm, not realizing whonix-gw exists. maybe we need to rename whonix-gw as torvm and just replace torvm documentation entirely.

[adrelanos]

Michael Carbone:

Talked to @bnvk at the Tor summer dev meeting. Agreed to move
Qubes-Whonix quick start instructions to the Qubes website. @bnvk
wanted to take this task. Feel free to reassign the task back to me.

What's the status of this? @bnvk @adrelanos

Unchanged. I am waiting for @bnvk. Or I take the task back if @bnvk no
longer wants it.

tired of folks emailing qubes-users failing at setting up torvm, not
realizing whonix-gw exists. maybe we need to rename whonix-gw as
torvm and just replace torvm documentation entirely.

Not a good idea for many reasons:

• it might confuse less the new TorVM users, but confuse more the
  existing TorVM users
• it would confuse the existing TorVM users, where the old TorVM is gone
• TorVM is perhaps more popular in the Qubes world, but overall Whonix
  is much more popular
• don't use project names with 'tor' in their name, as soon as the
  project gains popularity, TPO will complain about trademark violation.
  Speaking from experience. That's why TorBOX (original project name) was
  renamed to Whonix. It would have never come to my mind to rename to
  Whonix, if they didn't complain. -
  https://www.whonix.org/wiki/Dev/TPO_Trademark

[adrelanos]

Michael Carbone:

Talked to @bnvk at the Tor summer dev meeting. Agreed to move
Qubes-Whonix quick start instructions to the Qubes website. @bnvk
wanted to take this task. Feel free to reassign the task back to me.

What's the status of this? @bnvk @adrelanos

Unchanged. I am waiting for @bnvk. Or I take the task back if @bnvk no
longer wants it.

tired of folks emailing qubes-users failing at setting up torvm, not
realizing whonix-gw exists. maybe we need to rename whonix-gw as
torvm and just replace torvm documentation entirely.

Not a good idea for many reasons:

• it might confuse less the new TorVM users, but confuse more the
  existing TorVM users
• it would confuse the existing TorVM users, where the old TorVM is gone
• TorVM is perhaps more popular in the Qubes world, but overall Whonix
  is much more popular
• don't use project names with 'tor' in their name, as soon as the
  project gains popularity, TPO will complain about trademark violation.
  Speaking from experience. That's why TorBOX (original project name) was
  renamed to Whonix. It would have never come to my mind to rename to
  Whonix, if they didn't complain. -
  https://www.whonix.org/wiki/Dev/TPO_Trademark

[bnvk]

@mfc @adrelanos i'll take a stab at this as I've got a couple
other Doc patches in my local git + it was my idea :)

I'm thinking we make a separate heading on the Docs ToC for this
such as:

• Privacy Guides
• Privacy & Anonymization Guides
• Anonymizing Yourself Online

[bnvk]

@mfc @adrelanos i'll take a stab at this as I've got a couple
other Doc patches in my local git + it was my idea :)

I'm thinking we make a separate heading on the Docs ToC for this
such as:

• Privacy Guides
• Privacy & Anonymization Guides
• Anonymizing Yourself Online

[andrewdavidwong]

I'm thinking we make a separate heading on the Docs ToC for this such as:

• Privacy Guides
• Privacy & Anonymization Guides
• Anonymizing Yourself Online

A new section on the /docs/ page would be fine as long as there are enough pages under it to justify having it as a separate section.

I would go with "Privacy Guides" rather than the anything with "Anonymization" in the title, because often what you're talking about isn't actually anonymity but pseudonymity (or some other form of *nymity).

[andrewdavidwong]

I'm thinking we make a separate heading on the Docs ToC for this such as:

• Privacy Guides
• Privacy & Anonymization Guides
• Anonymizing Yourself Online

A new section on the /docs/ page would be fine as long as there are enough pages under it to justify having it as a separate section.

I would go with "Privacy Guides" rather than the anything with "Anonymization" in the title, because often what you're talking about isn't actually anonymity but pseudonymity (or some other form of *nymity).

[marmarek]

Does the commit QubesOS/qubes-doc#108 mean it is finished ?

[marmarek]

Does the commit QubesOS/qubes-doc#108 mean it is finished ?

[mfc]

yep let's call it done. hurrah!

[mfc]

yep let's call it done. hurrah!