I’d say that compared to some, my “pushing of the brand” is non-existent. The only thing I do is host Qubes material on GitHub, and a server provided by a supporter of Qubes. I rarely reference them or promote them.
I think your insinuation was unpleasant and uncalled for.
To the matter in hand:
I havent tried to “close down” concerns raised in the thread. I did try to close down the initial concern raised by @jagnopurka because it was based on a misunderstanding. You did much the same in your initial response.
The thread has moved on to other matters. I tried to directly address some misunderstandings, or things I found misleading.
Among other matters raised:
Risks of “losing” core contributors
Lack of funding for team
Lack of funding for contributors
Issues remaining unfixed for a long time.
Issues and PRs often remain unanswered.
Difficulties in getting involved
complexity of code arrangement
lack of developer documentation
lack of simple build instructions
Hard to reach core team
Lack of a clear roadmap.
Lack of perceived “core” features:
incremental backups
GPU acceleration
working dark theme
Problems with video-conferencing
remote management
Difficulty of commercial deployment
Issues with Qubes using GitHub
Proposal to fast track upstream committers and maintainers to have commit access to Qubes.
Thats pretty wide ranging, and I undoubtedly missed some things. Let’s break it down in to manageable chunks. I’ve tried to deal with some already.
For issues with GitHub, I’ve offered a proxy service to allow people to contribute without touching GitHub, and it’s also possible to email in diffs for changes.
Discussions about aspects of the design, code arrangement, contributing features, and build documentation should take place on qubes-devel. An alternative proposal - create a specific category here in the Forum for development, where these things can be discussed. We can share problems, experiences, solutions, and so on, and that can feed in to improved developer documentation. @alimirjamali’s project to clean up qubes-issues should be encouraged and you could join. We did something similar on the transition to 4.0 and made inroads in to the issues then. It’s undoubtedly time to do it again.
These may help overcome some of the barriers to entry.
Qubes need contributors, both on documentation and code. There’s a current thread on becoming a Qubes developer with some good ideas: take a look at that, and dive in. Be realistic where you start. Dont try to rewrite the whole doc web site - you can start with a single page or a single image. Dont start by trying to build the whole system - start with a single package. Look at open issues one by one. Whatever you can do, you can make some contribution, and help improve Qubes.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
It was substantiated and important to me as a user. I’m pleased to learn there’s nothing in it. I apologize if this was out of proportion compared to what other people are doing - I wasn’t aware of that.
I’m going to leave it there. I think I’ve been clear enough about my views on contribution, and that discussion can carry on in other places.
I’m happy to do that explicitly at least once. I wouldn’t be here if I didn’t think it was great. What we all want is for the great things to survive and spread, which is why we raise issues.
Would it be possible to have an up-to-date task list of what actually needs to be done, so that a newcomer may start contributing fairly quickly without having to acquire a mountain of knowledge?
What I mean is: Looking at ~2k issues is not encouraging that at all (especially when there are “critical” ones from 2015). One would rather get lost in that and give up in 10 minutes.
Example:
fix typos in doc X, Y, Z (required skills: English language)
refactor code in files A, B, C (required skills: Python)
create a script for … (required skills: shell scripting)
create functionality for … in … (skills: C, …)
etc
Individual tasks may be linked to actual issues or milestones and a project manager will check each fulfilled task. Contributors may receive some kind of reward/score for each successfully fulfilled task, so they are recognizable in the community for their contribution. Based on pre-defined thresholds a contributor may receive extra rights, e.g. to add items to the task list and so on.
I tried to prune a bit the thread and move the off-topic ‘JS issues’ discussion and the wayland one out of here. Please do keep the discussion on topic, everyone. Thank you .
From my perspective, I found this part of unman’s response reasonable, inoffensive, and worth answering (which I did). Some communication issues here do give me cause for concern about the project quality, but standard/style of English definitely isn’t one of them.
Maybe OP wanted to subject this topic as “How many people are paid regularly/monthly for working on Qubes OS, regardless of results/contribution”? If not, then please split the topic with such a subject, if needed.
.