structure / naming of the repositories

[ghost]

following the ML thread, IMHO we should settle on a clear and simple setup.

Root: Qubes-Community-Collaboration (maybe make it "Qubes-Community" ? it should be implicit that since it's on github with several members it should be a collaboration).

• staging-doc
  • that's where documentation "matures" until a PR is submitted to the official qubes-doc
  • should host the public wiki
  • should host issues with the qubes-doc documentation, to help people drop "drive-by" contributions.
• unofficial-doc
  • documents that we know wont be accepted by qubes-doc for whatever reason (like allowing to shoot yourself in the foot with security)
  • [?] interesting documents that were in staging-doc but that were rejected by qubes-doc
• projects
  • various projects living in the organization (it seems @Aekez transformed his account in the organization ; FYI the email invitation's first link proposed to do the same for mine, until I clicked the second link and simply accepted the invitation; otherwise I guess my projects would have migrated to the organization)
  • links to other interesting github projects (I don't think we should ask someone's approval for linking, their projects are already public on github)

[ghost]

I forgot: I'm not sure about the dedicated 'discussion' repo ; Discussions related to qubes in general belongs to ML (or reddit/...). Discussions related to this community effort could be discussed as issues in staging-doc or as team discussions if github allows it (but then it should be public, not only accessible to the team members)

[Aekez]

I didn't transform my account actually, I just gave away my ownership on those repository projects, so that it isn't owned by me anymore, but is everyone's property, and if they mature enough maybe move them to the Qubes ownership one day. Either way, I don't own them anymore, the community does :)

Among the two other pinned topics, should we re-name them for staging-doc and unofficial-doc? Maybe add an identity to them as well. I agree the community name is long, but here it might be too short? thoughts? For example

Would this work? unofficial-community-doc's staging-qubes-doc's

A project folder seems like an awesome idea, I'm not sure if folders are possible yet though. Still learning how GitHub works. If I find it, I'll try move them in there so that we can see the contrast.

Maybe we can make public team discussions as a communication form, so that people can always see them, and automatically join them if they write in them?

I'll try make some of the discussed changes so that we can see how it looks in contrast.

[Aekez]

I moved the collaboration down into the sub-title, works better?

[awokd]

Please delete/rename anything I made, I was mostly testing.

[Aekez]

alrighty, I'll try put forward the examples, lets keep discussing it until we find the best approaches. The changes are just to show contrasts until we settle on one.

[awokd]

Agree with

I forgot: I'm not sure about the dedicated 'discussion' repo ; Discussions related to qubes in general belongs to ML (or reddit/...). Discussions related to this community effort could be discussed as issues in staging-doc or as team discussions if github allows it (but then it should be public, not only accessible to the team members)

and

unofficial-community-docs staging-qubes-docs

I'd call the org. "Qubes-Community". Never mind, I see you did!

[awokd]

On second thought, don't really want to call it unofficial-community-docs because there is a Wiki in there too (which is not a doc).

[Aekez]

hmm, should we make the repository strictly for docs? i.e. if the goal is to later transfer any of those to the official Qubes doc's? I like your idea, but should we put the word docs in it too?

Also I'm not sure if small letters are important, is it a mistake to use big capital letters?

[Aekez]

oh nvm, we posted exactly the same time. A wiki does indeed make it different. Should we add a new repository for wiki's instead?

[Aekez]

the first repository README.md could link to decentralized wiki's as well.

[awokd]

I think the staging one for qubes-doc should match qubes-doc's settings/layout.

In general, let's try to minimize the number of repos- no need to scatter discussions every which way if we can help it. So the "community" one is almost everything. Discussions on staged docs would happen in that repo.

[awokd]

Separate repos for separate projects like you're doing might still be OK. Could use @adubois in here for some perspective.

[Aekez]

aight, try refresh frontpage again for the pinned repo's. I'm not sure if this is what you meant in terms of the naming? what do you think?

I agree it's a bit messy with all those extra repositories, perhaps we should move some of them out again if they won't be big enough to justify a repository on its own. What I like about it is the issue tracking system etc. i.e. like what I started doing in QubesTV, which can help solve QubesTV related issues. It'd be interesting if we can put these into a sub-folder/category system though, but it seems it's not a feature github offers yet https://github.com/klaussilveira/gitlist/issues/380 as someone said recently in the comments, it's 5 years old... it seems like a pretty basic and desired feature, it'd certainly help many github's if having the ability to organizing them in categories.

[awokd]

I'd collapse the 3 Community-* repos into 1 Community repo, but whatever works is fine with me! The rest looks good.

[Aekez]

That's a very good point, it shouldn't affect the published doc's to the Official Qubes docs, so it works far better if merged into one. I'll try do that, just a moment. I'll merge them to this one since we're using it for discussions and the others are empty.

[awokd]

Looks good to me!

[Aekez]

Great! :)

