Of course everything could be put into the Qubes doc page. But first, it's getting pretty large and cluttered and will probably only grow bigger. Second, the Qubes doc page does not show on-going and un-finished work. The strength of seeing unfinished projects, is that we can help each others finish and test them. Scrutinize them for security issues and reliability issues, before they are considered for the Qubes doc page.
To solve an issue like this, it'd be helpful to have a place where we can keep track of everyone's projects which are shared for others to use. It may also be worth discussing on quality and security, and how we "censor"? bad scripts/guides/code. It could be done in many various of different ways, which is also why I think it'd make sense to open a discussion on the matter, so we can find the most preferred method. First though, a location might be ideal starting place, where to keep everything updated?
Initial thoughts
- A https://www.qubes-os.org/doc/ page listing all the unofficial projects. The most simple and easy way.
- A decentralized network shared links through wiki pages, linking from one to the next. Takes some work to maintain, but could be useful if properly done. The weakness is that it is very redundant and requires edits on every wiki page containing shared content in order to keep a network based source system up. A single maintained overview page would therefore be easier. The strength is that it builds up a stronger sense of inter-connected community and inter-awareness of each others github pages.
- An off-sight website which can build on unofficial content, keeping the Qubes official website clean from unofficial releases. The strength here is that more can be done to make answers to redundant questions more visible, and highlight unofficial solutions to which many people keep facing. The weakness is that it once more segments where Qubes users hangout, which might not be something we currently can afford. There are only about 30.000 Qubes users tops? and from them we often see the same people posting, and many of the new faces don't re-post very often. It would also require a reputation of reliability and trust, including carrying out these responsibilities too, on its own.
Generally the main concern is the visibility of the effort that the community puts in Qubes, from the bottom-up, often goes to waste and few people see's it.
Thoughts? maybe other new solutions or a modified one to one mentioned? I'm pretty sure there are many good ideas, opinions and insights out there, lets discuss this issue.
@Laszlo
I was indeed not aware of that page, it's pretty similar to the initial suggestion up above. (Thanks for linking it!). But there is a very crucial difference I think, it appears much more top-down focused than bottom-up, and also not focused on more every-day kind of issues. It's more focussed on directly Qubes related issues, and not so much issues which can make Qubes easier to use, more mundane things, and other things which might be very important to some people, but not everyone. It also has a single developer mindset, rather than inspiring people in the community to work together to archive a common goal. So it's both very similar, but also very different at the same time.
I agree it should still be possible to block dangerous or out-dated guides/scripts/etc., that's my opinion/view as well. But what is sought here is also a method not to exclude people who try to start something (many people have creative ideas, but are unable to carry it out or finish it themselves, and it disappears). Something can be started up, and then later need/seek help from others in the community to help finish it. Have critical eyes on the work from others, which might also make people more daring to do something, which may not be bashful, but a friendly community to solve issues in development, in a similar way how we solve personal issues in these mail threads. It can be much more risky for an individual to try build something alone, and then stick ones head out, than it is if the process is transparent and everyone can see how it works. Not everyone is willing to face such a risk, even if they got the skills to finish it themselves.
There is at least a good handful, if not 10 or so people around in these forums, who try to do something like this, but everyone are working alone. There are skill sets on vastly different degrees and types, but everyone doesn't need to have the same skills to be useful. A good example are Artists who can make artwork for Qubes content, or editors/writers/guide-makers whom usually would not write to a Qubes doc page, due to already mentioned reasons, or other reasons, it could be lack of time, or because the Qubes docs seem too official. I would make a guess here, that few people would want to post anything to a Qubes doc page if they didn't finish it up and make it pretty decent quality, before posting it. But that won't happen if low confidence/unfinished/lack-skillsets-and-need-to-work-with-others-to-finish-it/too-official/feels-like-it-must-be-finished-in-high-quality-when-uploaded.
I get there is a quality problem with something like this, but that's also meant to be part of the discussion, as how to solve something like that. Should there be someone to edit the content, so one one runs a dangerous or unfinished script by mistake, etc.
@[799]
I'm glad you feel the same way :)
If we imagine the github approach, any idea how we can keep an overview of all projects? Maybe a Qubes doc? something else? Also true with github, it was also a bit of a jungle for me the first time, and still is at times.
I like the off-site website approach too, I'm just worried that we're too few people to do something like that :/
Maybe we could make a shared chat room of a sorts, to discuss scripts/guides/etc. where everyone are welcome to join openly?
I think a Qubes Doc page listing the other projects in GitHub could be good.
It should not be too much work for the Qubes team to accept the pull request for updates to this page, which could be not too frequent. If they accept.
Other projects have an incubator section.
However, I think we need to spend a bit more time to try to add to this a bit of structure so that:
- It drives merger of projects from community member to help one another when they want to achieve the same goal
- It drives projects to have a well defined small scope
Maybe have some forced phases "requirements definition", security/arch, minimum value product1 (1st dev iteration)...
Great feedback Alex, I think you're absolutely right. Lets indeed not be hasteful and jump to conclusions, and try get a structure down first. It would be interesting to hear if the Qubes staff think this is a bad or good idea though, or if they're neutral about it. At least I'm not planning to keep going with this if they think it's a bad idea, all I'm trying to do is start a discussion about it to see if it's feasible to get it going or not, whether something like this is possible also depends a lot of peoples views and interest too.
Ultimately we also need to find out how we decide on these things, I'm not planning to take on any sort of leadership or anything like that, I'm only trying to get it going, and from there no more than a normal member. But it can't be all chaotic and random either. Ideas and discussions on this issue seems in particular important. Like the strategy statement for a vision you put forward in your post puts a leadership structure without a physical leader present, which is a good idea I think.
Whatever it ends up becoming though, it seems to me like a good call to let the Qubes staff have a final say, if something goes on that they think is a bad idea or think should change. I don't think many would disagree about that either. If we can establish rules and guidelines, but that they are subject to change by the Qubes staff. But how do we decide on them as a community, I feel that is a tricky issue and it might depend on how well each hypothetical leading system works from the kind of people be bring together. Some groups don't need leadership and can act cooperatively through culture and shared values/culture, while other groups need strong leadership with clear rules, and so on. It also has a size factor, and it might depend a lot on where in the world people come from too with cultural differences.
Perhaps a good guideline for most of the bottom-up approach's structure to follow the essence, rules and culture that the Qubes project itself follows and set for itself? Although with a more community oriented focus of course. So something like this?
Basic structure:
- Always subject to the Qubes staff's decisions.
- Adheres naturally to existing Qubes culture and rules, but with modifications to allow a decentralized bottom-up community based development.
- Modifications must make sense and be clear, and should be well argued as to why they are needed.
Maybe something like this as the basis from which we can build from? I think you make a strong point too, that we need some kind of vision or strategy, goal setting, I'll cite your words here as I think you pretty much nailed it.
Strategy vision - Goal setting:
- It drives merger of projects from community member to help one another when they want to achieve the same goal.
- It drives projects to have a well defined small scope.
The idea of forced phases, kind of like it's done on github when posting I suspect? It seems like a good idea, it gives some guidelines. We sould try make them flexible so they don't hinder creativity though. Maybe using a simple ranking system too? If we do something similar as to https://www.qubes-os.org/qubes-issues/ with the colored labels, just the difference being instead of being top-down based, a page discussed here would be bottom-up.
Maybe we could use drafts or something, so we can have better overview of the layout proposals being discussed.
I feel this is what you suggested too between the lines, that we should let this discussion go on for a while, so that more opinions and views and come in? I agree with that, there is no need for haste.
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.
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 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.
I will not be participating in any website or wiki of this type if people with zero qualifications are allowed to provide "advice".
There are quite a lot of people on this list giving literally dangerous advice or telling people not to bother with increasing their security with libre software/hardware because of vague theoretical backdoors...
I believe the minimum of qualifications should be having at least one owner controlled motherboard with coreboot/libreboot/OpenPOWER firmware.
As a starter rule I would also say that people who have gmail/microsoft accounts should not be allowed to comment at all because they probably have no idea what they are doing[1].
It needs to have a section for
-Questions & -Community Tutorials
at the very least.
The Kali forums is a great example of what a qubes forum should look like.
If the goal is to target people who have little knowledge of security and make them more aware, then how to do this is very, very different than targeting people that seek to maximize security as far as possible, and keep learning in order to do just that. Most people are the former, not so many the latter. But the point is, those who seek to maximize security, will keep seeking answers and keep learning, while the other group spend very little time and energy on security.
So the problem here, if the community is off-putting, rude, elitist, or heavily rule based, then you will scare off exactly the kind of people that needs quick information and help to build a stronger security, while it will take much more to put off those who seek to maximize security whom are likely to stay.
But here an elitist or iron tight rule based community is created, in contrast to an open, welcoming and culture based community. If the goal is to reach as many people as possible with proper security, then a balance has to be sought between these two extremes.
You would have to first put forwardd the question, who is the target group? Is it the people that seek to maximize security? or is to spread out and make people more aware and use better security?
Both can be achieved too, one does not exclude the other. But heavy use of rules and elitist attitudes will surely push anyone away who puts little time and effort into security.
If you want both, then a lot more effort has to be put into forming the proper culture and codex among the user-base, and this is often what community designers are either lazy or ignorant about.
A proper community archiving both, would have to be a constant process that keeps working towards building the community, and not some place that is set in stone and unchanging.
What is needed is contant effort, and not to become lazy or ignorant about the community, but keep working on maintaining the balance and quality.
I agree with your view that some checks and rules are needed, but what can be shaped and guided through culture, should be done through culture, not by rules just because someone likes and feel better about rules (people are different, and that's okay).
If a person wants to spread and increase awareness of proper security, but at the same time want to lock-down the community hard by heavy use of rules, then that person has a cognitive bias. So I want to ask, who do you tihnk is the target group? Spreading the awareness of security, requres the human factor/psychology/culture to be included.
Hello Alex,2018-03-04 11:49 GMT+01:00 Alex Dubois <bow...@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
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 approachI 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.
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 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.
[799]
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
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.
too much resources discussing this, but rather contribute directly
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.
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)
NASA is doing something similar to this for their research projects, although it does hinder their innovation, but it does increase efficiency on cost and reliability of projects, while still preserving some levels of innovation in it.
The point here, is that nothing gets through the process before it had proper review, it will only come through if it has a certain quality to it. If creators misses something important, or ignores vital security/reliability implications, this will more likely than not be caught in the review process. Also the review system could be made so that it can withdraw it's acknowledgments, thereby if anyone should ever finds a reliability/security issue, it can be taken back as well.
If people run un-reviewed or criticized guides/scripts, despite being warned not to, or to be careful and try to understand what the script/guides does before executing it, then if they don't do that, it's their own fault.
What worries me a bit, are self-fulfilling prophecies, by being worried about an issue, that the person essentially creates the issue by focusing too hard on it. Many of these issues we can solve, it's not rocket science, they're not impossible obstacles that can't be overcome. The problem though, is if some don't want to consider the whole full complete picture, and focuses too hard on their self-fulfilling prophecies. We need to take a step back and reflect more on a holistic and abstract level, before returning to the details again, and then constantly shape the big picture until it improves.
If guides/scripts are constantly checked and corrected every time someone finds a flaw in them, then what's the issue? Why is this issue blown so much out of proportion? We're talking about a review system no one else is doing on the internet here (maybe I overlooked it, the internet is massive, but it's not common knowledge at least).
Generally, the criticism that follow other poor guides/scripts on the internet, does not automatically warrant criticism of guides that are put through an open review system like this.
I don't want to see criticisms born from examples of other places, when a review suggestion is different from any of these places the criticisms are born. Lets be practical about this, we can't just move criticisms from one place to another, without first taking into account if the system produces the same issues or not. I'm not saying this to any particular person, but an attempt to try get back on the ground again, we're moving too far into the details without looking at the big picture. <-- if a person does that too much, they become legitimately insane as a result, so too a discussion can become insane too. We need some practical reality checks here and stay on the ground.
It's a bit of irony that wanting closed development by few developers only, kind of echo's the mentality of closed proprietary code, rather than the mentality of open source. The whole idea of open source code, is reviews and checks, this is just a shift towards doing the same with guides/scripts as well.
I mean, if anyone think the NASA approach is flawed, good luck trying to argue against it without some pretty solid reasoning. It's true that innovation is hindered some (but not totally), but they do manage to cut down cost and increase reliability. So too, the same should be for open community scripts/guides.
It'd be exactly the same NASA is doing for their development projects. Who is still saying it will produce bad guides/scripts? I mean, if anything, these checks do increase the reliability/security. Taking examples from elsewhere on the internet is futile and pointless, because no one (or very few) are doing the same as NASA is doing to ensure quality checks. And this is essentially what is being proposed here.
Hello Alex,05.03.2018 8:28 "Alex Dubois" wrote: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 infoValid points, I agree.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.I love the work of the Qubes Team, don't get to me wrong, but I don't understand why and how they could block the community effort to create a fork?
Some of use have already forked the docs and are currently developing their own improved scripts.Doing so in a collaborative and centralized way would be much better.But - I would like to see of course - that Qubes Team is also supporting this idea and knows about it.
One reason was also to indicate clearly which part of the documentation is official and thereof reasonable secure and which is unofficial and maybe less secure.I definitely like the idea of an index page / rating system.too much resources discussing this, but rather contribute directlyLet's go, I am ready to start.@David (in his role of the community manager):What do you think?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.Yes, but we have already some interested people here, I think we only need to discuss the approvement process and how and if of those ideas/scripts might be placed more visible (maybe as a link) somewhere on the Qubes website which is the main area for new users (?).
At least a link to it, with maybe a disclaimer:"Take a look what is happening in the Qubes Community.DISCLAIMER: the content there should be treated as work in progress and has not been reviewed by the Qubes OS Team and maybe thereof less "reasonable secure" or maybe even opening attack vectors to your Qubes installation.Even more if you implement a script which you haven't reviewed (and understood) and which has not been marked as meeting the Qubes OS quality standards.WARNING:If you implement changes in dom0 or the sys-VMs (sys-net, sys-firewall, sys-usb) this might result in a total loss of security"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)This is a good example, is there a disclaimer or security rating on the qubes-doc pages?
[799]
>> 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> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote:
>> group can include Qubes OS Team, but also experienced community members
>> selected by the Qubes Team/David)?
>
> 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 <bow...@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
[799]
I see, that is a very good point, I agree fully with you.
So if I understood what you meant correctly (github terminology is tricky here), so a sense, we could have a single github (the official Qubes one) and a single repository as well, but within it have 3 different folders for 2 different pages, and another one which won't appear on any page but stays unofficial on github. This is what you meant?
I don't think it's an issue to have two pages appear on the Qubes website (Qubes doc's and Community doc's), sourced from 2 different github folders, that's how you see it too I suspect? So it's a question if different people can have different permissions on a pr. folder basis, which automatically? changes what appears on the websites doc page. So I end up with such questions as well, is permissions here doable on a pr. folder basis? Does Github allow such micro-managment? But I suspect Andrew might know the answer here.
It might be possible to move the whole guide file(s) as well with minimum work. have you tried fork your GitHub to your local harddrive awokd? It looks a lot like a simple folder/file structure, where moving files should be all it takes? As long as internal depending links and addresses are corrected, but if keeping the structure in-tact then I don't think that be an issue. The limited time I used GitHub, I think it's just a matter of moving it from one folder to another folder, in a sense a very basic but flexible system. But I might be too naive here? If true, then I believe it should preserve everything in the doc, formatting, code, size, fonts, everything, even if it's moved from one folder to another folder. But I'm not 100% sure either if that is how GitHub work here.
I did in my previous mail refer volunteers as moderators and not volunteers as community developers, maybe it's better to temporarily call them volunteer moderators to avoid mix-ups when discussing. Separating the volunteer moderators in two tiers as well maybe? The Community driven volunteer moderators must for example have better insight in what makes a guide a good quality, a good understanding of security, etc? While the trial and testing volunteer moderators requires less quality-checks and is more focused on managing the new ideas coming in from different GitHub sources (the communities own GitHub pages), and poking and turning stones to bring forth unseen perspectives.
So something like this?
Categories:
- Volunteer developer
- Volunteer moderator, tier 2
- Volunteer moderator, tier 1
- Qubes Staff, tier 0
Official Qubes OS GitHub maintenance
- Qubes Unofficial trial and testing grounds. (Tier 2 - Volunteer maintained)
- Qubes Community doc's. (Tier 1 - Volunteer maintained)
- Qubes Official doc's. (Tier 0 - Qubes staff maintained)
Qubes website appearance
- Qubes Official doc's
- Qubes Community doc's
Let me know if I misunderstood you. I'm still grasping the proper terminology, as well the limits and possibilities of Github, so it might be easy to misunderstand.
We gotta conquer GitHub! :)
So the suggestion is having all the volunteer stuff on a separate repository, but the two sub-set volunteer categories to be separated within that repository? Making it more cut and clean etc.?
I believe it should be easy to move between repositories on a local drive, but I only experimented with this for a short time the other week, so I'm not 100% sure on how it works yet. But essentially we can download all GitHub content to our drives, perform changes, and then commit it back up to GitHub again.
I believe this can be done even to GitHub repositories one has no authority over, but it'll instead be a, pull request? On the other hand, if one has the authority, then it'll immediately change the GitHub content. We can login via the terminal too, and keep our GPG keys on a SplitGPG AppVM.
So by having two different repositories on our local drives, it should be as simple as copy/paste the whole folder/file structure, or individual files/folders, from one repository to another repository?
Maybe this can be done online too on GitHub? But it seems we can do more if it's taken down to the drive, another example is changing the Home wiki page, which is more flexible if done on the local drive. I think maybe moving between the repositories, might be one of those better done on a local machine too?
I'll have to get back to that experimentation sometime soon. Maybe someone else can confirm if that is how it works in-between then though?
Using this guide as a common ground https://help.github.com/articles/about-pull-requests/
Pull requests could serve as a trial and testing grounds on a volunteer repository? Maybe this is what you meant all along and I misunderstood. But that does indeed make it much more simple.
It seems like a good way to do it, I like it. What does others think about it? It might be a good idea to have some finished thoughts / discussions ready for Andrew, it'd be inhuman to expect him to read everything (it's a lot to read). Does anyone disagree with the idea of making an initial first step with a second repository with an associated Community doc page, as discussed? We can always look at forums and other platforms later on, it's probably best not to do everything at once, especially now when the Qubes staff is busy, it might be best to start where the least work is needed from the Qubes staff. A second repository and assigning volunteer moderator(s) should be straight forward less than 5 minutes task (This is assuming this is also approved by the Qubes staff of course).
It would feel bad if causing you trouble rather than helping, I hope we will be able to provide help :) I can only speak for my self, but I believe others feel the same, feel free to correct us if we're doing something wrong with this community project. <-- when I say "us", it is based on my belief, but as said I can't speak for everyone. I mean, it would be horrible if we impacted Qubes in a way that you guys didn't like, after all the amazing work you guys did with Qubes over all these years, you guys essentially poured your souls into this. Consider to bring out that whip if something is off!
If I interpreted this correctly, my understanding is that it's preferred that a community like this to have an inviting GUI platform, so that it can easier gain traction and build up users, and include more people? i.e. github is not desired for the central community environment?
Maybe we could beta-run a volunteer run GUI based platform first before you decide if it should be made official on i.e. recognized on the Qubes website with a link? testing the waters a bit by dipping the toe in, before taking a full dive. With only some platform volunteers aware of it at first to test it? If it works, then we can always scale it up, or if it should fail, then change direction or start-over with a new discussion. Something like that, a beta run could be insightful before any final decisions are made.
I hesitate to use the forum word here, perhaps a new fresh discussion is warranted as for which platform to use? But if GUI is an important factor to include, then a forum might be the most suitable? There will always be some who don't like every platform though. But did I understand it correctly that the Qubes staff actually likes the idea of a forum, but just doesn't have the man-power to run it? i.e. if you had the volunteers, then this is a desired platform/direction seen by the Qubes staff to go? Maybe preserving the mailing-lists, but integrating a forum where a forum makes sense, and then keep the mailing-lists as they are now and have them coexist?
@[799] & Ivan
The good thing is as Ivan pointed out too, that it seems I misunderstood the analogy :) I like the github platform version as well for this community goal, though both platforms have their pros and cons of course.
Maybe we could start linking to each others github pages to get an initial network up? It's a lot of work to maintain in the long run though, but it could help us be aware of one another that way in the beginning? Before we later maybe get a page or something somewhere showing all the different channels with a brief introduction each? Maybe we can draft a single wiki page somewhere to make it more efficient? or wait, maybe we can even fork this with github? A master branch where multiple of long-term community users with master access can help moderate the github wiki list? Should be possible this way?
Thoughts about collecting an initial unofficial github list, get an overview, and start looking at the projects out there, to get started?
Tbh we're at a stage where we have to hunt down and copy/paste everyones github page to a private list at this point in order to keep track. It'd be better if everyone wanting to do this can write their github page, i.e. in this thread with words that they're into this idea, in a sense signing up for this community co-awareness with a github link posted here, so that those not interested don't automatically get included.
Apologies Andrew, I should have put the question more clearly. What I mean is if we have two pages, one for Qubes doc's, and another for Qubes Community doc's, where will the Community doc's be, in an official sense? I'm fully with you regarding the Qubes doc's, what I'm wondering about is the page listing all the Community doc's which are not ready to be moved to Qubes doc's yet. Should the Community doc page be kept off-site? or is it okay to have it listed (in a similar logical sense to current-testing and unstable repositories, just unstable and current-testing guides instead).
It doesn't matter if you prefer to work alone or in collaboration with others. This is also an opportunity to increase awareness of your work. The list strictly only purpose is just that, awareness, while work-style is a separate matter.
Knowing about someone's github account does not justify putting it on the list, please sign up for it so that we don't put anyone on who does not want to be on it. A simple search can show many Qubes OS wiki's, like https://github.com/search?utf8=%E2%9C%93&q=qubes+os&type=Wikis however it's not the same as agreeing to be on an awareness/promotional list.
A small description/introduction can be added to the list later, or now if you like to do that. Please keep it short though if you do, i.e Twitter/SMS post size description, slightly bigger than that should be okay though. The idea here is that introduction/descriptions can be updated later.
Copy/paste the list here (ABC) if possible.
Yuraeitha - https://github.com/Aekez - Right now not much has been done, however QubesTV is starting to take shape. Other repositories are currently work-in-progress.
Found this;
Organizations include:
- A free plan with unlimited collaborators on unlimited public repositories
- The option to upgrade to paid plans with unlimited private repositories, sophisticated user authentication and management, 24/5 support, and a service level agreement for uptime availability
- Unlimited membership with a variety of roles that grant different levels of access to the organization and its data
- The ability to give members a range of access permissions to your organization's repositories
- Nested teams that reflect your company or group's structure with cascading access permissions and mentions
- The ability for organization owners to view members' two-factor authentication (2FA) status
- The option to require all organization members to use two-factor authentication
Source: https://help.github.com/articles/differences-between-user-and-organization-accounts/
Works for me, I'll only keep it for the sake of getting the project running, I won't actual own it. I also prefer if a Qubes staff member takes it over, but we'll see what happens.
Name changes seems easy too, at least if not too many project links has been created. https://help.github.com/articles/renaming-an-organization/
So we can take our time to settle on a name.
I'll use something default sounding as the initial name, "Qubes Community Collaboration".
Here's the link
https://github.com/Qubes-Community-Collaboration
I invited you both as owners, so you have administration access as well.
What does everything think about it?
Assuming we go on with this organization layout, we could also need a logo for it, do we have any artists in our midst who want to bring up some logo design suggestions?
It seems we can make team discussions too for particular projects, this might make it less messy if others are not interested in different sub-discussions. I'll try set a few examples up we can look at.
Awesome, I'll go right there and read/reply :)
I also just made this example, doesn't have to be like this, it's just a layout. https://github.com/orgs/Qubes-Community-Collaboration/teams
It allows for team discussions too, as well as allow community members to find who specialize in what, so that requests can be made. Thoughts?
Apologies, we decided to shorten the name a bit, the collaboration is in the sub-title now instead. It can be found here https://github.com/Qubes-Community
Once the name and base structure is agreed on, then changes like this shouldn't happen again for the sake of connectivity, like just now, when the link stopped working. Can you see it now? :)
Apologies, we decided to shorten the name a bit, the collaboration is in the sub-title now instead. It can be found here https://github.com/Qubes-Community