On Thursday, March 1, 2018 at 8:48:35 PM UTC+1, Alex Dubois wrote: > On Thursday, 1 March 2018 11:47:13 UTC, Yuraeitha wrote: > > On Thursday, March 1, 2018 at 1:31:50 AM UTC+1, [799] wrote: > > > Hello Yuraeitha, > > > > > > > > > -------- Original-Nachricht -------- > > > An 28. Feb. 2018, 21:39, Yuraeitha schrieb: > > > > > > > It seems from time to time that various > > > > people have shared a good unofficial script, > > > > guides and 'how to's', and even code, for > > > > Qubes related content, on their github page or > > > > similar. The problem however is that while > > > > shared, it isn't very visible, and even if they are > > > > from time to time mentioned in a mail thread, > > > > it quickly gets buried under many new mails. > > > > > > I have recognized the same and was wondering already what could be the > > > reason that people have written own small projects which I only knew of > > > because following this mailing list. > > > Honestly I started the same, after coming up with the first draft of ma > > > qvm-screenshot-to-clipboard script. > > > > > > The main reason why I didn't upload it (yet) to Qubes docs: > > > > > > 1) it is on a very early stage and while it is working I would feel a bit > > > ashamed, as there is no error handling etc. > > > > > > 2) I am unsure if the script is not only working but also "reasonable > > > secure" to use > > > > > > 3) I like the quality of the existing Qubes documentation, but it takes > > > some time for a newbie user not only to write a good how-to but also > > > include all the valuable feedback or keep the discussion ongoing. > > > > > > Maybe those are the reasons why others like to keep developing their > > > stuff outside of the Qubes doc repository. Summarized: > > > > > > 1. Scripts are not yet ready/to basic > > > 2. Unknown impact on security > > > 3. Not enough time to craft a quality "product" > > > > > > > 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. > > > > > > Yes, please! His could also be a good ressource to browse looking to > > > fine-tune Qubes. > > > > > > > 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? > > > > (...) > > > > A https://www.qubes-os.org/doc/ page listing > > > > all the unofficial projects. The most simple > > > > and easy way. > > > > > > I like the idea having it available at GitHub as we can easily contribute > > > to the code and GitHub has all the features to keep discussion ongoing > > > etc. > > > It is also allows to keep a copy of the latest version of the scripts and > > > people don't have to learn another tool when their code is ready to be > > > released. > > > > > > The bad thing: > > > If you're not a developer and have never worked with GitHub the learning > > > curve might be high. > > > At least I had to click some time arround to understand what is located > > > where and how it is working. > > > > > > > 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. > > > > > > The other benefit is, that I learn a lot from reading other person's > > > scripts and of course following the discussion. > > > > > > Maybe some of the ideas there could also be mentioned in a maybe monthly > > > blog post, so that new users can see that Qubes is a living project. > > > > > > I would call this site/place where all the ideas are summarize "Qubes > > > Garden" or "Qubes Playground" :-) > > > > > > [799] > > > > @[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. -- 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/f8ad1aee-22c8-4483-b1c7-88db7b8c6c90%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