Then there is the issue of discussions, if for example we use this issue tracker for feedback concerns (then they can be closed as they are solved/etc.). Then what about general or other types of discussions? Like Ivan said @taradiddles if only members can see the team discussions, even if they are made public to all of the organization, then those who didn't join the github organization can't see the discussions. Maybe we need an additional platform for discussions, thoughts? maybe we should take some time to think about it?

[awokd]

I was able to view this issue without logging in to Github, so looks like it's on public already!

[Aekez]

That's good! At least that is ensured to work then. It seems team discussions can't be seen without at least being logged in though, probably require organization membership too as Ivan mentioned :/ it'd be nice if we can keep more discussions open and transparent.

[Aekez]

https://github.com/orgs/Qubes-Community/teams Made a few examples here as a trial thingy, to see how it works.

[Aekez]

https://github.com/Qubes-Community/Qubes-Community/blob/master/README.md Thoughts about this README document that people see when they access the Qubes-Community repository? I tried adding bulletpoints for the listings, but it seems the formatting is a bit different in the actual text documents. Need to find out how to do that properly. Thoughts about having lists like this, layout and the context choice of words in it?

[awokd]

Do we need team discussions if we discuss items in here? Not sure what value they add. I'll try to research too.

I say just make it look like how you want and we can suggest edits or do the same.

[awokd]

Can we move the discussion threads off qubes-users onto here instead too? If people are interested, they should be aware by now.

[Aekez]

Agreed, we probably don't need to post further there unless there are questions or feedback from others. But it's massive thread at this point, some people might have just given up clicking on it to read, even if it updates with new replies, since it's too much to read for many.

• Perhaps once we got everything sorted out here, we could make a new, much shorter and brief thread in the qubes-users and announce it?

• I suppose an anarchy kind of leadership system with backward democratic feedback loop indeed could work pretty well, at least until we find something better. Everyone here seem to be responsible though, so we probably don't need to worry about that.

• Also looking onward into the future, maybe we should restrict the owners flag when inviting less known people onward and this place grows bigger, it's essentially full administrator permissions. Members should be able to do the post/commit/push/pull, though we might need to audit the permission system a bit to make it work as intended.

• I haven't found out how new members get on here though, do we need to invite them all? I can't just test it by logging out either, it seems we need a github logged-in account not bound to the organization, in order to confirm this. Maybe someone knows about this though, it would be kinda bad if people can't join on their own :/

• I'm not too sure about the discussions either, maybe it's too early to say how needed they will be? If we're just a handful people, then it probably won't be all that important. But if many more joins, then we might have to look into it? So it might not be so important to sort it out immediately?

[adubois]

You need only 3/4 owners. Then give all access but admin, otherwise someone can delete everything I believe.

Sent from my mobile phone.

On 9 Mar 2018, at 20:56, Yuraeitha notifications@github.com wrote:

Agreed, we probably don't need to post further there unless there are questions or feedback from others. But it's massive thread at this point, some people might have just given up clicking on it to read, even if it updates with new replies, since it's too much to read for many.

Perhaps once we got everything sorted out here, we could make a new, much shorter and brief thread in the qubes-users and announce it?

