For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

241 views
Skip to first unread message

Yuraeitha

unread,
Feb 28, 2018, 3:39:06 PM2/28/18
to qubes-users

It seems from time to time that various people have shared a good unofficial script, guides and 'how to's', and even code, for Qubes related content, on their github page or similar. The problem however is that while shared, it isn't very visible, and even if they are from time to time mentioned in a mail thread, it quickly gets buried under many new mails. It often isn't feasible to use the search engine to find these either.

Of course everything could be put into the Qubes doc page. But first, it's getting pretty large and cluttered and will probably only grow bigger. Second, the Qubes doc page does not show on-going and un-finished work. The strength of seeing unfinished projects, is that we can help each others finish and test them. Scrutinize them for security issues and reliability issues, before they are considered for the Qubes doc page.

To solve an issue like this, it'd be helpful to have a place where we can keep track of everyone's projects which are shared for others to use. It may also be worth discussing on quality and security, and how we "censor"? bad scripts/guides/code. It could be done in many various of different ways, which is also why I think it'd make sense to open a discussion on the matter, so we can find the most preferred method. First though, a location might be ideal starting place, where to keep everything updated?

Initial thoughts
- A https://www.qubes-os.org/doc/ page listing all the unofficial projects. The most simple and easy way.

- A decentralized network shared links through wiki pages, linking from one to the next. Takes some work to maintain, but could be useful if properly done. The weakness is that it is very redundant and requires edits on every wiki page containing shared content in order to keep a network based source system up. A single maintained overview page would therefore be easier. The strength is that it builds up a stronger sense of inter-connected community and inter-awareness of each others github pages.

- An off-sight website which can build on unofficial content, keeping the Qubes official website clean from unofficial releases. The strength here is that more can be done to make answers to redundant questions more visible, and highlight unofficial solutions to which many people keep facing. The weakness is that it once more segments where Qubes users hangout, which might not be something we currently can afford. There are only about 30.000 Qubes users tops? and from them we often see the same people posting, and many of the new faces don't re-post very often. It would also require a reputation of reliability and trust, including carrying out these responsibilities too, on its own.

Generally the main concern is the visibility of the effort that the community puts in Qubes, from the bottom-up, often goes to waste and few people see's it.

Thoughts? maybe other new solutions or a modified one to one mentioned? I'm pretty sure there are many good ideas, opinions and insights out there, lets discuss this issue.

[799]

unread,
Feb 28, 2018, 7:31:50 PM2/28/18
to yura...@gmail.com, qubes...@googlegroups.com
Hello Yuraeitha,


-------- Original-Nachricht --------

An 28. Feb. 2018, 21:39, Yuraeitha schrieb:

> It seems from time to time that various
> people have shared a good unofficial script,
> guides and 'how to's', and even code, for
> Qubes related content, on their github page or
> similar. The problem however is that while
> shared, it isn't very visible, and even if they are
> from time to time mentioned in a mail thread,
> it quickly gets buried under many new mails.

I have recognized the same and was wondering already what could be the reason that people have written own small projects which I only knew of because following this mailing list.
Honestly I started the same, after coming up with the first draft of ma qvm-screenshot-to-clipboard script.

The main reason why I didn't upload it (yet) to Qubes docs:

1) it is on a very early stage and while it is working I would feel a bit ashamed, as there is no error handling etc.

2) I am unsure if the script is not only working but also "reasonable secure" to use

3) I like the quality of the existing Qubes documentation, but it takes some time for a newbie user not only to write a good how-to but also include all the valuable feedback or keep the discussion ongoing.

Maybe those are the reasons why others like to keep developing their stuff outside of the Qubes doc repository. Summarized:

1. Scripts are not yet ready/to basic
2. Unknown impact on security
3. Not enough time to craft a quality "product"


> To solve an issue like this, it'd be helpful to
> have a place where we can keep track of
> everyone's projects which are shared for
> others to use. It may also be worth discussing
> on quality and security, and how we "censor"?
> bad scripts/guides/code.

Yes, please! His could also be a good ressource to browse looking to fine-tune Qubes.


> It could be done in many various of different
> ways, which is also why I think it'd make
> sense to open a discussion on the matter, so
> we can find the most preferred method. First
> though, a location might be ideal starting
> place, where to keep everything updated?
> (...)

> A https://www.qubes-os.org/doc/ page listing
> all the unofficial projects. The most simple
> and easy way.

I like the idea having it available at GitHub as we can easily contribute to the code and GitHub has all the features to keep discussion ongoing etc.
It is also allows to keep a copy of the latest version of the scripts and people don't have to learn another tool when their code is ready to be released.

The bad thing:
If you're not a developer and have never worked with GitHub the learning curve might be high.
At least I had to click some time arround to understand what is located where and how it is working.


> Generally the main concern is the visibility of
> the effort that the community puts in Qubes,
> from the bottom-up, often goes to waste and
> few people see's it.

The other benefit is, that I learn a lot from reading other person's scripts and of course following the discussion.

Maybe some of the ideas there could also be mentioned in a maybe monthly blog post, so that new users can see that Qubes is a living project.

I would call this site/place where all the ideas are summarize "Qubes Garden" or "Qubes Playground" :-)

[799]

Zrubi

unread,
Mar 1, 2018, 5:53:19 AM3/1/18
to Yuraeitha, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Have you seen this page:
https://www.qubes-os.org/qubes-issues/



- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlqX244ACgkQGjNaC1SP
N2SdmA//R9MMEoRIww3VVxSMhgLX8E/pAVnMLFjbJj11KyfVqIyGnB32x8ZXn4Fj
Ep2HDuTV5Gz+UiJHl3dTcO/1k7CII2SCwo01JWcOyuR02HFxFyEnMSO8ZezfZbuS
Uy6LozQ6gFQO5YNKH3D21UfOEw9Hg2XFVu2EreN8KmTJCbS3J3tX2OElZzGFb27k
Lvz2BdSYl9emx2+GdmxJSzQsYFQcC5a7q3zxPqfApXUn6W1UHTWGNY8Roijz25EA
luLfolwiae7iE7a17dLslqBcdB5bW/Jb4Sf7dx0cTKx5hvT5YO3EcikNeyAkiQ3m
tMi9dPK1NgvgkCd7liHYLSfdRm3LkN+DrGkcN5yOIGldLgwDFUtJnhhjfpYvcINQ
fqdXZYuTtuswP02VR5HnTJ9HX7+eCoUBT+Uk4N9GABYwVRODHLx6KqSOJ2YT0I3R
ZvM2m0qcfdGSQEkp9cK2gKgvrVL3Odbw+Lhm25KvGcviR/sJr+LOxxE76lu6TOvg
qgBsbPlt5L0ferDt67IHfkrspz3juxEiF7+O0ZTmcvIKmbvMCPe8K2NA00Uo+y0j
kUErAdUomPWXoPPFdRo4i+GWLNPyo2EiBi6AXIwYFWZIbjcMmPNab/DGJrWFWFX+
ZxFZBmf+8+rkAV2PYWi299LUQjjWLEizrEX6l+Dja3eD6wCBlZc=
=+Zw+
-----END PGP SIGNATURE-----

Yuraeitha

unread,
Mar 1, 2018, 6:39:34 AM3/1/18
to qubes-users

@Laszlo
I was indeed not aware of that page, it's pretty similar to the initial suggestion up above. (Thanks for linking it!). But there is a very crucial difference I think, it appears much more top-down focused than bottom-up, and also not focused on more every-day kind of issues. It's more focussed on directly Qubes related issues, and not so much issues which can make Qubes easier to use, more mundane things, and other things which might be very important to some people, but not everyone. It also has a single developer mindset, rather than inspiring people in the community to work together to archive a common goal. So it's both very similar, but also very different at the same time.

I agree it should still be possible to block dangerous or out-dated guides/scripts/etc., that's my opinion/view as well. But what is sought here is also a method not to exclude people who try to start something (many people have creative ideas, but are unable to carry it out or finish it themselves, and it disappears). Something can be started up, and then later need/seek help from others in the community to help finish it. Have critical eyes on the work from others, which might also make people more daring to do something, which may not be bashful, but a friendly community to solve issues in development, in a similar way how we solve personal issues in these mail threads. It can be much more risky for an individual to try build something alone, and then stick ones head out, than it is if the process is transparent and everyone can see how it works. Not everyone is willing to face such a risk, even if they got the skills to finish it themselves.

There is at least a good handful, if not 10 or so people around in these forums, who try to do something like this, but everyone are working alone. There are skill sets on vastly different degrees and types, but everyone doesn't need to have the same skills to be useful. A good example are Artists who can make artwork for Qubes content, or editors/writers/guide-makers whom usually would not write to a Qubes doc page, due to already mentioned reasons, or other reasons, it could be lack of time, or because the Qubes docs seem too official. I would make a guess here, that few people would want to post anything to a Qubes doc page if they didn't finish it up and make it pretty decent quality, before posting it. But that won't happen if low confidence/unfinished/lack-skillsets-and-need-to-work-with-others-to-finish-it/too-official/feels-like-it-must-be-finished-in-high-quality-when-uploaded.

I get there is a quality problem with something like this, but that's also meant to be part of the discussion, as how to solve something like that. Should there be someone to edit the content, so one one runs a dangerous or unfinished script by mistake, etc.

Yuraeitha

unread,
Mar 1, 2018, 6:47:13 AM3/1/18
to qubes-users

@[799]
I'm glad you feel the same way :)
If we imagine the github approach, any idea how we can keep an overview of all projects? Maybe a Qubes doc? something else? Also true with github, it was also a bit of a jungle for me the first time, and still is at times.

I like the off-site website approach too, I'm just worried that we're too few people to do something like that :/

Maybe we could make a shared chat room of a sorts, to discuss scripts/guides/etc. where everyone are welcome to join openly?

Alex Dubois

unread,
Mar 1, 2018, 2:48:35 PM3/1/18
to qubes-users

I think a Qubes Doc page listing the other projects in GitHub could be good.
It should not be too much work for the Qubes team to accept the pull request for updates to this page, which could be not too frequent. If they accept.

Other projects have an incubator section.

However, I think we need to spend a bit more time to try to add to this a bit of structure so that:
- It drives merger of projects from community member to help one another when they want to achieve the same goal
- It drives projects to have a well defined small scope

Maybe have some forced phases "requirements definition", security/arch, minimum value product1 (1st dev iteration)...

Yuraeitha

unread,
Mar 1, 2018, 10:10:05 PM3/1/18
to qubes-users

Great feedback Alex, I think you're absolutely right. Lets indeed not be hasteful and jump to conclusions, and try get a structure down first. It would be interesting to hear if the Qubes staff think this is a bad or good idea though, or if they're neutral about it. At least I'm not planning to keep going with this if they think it's a bad idea, all I'm trying to do is start a discussion about it to see if it's feasible to get it going or not, whether something like this is possible also depends a lot of peoples views and interest too.

Ultimately we also need to find out how we decide on these things, I'm not planning to take on any sort of leadership or anything like that, I'm only trying to get it going, and from there no more than a normal member. But it can't be all chaotic and random either. Ideas and discussions on this issue seems in particular important. Like the strategy statement for a vision you put forward in your post puts a leadership structure without a physical leader present, which is a good idea I think.

Whatever it ends up becoming though, it seems to me like a good call to let the Qubes staff have a final say, if something goes on that they think is a bad idea or think should change. I don't think many would disagree about that either. If we can establish rules and guidelines, but that they are subject to change by the Qubes staff. But how do we decide on them as a community, I feel that is a tricky issue and it might depend on how well each hypothetical leading system works from the kind of people be bring together. Some groups don't need leadership and can act cooperatively through culture and shared values/culture, while other groups need strong leadership with clear rules, and so on. It also has a size factor, and it might depend a lot on where in the world people come from too with cultural differences.

Perhaps a good guideline for most of the bottom-up approach's structure to follow the essence, rules and culture that the Qubes project itself follows and set for itself? Although with a more community oriented focus of course. So something like this?

Basic structure:
- Always subject to the Qubes staff's decisions.
- Adheres naturally to existing Qubes culture and rules, but with modifications to allow a decentralized bottom-up community based development.
- Modifications must make sense and be clear, and should be well argued as to why they are needed.

Maybe something like this as the basis from which we can build from? I think you make a strong point too, that we need some kind of vision or strategy, goal setting, I'll cite your words here as I think you pretty much nailed it.

Strategy vision - Goal setting:
- It drives merger of projects from community member to help one another when they want to achieve the same goal.
- It drives projects to have a well defined small scope.


The idea of forced phases, kind of like it's done on github when posting I suspect? It seems like a good idea, it gives some guidelines. We sould try make them flexible so they don't hinder creativity though. Maybe using a simple ranking system too? If we do something similar as to https://www.qubes-os.org/qubes-issues/ with the colored labels, just the difference being instead of being top-down based, a page discussed here would be bottom-up.

Maybe we could use drafts or something, so we can have better overview of the layout proposals being discussed.

I feel this is what you suggested too between the lines, that we should let this discussion go on for a while, so that more opinions and views and come in? I agree with that, there is no need for haste.

Andrew David Wong

unread,
Mar 1, 2018, 10:16:39 PM3/1/18
to Yuraeitha, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> @Laszlo
> I was indeed not aware of that page, it's pretty similar to the initial suggestion up above. (Thanks for linking it!). But there is a very crucial difference I think, it appears much more top-down focused than bottom-up, and also not focused on more every-day kind of issues. It's more focussed on directly Qubes related issues, and not so much issues which can make Qubes easier to use, more mundane things, and other things which might be very important to some people, but not everyone. It also has a single developer mindset, rather than inspiring people in the community to work together to archive a common goal. So it's both very similar, but also very different at the same time.
>
> I agree it should still be possible to block dangerous or out-dated guides/scripts/etc., that's my opinion/view as well. But what is sought here is also a method not to exclude people who try to start something (many people have creative ideas, but are unable to carry it out or finish it themselves, and it disappears). Something can be started up, and then later need/seek help from others in the community to help finish it. Have critical eyes on the work from others, which might also make people more daring to do something, which may not be bashful, but a friendly community to solve issues in development, in a similar way how we solve personal issues in these mail threads. It can be much more risky for an individual to try build something alone, and then stick ones head out, than it is if the process is transparent and everyone can see how it works. Not everyone is willing to face such a risk, even if they got the skills to finish it themselves.
>
> There is at least a good handful, if not 10 or so people around in these forums, who try to do something like this, but everyone are working alone. There are skill sets on vastly different degrees and types, but everyone doesn't need to have the same skills to be useful. A good example are Artists who can make artwork for Qubes content, or editors/writers/guide-makers whom usually would not write to a Qubes doc page, due to already mentioned reasons, or other reasons, it could be lack of time, or because the Qubes docs seem too official. I would make a guess here, that few people would want to post anything to a Qubes doc page if they didn't finish it up and make it pretty decent quality, before posting it. But that won't happen if low confidence/unfinished/lack-skillsets-and-need-to-work-with-others-to-finish-it/too-official/feels-like-it-must-be-finished-in-high-quality-when-uploaded.
>
> I get there is a quality problem with something like this, but that's also meant to be part of the discussion, as how to solve something like that. Should there be someone to edit the content, so one one runs a dangerous or unfinished script by mistake, etc.
>

Yuraeitha, it's clear that you're motivated by a strong desire to help
other users and improve the community over all. I greatly appreciate
that and sincerely thank you for it.

As for the matter at hand, I think it would help to have a concrete set
of examples of things (guides, scripts, etc.) that are demonstrably
valuable to some subset of Qubes users and that fell between the cracks
of our current systems due to the natures of those systems (and not due
to user error or minor tweaks we can make to the existing systems). The
second part is very important. For example, if some people refrain from
submitting good guides to qubes-doc because they have mistaken beliefs
about how the documentation works, which they continue to harbor because
they haven't bothered to read the Documentation Guidelines, then the
example will be not be very convincing, since objectors will point out
that the good guides *should* have been submitted to qubes-doc, and
hence that the solution isn't to introduce a new system, but to get
people to use the existing one correctly.

On the other hand, if you can point to a real example of a good guide
that clearly *doesn't* belong in qubes-doc for some reason (and is
demonstrably valuable to a subset of users, and clearly doesn't belong
in any of our other extant systems), that'll probably be a convincing
example of the need for the new system. (Moreover, it might help to
define the requirements of the new system.)

