Sé que sucede cuando alguien de Discourse le da “me gusta” al tema de error publicado en Bug. ¿Utilizan un servicio web para esto y simplemente esperan el primer “me gusta” en una nueva publicación, y se aseguran de que no tenga varios “me gusta” de alguien en CDCK?
SELECT distinct p.user_id, p.created_at granted_at, p.id post_id
FROM badge_posts p
JOIN topics t ON t.id = p.topic_id
JOIN post_actions pa ON pa.post_id = p.id AND
post_action_type_id = (
SELECT id FROM post_action_types WHERE name_key = 'like'
) AND
pa.user_id IN (
SELECT gu.user_id
FROM group_users gu
WHERE gu.group_id = ( SELECT id FROM groups WHERE name ilike 'team' )
)
WHERE category_id = (
SELECT id FROM categories WHERE name ilike 'bug'
) AND p.post_number = 1
(Como comentario adicional, también he creado otras similares para que funcionen a partir de una Reacción específica de un grupo determinado )
@JammyDodger ¡esto es increíble! Todavía no he tenido tiempo de meterme en las consultas de insignias personalizadas, pero esto podría finalmente darme una oportunidad.
Si es posible preguntar, ¿cómo gestionan las incidencias de errores internamente más allá de la insignia? Al menos en el contexto de Meta? ¿Lo añaden manualmente a su cola de incidencias en algún lugar? ¿Utilizan un plugin para enviarlo a su cola de incidencias directamente desde el tema?
También tengo curiosidad por la logística de la gestión de informes de errores y solicitudes de características en Discourse y cómo lo vinculan a sus sistemas de desarrollo/internos.
Son muy divertidas. Y hay muchos ejemplos por ahí si necesitas inspiración o consejos.
La categoría Bug es una gran parte de nuestra cola de errores. Para evitar duplicaciones, a menudo gestionamos el problema dentro del propio tema de Meta (usando susurros, @menciones y asignaciones) y solo dividimos los problemas en un área de equipo si necesitan una conversación o aportación adicional significativa de otros. También recibimos informes de errores a través de canales de clientes, que a menudo también se resuelven ‘en el tema’, a menos que haya varios informes o que ya exista uno público (en cuyo caso, uno se utiliza generalmente como el principal para no dividir demasiado la conversación, y los otros se enlazan). Para los que detectamos nosotros mismos, tenemos un par de temas internos que podemos utilizar para tomar nota de las cosas pequeñas, listas para que alguien las resuelva, y para los más grandes creamos un tema dedicado de la misma manera que la categoría pública Bug.
Generalmente, el flujo es: llega un informe y uno de nosotros intentará reproducirlo y obtener los detalles adicionales necesarios. Una vez confirmado, enviaremos una señal de @mención al grupo/persona relevante para que le dé prioridad y lo asigne. Llega la corrección y se publica en un post para cerrar el tema (con un retraso en el temporizador del tema solo para que podamos confirmar que todo funciona como se espera ).
Feature es un poco diferente, ya que a menudo hay mucho más que discutir internamente. Intentamos mantener los susurros al mínimo en esos temas públicos, y los reservamos para notas breves y para llamar la atención sobre los que están ganando interés adicional (de nuevo, confiables @menciones). De esa manera, no dividimos la conversación entre demasiados lugares. A los gerentes de producto también les gusta interactuar públicamente con ellos para explorar diferentes casos de uso y para tantear las posibilidades (así como para informar a la gente de lo que están pensando sobre el tema, ya que nos gusta ser transparentes cuando podemos ). Si un Feature se convierte en algo que estamos considerando seriamente, tendrá un tema interno donde desarrolladores, diseñadores, gerentes de producto, moderadores de la comunidad curiosos, etc., puedan aportar ideas y maquetas sobre cómo creen que se puede lograr mejor (enlazado al tema de Meta para unirlos).
Ahora que lo he escrito, no estoy seguro de si es útil… Pero házmelo saber si quieres saber algo más.