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 <one7tw...@gmail.com> wrote: > > > >> > > > >> Hello, > > > >> > > > >>>>> On Sun, March 4, 2018 8:04 pm, 799 wrote: Can't we just > > > >>>>> create a new "community" repo where Pull request get > > > >>>>> reviewed by us but finally approved by more experienced > > > >>>>> Power Users (this group can include Qubes OS Team, but also > > > >>>>> experienced community members selected by the Qubes > > > >>>>> Team/David)? > > > >>>> > > > >>>> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote: I > > > >>>> wouldn't mind helping out on reviews on something like this, > > > >>>> as well as contributing my own half-baked ideas. > > > >>> > > > >>> On 5 March 2018 at 08:57, Alex Dubois <bowa...@gmail.com> > > > >>> wrote: True we could have sandbox per person, or each person > > > >>> fork (the fork) and we have a page with list of forks Once idea > > > >>> is ready, do a PR to the community fork... > > > >>> > > > >>> This is the spirit of git > > > >> > > > >> can't we just start to fork qubes-doc to qubes-community-doc and > > > >> start there. If we think we need to rearrange the content or get > > > >> rid of it, because it just doesn't make sense, we can still do > > > >> so. > > > >> > > > >> In the main qubes-doc repository it seems that some skilled users > > > >> are able to approve Pull Requests, I don't know enough about > > > >> github how this works? Are those special permissions for trusted > > > >> users or can it be anyone? I would like to see Andrew David Wong > > > >> or marmarek as power users supporting this - by at least maybe > > > >> giving feedback. If there are any other skilled persons which are > > > >> happy to gibr feedback to improve the scripts which are collected > > > >> there, this is even better - just mentioned those two as they > > > >> were super helpfull when I wrote my first Qubes Docs hey, ho - > > > >> let's go. > > > > > > > > Give David a bit of time. His schedule might be busy, he may need > > > > to sync with a number of other persons, they may discuss what’s > > > > best. There is no rush. He is doing a great work as community > > > > manager. > > > > > > > > > > Thanks. :} > > > > > > Currently, qubes-doc PRs have to be approved by a member of the Qubes > > > team before being merged into the master branch, which is the live > > > version. (Usually, I'm the one who does the merge. In those cases, if > > > you don't see explicit approval from another member of the team, it > > > just means that I'm the one who has reviewed and approved the PR.) > > > This system is great for maintaining high standards of security (as a > > > first priority) and quality (as a second priority) for the docs. > > > However, it's very time-consuming, since (at least) one of us has to > > > review every single PR that gets merged (as well as many of those that > > > ultimately get rejected, which are a small minority). > > > > > > Currently, we barely have enough time to keep up with the stream of > > > PRs that get submitted to qubes-doc, so it's very unlikely that we'd > > > also have time to review or provide substantive feedback on PRs for a > > > second, community-run version of qubes-doc that receives even more PRs > > > (if I'm understanding the proposal correctly). > > > > > > However, I do like the sound of a fully-community-run version that > > > serves to collaboratively improve content before it is submitted to > > > qubes-doc. Currently, most contributors just submit their work > > > directly to qubes-doc, and the quality tends to vary. Perhaps the > > > community-run version could be an optional (but recommended, > > > especially for first-time contributors) place where work is polished > > > up with feedback from the community before it's submitted as a PR to > > > qubes-doc to be reviewed by the team. This could make things easier > > > for contributors, improve the quality of the docs, and save the team's > > > time. > > > > > > > > > P.S. - You can call me "Andrew." "David" is my middle name. :) > > > > > > - -- > > > Andrew David Wong (Axon) > > > Community Manager, Qubes OS > > > https://www.qubes-os.org > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd7psACgkQ203TvDlQ > > > MDDzqRAAlppp00e/YixAnaLJgyNEYbZgxA9ZlVABBxUJwUX7Ede0MAHeiLHLiR0E > > > PqdvVBSBi1rt0XYROka44IJ8amj1pM3tc5UroE4rhG8yxY7TPnul0tAHeTH5rTk2 > > > rCPOsHLSuv/nwqdzhvcCK2cC9SKYgJF7IGdgtRnaMg56JEYkn7HISKFxMfL6m8L9 > > > quU4dRdBJnWEk16lYHxQBd3JtVeBtHjCppHh9CFn5XYdbPvbPd8qYwOVMdSOaG0k > > > 0adeue8gI8G6Mkf3pzJt7Etjr8xjlHB4JKaMy7VCN7PekdkrITbQCwPH24PLQHP9 > > > +pFQu2ShBZgOFyNQ+itDPW70r/1Jfc0mpRu16Dz85/VTew/ROrdOlizLqHtbS6L4 > > > i0ZG6vbFAw0H4/kPzOWz3xxRukbXtOWBL6kx1a8Sj+JZSs5B5mbSGkg5S4vOEXrg > > > p+PBzt5jfuwg9ZrJCqBOWy56JfPqpmb37ooqC94oTYeXX2utRFQg8QyA/NRMgduM > > > pkRNOVOpO81OIiUYvzM9eY2zYhWa3LUY4x0OdkiO9hcZ7tVQ17iurgBE8KFy6drj > > > dKd4nLPiXUMF6mGXt+6fksaKhhSAxyMcWSUb094PXhZjcqiMKEaP+7hd0tZeNSE8 > > > R/zFQJyd6VPaervecyKvcMw9mXt2Mal/OBRlyMHbJcyNqLpucLs= > > > =WFKk > > > -----END PGP SIGNATURE----- > > > > To extend on [799]'s idea of a new Community doc page, and combine the idea > > to make a stepping stone development progress system, and combine it with > > 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. -- 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/81950c13-0ca4-41a7-9c5c-534894cd1dd5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
