Se siente un poco extraño elegir una categoría basándose en “quién es el más probable que lo solucione”. ¿También dirías que un foro en blanco debido a un display: none global no es un error porque un diseñador lo solucionará?
Y por supuesto, puedes decir “no importa, simplemente selecciona uno, podemos moverlo”, pero esto solo ayuda para publicar. Cuando intento encontrar informes anteriores, buscaría ambos problemas en UX. ¿Sería posible rastrear la responsabilidad de la solución de forma independiente de las categorías?
10 Me gusta
Estoy de acuerdo contigo, esto es extra confuso, es muy difícil para los operadores saber qué hacer aquí.
@tobiaseigen / @jordan.vidrine ¿alguna idea sobre este problema?
@Moin ¿alguna sugerencia sobre cómo podría funcionar mejor?
Supongo que una alternativa es simplemente tener las cosas en feature/bug incondicionalmente y usar etiquetas para indicar la experiencia de usuario.
Es un tema difícil, sin duda.
4 Me gusta
Me parece una buena solución. Es obvio a qué categoría publicar y aquellos a quienes les importa la UX pueden seguir esa etiqueta. ¡Otra ventaja es que podemos eliminar una categoría!
No estoy seguro de cómo separar los temas que actualmente están en UX y que probablemente querrían ir a Bug o Feature. Podría ser un buen ejercicio revisar y limpiar todo eso.
4 Me gusta
Algunas reflexiones de mi parte:
- Creo que dividir más de 3000 temas en solo 2 categorías es mucho trabajo, y me pregunto quién tendrá tiempo para asumir esta tarea.
- Además, no creo que todos los temas de UX se puedan dividir fácilmente en Característica (Feature) y Error (Bug). Para mí, un informe sobre un texto que no se puede traducir no es realmente un informe de error[1]. Del mismo modo, señalar un texto incomprensible u obsoleto no es una solicitud de característica ni un informe de error[2]. De manera similar, las descripciones de experiencias de usuario que no contienen ningún error ni una sugerencia de mejora concreta no encajan en Característica o Error[3].
- No sé cómo han manejado esto hasta ahora, pero tuve la impresión de que los desarrolladores, cuando era necesario, también trabajaban en temas de UX, y viceversa. Me pregunto si sería posible mantener las cosas como estaban, con el grupo que supervisa la categoría simplemente informando al otro grupo si es necesario, sin mover la publicación. Sin embargo, no puedo evaluar esto completamente, ya que no conozco los procesos anteriores ni los actuales.
5 Me gusta
¡Gracias Moin! Haces buenos puntos. Yo también estaba mirando el número total de temas de UX y ¡es mucho! 
Quizás el problema que tenemos es que la categoría UX está inadecuadamente descrita y, por lo tanto, la gente publica cosas allí que deberían estar en Bug o Feature. Así es como la describimos en nuestra documentación interna.
La categoría UX es un punto intermedio entre la categoría Feature y la categoría Bug. Generalmente, los problemas de visualización menores irían aquí en lugar de Bug, y sería el hogar de pequeños cambios en las características existentes. Temas más de “calidad de vida” que algo grande.
Generalmente, el manejo de estos temas seguiría el patrón de la categoría Feature - Acerca de la categoría de características
Etiquetado
hmmm, este lo clasificaría como un error… desde un punto de vista puramente práctico, pero lo triado con mucha más frecuencia por mí porque la experiencia de usuario atrae cosas más vagas.
En este caso, ese problema de la insignia me parece un error de traducción.
En realidad, también me parece un error, nada está abierto a la interpretación aquí, nuestro texto está claramente mal y necesita ser actualizado.
Esto, sin embargo, está muy en el tema de la experiencia de usuario para mí, es una discusión abierta sobre un punto de dolor sin recomendaciones concretas todavía. Nos está dando una historia y un lugar para extraer temas de errores/funciones particulares en el futuro.
Quizás todo lo que necesitamos aquí es aclarar mejor las reglas, dejar la experiencia de usuario para discusiones abiertas y no estructuradas e historias de usuario, y mantener los “defectos claros” en errores… y las “listas de deseos claras” en funciones.
Entiendo que todo es muy gris en este mundo, es difícil agitar una varita mágica y arreglarlo todo.
Sin embargo, ser más claros sobre nuestras expectativas ayudará sin duda.
7 Me gusta
Ustedes están eludiendo a los usuarios ahora. No podemos (y no lo haremos) saber cómo una empresa asigna o clasifica las cosas. Es algo totalmente interno. Todo lo que podemos hacer es adivinar si algo es un error, un problema de UX o algo completamente diferente. Y los moderadores y el personal hacen su magia después de eso, como está planeado en el núcleo mismo de Discourse.
Entonces, ¿este tema es realmente para el personal y los usuarios avanzados, y el resto de los mortales podemos dejar de seguirlo, o alguien realmente piensa que yo, que no puedo saber la diferencia entre una imagen y una imagen dependiendo de si algo sucede a nivel de archivo o contenedor, tengo la capacidad de preguntarme qué posición dentro de CDCK se encargará de un problema?
A un nivel más general, aquí hay dos aspectos, al menos (como todo el mundo sabe):
- las categorías no son cajas lógicas donde hay límites estrictos
- para qué usuarios están hechas las categorías, públicas o internas
No lo sé… He seguido la política donde uso
- soporte si no sé si el problema soy yo,
- UX si tengo la sensación de que algo está planeado para funcionar de esa manera
- error si algo dejó de funcionar o rompe lugares por completo
Pero nunca elegiré una categoría dependiendo de quién en qué posición intentará cuidarla. Es puramente una cuestión gerencial.
2 Me gusta
Me gusta la idea de ux como etiqueta (¿y tal vez tener dev como etiqueta también?), pero estoy de acuerdo en que podría haber casos de UX que sientan que realmente no pertenecen a una categoría diferente.
Y algunos temas pueden ser técnicamente una característica, pero son tan pequeños que se sentirían fuera de lugar en la categoría de características para votar, por ejemplo: Clickable components instead of just the Edit button
¿Pero tal vez no deberíamos preocuparnos? ¿Y cualquier problema que pida cambiar algo pertenece a la categoría de características, sin importar cuán pequeño sea?
¿O tal vez deberíamos tener una categoría “Sugerencias”, para cosas que no están rotas, no son una solicitud de característica completa y no se tratan de cómo hacer las cosas? Y luego podemos etiquetarlo internamente como dev o ux.
Editar: me di cuenta de que ya tenemos una etiqueta ux, simplemente está infrautilizada en este momento.
4 Me gusta
Una categoría de Sugerencias parece importante. La tengo en mis 2 comunidades.
A veces, una etiqueta puede pasarse por alto o la categoría UX puede no ser tan clara para ciertos usuarios, pero una categoría de Sugerencias es bastante clara sobre para qué sirve.
1 me gusta
Realmente no creo que necesitemos cambiar mucho las categorías aquí, han estado funcionando bien durante un tiempo y la descategorización ocurre, pero no a un ritmo agobiante por lo que puedo ver. Si las menciones, etiquetas y asignaciones no son suficientes para el triaje interno, siento que algo está saliendo mal… porque tenemos muchas opciones allí.
2 Me gusta
Profundizando, no estoy seguro @moin 
Creo que el núcleo del problema aquí es:
- Sam recategoriza algo de UX → Bug
- Sam sabe que tocar cualquier cosa sobre la publicación de alguien puede hacer que se sienta mal, o que sienta que cometió un error
- Sam se disculpa
- Luego, los usuarios se confunden, quieren autocorrección y hay un ciclo doloroso.
¿Quizás el problema de raíz aquí es?
¿Sam debería sentirse libre de recategorizar como le parezca, para satisfacer mejor nuestras necesidades comerciales, y no debería disculparse por las cosas cada vez que lo hace?
2 Me gusta
He estado pensando en este tema durante las últimas semanas mientras participo en discusiones, abordo temas en las categorías UX Bug Feature y creo mis propios temas.
Creo que este es definitivamente el caso. Sam y los miembros del equipo son libres de categorizar y etiquetar temas como mejor les parezca, en aras de responder al tema y llegar a una resolución. Si los miembros están confundidos acerca de estas decisiones, pueden comunicarse con @moderators.
Este es un gran ejemplo de un tema que pertenece a UX. Es pequeño y se trata específicamente de hacer una mejora en la interfaz. También es un gran ejemplo del tipo de colaboración entre los miembros de la comunidad y el equipo que nos gusta ver, que conduce a mejoras de calidad de vida muy agradables. 
Continuando con el ejemplo que citó Charlie, un área en la que nuestro equipo necesita trabajar es en dar seguimiento a temas como este hasta el final para que puedan cerrarse. Incluso esta excelente colaboración quedó con algunos cabos sueltos. Esto es natural en el flujo y reflujo de la discusión y la colaboración aquí, y nuestros ingenieros y diseñadores están ocupados. Como resultado, las mejoras de UX a veces se pierden, sin importar cuán buena sea la sugerencia o cuán pequeña parezca la solicitud. Después de un tiempo, @moderators puede ayudar a identificar estas y guiarlas a casa.
Actualicé la descripción de la categoría UX para hacer pública cuál ha sido nuestro enfoque interno para esta categoría. Espero que esto ayude a todos a comprender mejor qué va en UX frente a otras categorías Feature y Bug.
Discusión sobre problemas menores de visualización y cambios pequeños en la interfaz de usuario de Discourse, y cómo se presentan las características (incluidos el lenguaje y los elementos de la interfaz de usuario). Más temas de ‘calidad de vida’ que nada importante.
Se aplican las etiquetas completed o fixed a los temas de esta categoría dependiendo de la naturaleza del tema.
Avísame si esto no está lo suficientemente claro o si puedes pensar en más refinamientos. Me gustaría darles el mismo tratamiento a Bug y Feature, pero por ahora me abstendré de hacerlo.
Creo que también deberíamos usar más la etiqueta ‘ux’. Sería útil para priorizar en mi opinión, algo puede ser un tema de soporte o error pero pertenece a UX. Esto también resolvería la duda de “esto es un error pero es algo visual, ¿debería estar en Bug o en UX”.
=> hazlo un error pero ponle una etiqueta ux
Creo que la categoría UX debería ser principalmente sugerencias de mejoras, cosas que no están claras. No cosas que están rotas.
Al menos esa distinción tiene sentido para mí.
3 Me gusta
Estoy de acuerdo en usar más la etiqueta ux, ¡en las tres categorías! Las personas a las que les importa mucho la experiencia de usuario pueden seguir esa etiqueta.
Parece que todavía no estamos completamente alineados: en mi opinión, UX puede contener tanto errores como solicitudes de funciones, pero tienen que ser pequeñas mejoras de “calidad de vida” y nada grande. Si algo está realmente roto en la interfaz de usuario, va en Bug. Si es un proyecto importante (por ejemplo, permitir la edición de la meta descripción de una etiqueta), va en Feature.
¿Cómo mejorarías la descripción de la categoría UX para que coincida con tu comprensión de las cosas?
Buena pregunta. Yo diría algo como…
Un tema de UX se utiliza cuando el producto funciona técnicamente como se esperaba, pero el diseño, la interacción o el flujo crean fricción, confusión o ineficiencia innecesarias para los usuarios.
También estoy de acuerdo con que contenga:
Pero creo que cualquier cosa que esté realmente rota, incluso si es pequeña, debería ser simplemente un error con una etiqueta de UX.
3 Me gusta
¿Qué tal esto para una nueva descripción de UX? Se siente un poco forzado pero más conciso. ¿Creo que funciona? (Publiqué un UX tema propio para informar que las etiquetas no se muestran correctamente en los banners de las categorías)
Original:
Discusión sobre la interfaz de usuario de Discourse y cómo se presentan las funciones (incluyendo el idioma y los elementos de la interfaz de usuario).
Actual:
Discusión sobre problemas menores de visualización y pequeños cambios en las funciones existentes de la interfaz de usuario de Discourse, y cómo se presentan las funciones (incluyendo el idioma y los elementos de la interfaz de usuario). Más temas de “calidad de vida” que algo importante.
Las etiquetas completed o fixed se aplican a los temas de esta categoría dependiendo de la naturaleza del tema.
Nuevo sugerido:
Los temas de UX se utilizan cuando Discourse técnicamente funciona según lo previsto, pero el diseño, la interacción o el flujo crean fricción, confusión o ineficiencia innecesarias para los usuarios. También para pequeñas mejoras de “calidad de vida”. Las etiquetas completed o fixed se aplican según la naturaleza del tema.
1 me gusta
Gracias, me parece bien 
¡Genial! He hecho el cambio.
(aparte: es muy raro que los cambios en la descripción tarden un par de minutos en aparecer en el banner de la categoría. ni siquiera un refresco forzado lo hace.)
2 Me gusta