Likewise, if there's good content in the mailing list archives that can
be found by searching, but people aren't bothering to search or are
using the search bar incorrectly, then objectors will point out that the
problem isn't with the way the mailing lists work, but rather with
people not using or misusing it. By anticipating such objections, you'll
build a much stronger case for the need for a new system.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqYwgYACgkQ203TvDlQ
MDD0Ug/7BUyIkIvFm3fynP8LVrtE1nk99dIYYYO6Heo0cCIB9WGFYscZA9kKCFgI
eehCqdZLZkSrxGvIqReUWdw5ptH2bc4vodWfkf1HVMIGbqEVb2cC/C8rdwxNPEc+
AK2aYtkOMD5kYE9lUWsvf2otPNzVUCLL/BkUB9TRagWScQ9318+xkX6FZAWWpXrh
xru7Efvdm6eUKd/wL4cOMd7veiyerYEy+zldhbM9KWFEw8Dz1bLSALpC5fV2orps
GlfopXaa+ZytvnlRZHrrGlieWRV3P1HH2w7+enYlIC+2anlI1dQ34CK+tBAs4G/E
6Z204424EP7Nu+7yIgSw3vCKmf11pXVe1s5Bk3LL0LgwZLey8yVYk+byzasZaIcH
CcsXEXKcHmHj4k7uimrPTY/KE2K22Vv908x60xJHDe9Mmi/V8LojwWf44sa6qMaT
SUrgc80narDNRwDplz+UqjhfmuewvzpqvjXbPGRlwEivUKvfCISCNPuZ9o04FfF7
Fh+gb9mw+qx+eIXjXVDLjkBJ/qKmxYl2i/so4AXpwtsBlxo4F/a6sHM3SCXSUGtj
ebguGwoqo9HQPv9VXU04irj/cDKZ3dJYGqtuPG/ztpRFJHckYIgEPCyvzRKS1gMe
09zDIyN7WnBjCXATkH2KLcmJs+FZ4dlNxFSesRfquUJkg2bcEaI=
=ChoR
-----END PGP SIGNATURE-----

Yuraeitha

unread,
Mar 2, 2018, 1:12:47 AM3/2/18
to qubes-users
Thanks for the great feedback, I appreciate your insight and views, as well as the questions you bring forward too. I'll mention early on that I'm entirely open, I won't take it personally if this idea doesn't develop, I want to be realistic about it. If it doesn't work, then it doesn't work, and I agree that it should bring value to Qubes overall too, whether official or unofficial, actual real value is important.

I think it's an interesting perspective you bring into focus, whether it's how to communicate with people that might need a change, or whether it's the system that needs a change. I'll try return to this question below after discussing some ideas. It is difficult to put everything into a single post/view, there are multiples aspects to it, but I'll take a shot at it and try differentiate, trying not to use too many words.

The Qubes Air article https://www.qubes-os.org/news/2018/01/22/qubes-air/ is an excellent example and starting point here. It shows how Qubes is thought to grow beyond just a desktop computer, and for example into the cloud as well. This too, could further expand onto home-based cloud systems which remains within users own control, etc. I'm sure this is well thought out years ago as you started with building Qubes. But there are other areas, such as QubesTV, QubesNAS and other services which can benefit from Qubes too.

For example there are an increasing number of SmartTV's with microphones and now even web-cam's, and we're looking down the barrel of artificial intelligence coming into TV's as well. Making Qubes work on a TV, through a computer, therefore makes good sense I think. But it doesn't need programming to work, scripts and guides can solve many issues here, at least until the programming catches up and helps removing the need for scripts and guides.

This I think is a nice example, because it shows things can be made possible with Qubes early on, before the more advanced work goes into it (I got some working scripts already for a QubesTV, but I haven't uploaded them yet due to exams). Essentially, a community driven perspective can bring on early working versions for something very useful as the saying often goes in open source discussions "by building on-top the shoulders of giants", scripts can make Qubes into something it wasn't designed to be. It can also inspire future development through the community showing interest in some of these projects, while also at the same time giving early access. Thereby it can be easier to see what features users are interested in, and the scripts and guides may one day be replaced with more sophisticated and reliable programming code.

If people today want to use Qubes as a TV, it's certainly possible. But if we had to wait for the programming and coding, it might take years, or it might even never happen without the inspired focus by its community. Maybe you already thought of Qubes on a TV too but it was never mentioned. (I wouldn't know about that, but I'm aware I don't have that insight).

I'm not a programmer, and I'm not terribly advanced with scripts either. Though I put in time to figure out how they work, learning as I go, learning from others as well as hoping to help others learn too, like what [799] mentioned up above. There are others doing similar approaches, like [799] also mentioned in this thread further up above, as well as a known handful others on the mailing list working on their own projects, where projects come before the learning, thereby the projects drives learning, and learning provides results, rather than the advanced developer who already has the skills and know-how. The hope is that there will come more of people like us, and that we can help each others out with small projects that can benefit Qubes, so too welcome any help or suggestions from advanced developers, though the expectation is not to get help, but it's a welcoming gesture for whenever/if it happens.

Scripts and guides are not really seen as high quality compared to actual coding, and I agree with that. But it does provide early access to where development has still not managed to make a reach, and scripts (if done well) can be pretty good too, if not reaching a decent quality on their own.

Another example is scripts on how to take screenshots and move them out of dom0 and into a VM. Both [799] and I did our own, without realizing we both did same work, albeit it looked different, it would have helped if knowing about each others projects. So too with the Qubes updating script that I made, which Chris also had made. Double work was carried out, with existing solutions available. Each versions had their own strengths and weaknesses too, for example [799] made it copy to the clipboard inside the targeted VM, which I think was pretty ingenious idea for a script.

Another example is the graphics and looks of Qubes interface. I'll upload a picture below as an example, however it's not my artwork (artwork ownership disclaimer). This is just an example how artists can help contribute to Qubes, either indirectly or directly. This includes writing guides on how to do something like this without carrying risks to dom0, making sure the pictures are processed properly with the qvm-convert-img in an offline VM, opening it up in an disposal VM to process the pictures. (See attached picture). Guides like these might cluster the Qubes doc page too, especially as we move onwards over the years. Would there be room for something like this which is so far away from Qubes main focus? Maybe another alternative is to make a second Qubes doc page for non-system-stability and non-security Qubes central focused guides, but instead with content focused on everyday use of Qubes. Such as taking different kind of screenshots and moving them easily to any target VM with a single keybind. Changing Qubes graphics and doing it securely. Making a QubesTV or QubesNAS with scripts, and so many other similar projects, many of which might not even have been thought up yet, or some people sit with without sharing them.


These are things that don't get fixed in the current system very quickly, it's slow, but not without good reason. It's understandable that system feel and look, graphics, and interface design takes time to develop, and it should be remembered that the development on the security side is moving very rapidly (at least that's the perceived appearance to me). This is good, since it's what Qubes is all about right. But there is a lag of development on the usability of Qubes on the more lower levels like touch and feel, ease of use, and alternative use-cases of Qubes, such as TV or NAS systems. These are areas where the community can help bring in value, as they are not all that advanced issues to fix with scripts and guides, and it will save development time and focus to focus on the higher priorities first.

It's kind of supportive, having the community help fixing low-system needs. It also removes the problem of guessing what users want or need, because users will bring it up themselves through the community. For example the Qubes OS Project won't need to do what Oracle over at Ubuntu recently did to improve user-ability of Ubuntu, https://www.omgubuntu.co.uk/2018/02/ubuntu-data-collection-opt-out

The headline in that article, "Help Improve Ubuntu …By Doing Nothing" is showing a very strong contrast to what this idea is about. It's exactly by doing something, that will show Qubes staff what users use Qubes for, or is interested in using it for. This might be less of a concern when building the basic infrastructure and security of Qubes. But once the focus moves onto development of features and maybe even how to solve security around user habits, it might be insightful to gain insight into how users use Qubes.

By having the community build up awareness on its own, it avoids the whole need to collect data of users, or at the very least it's an alternative to it.


Whether any of the above examples can be solved through the communication with people, or through a different or changed system, is a good question, and I certainly don't want to push any agendas here. What works, works, and if it can be solved differently, then this is good too.


The value of bottom-up:
- The chance to become a part of something which people believes in is very inviting and motivating. It's within human nature to be part of something, a community. That's not meant to some kind of buzzword or empty pretty looking words, but to me is a very powerful mechanism found in many people's instincts. The downside with the top-down approach is that it's more of a one-way communication, while Qubes is truly amazing already as it is, but it hinders a community to truly grow to its potential. Perhaps it's undesired to have a community that takes shape on its own, if so I understand, it may not be something desired for a security system like Qubes to have a dynamic community with a lot of DIY types of people. But allowing Qubes users to take part, in a limited way of course, but still take part in Qubes, I think can have a powerful effect on the community's passion and ultimately increase creativity and work coming in from the community.

- Community transparency helps showing what everyone can do to help bring value. This inspires people to help bring forward their own creativity, ideas and work to make it happen. Perhaps someone has an idea or insight which they don't think much about until they see a discussion in the community, or maybe someone with a unique set of skills reads the discussion, and drops in to offer help, as well as varying degrees of skills.

- Decentralized work, in contrast to centralized work. It's true that github and open source in general invites cooperation, but it also has a dampening effect, especially when it's high quality like Qubes stands out to be. This puts off people who try to do work as they learn, and want to face risks by be allowed to take risks (to learn by making mistakes). The quality issue here, is thought to be solved by having others look at the work too, working together to fix issues. Maybe even put in a ranking system, similar to that of https://www.qubes-os.org/qubes-issues/ so that nothing unfinished or risky is run without users being aware of potential pitfalls that unfinished or complex DIY projects might carry. But the strength of DIY projects, is that carries immense creativity, especially if people feel that they can be allowed to fail, without being criticized or be turned away by a kind of silent/or-voiced dismissive message, but instead have others say "hey, this is an interesting idea, but maybe lets do this part over here a little different to make it work better."

Returning to your question, I hope it can be seen how different a bottom-up approach can bring value this way. I understand that it might not be desired to support something like this, for example it may not be desired to have a DIY kind of movement inside the Qubes community, for various reasons. Whatever the reason though, I won't talk further about the idea if its undesired by the Qubes staff, I highly respect your opinions and Qubes is already truly amazing as it is already in its present state, it's amazing work. What I think could add more value though, is to bring forward a way for the community to spur on innovation, ideas and taking initiatives, which is not being done by developers.

A good source here, could be to look into the corporate strategy books, which are typically divided into strategy lenses. Strategy by design, Strategy by experience, Strategy by ideas, and strategy by discourse.

Strategy by design is typically the leadership top-down directions, while strategy by idea is the ideas born from below, innovation and creativity, which can flourish better in more open and inviting environments. For example a very locked down organization, will have little invitation to innovation and new ideas. Similar can the experience strategy help with existing approaches, which is not unlike how we are already doing it in these mailing lists, we solve issues through experience. The discourse lens, is a means to challenge existing ideas, be it design, experience or ideas. Which is like what this discussion is all about, which has a very discourse strategy nature.

So, using that, what is proposed is a better environment to spur on Strategy seen through the Idea lens, spur on innovation and ideas, from within the community, by making the environment more suited to spur it on. For example by bottom-up decentralized projects, which start out unfinished, rather than being released finished.

I hope this post didn't become too long. I felt like I had to try put it all in a single post, which also felt kind of impossible too, as this is a very complex topic, with many reasoning's, different views, and ways to approach it.

Perhaps we should bring up more, or more detailed examples? I also have an exam in a few days, but I'll try see if I can bring some of my examples up more clearly when I find the time, it might take little over a week before I got much breathing time again. Hopefully others will share theirs too.

Artwork credits: https://www.deviantart.com/art/22-More-Firefox-Icons-124166413
Unfortunately I can't trace back the credits for the second firefox icon, which looks very similar to current Qubes icons, except it looks more nuanced/clear/detailed. Check the attached pictures.
Screenshot_2018-03-02_06-43-33.png
Screenshot_2018-03-02_06-44-57.png
a very small piece of QubesTV, rest to come.sh
screenshot-fullscreen-and-move-to-targetVM.sh

[799]

unread,
Mar 2, 2018, 2:49:16 AM3/2/18
to yura...@gmail.com, qubes...@googlegroups.com
Hello,

-------- Original-Nachricht --------

An 2. März 2018, 04:10, Yuraeitha schrieb:

> It would be interesting to hear if the Qubes
> staff think this is a bad or good idea though,
> or if they're neutral about it. At least I'm not
> planning to keep going with this if they think
> it's a bad idea

I don't think it's a bad idea and I think that projects like Qubes should also be supported by us the users.
What I would like to see is a clear differentiation between "official" Qubes Docs and the "community scripts/ideas" which don't met Qubes standards or which have a controversial discussion about it (if a proposed solution is "reasonable" secure).

Maybe a solution would be to create an own "unofficial" "Qubes Beta Scripts repository" where scripts/ideas can be shared and after the reach a certain quality level, they get pushed over to qubes-docs.

[799]

Ivan Mitev

unread,
Mar 2, 2018, 4:29:22 AM3/2/18
to qubes...@googlegroups.com
Hey,
I proposed more or less the same thing some time ago on qubes-devel but
it was a bit lost in the noise of a long thread [1] and then I didn't
have time to think about it.

I'm summarizing below some replies I got here and there about a
community doc area (whatever it's called - wiki, staging area, beta
scripts repo, ...) + some personal thoughts on the issue:

The community doc area itself:

- must not require *any* time from the Qubes team
- shouldn't replace the current documentation in the long term (either
willingly or not)
- shouldn't diverge from the official docs
- shouldn't duplicate the official docs (= no official->community flow)
- will there be restrictions on the content (topics / quality / ...) ?

Flow from the community area to the official docs:

