Why is Qubes OS project team so small?

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.
5 Likes

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.

It was not substantiated, and you should not suggest it was. However, I accept your apology.

Besides raising issues we need people who will contribute, in any
capacity. I suggested areas, and made some proposals to move forward.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like

Besides raising issues we need people who will contribute, in any
capacity. I suggested areas, and made some proposals to move forward.

@unman

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.

There is a help wanted label on GitHub: Issues · QubesOS/qubes-issues · GitHub

1 Like

There’s also the good first issue label, which is currently on only four issues.

1 Like

None of these 2 links is quite what I mean.

Well, there’s also the Current team tasks board, which shows what the team is actively working on at any given time.

Well, there’s also the Current team tasks board, which shows what the team is actively working on at any given time.

Shows an empty page in Tor Browser with JS disabled.

1 Like

3 posts were split to a new topic: Are there plans to move to wayland?

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 :pray: .

3 Likes

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.