Hmm, looks like a problem. @adw is there a roadmap, like a list of new major features that are planned for R4.3 for example?
I know that work with wayland is in progress. It is huge, difficult and inevitable migration that will not give explicit joy to users, because in the best scenarios they should not even notice it if everything works in their Xorg installations. And it is not clear will it be implemented for R4.3 or in some distant future as the task looks quite hard.
But what else?
How about an idea to publish plans for new features of R4.3 in advance? Maybe not everything will be done by that time, or something will be added, but at least users will be waiting for this new or better stuff and care more for new releases.
Don’t the release notes state what’s changing?
Granted, the “why I should care part” is more difficult.
Unfortunately, there is not. My guess is either that it has not yet been determined or decided, or it exists only in @marmarek’s head.
I think the closest thing we have is just keeping an eye on the Release 4.3 milestone to see which issues @marmarek adds to it over time.
There have been requests and attempts to have a public road map and related things:
However, these never really went anywhere. My guess as to the root cause is that @marmarek never had the time for them, and/or other things were always more important.
But all this talk about 4.3 is a bit puzzling to me. I thought we were talking about 4.2 testing.
I see, it would be great to have roadmap at least for the next major version. Otherwise it is not obvious where Qubes OS is moving.
It can be also affected by public users’ vote, e.g. of forum to avoid additional registrations. What do you think about it? Not decided, by still affected to reflect what users what better. Maybe it will drag more users to testing new releases.
I also would love to promote my qubes-completion to the milestone of R4.3
This has come up before. While it sounds like a nice idea in theory, it typically doesn’t produce great results in practice, because there tends to be a significant gap between non-expert user opinions about security and the complex reality of security engineering. The result tends to be a product that caters to what users say they want rather than what will actually keep them most secure.
Yeah, your logic makes sense to me.
Yet, I remember there were votes about new start menu, was it effective?
Maybe this voting could still be a thing even if the voting options and interpretation of results will be strictly limited.
Ah, yes, we do occasionally conduct surveys when there is specific information that the developers wish to gather. It can be quite helpful for the developers to know how users actually use Qubes OS in practice, but this is quite different from asking users what they think we should do in the future. Of course, there’s nothing wrong with users sharing their thoughts and opinions, and the developers are (usually) happy to hear them. But holding a vote for the roadmap would give people the wrong impression and set the wrong expectations. For example, if the vote were overwhelmingly in favor of something, and the developers decided not to do it, then a lot of people would be upset, even if the developers were actually right not to do it because it would be worse for users. Now, you might say, “Well, if the developers were actually right, then they should be able to explain why they’re right in a way that people can understand.” That may be true, but it would also suck valuable time away from actually developing Qubes OS and cause all sorts of social turmoil in a way that’s entirely avoidable.
This type of feedback and transparency may be beneficial for both parties.
Unseen doesn’t mean avoidable.
If “something” is desirable by users and the decision goes other way, especially without explanation, it leads to more than just “upset”.
Along with loss of trust, potential users etc, it may lead to bad decisions that will echo in the future when it will be too late, cost-effectively speaking.
@Zeno : did you follow the “Dom0 running Fedora” threads? and the passwordless sudo discussions? Both cases are a clear indication that the user base will never determine the slightest change in Qubes.
Yes, you can read about the rationale for that here.
I’m afraid the answer is basically just GitHub, mailing lists, this forum, and chat rooms. Even I don’t have more insight than that. Aside from what you see there, there isn’t really any place (besides the developers’ brains) where this information is stored and accessible.
Voting is not the only way to provide feedback. You are welcome to provide feedback here on this forum and on the mailing lists where the developers can see it. If you present sound arguments, you can help prevent the sorts of bad outcomes you describe.
The developers may not have agreed with you in those cases, but it does not logically follow that “the user base will never determine the slightest change in Qubes.” The entire history of the project consists in the user base making changes in Qubes. Every user contribution that has been merged over the years is direct evidence of this.
