Coisas assustadoras acontecendo 👻

[LeoMcA (Leo McArdle)]

Há coisas como as seguintes que tenho notado há meses, mas nunca registrei um relatório, porque nunca consegui reproduzi-las consistentemente. Mas, finalmente, por acidente, capturei uma em vídeo! (Então, por favor, perdoem as pausas e a confusão refletidas nos movimentos do meu cursor.)

2017 04 19 14 22 26

As coisas para observar são:

1. A aba “Não lidos” estar vazia
2. Contribute > Feature aparecendo como “Normal” (apesar de estar sendo rastreado, conforme mostrado nas minhas preferências) e só aparecer como “Rastreado” após uma atualização da página
3. Um tópico aparecendo misteriosamente em “Não lidos” (de dias atrás, da categoria howto)

O segundo ponto é algo semelhante a um bug comum que vejo (mas nunca consegui reproduzir em vídeo), onde eu clico em um tópico de “Novos” em uma categoria que estou rastreando, mas o status próprio dele não aparece como “Rastreado” a menos que eu atualize a página. (Imagino se isso esteja relacionado a isso.)

Pouco antes de gravar este vídeo, estava tentando reproduzir esse bug rastreando Contribute > Bug e, em seguida, clicando em um dos tópicos dele na aba “Não lidos”. Não consegui, mas ao parar de rastrear Contribute > Bug, minha aba “Não lidos” foi preenchida com cerca de 20 tópicos fechados em Contribute > Bug de por volta de 2015, o que parece ser o mesmo bug do ponto 3.

Não entendo por que isso poderia estar acontecendo.

[codinghorror (Jeff Atwood)]

What are the repro steps?

[LeoMcA (Leo McArdle)]

There are two bugs here.

I can’t consistently reproduce the first, where the correct notification level is only shown after a refresh (of a category, or a topic). It’s been happening to me for months, but whenever I try to reproduce it, it doesn’t happen.

The second, which I think is a bit more minor, but still a nuisance can be reproduced (for a limited time only) like so:

1. Clear /unread
2. Track a category currently set to ‘Normal’
3. Go back to /unread and observe posts not previously in it

I’ve been able to do this with a number of categories, but only once for each. Once I’ve dismissed the posts from unread, they never appear again.

Consistently reproducing it takes a little more work, so hold onto your hats, it’s gonna get a bit crazy:

• Go to unread in a category of your choosing which has a notification level of “Normal”, observe nothing there:

• List all the currently tracked topics in that category (and remember, or take a screenshot of them):

• Enter a topic from that category not on that list:

• Start tracking the category
• Again list tracked topics in that category
• Observe the topic you just opened in that list:

• Go to unread, and again observe that topic in the list:

---

TL;DR

So, the bug here is that previously opened topics in a category become tracked, and appear in unread (unless previously dismissed), when the category is tracked, whereas nothing happens to old not-opened-before topics.

To me, what should happen is either:

• Nothing changes about the notification status of old topics in a category when it becomes tracked, previously opened or not.

or

• All old topics become tracked when the category is tracked, but are automatically dismissed, so only new activity appears in the unread tab.

I lean towards the second solution, provided explicitly set notification levels on topics are kept.

I haven’t investigated how this works with other notification levels, I imagine its the same, but I feel it would confuse things for the time being.

[cpradio]

So in relation to

Watching and tracking implementation for tags and categories

I just revised the implementation of “tracking” and “watching” of tags and categories: [image] Watching categories and tags has always been a rather limited feature. When you started watching a category you would only watch topics in that category from that time on. (with an edge case that allowed you to also watch recategorized old topics) This limitation was … hmm … limiting. Start watching Bug and you would not be notified on a large amount of current Bug discussion on historic topics. T…

What part is considered as “not working as expected”?

[LeoMcA (Leo McArdle)]

@cpradio

Qual parte é considerada como “não funcionando conforme o esperado”?

2 partes:

A primeira seria os tópicos não sendo rastreados implicitamente de forma adequada. Se o fossem, todos os tópicos de Community Building > Praise deveriam aparecer nesta etapa:

@LeoMcA

Observe o tópico que você acabou de abrir nessa lista:

Parece que essa lista está mostrando apenas tópicos com um registro de rastreamento “rastreado”, e isso não está funcionando conforme o esperado. O que deveria acontecer é mostrar todos os tópicos com um registro de rastreamento “rastreado” e todos os tópicos que estão em uma categoria rastreada. (O mesmo se aplicaria à opção de assistir.)

