That is very true, and I completely sympathize with needing to compartmentalize the high priority and actionable tickets so you don’t drown. Going by personal experience, I don’t think any place I’ve worked has managed to settle on a healthy way to deal with backlogged tickets, so I definitely shouldn’t be throwing stones. If it works for you all in the Qubes team, it’s the right approach!
I hadn’t seen that section in the documentation, but I’m glad that the intent of the open/closed state is explained somewhere. This is partly on me for not reading the links in the README of the qubes-issues repo
In part, for me at least, I think the knee-jerk reaction towards the “closed” status comes from associating it with less friendly open-source projects from the olde bugzilla days dismissing bug reports “CLOSED-WONTFIX” without any context. To be clear, the github-actions bot does leave a very helpful explanation when closing tickets that clarifies the situation. This helps a lot. Still, the cognitive bias is hard to shake after being in the open source community for so many years.
I do think there is an inherent discoverability issue for closed tickets (for us users), only due to how the Github UI emphasizes open ones by default. Though, as mentioned in the documentation page, you do encourage users to search for both open and closed tickets. I will definitely try to remember to do that from now on.
(By the way, thanks for your welcoming comment on that #6589 ticket from last year, and trying to point me in the right direction in the dev docs. Though, as mentioned, I sadly never got around to delving into it, with life getting in the way Then again, it’s the very definition of a low priority ticket, so I’m not too fussed about it stagnating.)
Simple tool tip for installer saying something like:
“You don’t have any USB device attached so the installation can proceed. But, you have USB controllers. Please consider to create sys-usb. For more info please refer to The Invisible Things Lab's blog: USB Security Challenges”
I discuss some “things we want to express” (which could translate to your “groups of visual ques”), here:
I do like your qube properties based idea though. If i could still edit the above post i’d probably add “indication of which sys-firewall-* qube it was using” (or more generally, what qube it’s using as it’s network qube).
One option could actually be changing the window title from something like [work] user@work: ~
(for a terminal) to something like [work via sys-firewall-wifi] user@work: ~
or [work via sys-firewall-only-my-bank] user@work: ~
or [work with no networking] user@work: ~
Yes please! It’s so hard to have to trawl through forum posts to try and figure out breaking issues and if they are fixable or we have to sit and wait.
I’d also add better treatment of the stable release. It feels like it’s just not cared about when you look at issues like the current breaking updates or security updates where it tends to be along the lines of “those of you on testing you are good, for the rest of you on stable, godspeed, you’ll get the fix eventually”
I’m curious why you have this impression. Is it because you think there’s too long of a time gap between the fix going into testing and that same fix migrating to stable, or is it something else? The consequences of moving fixes from testing to stable too quickly can be very bad. We had that problem years ago, where “fixes” that broke more than they fixed were pushed out to all stable systems without sufficient testing. We learned our lesson from such experiences and created the testing repos in order to avoid repeating the same mistakes. If you want, you can enable the testing repos on your own system, then you won’t have to wait as long. There is an inherent trade-off here between speed and stability, so you have to choose which you wish to prioritize.
It feels quite contrary to other distributions where typically announcements are only made when patches are available for stable, especially when it comes to security patches.
All the qubes security announcements that I can recall are as I mention. “fixed in testing, available in 2 weeks in stable”
I don’t particularly want to have to run testing but I would like to be able to apply security updates when they are announced
I can understand - but what are the options?
If the announcement were made when the package hit stable then it would
look as if Qubes were slow to respond.
Generally, its good to be able to have some testing of packages before
they are offered to general users.
Also, there are people who use testing just so they can evaluate
packages in testing - it’s useful to tell those people when there
are such packages.
And finally, there are repositories for “update candidates”, and
“security updates testing” - you could enable just the security updates
testing, if you cannot wait for the migration to stable.
Interesting. I suppose it would be possible to publish QSBs on GitHub immediately but delay the announcements on the website, forum, mailing lists, and social media until the packages hit stable. That feels a bit weird, though, like hiding information from you for your own psychological comfort. On the other hand, I suppose it makes sense that announcements should be actionable for the majority of users who read them. But then again, most QSBs don’t require any special user action. Just “continue updating normally.” I’m also not sure how people would react to such a change. I can imagine the majority of the userbase hating that and preferring the current way we do it. I can also imagine the opposite.
Besides, even if we were to do this, it’s highly likely that some users would take it upon themselves to post their own unofficial announcements here in the forum whenever we quietly published a QSB on GitHub. That already happens now, even when we publish timely official announcements for things (recent example). So, you’d likely end up in a situation where you’re still forced to become aware of security updates before they’re in stable, except you’d probably receive a potentially less-informative, less-reliable unofficial announcement at first and have to wait longer for the official one.
If you don’t want to use security-testing updates (which is completely fine), why don’t you just continue updating normally and get the updates when they hit stable? Or, if you’d rather have the security updates as soon as they’re available, why don’t you just enable security-testing but not any other testing repos? If none of these options sound good, I think it’s because what you want is just fundamentally at odds with the nature of software development. There’s an inherent trade-off between stability and speed. Since testing takes time, you can either have faster updates that are less tested (less stable) or slower updates that are more tested (more stable).
The more I think about this, the more odd it seems to me. I would think that one should decide whether one wants to use only stable or some combination of testing repos, then one should update regularly from there, regardless of any announcements. One would then get the security updates whenever they’re available in one’s chosen repos. Why does it matter if the date of an announcement differs from the date on which the attendant patches are applied on one’s system? One already considered that when deciding which combination of stable and testing repos to use. The timing of the announcement doesn’t change the facts on the ground. The vulnerability is out there, and the fix is either applied on a system, or it is not. The user’s cognizance of the situation doesn’t affect this. Not wanting to hear about a vulnerability when a fix is available just because one has chosen not to apply the fix yet seems analogous to wanting to stick one’s head in the sand or close one’s eyes in order avoiding seeing something dangerous.
I am not a UX designer so this is entirely non constructive criticism, but the out of the box look just… feels like an old operating system. Something that is supposed to be used and made by people who got accustomed with their ideas of how computers are supposed to look and work some decades ago. I know that there are workarounds and stuff and this is a OS for power users mainly, but the simple out of the box appearance is one that limits the accessibility.
This feels like a bad thing to say because I don’t actually know how to make it better, but I feel like with some tiny twists the out of the box experience might become a lot easier.
On the other hand I kind of like that aspect, that setting it up is a lot of work and personalization and figuring things out. I like that as a hobby. But I feel like with some general redesign it might save a lot of clicking through menus for those users who are not willing or able to change much from the out of the box design.
accessibility as in allowing disabled people to use the system?
this could be improved indeed, but Gnome or Plasma wouldn’t help much in that regard
if you want to start working on it, you could analyze the current UX
write down each simple tasks a user may have to do, describe the steps, see if there are any extra useless steps or if some steps could be made easier / factorized across different tasks.
Then again, it’s the very definition of a low priority ticket, so I’m not too fussed about it stagnating.)
qube with HYPER-V enabled.