I suppose an anarchy kind of leadership system with backward democratic feedback loop indeed could work pretty well, at least until we find something better. Everyone here seem to be responsible though, so we probably don't need to worry about that.

Also looking onward into the future, maybe we should restrict the owners flag when inviting less known people onward and this place grows bigger, it's essentially full administrator permissions. Members should be able to do the post/commit/push/pull, though we might need to audit the permission system a bit to make it work as intended.

I haven't found out how new members get on here though, do we need to invite them all? I can't just test it by logging out either, it seems we need a github logged-in account not bound to the organization, in order to confirm this. Maybe someone knows about this though, it would be kinda bad if people can't join on their own :/

I'm not too sure about the discussions either, maybe it's too early to say how needed they will be? If we're just a handful people, then it probably won't be all that important. But if many more joins, then we might have to look into it? So it might not be so important to sort it out immediately?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[awokd]

Perhaps once we got everything sorted out here, we could make a new, much shorter and brief thread in the qubes-users and announce it?

+1

I haven't found out how new members get on here though, do we need to invite them all?

I think @adubois just confirmed we don't need to invite.

I'm confused about the Wiki permissions. One says "Any GitHub user can create and edit pages" and the other right below it says "Restrict editing to users in teams with push access only".

[Aekez]

Thanks @adubois and indeed, we certainly don't want everything to be deleted or changed... especially if it happens after we put in a lot of work here. We might indeed need to think about that more carefully.

btw, maybe if all owners have backups in place? https://help.github.com/articles/backing-up-a-repository/ This way we decentralize it so that if anything is ever lost, we can always recover it. Essentially download the whole repository to our drives. It seems like it might be easier to work with github outside the browser anyway, but all that is still very new to me.

I'll also add a second factor to my account soon (I need a new computer first because my hardware restricts my USB controller to dom0, which in turn doesn't play nice with the hardware key in the qvm-usb. But I'm planning to do that very soon though). At the very least a hacker can't delete the whole thing then, though other owners can still delete things, albeit more slowly. If we all among the owners, have second factor enabled, then we should be reasonably secured from any deletes.

btw I gave Andrew an invite as owner earlier today when we started using this github organization, with that we're 5 people if he accepts. We should probably try restrict it now, like adubois suggested as well.

hmm indeed, that wiki permission seem to have a bit of ambiguity.. we can try guessing, but we might also get it wrong by guessing, i.e. if we believe it to be between two choices, like 80% probably that, and 20% less likely, but then it turns out to be the 20% scenario instead of the thought more likely 80% scenario. Maybe we can try restrict a repository, and ask a non-owner to help us confirm if it works? This way we can know with certainty. Do you know anyone who can check for us?

[Aekez]

https://github.com/Qubes-Community/Qubes-Community and https://github.com/Qubes-Community/Qubes-Community/tree/master/docs thoughts on the layout?

Also I changed my personal profile on here from private to public. Any chance you guys feel like to do the same? or should I put mine back on private again? It'd probably look weird if only one or two people show up as active users for people who are not members, while members can see everyone. If you want to change it, then I found the toggle setting over here https://github.com/orgs/Qubes-Community/people if not, then I'll probably put mine back on private instead.

Deleting the empty Qubes-Styling repository I made earlier today https://github.com/Qubes-Community/Qubes-Styling and instead use the Qubes-Community repository for these. Keeping it simpler, Qubes-Styling probably won't require issue tracking or multiple inter-connected scripts like QubesTV, Qubes-NAS, Qubes-A.I. or other yet-to-come-similar-complex-projects will require.

[adubois]

Thanks @adubois and indeed, we certainly don't want everything to be deleted or changed... especially if it happens after we put in a lot of work here. We might indeed need to think about that more carefully.

Initially you want to provide access rights so that: anybody can read, submit PR/issues small number of users can approve PR core team manage access rights

Have I got any access right in here? not sure. I wanted to do my original ideal which was to clone qubes-doc (with all the existing doc)

btw, maybe if all owners have backups in place? https://help.github.com/articles/backing-up-a-repository/