Além disso, embora faça sentido:

@sam

Tópicos com estado ausente são acompanhados implicitamente; um registro de rastreamento é criado quando notificamos os usuários.

Parece que a mesma funcionalidade está faltando quando um usuário rastreia uma categoria. Não deveria ser criado um registro de rastreamento também quando houver uma nova postagem em um tópico?

A segunda parte seria o aparecimento de tópicos aparentemente arbitrários como não lidos quando você rastreia uma categoria (assumo que seja um efeito colateral da alteração do estado de rastreamento de tópicos anteriores de “regular” para “rastreado”), o que poderia ser corrigido dispensando automaticamente esses tópicos da lista de não lidos.

[Mittineague]

What are your Preferences → Other
Consider topics new when
and
Automatically track topics I enter
settings?

[LeoMcA (Leo McArdle)]

@Mittineague

Consider topics new when

I haven’t viewed them yet

@Mittineague

Automatically track topics I enter

never

[david (David Taylor)]

@LeoMcA

Então, o bug aqui é que os tópicos abertos anteriormente em uma categoria passam a ser rastreados e aparecem como não lidos (a menos que tenham sido previamente descartados) quando a categoria é rastreada, enquanto nada acontece com os tópicos antigos que nunca foram abertos.

Isso é algo que encontrei há algum tempo, e há um tópico sobre o assunto aqui (não tenho certeza absoluta do motivo de ter sido movido de Contribute > Bug para Contribute > Feature).

O tópico é bastante confuso, pois originalmente achei que o problema fosse causado pela importação inicial do phpBB. Então, aqui vai uma tentativa de resumir:

O problema se resume ao fato de que um tópico não pode ser simultaneamente novo e não lido:

• Embora seja implicitamente rastreado, o tópico não aparece em não lidos porque o usuário nunca o visualizou
• O tópico não aparece em novos porque está além do limite definido na sua configuração “Considerar tópicos novos quando”

É um problema difícil de resolver, pois fazer com que todos os tópicos antigos de uma categoria apareçam na sua aba ‘não lidos’ realmente não é uma boa experiência para o usuário.

“Descartar automaticamente” esses tópicos é bastante custoso em termos de banco de dados (um novo registro TopicUser teria que ser criado para cada tópico na categoria que você acabou de rastrear).

Realmente não chegamos a uma ideia elegante para resolver o problema, e a discussão acabou morrendo. Uma opção que @sam sugeriu foi

@sam

Talvez haja algo “barato” que possamos fazer.

Se um tópico em uma categoria rastreada for atualizado (bump), adicione-o de volta à lista de “novos” pela duração definida para isso.

Ainda assim, isso pode parecer um pouco estranho.

Na época, achei que essa poderia ser uma boa ideia:

@david

No momento, a aba “novos” é ordenada por “topic.bumped_at”, mas filtrada por “topic.created_at”. Qual é a lógica por trás disso? Parece um pouco pouco intuitivo que os tópicos não “saiam do final” da lista assim que deixam de ser considerados novos. Seria bem interessante, pelo menos para o meu fórum, filtrá-los por “topic.bumped_at”.

Mas

@sam

O problema com uma mudança como essa é que muitos usuários ficariam muito confusos sobre como remover itens da lista de “novos”.

TL;DR: Não tenho uma solução, mas espero que isso deixe o problema mais claro

[david (David Taylor)]

And for the other issue in this thread:

@LeoMcA

I can’t consistently reproduce the first, where the correct notification level is only shown after a refresh (of a category, or a topic). It’s been happening to me for months, but whenever I try to reproduce it, it doesn’t happen.

I can reproduce this consistently here on meta for categories. Repro steps:

1. Go to your user preferences, remove all tracked categories
2. Go to a category page, e.g. #meta, and observe that the ‘notification level’ indicator is “normal”
3. Go immediately to your user preferences, by clicking your avatar in the top right, then the cog
4. Add the category you just visited, e.g. #meta, to your “tracking” categories
5. Press “save changes”
6. Press the back button in your browser to return to #meta, and observe that the ‘notification level’ indicator is still “normal”
7. Refresh the page, and observe that the ‘notification level’ is now “tracked”

If you replace step 6 with visiting the category page by some other route, the tracking status appears correctly.

