Propósito

En esta página se recopila aquella información que puede ser más útil para los usuarios y desarrolladores que colaboran en la clasificación de incidencias.

La mayoría de incidencias que se abren en el repositorio de Github de NVDA pertenecen a una de estas categorías:

  • Añadir soporte a nuevas aplicaciones
  • Añadir nuevas características a NVDA
  • Añadir nuevas características para dar mejor soporte a aplicaciones de terceros
  • Informes de errores

Lo primero que quiere NVAccess es catalogar y procesar las incidencias urgentes, y resolverlas en primer lugar. En ellas podría haber cosas como:

  • Un error fatal de NVDA
  • Sintetizadores de voz que no funcionan bien
  • Un error en una característica existente

En segundo lugar, los desarrolladores quieren estar seguros de que hay información suficiente en la incidencia para que pueda entenderse bien y se pueda empezar a trabajar en cuanto llegue al principio de la cola. Cuanto más pronto se haga, más probable es que la información llegue donde debe. La mayor parte de la información requerida se pregunta en las plantillas de incidencia de Github, por lo que es un buen lugar para empezar.

Busca duplicados

Coge unas cuantas palabras clave y busca en el repositorio de NVDA en Github. No busques sólo en las incidencias, hazlo también en los pull requests. Podría haber uno en el que se trabaje para resolverla.

¿De qué tipo de incidencia se trata?

¿Se puede etiquetar como una regresión, una solicitud de cambio de comportamiento, o una solicitud de nuevas características?

Regresión

El comportamiento del software ha cambiado de forma no intencionada. Esto significa que una característica deja de funcionar, o se oye un sonido de error, o se produce un error fatal.

Características nuevas

Se trata de algo nuevo que NVDA no hace todavía.

Cambio de comportamiento

La incidencia describe algo del tipo «NVDA hace esto, pero me gustaría que hiciera esto otro en su lugar».

¿Hay algún truco para evitar el problema?

¿Se podría conocer algún truco, alternativas existentes, o cualquier otra forma de resolver la petición?

Información recopilada

Este es el tipo de información que podría ayudar al investigar la incidencia más a fondo.

Regresiones

  • ¿Cómo se activa la regresión? A esto podemos llamarlo pasos para reproducir (steps to reproduce, str para abreviar). O lo que es lo mismo: se busca el conjunto de pasos para que el fallo ocurra en el propio sistema de los desarrolladores.
  • ¿Qué pasa / cuál es el comportamiento actual? Algunos ejemplos podrían ser:
    • Un error fatal
    • Un cuelgue
    • Un sonido de error
    • Un mensaje en el registro
  • Si se ha oído un sonido de error o hay un mensaje en el registro, ¿va acompañado de un comportamiento inesperado? Por ejemplo, ¿ha fallado NVDA al anunciar algo que debería haber anunciado?
  • Incluso si parece obvio, ¿qué debería pasar en su lugar?
  • Vale la pena tener las cosas claras con el usuario, asegurarse de que habláis de lo mismo y el problema se entiende claramente.
  • En qué versión de NVDA ocurre. Es bueno conseguir algo como: ‘stable’, ‘next’, ‘rc’ o ‘release’. Pero es mucho mejor obtener la versión exacta de NVDA, que se puede saber yendo al menú ayuda de NVDA, en Acerca de. ‘next-13896,5322f3d8’
  • ¿En qué versión de NVDA funcionaba esto como era de esperar?
  • Si se necesita otro software para reproducir la incidencia, saber qué software es y qué versión produce el problema en NVDA ayuda mucho. Los documentos con casos de uso y pruebas también son muy útiles.
  • Algunos comportamientos ocurren sólo en ciertas versiones de un sistema operativo concreto. Algunas veces un fallo sólo puede reproducirse en esa versión concreta del sistema operativo. Por tanto, también es necesario obtener esta información. Al igual que con la versión de NVDA, cuanto más específicos seamos, mejor. Por ejemplo, es bueno saber que la incidencia ocurrió en ‘Windows 7’, ‘Windows 10 insider’. Pero es mejor conocer la versión y la compilación también: ‘Windows 10, fast insider (anillo rápido), version 1703, build 16170.1000’.
  • Una copia del registro de depuración
  • Si existe, un archivo de volcado de errores
  • ¿Puede alguien más reproducir la incidencia?
  • ¿Ha intentado alguien reproducir la incidencia sin éxito?

