Pergunta rápida sobre o acima. E quanto aos tópicos auto-fechados com uma solução? Logicamente, queremos que eles apareçam porque têm uma solução, mas se entendi corretamente, então no momento eles são automaticamente menos proeminentes.
15 curtidas
Isso é algo que podemos ativar/desativar com uma configuração do site? Em alguns casos, um Tópico pode ser Fechado e Resolvido. Inversamente, alguns usuários podem até esperar que isso esteja mais alto nos resultados.
Estou muito feliz em ver a busca recebendo atenção. Ser capaz de pesquisar especificamente por categoria já é um grande ponto positivo para o nosso caso de uso.
A única coisa que eu adoraria ver um pouco de melhoria são erros comuns de ortografia. Alguns motores de busca me mimaram a ponto de eu preguiçosamente apertar as teclas até que uma mistura de letras que apenas vagamente se assemelham à palavra original esteja na barra de pesquisa 
. Não espero que isso seja correspondido, mas melhorias nessa área seriam um grande passo à frente.
9 curtidas
Opinião polêmica! Acho que seria melhor manter a consistência (ou seja, sem opção por site) e:
- Aumentar a prioridade de posts fechados que estão resolvidos (para ser maior que posts abertos).
- Adicionar a opção de um temporizador (idealmente, por categoria e/ou por tag) para arquivar automaticamente posts fechados.
- Dentro de posts arquivados, priorizar aqueles com soluções — mas não tanto a ponto de aparecerem antes de posts não arquivados.
Aviso: sim, eu quero esse recurso de arquivamento automático para o meu próprio site! Mas acho que faz sentido em geral. Qualquer coisa que foi respondida, mas provavelmente irrelevante, deve ser removida. E se você não quiser isso (suas perguntas resolvidas são perenes), não ative o arquivador.
8 curtidas
Por quê, porque facilita para o lado do desenvolvedor? Ou porque facilita a vida dos usuários quando eles pulam entre Discourses? Algo mais?
A primeira razão não é razão alguma — desde que a carga de trabalho seja humana e uma tarefa seja possível nesta realidade. A segunda é uma boa razão para a MS ou Apple, que não querem lutar muito com os clientes, mas, caso contrário — como administrador e criador de conteúdo, quero servir meus usuários, não manter as coisas semelhantes aqui, ali ou em qualquer outro lugar 
Então — a terceira opção é a interessante.
4 curtidas
Ambos. E porque reduz a complexidade administrativa. Em vez de um monte de opções adicionais (e a oportunidade de nem perceber que existe uma configuração para fazer o que você quer), dê um passo para trás e encontre um padrão geral para que o padrão desejado simplesmente funcione na maioria dos casos.
7 curtidas
Esse é definitivamente um ponto forte.
Mas. Poderíamos usar outra solução, ainda familiar: configurações ocultas?
Vejo aqui duas estratégias diferentes agora:
- os administradores devem ter mãos livres para ajustar partes importantes, como resultados de pesquisa, porque as necessidades da comunidade são diferentes e não dependem da plataforma (essa é uma questão de codificação/desenvolvimento)
- os administradores devem ser tratados como outros usuários e manter as coisas organizadas e com uma experiência do usuário limpa, e deixar o CDCK decidir o quê, onde e por quê
Olhando para o Support, ambas as formas têm prós e contras Mas ainda assim — a primeira direção é meio que mais parte do mundo open source, enquanto a última é o jeito da Apple.
Mais opções geram mais perguntas e problemas criados por administradores não tão habilidosos como eu. Mais opções podem dar melhores resultados para usuários e visitantes. Então?
Para mim a questão é muito fácil: quero ter a pesquisa mais poderosa possível, e se fechar um tópico diminuir seu ranking nos resultados de pesquisa, eu não fecho mais os tópicos ou muito raramente. Escolha fácil, mas então tenho que agir por causa das limitações do software, não por causa das necessidades da comunidade.
Então — estratégias são coisas diferentes de táticas
4 curtidas
Temos muitos precedentes para controles aqui, temos prioridade de pesquisa por categoria que qualquer administrador pode configurar.
Eu certamente não sou contra alguns controles adicionais sobre como o bônus “arquivado/fechado/resolvido” aumenta (ou diminui) nos resultados de pesquisa.
É um pouco de missão secundária, recomendamos que a dividamos em outro tópico com uma proposta clara sobre qual configuração faria sentido?
8 curtidas
Gostaria de definir quais seriam os próximos passos para uma mudança aqui, dada a atenção expressa até agora.
Atualmente, esta é a lógica:
conforme @sam:
note o caso extremo aqui!
Em meta… dada a poluição em Support, tendemos a querer despriorizá-la… uma vez despriorizada, o bônus de classificação fechado não tem mais efeito…
Portanto, algo mais a considerar é como isso se relaciona com os pesos das categorias.
Acho que uma abordagem iterativa aqui poderia ser a seguinte:
- Apenas adicionar um caso para resolvido
WHEN topics.solved then 1.1 - Alterar os pesos de arquivado, fechado e resolvido para serem multiplicadores do peso da categoria e entre si.
- Tornar os multiplicadores de peso de arquivado, fechado e resolvido configuráveis nas configurações do site
Talvez faça sentido fazer tudo isso de uma vez. Ou talvez façamos (1) e (2) primeiro e esperemos antes de torná-los configuráveis. O que você acha @sam?
3 curtidas
Usar multiplicadores parece uma abordagem geralmente boa, mas acho difícil expressar o que eu estava sugerindo acima.
fechado não resolvido < aberto não resolvido < aberto resolvido < fechado resolvido
Fechado deve ser um aumento de prioridade para posts resolvidos, mas uma diminuição para os não resolvidos.
Posts fechados sem solução são quase inúteis — outra pessoa teve esse problema, mas não há resposta para ele aqui, e você não pode fornecer uma. Posts fechados com soluções, por outro lado, são ouro. Eles não são meramente resolvidos, mas definitivamente o são.
4 curtidas
OK, e além disso, você mencionou tópicos arquivados anteriormente também:
Então, se entendi corretamente, você prefere classificar as coisas desta forma?
(Do maior para o menor)
- fechado resolvido
- aberto resolvido
- aberto não resolvido
- fechado não resolvido
- arquivado resolvido
- arquivado não resolvido
(E depois adicionar a complexidade em camadas de classificações por categoria de alguma forma também)
2 curtidas
Sim, basicamente, embora a ordem das postagens arquivadas provavelmente não importe:
Postagens arquivadas com soluções são provavelmente irrelevantes, mas podem ser historicamente interessantes. Postagens arquivadas sem soluções são basicamente as mesmas — se você está procurando no arquivo, é provavelmente por motivos históricos, então o estado resolvido é uma informação, mas se importa qual delas é, você deve incluir isso explicitamente em sua consulta.
2 curtidas
Você usa ponderações de categoria? Se sim, você tem alguma opinião sobre se essa ponderação deve substituir os pesos baseados no estado como estão agora ou ser multiplicativa?
1 curtida
Eu acho que o interruptor para pesquisar em uma categoria específica é suficiente e poderia ser bom descartar esse peso na pesquisa (porque as pessoas estão procurando soluções, não categorias ou tópicos/categorias sugeridos).
Minhas duas moedas, concordo totalmente com o que você está fazendo aqui 
2 curtidas
Sim, definitivamente as usamos. Temos algumas categorias de “fluxo de trabalho” que basicamente nunca devem aparecer, a menos que sejam solicitadas, e outras que são anúncios e notícias que são mais importantes.
Estou inventando isso agora mesmo, então me reservo o direito de ser inconstante em minha opinião no futuro, mas sinto que quero que os pesos das categorias substituam todos os pesos de status do tópico, exceto arquivados. Estou pensando no caso de notícias aqui. Elas devem aparecer em destaque nos resultados enquanto estão frescas, mas não aparecerem após um certo tempo. E arquivar posts pode ser a maneira de cada site especificar o que “um certo tempo” significa ali.[1]
Alternativamente, e talvez mais simples: apenas ter pesos de categoria que prevaleçam, e então introduzir uma opção por categoria para preferir posts recentes, e se essa opção for marcada, ter um multiplicador que diminui com o tempo (de 2x para 0,5x, por exemplo).
E ainda há a solicitação de arquivamento automático por tempo, mas detalhes, detalhes! ↩︎
2 curtidas
OK, o que estou ouvindo é que os pesos das categorias devem ter precedência.
Acho que os pesos de resolvido/fechado/arquivado ainda devem ser aplicados dentro de uma categoria.
Também ouvi o que você disse sobre o temporizador automático de arquivamento… é complementar, mas acho que podemos ter algum progresso aqui primeiro sem ele.
1 curtida
Eu discordo aqui. Um tópico pode ter uma boa resposta, mas o OP não se incomodou em marcá-la como solução/soluções não estavam disponíveis se for um tópico antigo, etc.
Um tópico aberto tem a vantagem de que você pode impulsioná-lo, mas eu não daria muito peso a isso. Eu preferiria ver o conteúdo mais relevante com base em palavras-chave.
Em relação ao arquivado, concordo - para mim, este é conteúdo que não é mais relevante e pode ter menos peso.
2 curtidas
Por que tal tópico seria fechado? (E, preventivamente: “Porque o site está configurado para fechar tópicos após N dias” é uma resposta a como o tópico foi fechado, não por quê.)
3 curtidas
Acho que para manter essa mudança gerenciável, a fase zero é trivial:
- Adicionar configuração do site
prioritize_solved_topicscom valor padrãotrue - Quando definido como true, dar aos tópicos resolvidos 1.1 incondicionalmente.
Isso não resolve todas as peculiaridades aqui, mas nos daria um progresso razoável rapidamente.
O problema é que, de uma perspectiva de extensibilidade, esta não é uma mudança fácil.
Não há uma coluna “solved” na tabela de tópicos, o que estamos presos fazendo aqui é injetar algum tipo de junção de “solved” nos campos personalizados do tópico… isso significa que este SQL precisa ser transformado de uma maneira bastante elaborada:
Ou
-
Precisamos injetar um
LEFT JOINno pluginsolvedLEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id -
Precisamos transformar esta instrução
CASE, o que provavelmente significa tornar toda a instrução CASE compósita usando um plugin.
Alternativamente, podemos conseguir algo como CASE EXISTS(...) THEN 1.1, que elimina a necessidade de um left join, mas vem com seus próprios riscos.
Vou pensar sobre este problema, o enorme desafio aqui é descobrir como não criar uma bagunça gigante adicionando este suporte, dado que o “core” não sabe nada sobre tópicos resolvidos.
8 curtidas
@mcwumbly é um daqueles em que fazer o trabalho é, na verdade, mais fácil do que especificar o trabalho…
Fiz uma tentativa em:
7 curtidas
Quase todos para mim! Quase nunca consigo entender a especificação até ter escrito o código que tenho quase certeza que funciona. Isso (em parte) porque geralmente estou escrevendo código para uma especificação que não entendo. Algumas vezes consegui escrever as especificações primeiro como um adulto, mas é bem raro.
É bom saber que isso acontece com você pelo menos às vezes também. 
5 curtidas