Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote: > Hello, > > > > Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" : > > > > 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] 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2d18ff7b-c233-42b9-ab08-daa6848df8ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote: > Hello, > > > > Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" : > > > > 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] 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 :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3e5df224-7b3b-4b5e-8b98-a4a91d792b43%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote: > Hello, > > > > Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" : > > > > 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] 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 :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1e85ae0a-0f8b-46c1-aa17-23753e9a508d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Hello, Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" : 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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2sBt3Tg2v55T9fudkO7Z-8s%2BskAmQJn%3DnNY5oA5_3j_GA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 7:12:42 PM UTC+1, [ 799 ] wrote: > Hello, > > On 03/09 09:01, Yuraeitha wrote: > > On Friday, March 9, 2018 at 5:58:33 PM UTC+1, Ivan Mitev wrote: > > > 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 > > > > > > :) > > > > 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? > > 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] 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? :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f09a4ddd-2974-484e-89e6-a8f3011352fd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Hello, On 03/09 09:01, Yuraeitha wrote: > On Friday, March 9, 2018 at 5:58:33 PM UTC+1, Ivan Mitev wrote: > > 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 > > > > :) > > 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? 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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180309181220.rjjf6npd2opd4ehc%40my-privmail. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 5:58:33 PM UTC+1, Ivan Mitev wrote: > 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 > > :) 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f8d96d17-2b44-4288-bdb3-7650b8673154%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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 :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0ff9add8-5f69-944e-dccb-e79210a1e956%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 5:32:48 PM UTC+1, Ivan Mitev wrote: > 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 ? > > > > > > 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? 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0d860618-483f-4a58-90ec-7f98f608f557%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
I added a repository for Community Discussions, and pinned it at the top. Something like this is good for everyone? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c62616b0-00a7-482d-9ab8-25c92a4749c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Fri, March 9, 2018 4:32 pm, Ivan Mitev wrote: > in an issue in one of the repos in > Qubes-Community-Collaboration ? This. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2606feb06921da639e5f172ffb684703.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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 ? > > 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/028ce8d9-c774-8849-16de-3e181d2dee75%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/556a4faa-7d6b-4284-939b-9e91a2d56ca9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 4:04:00 PM UTC+1, Ivan Mitev wrote: > On 03/09/2018 04:58 PM, Yuraeitha wrote: > > On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote: > >> On 03/09/2018 02: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. > >>> > >>> 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. > >> > >> * 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 ? > > > > 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/ > > 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). 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/02d27b54-e7b2-4544-827c-91cdf149bce8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On 03/09/2018 04:58 PM, Yuraeitha wrote: > On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote: >> On 03/09/2018 02: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. >>> >>> 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. >> >> * 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 ? > > 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/ 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). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/590207f4-e3fc-b65a-d537-95a7f00e6d2c%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote: > On 03/09/2018 02: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. > > > > 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. > > * 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 ? 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/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5c76e73f-701f-45d9-9288-6982fa30c8fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote: > On 03/09/2018 02: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. > > > > 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. > > * 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 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e94ae542-72e4-4186-9804-0dfe4040738d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/535bd800fe0a22ebd03a4ab36502f9b0.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On 03/09/2018 02: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. > > 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. * 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 ? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f93c846b-8c47-c6fe-fc54-47d1dc9cb116%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f2c04219cb1b12255020ccfd43dae94c.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3e86debd-42ec-4d01-b417-53f12dc4577e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
-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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/25a0c602-c678-b6e4-0fd5-ca6898c40bf0%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 8 Mar 2018, at 13:50, awokd 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. > >>> 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. > > 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. > 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2D1D604A-E974-455D-9B42-ADEC79AB9A90%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Thu, March 8, 2018 1:16 pm, Alex Dubois wrote: I think the indentation got broken, this is you, right? >> 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. 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/593bea1eff28bf50d15d1d4eb2108ebf.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 8 Mar 2018, at 07:57, Alex Dubois wrote: > > > > Sent from my mobile phone. > >> On 7 Mar 2018, at 18:48, [799] 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 thebenefitwould be, that the discussion >> always starts (!)in the production qubes-doc. >> Then the actualcoding/discussion/happening in the Qubes-Community doc. >> >> If "mature" a Pull Request is raised toupload 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] >> -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/178C3F4D-61B1-4642-B5AA-CD44D25891E7%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Thursday, March 8, 2018 at 7:47:19 AM UTC+1, [ 799 ] wrote: > 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] @[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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fbc1746a-0bd3-48db-a2c2-f408c60a9424%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2uEWmnEAhKuezusMgUwQuGxNVbSPs7_Ks-o%3DRZQn%2BDOxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. > 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ac67bc57-7d45-d470-647a-3e7e6c3a1265%40maa.bz. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Thursday, March 8, 2018 at 3:15:13 AM UTC+1, Andrew David Wong wrote: > -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- 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/42238610-a1e0-4533-b627-25e2587a49d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
-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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1b62e64c-6855-7f56-6435-8f643318b4fb%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180307185609.h2s4abfp3a3fp4gk%40my-privmail. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Wednesday, March 7, 2018 at 1:37:06 PM UTC+1, awokd wrote: > On Wed, March 7, 2018 11:48 am, Yuraeitha wrote: > > On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote: > > > >> 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. > >> > - 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! > > > > > 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. > > 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. 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). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cbd1f82c-c611-45a1-836f-03259b3370ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Wed, March 7, 2018 11:48 am, Yuraeitha wrote: > On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote: > >> 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. >> - 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! > > 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. 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/38f51eeab6accf3a42154c8ee9e375b0.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote: > 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. > > >> - 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! > >> 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2ba64415-5371-4d66-ab43-569c3783e993%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote: > 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. > > >> - 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! > >> 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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3d0d5e23-3c17-4076-82ba-803bc90d8d2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. >> - 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! >> -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ba0a3fa3473ecb083b9a37262d9bd648.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
@awokd On Wednesday, March 7, 2018 at 10:45:42 AM UTC+1, awokd wrote: > On Wed, March 7, 2018 9:00 am, Yuraeitha wrote: > > On Wednesday, March 7, 2018 at 9:50:13 AM UTC+1, Yuraeitha wrote: > > > >> On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote: > >> > > >>> > >>> 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. > >> > >> 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. > > > > 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. > > 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 an
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Wed, March 7, 2018 9:00 am, Yuraeitha wrote: > On Wednesday, March 7, 2018 at 9:50:13 AM UTC+1, Yuraeitha wrote: > >> On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote: >> >>> >>> 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. >> >> 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. > > 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. 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 appr
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Wednesday, March 7, 2018 at 9:50:13 AM UTC+1, Yuraeitha wrote: > On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote: > > On Tuesday, March 6, 2018 at 2:28:25 AM UTC+1, Andrew David Wong wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > On 2018-03-05 16:28, Alex Dubois wrote: > > > >> On 5 Mar 2018, at 21:07, 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 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 > > > >>> 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. > > > > > > > > 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. > > > > > > > > > > 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/ROrdOlizLqHt
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote: > On Tuesday, March 6, 2018 at 2:28:25 AM UTC+1, Andrew David Wong wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 2018-03-05 16:28, Alex Dubois wrote: > > >> On 5 Mar 2018, at 21:07, 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 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 > > >>> 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. > > > > > > 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. > > > > > > > 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+6fksaKhhSAxyMcWSUb094PXhZ
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Tuesday, March 6, 2018 at 2:28:25 AM UTC+1, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2018-03-05 16:28, Alex Dubois wrote: > >> On 5 Mar 2018, at 21:07, 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 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 > >>> 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. > > > > 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. > > > > 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- 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
Fwd: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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]
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
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"bh"t
Lenovo X230: Qubes OS 4rc4 with Coreboot
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2spQpUQbLaMvw%2Bo950sAF5SwFyZO7mOoCXVLz_wrk8JOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 6 Mar 2018, at 01:28, Andrew David Wong wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2018-03-05 16:28, Alex Dubois wrote: >>> On 5 Mar 2018, at 21:07, 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 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 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. >> >> 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. >> > > 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. :) 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 > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd7psACgkQ203TvDlQ > MDDzqRAAlppp00e/YixAnaLJgyNEYbZgxA9ZlVAB
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Hey Alex, On 03/06/2018 12:31 AM, Alex Dubois wrote: > > > Sent from my mobile phone. > >> On 5 Mar 2018, at 21:42, awokd 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 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 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? 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/25321d40-c889-12dd-2c2e-346db1da83d5%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-03-05 16:28, Alex Dubois wrote: >> On 5 Mar 2018, at 21:07, 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 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 >>> 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. > > 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. > 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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c00df96b-2ccc-b162-2731-367fbf2da759%40qubes
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 5 Mar 2018, at 21:42, awokd 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 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 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? > >> 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. > >> 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 > > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/AE67729B-1060-4551-9D45-B2BE24B2687A%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 5 Mar 2018, at 21:07, 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 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 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. 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] > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1FE16220-B6F8-4F06-B1DE-E7718831615E%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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 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 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. > 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3c3770d0a78a441b1008a1f2e751647b.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/583350bf-1f93-f4b8-912e-3134ca5395a2%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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 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 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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2sFDuG4UJWY7ovwOh3seC1ijFayWASvf4%3DPz7ujSVa08A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 5 Mar 2018, at 07:59, 799 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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/96D15406-2197-4284-94D3-DC5860E959C7%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2uq%3DMfrp-ZRzRULeTFHtEa%3DQyTxGw2h4r87kwJ6-6k6zQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 4 Mar 2018, at 21:44, awokd 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 > Can't really commit the time to be a > forum moderator, but something like this would work. > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/492AFBEE-BF3F-46E0-82CD-CE9D849B67E7%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Sent from my mobile phone. > On 4 Mar 2018, at 20:04, 799 wrote: > > Hello Alex, > > > 2018-03-04 11:49 GMT+01:00 Alex Dubois : >> >> 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] > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://grou
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
@Taiidan On Sunday, March 4, 2018 at 9:48:51 PM UTC+1, tai...@gmx.com wrote: > 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. 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0d44e704-bfdd-4930-9f7e-fbf465b5e608%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180305004121.d3z22jiiuxunssua%40my-privmail. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/50df1bb5-8aa7-4b8b-9631-777fc1be4f25%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ade01ed7ab04b9aa88dc4194695bd05b.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Hello Taiidan, Am 04.03.2018 9:48 nachm. schrieb "taii...@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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2tU0q%2BOeikDJ2OSw%2BO7X8P5g6m7n6R09ujwh6nOpQ_h7w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/540e338b-b6fa-173c-7b31-d0b14edf5330%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Hello Alex, 2018-03-04 11:49 GMT+01:00 Alex Dubois : > > 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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2uhd7eaW4%3DOPvQThfJK15PrTyy4nEOLEzXxdV4NT9%3DCXw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Sunday, 4 March 2018 01:11:08 UTC, Yuraeitha wrote: > On Sunday, March 4, 2018 at 2:01:40 AM UTC+1, Yuraeitha wrote: > > @[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 > > On Saturday, March 3, 2018 at 6:25:08 AM UTC+1, Andrew David Wong wrote: > > > -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
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Sunday, March 4, 2018 at 2:01:40 AM UTC+1, Yuraeitha wrote: > @[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 > On Saturday, March 3, 2018 at 6:25:08 AM UTC+1, Andrew David Wong wrote: > > -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/XTXMEd3F2XUlCKOiLCLdNCVIY
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
@[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 On Saturday, March 3, 2018 at 6:25:08 AM UTC+1, Andrew David Wong wrote: > -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- Those are interesting older threads indeed, it gives some good new insight. I
AW: Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3mL8yqgzX82vXT0M2YQTfqtokZoNBaVgopo61t_IrBWJOu23qV2xMPREH9VLQdthorQIdTRoh_e_XqIJIGbZBHbKknThRCzmF0RhJXJZH2g%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
-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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3e7e33f5-ff89-fee2-b3f0-86403079adac%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
-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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1b87eb37-a69c-2d26-6c28-8b8dc4fc5861%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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
Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
Hey, On 03/02/2018 09:49 AM, '[799]' via qubes-users wrote: 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. 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/996f7438-1817-b25e-5252-2482617f8219%40maa.bz. For more options, visit https://groups.google.com/d/optout.
AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/p-uX5tavIz92-fwvIJnRRSFD-WqFaQsfrK4At8UiXHtw09EYse8U3Kh7ipZcp2KEbZ_eBo3BVAXDZxo-huP-26Us-xPqudGA94DsdO1Rxqg%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Friday, March 2, 2018 at 4:16:39 AM UTC+1, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2018-03-01 05:39, Yuraeitha wrote: > > On Thursday, March 1, 2018 at 11:53:19 AM UTC+1, Laszlo Zrubecz wrote: > > On 02/28/2018 09:39 PM, Yuraeitha wrote: > > 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. > > > > Have you seen this page: > > https://www.qubes-os.org/qubes-issues/ > > > > > > > > > > @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
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-03-01 05:39, Yuraeitha wrote: > On Thursday, March 1, 2018 at 11:53:19 AM UTC+1, Laszlo Zrubecz wrote: > On 02/28/2018 09:39 PM, Yuraeitha wrote: 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. > > Have you seen this page: > https://www.qubes-os.org/qubes-issues/ > > > > > @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 th
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Thursday, March 1, 2018 at 8:48:35 PM UTC+1, Alex Dubois wrote: > On Thursday, 1 March 2018 11:47:13 UTC, Yuraeitha wrote: > > On Thursday, March 1, 2018 at 1:31:50 AM UTC+1, [799] wrote: > > > 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] > > > > @[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? > > 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 m
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Thursday, 1 March 2018 11:47:13 UTC, Yuraeitha wrote: > On Thursday, March 1, 2018 at 1:31:50 AM UTC+1, [799] wrote: > > 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] > > @[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? 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)... -- You received thi
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Thursday, March 1, 2018 at 1:31:50 AM UTC+1, [799] wrote: > 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] @[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? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a26c729c-4c82-41ef-ab5d-8179a2495c8b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
On Thursday, March 1, 2018 at 11:53:19 AM UTC+1, Laszlo Zrubecz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 02/28/2018 09:39 PM, Yuraeitha wrote: > > > > 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. > > 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- @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
Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2018 09:39 PM, Yuraeitha wrote: > > 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. 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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e93fc79c-5aad-d190-c32e-82e85d664d6a%40zrubi.hu. For more options, visit https://groups.google.com/d/optout.
AW: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0pr2C-ky5f2cKco20qOf5PtKmsLafq7Xmw0-9qKvG0demT1mbPRyAv1QOkn6w6oYvxjrv-XP_eVgyhuqrbNE8Hac1U2BLhioUJ9M6l5SlkA%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5d1fd248-de9c-4d4a-a8a8-c716a5e251a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