- how often would PRs be submitted ?
- who would decide which content to pick for a PR, review it, and submit
to the official docs ? (IMO: anyone).
- what level of control ? ie. fully public area (but then what about
spam/bad content/...) ? Or would it need acks from the community admins ?
- who would operate this area, where would it be hosted (IMO we
shouldn't rely on git), how to make clear it is independent from the
"official" Qubes site/people ? ...
- are there enough people interested in handling that work ? (probably
Yuraeitha judging by his nice and detailed posts, maybe you ?, awokd ?
and probably me to a lesser extent but my workload is like a jigsaw).
- one of the idea of the community docs is to lower the bar to send
useful doc for Qubes so sooner or later people would find it easier to
send edits to the community area instead of the official docs; so:
* how to educate contributors to become accustomed with the
official docs' PR process so that they eventually begin to send PRs
there after contributing 2 or 3 times to the community doc ? (provided
of course that their doc is fit for inclusion in the official docs).
* how to prevent the community admins/reviewers/... from becoming a
bottleneck ?


We could open an issue and continue the discussion there if enough
people are interested.

Related issues:
- https://github.com/QubesOS/qubes-issues/issues/3629
- https://github.com/QubesOS/qubes-issues/issues/3495


[1] https://groups.google.com/d/msg/qubes-devel/tBqwJmOAJ94/4Hc8XrYhBAAJ

Yuraeitha

unread,
Mar 2, 2018, 4:05:46 PM3/2/18
to qubes-users
Those are interesting points [799] & Ivan, I agree with both of your views. I also like the concept of moving guides/scripts over to the official Qubes doc's for final review if it reaches a certain minimum of quality. Keeping it separate in some sense to differentiate quality, seems like a good call as well.

Some of the issues/questions addressed seems like they could be solved quite effectively and efficiently on a highly customize-able forum? For example we'd be able to segment things cleanly, like moving work/posts between forums as they develop and gain quality, until the final stage where it's polished and published to Qubes doc page for official review, once it meets Qubes minimum quality standards, but preferably higher than minimum of course, so we don't risk spam the Qubes doc page. Maybe some things, despite being good quality, might not belong on the Qubes doc page, what belongs there? Should everything with high quality be added? or should there be a category limitations in addition to quality limitation?

As you suggested, I indeed don't mind to help doing something like that either, if we're going with forum approach (or something else), can I help move the work topics (like a single topic for a project-work-place) between the forum quality segments as the various scripts and guides evolve. It's also interesting that project activity can be traced back inside that topic, even after it has been moved to higher quality, so that it retains its history. Also Ivan, even if you're less active due to busy real life schedule, it'd make sense if you have similar capabilities if find something that needs moderation and got spare-time to do it, which adds flexibility. I'm not sure who else might be interested in helping out with this either? For example we won't be around 24/7, even if you're more busy than me I can't be around 24/7 either, so it might be a good idea to have a team of moderators, though of course we can start small and scale up as needed with new moderators as we learn to trust new people over time. It shouldn't matter if some moderators are less active either. When getting new moderators, then we can also for example segment moderators and global moderators. While the global moderators can moderate all the content segments, and segment moderators is kind of self-explanatory at this point, which are those who have less responsibility, for example new moderators when the script community grows.

I think it also becomes more clear if we have different stages of development. For example if different stages have different kind of nature of qualities (See below). The first stage being a convincing useful concept. The second state practical solutions being developed. Then in order to reach the late polishing quality stage, it must have a united concept and roughly finished development. Then in the late stage, if it can't reach the final touch of subjective judgment, it'll remain there until it can surpass quality judgements. Then we could for example post all finished guides/scripts to the front page, which allows everyone to quickly see something is finished, without having to dig through all the otther topics, as well as people who only visit the website, only to keep check on the blog.

For example the blog front page allows people to quickly visit, to check if something new is out, and then maybe have a look at the details, perhaps find some weaknesses and give feedback in the comment section. This way it gives a last opportunity to bring it to focus and review otherwise finished work, even if people don't read all the topics in the forums. Once everything checks out, for example let it be 14 or 30 days on the blog page for additional review? before posting it to the Qubes docs.

- Early conception stage forum (concepts to be discussed, can also act as a spam filter).
- Middle stage development forum (work has started and its starting to take shape. One can start out alone, maybe others will join to help).
- Late stage polishing forum (testing, finding errors, security and reliability issues).
- Pre-review on front-page's blog (for i.e. 14/30 days).
- Published to Qubes doc page if it passes (or Qubes sub-doc page if needed).

Where appropriate, we can ask the question if it's fitting for a Qubes doc page. For example those 5 quality checkers you put forward Ivan.

Then, by looking into these different forums, one will know every topic is in concept phase, or if looking into the development forum and all topics are in their development phase and anyone can drop in to help in different topics. Yet another forum for the late stages, and all topics here require reviews, hunts for errors and polishing.

So we have a 2D axis here, one dimension is the segmentation of forum boards, forums, and sub-forums, while the other dimension is a layer of segment-users/moderator/global-moderator/admin capability. It adds a flexible work-place with flexible order and structure, and it's also very scale-able too as the community grows and/or changes over time. I start to like the forum idea, what do you guys think about it? Maybe there are some downsides/upsides I didn't consider?

We can also make sticky posts in the appropriate fitting forums, with information, guides and approaches, guides how to navigate and use the script community, and even guides introducing Qubes official website. For example we could help Qubes gain new people if they come to the script community first, before Qubes, so some kind of sticky posts like that seems warranted too.

It is also possible to make website pages next to the forum/frontpage-blog, for example if we need some pages for more visible content.

Some other considerations are the transparency, trust and logs, and the mix of privacy and freedom as well. Should we keep an eye on the logs on the moderators and admin changes, etc. Transparency is good, but it might also remove the need for trust, and trust is healthy as well. Similar keeping eyes on logs and looking over others shoulders and corrode trust too. Yet trust can also be abused if not kept in check, and power is said to corrode as well, corrupting a person. Seemingly it can happen to anyone, power is dangerous. So it's an interesting dynamic in various different direction of different issues connected, though, very problematic to balance properly in practice.

It seems like logs should be attempted to be changed on how they are viewed (a matter of shifting perspective). So that for example a moderator can feel relaxed with the logs, rather than being worried about making a mistake that can be seen in the logs or looking over ones own shoulder (which is stressful). Like logs can be empowering too for a moderator, which can justify actions. Seeing logs as a safety mechanism protecting a moderator, rather than as a means to hunt down corruption, while it still prevents corruption by protecting the moderator at the same time. I think this shifted perspective is value-able as a moderator or online community where someone has power. In the past I've felt comfortable with having logs, personally for me it removes the worry that some might speculate and make claims, like for example some random guy is claiming a moderator is abusing power, when one really is not, at which times having logs is very nice. And even if someone isn't throwing fingers, a moderator might feel uncomfortable with the possibility of people thinking it. So this way logs can also be seen as a way to humanize moderators, rather than dehumanize moderators, allowing to feel free despite the burden which the responsibility of moderation can carry.

Still pondering about the names, I haven't really thought about that yet. Those are some interesting candidates already, maybe we can align them all next to each others to compare and pick between, take some time to come up with the best name. It might also change depending on the platform/approach we choose? For example if it ends up on github then adding repository to the name makes good sense, but it might not make much sense on a forum or another platform. So I think it depends on what we choose to go with.

Thoughts about using a forum? Possibly with a frontpage blog?

If we indeed go with something like this, forum or some other platform, as you also questioned Ivan, who is interested in being a moderator? I'm okay with helping out with it, but I probably will need help to cover everything, especially when I have exams and so on. If having a handful moderators, it increases the odds that there always will at least be one around who isn't sleeping, at work, studying, living life, taking a break from online activities, and what else might cause down-time. Also creates redundancy if one or few is less active or becomes inactive. It might not be a big issue in the beginning though, considering we'd be starting out small.

btw a thought just occurred to me, we could also have a forum section (or something else if we don't go with forums) to discuss legal issues, for example what is appropriate/inappropriate, legal/illegal, ethical/unethical in regards to using existing work, such as codes and artworks. How to properly cite and credit them. Putting disclaimers where disclaimers needed. These waters generally seem very muddy, and it seems few people actually have full awareness of every aspect in this chaotic place of 'borrowing' from other peoples work. So it'd be nice to create a place where one can seek clarification on how laws and ethics play out, or even ask questions if unsure about a certain piece of artwork or code. Though we should probably put a disclaimer, that we're not lawyers. If anyone gets a lawsuit for copyright breach, that advice's in this forum are suggestive guidelines, and not professional lawyers (probably unlikely to happen unless it was some pretty bad copyright breach and one probably was not very careful with ownership checks, but still). It serves as a warning for users, while helpful legal information, it is still important to be careful and skeptical when working with other people's owned copyright, what is allowed, and what isn't. Which too also includes ethics of course, but I guess that depends on the individuals morale. Though any work done on such a place, I feel, should adhere to ethics too, and not just morale. Thoughts?

Andrew David Wong

unread,
Mar 3, 2018, 12:16:20 AM3/3/18
to Yuraeitha, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2018-03-02 15:05, Yuraeitha wrote:
> Some of the issues/questions addressed seems like they could be
> solved quite effectively and efficiently on a highly
> customize-able forum?
>
> [...]
>
> Thoughts about using a forum?
>

FYI, in case you haven't seen this thread:

https://groups.google.com/d/topic/qubes-users/2rqas38ncFA/discussion

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqaL5YACgkQ203TvDlQ
MDAB1xAAzWFSpxUdskyMekUg/K3oeH5umI7m2XMdlRw9AKYUtqKhxNgOOQv6DHTO
4uhFt5MMtmcae6XmfoRPMPGhLVMN7qUY7OeEz8EXzFUYa4DtSGdnf84ysRHYGD+k
U44j0Zb36sbH6ZuQfGoBf3Rydfb+rlHgZFH1iTQ+rMM8TUsn04KVD58E9UoMRKRm
ndKLlntPa+tUgD3LfKpTai2/pYvD4JDqBPpmL1OMVnQ7Fdi/H55EGV2B/aCW2O44
uyxHJX6BgnwvAeaMZtdE3NkpEIbbiMjSODLpma335j23wDn1r+FyI+xsdE8h9M9L
WJZjrKs5gfGHfvxef13xYScujjjEQGDBfZz5Os5IrLMJ12Riq+S79ARuJAxQeGop
SGXcQR+Qk4OnI3tPIX+zkVDKFXXmtJltQlDh7rfrP15d+/Il5ENoo2+RA+WlgQxS
/vcHmbXcytR6GwpS406umeGcYk4H95vFjvb+KJbJWHpltSQHJRCSGkxM3xVFFuLH
8oFIlfP/f9Huh0aI36jKzyScEESvdvUa0pHPJ279OqSjPZ8FsxpbaDUYKj+saXUU
gRLTXnDsOytJb/U/+gqcUF048R2KtK8YcLeH6bS1NFvkHEsG1TLs3ihdEndZXz6Y
TyzVe83QX1e+5g29CTUYd5B3yYMv8nOLmkWciqPExBZebLEYJ+c=
=oKGu
-----END PGP SIGNATURE-----

Andrew David Wong

unread,
Mar 3, 2018, 12:25:08 AM3/3/18
to Yuraeitha, Ivan Mitev, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2018-03-02 23:16, Andrew David Wong wrote:
> On 2018-03-02 15:05, Yuraeitha wrote:
>> Some of the issues/questions addressed seems like they could be
>> solved quite effectively and efficiently on a highly
>> customize-able forum?
>
>> [...]
>
>> Thoughts about using a forum?
>
> FYI, in case you haven't seen this thread:
>
> https://groups.google.com/d/topic/qubes-users/2rqas38ncFA/discussion
>

While at it, here are some other old threads where similar ideas have
been suggested:

https://groups.google.com/d/topic/qubes-users/D0YuoXMe_vE/discussion

https://groups.google.com/d/topic/qubes-users/es4q40dt1EE/discussion

Approximately every 6-12 months since the beginning of the project, a
new person (including me, at one point, IIRC) suggests that there
should be a Qubes wiki or forum, so you'll find many more threads like
these if you search through the archives. :)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqaMZcACgkQ203TvDlQ
MDDD4xAAwbajnwJ/PZxzrVnmzKECGkYVQQDs90LieN1s/ewuqilNx9Cdxk8Fy9La
jokevIemgSB/QjqRD1zl2L0ksn/XhsOgQyWyK+RCSNWdKsvDhJtsVvh0B5SA5t4N
FrMzig0uUHLodl9ZOT9ltvy/nOnMBj8YcfQ2i+3yEaOFSN6hc7DkyXnPRhLbEdrK
pwJJxbdAkvocSu6tEL1xE86cZ1CZrBIHvrVt1oCy1QPCr5EBNUukg4JMGOygZNi2
62TF+/vv1Fe9IeJ7tu+WaZLIJQ1guLesYMISMHAvsUaAwB+vbMFUFuRhHqhiB7Ir
qEyrf5S24aulX/F9w8043088Wd+RA/lWG2lyXZk3w9H+Gqn2UOKnKnJRCFxBmkbE
O+TS3/U4pB5t/4K9oezKc9dSODEt4RZO4LSN9U0i5Ksp4q1WDJyJC7eyRnQTpDc6
sQHHCi3d0kFTxDozcjCJPFTLhE3OYqBfCClMmCXlLhL1j2/N0XS9nOYWRL2foA1R
FLaE4lOBuoNcAQO/XTXMEd3F2XUlCKOiLCLdNCVIYyhZJSFwHqpwt8pRLRk6n2hs
EdiyVGQh4uyOt1rWEniPEyyb2Bx/MLSYT4iafU/3ltY7uKbzDpmaUSP+oVZd6+gj
6eEpVFlDzp4kfTCFRj3a/Gx8Ail4P9/KmHp+tBVfxrWQrFi+bWs=
=I6G3
-----END PGP SIGNATURE-----

[799]

unread,
Mar 3, 2018, 5:09:47 PM3/3/18
to yura...@gmail.com, qubes...@googlegroups.com
Hello yuraeitha,

-------- Original-Nachricht --------

An 2. März 2018, 22:05, Yuraeitha schrieb:

> Thoughts about using a forum? Possibly with
> a frontpage blog? If we indeed go with
> something like this, forum or some other
> platform, as you also questioned Ivan

I don't know what the right platform looks like to share scripts and howtos which didn't make it to Qubes docs yet.
But what I know is that I would like to have something available as soon as possible.
I would call my self still a Qubes newbie which is a great opportunity to write documentation because I try to implement my existing workflows on Qubes and as soon as I find out that it will not work I am trying to work around it: either by changing my workflow or by enhancing Qubes so that it fits better.
This "knowledge" is interesting to be shared for other newbie users or people who are interested in Qubes, mainly because...

1) people might be interested in Qubes, but are looking for information if their current workflow could be done on Qubes

2) if they need to change their workflow, they might be interested what would be a good approach

3) an active community is a very good advertisement.

Thereof I think having a place at GitHub, where we can consolidate information is a good thing.
Two reasons:

1) we know how to use GitHub
2) transfer of "qualified documentation" to the Qubes docs will be easy.

Neverless it could make sense to present some of the more interesting subjects which have reached a certain quality level on the Qubes Blog or another blog.

Please keep in mind that Qubes is and should be very interesting for user which are not that experienced with Mailinglists and GitHub, they also have the right to be reasonable secure and thereof the access to the documentation should be easy in the end.


> who is interested in being a moderator? I'm
> okay with helping out with it, but I probably
> will need help to cover everything, especially
> when I have exams and so on.

I could also help out, but I don't think that there is much need to do so. If we are using Github as repository (soemthing maybe named "qubes-community-playground") we can start to use it.
Honestly I expect to see much more people take a very short look there to scan if there is something that is useful for them, instead of actually contributing documentation themselves. But this is totally fine.

I am currently writing a how-to to access Microsoft Exchange under Qubes which could be interesting to others, of they want to decide if they try it all.
While I could add it to my own GitHub repository it would make more sense to share it and to improve it step by step.

Maybe also a page like: "I wish Qubes would allow me to ..." where users leave their wishes and maybe others have a quick idea how to solve this. This could become something like a backlog to improve Qubes even further.

[799]

Yuraeitha

unread,
Mar 3, 2018, 8:01:40 PM3/3/18
to qubes-users
@[799]
Maybe we can do both and increase the overall value altogether? I'll understand if you don't think that is a good idea, but lets for a moment try see if a merged forum/github-wiki concept can work. We could make a sub-forum or even a whole forum section for GitHub account activity. Make a sticky post which is kept updated, with overview and introducing every GitHub content developers who are making unofficial work to Qubes. Then below that, everyone can post a detailed post for their GitHub page, listing and giving brief or detailed explanations of what it brings of value. Essentially it's possible to promote ones work here, so that others can find it.

So overall, for example one forum section for guides on how to use and get into Qubes (i.e. new people to Qubes, and how to get started). Another section for work on scripts and guides with sub-forums, moving the scripts/guides over as they develop. And a final forum section to polish the scripts/guides to finish them. Then we can have a forum section for GitHub pages as described above, this way, people can choose the degree they want others to meddle in their work. For example GitHub while cooperative, doesn't tend to have others come in unless there is an open invitation there, or if the other party is rude. But on the forum here, it's an open invitation to come and work together on a project. This way one can preserve a form of individuality too, and invite others in naturally through the forum as a framework, if that is what is desired. The forum will then focus on both approaches, whether it's promoting/sharing work done on, or inviting on projects for work to-do.

As such people can choose the style they like. Also in addition to that, not everyone enjoys working in groups, but some enjoys working alone (and that should be respected, imo). For example it may fuel energy and be relaxing to work alone (it can even be a way of relaxing after a long day at work/similar), while in contrast it would be exhausting to work with others. Essentially the embodiment of being introvert and extrovert, both I think is completely normal and none is better than the other. People who gain energy working with others prefer a different work-style. Nothing wrong with it either, it's just how people gain energy, there is nothing bad about either of the two.

I think if we mix the approaches together, we can add value to both suggestions. It's also easier to have discussions for both groups, for example a forum for the copyright/law discussions on using other people work, so that we can be better informed on such matters. We can also highlight some kinds of works in various of different forums, wherever there is people willing to discuss or read, and all this can be closely tied to GitHub and GitHub Wiki's. What do you think of a merged approach?






@Andrew
Those are interesting older threads indeed, it gives some good new insight. I apologize that I did not find them, they are indeed very useful.

In regard to some of the discussions, for example in the thread you started back in 2016, on the concern of preserving the mailing list. I have a suggestion to solve that issue, instead of polarizing the different solutions trying to replace the other. The idea here is to combine them all together and make use of all of their strengths without introducing too many new weaknesses, similar to what is suggested above with GitHub users/wiki's.

By replacing a forum with a link (some forums easily allow this), with a short warning, i.e. in the description below that it'll take the user off the forum to the google mailing lists. So in that essence, the forum would only fulfill anything not already fulfilled in the mailing-lists, as the mailing-list would essentially be directly integrated into the forum, without users on the mailing-list being forced to use the forum. This might solve any/most? of the concerns. Maybe I overlooked something? The mailing-lists can keep functioning exactly like they do now, but users of the forums will automatically be made aware of the mailing-lists too, and anything normally done in the mailing-list will not be done on the forum, thereby making a sharp clean purpose of either that is easy to quickly grasp for new users.

The mailing-lists can also be hard for new users to discover from the Qubes website, so by having the mailing-lists integrated into a Qubes forum, it could make everything interconnected with the Qubes website as a starting point; the Qubes website, the Qubes forum, and all the mailing-lists, all unofficial GitHub projects, even the official GitHub projects, which could be made very visible and near top on the forum, and replace some of the forum links with direct-links, before more of the actual forum-only parts comes below it. The first forum section could remain as a forum to introduce Qubes to new users with sticky posts, but then after that we could put the mailing-lists segments and GitHub project forum segments. After that, once existing systems are fully integrated, the other forum segments can be put below, for example the community working on scripts/guides, having volunteers move them across the sub-forums in the segment as they develop and mature, keeping it tightly organized and easy to read for anyone looking. Then maybe a forum to discuss law and ethics, so that developers have a means to discuss the muddy water of using other people's work.