Los últimos puntos en particular suponen un consumo excesivo de tiempo para NVAccess, y son una forma excelente de contribuir con NVDA para los miembros de la comunidad. Comprueba si los fallos se producen en los distintos equipos de tu entorno, así como en máquinas virtuales si quieres, e informa de los resultados.

Nuevas características

Típicamente, debe haber una descripción del comportamiento deseado y de por qué el usuario quiere tener este comportamiento. Para comenzar podemos partir de un caso de uso, y convertirlo en historias de usuario. Si es posible, se deberían identificar variaciones posibles del caso de uso planteado.

Con el fin de evaluar el impacto de la nueva característica, habría que pensar quién se beneficia de ella, y si es necesario un comportamiento distinto para la voz, el braille y la apariencia visual. Aquí podemos dividir esto en dos partes: cómo de beneficioso es para un individuo en particular y cuántos individuos van a usar esta característica. Finalmente, es útil saber si esta característica existe ya en otros lectores de pantalla. Si es así, ¿Cómo funciona allí?

Cambio de comportamiento

Podríamos decir que esto puede ser una combinación de un fallo y una petición de una nueva característica, y en cierto modo se espera recopilar la información expuesta en los apartados anteriores.

Sin embargo, la información más importante necesaria en este tipo de peticiones es la siguiente:

  • ¿Cómo se reproduce el comportamiento?
  • ¿Cuál es exactamente el comportamiento actual?
  • ¿Qué es lo que está mal en el comportamiento actual?
  • ¿Qué debería hacer NVDA en vez de lo que hace ahora?

Esencialmente, eso se reduce a:

  • Cuál es el caso de uso y las historias de usuario,
  • Cómo difiere del caso de uso actual para esa característica.

Casos de uso e historias de usuario

Hay tres cosas que debemos intentar definir: quién, cómo y por qué. Esto generalmente se suele expresar de la siguiente forma: como un algo (quién), quiero ser capaz de algo (qué) para que pueda hacer esto (el porqué).

Aquí hay un ejemplo de una incidencia reciente en Github. Primero lo pondremos en inglés, luego en español:

As a Braille user, I notice that the cursor is a different shape when tethered to focus than it is when tethered to review. This is so that I can tell the difference between the two modes.

Como usuario braille, me doy cuenta de que el cursor tiene una forma diferente cuando sigo al foco y cuando sigo a la revisión. Así es como consigo distinguir si estoy en un modo u otro.

Quién

  • ¿A quién afecta? Por ejemplo usuarios de pantallas braille, usuarios que trabajan con voz, desarrolladores que trabajan en la accesibilidad de sus sitios web y aplicaciones, los propios desarrolladores de NVDA, etc.
  • Sabiendo esto, se puede estimar cuánta gente se verá beneficiada al arreglar la incidencia.
  • También puede ayudar a crear distintos casos de uso con distintos requisitos para grupos de usuarios diferentes. Esto pasa cuando no podemos definir el mismo caso de uso para dos grupos de usuarios.

Qué

  • Esto puede ser una guía paso a paso de lo que esperan hacer, y la salida que esperan obtener.
  • Cosas a tener en cuenta:
    • ¿Es necesario trabajar con otro software? Si es así, ¿qué versión?
    • Al trabajar particularmente con otro software, viene bien disponer de un archivo o documento relacionado con él. Por ejemplo, un caso de prueba relevante.

Por qué

La pregunta más difícil de responder, pero la que más valor tiene.

  • ¿Por qué quieren hacerlo?
  • ¿Qué logran con ello?
  • Es muy importante responder al por qué, ya que aporta información sobre las circunstancias que rodean al qué. Conociendo estas circunstancias, se puede proponer incluso una alternativa más simple.

Sintetiza la incidencia

Es bastante probable que al recopilar información se generen muchos comentarios en la incidencia.

Según vaya creciendo la incidencia en Github con comentarios, preguntas y debates, conviene resumir periódicamente su estado. Así se ayuda a condensar todo el debate en un resultado final. Así todos lo tendrán más fácil para coger el problema, moverse rápidamente por los comentarios y entenderlo leyendo el resumen. También ayuda a asegurarse de que todo el mundo está al día y a iterar sobre el problema, entendiendo por qué se han tomado ciertas decisiones.