[RFC] Propuesta de mejora sobre la gestión de bugs y otras incidencias

[castarco]

Hola, os escribo porque he estado ayudando a una amiga que tiene problemas para usar Autofirma junto con Ubuntu (22.04) y Firefox (120.0); y cuando he llegado a este repositorio me he echado las manos a la cabeza al ver cómo se está gestionando todo esto.

Sé que empezar criticando no me va a generar simpatías, pero debo resaltar que lo digo de buena fe y con ánimo constructivo.

Voy al tema que toca, mi propuesta, que consta de varios puntos (la mayoría se apoyan entre ellos, pocas de estas medidas tienen sentido por sí solas):

Medidas "sociales"

1. Introducir plantillas para las "issues", que permitan a los ciudadanos saber qué datos estructurados deben aportar para facilitar la comprensión del problema, con lo típico:

   • versión del sistema operativo
   • versión del navegador
   • versión del cliente AutoFirma
   • versión del JRE (y aquí incidir en cual se está usando, que a veces hay varias instaladas)
   • Lista de certificados cargados en el navegador (no tengo claro cual debería ser el formato de tal listado ni cómo facilitar a los usuarios que lo puedan generar, pero estoy seguro de que se puede encontrar una solución satisfactoria en menos de 1 día de trabajo)
   • los pasos que se han seguido
   • las expectativas que tenía el usuario
   • lo que ha sucedido en lugar de lo que el usuario quería
   • screenshots
   • etc. (lo que los desarrolladores consideren necesario, yo he listado lo más evidente).

2. Un documento de código de conducta ( https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project ) que "justifique" bloquear (aunque sólo sea temporalmente, por eso de que siguen siendo ciudadanos) a los usuarios que actúen de forma irrespetuosa tanto en la sección de Issues, como en la sección de Discusiones.

3. Darle más peso a la sección de discusiones (mover las issues que no son bugs allí, puede servir para que los usuarios se den soporte entre ellos sin aumentar la carga de trabajo de los mantenedores).

4. Añadir un documento sobre cómo contribuir ( https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors ). Aunque este sea un proyecto estatal, entiendo que si un ciudadano con conocimientos técnicos elevados aportara alguna corrección o mejora sustancial, tendría sentido aceptarla... pero obviamente esto se tiene que hacer "bien" por muchos motivos (entre legales y de seguridad)

5. Introducir un documento formal con la política de seguridad (SECURITY.md), para facilitar que el resto de ciudadanos puedan reportar problemas de seguridad de forma adecuada (hay poca gente que pueda hacer eso, pero la hay).

Medidas de "UX"

6. Remodelar el documento README para que contenga información esencialmente útil para los usuarios finales, y no para los desarrolladores. La información que veo ahora mismo se podría mover a la guía CONTRIBUTING.md. Este README podría introducir enlaces a las secciones importantes de la wiki, o explicaciones introductorias breves (incluyendo el cómo reportar incidencias). Puedo ayudar con esto, pero me gustaría saber que los mantenedores están de acuerdo con esta propuesta.

Medidas "Administrativas"

