Triage process

Reef Turner edited this page Aug 14, 2017 · 5 revisions

For transparency, the following is a brief outline of the process NV Access is following for issue triage. If you would like to help with the triage process (which is an excellent way to make a contribution to NVDA) please refer to issue triage help on the wiki

Issues to triage

For a list of issues still requiring triage: is:issue is:open -label:feature -label:p1 -label:p2 -label:p3 -label:p4 -label:blocked sort:updated-desc

Missing attachments

NV Access migrated tickets from our old issue tracker ('Trac') into Github issues. These issues can be identified by having an author of nvaccessauto. Some of these issues have comments that indicate an attachment should be available, but it is not. All of these Trac attachments are now accessible at: (then the Github issue number). So as an example, for issue #2396, get the attachments from If you come across one of these missing attachments, please upload if you think they're relevant to GitHub. Note you'll need to rename adding a .txt extension to code, logs, etc. Anything else should probably be zipped.

How prioritisation works

We differentiate between the priority for bugs (labelled bug) and new features (labelled feature). Rather than assign a priority to issues with the feature label, typically we try to group new features into a project of related work. We should try to ensure that new features are well defined before applying the feature label. One exception here might be if we can determine that a feature is not something we are likely ever to work on. In this case we should apply P4 and explain this is not something we are going to look at but will be happy to accept a pull request for. We also have a label for enhancement, think of this as a more internal facing change. For instance, editing code comments to provide clearer / more complete information, or extending an internal framework/API to unblock other issues.

Bugs/regressions are given priorities based on an estimate of their severity, impact and implementation cost:

  • P1 issues are typically crashes or severe errors that should be fixed immediately.
  • P2 issues should be among the next issues fixed. Try to start on the oldest of these issues.
  • P3 issues are less likely to get fixed, we hope to get to them "one day". However if something changes (severity/impact/cost) the priority can be reassessed.
  • P4 issues probably won't be worked on by NV Access, however we will be happy to provide implementation guidance and accept a Pull Request.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.