True, and we may need to test what happens if we fork (in our personal). Very true that the original may disappear, but the fork would remain (so we can re-establish).

This way we decentralize it so that if anything is ever lost, we can always recover it. Essentially download the whole repository to our drives. It seems like it might be easier to work with github outside the browser anyway, but all that is still very new to me.

You are right, once you know git, it is much easier to do from command line (and you can script work-flows) One important point on that topic, make sure we are independent off github. So for the site generation, we can use github pages (it takes a repo, parse all the md and merge it with a template, and generate a static website). We need to make sure we can fully do that on desktop too. Hugo.io is a good project that allows that (but this is one of the tool using this pattern). We need to identify the tool that does on the desktop what github does on the server.

I'll also add a second factor to my account soon (I need a new computer first because my hardware restricts my USB controller to dom0, which in turn doesn't play nice with the hardware key in the qvm-usb. But I'm planning to do that very soon though). At the very least a hacker can't delete the whole thing then, though other owners can still delete things, albeit more slowly. If we all among the owners, have second factor enabled, then we should be reasonably secured from any deletes.

In Atlassian confluence wiki, you can have the right to add/modify but not delete. git is better than a wiki, you never delete, as someone can still see in the history the past version.

btw I gave Andrew an invite as owner earlier today when we started using this github organization, with that we're 5 people if he accepts. We should probably try restrict it now, like adubois suggested as well.

hmm indeed, that wiki permission seem to have a bit of ambiguity.. we can try guessing, but we might also get it wrong by guessing, i.e. if we believe it to be between two choices, like 80% probably that, and 20% less likely, but then it turns out to be the 20% scenario instead of the thought more likely 80% scenario. Maybe we can try restrict a repository, and ask a non-owner to help us confirm if it works? This way we can know with certainty. Do you know anyone who can check for us?

