Super busy over the past few days. But I’m almost done with updating the logic for getting the next closest stat: instead of looking at percentage, it looks at the lowest actual value then can be next achieved.
As for TL3s about to lose progress, I’ve started on that too. The repo probably shouldn’t bebused for now since it’s in-between the finished product.
Hmm. I’d say they kind of existed forever. I found a commit renaming them from 2014
I don’t think there is “a long time” of Discourse before that.
I think you might need separate settings for light and dark color palettes. lightgray on black has a different contrast than on white.
Instead of time_period: "Based on last %{num_days} days." you can use
time_period:
one: "Based on last %{count} day."
other: "Based on last %{count} days."
Then you get day/days depending on the number. Things get a little complicated when there is more than one number other words depend on in the text. I’d try to avoid Message Format.
Interesting, now I have to wonder why I think what I noted.
Other interesting note about the commit, it was done by Jeff ( coding-horror) which is rare to see now-a-days.
I was reminded of a problem some users encounter when trying to reach TL3.
When users are required to read a certain number or percentage of posts, they naturally assume that all posts included in that calculation are visible to them. However, that may not always be the case.
For example, if posts in a muted category still count toward the requirement, there could be enough eligible posts in muted categories to make the target difficult—or perhaps impossible—to reach without first unmuting those categories and reading the posts.
The plugin should therefore provide a category-by-category breakdown showing:
how many posts in each category are included in the eligibility calculation; and
how many of those eligible posts the user has read.
This would reveal whether muted categories are affecting the user’s progress and show what they need to do to meet the requirement—or, as some users might describe it, how to “game” the system.
Nearly done with showing the stats if a TL3 is going to lose TL3 (with a minimum threshold setting to show a warning if a stat is below that value).
The thing is that not even core has this kind of indication. The original idea is to bring the info that staff users can see to the users themselves. I think this may be too out of the plugin’s scope. But I would like to know more about this. Are you saying that the unmuted categories do not contain enough posts to hit the requirement, and that the remaining number can come from muted categories?
Plus, how would that work? Get every post created in the time frame, check the topic each belongs to, check the category id, compare that with the user’s muted categories, then add it to a counter? Or maybe some optimised SQL query…
Not necessarily, although that could be true in an extreme case.
From time to time, while helping users, it was noticed that one user’s post-read count was increasing faster than another’s. The difference was often that the more active reader had no muted certain categories. Topics from those categories therefore appeared in their topic lists and were more likely to be read.
When the other user unmuted the category, more topics became visible in their normal browsing views, and their daily post-read count increased to roughly match the other user’s.
Yes. Posts in those categories can count when they are actually read. However, muting a category can indirectly slow a user’s progress because its topics are hidden from views such as Latest and are therefore easier to miss.
Years ago, the post-reading requirement on the OpenAI forum was based primarily on a percentage of the forum’s activity, without the lower cap that exists in many current configurations. On a very active forum, that could require reading 10,000 or more posts.
Some users noticed that other members’ post-read totals, as shown in the user directory, were increasing much faster even though they were reading every visible post they could find. After some investigation, muted categories were identified as the reason: a substantial number of available posts were not appearing in their usual topic lists.
Okay, so I’ve added the feature to show the lowest stat if the user is over TL3. I’ve worked out the queries for finding the number of topics and posts in muted categories, and I’m working to integrate them into the UI.