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! Tienes algunos puntos muy válidos. También estaba revisando el número total de temas de Contribute > UX y ¡es una barbaridad! 
Quizás el problema que tenemos es que la categoría Contribute > UX está descrita de forma inadecuada, por lo que la gente publica ahí cosas que deberían estar en Contribute > Bug o Contribute > Feature. Así es como la describimos en nuestra documentación interna.
La categoría #ux::category es un poco un punto intermedio entre #feature::category y #bug::category. Por lo general, los problemas menores de visualización irían aquí en lugar de en #bug::category, y sería el lugar para pequeños cambios en funciones existentes. Más temas de ‘calidad de vida’ que de grandes cambios.
Por lo general, el manejo de estos temas seguiría el patrón de la categoría #feature::category - Acerca de la categoría de funciones
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 Contribute > UX puede no ser tan clara para ciertos usuarios, pero una categoría de Sugerencias es bastante clara sobre su propósito.
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í.
3 Me gusta
Profundizando, no estoy seguro @moin 
Creo que el núcleo del problema aquí es:
- Sam recategoriza algo de Contribute > UX → bug
- Sam sabe cómo 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 autocorregirse y hay un ciclo doloroso.
¿Quizás el problema raíz aquí es?
¿Sam debería sentirse libre de recategorizar como vea conveniente, para satisfacer mejor nuestras necesidades comerciales, y no debería disculparse por cada cosa que hace?
2 Me gusta
He estado pensando en este tema durante las últimas semanas mientras participo en discusiones, abordo temas en las categorías Contribute > UX, Contribute > Bug y Contribute > Feature, y creo mis propios temas.
Creo que esto es definitivamente así. Sam y los miembros del equipo son libres de categorizar y etiquetar los temas como consideren oportuno, con el interés de responder al tema y llegar a una resolución. Si los miembros están confundidos sobre estas decisiones, pueden contactar a @moderators.
Este es un gran ejemplo de un tema que pertenece a Contribute > UX. Es pequeño y se trata específicamente de realizar una mejora en la interfaz. También es un gran ejemplo del tipo de colaboración entre miembros de la comunidad y el equipo que nos gusta ver, que conduce a mejoras muy agradables en la calidad de vida. 
Continuando con el ejemplo que Charlie citó, un área en la que nuestro equipo necesita trabajar es en seguir temas como este hasta el final para que puedan cerrarse. Incluso esta colaboración bastante excelente dejó 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 caen entre las grietas, sin importar lo buena que sea la sugerencia o lo pequeño que parezca la solicitud. Después de un tiempo, @moderators pueden ayudar a identificar estos y guiarlos a su destino final.
Actualicé la descripción de la categoría Contribute > UX para hacer público lo que ha sido nuestro enfoque interno para esta categoría. Espero que esto ayude a todos a entender mejor qué va en Contribute > UX en comparación con otras categorías como Contribute > Feature y Contribute > Bug.
Discusión sobre problemas menores de visualización y pequeños cambios en la interfaz de usuario de Discourse, y cómo se presentan las características (incluyendo elementos de lenguaje e interfaz). Más temas de ‘calidad de vida’ que cualquier cosa grande.
Las etiquetas completed o fixed se aplican a los temas en esta categoría dependiendo de la naturaleza del tema.
Házmelo saber si esto no es lo suficientemente claro o si puedes pensar en más refinamientos. Me gustaría dar el mismo tratamiento a Contribute > Bug y Contribute > Feature, pero lo dejaré para otro momento.
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