Assistindo e acompanhando a implementação de tags e categorias

Acabei de revisar a implementação de “rastreamento” e “acompanhamento” de tags e categorias:

O acompanhamento de categorias e tags sempre foi um recurso bastante limitado. Quando você começava a acompanhar uma categoria, só recebia notificações sobre os tópicos daquela categoria a partir daquele momento. (Havia uma exceção que permitia acompanhar também tópicos antigos recategorizados)

Essa limitação era… hmm… limitante. Comece a acompanhar Contribute > Bug e você não seria notificado sobre uma grande quantidade de discussões atuais em Contribute > Bug em tópicos históricos.

A nova implementação agora resolve o problema do histórico de forma bastante limpa.

Estado de rastreamento de tópicos

Para cada tópico que você visita, o Discourse armazena um registro com informações do usuário sobre aquele tópico.

  • Quando você o visitou pela primeira vez?
  • Em qual postagem você está?
  • Você está rastreando/acompanhando/silenciando?
  • E assim por diante

Quando uma conta é criada pela primeira vez, não há registros nessa tabela; eles são criados sob demanda conforme você visita tópicos.

Isso significa que, em um fórum antigo e estabelecido com 200 mil tópicos, não precisamos criar 200 mil linhas por usuário com o estado de rastreamento para cada nova conta.

Esse foi o motivo original pelo qual o “acompanhamento” era limitado ao período “a partir de agora”. Eu não queria ter que preencher centenas de milhares de linhas ao acompanhar uma categoria. Seria um pesadelo de desempenho.

A nova implementação resolve esse problema definindo um conceito de “acompanhamento implícito”. Quando uma nova postagem é criada, também verificamos as preferências de categoria e tag (além das preferências no nível do tópico) para decidir quem deve ser notificado. Isso nos permite notificar de forma limpa sobre tópicos antigos sem precisar manter registros no estado de rastreamento de tópicos (até o último momento).

Quando um novo tópico é acessado e criamos a linha do estado de rastreamento, também verificamos as preferências de tag e categoria do usuário para saber se ele deve estar acompanhando no objeto inicializado.

Nova implementação de rastreamento e acompanhamento

A nova implementação de acompanhamento funciona assim:

Quando um usuário acompanha uma categoria/tag:

  • Todos os registros de estado de rastreamento de tópicos antigos que estão em “rastreamento” ou “regular” naquela categoria passam a ser “acompanhados” (com o motivo “você está acompanhando esta categoria”)
  • Armazenamos um registro para indicar que o usuário está acompanhando a categoria
  • Tópicos com estado ausente são acompanhados implicitamente; um registro de rastreamento é criado quando notificamos os usuários.

Quando um usuário para de acompanhar uma categoria/tag:

  • Todos os tópicos acompanhados naquela categoria que foram acompanhados devido ao acompanhamento da categoria passam a ser rastreados
  • Removemos o registro que indica que o usuário está acompanhando a categoria

Nota: Removi a “tomada de decisão” sobre o que fazer com o histórico do usuário. Como é bastante simples “parar de rastrear” se necessário, basta clicar em “Dispensar”. Na grande maioria das vezes, a decisão de parar de acompanhar está correta e não há motivo para envolver o usuário aqui.

A implementação de rastreamento é mais simples:

  • Todos os registros de estado de rastreamento de tópicos antigos que estão em “regular” passam a ser “rastreados”.
  • O restante é rastreado implicitamente, sem registro.

Não “paramos de rastrear” nada para você se você parar de rastrear uma categoria. A expectativa é que você não fique apenas mexendo nas configurações ali, pois reverter não é trivial. E se você leu o tópico, postou nele, o rastreou manualmente ou atingiu o tempo de leitura? Uma implementação mais simples é deixar com que os usuários cliquem no botão “Dispensar” se ficarem presos a tópicos que não querem rastrear.

Categorias como “listas de e-mail”

Essa implementação libera a capacidade de usar o acompanhamento de “categoria” ou “tag” como substituto de listas de e-mail. Esse recurso foi solicitado com frequência.

Período de transição

Não há “migração” do sistema antigo para o novo. Se você tem muitos “estados de rastreamento” para tópicos antigos e um “acompanhamento de categoria”, você deve:

  • Parar de acompanhar a categoria
  • Voltar a acompanhar a categoria

