Revisión de código: Issues Migrator

Mis disculpas si este no es el lugar adecuado para publicar esto, pero ¿existe algún plan para incluir nuevamente una funcionalidad similar al migrador de Issues de GitHub a Discourse? Nos encantaría utilizarla en el proyecto kubernetes y en otros proyectos de código abierto que conozco.

Cerramos los problemas de soporte que se publican en GitHub y pedimos a los usuarios que los vuelvan a publicar en nuestro foro de Discourse. Si existiera alguna capacidad de migración integrada, podríamos agregar un comando de bot para moverlos automáticamente cuando se marquen y proporcionar un enlace al usuario.

6 Me gusta

¡Oh, parece que estás buscando una solución más permanente aquí! Que nosotros escaneemos regularmente la lista de problemas y copiemos/cerramos.

Supongo que, en términos de flujo de trabajo, una buena solución sería que etiquetarás las cosas con kind/support y, si vemos nuevos problemas de soporte, los cerraremos en GitHub, los abriremos en Discourse y añadiremos una publicación que enlace a Discourse.

Sería necesario realizar bastante trabajo para que algo así funcione; tendríamos que ampliar nuestro plugin Discourse ↔ GitHub (GitHub - discourse/discourse-github · GitHub), ya que actualmente solo hacemos enlaces de retorno. Pero es ciertamente factible.

No creo que esto encaje en el plugin de revisión de código, por lo que habría que volver a etiquetar.

¿Es este el tipo de trabajo que estás considerando patrocinar? Si es así, puedo mover esto a la bandeja de entrada de nuestro equipo.

3 Me gusta

Mis disculpas por la demora en la respuesta.

Aclaración: no estoy muy familiarizado con el funcionamiento del plugin discourse-github, pero una idea potencial podría ser: si un proyecto puede desencadenar una llamada (webhook) que contenga el número del problema en cuestión, ¿podría recuperar el problema, crear una publicación como un tema y luego publicar un enlace en el problema de vuelta al tema?

De esta manera, lo que desencadena la acción de recuperar el problema y los comentarios recae en el responsable del repositorio. Podría ser una acción de GitHub, un plugin probot, etc. También pueden decidir si desean cerrar automáticamente el problema o dejarlo abierto.

2 Me gusta

Para dar seguimiento a la última parte, por ahora no… aunque potencialmente en el futuro sí.