The reason I ask is because it would be helpful to have a streamlined place to send people who have accessibility issues with Fedora, whether that’s something on this forum, making a ticket in GitLab, or something else.
I can also dump feedback I see online into that same place for folks who are having issues but may not take the time to talk about their issue outside of a social media post. I won’t always do that, but I can make an exception for accessibility because it’s an important issue and one of our objectives for Strategy 2028.
We also may need to think about how we circulate feedback to upstream projects. For example, someone in the Mastodon thread I linked shared an issue with Gnome, which isn’t really something we cover. However, we do work closely with the project and can probably communicate this with them. From that perspective we can function as hub to improve accessibility upstream for projects who may not have their own accessibility initiatives.
The A11y WG is in its initial formation stages at the moment, but we do want to provide a place for users to share / file their issues, and we would attempt to connect them with the right team / people.
This is just an idea that I’m not sure will work, but I wonder if we could set up a separate GitLab repo that is specifically for “Fedora Accessibility Feedback” so that tickets like these don’t mix with the ones you’re using for internal team tasks. It could also be helpful for the Quality Team if it’s separate so that they know that every ticket they’re seeing is related to an accessibility issue. Would love to hear from someone on that team for what there thoughts are on a good process.
My first thought is that creating more than one GitLab repo while we are still early days in this work might be premature. I suspect we are not yet equipped to triage and respond to this kind of feedback. Keeping it in one place, for now, at least gives us one common place to start surfacing ideas, feedback, and improvements.
In general though, I am not sure we are ready to open the floodgates for feedback on accessibility. It is valuable information, but I do not want to set up an expectation that we are equipped and ready to act on every piece of feedback we get.
A separate repo might be a good idea after we prove the concept of the Working Group and have an idea of how to prioritize and respond to user feedback.
This is an area where I could learn a lot. Across my years in Fedora, I have not gone deep in the quality end of things in Fedora.
I am also not sure how accessibility-related feedback would be exposed to the Quality Team. Is it Bugzilla tickets?
I think we could also point to people to Bugzilla is that’s preferred. As long as there’s a place where we can point people to and not have it lost, I think we’re good.
The only concern I have with a Quality Team focused ticket repo is that not every point of feedback that we get about accessibility is something they can work on. We would have to take that into account so that tickets that aren’t actionable for the Quality team are still tracked for communicating with upstream projects.