[LeoMcA (Leo McArdle)]

@david

It comes down to the fact that a topic cannot be both new and unread simultaneously:

From a practical perspective, that doesn’t make sense to me. If I buy a book and put it on my shelf having not opened it, it is both new and unread.

@david

having every single old topic in a category appear in your ‘unread’ tab is really not a good user experience.

Wouldn’t it be possible to have an old topic (with no tracking record) only appear in unread when there’s new activity on it?

@sam

When a user watches a category/tag:

[…]

• Topics with missing state are watched implicitly, a tracking record is created when we notify users.

So, just as a tracking record is created on new activity for topics in watched categories, a tracking record would be created on new activity for topics in tracked categories.

@david

“Automatically dismissing” them is quite expensive database-wise (a new TopicUser record would have to be created for every single topic in the category you just tracked).

Combined with the above, couldn’t we just dismiss topics where the tracking record has been changed to “tracking” as a result of tracking the category, which would mean the same user experience, without any additional database writes? (If I understand how tracking records, dismissing and TopicUser relate.)

This way, it seems to me, we could have a mailing list experience for tracking too!

[david (David Taylor)]

@LeoMcA

From a practical perspective, that doesn’t make sense to me.

Sure, I agree. I was talking purely about how it currently works in discourse.

@LeoMcA

Wouldn’t it be possible to have an old topic (with no tracking record) only appear in unread when there’s new activity on it?

I believe @sam thought this would have major performance issues

@LeoMcA

So, just as a tracking record is created on new activity for topics in watched categories, a tracking record would be created on new activity for topics in tracked categories.

I’m 99% sure a new record isn’t created for tracked topics - @sam said “created when we notify users”, and tracking doesn’t cause notifications. Maybe fixing this is the solution

[LeoMcA (Leo McArdle)]

@david

I was talking purely about how it currently works in discourse.

Do you know if there’s an architectural issue which means the new/unread either/or has to be the case?

@david

I’m 99% sure a new record isn’t created for tracked topics - @sam said “created when we notify users”, and tracking doesn’t cause notifications. Maybe fixing this is the solution

Indeed, I was proposing this as a solution which seems to not have any major performance issues.

[david (David Taylor)]

@LeoMcA

Do you know if there’s an architectural issue which means the new/unread either/or has to be the case?

I assume it’s by design - having a topic listed on the new tab and the unread tab would be a bit weird.

Taking your book analogy, while it can be both unread and new, you can’t put it on your “new” shelf and your “unread” shelf simultaneously

[david (David Taylor)]

Ok… I’ve done some testing in my dev environment. As a simplest possible repro:

1. Set previous visit timeout hours site setting to 0, to make testing quicker

• User A sets “Consider topics new when” to “created since I was last here”
• User A sets Category1 to tracked
• User B posts in Category1
• User A observes the topic in ‘new’, but does not open it
• User A leaves the site
• User A comes back to the site later, and User B’s post is gone from the ‘new’ tab
• User B posts again in the same topic
• The topic does not appear in either ‘new’ or ‘unread’ for User A, even though they are tracking the topic

That same repro works for ‘watching’ a category as well. A notification is sent, but no TopicUser row is created (checked on the rails console). It seems that this:

@LeoMcA

a tracking record is created when we notify users.

is not happening for some reason, both for watched and tracked categories.

[LeoMcA (Leo McArdle)]

@david

having a topic listed on the new tab and the unread tab would be a bit weird.

Would it though? We already have topics listed in the latest tab and the new/unread tabs simultaneously. And the two (new and unread) are for different purposes: new is “show me the newest topics on this site” and unread is “show me topics I’ve expressed an interest in, but haven’t (finished) read(ing)”. For new to achieve its purpose it has to have unread topics in it which are new, and for unread to achieve its purpose it needs to have new topics in it which are unread.

Currently the unread tab is rather dysfunctional.

@david

It seems that this:

a tracking record is created when we notify users.

is not happening for some reason, both for watched and tracked categories.

Interesting, thanks for doing all this investigation! So it would seem like if this did actually happen (or more specifically, a TopicUser row was created on topic update, rather than notification, to include tracked categories), then our problems here would be solved. @sam thoughts?

[sam (Sam Saffron)]

I am fine to change the semantics of “tracked category” so it means, if a category is tracked it will unconditionally show up in new regardless of your new duration, it does not mean this now.