Discourse Yearly Review

[Discourse]

	Summary	Discourse Yearly Review creates a topic on January 1st that summarizes the previous year’s forum activity. (See our examples here on Meta - year-in-review)
	Repository Link	https://github.com/discourse/discourse-yearly-review
	Install Guide	How to install plugins in Discourse

As this is an official plugin maintained by the Discourse team, Support, Bug, UX, and Feature requests can be made in the respective categories here on Meta, and tagged with the appropriate plugin tag. Click on a link below to get one started.

 Support  Bug  UX  Feature

Initial Setup

Head to your /admin/plugins page to click the discourse-yearly-review Settings button:

1. Enter categories to pull data from into the yearly review categories setting. If left blank, it will default to the top 5 public categories.

2. Using the yearly review publish category setting, choose a destination category for the review to be posted.

   It is highly recommended to set the yearly review publish category to the staff or other private category so that you can view the topic before making it public. You might also like to edit it first.

3. Then, enable the plugin using the yearly review enabled setting.

Features

As you can see at 2022: The Year in Review, data is displayed in two sections - users and topics.

The users section includes:

• Most Time Reading
• Most Topics Created
• Most Replies Created
• Most Replied to
• Most Likes Given
• Most Likes Received
• Most Visits
• Users who have been granted a featured badge (the badge is set by the yearly review featured badge Site Setting

The topics section includes:

• Most Read
• Most Liked
• Most Replied to
• Most Popular
• Most Bookmarked

Generating the Yearly Review

The plugin sets thresholds for deciding which topics to display. There need to be a minimum of 10 likes or replies, 5 bookmarks, a score of 10, or one hour’s read time before a topic will be displayed. The topic is published automatically through a background job. The job checks that the plugin is enabled and that it is within the first 31 days of the first month of the year. It then checks to see if a topic with the title yearly_review.topic_title has already been published by the system user. If all checks pass, the topic is published to the category set in the yearly review publish category setting. If this is not configured, the topic will be published to the Uncategorized category.

Extra Options

Yearly review categories

Categories used in this section are taken from the 5 best public categories that have been set in the yearly review categories Site Setting. If this setting is not configured, the 5 best public categories from the forum will be chosen. “Best” is determined by the category topics_year count. Topics created in read restricted categories are not included in the topics section.

Sub-categories of any categories specified in the yearly review categories Site Setting will not be included in the yearly review report. If you want sub-categories to be included in the yearly review report, you will need to explicitly specify them in the yearly review categories Site Setting.

Yearly review exclude staff

The plugin has a yearly review exclude staff setting. It is enabled by default so that staff members are excluded from the users section and topics created by staff are excluded from the topics section.

Yearly review featured badge

A featured badge can be set via the yearly review featured badge setting. A maximum of 15 badge users are displayed. If more than 15 users have been granted this badge, a link to the badge’s page is displayed. If the yearly review featured badge is not configured, this section will not be displayed.

Running the Yearly Review manually

If you don’t want to wait for the background job, you can publish the topic from the rails console with:

Jobs::YearlyReview.new.execute(force: true)

If you want to generate a report for a specific year just add review_year: 'year', e.g.:

Jobs::YearlyReview.new.execute(force: true, review_year: '2021')

Hosted by us? If you would like to run the Yearly Review manually you can contact us at team@discourse.org and we’ll be happy to arrange that for you.

Settings

Name	Description
yearly review enabled	Enable the yearly review.
yearly review categories	Public categories to pull topics from. The top 5 categories from this group will be selected. If left blank will default to the top 5 public categories.
yearly review exclude staff	Exclude Staff from user stats.
yearly review include user stats	Add user-identifying stats to the first post of the review topic.
yearly review include private categories	Include user activity from private or read-restricted categories in the review.
yearly review publish category	The category the review will be published in.
yearly review featured badge	Enter the full badge name. Can be left blank.

Hosted by us? This plugin is available on all of our hosting tiers Yearly Review | Discourse - Civilized Discussion

---

Known Issues

• The data is displayed in HTML tables. Tables are wrapped in div tags that have data-review-topic-users="true' and data-review-featured-topics="true" attributes. This allows the tables to be styled when they are displayed on Discourse. The styles are not copied when emails for the topics are created. Emails sent out for the topic don’t look great.

• The first post in the generated topic is ≈ 40,000 characters due to using HTML. As a result, it cannot be edited unless you first increase the body character limit above this (see Body is limited to 32000 characters; you entered 43659)

• emojis in titles are not rendered in the featured topic links

Last edited by @SaraDev 2024-12-05T20:13:22Z

Check document

Perform check on document:

[Samantha_O]

A few nice enhancements that could be made to this plugin, I hope I’m sharing this in the right place? Let me know if not.

• Ability to exclude staff from user list, but still include the topics that they create
• Ability to exclude TL4 from user list (and like above, still include the topics they create)
• Ability to create multiple review posts so that we could have one for TL4 (we use this for employees) & staff members, and then have a community member only post

[Ayelen_Rives (Aye Rives)]

Hi!
I installed the plugin this year, but even though it’s enabled, I don’t know when the review is posted, or if I should do anything else to publish it.

Can anyone let me know?
Thanks a lot!!

[Aaron_Walsh]

Greetings @Ayelen_Rives,

Upon inspecting the administrative console, you will be presented with the following visual aid:

Further scrutiny within the plugin titled ‘plugin:discourse-yearly-review’ reveals yet another illustrative example:

It is imperative that while configuring the settings, you designate the annual review’s publishing category either to the staff or another restricted category. This ensures a preliminary review before permitting broader visibility.

[Ayelen_Rives (Aye Rives)]

Thank you so much, Aaron!

Unexpectedly, I don’t see those messages in the administrative console, neither on the settings:

The publish category is Staff, so I’ll found out on January 1st if it is created.

Thanks again and happy holidays!

[Roi]

Happy new year!

The plugin did not run here in two forums. And now shows the message for Jan 1st 2025. Strange.

I ran it manually in the rails console in one forum and it came back in English, not German, the language of the forum.

Something is/was wrong here.

[JammyDodger]

It’s not arrived here on meta yet either. I followed the advice and set it to publish to #staff first, which I think is the only difference to last year?

I was hoping it would magically turn up with a little patience, but I may be being optimistic.

[Roi]

I did not change anything in the config, not even the forum to first check it as a staff member and then move it,

In my second forum there is still nothing. And it is 11:24am here.

It looks like something is broken.

Is there a need for a language flag when manually running it? I do not want to translate everything in the second forum, too.

[JammyDodger]

I’d be tempted to leave it a bit longer to see if there’s a delay in the background job, but I’m also not sure why manually triggering it would give a different result to having the background job run on its own?

We may need someone more knowledgeable to chip in.

[packman (Chris McMahon)]

Mine didn’t run automatically but I just ran it manually and it seems to have worked OK, although I wasn’t wanting it in a different language.

[Jagster (Jakke Lehtonen)]

Today morning’ish sidekiq was telling to me yearly review will be scheduled in 50 mins time and at the moment that would be around 11 am local time. I didn’ wait, though, but did it manually. No issues and the language was right too.

After that I was forced downgrade my miderators and do sidekiq again because they were really upset — I was excluded staff… I couldn allow staff because then I as an really active admin would dominate lists totally, so I took fastest route.

Well, that is different story, but could we have a bit more free hands include or exclude groups?

[Roi]

Holy sh… On the other forum the 2023 thread is there… 2:31pm local time. And in German. So, still mysterious…

[JammyDodger]

I triggered ours from Sidekiq in the end.

2023: The Year in Review

2023's Top Users Most Time Reading User Hours Read [avatar] @Canapin 294 [avatar] @Don 233 [avatar] @Moin 186 [avatar] @merefield 158 [avatar] @pfaffman 139 [avatar] @simon 127 [avatar] @Arkshine 118 [avatar] @Jagster 117 [avatar] @ClawdiaWolf 82 [avatar] @Heliosurge 69 Most Topics User Topics [avatar] @twofoursixeight 84 [avatar] @jordan-violet 69 [avatar] @Don 67 [avatar] @danielabc 65 [avatar] @Jagster 62 [avatar] @jidanni 62 [avatar] @Cana…

[tobiaseigen]

On my sites the topic was generated without me having to run it manually in sidekiq.

@Samantha_O

• Ability to exclude staff from user list, but still include the topics that they create
• Ability to exclude TL4 from user list (and like above, still include the topics they create)
• Ability to create multiple review posts so that we could have one for TL4 (we use this for employees) & staff members, and then have a community member only post

These are great suggestions. Thank you! It’s interesting to hear about more use cases for this plugin. We will be looking at this more closely soon based on this year’s eperience, to see what we might be able to do to improve it before next year!

In the meantime, for this go round you can edit the post once it’s posted as you see fit.

One interesting behavior I noticed is that if you delete the generated topic it will create a new one the next day, as long as the plugin is enabled. So you could play around with the settings and generate multiple versions of the annual review topic, copy the text out of them, and then publish new topics yourself as you see fit. If you have access to /sidekiq you can find the job there and run it immediately.

[Jagster (Jakke Lehtonen)]

@tobiaseigen

if you delete the generated topic

And that’s why a tip to publish the review first at more private category, i.e. Staff, and then move to public, is actually not-so-good advice Unless an admin wants to keep two versions.

Not a biggie, though.

[Ayelen_Rives (Aye Rives)]

@Ayelen_Rives

I’ll found out on January 1st if it is created.

Hi! Fortunately the plugin triggered itself on January 1st without any issue!

I come now with some questions about how it works because some reports (like Most Topics & Most likes given) show different results than the Users page for the same period.

For instance, for Most topics the Users page shows first the user “S”:

And the Yearly review shows first the user “C” and never shows user “S” in the table:

(Sorry, I have to blur the images for company confidenciality, but I think it’s clearer if I add them. Also, the table is broken, you can ignore it )

Does anyone know why this could be happening? Other reports show exactly the same information, but Most topics and Most likes given shows different users.

Thank you so much for your help!

[tobiaseigen]

@Jagster

And that’s why a tip to publish the review first at more private category, i.e. Staff, and then move to public, is actually not-so-good advice Unless an admin wants to keep two versions.

Whoa, I was not aware that this is what happens. I just tested it and you are right! This is a bug. It should not create a second yearly review topic if one exists already.

Replication steps:

1. once yearly review topic is created, move it to a different category
2. trigger creation of yearly review topic via /sidekiq
3. second yearly review topic is created.

If you run afoul of this issue I’d suggest disabling the plugin. We are going to be looking at this plugin soon to fix bugs and improve it before next year.

[ganncamp (G Ann Campbell)]

@tobiaseigen

One interesting behavior I noticed is that if you delete the generated topic it will create a new one the next day, as long as the plugin is enabled.

how persistent is it? If I keep deleting it, will we still be doing the dance in June?

And does this mean I don’t need to reach out to support to retroactively generate the post for my site? It’ll just appear some time tomorrow?

[Jagster (Jakke Lehtonen)]

@ganncamp

how persistent is it?

Really. It works via sidekiq every day.

[Moin]

@ganncamp

If I keep deleting it, will we still be doing the dance in June?

I would hope it will stop at the end of january.

The Yearly Review plugin keeps creating new topics

Thanks for following up on this. Relying on the topic’s title to prevent creating multiple review topics is a really flaky approach (that’s my fault.) Once January ends, the issue won’t come up again until next year. @JammyDodger, maybe you could pass a note to the Discourse team to look into coming up with a better way of preventing multiple topics from being created. That should get done before January 2024. Time sure flies