Comunicación about rla-es HOT 22 CLOSED

Tengo la misma desazón que tú. 😄 Tengo un proyecto creado aquí (del que, por tanto, soy administrador) y no me suena haber visto nada similar a un foro o una lista de correo. Me da la sensación de que los issues son el único medio de comunicación, pero a ver si hay alguien que pueda sacarnos de nuestro error.

Los issues "que deberíamos resolver para finalizar la 2.1" tienen asignado ese hito, según una estimación que hice cuando acabamos la 2.0. Puedes verlos fácilmente si vas a la lista de issues, pulsas el botón Milestones y luego pulsas en el título "Versión 2.1".

Ahora mismo hay 7 issues asignados, de los cuales 4 ya están hechos. Por supuesto, podemos añadir o quitar los que queramos, aunque el de las palabras de Wikipedia, estando a medias, yo lo dejaría ya dentro de la 2.1 hasta completar el bloque de 100 que comentabas. Sobre la fecha, probablemente ese bloque de 100 palabras sea el mejor indicador para dar por finalizada la versión. Finales de marzo me parece un tope razonable y, si podemos adelantarlo algo, mejor. Pero todo esto son elucubraciones mías que hago únicamente para que haya una referencia sobre la que podamos construir entre todos.

Para no contaminar el issue, acabo recordando que necesitamos a alguien que nos diga si hay posibilidad de asociar foros o listas de correo a un proyecto en GitHub, o si la forma de comunicación prevista es mediante issues

from rla-es.

Pensando en servicios que se puedan vincular con GitHub, conozco a Gitter que es una especie de chat IRC pero con ciertas mejoras como almacenar las conversaciones en la nube, referir issues, entre otras cosas. Es bastante popular y usado en proyectos grandes como Angular.js y otros.

Un servicio más similar a foros que también se puede vincular a los repositorios u organizaciones de GitHub es Ost.io. Aunque es mucho menos popular y por lo que vi es bastante simple y limitada la funcionalidad de foro. Por ejemplo, según el mismo sitio, éste es uno de los foros más populares.

GitHub es meramente un sistema de versionado de código, el cual le han añadido algunas funcionalidades como la gestión de issues, la wiki, páginas de repositorios, etc.
Por suerte, alrededor de GitHub surgieron muchos servicios adicionales, como los que acabo de mencionar.

from rla-es.

Parece q lo q necesitan es una lista de correos

from rla-es.

Parece q lo q necesitan es una lista de correos

Sí, yo creo que realmente lo único que no nos convence de usar los propios issues para comunicarnos es que la conversación queda registrada como un fallo o mejora.

Podría ser cuestión de acostumbrarnos a verlo de una manera ligeramente diferente. Por ejemplo, @Almorca comentaba esto como origen de este issue:

La duda me ha surgido porque quería comentar que fecha buscar para publicar la versión 2.1 y
que issues deberíamos resolver para darlo por finalizado.

La primera cuestión, la fecha de publicación, podría haberse gestionado creando un issue con el título "Elegir fecha de publicación de la versión 2.1" y asignándolo al propio milestone "Versión 2.1". En realidad, tiene cierto sentido: casi lo primero que hay que resolver para tener lista la versión 2.1 es decidir cuándo la queremos tener lista. 😄

La segunda cuestión, ver qué issues hay que resolver para considerar la versión 2.1 lista, se puede obtener en un momento cualquiera como comenté más arriba ("...vas a la lista de issues, pulsas el botón Milestones y luego pulsas en el título Versión 2.1"). Determinar qué issues nominamos para que se incluyan en la versión 2.1 se podría discutir en cada uno de esos issues. Si alguien (como he hecho yo mismo) marca algún issue para una versión y otros miembros no lo ven correcto, pueden comentarlo en el mismo, o incluso eliminar esa asignación (supongo que no seré el único, además de Santiago Bosio, con permisos para asignar un issue a un milestone, pero si fuera así, hay que pedirle a Santiago que dé permiso a más miembros).

Esto soluciona este ejemplo concreto de Alejandro; habrá otras cosas de las que interese hablar y no consideremos issues. Es cuestión de ir viéndolas y buscar formas de encajarlas con las herramientas que tenemos (repositorio, registro de incidencias y el wiki).

from rla-es.

Una alternativa es usar una sala de charla en jabber.org http://www.jabber.org/faq.html#chatrooms

from rla-es.

Ost.io que comenta @ezeperez26 no tiene mala pinta y se puede usar con la cuenta de github. Otra opción que he visto en algún proyecto es hacer un grupo de Google.

from rla-es.

Usar Gitter o Slack son antipatrones de herramientas de comunicación para
proyectos abiertos:
https://drewdevault.com/2015/11/01/Please-stop-using-slack.html

2016-02-02 10:45 GMT+01:00 Almorca [email protected]:

Ost.io que comenta @ezeperez26 https://github.com/ezeperez26 no tiene
mala pinta y se puede usar con la cuenta de github. Otra opción que he
visto en algún proyecto es hacer un grupo de Google.

