Lo bugs que sí y los bugs que no
Leí un correo de Ian Jackson en el que se refería específicamente al error de pensar que todas las personas pueden y deben reportar bugs. Me gustaría traducirlo completo pero ahora mismo no puedo. En resumen, más o menos planteaba -con más sinceridad de la que mucha gente agradece- que para el caso de Debian, si un desarrollador debe gastar dos de sus cuatro horas diarias de programación para responderle a personas usuarias que reportan bugs que en su mayoría, son errores de procedimiento… eso no es beneficioso para el proyecto debian. Para él, “mimar” a las personas usuarias de esa manera no contribuye en nada. Habla de varias falacias muy interesantes y si leen inglés, por favor revisen el correo antes de seguir leyendo aquí (que mi resumen es muy pobre, la verdad).
Aunque puede parecer chocante… la verdad sea dicha: tiene razón. Tiene razón cuando hablamos de proyectos de desarrollo de un sistema operativo o aplicaciones horizontales. Todos los desarrolladores saben cómo debe comportarse un sistema operativo. Es decir, en la mayoría de los casos, los reportes no le dirán nada nuevo y si no los hacen personas con suficientes conocimientos, no contribuirán en mucho a encontrar la solución. –> Hace un año me hubiera pegado por la mano por escribir una cosa así.
¿En dónde sí vale la pena reportar bugs?
No sé… imagino que en desarrollos como Gimp o aplicaciones para sectores u ocupaciones específicas. Ahí sí los desarrolladores no saben qué es lo que se espera del programa (supongo) y ¿se necesita de mucha guía de personas usuarias que sí saben qué es lo que el programa debe hacer o cómo, lo que imaginan, no puede ser implementado a partir de la herramienta?
¿Y entonces, cómo mejoramos el software?
También, es importante reportar el otro tipo de bugs… los bugs generados por la endogamia hacker: ¿qué cosas no son útiles a las personas usuarias? Habría que generar espacios distintos, algo como grupos focales que permitan recibir observaciones sobre cosas que no se reciben bien, errores comunes en una interfaz, campañas equivocadas o actitudes que nos alejan de los proyectos. Es decir, por mucho tiempo las personas que no programamos, hemos pensado que debemos convertirnos en lo que no somos, para poder reportar bugs y ayudar “de verdad”. Tal vez la pista esté en otro tipo de reportes que debemos hacer e incluso, en no reportar nada más, sino involucrarnos de lleno en organizar el cambio. Y ahí es donde topamos con pared: ¿en cuáles espacios podemos mejorar el software quienes no programamos? ¿tenemos que conformarnos con probar versiones nuevas de los programas? ¿tenemos que dedicar nuestra energía a aprender a reportar bugs apropiadamente en lugar de aprovechar las capacidades que ya tenemos?
Para nada de eso tengo respuesta. Yo sólo tengo dudas.




La segunda versión alpha de Athena GNU/Linux 2.0 ha sido liberada. Esta es una versión de prueba por lo que se recomienda a los usuarios no usarla en sistemas de producción ya que puede contener errores que afecten el rendimiento del sistema.







