Follow-up Workflow Keyword Proposal

This post is a follow-up to the workflow keyword proposed on April 29th, 2021. Originally posted as a comment on the original post by @ryokuhi

The accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team reviewed the proposal today during the weekly meeting.
As we would like to bring this proposal forward, we investigated some possible keywords and would like some feedback on them.

• needs-implementation could be a nice addition to needs-design: while needs-design usually involves only the creation of a layout, needs-implementation would convey also the need of an actual implementation to test for accessibility. The downside is that such a keyword would be very similar and difficult to distinguish from needs-patch.
• has-accessibility-review (along the lines of has-privacy-review) could be added after a first triage to exclude tickets from scrubbing until extra feedback is needed. The downside is that often accessibility review is a multi-stage process that needs to happen after each UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. change, not just once for a ticket: the wording has-accessibility-review might induce to think that everything is done once the ticket is reviewed.
• needs-accessibility-feedback or needs-accessibility-review are keywords that could be added when an action from the accessibility team is required. The downside is that similar keywords don’t really add any extra information if the ticket also has the accessibility focus.
• changes-requested underlines the fact that the owner of the ticket needs to do an action before the accessibility team (or any other team) can offer feedback on the ticket.

Apart from adding a new workflow keyword, the team also took in consideration two other options.

• Differentiating between primary and secondary focuses on TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. might allow teams to distinguish more easily between tickets they are responsible for and tickets where only feedback is needed. Of course, this would require a change to Trac, which is probably complex and could be done only in the long run.
• If the reporter or the owner of the ticket doesn’t take any action after a reasonable amount of time, the team will change the milestone of the ticket even if it’s not under their direct responsibility. The team consider this as an extreme option to invite who is monitoring the ticket to take action.

The team would like to have another round of feedback on the (updated) proposal and will review it again in one or two weeks.

#trac-2, #workflow