Eu realmente gosto da intenção por trás do modo lento, mas ele não aborda completamente o principal motivador de discussões acaloradas no nosso Discourse:
Alguém entra “em fogo” — frequentemente um novo usuário ou alguém vindo de outra comunidade — e lista uma série de reclamações
Muitos membros existentes respondem para falar com/com o autor original, com motivações variadas (mas com a síndrome do “Eu acho que alguém está errado na internet” figurando em alto grau)
O autor original quer responder a/todos
Mesmo nas melhores discussões, as coisas escalam rapidamente.
O modo lento não ajuda aqui, porque há um problema de muitos-para-um. Muitas vezes, isso apenas aliena ainda mais o novo membro, já que ele é quem sente o peso da limitação: muitos podem responder a ele enquanto o temporizador de espera está correndo, e então ele só recebe uma postagem para responder.
Uma ferramenta que gostaria de ter na minha caixa de ferramentas para situações como essas é desacelerar o bumping do tópico. As listagens padrão (tanto as mais recentes quanto as principais) priorizam esses tópicos “quentes”. Gostaria muito de poder limitar os bumps a uma vez a cada 12 horas ou algo assim. Assim, não seria uma remoção completa da lista, mas uma desvalorização significativa que poderia ajudar a limitar o número de novos participantes na discussão (a menos que eles ativamente procurem por ela, o que é perfeitamente aceitável).
Com certeza, mas essas respostas-monstro que respondem a várias mensagens tornam o tópico ainda mais difícil de gerenciar. Divisões se tornam impossíveis, e elas tendem a colocar o autor ainda mais em estado de guerra (ou, no mínimo, dar a aparência de agravamento, apenas pela existência desse grande bloco de texto).
Isso é, na verdade, outra consequência não intencional do modo lento que já observamos no Julia discourse, que é uma instância hospedada paga e bastante ativa: o modo lento é ativado e algumas pessoas começam a editar suas postagens em vez de escrever novas. Problema semelhante ao definir alguém que está sendo problemático para TL0: eles não podem criar novas postagens, mas ainda podem editar as antigas, então farão isso, o que é especialmente ruim se escreveram algo inflamador ao qual as pessoas responderam e que eles então editam, fazendo com que a resposta pareça desproporcional.
Mas sim, eu definitivamente apoio a sugestão de @mbauman—ser capaz de impedir que um tópico quente seja movido para o topo com tanta frequência seria muito útil para acalmar as coisas.
Além de evitar que o tópico quente seja reativado, pode ser uma boa ideia adiar as notificações. Isso resolve o problema de alguém responder ou mencionar vários usuários de uma só vez.
Um truque que você pode usar hoje é deixar tópicos como este não listados. Temos planos de adicionar temporizadores que possam re-listá-los, mas você também pode fazer isso manualmente.
A opção “Enterrar” tópico já surgiu no passado e é algo que temos considerado.
Eu não entendi muito bem o que você está propondo. Você pode me mostrar um mockup da interface de como isso funcionaria, o que o usuário veria, o que o membro da equipe veria?
É por isso que a edição é limitada por padrão no Modo Lento. Você pode desativar os limites de edição se confiar que sua comunidade não fará isso.
E considere o que @sam disse. Torne o tópico não listado. Por favor, utilize totalmente as ferramentas existentes em seu kit antes de propor mais.
A ideia principal é bem simples: eu chamaria algo como “Limitar Bump de Tópicos…” no menu de tópicos do administrador (provavelmente ao lado do item “ Reset Bump Date”). Ele abriria uma caixa modal que pediria para você inserir o período de tempo. O texto seria algo como: “Limitar a frequência com que este tópico aparece no topo das visualizações Mais Recentes e de outras categorias para, no máximo, uma vez a cada X horas”, com um padrão de cerca de 8 horas.
Eu não tenho uma opinião forte sobre como seria implementado; poderia ser stateful (manter o controle da última postagem que atualizou o tempo de bump do tópico e atualizá-lo apenas se o tempo de uma nova postagem for mais de X horas no futuro) ou stateless (sempre definir o tempo de atualização do tópico para o piso do múltiplo de X horas a partir da época Unix ou da primeira postagem). Ou algo mais, o que for.
Quanto ao que é exibido para o usuário, não tenho 100% de certeza se precisa ser comunicado a ele, mas poderia aparecer como um item de postagem “não listado”, simplesmente afirmando: “este tópico só aparecerá no topo das listas de tópicos uma vez a cada X horas.”
Quanto a outras ferramentas, às vezes usamos a não listagem de threads, mas isso é tudo sobre novos usuários combativos — muitas vezes o tipo de pessoa que pode se ofender muito com qualquer indício de censura. E eu realmente não quero censurar/ocultar/excluir coisas. O objetivo é uma intervenção mais suave que, esperançosamente, seria menos provável de causar mais aborrecimento por si só, mas que esperançosamente ajudaria a manter a temperatura um pouco mais baixa.
Isso é um tanto inspirado na forma como o Hacker News penaliza tópicos com significativamente mais comentários do que votos positivos.
Quais são seus sentimentos sobre isso @sam@eviltrout? Poderíamos ter um inteiro aqui representando o tempo, onde 0 significa “nunca permitir que seja promovido” e 1-6000 poderia ser “permitir 1 promoção a cada {x} minutos” ou algo assim.
É uma ideia interessante - algo como debouncing para solavancos.
Parece uma ferramenta poderosa, mas consigo ver que seria útil. Não acho que seja algo fácil de adicionar – provavelmente algo com um nível de esforço médio.
Acho que pode ser útil em alguns cenários para evitar que um tópico esquente demais em primeiro lugar, se detectado cedo pela moderação. Especialmente em instâncias com muitos usuários.
Se o tópico já estiver aquecido e a discussão for autossustentável, o modo lento provavelmente fará um trabalho melhor, já que as notificações que os usuários recebem de interações no tópico (provavelmente) o manterão ativo.
Eu estava verificando o código-fonte e, além de mudar os modelos, bypass_bump? seria suficiente para impedir que eles fossem “bumpados”?
Talvez adicionar um campo em Topic, algo como min_seconds_between_bumps por exemplo e outra condição em bypass_bump?:
Não tenho certeza sobre o valor 0 indicando que o tópico não deve ser “bumpado” de forma alguma. Isso pode confundir alguns usuários. Se feito dessa forma, acho que seria uma melhor experiência do usuário se o webapp não expusesse o zero diretamente ao usuário.
Se estou interpretando corretamente, a decisão sobre se deve ou não dar um bump ocorreria no momento em que uma resposta é postada, mas se nenhuma resposta subsequente for postada após o período de não-bump, o tópico nunca dará um bump.
Esse seria o comportamento desejado ou o tópico sempre deve dar um bump ao final do período de não-bump se uma resposta foi postada durante o período? Se sempre deve dar um bump, deve dar um bump para “agora” ou para o horário da última resposta?
Sim, nesta abordagem, a decisão ocorreria quando a resposta fosse postada e, sem respostas subsequentes, o tópico nunca seria aumentado novamente. Se eu estiver correto, já que de forma alguma sou um especialista no código-fonte do Discourse, esta seria a maneira mais fácil de implementar isso.
O outro comportamento possível, aumentar após o período de resfriamento, provavelmente exigiria mais trabalho, como @eviltrout disse, pois exigiria que o aplicativo armazenasse o próximo aumento esperado e tivesse algum tipo de agendador ou trabalho sidekiq para executar os aumentos pendentes periodicamente.
Ambas as abordagens são válidas e, se isso for implementado algum dia, não sei qual será escolhida.
Pessoalmente, não me importo se um tópico problemático nunca mais for aumentado se não houver respostas subsequentes. Mas essa é apenas a minha opinião.
Meu raciocínio é que a lógica mais simples é esta:
O tópico tem uma configuração, “só pode ser atualizado uma vez a cada {x} minutos”, onde o número de minutos é uma configuração ajustável, variando de zero (o padrão, pode ser atualizado quantas vezes houver respostas) a ~10.000 (só pode ser atualizado uma vez por semana). Vamos supor que alguém inseriu 60 minutos, o tópico só pode ser atualizado no máximo uma vez a cada 60 minutos.
Quando uma resposta é postada, verifique a data da última atualização:
Se a data da última atualização foi há mais de 60 minutos, permita que o tópico seja atualizado por esta nova resposta.
Se a data da última atualização foi há menos de 60 minutos, não atualize o tópico ao postar esta nova resposta.
Sim, isso parece simples e funcional. Vamos adicioná-lo à próxima versão @sam@eviltrout?
-1 (não pode ser incrementado indefinidamente) também seria valioso? Acho que estou pendendo para não, seria difícil encontrar tais tópicos mais tarde (sem trabalho extra) e se um administrador realmente quiser que um tópico nunca mais seja incrementado, provavelmente faz mais sentido apenas fechá-lo.
Na verdade, acho que o tempo máximo definido deveria ser uma configuração configurável na página de administração. Algo como max_slowbump_time ou algo assim.
Além disso, já que estamos nisso. Seria possível aplicar também incrementos lentos no nível da categoria?
Uma funcionalidade como essa chegou a ser implementada? Temos outro tópico semelhante que levou @mbauman a solicitá-la originalmente e, se essa funcionalidade existir agora, seria ótimo poder usá-la.
Reset Bump Date”). Ele abriria uma caixa modal que pediria para você inserir o período de tempo. O texto seria algo como: “Limitar a frequência com que este tópico aparece no topo das visualizações Mais Recentes e de outras categorias para, no máximo, uma vez a cada X horas”, com um padrão de cerca de 8 horas.