Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

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

[Ivan Mitev]

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

[Yuraeitha]

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

[Yuraeitha]

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

['awokd' via qubes-users]

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

[Ivan Mitev]

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

[Yuraeitha]

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

[Yuraeitha]

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=qubes+os=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

[Ivan Mitev]

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=qubes+os=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

[Yuraeitha]

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=qubes+os=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

[Yuraeitha]

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=qubes+os=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

['awokd' via qubes-users]

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

[Ivan Mitev]

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=qubes+os=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

['awokd' via qubes-users]

On Fri, March 9, 2018 12:53 pm, Yuraeitha wrote:
>

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

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

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

-- 
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

[Yuraeitha]

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=qubes+os=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

[Andrew David Wong]

-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: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Ivan Mitev]

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

[Yuraeitha]

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

[Andrew David Wong]

-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: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

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

['awokd' via qubes-users]

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

[Yuraeitha]

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

[Yuraeitha]

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

['awokd' via qubes-users]

On Wed, March 7, 2018 11:06 am, Yuraeitha wrote:

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

Github is easy for me to misunderstand too. :)

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

>> - 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

[Yuraeitha]

@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 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

['awokd' via qubes-users]

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 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

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
> > 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

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
> > 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

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 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

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-
> 
> 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Ivan Mitev]

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

[Andrew David Wong]

-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 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

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

[Alex Dubois]

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

['awokd' via qubes-users]

On Mon, March 5, 2018 9:07 pm, 799 wrote:
> Hello,
>
>
>>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>>>
 Can't we just create a new "community" repo where Pull request get
 reviewed by us but finally approved by more experienced Power Users
>> (this
>>
 group can include Qubes OS Team, but also experienced community
 members selected by the Qubes Team/David)?
>>>
>>> On 4 Mar 2018, at 21:44, awokd  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

[taii...@gmx.com]

On 03/04/2018 04:17 PM, 799 wrote:


Hello Taiidan,

What does "zero qualification" means and what does "advice" stands for?
If this is going to be a wiki letting anyone edit it irregardless of 
skill level will result in poor quality.

It's not about advicing (advice to me means: I know something better then
someone else or at least I feel knowledgeable enough to tell other people
what they should do).

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


I don't see how qualification is "certified" by running Coreboot/Libreboot?
It is an easy way to prove that someone has a decent level of linux 
experience as the installation of coreboot is considered difficult.

You need a way to separate the wheat from the chaff.

I am running coreboot does this qualifies me?
If you compiled installed it yourself then yes - it proves you have a 
decent skill level.

Keep also in mind that there
might be users who need to run recent hardware or hardware that are not on
the Coreboot Hardware Compatibility List (HCL).
By your standards why not let windows users comment too? after all not 
everyone has hardware that supports qubes right?


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


If someone can't afford a $100 laptop they probably have nothing worth 
stealing (personal data or otherwise) and thus have no reason to use 
qubes or even have a computer at all.

Writing from my Googlemail address which is only there for Qubes+Coreboot
Mailinglist because Protonmail doesn't offer IMAP:
There are way more than just two email providers even if you don't wish 
to pay a very reasonable $5/mo for paid email there are free providers 
that don't abuse you to the level that google does.

Not using Google doesn't make someone superior
No it really does, not using google means you have skills and have put 
in the research and effort to find a superior provider - ie: you care 
about your security.

and even if you are right
that there are reasons not (!) to use Google for personal E-Mails:
There are many including AI research, datamining, no real security and 
the lack of customer service.


Not to mention google recently choosing politics over profit which is 
not what a publicly held for-profit company should be doing.

If you don't allow them to comment,there is no possibility for a discussion
and convincing them to try something different.
I am not referring to a discussion forum I am referring to a wiki where 
letting anyone edit it is dangerous, the good advice of skilled user is 
easily edited and ruined by a microsoft fanboy who thinks that owner 
controlled hardware is too dangerous for just anyone to own (remember 
that hardware enforced code signing is a very recent development, owner 
controlled was the superior norm for the first half century of 
computing) and that everyone should use "secure" boot for "security".

And if so, then Qubes should not run this Google group/Mailinglist ;-)
I have complained about this - I really don't like giving google carte 
blanche to use my data to for instance eventually put me out of work via 
their AI research.


--
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

[799]

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

[Alex Dubois]

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

[799]

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

[Alex Dubois]

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

[Alex Dubois]

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 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

@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: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[sevas]

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

['awokd' via qubes-users]

On Sun, March 4, 2018 8:04 pm, 799 wrote:

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

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


-- 
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

[799]

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

[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".


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

[799]

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

[Alex Dubois]

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
> > > 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

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
> > 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

@[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

['[799]' via qubes-users]

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

[Andrew David Wong]

-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

[Andrew David Wong]

-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

[Yuraeitha]

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 

AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

['[799]' via qubes-users]

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.