Isso corrigirá todos os estados de rastreamento. Vou considerar adicionar uma migração para isso talvez em uma semana ou mais, quando o sistema estiver totalmente estabilizado.

Espero que prefiram essa implementação simplificada. Comentários? Perguntas?

21 curtidas

This is awesome! :100:

I’m sure some edge cases will pop up, but this is way better than the old system.

How does muting a category work now?

2 curtidas

Zero changes were made to muting. Works exactly as it used to work, hides from front page.

5 curtidas

Thank you @sam this seems to be exactly what I had expected all along.

I’m not entirely sure about existing Watchings.. is the

Just for performance, removing many many rows of watching states? Or is it required to get the “hey I’m watching a category” state?

If the migration you mentioned will set the category watching state once the dust settles, that’ll be awesome.

Again, thank you for this such quick, decisive action on the matter of Watching Categories.

I feel like I’m missing something. Why put this state on a record associated with the topic at all now? Why not just always check the preference?

Because you could be not watching a category but see a topic of interest and want to watch that topic specifically (which wouldn’t be covered under preference).

1 curtida

Yeah, of course. I’m not suggesting eliminating topic-based tracking states all together. Only in the cases of tracking categories or tags.

Como um usuário pode substituir um tópico específico

Assista a Contribute > Bug, mas silencie um bug em particular

7 curtidas

I see. I guess there’s have to be a nil or default topic tracking state to know when to fall back on the category or tag preference.

It’s a bit hard to tell without the migration you mention, but so far this seems to be just right.

I look forward to a migration that will set the new style tracking state, so I can finish testing this out.

2 curtidas

This sounds terrific, @sam! It sounds like this change is what the mailing list crowd was asking for.

What Discourse version is this change on?

I’m not sure how to transition, though. Would we need a script that removes and re-adds all users’ watched categories?

Edit: do these changes impact the watching/tracking states of Group PMs?

A migration is quite risky here, I am worried about adding it and its just for an edge case.

The edge case we are not handling now is:

  • User visits topic X in category Y
  • User watches category Y
  • Topic X is not watched
  • Admin upgrades Discourse
  • topic X is still not watched

However this works just fine

  • User never visited topic X in category Y
  • User watches category Y
  • Admin upgrades Discourse
  • topic X is watched

@alehandrof this is in latest beta, I would not worry about transition edge cases you can deal with them on a case by case basis imo. This has no impact on group PMs

1 curtida

What if:

  • User watches category Y (because I have that as the site default for users)
  • User visits topic X in category Y
  • Topic X is not watched (in other words, they took no action while viewing it)
  • Admin upgrades Discourse

Would topic X still be watched [by way of the category watch]?

Unfortunately the edge case you mention is exactly my situation.

I have specific groups watching specific categories (automated via a plugin). I need to know that everyone in that group is receiving notifications from every topic in that category.

2 curtidas

@sam In my primary forum, about 1/2 the users are in the edge case you describe, the other are in the one I describe.

Like Alex, the goal is to know that users are Watching specific categories. Perhaps removing them & reading them to a Group could reset the Watching state, via this Group-watch feature request?

2 curtidas

encountered this bug recently:

  1. Start by clicking the Category dropdown menu, and choose any category.
  2. While in the selected category space, click on the watch/track button next to + New Topic
  3. Choose to watch the category
  4. Refresh page, then try to unwatch the category by setting it to other option (like Normal or Watching First Post)
  5. Refresh page, the category is still being watched (Watching is still selected).
  6. Only way to unwatch the category is through the account preference page.

Shouldn’t user be able to unwatch any category the same way they use to watch one?

1 curtida

@sam Has this actually been implemented yet? If so, could you reference the commit?

Not following, this has been implemented for ages.

2 curtidas

@sam That’s what I thought, which is why I’m a bit confused.
The way I understand it, if I am watching a category, a new topic in this category would result in a record being created for this topic where the initial state would be watching.

Is that correct?
Because the way I am experiencing it now is that you will for example get a notification about the new topic, but if you vist /latest?state=watching, the new topic will not show up. It is not until you go visit the topic that the watching state will be set.

@sam did you receive my question?