—
Reply to this email directly or view it on GitHub
#56 (comment).

Ismael Olea

http://olea.org/diario/

from rla-es.

Interesante artículo de @olea. Concuerdo que no tiene mucho sentido usar herramientas privativas en proyectos de código abierto.
Ost.io es libre según su sitio y hasta tienen el código publicado en GitHub.
Usar algo como Freenode o Jabber no es útil, a menos que algún día coordinemos un horario para encontrarnos varios al mismo tiempo.
Aunque concuerdo con @RickieES, para el caso de la planificación de la versión 2.1 se podría haber creado un issue. Todo depende de las políticas que le demos al gestor de incidencias. Otros proyectos sólo lo usan para reporte de errores, la planificación la gestionan con otras herramientas.

from rla-es.

2016-02-02 15:51 GMT+01:00 Ezequiel [email protected]:

Interesante artículo de @olea https://github.com/olea. Concuerdo que no
tiene mucho sentido usar herramientas privativas en proyectos de código
abierto.

para mí no es tanto problema la licencia del código como de la
transparencia de la comunicación

Usar algo como Freenode http://freenode.net/ o Jabber no es útil, a
menos que algún día coordinemos un horario para encontrarnos varios al
mismo tiempo.

con Jabber sabéis que se pueden tener sesiones abiertas indefinidamente y
desde múltiples dispositivos, con lo que la persistencia de la comunicación
es muuucho más robusta que con IRC.

from rla-es.

Yo coincido con @ezeperez26 en lo de Freenode. Como dice @eksperimental, probablemente lo que querríamos, si no conseguimos apañarnos con los propios issues, sería una lista de correo.

En otros sitios se están usando canales de Telegram, que imagino que es parecido en funcionalidades (envío de archivos e imágenes, histórico, etc., control de acceso por invitación...) a usar Jabber, aunque para crear la cuenta se requiere un teléfono móvil (pero luego no hay que hacerlo público). Es muy cómodo porque funciona en el móvil, en web, con posibilidad de tener varios clientes abiertos simultáneamente de manera completamente independiente (no necesitas tener el móvil encendido ni a mano para tener la versión web abierta en uno, dos o cinco equipos a la vez).

Yo, que ahora mismo ya no tengo cliente Jabber en el móvil, preferiría Telegram. Por supuesto, a quien no usa Telegram habitualmente le pasará lo mismo que a mí con Jabber, pero al revés.

Lo malo de una solución basada en mensajería instantánea es que es relativamente fácil acabar chateando en lugar de hablando de la temática del grupo y suele producirse de una manera tan progresiva que, cuando el desmadre es notorio, nadie suele estar libre de pecado para poder poner orden.

from rla-es.

Mirando de nuevo, Ost.io tampoco me desagradaría mucho si no conseguimos organizarnos con lo que tenemos. Y tampoco descartaría el grupo de Google, que propone @Almorca, que seguramente es lo más cercano a lo que queremos (porque, a todo esto, la idea no es que cualquiera pueda aparecer por el canal de comunicación que sea a proponer o criticar lo que quiera, ¿no? Al fin y al cabo, eso ya lo pueden hacer con los issues de Github y la propia estructura de los issues es un filtro psicológico para que lo que se proponga tenga cierta argumentación). Con el grupo de Google imagino que podemos limitar la suscripción; no sé si con Ost.io también se puede limitar.

from rla-es.

¡Saludos a todos!

Me parece un tema súper interesante. ¿Han platicado sobre usar un canal de IRC que estuviera unido a un grupo de Telegram? Yo pudiera ayudar a gestionar que en Mozilla (MozNet) tuviéramos un canal de IRC que estuviera unido a un grupo de Telegram mediante un "bot".

Espero les agrade la idea, me parece que sería algo muy positivo para todos.

Saludos.
Edgardo

from rla-es.

Perdón por el retraso en comentar sobre esto. Edgardo, ¿qué aporta enlazar un canal de IRC a un grupo de Telegram, si ambos son mensajería instantánea y el segundo mantiene el histórico sin que nadie tenga que permanecer en él conectado, como creo recordar que es necesario con IRC? Lo único que se me ocurre es que así puede participar quien no quiera usar Telegram.

from rla-es.

Tal vez con el aumento de popularidad entre la comunidad de desarrolladores, una buena alternativa podría ser reddit. El contenido queda público y debido a la diversidad de dicha red, es más fácil que alguien tenga una cuenta en reddit que en github. Pero si solo interesa incluir a quienes participan en github, basta con habilitar las notificaciones por correo de github, y eso sería equivalente a tener una lista de correo pública (usando simplemente los issues).

from rla-es.

La unica opcion que veo viable sería una lista de correo. Tener discusiones en los issues seria abusar de ellos, ya que no es la finalidad de los mismos, y puede que terminen aburriendo a la gente que este interesada en contribuir codigo, pero no en discutir si una palabra deberia agregarse o no al diccionario.
Personalmente crear una cuenta en telegram, o reddit, o entrar a un grupo de charla en linea como IRC, no le veo mucho sentido, ya que de poco serviría debatir sobre algo en donde no hay certeza de que todos estén leyendo en ese momento.

