Sent from my mobile phone.
> On 4 Mar 2018, at 20:04, 799 <one7tw...@gmail.com> wrote: > > Hello Alex, > > > 2018-03-04 11:49 GMT+01:00 Alex Dubois <bowa...@gmail.com>: >> >> I had some thought. >> - Qubes team probably don't have the time to spread too thin, and would >> prefer for us to help them on there Qubes repo >> - Some people invest time in documenting, but it takes time for Qubes team >> to validate the pull request, and sometime they may prefer to not accept the >> PR. > > It is important to communicate why a pull request has not been approved. > This communication takes some time and also fixing the issues Yes agreed and the fork would be a good staging area/first pass > >> I think one of these 2 options would be a first good step in the right >> direction: >> - Qubes team provides a fork of qubes-doc in another project on which >> community members accept PR that can then be accepted as PR upstream on the >> official qubes-doc, qubes team only manage the access right for the PR (?) >> - Someone is happy to put the effort to do option 1 and manage it (which >> should be limited to access right to that repo to trusted comminutity >> members to accept PR), as long as Qubes team agree with the approach > > > I agree that this will be the easiest option and allows us to start > collecting scripts. > I am unsure if we really need to fork the whole qubes-doc as this might lead > to confusion where to work when improving the existing documentation. I think it is important to keep it as a fork for few reasons: - most importantly we focus on helping the Qubes team - if not it would be hard to clean-up what is in Qubes-doc, in the community repo, and if the Qubes-doc get improved directly, it won’t be ported to community, leading to not up to date info That does not prevent the fork from starting new areas of documentation. I strongly feel that if it is not a fork we will dilute our contribution to the project. If David does not have the bandwidth to manage the access right, I feel awokd is a good candidate too. He acquired a good visibility of the overall doc. However I think my suggestion is only to be taken with Qubes team validation. And if they feel it is not the best way and prefer the mailing lists and existing infrastructure it is important to respect that and get back in line. It is also important to not spend too much resources discussing this, but rather contribute directly. > > Can't we just create a new "community" repo where Pull request get reviewed > by us but finally approved by more experienced Power Users (this group can > include Qubes OS Team, but also experienced community members selected by the > Qubes Team/David)? I don’t have much experience in managing communities. I feel that a pair/trio need to be “responsible” per area or subject. With a person helped by one or two for the overall. > >> I have one concern with such proposal. A number of community proposal are >> sometimes not very secure (to be gentle). So ideally a layer of meta-data is >> added (maybe on a single index page), with the rating of the doc page. > > > Agree, it might feel frustrating in the beginning of you start contributing > docs and then find out that the "nice idea" that you had leads to several > security risks or is just not yet ready to be released. > But: this is exactly the point what I like about Qubes. That I can rely that > it's not that easy to do something stupid which compromises security. > As such writing docs or scripts always include a learning curve which is a > good thing. Yes and different people have different expectations. But I think an index page rating the security level or enumerating the risks identified would be nice. For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn in line (I.e. sys-firewall). This is a bad practice as the attack surface of one protocol is exposing the entier Qubes system. A better way is to have these hosted on app-vm and have sys-firewall intercepting and routing the traffic. Even having sys-firewall doing the download rather than a dispvm is increasing the attack surface (not sure if still the case) All these points are not criticism of Qubes, perfect security does not exist, but capturing them in a central place would be beneficial. That said, the most important thing is that I am at fault for doing this in an email rather than in a PR. But this same PR done in the community staging area would give some bandwidth to Marek and co. However Marek may loose visibility on how things are going so David or awokd need to sync with him a summary. > > [799] > -- 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/A676470A-9008-44F8-89C2-3561EF874883%40gmail.com. For more options, visit https://groups.google.com/d/optout.
