Discourse suggests and triggers users to post in dead / obsoleted topics (I just got #f32 as first suggestion) rather than opening new topics (while we explicitly want to avoid users to post in dead / obsoleted topics of obsoleted releases)

Site Help & Feedback
,
1

While creating a new topic, discourse suggested me a lot of existing topics that might answer my question/issue.

That is nothing new. However, I now realized for the first time that I got suggestions that contain tags like “F32”.

We promote and enforce to create new topics when a topic is about an obsoleted release.

I am thinking if some of the users who re-open obsoleted / dead topics have been maybe triggered to do so by Discourse suggestions.

I am thinking if there is a way to configure Discourse to not show suggestions that are older than 1 year or so? Given that we tend to expect by default that if a dead topic is above 6 months old, a new occurrence is a new issue, we might even want to avoid suggestions above 6 months. (The next question would be if we talk of 6 months since topic creation or 6 months since last post).

Alternatively, or additionally, Discourse might be configured to not show topics that contain a tag that belongs to an obsoleted release (e.g., f32 ), which on itself might already remove a lot of (although not all) obsoleted topics from the list. This alternative/addition might need some manual input each 6 months, I can volunteer to support here if necessary/applicable.

On one hand, this could maybe avoid one or the other post in a dead topic.

On the other hand, in a case in which a user posts in a topic that was suggested by discourse rather than opening a new one, the user does not get a good experience if then subsequently asked to open a new topic by a TL3/TL4/mod. So first discourse suggests to do one thing, and then a TL3/TL4/mod asks to do the opposite.

Ain’t a critical issue, but if discourse can be adjusted easily, it might be worth a thought :wink:

2 Likes
2

I think that would require a feature request to Discourse.

As far as I know, the only controls that exist for that feature are to set the number of topics to show and to set a threshold for the minimum number of topics that exist before you show that feature.

3 Likes
3

I often get that, but I stubbornly ignore it. I have the mindset that :
:speaking_head: “I know what I want to ask, and that is usually different than what it suggest”
usually because it was wrong in the suggestions.

Some users will start their thread saying “Yeah, I read some threads and none of them relate to my issues” , which I have always believed was due to the suggestions.

Another point is when I am making boolean searches for issues similar to the topic the OP posted. I often get results dating back to Fx and simply having sentences that were realted to the topic but not solving issues. Which makes it harder to find things. I have partially solved this by Bookmarking answers I see are useful.

I assume that closed topics would not show up, but I can be wrong on this. I think having the release tag of Fx would help in identifying old issues, but that is up to the user at that point.

:eyes:

On a side note, I think topics with solutions should be closed earlier, to encourage opening a new thread, Some Project Discussion topics should also be closed as discussion points tend to not need a “Solution” as they are merely conversation pieces, and people with juxtaposed ideals can silently “agree to disagree” which I see as a very good way to end discussions intelligently.

For example : Today i was essentially baited into resurrecting a topic that should have been closed, but was brought up, and my urge to comment on such things of interest, I essentially caved. Realizing the topic was already 8 months old, and should had been closed, I posted with regret.

4

I agree. I also don’t remember to have received a useful one. However, especially users who ask less detailed / less deep-tech questions could get something that is useful for them (also, if there are bugs we have not yet solved several topics can occur - this function could prevent topics we need to merge later): we want that users first check if related topics are already open. The Discourse function is to mitigate that many users do not check if anything related is open.

Yet, if this Discourse function fulfills that role can be questioned, especially as long as it presents very old topics without sorting by date → that way, it is unlikely the user gets presented something useful of “today”. That of course leads to the question if we shall disable that function (in case this is possible) if it cannot be adjusted (?).

5

I am pro enforcing setting the Fedora version tag. Very useful to directly detect EOL or sort out stuff.

Also it can be updated if issues really persist.

That tag could be used, maybe adding another tag for topics that are not version dependend?

I dont agree that all old info is outdated, thats simply not true. Many things repeat themselves.

2 Likes
6

No one said that. But if a user has an issue now, we take it as something new, and unless there is explicit indication that suggests otherwise, we do not assume that it is the same as a topic of, e.g., F32, even if the symptoms seem to be the same. Contexts change among releases - and also their packages are not always the same (e.g., different versions among releases are possible). Different things can cause the same symptoms. Even if a topic is about F39, we should not mix it with F40 as long as there is no explicit indication that it is the same issue, as several packages might have different versions and several configurations might differ as well.

When it comes to superficial things, much remains for long applicable, but average users who ask related questions are often not able to identify when old stuff applies or not. This is why we accept if they open new topics also in such a case: it is fine to link them then to an old topic if you know for sure that is still applicable (I always have some old btrfs topics in the backhand :wink: ). That way (if you re post it to a f40 topic), this information of, e.g., F36, is confirmed from the time of F40 for F40 applicability, and in the new topic, it is now confirmed and documented that this is still applicable → this way the old topic gets “refreshed” for, e.g., F40 within the new topic. In all cases, re-opening a case that is from an outdated release (e.g., F37) should be never justified.

Given the many and quick developments in Fedora and that we are usually close to upstream (and that a lot can differ between releases), we prefer to open new topics instead of using old topics from different releases or even releases that are outdated.

Also, environments and contexts change, and people who were following a topic a year ago might be annoyed if they then get posts again from that.

Just some examples, but the reason why we prefer new topics in several conditions does not imply that all previous information is obsoleted. The major point from a supporters perspective is in the end that we have to be careful with presumptions when people ask questions: it is easier to merge two topics when we identify they are the same, as it is to untangle it when two different issues felt comparable in the beginning (and thus began as one topic → one case) but are in fact two different issues.

Some repetition is indeed intended. A well example is the regularly appearing “Fedora-compatible notabook” topics: it is intended that regularly new notebook topics occur instead of having that somewhere consolidated (which then no one reliably maintains). That way, such a topic has always current information: on one hand, devices that still exist. On the other hand, confirmation that devices are compatible to current Fedora releases.

1 Like
7

Just an example of f32 taged information where is still today actual. I mean it was a topic with two questions in one. The second question is still valid on f40.

Can't open Extension Settings in Tweaks Fedora-32

If someone comes back to Fedora Gnome from an other desktop or OS, he could even see the first question, opening extensions from tweaks, as a valid information.

In my case I simply would remove f32 tag and use the gnome-extensions tag instead.

This way we can see the history of Fedora Linux. When things changed and or moved out to a separate app like gnome-extentions-app.

I would even add the information that with the gnome-extensions command we can manage extensions in the terminal with out using the gnome-extensions-app package installed.

1 Like