Por motivos de transparencia, a continuación se muestra una breve descripción del proceso que está siguiendo NV Access para la clasificación de incidencias.
Si quieres ayudar con el proceso de clasificación (lo que es una excelente forma de hacer una contribución a NVDA), consulta la sección de ayuda de clasificación de incidencias.

Adjuntos que faltan

NVAccess migró sus tickets desde su antiguo rastreador de incidencias (‘Track’) a incidencias de GitHub. Estas incidencias pueden identificarse porque tienen como autor a nvaccessauto. Algunas de estas incidencias tienen comentarios que indican que debería haber un adjunto disponible, pero no está. Todos estos adjuntos de Track ahora están accesibles en: https://www.nvaccess.org/files/nvdaTracAttachments/ (seguido del número de incidencia de GitHub). De esta manera, como ejemplo, para la incidencia #2396 obtén los adjuntos desde https://www.nvaccess.org/files/nvdaTracAttachments/2396
Si te encuentras con uno de estos adjuntos que faltan, por favor súbelo a GitHub si piensas que es relevante. Ten en cuenta que deberás prestar atención a las restricciones de nombres de adjuntos en GitHub, si falla intenta comprimirlos en zip.

Cómo funciona la asignación de prioridades

NV Access diferencia entre prioridad para fallos (etiquetados como bug) y nuevas características (etiquetadas como feature). En vez de asignar una prioridad a incidencias con la etiqueta de feature, NV Access intenta agrupar nuevas características en un proyecto con trabajos relacionados. Se debe intentar que las nuevas características estén bien definidas antes de aplicar la etiqueta feature. Podría darse una excepción aquí si podemos determinar que una característica es algo en lo que probablemente nunca se trabajará. En este caso se debería aplicar P4 y explicar que esto no es algo que vayamos a mirar, pero para lo que se acepta felizmente una solicitud de cambios. NV Access también tiene una etiqueta para mejoras, piensa que esto tiene que afrontar cambios más internos. Por ejemplo, editar comentarios del código para ofrecer información más clara y completa, o extender una API o framework interno para desbloquear otras incidencias.

Los fallos y las regresiones reciben prioridades en base a una estimación de su severidad, impacto y coste de implementación:

  • Las incidencias P1 son típicamente errores fatales o muy graves que deben repararse inmediatamente.
  • Las incidencias P2 deberían estar entre las siguientes incidencias reparadas. Intenta empezar con la más antigua de ellas.
  • Las incidencias P3 tienen menos probabilidad de ser reparadas, se espera centrarse en ellas «algún día». Sin embargo, si algo cambia (severidad, impacto, coste) su prioridad puede alterarse.
  • NV Access probablemente no trabajará en las incidencias de tipo P4. Sin embargo, estarán encantados de ofrecer guiado durante la implementación y aceptar una solicitud de cambios.

Debido a la dificultad a la hora de dar prioridad a incidencias individuales, recientemente (2019) NV Access ha pedido a los miembros de la comunidad que hablen de sus 2 incidencias más importantes. Estos datos permitieron a NV Access encontrar tendencias, dando como resultado una reasignación de prioridad en sus esfuerzos. Aunque este ejercicio les permitió resolver los problemas más importantes para la mayoría, son conscientes de que hay problemas críticos que afectan a pequeños grupos que pueden no haber sido resueltos. Por tanto, se debería seguir aplicando el proceso anterior, especialmente para las incidencias p1 y p2. Si una incidencia resulta crítica para ti, comenta en ella y explica por qué.

Páginas en esta sección