Also anything that should be kept in focus, but happens to drown in the mailing-list since they can't be stickies to the top of the mailing-list, could instead be put in the forum where they might be more easily found. This could potentially lower the activity in the mailing-list a bit, but over time, I think it would benefit both. I believe a structure like this is more welcoming to new users, and thereby it might even help increase the mailing-list over time, since the forum is promoting the mailing-list, not replacing it.

About the ties to Qubes itself, I believe the different options can look like this. (Maybe I overlooked one, anyone feel free to correct me if I did).

1) Qubes ownership - Official Qubes board decisions - Q-Staff day-to-day run.
2) Qubes ownership - Official Qubes board decisions - Volunteer day-to-day run.
3) Qubes ownership - Official Qubes board decisions - Q-Staff/Volunteer mix, day-to-day run.
4) Qubes ownership - Unofficial board decisions - Volunteer day-to-day run.
5) No Qubes ownership - Unofficial board decisions - Volunteer day-to-day run.

I did not put in staff/staff-mix in day-to-day in option 4/5 if the forum's long term board decisions are not controlled by the Qubes staff. I mostly did that for legal reasons to protect Qubes if the forum did any wrong-doing or if it shines bad light on reputation, but in theory it could also include some staff members in the final column. Option 4) and option 5) might therefore be best run off-site away from the Qubes website or official associations. Option 4 however, serves as a commission, exactly like in business and business law, where Qubes retains the ownership, but not the control over the asset, and thereby is not responsible by its actions, but reputation might still affect it, so if reputation is an issue, where such a risk exist if it has no long-term board control. Then either option 1/2/3 or 5 might be better, if reputation is an important aspect. Option 4 is therefore not without risk, although it'd have to be pretty serious issues for it to link across. Still, if preferring to keep the forum close to the Qubes, option 1), option 2) and option 3) are better, but here the question is more what kind of day-to-day management to keep, and reputation is less an issue to run out of control, because it stays in the long-term board control.

Personally I think option 3) is the best one, meeting every needs. It stays in Qubes control, and long-term board decisions of the forum is not very time demanding. Furthermore, by keeping an admin/primary moderator, to ensure everything runs smoothly, but by having volunteers help out with the more day-to-day work on the forum, this way everything is still tied together, but it minimizes a lot the work you guys have to do. For example if Marek or Joanna keeps the ownership of the forum as they do with other aspects of Qubes, and if you Andrew can keep oversight of the volunteers? For example moderators can also be segmented into different forums, so have limited responsibilities, or others who have broader responsibilities and act as global moderators across all the forums (not as admins though).

Could something that like that work? Combining all the strengths into a single platform, without taking away GitHub/mailing-list, but even strengthening GitHub/mailing-list through the forum by promoting them, while the forum keeps activities that can't be done on other platforms. By using option 3), to minimize work done, while keeping it close to Qubes. Could this be seen as a win-win-win for everyone? or does it have drawbacks/downsides I'm not seeing?

Yuraeitha

unread,
Mar 3, 2018, 8:11:08 PM3/3/18
to qubes-users
I forgot to take the wiki aspect fully into it too, but that too could be integrated into the forum as well, and it also makes it much, much, much more easy to maintain a decentralized GitHub wiki as a moderator can edit the sticky post in the wiki forum segment, and this way the forum serves not only as a forum, but also a as hub to all other Qubes platforms. It can also help promote Qubes donation website over at https://opencollective.com/qubes-os# and the other off-site webpages. Essentially the forum, I think is a very powerful platform to increase awareness of the other platforms, while also serving as a forum at the same time, without trying to replace what the other platforms are doing, and then add value on its own in those areas where forums make more sense to use.

Alex Dubois

unread,
Mar 4, 2018, 5:49:32 AM3/4/18
to qubes-users
Apologies, I don't have the bandwidth to read the full thread.

I had some thought.
- Qubes team probably don't have the time to spread too thin, and would prefer for us to help them on there Qubes repo
- Some people invest time in documenting, but it takes time for Qubes team to validate the pull request, and sometime they may prefer to not accept the PR.

I think one of these 2 options would be a first good step in the right direction:
- Qubes team provides a fork of qubes-doc in another project on which community members accept PR that can then be accepted as PR upstream on the official qubes-doc, qubes team only manage the access right for the PR (?)
- Someone is happy to put the effort to do option 1 and manage it (which should be limited to access right to that repo to trusted comminutity members to accept PR), as long as Qubes team agree with the approach

The aim is to have as much help as possible pushed to Qubes project while filtering and nurturing the efforts.

I have one concern with such proposal. A number of community proposal are sometimes not very secure (to be gentle). So ideally a layer of meta-data is added (maybe on a single index page), with the rating of the doc page.

799

unread,
Mar 4, 2018, 3:04:05 PM3/4/18
to Alex Dubois, qubes-users
Hello Alex,


2018-03-04 11:49 GMT+01:00 Alex Dubois <bow...@gmail.com>:

I had some thought.
- Qubes team probably don't have the time to spread too thin, and would prefer for us to help them on there Qubes repo
- Some people invest time in documenting, but it takes time for Qubes team to validate the pull request, and sometime they may prefer to not accept the PR.

It is important to communicate why a pull request has not been approved.
This communication takes some time and also fixing the issues

I think one of these 2 options would be a first good step in the right direction:
- Qubes team provides a fork of qubes-doc in another project on which community members accept PR that can then be accepted as PR upstream on the official qubes-doc, qubes team only manage the access right for the PR (?)
- Someone is happy to put the effort to do option 1 and manage it (which should be limited to access right to that repo to trusted comminutity members to accept PR), as long as Qubes team agree with the approach

I agree that this will be the easiest option and allows us to start collecting scripts.
I am unsure if we really need to fork the whole qubes-doc as this might lead to confusion where to work when improving the existing documentation.

Can't we just create a new "community" repo where Pull request get reviewed by us but finally approved by more experienced Power Users (this group can include Qubes OS Team, but also experienced community members selected by the Qubes Team/David)?

I have one concern with such proposal. A number of community proposal are sometimes not very secure (to be gentle). So ideally a layer of meta-data is added (maybe on a single index page), with the rating of the doc page.

Agree, it might feel frustrating in the beginning of you start contributing docs and then find out that the "nice idea" that you had leads to several security risks or is just not yet ready to be released.
But: this is exactly the point what I like about Qubes. That I can rely that it's not that easy to do something stupid which compromises security. 
As such writing docs or scripts always include a learning curve which is a good thing.

[799]

Tai...@gmx.com

unread,
Mar 4, 2018, 3:48:51 PM3/4/18
to qubes...@googlegroups.com
I will not be participating in any website or wiki of this type if
people with zero qualifications are allowed to provide "advice".

There are quite a lot of people on this list giving literally dangerous
advice or telling people not to bother with increasing their security
with libre software/hardware because of vague theoretical backdoors...of
course they fail to mention the actually *proven* backdoors in closed
source software/hardware - considering that qubes etc is used by people
in oppressive third world regimes bad advice well intentioned or
otherwise can get people killed what they are doing goes beyond simple
incompetence.

I believe the minimum of qualifications should be having at least one
owner controlled motherboard with coreboot/libreboot/OpenPOWER firmware.

As a starter rule I would also say that people who have gmail/microsoft
accounts should not be allowed to comment at all because they probably
have no idea what they are doing[1].

I also suggest that it be hosted on a platform that respects its users,
which excludes anything google cloudflare microsoft source-forge etc.

[1] qmastery man you clearly have actual skills why do you keep using
one? its not like there aren't alternatives either paid or free not only
are you giving up your data you are helping them with their AI research
that will put people out of work every time you complete a re-captcha.

799

unread,
Mar 4, 2018, 4:17:57 PM3/4/18
to Tai...@gmx.com, qubes...@googlegroups.com
Hello Taiidan,

Am 04.03.2018 9:48 nachm. schrieb "Tai...@gmx.com" <Tai...@gmx.com>:
I will not be participating in any website or wiki of this type if people with zero qualifications are allowed to provide "advice".

What does "zero qualification" means and what does "advice" stands for?
It's not about advicing (advice to me means: I know something better then someone else or at least I feel knowledgeable enough to tell other people what they should do).

There are quite a lot of people on this list giving literally dangerous advice or telling people not to bother with increasing their security with libre software/hardware because of vague theoretical backdoors...

If so, those users should be given constructive feedback and guidance. Keep in mind that those "users" are still more likely to listen than the "average" user, who has no interest in privacy at all.

I believe the minimum of qualifications should be having at least one owner controlled motherboard with coreboot/libreboot/OpenPOWER firmware.

I don't see how qualification is "certified" by running Coreboot/Libreboot?
I am running coreboot does this qualifies me? Keep also in mind that there might be users who need to run recent hardware or hardware that are not on the Coreboot Hardware Compatibility List (HCL).

As a starter rule I would also say that people who have gmail/microsoft accounts should not be allowed to comment at all because they probably have no idea what they are doing[1].

Writing from my Googlemail address which is only there for Qubes+Coreboot Mailinglist because Protonmail doesn't offer IMAP:
Not using Google doesn't make someone superior, and even if you are right that there are reasons not (!) to use Google for personal E-Mails:
If you don't allow them to comment,there is no possibility for a discussion and convincing them to try something different.
And if so, then Qubes should not run this Google group/Mailinglist ;-)

[799]

awokd

unread,
Mar 4, 2018, 4:44:40 PM3/4/18
to 799, Alex Dubois, qubes-users
On Sun, March 4, 2018 8:04 pm, 799 wrote:

>
> Can't we just create a new "community" repo where Pull request get
> reviewed by us but finally approved by more experienced Power Users (this
> group can include Qubes OS Team, but also experienced community members
> selected by the Qubes Team/David)?

I wouldn't mind helping out on reviews on something like this, as well as
contributing my own half-baked ideas. Can't really commit the time to be a
forum moderator, but something like this would work.


sevas

unread,
Mar 4, 2018, 6:48:23 PM3/4/18
to qubes-users
A forum is a must. It doesnt have to be official. But it needs to happen.

It needs to have a section for
-Questions & -Community Tutorials
at the very least.

The Kali forums is a great example of what a qubes forum should look like.

[799]

unread,
Mar 4, 2018, 7:41:26 PM3/4/18
to sevas, qubes-users
On 03/04 03:48, sevas wrote:
> A forum is a must. It doesnt have to be official. But it needs to happen.
> It needs to have a section for
> -Questions & -Community Tutorials
> at the very least.

the only problem with a forum is, that it produced overhead in order to
keep the forum software secure and up-to-date.

[799]

Yuraeitha

unread,
Mar 5, 2018, 2:08:51 AM3/5/18
to qubes-users
@Taiidan

If the goal is to target people who have little knowledge of security and make them more aware, then how to do this is very, very different than targeting people that seek to maximize security as far as possible, and keep learning in order to do just that. Most people are the former, not so many the latter. But the point is, those who seek to maximize security, will keep seeking answers and keep learning, while the other group spend very little time and energy on security.

So the problem here, if the community is off-putting, rude, elitist, or heavily rule based, then you will scare off exactly the kind of people that needs quick information and help to build a stronger security, while it will take much more to put off those who seek to maximize security whom are likely to stay.

But here an elitist or iron tight rule based community is created, in contrast to an open, welcoming and culture based community. If the goal is to reach as many people as possible with proper security, then a balance has to be sought between these two extremes.

You would have to first put forwardd the question, who is the target group? Is it the people that seek to maximize security? or is to spread out and make people more aware and use better security?

Both can be achieved too, one does not exclude the other. But heavy use of rules and elitist attitudes will surely push anyone away who puts little time and effort into security.

If you want both, then a lot more effort has to be put into forming the proper culture and codex among the user-base, and this is often what community designers are either lazy or ignorant about.

A proper community archiving both, would have to be a constant process that keeps working towards building the community, and not some place that is set in stone and unchanging.

What is needed is contant effort, and not to become lazy or ignorant about the community, but keep working on maintaining the balance and quality.

