Una pregunta rápida sobre lo anterior. ¿Qué pasa con los temas autocerrados con una solución? Lógicamente, uno quiere que aparezcan porque tienen una solución, pero si entendí bien, entonces ahora mismo son automáticamente menos prominentes.
15 Me gusta
¿Es esto algo que podemos activar/desactivar con una configuración del sitio? En algunos casos, un tema puede estar Cerrado y Resuelto. Por el contrario, algunos usuarios pueden esperar que eso esté más alto en los resultados.
Estoy muy contento de ver que la búsqueda recibe atención. Poder buscar específicamente por categoría ya es una gran ventaja para nuestro caso de uso.
Lo único en lo que me encantaría ver una mejora es en los errores comunes de ortografía. Algunos motores de búsqueda me han malacostumbrado hasta el punto de que golpeo perezosamente las teclas hasta que una mezcla de letras que solo se parecen vagamente a la palabra original está en la barra de búsqueda 
. No espero que se iguale eso, pero las mejoras en esa área serían un gran paso adelante.
9 Me gusta
¡Opinión audaz! Creo que sería mejor mantener la coherencia (es decir, sin opción por sitio) y:
- Aumentar la prioridad de las publicaciones cerradas que están resueltas (a mayor que las publicaciones abiertas).
- Añadir la opción de un temporizador (idealmente, por categoría y/o por etiqueta) para archivar automáticamente las publicaciones cerradas.
- Dentro de las publicaciones archivadas, priorizar aquellas con soluciones, pero no tanto como para que aparezcan por encima de las publicaciones no archivadas.
Descargo de responsabilidad: ¡Sí, quiero esa función de archivo automático para mi propio sitio! Pero creo que tiene sentido en general. Todo lo que esté respondido pero probablemente sea irrelevante debería ser apartado. Y si no quieres eso (tus preguntas resueltas son perennes), no habilites el archivador.
8 Me gusta
¿Por qué, porque facilita el desarrollo? ¿O porque facilita la vida de los usuarios cuando saltan entre Discourses? ¿Alguna otra cosa?
La primera razón no es una razón en absoluto, siempre que la carga de trabajo sea humana y la tarea sea posible en esta realidad. La segunda es una buena razón para MS o Apple, que no quieren luchar demasiado con los clientes, pero por lo demás, como administrador y creador de contenido, quiero servir a mis usuarios, no mantener las cosas similares a aquí, allí o en cualquier otro lugar 
Entonces, la tercera opción es la interesante.
4 Me gusta
Ambas cosas. Y porque reduce la complejidad administrativa. En lugar de un montón de opciones más (y la oportunidad de ni siquiera darse cuenta de que hay una configuración para hacer lo que quieres), da un paso atrás y encuentra un patrón general para que el patrón deseado simplemente funcione en la mayoría de los casos.
7 Me gusta
Ese es definitivamente un punto fuerte.
Pero. ¿Podríamos usar otra solución, pero familiar: la configuración oculta?
Veo aquí dos estrategias diferentes ahora:
- ¿Deberían los administradores tener manos libres para ajustar partes importantes, como los resultados de búsqueda, porque las necesidades de la comunidad son diferentes y no dependen de la plataforma (esa es una cuestión de codificación/desarrollo)?
- ¿Deberían los administradores ser tratados como otros usuarios y mantener las cosas ordenadas y limpias en cuanto a la experiencia de usuario, y dejar que CDCK decida qué, dónde y por qué?
Mirando Support, ambas formas tienen pros y contras Pero aún así, la primera dirección es una especie de parte del mundo del código abierto, mientras que la segunda es el camino de Apple.
Más opciones generan más preguntas y problemas creados por administradores no tan habilidosos como yo. Más opciones pueden dar mejores resultados para los usuarios y visitantes. Entonces, ¿qué?
Para mí la pregunta es muy fácil: quiero obtener una búsqueda lo más potente posible, y si cerrar un tema disminuye su clasificación en los resultados de búsqueda, ya no cierro temas o muy raramente. Elección fácil, pero entonces tengo que actuar debido a las limitaciones del software, no por las necesidades de la comunidad.
Entonces, las estrategias son algo diferente de las tácticas
4 Me gusta
Tenemos muchos precedentes para perillas aquí, tenemos prioridad de búsqueda por categoría que cualquier administrador puede configurar.
Ciertamente no estoy en contra de algunas perillas más sobre cómo la bonificación “archivado/cerrado/resuelto” sube (o baja) en los resultados de búsqueda.
Es un poco una misión secundaria, ¿recomiendo que la dividamos en otro tema con una propuesta clara sobre qué configuración tendría sentido?
8 Me gusta
Me gustaría averiguar cuáles podrían ser los próximos pasos para un cambio aquí, dado el interés expresado hasta ahora.
Actualmente, esta es la lógica:
según @sam:
¡nota el caso límite aquí!
En meta… dado el ruido en Support, tendemos a querer darle baja prioridad… una vez que se le da baja prioridad, la bonificación de clasificación cerrada ya no tiene efecto…
Así que algo más a considerar es cómo esto interactúa con los pesos de las categorías.
Creo que un enfoque iterativo aquí podría ser el siguiente:
- Simplemente agregue un caso para resuelto
WHEN topics.solved then 1.1 - Cambie los pesos de archivado, cerrado y resuelto para que sean multiplicadores del peso de la categoría y entre sí.
- Haga que los multiplicadores de peso de archivado, cerrado y resuelto se puedan configurar a través de la configuración del sitio.
Tal vez tenga sentido hacer todo esto a la vez. O tal vez hagamos (1) y (2) primero y esperemos antes de hacerlos configurables. ¿Qué opinas @sam?
3 Me gusta
Usar multiplicadores parece un enfoque generalmente bueno, pero creo que es difícil expresar lo que sugería anteriormente.
cerrado no resuelto < abierto no resuelto < abierto resuelto < cerrado resuelto
Cerrado debería ser un aumento de prioridad para las publicaciones resueltas pero una disminución para las no resueltas.
Las publicaciones cerradas sin solución no valen casi nada: alguien más tuvo este problema, pero no hay respuesta aquí y no puedes proporcionar una. Las publicaciones cerradas con soluciones, por otro lado, son oro. No solo están resueltas, sino que lo están de forma definitiva.
4 Me gusta
OK, y además, antes también mencionaste temas archivados:
Entonces, si entiendo correctamente, ¿preferirías clasificar las cosas de esta manera?
(De mayor a menor)
- cerrado resuelto
- abierto resuelto
- abierto no resuelto
- cerrado no resuelto
- archivado resuelto
- archivado no resuelto
(Y luego añadir la complejidad en capas de las clasificaciones por categoría de alguna manera también)
2 Me gusta
Sí, básicamente, aunque el orden de las publicaciones archivadas probablemente no importe:
Las publicaciones archivadas con soluciones son probablemente irrelevantes pero pueden ser históricamente interesantes. Las publicaciones archivadas sin soluciones son básicamente lo mismo: si buscas en el archivo, es probablemente por historia, por lo que el estado resuelto es información, pero si importa cuál es, debes incluirlo explícitamente en tu consulta.
2 Me gusta
¿Utiliza usted ponderaciones de categoría? Si es así, ¿tiene alguna opinión sobre si esa ponderación debería anular los pesos basados en el estado como están ahora o ser multiplicativa?
1 me gusta
Creo que el interruptor para buscar en una categoría específica es suficiente y podría ser bueno descartar ese peso al buscar (porque la gente busca soluciones, no categorías o temas/categorías sugeridos).
Mis dos centavos, estoy totalmente de acuerdo con lo que estás haciendo aquí 
2 Me gusta
Sí, definitivamente las uso. Tenemos algunas categorías de “flujo de trabajo” que básicamente nunca deberían aparecer a menos que se soliciten, y otras que son anuncios y noticias que son más importantes.
Me lo estoy inventando ahora mismo, así que me reservo el derecho de ser inestable en mi opinión en el futuro, pero siento que quiero que las ponderaciones de las categorías anulen todas las ponderaciones de estado del tema, excepto las archivadas. Estoy pensando en el caso de las noticias. Estas deberían aparecer en lo alto de los resultados mientras estén frescas, pero no en absoluto después de un período de tiempo. Y archivar publicaciones podría ser la forma en que cada sitio especifica qué significa “un período de tiempo” allí.[1]
Alternativamente, y quizás más simple: simplemente haz que las ponderaciones de las categorías prevalezcan, y luego introduce una opción por categoría para preferir las publicaciones frescas, y si está marcada, ten un multiplicador que disminuya con el tiempo (de 2x a 0.5x, por ejemplo).
¡Y luego todavía está la solicitud de función de archivo automático en un temporizador, pero detalles, detalles! ↩︎
2 Me gusta
OK, lo que entiendo es que los pesos de categoría deberían tener prioridad.
Creo que los pesos de resuelto/cerrado/archivado aún deberían aplicarse dentro de una categoría.
También entiendo lo del temporizador automático de archivo… es complementario, pero creo que podemos avanzar aquí primero sin él.
1 me gusta
Aquí discreparía. Un tema podría tener una buena respuesta, pero el OP no se molestó en marcarla como solución/las soluciones no estaban disponibles si es un tema antiguo, etc.
Un tema abierto tiene la ventaja de que puedes darle un empujón, pero no le daría demasiado peso a eso. Preferiría ver el contenido más relevante basado en palabras clave.
En cuanto a archivado, estoy de acuerdo: para mí es contenido que ya no es relevante y puede tener menos peso.
2 Me gusta
¿Por qué se cerraría un tema así? (Y, preventivamente: “Porque el sitio está configurado para cerrar temas después de N días” es una respuesta a cómo se cerró el tema, no por qué.)
3 Me gusta
Creo que para que este cambio sea manejable, la fase cero es la trivial:
- Añadir ajuste del sitio
prioritize_solved_topicspor defectotrue - Cuando se establece en
true, dar asolved1.1 incondicionalmente.
No resuelve todas las peculiaridades aquí, pero nos daría un progreso razonable rápidamente.
El problema es que, desde una perspectiva de extensibilidad, este no es un cambio fácil en absoluto.
No hay una columna “solved” en la tabla de temas, lo que estamos atrapados haciendo aquí es inyectar algún tipo de unión desde “solved” a los campos personalizados del tema… esto significa que este SQL necesita ser transformado de una manera bastante elaborada:
O bien
-
Necesitamos inyectar un
LEFT JOINen el plugin “solved”LEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id -
Necesitamos transformar esta condición
CASE, lo que probablemente significa hacer que toda la declaraciónCASEsea componible utilizando un plugin.
Alternativamente, podríamos salirnos con la nuestra con algo como CASE EXISTS(...) THEN 1.1, lo que elimina la necesidad de un left join pero conlleva sus propios riesgos.
Pensaré en este problema, el enorme desafío aquí es descubrir cómo no crear un gran desorden al agregar este soporte dado que “core” no sabe nada sobre los temas resueltos.
8 Me gusta
@mcwumbly es de esos en los que hacer el trabajo es en realidad más fácil que especificar el trabajo…
Hice un intento en:
7 Me gusta
¡Eso me pasa a mí en casi todos los casos! Casi nunca puedo descifrar la especificación hasta que he escrito el código que estoy bastante seguro de que funciona. Esto es (en parte) porque normalmente escribo código para una especificación que no entiendo. Un par de veces he podido escribir las especificaciones primero como un adulto, pero es bastante raro.
Me alegra saber que al menos a ti también te pasa a veces. 
5 Me gusta