I am happy to set-up the qubes-doc doc once you invite me (you may have, I'll check the mailbox again it is flooded) Then I can remove my access and do some testing I may have time to look at setting up access right before. In atlassian Jira you have a number of roles:

• User, Contributor,Ddeveloper,Ccomponent owner, etc... I suspect it is the same here. We'll see, it should be pretty clear.

[adubois]

I strongly believe that an empty staging-qubes-doc is useless. a forked one give:

• Ability to submit PR with one click (no need to copy the modified text and paste it in an edit of the qubes-doc)
• Ability to fetch (pull changes from qubes-doc)

So this I would definitely change. An empty one does not provide any of github functionality. The 2 repo are separated. Having the link to the one in progress in the qubes-comunity repo is very good (so people find what we are working on). For QubesTV, QubesNAS repo, is the aim to provide a tool to automatically set this up (independently of how his user may already have his set-up done)? Because I have few ideas in this area and we will need at some point to think about the architecture so that is a user install QubesTV + QubesNAS, it is possible. But let's keep the tread focused on this issue after your reply.

[ghost]

A lot of comments have piled up ; quite some stuff to reply to.

flows and repos

After quickly reading the comments and looking at the new repo layout I don't really understand how information from users is supposed to flow. There are basically two things that we ought to achieve (IMHO):

1. being a gateway to the official qubes-doc / making it easier for unexperienced users to send back their feedback.
   • non-git users should be able contribute; that means having a public place where anybody can add stuff, like a 'scratch' public wiki page or alternatively a public email address (don't know how that'd work with github though). It is to be expected that this 'scratch' wiki page (or pages) can be defaced/spammed/... although this shouldn't happen often since it requires people to log with a github account to publish something.
   • people comfortabe with git would submit PRs to staging-doc (if they target inclusion in the official qubes-doc later on) or to qubes-community (if they don't know what to do, or they know the doc won't be accepted in qubes-doc).
2. gathering docs/scripts/... that for a reason or another won't/can't be included in the official qubes-repo. The reason for non-inclusion in the official qubes repos should be clearly stated when possible (eg. "widening surface attack", "not in a supported prog. language", ...).

Anyone disagrees ?

I see that the description of the staging-doc says "declined, or accepted". IMO the staging repo (docs with PRs + wiki) have to be only for pending new stuff, and work in a producer-consumer way:

• if something's in the 'scratch' wiki, one of the team members would move the content into a PR submitted either to the staging community doc for further discussion, or directly to the official qubes-doc. (TBD what to do with bad content/ideas).
• if a doc is accepted in qubes-doc it is then deleted from staging (in the same way the linux kernel's staging branch works). Otherwise there will be duplicate content + divergence when the doc is modified in only one of the repos.
• if a doc is rejected, the reason for rejection should be added to the doc, and the doc moved to qubes-community

Wikis: IMHO only a "scratch" wiki like described above is required. Having another official wiki will make it harder for the team/contributors to synchronize pages with the content in qubes-community (properly written README.md in subfolders ought to be enough). And there's the problem with permissions anyway.

forking qubes-doc

@adubois : the staging repo should really be a 'transit' repo for new content. I definetely see your concerns though, so what about forking qubes-doc in a standalone repo ? Either way, how do you plan to keep that repo in sync with upstream ?

instructions for contributors

once the repo structure is ready there should be a short guide explaining how to contribute to the commnuity effort (flows, PRs, 'scratch' wiki, community repo, ...). I'm OK to write that.

[awokd]

Sent @adubois an owner invite. If we want to keep owners in the 3-4 range, I nominate myself for removal from that role!

Re: the workflow discussion above, those are the parts I generalized away as "magic" but they seem reasonable.

[Aekez]

@awokd I think the 3-4 range mostly makes sense in order to minimize someone going rogue or getting hacked. If we all get 2nd factor to our accounts, then I don't think it changes much if stepping down is to allow another to take his place, the 3-4 rule is kind of a rule of thumb anyway? But in general, I think we can handle the being 5, or 6 if Andrew accepts. Especially if we all have git backups on our drives and use 2nd factor to our accounts. I haven't had the chance to look at the permission system yet, but from what I get the gist of in Alex's words, is that teams can have permissions too. Maybe we can make a high rank moderator rank in there as well. Some things to think about, I'll try go look at the team permissions now.

@adubois oh right, you're Alex! Having second names is confusing at first, especially when I suck at names, I had to look you up to find out.

To have a proper channel to send/receive between the Official Qubes docs, if you can make that work, it'd be a great help. You're thinking about removing the empty repository and fork the Qubes doc in it's place, if I understood your suggestion right? Then we can commit changes back from the fork, is that how it in a broad sense works?

You're welcome to take part in QubesTV and QubesNAS, I'm essentially all alone with them right now, so if you're interested we can work together on them. You're probably more skilled than me with scripts though, but we'll figure it out. By the way I got a response from Marek for whether it can be judged as okay to install pulseaudio-utils in dom0 for the pactl command to control sound, it should be alright to include the install command in the installer we make. You can find it here https://github.com/QubesOS/qubes-issues/issues/3659

Gonna spend time today to get more into git/terminal and github user permissions.

@taradiddles I made a few folders last night, I'm not sure if it fixes this issue of staging, but try have a look in here https://github.com/Qubes-Community/Qubes-Community/tree/master/docs Maybe the last folder can be considered as a staging folder? It's already kind of like that. This is just a question btw, as you might have a better setup in thoughts.

A scratch wiki seems like an interesting concept, can you try make one to put the idea in form? I'm still thinking about the wiki part, to me some loose ends still feels open, but I definitely think a scratch wiki is a good idea though.

https://github.com/Qubes-Community/Qubes-Community For example, the question you put forward whether we should move the wiki segment here to the scratch wiki. To me here are two opposite contrasts, it both makes sense to have a single place for all lists, but it also makes sense to only have a single wiki in a single place for all things wiki. Since I think the scratch wiki is a good idea, I'm kind of torn between these two perspectives. It's probably best to remove the wiki in the overview page found in the up above though, and just make a single place for all things wiki, as you suggested. Cutting the clutter, making it more easy to navigate the system.

btw what do you think about the distinction between docs, projects and guides? I.e. guides on how to use the community platform could be put in the guides section? It might also be worth discussing what we list in these lists, for example will we still link to finished docs after they get accepted in the Official Qubes docs, or will we keep it cleanly separated. Again, a question of keeping it clean vs. using github as a second platform to find guides/docs. When push comes to show, this place is first and foremost about building, so if it comes down to it, it might be better to just cut loose overview lists of docs that was accepted to the official Qubes docs. Thoughts?

[ghost]

@awokd

If we want to keep owners in the 3-4 range

I don't think there should be a limit, but if there is I'd rather be removed given the work you're doing on qubes-doc

@adubois I don't have any objection to forking qubes-doc into staging-doc. From my noob attempts at git I don't see how you'll solve conflicts when sync-ing with upstream every now and then though.

@Aekez

A scratch wiki seems like an interesting concept, can you try make one to put the idea in form

Basically I'll just add a wiki functionality to staging-doc and make it fully public. Or, if we all agree that there won't be a full blown wiki in qubes-community and that README.md-s will do, the 'scratch' wiki could be in qubes-community. But again, this wiki should be empty most of the times: in theory as soon as something is published it should be converted as a PR.

I'm running out of time, I'll try to reply to your other points later today

[Aekez]

@ all aight, found out how the team permissions work with repositories now, it's so simple that it becomes hard... well, easy once found, but it's kind of ironic.

@taradiddles yeah we need to justify it if we make a limit, as I don't see a way to justify it, then I don't think we need to enforce it. Though maybe we can slow down on who we invite as owner onwards. I.e. if anyone is helpful organizing in the future, then we can give them team permission instead (at least in the beginning). But I think it makes good sense that all founders have ownership here.

I like your wiki ideas. Should we wait till after we solve how we fork though since the wiki might depend on how we do that? Unfortunately I don't have much insight forking/pull/push yet, so I can't help with this before I get a better insight. Maybe we can try setting up some examples, i.e. if @adubois makes one, and we try see how it works from there and then discuss it? Then we can try see how the wiki fits into it too? We can always re-work things, I trial and error'ing a bit.

[awokd]

@Aekez I don't think we need folders like that there. 1 & 2 will be handled either on the wiki or in an individual's PRs. 3 will be part of the PR process when something gets submitted to the community repo. 4 is OK but if we start getting a lot of content we could make additional folders by content type (like the qubes-doc repo does). 5 would be part of the PR process against the staging repo.

[Aekez]

@awokd Good point, concept phase can be made via wiki's, that also add's more openess to it all. And considering folder 2 and 3 can essentially be merged into one indeed. Well, might be better to just remove them all, the idea kind of breaks apart at this rate, since as you mention folders can take different structures depending on the other repositories and amount of work. I'll remove them when I establish git/terminal connection, since folders are a pain to control from the web interface.

[awokd]

PRs are open too, just a little more difficult to find. :) I'd still leave 4 though, so we're not dumping everything into "root" in there.

[adubois]

@taradiddles completely agree with you on the objectives.

I was thinking in approaching it as a qubes-doc fork as the main way of doing (using github, you can just edit the page). New doc script get added to new section of the qubes-doc if required. If Qubes project push back, we move them either to a folder of our fork or to another repo (I think the first option will be easier). (we will need a repo same as qubes-github-io to generate the website for the fork (if we need).

The second option is the one some of you like, where we bridge the gap for non git users by having a wiki.

Best is we explore the 2 and see where the pain points are.

Once done we document the information flow and how to apply it I agree, this is required.

[adubois]

I am going to create a new issue to discuss the fork idea as we are starting to mix a lot of topics and it's getting hard to follow. Maybe create another one for the wiki workflow and we communicate here for the link between the 2.

For now I would not split guide, doc, projects. Just because we don't know yet how we are going to work. Once we do we discuss the structure of what we put inside. I agree that separate repo is required for a "package": set of script/code that deliver a product. The doc for that specific package should ideally be with it. I think we can make the web-site to parse the qubes-doc and the various qubes-repo where there is a /docs folder (we just need to agree on a convention).

[adubois]

4 has progressed I let you have a look, it looks promising.

for the package doc, if we want github to do the website automatically, it has to be in /docs (check the repo settings, you can make a website from / or /docs)

[ghost]

@Aekez - thoughts on the 2nd part of your post

I made a few folders last night, I'm not sure if it fixes this issue of staging, but try have a look in here

I see you modified the folders after @awokd's remarks.

• what is the 'preparing qubes doc' folder for ?
• the '1) work in progress' folder duplicates the PR functionality; pros: it's more visible than PRs (but then we could point PRs to people in README.mds) ; cons:
  • we loose the discussion thread in PRs so we'll have to open related issues for each work in progress page/file.
  • PRs are public but each PR is constrained to its creater/owner - How to replicate those permissions within a folder ?

Minor quibble: I'd remove the leading numbers - IMHO they won't make sense if folders are added/removed in the future.

just make a single place for all things wiki

My idea was to have only one wiki: the 'scratch one' (at least at the beginning). Its content would be:

• a single page for small drive-by contributions, ideas, one-liners, ...
• temporary pages created by "non-git" people contributing more lengthy documentation (eg. like I first did with the windows documentation).

btw what do you think about the distinction between docs, projects and guides? I.e. guides on how to use the community platform could be put in the guides section?

I don't really have any preference, this will become clear once we begin to add content. That said, the text about how to contribute to the docs should be prominent, eg. at the top of qubes-community's README.md.

@ all : with PRs in Qubes-Community + the "Qubes-Community/docs/work-in-progress" folder (provided the permissions issue is worked out) + PRs in the forked qubes-doc repo we can probably get rid of the Staging-Qubes-docs repo. Thoughts ?

I'll try to create another github user for testing different workflows. Will report in another issue (@adubois's right, the thread is already too long...)

[awokd]

get rid of the Staging-Qubes-docs repo

Yes, the forked qubes-doc would be used for staging.

[adubois]

Sent from my mobile phone.

On 10 Mar 2018, at 08:29, awokd notifications@github.com wrote:

Sent @adubois an owner invite. If we want to keep owners in the 3-4 range, I nominate myself for removal from that role!

Sorry missed that. The number is not a hard number and you should more than I anyway. So we can be the number we are no Pb

Re: the workflow discussion above, those are the parts I generalized away as "magic" but they seem reasonable.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Aekez]