I agree with your view that some checks and rules are needed, but what can be shaped and guided through culture, should be done through culture, not by rules just because someone likes and feel better about rules (people are different, and that's okay).

If a person wants to spread and increase awareness of proper security, but at the same time want to lock-down the community hard by heavy use of rules, then that person has a cognitive bias. So I want to ask, who do you tihnk is the target group? Spreading the awareness of security, requres the human factor/psychology/culture to be included.

Alex Dubois

unread,
Mar 5, 2018, 2:28:14 AM3/5/18
to 799, qubes-users


Sent from my mobile phone.

On 4 Mar 2018, at 20:04, 799 <one7...@gmail.com> wrote:

Hello Alex,


2018-03-04 11:49 GMT+01:00 Alex Dubois <bow...@gmail.com>:

I had some thought.
- Qubes team probably don't have the time to spread too thin, and would prefer for us to help them on there Qubes repo
- Some people invest time in documenting, but it takes time for Qubes team to validate the pull request, and sometime they may prefer to not accept the PR.

It is important to communicate why a pull request has not been approved.
This communication takes some time and also fixing the issues

Yes agreed and the fork would be a good staging area/first pass


I think one of these 2 options would be a first good step in the right direction:
- Qubes team provides a fork of qubes-doc in another project on which community members accept PR that can then be accepted as PR upstream on the official qubes-doc, qubes team only manage the access right for the PR (?)
- Someone is happy to put the effort to do option 1 and manage it (which should be limited to access right to that repo to trusted comminutity members to accept PR), as long as Qubes team agree with the approach

I agree that this will be the easiest option and allows us to start collecting scripts.
I am unsure if we really need to fork the whole qubes-doc as this might lead to confusion where to work when improving the existing documentation.

I think it is important to keep it as a fork for few reasons:
- most importantly we focus on helping the Qubes team 
- if not it would be hard to clean-up what is in Qubes-doc, in the community repo, and if the Qubes-doc get improved directly, it won’t be ported to community, leading to not up to date info

That does not prevent the fork from starting new areas of documentation.

I strongly feel that if it is not a fork we will dilute our contribution to the project. 

If David does not have the bandwidth to manage the access right, I feel awokd is a good candidate too. He acquired a good visibility of the overall doc.

However I think my suggestion is only to be taken with Qubes team validation.
And if they feel it is not the best way and prefer the mailing lists and existing infrastructure it is important to respect that and get back in line. 

It is also important to not spend too much resources discussing this, but rather contribute directly. 


Can't we just create a new "community" repo where Pull request get reviewed by us but finally approved by more experienced Power Users (this group can include Qubes OS Team, but also experienced community members selected by the Qubes Team/David)?

I don’t have much experience in managing communities.

I feel that a pair/trio need to be “responsible” per area or subject. With a person helped by one or two for the overall. 




I have one concern with such proposal. A number of community proposal are sometimes not very secure (to be gentle). So ideally a layer of meta-data is added (maybe on a single index page), with the rating of the doc page.

Agree, it might feel frustrating in the beginning of you start contributing docs and then find out that the "nice idea" that you had leads to several security risks or is just not yet ready to be released.
But: this is exactly the point what I like about Qubes. That I can rely that it's not that easy to do something stupid which compromises security. 
As such writing docs or scripts always include a learning curve which is a good thing.

Yes and different people have different expectations.

But I think an index page rating the security level or enumerating the risks identified would be nice.

For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn in line (I.e. sys-firewall). This is a bad practice as the attack surface of one protocol is exposing the entier Qubes system. 
A better way is to have these hosted on app-vm and have sys-firewall intercepting and routing the traffic. 
Even having sys-firewall doing the download rather than a dispvm is increasing the attack surface (not sure if still the case)

All these points are not criticism of Qubes, perfect security does not exist, but capturing them in a central place would be beneficial. That said, the most important thing is that I am at fault for doing this in an email rather than in a PR.
But this same PR done in the community staging area would give some bandwidth to Marek and co. 
However Marek may loose visibility on how things are going so David or awokd need to sync with him a summary. 

[799]

Alex Dubois

unread,
Mar 5, 2018, 2:58:01 AM3/5/18
to aw...@danwin1210.me, 799, qubes-users


Sent from my mobile phone.

> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote:
>
>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>>
>>
>> Can't we just create a new "community" repo where Pull request get
>> reviewed by us but finally approved by more experienced Power Users (this
>> group can include Qubes OS Team, but also experienced community members
>> selected by the Qubes Team/David)?
>
> I wouldn't mind helping out on reviews on something like this, as well as
> contributing my own half-baked ideas.

True we could have sandbox per person, or each person fork (the fork) and we have a page with list of forks
Once idea is ready, do a PR to the community fork...

This is the spirit of git

799

unread,
Mar 5, 2018, 2:59:35 AM3/5/18
to Alex Dubois, qubes-users
Hello Alex,


05.03.2018 8:28 "Alex Dubois" wrote:

I think it is important to keep it as a fork for few reasons:
- most importantly we focus on helping the Qubes team 
- if not it would be hard to clean-up what is in Qubes-doc, in the community repo, and if the Qubes-doc get improved directly, it won’t be ported to community, leading to not up to date info

Valid points, I agree.

However I think my suggestion is only to be taken with Qubes team validation.
And if they feel it is not the best way and prefer the mailing lists and existing infrastructure it is important to respect that and get back in line. 

I love the work of the Qubes Team, don't get to me wrong, but I don't understand why and how they could block the community effort to create a fork?
Some of use have already forked the docs and are currently developing their own improved scripts.
Doing so in a collaborative and centralized way would be much better.
But - I would like to see of course - that Qubes Team is also supporting this idea and knows about it.
One reason was also to indicate clearly which part of the documentation is official and thereof reasonable secure and which is unofficial and maybe less secure.
I definitely like the idea of an index page / rating system.

too much resources discussing this, but rather contribute directly

Let's go, I am ready to start.
@David (in his role of the community manager):
What do you think?

I feel that a pair/trio need to be “responsible” per area or subject. With a person helped by one or two for the overall. 

Yes, but we have already some interested people here, I think we only need to discuss the approvement process and how and if of those ideas/scripts might be placed more visible (maybe as a link) somewhere on the Qubes website which is the main area for new users (?).
At least a link to it, with maybe a disclaimer:

"Take a look what is happening in the Qubes Community.

DISCLAIMER: the content there should be treated as work in progress and has not been reviewed by the Qubes OS Team and maybe thereof less "reasonable secure" or maybe even opening attack vectors to your Qubes installation.
Even more if you implement a script which you haven't reviewed (and understood) and which has not been marked as meeting the Qubes OS quality standards.
WARNING:
If you implement changes in dom0 or the sys-VMs (sys-net, sys-firewall, sys-usb) this might result in a total loss of security"

For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn in line (I.e. sys-firewall). This is a bad practice as the attack surface of one protocol is exposing the entier Qubes system. 
A better way is to have these hosted on app-vm and have sys-firewall intercepting and routing the traffic. 
Even having sys-firewall doing the download rather than a dispvm is increasing the attack surface (not sure if still the case)

This is a good example, is there a disclaimer or security rating on the qubes-doc pages?

[799]

Yuraeitha

unread,
Mar 5, 2018, 3:43:19 AM3/5/18
to qubes-users
This isn't directed directly at anyone in particular, but I don't get why there is all the fuss about a quality issue though, after all, these guides/scripts are meant to have many eyes on them and critical views. Like others have said too. Take for example the suggestion with the multiple sub-forums having moderator volunteers (who have proper insight) moving them along as they mature. This would heighten the quality, by only accepting guides/scripts which had proper review of knowledgeable people, would be put forward. Similar can be done with individual works too, which can be put under review before acknowledged.

NASA is doing something similar to this for their research projects, although it does hinder their innovation, but it does increase efficiency on cost and reliability of projects, while still preserving some levels of innovation in it.

The point here, is that nothing gets through the process before it had proper review, it will only come through if it has a certain quality to it. If creators misses something important, or ignores vital security/reliability implications, this will more likely than not be caught in the review process. Also the review system could be made so that it can withdraw it's acknowledgments, thereby if anyone should ever finds a reliability/security issue, it can be taken back as well.

If people run un-reviewed or criticized guides/scripts, despite being warned not to, or to be careful and try to understand what the script/guides does before executing it, then if they don't do that, it's their own fault.

What worries me a bit, are self-fulfilling prophecies, by being worried about an issue, that the person essentially creates the issue by focusing too hard on it. Many of these issues we can solve, it's not rocket science, they're not impossible obstacles that can't be overcome. The problem though, is if some don't want to consider the whole full complete picture, and focuses too hard on their self-fulfilling prophecies. We need to take a step back and reflect more on a holistic and abstract level, before returning to the details again, and then constantly shape the big picture until it improves.

If guides/scripts are constantly checked and corrected every time someone finds a flaw in them, then what's the issue? Why is this issue blown so much out of proportion? We're talking about a review system no one else is doing on the internet here (maybe I overlooked it, the internet is massive, but it's not common knowledge at least).

Generally, the criticism that follow other poor guides/scripts on the internet, does not automatically warrant criticism of guides that are put through an open review system like this.

I don't want to see criticisms born from examples of other places, when a review suggestion is different from any of these places the criticisms are born. Lets be practical about this, we can't just move criticisms from one place to another, without first taking into account if the system produces the same issues or not. I'm not saying this to any particular person, but an attempt to try get back on the ground again, we're moving too far into the details without looking at the big picture. <-- if a person does that too much, they become legitimately insane as a result, so too a discussion can become insane too. We need some practical reality checks here and stay on the ground.

It's a bit of irony that wanting closed development by few developers only, kind of echo's the mentality of closed proprietary code, rather than the mentality of open source. The whole idea of open source code, is reviews and checks, this is just a shift towards doing the same with guides/scripts as well.

Yuraeitha

unread,
Mar 5, 2018, 3:49:15 AM3/5/18
to qubes-users

I mean, if anyone think the NASA approach is flawed, good luck trying to argue against it without some pretty solid reasoning. It's true that innovation is hindered some (but not totally), but they do manage to cut down cost and increase reliability. So too, the same should be for open community scripts/guides.

It'd be exactly the same NASA is doing for their development projects. Who is still saying it will produce bad guides/scripts? I mean, if anything, these checks do increase the reliability/security. Taking examples from elsewhere on the internet is futile and pointless, because no one (or very few) are doing the same as NASA is doing to ensure quality checks. And this is essentially what is being proposed here.

Alex Dubois

unread,
Mar 5, 2018, 4:47:48 AM3/5/18
to 799, qubes-users


Sent from my mobile phone.

On 5 Mar 2018, at 07:59, 799 <one7...@gmail.com> wrote:

Hello Alex,

05.03.2018 8:28 "Alex Dubois" wrote:

I think it is important to keep it as a fork for few reasons:
- most importantly we focus on helping the Qubes team 
- if not it would be hard to clean-up what is in Qubes-doc, in the community repo, and if the Qubes-doc get improved directly, it won’t be ported to community, leading to not up to date info

Valid points, I agree.

However I think my suggestion is only to be taken with Qubes team validation.
And if they feel it is not the best way and prefer the mailing lists and existing infrastructure it is important to respect that and get back in line. 

I love the work of the Qubes Team, don't get to me wrong, but I don't understand why and how they could block the community effort to create a fork?
Some of use have already forked the docs and are currently developing their own improved scripts.
Doing so in a collaborative and centralized way would be much better.
But - I would like to see of course - that Qubes Team is also supporting this idea and knows about it.
Same

One reason was also to indicate clearly which part of the documentation is official and thereof reasonable secure and which is unofficial and maybe less secure.
I definitely like the idea of an index page / rating system.

too much resources discussing this, but rather contribute directly

Let's go, I am ready to start.
@David (in his role of the community manager):
What do you think?

I feel that a pair/trio need to be “responsible” per area or subject. With a person helped by one or two for the overall. 

Yes, but we have already some interested people here, I think we only need to discuss the approvement process and how and if of those ideas/scripts might be placed more visible (maybe as a link) somewhere on the Qubes website which is the main area for new users (?).
I agree

Approvement process should have:
- initial Issue exposing the idea and the work proposed = requirements (so that we collaboratively shape what will be done, how and by who)
- once this phase is done, a proper concise and precise issue can be raised to Qubes 
- work executed with a number of PR on Qubes-doc community (possible individual working on their own fork)
- PR approved by interested moderator
- once issue is felt resolved, submit PR to Qubes project (if issue was accepted by Qubes)

Some issues may fall outside of official doc (issue or PR get rejected). Moderator modify issue to store the result of the work in a community doc with the disclaimer you mention (for the one where the issue is accepted by Qubes team) we put a work in progress instead. 

At least a link to it, with maybe a disclaimer:

"Take a look what is happening in the Qubes Community.

DISCLAIMER: the content there should be treated as work in progress and has not been reviewed by the Qubes OS Team and maybe thereof less "reasonable secure" or maybe even opening attack vectors to your Qubes installation.
Even more if you implement a script which you haven't reviewed (and understood) and which has not been marked as meeting the Qubes OS quality standards.
WARNING:
If you implement changes in dom0 or the sys-VMs (sys-net, sys-firewall, sys-usb) this might result in a total loss of security"

For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn in line (I.e. sys-firewall). This is a bad practice as the attack surface of one protocol is exposing the entier Qubes system. 
A better way is to have these hosted on app-vm and have sys-firewall intercepting and routing the traffic. 
Even having sys-firewall doing the download rather than a dispvm is increasing the attack surface (not sure if still the case)

This is a good example, is there a disclaimer or security rating on the qubes-doc pages?

No that I am aware of, and this is were I slap myself on the wrist as I should have raised an issue or PR (but this may have wasted time from Qubes team) and this could be one of the issue we work collaboratively in the community repo shape and refine before sending upstream.


[799]

799

unread,
Mar 5, 2018, 4:07:39 PM3/5/18
to Alex Dubois, aw...@danwin1210.me, qubes-users
Hello,

>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>> Can't we just create a new "community" repo where Pull request get
>> reviewed by us but finally approved by more experienced Power Users (this
>> group can include Qubes OS Team, but also experienced community members
>> selected by the Qubes Team/David)?
>
> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote:
> I wouldn't mind helping out on reviews on something like this, as well as
> contributing my own half-baked ideas.

On 5 March 2018 at 08:57, Alex Dubois <bow...@gmail.com> wrote:
True we could have sandbox per person, or each person fork (the fork) and we have a page with list of forks
Once idea is ready, do a PR to the community fork...

This is the spirit of git

can't we just start to fork qubes-doc to qubes-community-doc and start there.
If we think we need to rearrange the content or get rid of it, because it just doesn't make sense, we can still do so.

In the main qubes-doc repository it seems that some skilled users are able to approve Pull Requests, I don't know enough about github how this works?
Are those special permissions for trusted users or can it be anyone?
I would like to see Andrew David Wong or marmarek as power users supporting this - by at least maybe giving feedback. If there are any other skilled persons which are happy to gibr feedback to improve the scripts which are collected there, this is even better - just mentioned those two as they were super helpfull when I wrote my first Qubes Docs
hey, ho - let's go.

[799]
 

Tai...@gmx.com

unread,
Mar 5, 2018, 4:42:20 PM3/5/18
to 799, qubes...@googlegroups.com
On 03/04/2018 04:17 PM, 799 wrote:

> Hello Taiidan,
>
> What does "zero qualification" means and what does "advice" stands for?
If this is going to be a wiki letting anyone edit it irregardless of
skill level will result in poor quality.
> It's not about advicing (advice to me means: I know something better then
> someone else or at least I feel knowledgeable enough to tell other people
> what they should do).
>
> If so, those users should be given constructive feedback and guidance. Keep
> in mind that those "users" are still more likely to listen than the
> "average" user, who has no interest in privacy at all.
>
>
> I don't see how qualification is "certified" by running Coreboot/Libreboot?
It is an easy way to prove that someone has a decent level of linux
experience as the installation of coreboot is considered difficult.
You need a way to separate the wheat from the chaff.
> I am running coreboot does this qualifies me?
If you compiled installed it yourself then yes - it proves you have a
decent skill level.
> Keep also in mind that there
> might be users who need to run recent hardware or hardware that are not on
> the Coreboot Hardware Compatibility List (HCL).
By your standards why not let windows users comment too? after all not
everyone has hardware that supports qubes right?

If your goal is to have a wiki that contains safe high quality advice
you aren't going to be able to accomplish your mission if you let anyone
edit it regardless of skill level.

If someone can't afford a $100 laptop they probably have nothing worth
stealing (personal data or otherwise) and thus have no reason to use
qubes or even have a computer at all.
> Writing from my Googlemail address which is only there for Qubes+Coreboot
> Mailinglist because Protonmail doesn't offer IMAP:
There are way more than just two email providers even if you don't wish
to pay a very reasonable $5/mo for paid email there are free providers
that don't abuse you to the level that google does.
> Not using Google doesn't make someone superior
No it really does, not using google means you have skills and have put
in the research and effort to find a superior provider - ie: you care
about your security.
> and even if you are right
> that there are reasons not (!) to use Google for personal E-Mails:
There are many including AI research, datamining, no real security and
the lack of customer service.

Not to mention google recently choosing politics over profit which is
not what a publicly held for-profit company should be doing.
> If you don't allow them to comment,there is no possibility for a discussion
> and convincing them to try something different.
I am not referring to a discussion forum I am referring to a wiki where
letting anyone edit it is dangerous, the good advice of skilled user is
easily edited and ruined by a microsoft fanboy who thinks that owner
controlled hardware is too dangerous for just anyone to own (remember
that hardware enforced code signing is a very recent development, owner
controlled was the superior norm for the first half century of
computing) and that everyone should use "secure" boot for "security".
> And if so, then Qubes should not run this Google group/Mailinglist ;-)
I have complained about this - I really don't like giving google carte
blanche to use my data to for instance eventually put me out of work via
their AI research.

awokd

unread,
Mar 5, 2018, 4:42:54 PM3/5/18
to 799, Alex Dubois, aw...@danwin1210.me, qubes-users
On Mon, March 5, 2018 9:07 pm, 799 wrote:
> Hello,
>
>
>>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>>>
>>>> Can't we just create a new "community" repo where Pull request get
>>>> reviewed by us but finally approved by more experienced Power Users
>> (this
>>
>>>> group can include Qubes OS Team, but also experienced community
>>>> members selected by the Qubes Team/David)?
>>>
>>> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote:
>>> I wouldn't mind helping out on reviews on something like this, as well
>>> as contributing my own half-baked ideas.
>>
>> On 5 March 2018 at 08:57, Alex Dubois <bow...@gmail.com> wrote:
>> True we could have sandbox per person, or each person fork (the fork)
>> and we have a page with list of forks Once idea is ready, do a PR to the
>> community fork...
>>
>> This is the spirit of git
>>
>>
>
> can't we just start to fork qubes-doc to qubes-community-doc and start
> there. If we think we need to rearrange the content or get rid of it,
> because it just doesn't make sense, we can still do so.

I was picturing an empty repo with relaxed editing requirements (can
Github do this?) for new content only. Think forking existing might be
confusing short and long term. :)

> In the main qubes-doc repository it seems that some skilled users are
> able to approve Pull Requests, I don't know enough about github how this
> works? Are those special permissions for trusted users or can it be
> anyone?

In the official repo, I believe only Andrew and marmarek (and probably
other Qubes members) can merge. This responsibility should stay with
official Qubes reps. due to the sensitivity. However, there are some
(Whonix, template maintainers) who might also authoritatively review
related commits.

> I would like to see Andrew David Wong or marmarek as power users
> supporting this - by at least maybe giving feedback.

adw's stated elsewhere they are happy with a community run site but
wouldn't have the resources to support it.

Alex Dubois

unread,
Mar 5, 2018, 5:28:18 PM3/5/18
to 799, aw...@danwin1210.me, qubes-users


Sent from my mobile phone.
Give David a bit of time. His schedule might be busy, he may need to sync with a number of other persons, they may discuss what’s best. There is no rush. He is doing a great work as community manager. 

In the mean time, I certainly don’t want to break your enthusiasm, anybody who wants can fork the Qubes-doc to work on his bits and once things are decided either raise issues and PR either to main Qubes OS or the community one.

We can discuss here ideas and agree on the way to proceed.

At the moment I am trying to help on the QWT as I think it essential for Qubes, most users have a leg in the windows world professionally.
After that, I would like to finish my Qubes-yubikey app
And finally do a proposal for a daemon-service (service+AppVM+firewall rules), as I feel a lot of users are compromising their system by doing the wrong thing (already mentioned I think)
Or work on Qubes-manager replacement but I have never done Linux client dev...

Maybe others can also share their plans...


[799]
 

Alex Dubois

unread,
Mar 5, 2018, 5:31:13 PM3/5/18
to aw...@danwin1210.me, 799, qubes-users


Sent from my mobile phone.