7. Usar el sistema de etiquetas para etiquetar las issues en función de varios aspectos. Por ejemplo, las que aún no han sido revisadas por los mantenedores, podrían ser automáticamente etiquetadas por un bot con una etiqueta tipo triage ( https://docs.github.com/en/actions/managing-issues-and-pull-requests/adding-labels-to-issues ). Estoy dispuesto a ayudar con esto, tengo bastante experiencia usando estos sistemas para agilizar la gestión de incidencias. El sistema de etiquetas no sólo ayuda a los mantenedores, también a los usuarios a la hora de buscar incidencias parecidas a las suyas.

   • Algunas etiquetas que entiendo que son necesarias (obviamente podrían estar todas en Castellano, uso Inglés por inercia): triage (aun no revisado por los mantenedores), bug (después del proceso de triaje se ha determinado que la incidencia corresponde a un bug real), feature_request ( los usuarios sugieren una nueva característica, y los mantenedores no han descartado la idea ), os:linux, os:win, os:mac, browser:firefox, browser:chrome, browser:safari, jre:oracle, jre:openjdk ... (todas estas son bastante evidentes), invalid (el reporte es erróneo), security (afecta a la seguridad del usuario), ...

8. Hacer limpieza. Cerrar incidencias y PRs, idealmente con alguna respuesta explicando el porqué se cierran; aunque mejor aún sería dar solución a los problemas expuestos por los usuarios.

Medidas "legales"

9. Esclarecer bajo qué licencia se distribuyen la aplicación y su código. Que esto esté especificado en una wiki completamente desconectada de este repositorio es irrelevante. La licencia tiene que estar disponible junto con el código.

[gonzaleztroyano]

Me sumo a la mayoría de las propuestas. Aquí habría que ver la intención de los mantenedores/organismo del que dependan respecto a aceptar propuestas de la comunidad.

Respecto a la última cuestión, en relación con la licencia: Es software libre con licencia GPL 2+ y EUPL 1.1., tal y como se puede ver en el README, aunque sí sería interesante añadir el típico archivo LICENSE.md al repo, así como aclarar por qué se licencia bajo 2 distintas.

Respecto a esto último (2 licencias), parece que en el apartado Acerca de Autofirma se explica algo mejor:

AutoFirma es Software Libre; puedes redistribuirlo ylo modificarlo bajo los términos de al menos una de estas dos licencias:
• La -GNU General Public License- tal como es publicada por Ia Free Software Foundatjon; versión 2 de la Licencia, o (a su elección) cualquier versión posterior.
• La -European Software License-; versión 1.1 de la Licencia, o (a su elección) cualquier versión posterior.

EDIT: hay una carpeta llamada license en la raíz del repositorio, que contiene toda la información en este sentido. Github no la reconoce, al no ser la ubicación estándar.

[Ivomola]

Coincido completamente. Yo ya abrí una issue (#317) hace unos años más o menos diciendo lo mismo aunque de una manera bastante menos formal y educada. El tema es que creo que el hecho de que la suite de @firma sea de código abierto es simplemente para cumplir con alguna obligación legal relacionada con el CTT, porque este es un proyecto que no está para nada gestionado como un proyecto de código abierto debería ser gestionado. Para empezar, con un simple vistazo se ven:

• Pull requests que están mergeadas con commits en lugar de merges (Soporte para uso de AutoFirma mediante JNLP y para firma de varios documentos por petición #2)
• No se usan lables/etiquetas. Si una issue o PR no interesa ni se hace el esfuerzo de responder (como esta), en lugar de etiquetarla como "wontfix" o similar. El colaborador nunca tiene ni idea de lo que decide el equipo de desarrollo.
• La única función avanzada de GitHub que se usa es el bot de dependencias. No se presta atención a las discusiones, no hay archivo LICENSE.md como ya se ha mencionado, ni tampoco hay SECURITY.md (y es un software del gobierno!! Una política de reporte de vulnerabilidades es lo MÍNIMO!!)
• Hay colaboradores del proyecto con permiso de commits que ni siquiera tienen cuenta de GitHub.
• No hay código de conducta, ni indicaciones para contribuir (archivo CONTRIBUTING.md)

Y así podría seguir hasta agotar los caracteres permitidos en una issue. La intención no es menospreciar el trabajo que se hace; es una suite compleja, y Java tampoco facilita la cosa, pero el trato que se le da a este proyecto sí que es un menosprecio al espacio Open Source y al software de código abierto por parte del Gobierno de España. Esperemos que tomen en cuenta todos estos clamores y empiecen a tratar un proyecto Open Source como tal, y no solo para cumplir una obligación legal.

[Ivomola]

Entrando a la issue de nuevo acabo de ver las ediciones nuevas. Gran trabajo @castarco 🔥

[narcisgarcia]

El nivel de exigencia en la comunidad del software libre es muy elevado, y los equipos desarrollo de software, los que suelen gestionar proyectos de forma no pública, no están acostumbrados a ese nivel de exigencia técnica y comunitaria.

Pero es justamente el ámbito de las administraciones públicas el que tiene mayor responsabilidad en su gestión pública, de forma pública (que no es una redundancia).

Gracias @castarco