Sorry missed that. The number is not a hard number and you should more than I anyway. So we can be the number we are no Pb

yeah, and everyone here took part in building this place. It wouldn't feel right, like a big hole is missing if you stepped down awokd. Wouldn't want that, plus we all get along nicely :)

It also helps increasing our resilience by having more proper backups and being a handful people who can build a new community and transfer everything, if something should happen to the owner who holds the organization account in place. I would not willingly disappear without a word or giving over the ownership to one of you guys, but things can happen like getting run over by a car or other sudden accidents.

So we might want to think about this, what will happen in a scenario like this if I for example died in a sudden accident? Would it make a difference to the communities long-term survival/health after an accident like that? You guys can invite new owners for example, so it won't run out of owners at least. Is it possible for you guys to transfer ownership of repositories? If so, a new community can always be made, but it would suck if many know this address and have to get used to a new address, as well as links and references to this place. It'd be interesting if a will or something like that can be made in github, like if someone disappears, after a time it is automatically handed over to someone among the owners through github customer service, or something like that. I haven't checked if that is possible yet, I might get to it in one of these days to solve this issue.

A different approach altogether could be to make a new shared github account between owners, that holds the ownership, that way it's never lost. But having multiple credentials, would it be easier for a 3rd party to hack it for example? multiple hardware login's? Can a shared e-mail bound to the account be made in a sensible way as well? too much overhead work to do something like that and still keep it more secure? Thoughts?