> On 5 Mar 2018, at 21:42, awokd <aw...@danwin1210.me> wrote:
>
>> On Mon, March 5, 2018 9:07 pm, 799 wrote:
>> Hello,
>>
>>
>>>>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>>>>>
>>>>> Can't we just create a new "community" repo where Pull request get
>>>>> reviewed by us but finally approved by more experienced Power Users
>>> (this
>>>
>>>>> group can include Qubes OS Team, but also experienced community
>>>>> members selected by the Qubes Team/David)?
>>>>
>>>> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote:
>>>> I wouldn't mind helping out on reviews on something like this, as well
>>>> as contributing my own half-baked ideas.
>>>
>>> On 5 March 2018 at 08:57, Alex Dubois <bow...@gmail.com> wrote:
>>> True we could have sandbox per person, or each person fork (the fork)
>>> and we have a page with list of forks Once idea is ready, do a PR to the
>>> community fork...
>>>
>>> This is the spirit of git
>>>
>>>
>>
>> can't we just start to fork qubes-doc to qubes-community-doc and start
>> there. If we think we need to rearrange the content or get rid of it,
>> because it just doesn't make sense, we can still do so.
>
> I was picturing an empty repo with relaxed editing requirements (can
> Github do this?) for new content only. Think forking existing might be
> confusing short and long term. :)

I provided my input earlier on this in case you missed it. What others think?

Andrew David Wong

unread,
Mar 5, 2018, 8:28:25 PM3/5/18
to Alex Dubois, 799, aw...@danwin1210.me, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks. :}

Currently, qubes-doc PRs have to be approved by a member of the Qubes
team before being merged into the master branch, which is the live
version. (Usually, I'm the one who does the merge. In those cases, if
you don't see explicit approval from another member of the team, it
just means that I'm the one who has reviewed and approved the PR.)
This system is great for maintaining high standards of security (as a
first priority) and quality (as a second priority) for the docs.
However, it's very time-consuming, since (at least) one of us has to
review every single PR that gets merged (as well as many of those that
ultimately get rejected, which are a small minority).

Currently, we barely have enough time to keep up with the stream of
PRs that get submitted to qubes-doc, so it's very unlikely that we'd
also have time to review or provide substantive feedback on PRs for a
second, community-run version of qubes-doc that receives even more PRs
(if I'm understanding the proposal correctly).

However, I do like the sound of a fully-community-run version that
serves to collaboratively improve content before it is submitted to
qubes-doc. Currently, most contributors just submit their work
directly to qubes-doc, and the quality tends to vary. Perhaps the
community-run version could be an optional (but recommended,
especially for first-time contributors) place where work is polished
up with feedback from the community before it's submitted as a PR to
qubes-doc to be reviewed by the team. This could make things easier
for contributors, improve the quality of the docs, and save the team's
time.


P.S. - You can call me "Andrew." "David" is my middle name. :)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd7psACgkQ203TvDlQ
MDDzqRAAlppp00e/YixAnaLJgyNEYbZgxA9ZlVABBxUJwUX7Ede0MAHeiLHLiR0E
PqdvVBSBi1rt0XYROka44IJ8amj1pM3tc5UroE4rhG8yxY7TPnul0tAHeTH5rTk2
rCPOsHLSuv/nwqdzhvcCK2cC9SKYgJF7IGdgtRnaMg56JEYkn7HISKFxMfL6m8L9
quU4dRdBJnWEk16lYHxQBd3JtVeBtHjCppHh9CFn5XYdbPvbPd8qYwOVMdSOaG0k
0adeue8gI8G6Mkf3pzJt7Etjr8xjlHB4JKaMy7VCN7PekdkrITbQCwPH24PLQHP9
+pFQu2ShBZgOFyNQ+itDPW70r/1Jfc0mpRu16Dz85/VTew/ROrdOlizLqHtbS6L4
i0ZG6vbFAw0H4/kPzOWz3xxRukbXtOWBL6kx1a8Sj+JZSs5B5mbSGkg5S4vOEXrg
p+PBzt5jfuwg9ZrJCqBOWy56JfPqpmb37ooqC94oTYeXX2utRFQg8QyA/NRMgduM
pkRNOVOpO81OIiUYvzM9eY2zYhWa3LUY4x0OdkiO9hcZ7tVQ17iurgBE8KFy6drj
dKd4nLPiXUMF6mGXt+6fksaKhhSAxyMcWSUb094PXhZjcqiMKEaP+7hd0tZeNSE8
R/zFQJyd6VPaervecyKvcMw9mXt2Mal/OBRlyMHbJcyNqLpucLs=
=WFKk
-----END PGP SIGNATURE-----


Ivan Mitev

unread,
Mar 6, 2018, 3:14:45 AM3/6/18
to qubes...@googlegroups.com
Hey Alex,
Can you point to your post ? sorry if it's obvious but the thread is
quite long, with branches and lengthy posts.

FWIW I definitely agree with awokd that an empty state is the way to go.
Nothing prevents someone from pulling a doc from the qubes-doc repo and
modify it; if the changes are OK the doc could be pushed back to qubes-repo.

But I'm not sold on this git/github idea, sandboxes, forks, PRs, and
whatnot. Everyone here assumes that git is easy to use but that's
because people posting to MLs are techy by nature and probably had to
learn git at some point for their projects. Replies like 'git is easy'
are like 'riding a bike is easy' - people don't remember that they fell
when learning how to ride one.
What I mean is that using git or a git-centric platform restricts
contributions to people who know git or are willing to learn it only to
send PRs (like I did for instance). Those people are only a subset of
Qubes users: you leave aside those who may have valuable feedback -
journalists, activists, ... - but don't want, or don't have the time, to
learn how to use a new tool.

IMHO before choosing a technical platform based on assumptions, the
goal(s) and target(s) of this new community place should be made clear
first. I don't think I've seen such a post but I may be wrong.

I realize this post may sound negative - it's not at all; it's nice to
see enthusiastic people trying to improve Qubes. I'm of course not the
center of the world and I'll be happy to contribute on whatever platform
is eventually chosen.

Ivan

Alex Dubois

unread,
Mar 6, 2018, 6:37:39 AM3/6/18
to Andrew David Wong, 799, aw...@danwin1210.me, qubes-users


Sent from my mobile phone.

Oups apologies for some reason David did stick in my mind.

OK let’s starts.

2 options,

-1-
It is a new repo in QubesOS project and:
- github allows the QubesOS team to manage with sufficient level of granularity the access so community team does not have access to main part (but this is error prone from an admin point of view as well as github vuln)
- Qubes team has the resources to manage the access rights (I suspect add a number of users (awokd, 799, ivan myself, etc...) as PR approvers for the community doc

Benefits:
- it is part of the Qubes project
- it might be easier to generate a web-site or not (do we want that, I think we don’t)?

-2-
A new project is create (by Andrew?) called Qubes-community

I think 2 is better
- as we may have as repo a fork of Qubes-doc, but we could have Qubes-community templates, scripts, ...
- as it protects Qubes’s main project and operations

799

unread,
Mar 6, 2018, 7:21:00 PM3/6/18
to qubes-users
CC'd to list, as I am still learning neomutt and hitting reply ("r") only send the mail back to the main address.

---------- Forwarded message ----------
From: [799] <one7...@gmail.com>
Date: 7 March 2018 at 01:15
Subject: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
To: Alex Dubois <bow...@gmail.com>


Hello,

On 03/06 11:37, Alex Dubois wrote:

> [...]

> A new project is create (by Andrew?) called Qubes-community
> I think 2 is better
> - as we may have as repo a fork of Qubes-doc, but we could have Qubes-community templates, scripts, ...
> - as it protects Qubes’s main project and operations
> [...]

I agree, but would call it the "qubes-community-doc" and I also like the idea which was also mentioned by someone else, that we start with a simple empty repository.
Thereof the risk is lower that someone doesn't know where to publish changes.
the qubes-doc should be seen as the production area documentation while qubes-community-doc is something like a preproduction/staging area.

@Andrew/Qubes-Team:
Can you setup the repository from your account?
As mentioned I think it makes sense if you "own" the main repository.

[799]

--
Lenovo W540: Qubes OS 4rc4 + Windows 10 Ent - Dual"booooh"t
Lenovo X230: Qubes OS 4rc4 with Coreboot

Yuraeitha

unread,
Mar 7, 2018, 3:37:00 AM3/7/18
to qubes-users
To extend on [799]'s idea of a new Community doc page, and combine the idea to make a stepping stone development progress system, and combine it with the issue with the lack of time for the Qubes staff, perhaps we could make a third repository, for testing and reviewing, before sending it to a more official Community doc page, which then could later forward high quality content to the Official Qubes doc page?

This suggestion is only to get it started, we can always look to expand this later on with other platforms, be it forums or something else. In a nutshell, starting out small, and then scale it all up later on as the small gains success, and from there pick a direction (for example preferred platforms, community style and layouts, goals and directions, targets, etc.).

So to start small, with minimum time taken from the Qubes staff as far possible, something like this?

- Hidden Qubes trial grounds - Hidden away from normal users, so that only volunteer testers and reviewers can easily find it. Have a minimum time or a minimum amount of people read and review it, before the person who will be in charge to publish it to the Official Qubes Community doc page, where another volunteer can be in charge of quality checks.

- Official Qubes Community doc's - less quality, but still good/decent. Security and system reliability must always be top priority though. Then the volunteers here, if they find some guides/doc's to be outstanding or really good, could then forward this guide to Qubes Official doc page.

- Official Qubes doc's - keep working like normal. Only high quality docs/guides are accepted. Less clutter is received by having two system checks before arriving to the Qubes doc page, saving Qubes staff time.

By doing something like this, we're still staying neutral to big decisions, but we can start doing the community guides quality checks, and then reduce the amount of work arriving to the Qubes staff. This could then later on evolve further into many different things, keeping all those decisions for later in time.

What I also think is good about this, is that we start out small, nothing too complex, and then only proceed and build on-top of it once this small step is successful. The goal is to merge the community doc page idea with saving Qubes staff time and to increase the quality of the final Qubes doc page further.

This shouldn't take much time to setup either? We could clone the current Qubes doc page system and do it like that for the other two systems? So the trial grounds is like a gateway collecting work from the many different GitHub pages, and the community page then retains all the guides and docs which are not wrong, but also not high in quality, but also forwards the high quality to the Qubes doc page, acting as a system check to the final high quality Qubes doc content.

This also allows volunteers to step in and take a second or third look at the Community doc's to see if they can help increase the quality of it.

Yuraeitha

unread,
Mar 7, 2018, 3:50:13 AM3/7/18
to qubes-users
I want to underline that this suggestion is to start out as small as possible, while still starting out the primary idea of community work by the community.

Since this can take any shape later on, it will not negate any of the ideas in this thread, it'll only serve as a small starting point, or a testing grounds before expanding it, while at the same time starting to save Qubes staff's time on the Qubes doc page.

Yuraeitha

unread,
Mar 7, 2018, 4:00:13 AM3/7/18
to qubes-users
Qubes staff could also take the Qubes doc commits that came to them directly, and instead forward them backwards to the Qubes Community doc or trial grounds, if it does not have enough quality or needs improvements, or in case it is a busy time period and it can't be reviewed.

Furthermore in busy times, the bridge to carry over docs from Community doc's to Qubes doc's can be minimized to slow down the commits, as a dynamic to help the Qubes staff to better manage their own time.

awokd

unread,
Mar 7, 2018, 4:45:42 AM3/7/18
to Yuraeitha, qubes-users
Two repos mean twice the administration; not sure that's the best approach
to start out with. I poked around Github settings a bit. The permission
controls are very limited (maybe granular settings are available in the
paid version), but the following might fit most of your model:

- one Github site
- only a single owner permitted
- Wiki with editing permitted to any logged in Github user (your
scratch/development area)
- collaborators by individual Github name appear to have push/write access
to full repo
- Code section could contain the more formal contents, would have to be a
collaborator to contribute directly or approve submissions
- unclear on how documents would migrate from here to qubes-doc unless as
a copy/paste, but that would lose attribution and I imagine most would
like their own name on their commit!

Can any Github pros confirm/deny/provide additional detail?

Yuraeitha

unread,
Mar 7, 2018, 6:06:46 AM3/7/18
to qubes-users
@awokd

I see, that is a very good point, I agree fully with you.

So if I understood what you meant correctly (github terminology is tricky here), so a sense, we could have a single github (the official Qubes one) and a single repository as well, but within it have 3 different folders for 2 different pages, and another one which won't appear on any page but stays unofficial on github. This is what you meant?

I don't think it's an issue to have two pages appear on the Qubes website (Qubes doc's and Community doc's), sourced from 2 different github folders, that's how you see it too I suspect? So it's a question if different people can have different permissions on a pr. folder basis, which automatically? changes what appears on the websites doc page. So I end up with such questions as well, is permissions here doable on a pr. folder basis? Does Github allow such micro-managment? But I suspect Andrew might know the answer here.

It might be possible to move the whole guide file(s) as well with minimum work. have you tried fork your GitHub to your local harddrive awokd? It looks a lot like a simple folder/file structure, where moving files should be all it takes? As long as internal depending links and addresses are corrected, but if keeping the structure in-tact then I don't think that be an issue. The limited time I used GitHub, I think it's just a matter of moving it from one folder to another folder, in a sense a very basic but flexible system. But I might be too naive here? If true, then I believe it should preserve everything in the doc, formatting, code, size, fonts, everything, even if it's moved from one folder to another folder. But I'm not 100% sure either if that is how GitHub work here.

I did in my previous mail refer volunteers as moderators and not volunteers as community developers, maybe it's better to temporarily call them volunteer moderators to avoid mix-ups when discussing. Separating the volunteer moderators in two tiers as well maybe? The Community driven volunteer moderators must for example have better insight in what makes a guide a good quality, a good understanding of security, etc? While the trial and testing volunteer moderators requires less quality-checks and is more focused on managing the new ideas coming in from different GitHub sources (the communities own GitHub pages), and poking and turning stones to bring forth unseen perspectives.


So something like this?

Categories:
- Volunteer developer
- Volunteer moderator, tier 2
- Volunteer moderator, tier 1
- Qubes Staff, tier 0


Official Qubes OS GitHub maintenance
- Qubes Unofficial trial and testing grounds. (Tier 2 - Volunteer maintained)
- Qubes Community doc's. (Tier 1 - Volunteer maintained)
- Qubes Official doc's. (Tier 0 - Qubes staff maintained)


Qubes website appearance
- Qubes Official doc's
- Qubes Community doc's


Let me know if I misunderstood you. I'm still grasping the proper terminology, as well the limits and possibilities of Github, so it might be easy to misunderstand.

awokd

unread,
Mar 7, 2018, 6:17:09 AM3/7/18
to Yuraeitha, qubes-users
On Wed, March 7, 2018 11:06 am, Yuraeitha wrote:

> Let me know if I misunderstood you. I'm still grasping the proper
> terminology, as well the limits and possibilities of Github, so it might
> be easy to misunderstand.

Github is easy for me to misunderstand too. :)

You had 2 community repos in addition to the official Qubes repo. I'm
suggesting only 1 community repo with the following settings, and not
touching the official repo at all. I don't know how to address migrating
content, so I'm not sure it's a possibility.

Yuraeitha

unread,
Mar 7, 2018, 6:34:52 AM3/7/18
to qubes-users

We gotta conquer GitHub! :)

So the suggestion is having all the volunteer stuff on a separate repository, but the two sub-set volunteer categories to be separated within that repository? Making it more cut and clean etc.?

I believe it should be easy to move between repositories on a local drive, but I only experimented with this for a short time the other week, so I'm not 100% sure on how it works yet. But essentially we can download all GitHub content to our drives, perform changes, and then commit it back up to GitHub again.

I believe this can be done even to GitHub repositories one has no authority over, but it'll instead be a, pull request? On the other hand, if one has the authority, then it'll immediately change the GitHub content. We can login via the terminal too, and keep our GPG keys on a SplitGPG AppVM.

So by having two different repositories on our local drives, it should be as simple as copy/paste the whole folder/file structure, or individual files/folders, from one repository to another repository?

Maybe this can be done online too on GitHub? But it seems we can do more if it's taken down to the drive, another example is changing the Home wiki page, which is more flexible if done on the local drive. I think maybe moving between the repositories, might be one of those better done on a local machine too?

I'll have to get back to that experimentation sometime soon. Maybe someone else can confirm if that is how it works in-between then though?

Yuraeitha

unread,
Mar 7, 2018, 6:48:00 AM3/7/18
to qubes-users
On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote:

Using this guide as a common ground https://help.github.com/articles/about-pull-requests/

Pull requests could serve as a trial and testing grounds on a volunteer repository? Maybe this is what you meant all along and I misunderstood. But that does indeed make it much more simple.

awokd

