Join GitHub today
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
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: https://www.nvaccess.org/files/nvdaTracAttachments/ (then the Github issue number). So as an example, for issue #2396, get the attachments from https://www.nvaccess.org/files/nvdaTracAttachments/2396
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:
P1issues are typically crashes or severe errors that should be fixed immediately.
P2issues should be among the next issues fixed. Try to start on the oldest of these issues.
P3issues 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.
P4issues probably won't be worked on by NV Access, however we will be happy to provide implementation guidance and accept a Pull Request.