[awokd]

Thanks @Aekez , I think because this is an "organization" with multiple owners the problems mostly go away? Not finding any special permissions you have as the initial creator of the site. I don't see any way to deal with a rogue owner other than not adding them in the first place, or relying on Github support to help recover the site in case someone deletes everything including other owners.

[Aekez]

@awokd you're welcome :) I think we got something pretty good here together, and it seems like we all get along pretty well, we just need to let it grow and evolve now. We have different personalities, views and takes on things, but that I think is very valuable for better discussions and by all means positive, considering that we all seek to reach a common ground. I think it's also apparent that we all share similar goals and values about this project. It also seems Qubes OS in general attracts similar minded people, so too does it seem that creating scripts/guides/docs and sharing this work, further narrows that similarity down, similar yet very different too. That, I think can evolve and become even stronger and better over time, being similar and different at the same time, makes the ties quite resilient and powerful, imho.

@Qubes-Community/administrators A concern I discovered today though, is something I've seen in different very new communities as well, is that we might end up tiring ourselves down by putting too much effort in. Maybe we need to be careful not to exhaust ourselves, that is probably the biggest mistake we can do about this project, it might also make one feel caught in time consuming responsibilities? Maybe we should slow down a bit, like Rom wasn't build on a single day. It might also tire us down if we have to be available all the time, like mentions or notifications always bip'ing. That @ mention is both a curse and a blessing here. The kind of project we're building here doesn't need quick actions though, or what do you guys think? Right now when we're building up this place, it takes many required interactions to be able to decide on how to it, but once it settles down a bit, then we can relax much more and slow down. Thoughts?