unread,
Mar 7, 2018, 7:37:06 AM3/7/18
to Yuraeitha, qubes-users
Yes, one community repo with both a wiki and code section. Everyone with a
Github account could edit the community wiki to collaborate on documents.
Once it's roughly finished, the doc. owner could submit to the (same)
community code repo with a PR (which would require the repo owner or one
of the Collaborators to approve, IIUC). From there, magic would happen and
it would somehow get submitted to the official qubes-doc repo.



Yuraeitha

unread,
Mar 7, 2018, 9:48:04 AM3/7/18
to qubes-users

It seems like a good way to do it, I like it. What does others think about it? It might be a good idea to have some finished thoughts / discussions ready for Andrew, it'd be inhuman to expect him to read everything (it's a lot to read). Does anyone disagree with the idea of making an initial first step with a second repository with an associated Community doc page, as discussed? We can always look at forums and other platforms later on, it's probably best not to do everything at once, especially now when the Qubes staff is busy, it might be best to start where the least work is needed from the Qubes staff. A second repository and assigning volunteer moderator(s) should be straight forward less than 5 minutes task (This is assuming this is also approved by the Qubes staff of course).

[799]

unread,
Mar 7, 2018, 2:00:15 PM3/7/18
to Yuraeitha, qubes...@googlegroups.com
On 03/07 06:48, Yuraeitha wrote:

> It seems like a good way to do it, I like it. What does others think about it?

agreed.

> Does anyone disagree with the idea of making an initial first step with a second repository with an associated
> Community doc page, as discussed? We can always look at forums and other platforms later on, it's probably best not
> to do everything at once, especially now when the Qubes staff is busy, it might be best to start where the least
> work is needed from the Qubes staff. A second repository and assigning volunteer moderator(s) should be straight
> forward less than 5 minutes task [...]

as you mentioned let's do it this way and if we find out this was a bad idea, we can fix it later on.
the alternative could also be just start a new repository on our own accounts.
Honestly I think that only a few users will contribute, but that's fine.

[799]

Andrew David Wong

unread,
Mar 7, 2018, 9:15:13 PM3/7/18
to Yuraeitha, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2018-03-07 08:48, Yuraeitha wrote:
> It might be a good idea to have some finished thoughts /
> discussions ready for Andrew, it'd be inhuman to expect him to read
> everything (it's a lot to read).

Thanks. I appreciate that. :)

> it might be best to start where the least work is needed from the
> Qubes staff.

Yeah. Ideally, we'd like to keep the official qubes-doc PR system the
way it currently is and have the new system be completely autonomous
and community-run without any involvement from the Qubes staff. By way
of analogy, think of the official system as a command-line tool and
the community system as a user-friendly GUI frontend for that tool.
People who either don't know how or don't want to use the command-line
tool (i.e., submit a proper PR to qubes-doc) can instead use the GUI
(i.e., submit content, ideas, and suggestions in any format, which the
community then turns into proper PRs).

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqgnJcACgkQ203TvDlQ
MDA1XBAAs8dC9Ue4kwLToYNRWTIpY+se2pn8RCQ8gqfKNgVDPNO7Qb3z7lw8kERF
KLAktV4HL4NCz8jTJTKh0bMTB2lERytYm6uenx/fYT+fACFRAB7gg7o8D4lE+g7m
zedYznKQHg9x2Ehi+KfVDtbEHdfagDfOW5SSWixDUyK60ZYXHDivAzZkWytMc8b8
yZq3hZZsq8GcXAoMpxWOLl9sx5TiVHN+7WVphPEXYe0wCiCwPlwY3hDznzWAFWq2
2h+aYjnwRKVkvMAbcxrmfSXK0Bwr+Ccr29vBzzQ/eOgWcXwjt6oShkOoFTPLSvla
G3JAzm+15r/7KeKItQuuXVQECGJhCqaZVs6DJFsSLAxTsfg449y3i+EFZC7hkOrM
3glht/vfSOsFY0LChcTc+99sCZnwN/0Q7weXd/86+nn18Qh3Ce7I77nHA1PaXMt7
+/IUM+ZB7RY9dTUsdO3Mw2/GDtOohz8Ofmywuc7yhpzLgn+pPX+WP60jKZzRIkcw
dpvxSzYYGy5Mhc0TyjKTTqRXbZFWCyveOcfLG4r65iEkjN/Fvtr2CGhlcgaDxHN4
J2+h4dM15AH55PqCRvKuNMfeJP+KTgDBI8X3fo/zN0bHo/bmZjr737MZkr/R+mSO
veELCoGf0lA4iskF+dUQEsLw73PLBK0dUI7zU8WWLg4CMzJjjG4=
=IUpz
-----END PGP SIGNATURE-----

Yuraeitha

unread,
Mar 7, 2018, 11:59:06 PM3/7/18
to qubes-users

It would feel bad if causing you trouble rather than helping, I hope we will be able to provide help :) I can only speak for my self, but I believe others feel the same, feel free to correct us if we're doing something wrong with this community project. <-- when I say "us", it is based on my belief, but as said I can't speak for everyone. I mean, it would be horrible if we impacted Qubes in a way that you guys didn't like, after all the amazing work you guys did with Qubes over all these years, you guys essentially poured your souls into this. Consider to bring out that whip if something is off!

If I interpreted this correctly, my understanding is that it's preferred that a community like this to have an inviting GUI platform, so that it can easier gain traction and build up users, and include more people? i.e. github is not desired for the central community environment?

Maybe we could beta-run a volunteer run GUI based platform first before you decide if it should be made official on i.e. recognized on the Qubes website with a link? testing the waters a bit by dipping the toe in, before taking a full dive. With only some platform volunteers aware of it at first to test it? If it works, then we can always scale it up, or if it should fail, then change direction or start-over with a new discussion. Something like that, a beta run could be insightful before any final decisions are made.

I hesitate to use the forum word here, perhaps a new fresh discussion is warranted as for which platform to use? But if GUI is an important factor to include, then a forum might be the most suitable? There will always be some who don't like every platform though. But did I understand it correctly that the Qubes staff actually likes the idea of a forum, but just doesn't have the man-power to run it? i.e. if you had the volunteers, then this is a desired platform/direction seen by the Qubes staff to go? Maybe preserving the mailing-lists, but integrating a forum where a forum makes sense, and then keep the mailing-lists as they are now and have them coexist?

Ivan Mitev

unread,
Mar 8, 2018, 1:43:48 AM3/8/18
to qubes...@googlegroups.com


On 03/08/2018 06:59 AM, Yuraeitha wrote:
> On Thursday, March 8, 2018 at 3:15:13 AM UTC+1, Andrew David Wong wrote:
> On 2018-03-07 08:48, Yuraeitha wrote:
>>>> It might be a good idea to have some finished thoughts /
>>>> discussions ready for Andrew, it'd be inhuman to expect him to read
>>>> everything (it's a lot to read).
>
> Thanks. I appreciate that. :)
>
>>>> it might be best to start where the least work is needed from the
>>>> Qubes staff.
>
> Yeah. Ideally, we'd like to keep the official qubes-doc PR system the
> way it currently is and have the new system be completely autonomous
> and community-run without any involvement from the Qubes staff. By way
> of analogy, think of the official system as a command-line tool and
> the community system as a user-friendly GUI frontend for that tool.
> People who either don't know how or don't want to use the command-line
> tool (i.e., submit a proper PR to qubes-doc) can instead use the GUI
> (i.e., submit content, ideas, and suggestions in any format, which the
> community then turns into proper PRs).
>
>
> It would feel bad if causing you trouble rather than helping, I hope we will be able to provide help :) I can only speak for my self, but I believe others feel the same, feel free to correct us if we're doing something wrong with this community project. <-- when I say "us", it is based on my belief, but as said I can't speak for everyone. I mean, it would be horrible if we impacted Qubes in a way that you guys didn't like, after all the amazing work you guys did with Qubes over all these years, you guys essentially poured your souls into this. Consider to bring out that whip if something is off!
>
> If I interpreted this correctly, my understanding is that it's preferred that a community like this to have an inviting GUI platform, so that it can easier gain traction and build up users, and include more people? i.e. github is not desired for the central community environment?

The GUI / command line distinction was an analogy. Here's another: we're
given a powerful car but its user manual is targeting experienced
drivers. The community here could help with:
* lowering the difficulty for casual drivers to send improvements to the
official user guide
* centralizing "tuning" tips unsupported by the car's manufacturer
because the car could become dangerous to drive if you don't know what
you are doing.

Let's go ahead with awokd's suggestion of a wiki + repo.

Andrew: what's your position about mentioning this community effort
somewhere in the official qubes site ? (maybe as a news post with the
proper disclaimer + modifying the "contribute to the docs" page) ?
Without visibility only a few people would know about this community
effort and the project will quickly stall.
signature.asc

799

unread,
Mar 8, 2018, 1:47:19 AM3/8/18
to Yuraeitha, qubes...@googlegroups.com
Hello Yuraeutha,

On 03/07 08:59, Yuraeitha wrote:

> [...]

> If I interpreted this correctly, my understanding is that it's preferred that a community like this to have an inviting
> GUI platform, so that it can easier gain traction and build up users, and include more people? i.e. github is not desired
> for the central community environment?
>
> Maybe we could beta-run a volunteer run GUI based platform first before you decide if it should be made official on i.e.
> recognized on the Qubes website with a link? testing the waters a bit by dipping the toe in, before taking a full dive.
> [...]

I won't agree, as content is the most important thing.
Content first -> presentation later.

Let's just start with using GitHub and evolve from there.
What do you think?

[799]

Yuraeitha

unread,
Mar 8, 2018, 3:14:54 AM3/8/18
to qubes-users

@[799] & Ivan
The good thing is as Ivan pointed out too, that it seems I misunderstood the analogy :) I like the github platform version as well for this community goal, though both platforms have their pros and cons of course.

Maybe we could start linking to each others github pages to get an initial network up? It's a lot of work to maintain in the long run though, but it could help us be aware of one another that way in the beginning? Before we later maybe get a page or something somewhere showing all the different channels with a brief introduction each? Maybe we can draft a single wiki page somewhere to make it more efficient? or wait, maybe we can even fork this with github? A master branch where multiple of long-term community users with master access can help moderate the github wiki list? Should be possible this way?

Alex Dubois

unread,
Mar 8, 2018, 8:16:26 AM3/8/18
to [799], qubes...@googlegroups.com


Sent from my mobile phone.

> On 8 Mar 2018, at 07:57, Alex Dubois <bow...@gmail.com> wrote:
>
>
>
> Sent from my mobile phone.
>
>> On 7 Mar 2018, at 18:48, [799] <one7...@gmail.com> wrote:
>>
>> Hello Alex,
>>
>>> On 03/07 07:57, Alex Dubois wrote:
>>>
>>> From my part if I want let say to add a script to clean-up the logs in Dom0...
>>> 1- I will agree with the others where in the official doc we think it should go (in an issue) and possibly how to do it, w$
>>> 2- Once consensus I raise the issue in Qubes official so they can provide feedback
>>> 3- In parallel I work on the issue in community repo by either using GitHub web UI to edit the script and raise a PR, or b$
>>> 4- PR is reviewed by community
>>> 5- PR approuve and change merged (maybe a header is added saying under review for integration in Qubes doc)
>>> 6- submit PR in main Qubes-doc
>>> 7- if PR rejected, I will update the community page with a header included saying this is a community only page.
>>>
>>>> Thereof the risk is lower that someone doesn't know where to publish changes.
>>>> the qubes-doc should be seen as the production area documentation while qubes-community-doc is something like a preprodu$
>>
>> as far as I have understand the benefit would be, that the discussion always starts (!) in the production qubes-doc.
>> Then the actual coding/discussion/happening in the Qubes-Community doc.
>> If "mature" a Pull Request is raised to upload the doc to qubes-doc, correct?
>>
>> Wouldn't it be good to remove the content from the community-doc then, so that it really only serves as a staging repositorr$
>
> True but if the content is not accepted in Qubes... you may still want to have it in Qubes Community.
>
> An example is a page on setting up a vnc connection for remote admin to dom0... some user would want that, also you break a big part of the Qubes security. Qubes will not accept such a doc (I hope). It would reside in the Qubes-community doc in a section “at your own risk”, with a warning on the security risk and maybe a link to the PR discussion with Qubes as to why it was rejected.
> Now Qubes 4.4 for example comes along and they have a way to provide such service, we would be able to PR in Qubes after modifications.
>
> But I also see you point with a blank repo, it is clear and less prone to mistakes.
>
> Not sure but personally I prefer to just work on the fork. It will be more often useful and less copy pasting when submitting PR from one repo to the other (ie multiple pages updates in one PR)
>
> For new docs, it has the advantage to also implicitly help selecting the right place to host the info.
>
> The empty one will either be a mess or will have to be organised as well (with the additional burden that it also has to be aware of Qubes-doc)
>
> You can fork Qubes-community/Qubes-doc and do whatever you want (and others can access it (and know you forked) also not the reason so you could have a link to your fork in a in-progress section of Qubes community)
>
> I am naturally fairly organised and have experience of very large projects where I left sometimes too much flexibility and ended up with a mess 3 years later. So this is why I’m not keen on blank areas. But this is a community project, so I am also very interested in the human interaction factor and respectful of others opinions.
>
> If I have not convinced you and awokd, I don’t see a big problem in having both.
>>
>> [799]
>>

awokd

unread,
Mar 8, 2018, 8:50:27 AM3/8/18
to Alex Dubois, [799], qubes...@googlegroups.com
On Thu, March 8, 2018 1:16 pm, Alex Dubois wrote:

I think the indentation got broken, this is you, right?
Yes, that's part of that "magic" step I wasn't sure how to address. I'll
defer to your experience on it. My hope is the wiki will make it easy for
people to contribute too without worrying about PRs and all that, but I'm
not sure how much admin overhead's going to be involved.

Alex Dubois

unread,
Mar 8, 2018, 2:52:41 PM3/8/18
to aw...@danwin1210.me, [799], qubes...@googlegroups.com


Sent from my mobile phone.

> On 8 Mar 2018, at 13:50, awokd <aw...@danwin1210.me> wrote:
>
> On Thu, March 8, 2018 1:16 pm, Alex Dubois wrote:
>
> I think the indentation got broken, this is you, right?

Ouch yes might have been I had a problem with my mail client.
I don’t have much experience with GitHub, a bit more with git.

True the wiki may address it.

The best is probably to test it.

I am snowed under at work at the moment. So maybe test between you on one of your existing projects and then we can discuss.


Yuraeitha

unread,
Mar 8, 2018, 3:19:16 PM3/8/18
to qubes-users
Perhaps we should form a list in this thread to get started of who is who on github, for those interested in this project. It'd probably be fine to start working together too without further confirmation from the Qubes staff. What we do need confirmation about is how this will officially relate to Qubes OS on the contents that is finished in the Qubes Community doc page though though. Hopefully Andrew can shine some light on that. But before that, I'm sure it'd be fine to start organizing and work together, as long as we don't publish anything officially.

Thoughts about collecting an initial unofficial github list, get an overview, and start looking at the projects out there, to get started?

Tbh we're at a stage where we have to hunt down and copy/paste everyones github page to a private list at this point in order to keep track. It'd be better if everyone wanting to do this can write their github page, i.e. in this thread with words that they're into this idea, in a sense signing up for this community co-awareness with a github link posted here, so that those not interested don't automatically get included.

Andrew David Wong

unread,
Mar 8, 2018, 8:40:13 PM3/8/18
to Ivan Mitev, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2018-03-08 00:43, Ivan Mitev wrote:
> Andrew: what's your position about mentioning this community effort
> somewhere in the official qubes site ? (maybe as a news post with
> the proper disclaimer + modifying the "contribute to the docs"
> page) ? Without visibility only a few people would know about this
> community effort and the project will quickly stall.
>

I'll have to discuss it with the rest of the team, but I expect that
we would link to it from the Qubes website with a description making
clear that it's community-run (hence unofficial) and optional but
recommended for first-time contributors and anyone who has trouble or
lacks confidence about submitting directly to the docs (probably with
announcement on the MLs from you all). As long as the community-run
system continues to reflect well on the official project (its members
follow the Code of Conduct [1], the website doesn't serve malware,
etc.), then it shouldn't be a problem.

