Hi, folks. So something came up in passing at the QA meeting today which we agreed to discuss here.
We added a criterion for Fedora 21 Final:
"All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy."
https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_Launc...
that policy includes this:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha channel and a matching High Contrast icon."
so effectively any default-installed app in Workstation lacking a high contrast icon blocks the release of Fedora. We do indeed have two such bugs on the current blocker list:
https://bugzilla.redhat.com/show_bug.cgi?id=1160499 https://bugzilla.redhat.com/show_bug.cgi?id=1130794
someone at the meeting wondered whether we really want to block Fedora releases for this, and mclasen said:
<mclasen> I don't think it justifies blocking the release, tbh <mclasen> but it is nice to have some pressure for getting those gaps closed
We're quite strict about not using the blocker process for this kind of thing these days, and I still think that's the best policy. One of the problems we identified with the old blocker process back around F12-F14, when we solidified the current process and added the "freeze exception" (at the time, "nice to have") concept was that (ab)using the blocker list as a list of 'priority' bugs meant no-one was really clear on what bugs would actually literally block the release, and what bugs would just be hand-waved when it came time to decide whether we shipped.
Since then we've stuck to the policy that only bugs we would actually delay the release for go on the blocker list, and I think that's worked out well and we should try to stick with it.
So with that in mind, can I ask if we really want to block Fedora releases on high-contrast icons? If the consensus is 'yes', then fine, no need for action. If 'no', then we'd need to amend either the release criterion or the Applications and Launchers policy in some way - for instance:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha channel and SHOULD include a matching High Contrast icon."
On Mon, 2014-11-24 at 11:52 -0800, Adam Williamson wrote:
Since then we've stuck to the policy that only bugs we would actually delay the release for go on the blocker list, and I think that's worked out well and we should try to stick with it.
I absolutely agree with this.
So with that in mind, can I ask if we really want to block Fedora releases on high-contrast icons? If the consensus is 'yes', then fine, no need for action.
Well, the blocker is not that "app X needs a HC icon," the blocker is "app X with no HC icon is installed by default," which really should never be the last blocker left before final release since the affected app can be dropped if no icon materializes.
For F21, we obviously can't (or don't want to) remove anaconda, or fedora-welcome, or setroubleshoot (well honestly I was kind of hoping for that one to be removed :), so this time around the criterion was a credible threat to delaying the release. But that's just because the criterion is brand new. (Maybe it was a mistake for it to have applied to existing apps.) Going forward, this criterion only prevents us from introducing *new* applications to the default install if they would cause our high contrast coverage to regress; it will never again impact critical apps like anaconda (unless perhaps an icon is lost by accident, which ought to be easily-fixable). So when this issue occurs again, it will be because we decided to add a new app to the default install (or the app somehow was added inadvertently), and the WG will be able to close the blocker bug by dropping the app from the default install, rather than risk delaying the release. (Or it could choose to delay the release if the app is really insanely desirable.)
So my opinion is yes, blocking on HC icons is fine. But if we don't want to, we can just change the relevant point in the applications and launchers policy from MUST to SHOULD.
Michael
On Mon, Nov 24, 2014 at 12:52 PM, Adam Williamson adamwill@fedoraproject.org wrote:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha channel and SHOULD include a matching High Contrast icon."
I'd like to think a matching high contrast icon can be done inside an hour, and if not, then not knowing anything else yes I'd block on it.
The requirement is not new, and it is reasonable. I'm not an accessibility expert, and I don't know if Fedora is explicitly targeting those with vision impairment and how well we do across the board with respect to accessibility: i.e. if our accessibility grade is a poor/below average, then it's probably not block worthy; if Fedora otherwise scores well in accessibility then it's worth blocking on.
SETroubleshoot is probably a required application so we can't give it the boot. If we could, then I'd say "24 hours to hand over the high contrast icon, or the application is off the Fedora 21 train".
For Fedora 22, there needs to be a more formalized application qualifications being met before the first Beta TC. Something like, all applications are out, until they've ticked off the entire list of requirements; and only then do they appear as default applications.
On 11/24/2014 04:37 PM, Chris Murphy wrote:
On Mon, Nov 24, 2014 at 12:52 PM, Adam Williamson adamwill@fedoraproject.org wrote:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha channel and SHOULD include a matching High Contrast icon."
I'd like to think a matching high contrast icon can be done inside an hour, and if not, then not knowing anything else yes I'd block on it.
Wouldn't that be nice if things were that simple?
~m
On Mon, 2014-11-24 at 14:37 -0700, Chris Murphy wrote:
The requirement is not new, and it is reasonable.
Factual point, it is new. We dropped the old polish criteria several releases ago, and even when we had them, they did not require high contrast icons, only that there was a default icon of sufficiently high resolution (the exact wording was "All Applications listed in the system menus (or equivalent) must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry").
On Tue, Nov 25, 2014 at 10:37 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2014-11-24 at 14:37 -0700, Chris Murphy wrote:
The requirement is not new, and it is reasonable.
Factual point, it is new. We dropped the old polish criteria several releases ago, and even when we had them, they did not require high contrast icons, only that there was a default icon of sufficiently high resolution (the exact wording was "All Applications listed in the system menus (or equivalent) must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry").
OK "new this release" vs "new this week"; I'm pretty much assuming most everything is new for Fedora 21. But the originally cited guidelines are not new this week, they were approved three months ago. That's what I meant by not new.
Adam Williamson wrote:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha channel and a matching High Contrast icon."
Fwiw, I personally disagree with the last part about requiring a matching HC icon (which can easily be fixed in an update).
That said, the policy only affects the *menu*, and I don't consider either anaconda or setroubleshoot to be typical applications, so -1 to considering either bug a blocker.
-- Rex
On Tue, Nov 25, 2014 at 2:30 PM, Rex Dieter rdieter@math.unl.edu wrote:
Adam Williamson wrote:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha channel and a matching High Contrast icon."
Fwiw, I personally disagree with the last part about requiring a matching HC icon (which can easily be fixed in an update).
I would argue that if it's not visible to a partially sighted person during install how are they to actually get the release installed. Unfortunately for someone that actually needs high contrast to make a system usable it's not really something they can do without to begin with and update later, it's not like some other features that can be fixed easily with an update (like say a web cam or a peripheral driver) because it likely affects the persons ability to actually use anything from the outset.
Peter
On Tue, Nov 25, 2014 at 4:37 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Nov 25, 2014 at 2:30 PM, Rex Dieter rdieter@math.unl.edu wrote:
Adam Williamson wrote:
"App launchers MUST have a unique[3] 128×128 launcher icon with an alpha channel and a matching High Contrast icon."
Fwiw, I personally disagree with the last part about requiring a
matching HC
icon (which can easily be fixed in an update).
I would argue that if it's not visible to a partially sighted person during install how are they to actually get the release installed. Unfortunately for someone that actually needs high contrast to make a system usable it's not really something they can do without to begin with and update later, it's not like some other features that can be fixed easily with an update (like say a web cam or a peripheral driver) because it likely affects the persons ability to actually use anything from the outset.
Peter
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Right, but the problem is that with the current way Fedora is designed it's going to be hard for a visually impaired person (or anyone requiting *any* kind of accessibility features to actually install the OS, since enabling those options is hidden deep in the menus.
I'd say that if we want to make the installation process itself accessible, we need to have an option to turn on accessibility features directly from fedora-welcome some how, but this needs some careful design work.
For Fedora 21 I don't see a real reason to put these bugs as blockers. To see a high contrast icon you'd need to first find the accesibility settings panel and click on the right switch, which is probably not easy for people who need high contrast. Once we figure out a way to easily enable high contrast before installation, then it will be critical to have a proper icon. As for setroubleshoot, it's not critical during installation so it can always be updated later.
On Tue, 2014-11-25 at 16:45 +0200, Elad Alfassa wrote:
Right, but the problem is that with the current way Fedora is designed it's going to be hard for a visually impaired person (or anyone requiting *any* kind of accessibility features to actually install the OS, since enabling those options is hidden deep in the menus.
It is not 'deep in the menus'. We don't have submenus, so nothing can be 'deep' in there anymore. And we should the universal access icon on the login screen and during initial-setup precisely to make sure that a11y is just one click away. I'm not sure if we do the same on the uninstalled live image. If not, we probably should.
We also have a keyboard shortcuts for the most important ATs. I think at least for the screen reader, the binding is the same that Windows has, for increased familiarity.
On Tue, Nov 25, 2014 at 7:45 AM, Elad Alfassa elad@fedoraproject.org wrote:
I'd say that if we want to make the installation process itself accessible, we need to have an option to turn on accessibility features directly from fedora-welcome some how, but this needs some careful design work.
I agree with this. Perhaps the installer UI should be, I'm not sure of a proper term, but "passably accessible" from the start, with a straightforward way to enable an enhanced accessibility mode that passes through to the installation.
For Fedora 21 I don't see a real reason to put these bugs as blockers. To see a high contrast icon you'd need to first find the accesibility settings panel and click on the right switch, which is probably not easy for people who need high contrast. Once we figure out a way to easily enable high contrast before installation, then it will be critical to have a proper icon. As for setroubleshoot, it's not critical during installation so it can always be updated later.
Seems reasonable. So some additional granularity in the requirements is needed, to carve out what things will/won't block.
On 11/25/2014 09:37 AM, Peter Robinson wrote:
I would argue that if it's not visible to a partially sighted person during install how are they to actually get the release installed.
Anaconda has a high-contrast icon (it was always there, for some reason it wasn't displaying at first) that works now. So accessibility in terms of launching the installer itself isn't an issue.
The remaining problem is the welcome app doesn't have one. This is because the icon it uses is the Fedora logo and for various reasons we cannot produce a high contrast version of the Fedora logo. I don't think you can actually launch the welcome app anyway so it's an issue of it not having an icon in the dash / taskbar.
~m
On Tue, Nov 25, 2014 at 4:56 PM, Máirín Duffy duffy@fedoraproject.org wrote:
On 11/25/2014 09:37 AM, Peter Robinson wrote:
I would argue that if it's not visible to a partially sighted person during install how are they to actually get the release installed.
Anaconda has a high-contrast icon (it was always there, for some reason it wasn't displaying at first) that works now. So accessibility in terms of launching the installer itself isn't an issue.
The remaining problem is the welcome app doesn't have one. This is because the icon it uses is the Fedora logo and for various reasons we cannot produce a high contrast version of the Fedora logo. I don't think you can actually launch the welcome app anyway so it's an issue of it not having an icon in the dash / taskbar.
~m
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Oh, I understand.
Well, in that case I think it shouldn't be a blocker at all. The launcher policy was written about user-visible launchers. The welcome app is not one of these, so the policy should not apply.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Chris Murphy -
Elad Alfassa -
Matthias Clasen -
Michael Catanzaro -
Máirín Duffy -
Peter Robinson -
Rex Dieter