Now in Beta: Plugin to see TL3 Progress for TL2 users

[NateDhaliwal]

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.

[Moin]

@EricGT

For a long time, many of these values could not be changed through site settings. They can now be changed relatively easily.

Hmm. I’d say they kind of existed forever. I found a commit renaming them from 2014

rename site settings for trust levels as numbers

I don’t think there is “a long time” of Discourse before that.

@NateDhaliwal

Settings:

• Progress bar color: color of the progress bar (default green, like in the picture above)
• Progress bar background color: bg color of the progress bar (default light-gray like in the picture above)

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.

[EricGT]

@Moin

I found a commit renaming them from 2014

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.

[EricGT]

After reading:

Can someone clarify the 'posts read' TL3 promotion logic?

There’s this piece of code that’s been bugging me: For the life of me, I cannot figure out why the posts made in the time period is multiplied by the percentage of required posts read, then taken as the minimum value. If the intention here is the percentage of posts read, then wouldn’t it be the posts read / number of posts, multiplied by 100? Supposing there have been 9 posts in the last x days, and the setting only requires 2, then shouldn’t the method simply return 2 since it’s less than …

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.

[NateDhaliwal]

Color palettes for light/dark

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).

@EricGT

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.

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…