You raise a good point, other owners can do almost everything the final owner can, but it's still an administrative tier up, for example you can't demote other owners as an owner without the final owner? Not that I think that would ever be needed. But it's worth mentioning.

About the organization ownership, well I don't really want it, but I don't have an issue holding onto it either. If we find a solution at some point, then lets discuss it. It won't harm my feelings to discuss this (I mean I even discuss my own death lol). This is also a concern I carry my self, though it's not as if I expect to go and die or something. But nonetheless if the Qubes staff won't take the ownership (though still volunteer based right), then I hope this project to be independent and self relying in its ownership. So if Qubes staff doesn't accept it, then instead kinda like, community = ownership. I'm going to look into the international law and GitHub rules and guidelines and see what I can find later on, not right now though, but some time soon. If we do end up considering this like a real life organization, then this is also something we need to discuss, but it isn't a real organization right now of course. If we end up becoming a real organization and not just in name only, then it might be possible to make GitHub pass the ownership to one of the other owners if something should happen to me. Maybe that will be possible without turning into a real organization too, it depends on how GitHub run things. I don't mind putting in work here and bring the results I find up to discussions later on, working with organizations is somewhat what I study anyway, though I'm still far off being an expert in the field, so I will have to consult some books on this issue.

There is also the question whether the Qubes staff accepts the invitation to take part in this project, and that also potentially changes things. I gave Andrew a mail about this project around the time I put out the invites. He has replied that they will be discussing it. So this is also an element we need to take into consideration, there will probably be a time of chaos before we can settle down and relax much more.

I just hope we don't exhaust ourselves before everything settles down, that is my one and biggest worry about all this.

[awokd]

I think it's best to keep it simple at this point. No sense putting a lot of effort into something that may not get heavily used. And I saw you asked a question somewhere about adding more repos for discussions, but that just seems like over-complication to me. I can't even find where you asked that, for example!

[Aekez]

hah, that's a good point, I can relate. I've caught my self a few times today already asking "where the heck was it again". It'd be so much more simple if we had a forum for talking next to github, like a nice clean forum table where you can see everything from a single window before clicking on forums/sub-forums, which all have dynamic dates/time labels for new posts on the main window, rather than these segmented discussions that are hard to find. But lets not start a forum/github merger discussion now, as you said, lets keep it simple for the time being, I agree.

Perhaps we should name a single place as a primary discussion for the time being, so we don't loose track of the posts that are important?

[awokd]

Issues seems like a good primary place.