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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to