[1] https://www.qubes-os.org/code-of-conduct/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqh5fIACgkQ203TvDlQ
MDCezRAApDPpwvvTWMFe04QCsBItc8z2zVwTKlxcc918m9v5FUmXEBWoJdlhTiZ1
y4KvoRj9n1VIQ+UnA9W3ZTYLd3A+faSZyeowKAAUJYJJRAh6pLjCamfbHaWXCQVo
n2cOpZoZsGWtDz03vAE3mZ4kXhJJfIeGmD/FtEItBjD17O/eSNOm2XWsrTLRPZxQ
ZsCE0ZGLKYD4t3pok7OZiQtGduDpEZgrETRtba0HKtlH1pSQeIXoEDl6Uay/xr++
igjWGpoHmSaC6JglUH4AB5TLs9tH3OvDWFJ1/HK5+Zf86DRaqjKSZczCfA7SBAim
VedqUklX2tJw/LvicR2bjbH6T3NTcaGVdOYdRVR+Q4ICZUjEIvTuD/fYPY/e8wXS
nSEgZPATXp90/hhA5M9nY0Pllxlgk0eJ6jGaOv0uV4aO9AiskFk0h7OWIMlmhLwP
sG3u7v1Shewp0bH5bP1OGZck1lNps6KiOaYVIxrvRm+/uJP6HAaAPTJ3c7QnYxJN
/oX0s7N/ZdTZMvfbs8cCSoOELCsbTToKiYqHuecEYD1SLefuWy4zptCW0PqQY08O
yizpe3SDT7A/OIiTTov2wm13Y0YzT7OuKtE/t/IFlWMYelJcu/nuEaclYd59Lyqt
geZBC/J6zUuosNb8Fsw6xbYIOeQ5QS+8aNS+W5K8GDiKjsLC3jU=
=HTsZ
-----END PGP SIGNATURE-----

Andrew David Wong

unread,
Mar 8, 2018, 8:42:38 PM3/8/18
to Yuraeitha, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2018-03-08 14:19, Yuraeitha wrote:
> What we do need confirmation about is how this will officially
> relate to Qubes OS on the contents that is finished in the Qubes
> Community doc page though though. Hopefully Andrew can shine some
> light on that.
>

As explained above, I'm envisioning that the finished output of the
community system will be a high-quality PR submitted to qubes-doc.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqh5n0ACgkQ203TvDlQ
MDC2ZhAAwWD28DOy7Or29AWxfxvWU5LFpVjSpGTcwVxOWCbEXqJ2rI+dOEcb/KXj
Kp+CjIyfpXZGS8Azuv/kCEDYgnLGybkgY04l9N4A5YaDbFpHRZ08SdqtfvOWuesr
nX+n5dr3bW2pVm1NEoFPUKISy9hpwJT1YoIDXyIvHMwM9+EoLyLpwmz9kPrfdMDG
Ejev0zyDkX0S11mPrCi5SdJS+Hs/S2i2UP2obmUHIdAx8rbQsdomT1917pJaBz3d
NOenZCS5gL5120RdhljnzjvaryA7ldkS+ifEz+VAO3+yUvRdudaKu+n1QyAW9bT3
8EH0qb9fZlfOH2Xb1n72FCS+OP14NFpctEnh1s+gcBO4ZwPrkeGxlDQ5JxLVi+W+
qo5zLjiiUa3dFE6QWglO9XeN8zFq9rZso5SE/ziSkIO1xZnobaVwvBTaJeKhD3NH
bxZhfCDp32kirJf092EfWUY68B3AaMIWWkQMtcMsaJ/wlu2RHCQJbRbzyAM0Hanp
aWPH1v2jepUsHCAFRvCyFhlf0HBI33/lcZNK033iC8cHghpBzR1v1uaa+fjs48DW
qcZgdpUIPCR6HczaYqxCgTlVs3TCNfMRcJZwBqJE1EYwri5fqXUGhPqsSfJpw5e/
jm3A1jH1frsTlfPfBf9/RapitPx2YVrLiKDdRo4ZL6xaisrIFIk=
=hs8n
-----END PGP SIGNATURE-----

Yuraeitha

unread,
Mar 9, 2018, 6:29:03 AM3/9/18
to qubes-users

Apologies Andrew, I should have put the question more clearly. What I mean is if we have two pages, one for Qubes doc's, and another for Qubes Community doc's, where will the Community doc's be, in an official sense? I'm fully with you regarding the Qubes doc's, what I'm wondering about is the page listing all the Community doc's which are not ready to be moved to Qubes doc's yet. Should the Community doc page be kept off-site? or is it okay to have it listed (in a similar logical sense to current-testing and unstable repositories, just unstable and current-testing guides instead).

Yuraeitha

unread,
Mar 9, 2018, 7:53:33 AM3/9/18
to qubes-users

Suppose I'll start the first piece of the list to increase the individual github awareness. Where that list is later maintained or kept can be changed as we discuss that later. Please add your github if interested, and copy/paste the list to your own mail response here. Being on this list does nothing except increase awareness of who takes part in the Qubes community guides, there will be no expectations in turn, those who are busy will not become more busy from it unless wishing for it. <--- be warned it might add activity to your github page page though.

It doesn't matter if you prefer to work alone or in collaboration with others. This is also an opportunity to increase awareness of your work. The list strictly only purpose is just that, awareness, while work-style is a separate matter.

Knowing about someone's github account does not justify putting it on the list, please sign up for it so that we don't put anyone on who does not want to be on it. A simple search can show many Qubes OS wiki's, like https://github.com/search?utf8=%E2%9C%93&q=qubes+os&type=Wikis however it's not the same as agreeing to be on an awareness/promotional list.

A small description/introduction can be added to the list later, or now if you like to do that. Please keep it short though if you do, i.e Twitter/SMS post size description, slightly bigger than that should be okay though. The idea here is that introduction/descriptions can be updated later.

Copy/paste the list here (ABC) if possible.
Yuraeitha - https://github.com/Aekez - Right now not much has been done, however QubesTV is starting to take shape. Other repositories are currently work-in-progress.

awokd

unread,
Mar 9, 2018, 8:52:37 AM3/9/18
to Yuraeitha, qubes-users
On Fri, March 9, 2018 12:53 pm, Yuraeitha wrote:
>

> Suppose I'll start the first piece of the list to increase the individual
> github awareness. Where that list is later maintained or kept can be
> changed as we discuss that later. Please add your github if interested,
> and copy/paste the list to your own mail response here. Being on this
> list does nothing except increase awareness of who takes part in the
> Qubes community guides, there will be no expectations in turn, those who
> are busy will not become more busy from it unless wishing for it. <--- be
> warned it might add activity to your github page page though.

This might also be useful for finding potential "collaborators" for the
community site.

Yuraeitha - https://github.com/Aekez - Right now not much has been done,
however QubesTV is starting to take shape. Other repositories are
currently work-in-progress.
awokd - @awokd - mostly forks of qubes repos, no scripts

Ivan Mitev

unread,
Mar 9, 2018, 9:09:31 AM3/9/18
to qubes...@googlegroups.com
* Yuraeitha - https://github.com/Aekez - Right now not much has been done,
however QubesTV is starting to take shape. Other repositories are
currently work-in-progress.
* awokd - @awokd - mostly forks of qubes repos, no scripts
* ivan - @taradiddles - qubes-os repo: app popup (increases
productivity) + improving power management (script + deploying TLP)


Finally, who will create the public wiki + the repo and assign rights ?
You ? awokd ?

awokd

unread,
Mar 9, 2018, 9:38:39 AM3/9/18
to Ivan Mitev, qubes...@googlegroups.com
On Fri, March 9, 2018 2:09 pm, Ivan Mitev wrote:

> Finally, who will create the public wiki + the repo and assign rights ?
> You ? awokd ?

If the only thing involved is maintaining the list of collaborators, it
might be best for one of the Qubes team to do this. That way nobody can go
rogue with the community site. If there is other work involved in being
owner besides maintaining the list, it wouldn't be reasonable to expect
that but I'm not sure how to solve it. I don't have the Github experience
to know either way...


Yuraeitha

unread,
Mar 9, 2018, 9:50:37 AM3/9/18
to qubes-users
awokd posted same time as I was typing, so I'll edit to cover both responses. I agree we should protect this project from going rogue, conflicting interests outside the projects set goals, etc.

Maybe Andrew can take the ownership, assign some of us to have maximum access. Then it's kept protected, without the Qubes Staff having to do anything beyond assigning new head moderators, which probably will be rare anyway. The head moderators can then assign sub-moderators (is that possible on github though?). But at the same time it also means the Qubes staff becomes owners, and it's uncertain if they want that? I agree it would be ideal from our perspective though, but would they want it?

I don't mind putting in the work for this project, I can enjoy it so it won't feel like a burden to me to do it, but it's also fine if others want to do it. We can probably organize it with a few people together as well.

What about creating an Organization group on GitHub? the free version, at least at first. Quote: "Organization accounts allow your team to plan, build, review, and ship software — all while tracking bugs and discussing ideas."

Are there any redundancy in place for such an organization though? For example, can split ownership/leadership be made possible/easy on it? If no none knows then we can just try make one and experiment with it. It's probably best we find a way to secure the community stays healthy.

A GitHub organization also require a name, what should we call it?

Yuraeitha

unread,
Mar 9, 2018, 9:58:31 AM3/9/18
to qubes-users
On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote:

Found this;

Organizations include:
- A free plan with unlimited collaborators on unlimited public repositories
- The option to upgrade to paid plans with unlimited private repositories, sophisticated user authentication and management, 24/5 support, and a service level agreement for uptime availability
- Unlimited membership with a variety of roles that grant different levels of access to the organization and its data
- The ability to give members a range of access permissions to your organization's repositories
- Nested teams that reflect your company or group's structure with cascading access permissions and mentions
- The ability for organization owners to view members' two-factor authentication (2FA) status
- The option to require all organization members to use two-factor authentication

Source: https://help.github.com/articles/differences-between-user-and-organization-accounts/

Ivan Mitev

unread,
Mar 9, 2018, 10:04:00 AM3/9/18
to qubes...@googlegroups.com
I was looking at the same stuff:

https://git-scm.com/book/en/v2/GitHub-Managing-an-organization

If you're OK, create an organization and then if everything works out in
the long run you can give the credentials to Andrew (I'm not sure he
wants to take ownership, at least for now).


Yuraeitha

unread,
Mar 9, 2018, 10:20:08 AM3/9/18
to qubes-users

Works for me, I'll only keep it for the sake of getting the project running, I won't actual own it. I also prefer if a Qubes staff member takes it over, but we'll see what happens.

Name changes seems easy too, at least if not too many project links has been created. https://help.github.com/articles/renaming-an-organization/
So we can take our time to settle on a name.

I'll use something default sounding as the initial name, "Qubes Community Collaboration".

Here's the link
https://github.com/Qubes-Community-Collaboration

I invited you both as owners, so you have administration access as well.

Yuraeitha

unread,
Mar 9, 2018, 10:54:37 AM3/9/18
to qubes-users
The Organization feature of GitHub seems to solve many of our problems, not all, but many of them. It seems pretty great as a foundation. We won't even need to make a github list either now, people can just sign up to the volunteer run GitHub organization, and we can keep a list of all the decentralized Wiki's or private owned projects there, as well as move projects/repositories fully into the organization as well. This adds a lot of great flexibility.

What does everything think about it?

Assuming we go on with this organization layout, we could also need a logo for it, do we have any artists in our midst who want to bring up some logo design suggestions?

Ivan Mitev

unread,
Mar 9, 2018, 11:32:48 AM3/9/18
to qubes...@googlegroups.com


On 03/09/2018 05:54 PM, Yuraeitha wrote:
> The Organization feature of GitHub seems to solve many of our problems, not all, but many of them. It seems pretty great as a foundation. We won't even need to make a github list either now, people can just sign up to the volunteer run GitHub organization, and we can keep a list of all the decentralized Wiki's or private owned projects there, as well as move projects/repositories fully into the organization as well. This adds a lot of great flexibility.
>
> What does everything think about it?

Agreed, it seems quite flexible. At that point it's not clear how this
whole effort will take off, so I'd suggest we keep things simple.

I have a few suggestions for the organization and naming of repositories
but the thread is already very long. Should we continue the discussion
in this thread, in a new ML post, or in an issue in one of the repos in
Qubes-Community-Collaboration ?

awokd

unread,
Mar 9, 2018, 11:36:43 AM3/9/18
to Ivan Mitev, qubes...@googlegroups.com
On Fri, March 9, 2018 4:32 pm, Ivan Mitev wrote:

> in an issue in one of the repos in
> Qubes-Community-Collaboration ?

This.

Yuraeitha

unread,
Mar 9, 2018, 11:42:31 AM3/9/18
to qubes-users
I added a repository for Community Discussions, and pinned it at the top. Something like this is good for everyone?

Yuraeitha

unread,
Mar 9, 2018, 11:52:37 AM3/9/18
to qubes-users

It seems we can make team discussions too for particular projects, this might make it less messy if others are not interested in different sub-discussions. I'll try set a few examples up we can look at.

Ivan Mitev

unread,
Mar 9, 2018, 11:58:33 AM3/9/18
to qubes...@googlegroups.com


On 03/09/2018 06:42 PM, Yuraeitha wrote:
> I added a repository for Community Discussions, and pinned it at the top. Something like this is good for everyone?

https://github.com/Qubes-Community-Collaboration/Community-Discussions/issues/1

:)

Yuraeitha

unread,
Mar 9, 2018, 12:01:55 PM3/9/18
to qubes-users

Awesome, I'll go right there and read/reply :)

I also just made this example, doesn't have to be like this, it's just a layout. https://github.com/orgs/Qubes-Community-Collaboration/teams
It allows for team discussions too, as well as allow community members to find who specialize in what, so that requests can be made. Thoughts?

[799]

unread,
Mar 9, 2018, 1:12:42 PM3/9/18
to qubes-users
Hello,
I went to the page but couldn't see any public members.
How can someone become a member?
I would like to transfer my "Qubes Projects" over to this place.

[799]

Yuraeitha

unread,
Mar 9, 2018, 1:18:36 PM3/9/18
to qubes-users

Apologies, we decided to shorten the name a bit, the collaboration is in the sub-title now instead. It can be found here https://github.com/Qubes-Community
Once the name and base structure is agreed on, then changes like this shouldn't happen again for the sake of connectivity, like just now, when the link stopped working. Can you see it now? :)

799

unread,
Mar 9, 2018, 1:24:43 PM3/9/18
to Yuraeitha, qubes-users
Hello,


Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" <yura...@gmail.com>:
 
Apologies, we decided to shorten the name a bit, the collaboration is in the sub-title now instead. It can be found here https://github.com/Qubes-Community

Ok, I can the site but I don't know where to go from there. Let's say I would like to share my qvm-screenshot-2-clipboard script, where should I put it?

Should I create a fork and then create a new directory put the files in etc?
Maybe the first contribution could be to create a "Hello World" example?

[799]

Yuraeitha

unread,
Mar 9, 2018, 1:42:31 PM3/9/18
to qubes-users
We haven't discussed everything yet, but I believe the idea is to fork if you want to preserve the ownership, and transfer ownership if you want the Community to own your work. This hasn't been discussed yet, but it should probably be considered public domain ownership.

I'm still learning all this my self, there is also the whole licenses and such that I need to read up on to properly know how it works.

The initial idea is to have smaller work in the Qubes-Community repository, and larger projects in a separate repository. There is also a repository strictly for the purposes of forwarding official Qubes docs called Staged-Qubes-docs, it will hold nothing else but 'thought qualified' docs for official publishing, while the Qubes-Community holds everything from doc's, guide's, scripts, wiki's, issue's, etc. All these important repositories are pinned at the top.

If transferring a larger project (a full repository, it either has be forked to preserve ownership, or transfers ownership if that is the intention). One of the moderators has to accept it to make it appear.

If transferring smaller projects, doc's or scripts, etc. then they should be forked or transferred in the Qubes-Community repository.

Many things are still being worked out, but I think this can be considered initial layout.

Also remember I don't decide here, all these are subject to change as we discuss it collaboratively :)

Yuraeitha

unread,
Mar 9, 2018, 1:48:46 PM3/9/18
to qubes-users
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote:
If intention is ownership transfer, then I think it's best to wait until this project becomes fully established, proved working, and archive redundancy, as well as protected from conflicting interests outside the community's goals. This might take a while to archive. Until then it might be better to just fork everything instead, so ownership stays on your own account. Of course if forking is the original intention, then this isn't an issue :)

Yuraeitha

unread,
Mar 9, 2018, 2:34:32 PM3/9/18
to qubes-users
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote:
Found the reason why you couldn't see any people on there.

- The github organization hides all members by default, so if people join, they are hidden members.

- Once a member, you can see the other members as well.

- Everyone can decide for themselves and change between private/public listing of membership in their organization account settings <--- found in peoople tab --> click on your own name --> change it on the left side panel.

- Currently we're 4 members total. I changed mine to public, so there should be minimum one person listing public, if none others have done it at the time of this reading.

- It seems the github code can be changed so that everyone shows as public as default, but it remains a question if that should be done or not.
Reply all
Reply to author
Forward
0 new messages