Establecer regla de colaboración en los issues

[RickieES]

Viendo los issues que tenemos abiertos, creo que nos perjudica mucho para el avance permitir que nos los abran con colecciones largas de palabras con diferentes categorías, sin proporcionarlas categorizadas, con indicación de cómo deben añadirse o proporcionando un parche o PR.

Me gustaría proponer que establezcamos una regla por la cual, cuando alguien abra un issue en esas condiciones, les demos un tiempo (una semana, por ejemplo) para que aporten ellos el parche o PR o, en caso contrario, dividan el issue en varios divididos por categorías y con un límite máximo de lemas diferentes para añadir. Así, los issues serían más manejables y podríamos avanzar mejor, porque tenemos algunos abiertos desde hace años en los que hay colaboradores que trabajan cuando tienen tiempo y han hecho una buena parte, pero al tratarse de listas de palabras tan numerosas, les cuesta terminarlas y se eternizan.

¿Que opináis?

[cosmoscalibur]

Me parece importante que la cantidad de lemas sea limitada por reporte cuando no aporten el parche, eso facilitaría mucho la distribución de trabajo y la posibilidad de marcar un avance más claro en el repositorio.
Ahora, regular esto será difícil, y me parece en ese sentido una ayuda si contamos con plantillas de reportes para uno o dos casos típicos, y uno genérico.
Pensando en esto y con los reportes anteriores, no se que les parece si se cierran los reportes masivos añadiendo nuevos reportes que separen las listas (y que aporten más información). En el caso de los reportes #15 y #95 tengo las definiciones RAE de todos los lemas de este tipo, y una lista separada de lemas por revisar (noRAE) de #95 . El mismo trabajo podría hacerlo con las otras listas masivas (recuerdo la #11 y no se si hay más), de manera que sea más ágil el trabajo al menos en lemas RAE.

[RickieES]

Por lo que he visto, las plantillas tampoco van a forzar las normas, solo servirán para recomendar ajustarse a ellas a quienes crean un issue. Menos es nada. Lo que pasa es que no sé si nosotros podemos crearlas (nos falta la opción Settings desde la que se accede a la creación de las plantillas, aunque entrando por Insights sí parece que me dejaría crearla.

Una vez los tengamos, podríamos ir dividiendo los que hay, aunque al menos el #15 veo que ya tienes un montón de cambios aplicados. Por cierto, vaya panzada que te has pegado este año, esta versión deberíamos llamarla "Cosmocalibur edition". 😄

[RickieES]

¿Cómo veis que pongamos números a esas propuestas (me refiero a cuántos días de plazo y cuántas palabras son demasiadas)?

[cosmoscalibur]

La verdad cuando hacía esas validaciones, sentía que más de 20 palabras (máximo 50) era un montón. Sentía desánimo hacer cambios y ver que el reporte seguiría marcado sin resolver. Yo creo que puede ser más práctico, que quien asuma un reporte, al tiempo realice la edición del reporte para partirlo en múltiples reportes.
Respecto al plazo de días, creo que antes un mes o dos me hubiera parecido razonable, en medio de los cambios con la pandemia no sé cual pueda ser un plazo prudente (hasta ahora me siento con los ánimos de retomar, en los próximos días espero contribuir nuevamente).

[olea]

He estado haciendo algunos experimentos y se me ha ocurrido que el proceso de revisión podría acelerarse con algún script nuevo para verificar el fallo en el diccionario, identificar si está o no en el DLE, obtener listados de frecuencias... y, sobre todo, usar un lematizador como Freeling para facilitar las tareas mencionadas. Técnicamente lo veo viable pero la cuestión importante es saber si responde a la realidad del trabajo de revisión y adición. Por lo que mi pregunta sería: ¿cuál sería el procedimiento actual de revisión y adición? Paso por paso y casi en pseudocódigo, para saber si puedo responder a esa realidad. Hasta donde tengo visto creo que podría automatizarse casi toda la fase de recopilación de información.

Señalar que la instalación de Freeling ocupa mucho espacio de disco, y tiene que ser suficientemente útil para que os merezca la pena instalarlo. También es posible que haya otros lematizadores, pero no he buscado mucho más porque me consta que Freeling está muy maduro.

¿Qué os parece?

[RickieES]

Los primeros pasos dependen un poco de cómo llegan los nuevos lemas al repositorio. Se me ocurren tres formas:

• Un colaborador con acceso al repositorio (como yo mismo) detecta algunos términos incorrectos y hace un commit, preferiblemente asociado a un issue que describe el cambio.
• Alguien reporta uno o varios términos que no detecta el diccionario para su incorporación en un issue.
• Alguien prepara un PR para su fusión en el repositorio principal.

El primer caso no creo que merezca mucho detalle: se supone que quien puede escribir directamente en el repo es porque tiene suficientes conocimientos para no meter la pata y que, en cualquier caso, documenta los cambios apropiadamente. No creo que proceda ninguna herramienta de análisis en este caso.

En el segundo, lo que yo hago habitualmente es... pasar del issue a otro si la colección de términos es superior a 10. 😈 Si es más corto o, por lo que sea, puedo ocuparme del issue, básicamente busco cada palabra en el DLE y su categorización para decidir dónde añadirlo, tanto gramaticalmente como regionalmente. El único issue de adición de palabras que he atendido personalmente en la 2.8 incluía varios lemas que no eran neutros y se verá que alguno de ellos está añadido entre cinco y diez veces, una por cada variante regional en la que el DLE indica que es usado. Si lo atiende alguien que, en lugar de trabajar directamente con el repo, supongo que harán ese mismo trabajo generando un PR y, si no hacen ellos la revisión, normalmente la haremos quienes podamos fusionar el PR.

Y con los PR preparados directamente por colaboradores, la dinámica que yo sigo es la misma: verifico cada palabra contra el DLE y, en función de lo que encuentre, reporto o fusiono. Para ver lo que hay que revisar miro la pestaña "Files changed" y lo voy repitiendo cada vez que se tienen que hacer ajustes, por lo que siempre es de agradecer que los PR sean breves. 😄

Por supuesto, procuro tener en cuenta si los ficheros modificados son del directorio RAE o noRAE y también si son de distintas variantes regionales o neutros.

Para mí, la categorización automática que haría FreeLing no me aportaría mucho, porque sigo teniendo que revisar si el lema existe en DLE.

[cosmoscalibur]

@RickieES , consideras que hay algo que de esta discusión valga la pena agregar algo a la wiki o mejor lo cerramos, y seguir con lo que ha sucedido orgánicamente.

[cosmoscalibur]

Con estas características nos faltarían: #266 (la estoy trabajando), #313 (espero ayudar con las faltantes), #161 (que está complicada porque la mayoría entiendo que son afijos, y posiblemente inexistentes) y #184. Igual dado que no surgen ya con recurrencia, y que se están evacuando, diría que podemos cerrar y esperar al momento que ocurra una nueva para evaluar la estrategia. Y bueno, un punto a resaltar que necesitamos habilitar las discusiones de GitHub para separarlo de los reportes de errores o mejoras.