Establishing a clear policy for legacy Word object model bug reports

[gerald-hartig]

A recent bug report, #18334 "Cycling through tables : header bug - MSWord", has sparked a conversation about how we as a project should handle bug reports for legacy features. This discussion is to create a space to discuss the factors that influence the policy for this.

Context

NVDA's development focus is on improving support for modern technologies like UI Automation (UIA) in applications like Microsoft Word. This is where we are investing our core development time to ensure NVDA is future-proof.

At the same time, we recognise that the option to use the legacy Word object model still exists in NVDA's advanced settings. A significant number of users rely on this setting for specific workflows, often because of compatibility issues with other software (eg MathType, as noted in the original issue) where UIA is not yet a complete solution.

User reality vs. development focus

A point raised by @CyrilleB79 during the discussion was the feeling that by focusing solely on UIA, the project might be ignoring how people actually work in their day-to-day lives.

Some users have enabled the legacy object model out of necessity. From the project's perspective, we face the difficult reality of having limited resources. To ensure NVDA's long-term health and compatibility with future versions of Windows and Office we must prioritise UIA.

This creates the tension of how do we honour the reality of our users' current needs while steering the project towards a modern/sustainable future? One of the goals of this discussion is to raise the issues for the policy that will help us navigate this tension that doesn't dismiss real-world use cases but is also honest about our development priorities.

The question for discussion

How should we handle these bug reports going forward? The goal is to find a solution that correctly sets expectations about development priorities while also respecting user reports and helping us track the state of the software.

Here are a few options, based on the feedback in the issue thread:

1. Close as "Not Planned" / "Won't Fix"

   • Pro: Clearly communicates that no core team development resources will be assigned.
   • Con: Can be seen as dismissive. Makes tracking these issues difficult, potentially leading to duplicate reports and a loss of valuable data on user impact.

2. Keep open, tagged with low priority p5

   • Pro: The issue remains visible and searchable in the main tracker.
   • Con: May clutter the main issue tracker with issues that have a low probability of being addressed. Could create false hope for a fix.

3. Close, but track via a label and meta-issue / discussion

   • As suggested by @CyrilleB79, we could create a specific label like legacy-wontfix or word-object-model.
   • When a new legacy bug is reported, we apply the label, close the individual report and link it to a meta-issue or discussion.
   • Pro: Keeps the main tracker clean, sets clear expectations about a fix but provides long-term trackability. It acknowledges the report's validity without committing resources.
   • Con: Requires a bit more process overhead during triage.

We are leaning towards Option 3 as a healthy compromise, but we are opening this discussion to the community. What are your thoughts? Are there other approaches we should consider? Both more generally and in this specific UIA case?

[LeonarddeR]

This discussion was mentioned in #4631. Personally, I lean towards a hybrid between option 1 and option 2, based on the following distinction:

1. Apply option 2 to new bug reports that have a clear demand from an end user that one is missing a feature or needs a bug fixed with the object model.
2. Apply option 1 to issues that are existing as of now which were reported against the object model but have since been fixed in UIA. If they haven't been fixed in UIA either, it makes sense to leave them open of course.

In the case of #4631, we'd now close, but we'd be open to a new issue that reports that equation reading doesn't work in the object model, clearly stating that there is a blocking issue for the user to use UIA.

[Adriani90]

Thank you for raising this important discussion.
Actually it goes even far beyond objectModel, we are dealing with a situation where there is a transition process in technology from objectModel to UIA. This process is goind since years,. My opinion as following is based on our experience with similar cases in the past (e.G. the transition from the old Microsoft Edge browser to the new chromium based Edge browser).
In that situation, we created a new label for the old Edge browser and a new one for the new chromium based Edge browser.
After the transition was completed and the old Edge browser was gone, we closed all remaining issues with the coresponding label.
The community was still solving issues with the old Edge browser during the transition process, and this made sure that users still relying on the old Edge browser were not left behind until Edge Chromium was stable enough.

I propose following approach, a combination of option 2 and part of option 3, based on the positive experience we had in the past during transition:

• Add a new label for objectModel
• Assign that label to issues that are fixed in UIA but not in objectModel and let them open
• Give them a lower priority if you really think they cannot be taken by a core developer
• Close them as abandoned after the transition to UIA has been completed and confirmed by the community.

Background:

• The issue tracker already has a good prioritization system, for a core developer it should be easy enough already to find high priority issues
• Objectmodel issues are still valid and impact many users who cannot rely on UIA (e.g. forms created in older MS Word versions are not accessible via UIA at all). For my job at least, using UIA is not an option at all, I couldn't do it because we have a lot of MS Word documents in our company which were created in very old MS Word versions.
• The community is still actively working on fixing objectModel issues, see Report destination of link in Word / Outlook legacy #17292, Use Word object model to report distances when available #14575, Update braille when control+v, control+x, control+y, control+z, backspace or control+backspace is pressed and UIA not used in ms word #15491, MS Word object model: Always fetch range information #15307, Text alignment reporting and enhancements for MS Excel cells and MS Word text #15205, Report background and highlighted text in MS Word #14610.
• These pull requests make very clear, that during last two years the community still needs objectModel, and especially Report background and highlighted text in MS Word #14610 was, at least for me, a game changer since in my job many sighted people are working with highlighted text. I cannot work with them using UIA because it lacks support for highlighted text still.

Why not a meta discussion?

• There was never a good experience with Meta discussions on fixing single issues. They were rather overwelming and often led to less activity instead of focussed reactions. Meta discussions are really good for a new UX design, a complete redesign of a feature, etc. But single issues will get rather lost if we start a Meta issue on objectModel. The best example is Current state of UIA implementation. Was: Corporate mode for NVDA #16600 which is kind of a meta discussion on UIA, but didn't really bring any huge proggress. I think the propper label will already make sure people can find themselves the issues they want to fix.
• I understand that meta issues make sense in a well structured development landscape like a company with clear processes, and this can be done if NV Access plans to work on a larger scale of issues in parallel. But for the open source community where people contribute voluntarily, most people have a problem themselves and have an idea how to solve it, and they search for the specific issue to fix. Most people do not have time to go through a meta issue, especially if it gets far behind other new meta issues and discussions after a while. The search operators in Github are already advanced enough to find single issues quite easily imo.
• Closing the issues will very probably nip the discussion in the bud and no one will think about a fix. Users will not give further feedback on current state compared to UIA, etc.

Conclusion

• Imo it is much easier to abandon issues related to old software that is not supported anymore, but it is hard to abandon issues related to a technology that is still actively maintained and needed by the community, even if this means higher development efforts.
• We should rather clean up the repo from issues that
  • are not reproducible at all anymore
  • Lack of updates from users upon request
  • are duplicates
  • There is a clear policy that they won't be fixed due to risk of sending wrong signals (e.g. issues that, if they were fixed, would encourage developers to design their software / website in an inaccessible way because the screen reader takes care of e.g. labeling objects, focus redirection, supporting invalid syntax etc.)
  • The issue description and the comments are not clear enough to understand the issue (in case of old issues)
  • Not respecting the issue template (in case of new issues).

I think the repo was on a good way to get rid of many such issues in the past years, and if we look now at old issues, most of them are clearly reproducible and valid. There is still much to do, but this needs activity from more than just a few people who put a lot of energy in asking for updates etc.