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 approve submissions - unclear on how documents would migrate from here to qubes-doc unless as a copy/paste, but that would lose attribution and I imagine most would like their own name on their commit! Can any Github pros confirm/deny/provide additional detail? -- 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/76b06e6ea002ab84593a5bc1a1ee21a6.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
