I really like the intention behind slow mode, but it doesn’t quite address the most common driver for flamewars on our discourse:
Someone comes in “hot” — often someone new, often someone from another community — and lists a bunch of grievances
Lots of existing members respond to talk to/at the original poster with varying motivations (but with the “I think someone is wrong on the internet” syndrome ranking high)
The original poster wants to respond to/at everyone
Even in the best of discussions, things snowball rapidly.
Slow mode doesn’t help here, because there’s a many-to-one problem. It often just further alienates the new member as they’re the one that feels the brunt of the limitation: many can respond to them while their cool down timer is burning and then they only get one post to respond.
One tool I wish I had in my toolbox for situations like these is to slow down the bumping of the topic. The default listings (both latest and top) prioritize these “hot” topics. I’d love to be able to limit the bumps to once-every-12-hours or some such. Then it’s not a complete de-listing, but it’s a significant de-emphasizing that could help limit the number of new entrants to the discussion (unless they actively seek it out, which is just fine).
Absolutely, but such monster posts that reply to many messages make the topic even harder to manage. Splits become impossible, and they tend to put the poster even more on a war-path (or at the very least, give the appearance of aggravation just by virtue of the large wall of text).
That’s actually another unintended consequence of slow mode that we’ve seen on Julia discourse, which is a paid hosted instance that’s quite active: slow mode gets turned on and some people start editing their posts instead of writing new ones. Similar problem with setting someone who’s being problematic to TL0: they can’t make new posts but they can still edit their old ones, so they’ll do that, which is especially bad if they’re written inflammatory stuff which people reply to and they then edit, making the response look out of line.
But yes, I definitely second @mbauman’s suggestion—being able to prevent a hot topic from getting bumped so often would be very helpful for cooling things down.
In addition to preventing the hot topic from getting bumped, it might be an idea to delay the notifications. That kind of solves the issue where someone replies to or mentions multiple users.
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.