from rla-es.

Cambio ligeramente de tema, pero dentro de lo que es la comunicación, o la información más bien. Como quizá hayáis visto, he estado categorizando la mayoría de los issues y pull requests por número de versión en relación a la fecha en que se cerraron, y me he encontrado algunas dudas:

• Algunos de los issues no son tales, sino discusiones, preguntas, etc. que no provocan ningún cambio en el repositorio de ningún tipo. Si no los categorizo, me preocupa que, en una revisión posterior, vuelva a dudar de si me olvidé de categorizarlo o es que no incluía ningún cambio. Podríamos acordar que no se categoriza ningún issue que tenga la etiqueta pregunta, pero no siempre serán preguntas. Por otro lado, podría haber preguntas que finalmente desemboquen en un cambio en el repositorio y, entonces, sí que deben quedar categorizadas en la versión en que se hacen públicos.
• Algunos issues y pull requests provocan cambios en el repositorio, pero no desembocan en cambios prácticos en el diccionario, bien porque se producen en las herramientas o el README.md, o porque (menos frecuentemente) hacen algún cambio en los ficheros, como reordenarlos, particionarlos en varios o recodificarlos. Yo soy partidario de, a pesar de todo, incluirlos como cambios que hay que documentar referidos a una versión, porque, aunque no afecten a nuestros binarios, sí que cambian nuestro código fuente.
• Algunos pull requests acaban siendo descartados, bien porque no sirven en el fondo, o porque tienen algún error de forma que el autor original considera más cómodo corregir en un nuevo PR que modificando el que hay. ¿Deberíamos dejarlos marcados a pesar de todo, o usar la etiqueta no se corregirá?
• Y, en relación con todo lo anterior, alguno de vosotros nos presentó una utilidad que genera un registro de cambios automáticamente a partir de la colección de issues y pull requests. Lo ideal es que las respuestas a mis dudas anteriores sean compatibles con esa herramienta.

from rla-es.

Buenas, respondo por los mismos puntos que mencionas @RickieES

• Se podría renombrar la etiqueta "pregunta" a "preguntas / discusiones". Cuando el resultado de la discusión sea una mejora en el repositorio, se cambia la etiqueta por "mejora" y se las coloca en el milestone que se incluyó la solución.
• Concuerdo que en los releases del proyecto se debe incluir una descripción de todos los cambios realizados en el proyecto, tanto la inclusión de nuevas palabras como los cambios en herramientas. Pero cuando se publican los diccionarios en los repositorios de LibreOffice, Mozilla, etc. al usuario final le interesa sólo los cambios referidos al diccionario, no al proyecto. En ese caso quien sube el diccionario aplica un "filtro" al changelog.
• Considero que los PRs descartados no deberían tener ninguna etiqueta ni estar en ningún milestone. Dicho sea de paso, no le encuentro mucha utilidad a la etiqueta "no se corregirá". Por qué no se corrige? Si el issue no reporta un error, se cierra sin etiqueta y listo. Si es por una cuestión de prioridad, se puede mantener abierto el issue con etiquetas que indiquen la prioridad (por ejemplo, "prioridad baja/media/alta")
• Yo fui quien presentó la herramienta para automatizar la generación del changelog. La verdad es que he dejado de utilizarla. En otros proyectos al changelog lo armo a mano mirando los issues y PRs que se encuentran en el milestone. Para eso previamente se tiene que verificar que el milestone contenga todos los issues y PRs que se incluyeron. Lo bueno de haber usado la herramienta es conocer una forma estándar de redactar los changelogs y estaría bueno que se mantenga. Acerca de convención de changelogs, keepachangelog.com es un buen sitio de referencia.

Saludos!

from rla-es.

Sólo un aporte: desde hace unos meses estoy usando http://riot.im/ que incluye entre otras pasarelas a IRC. Ahora puedo mantenerme conectado a un canal sin perder info.

Me tiene bastante satisfecho.

FYI.

from rla-es.

@olea , lo estoy mirando, pero no sé si aporta gran cosa para los que no damos mucha importancia a la comunicación instantánea para este proyecto. La integración con Github parece limitarse a poder crear issues desde Riot y hacer referencia a los abiertos, no creo que podamos volcar las conversaciones en issues. No obstante, si hay mucha gente interesada en tener conversaciones en tiempo real, puede ser una buena alternativa.

from rla-es.

@RickieES lo bueno de usar Matrix/Riot es que las conversaciones no tienen que ser exclusivamente en tiempo real porque las conexiones son permanentes. Pero vamos, que es sólo por contároslo :)

from rla-es.

Como este tema no lo vamos a avanzar cierro la incidencia para ir dejando más limpio todo.

from rla-es.

Entre unas cosas y otras también me despisté en decir por aquí que hemos improvisado un grupo privado en Telegram O:-)

Si alguien necesita apuntarse que me escriba directamente.

FYI

from rla-es.