Community Health: monthly community health report system

[functionzz]

This PR creates a community health alert system for PMs, and allows PMs see month-over-month changes to CHS at a glance. It is compiled monthly.

Fixes #4329.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 94.32314% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.25%. Comparing base (d98e0ac) to head (c5a088b).
⚠️ Report is 2 commits behind head on main.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mathjazz]

Nice work!

Some high-level questions:

• Why is the /insights page shown to and the notification sent to is_staff users , but the emails can be opted in by is_superuser users?
• Why don't we automatically opt in all is_staff users also for receiving emails and drop the settings? This is an altert system afterall. Or at least opt them in by default, if we really want to keep the ability to opt out.
• Have we tested the notification in the translate view, which has its own notification implementation?
• The docstring says rows are "ranked by the size of that change", but the biggest gains come first and the worst regressions land at the bottom of the table. In an alert system, the regressions are the actionable half. Sort by abs(percentage) to match the docstring?
• The new command needs to be documented on documentation/docs/dev/deployment.md. We should mention it silently depends on cron ordering - it reads the current month's snapshot — which collect_chs_snapshots creates on that same day.
• We should also document the reporting feature for the Admins. Note that there's still #4338 (comment).

[mathjazz]

What's the purpose of this change?

[functionzz]

If we keep it as a span, if the description contains html elements, they will all be converted to text, which is not what we want.

[functionzz]

The main point is now we have a system notification that automatically sends but also contains more complex html + css, which was not supported with the current code. All our previous system notifications were just one-liner spans.

[mathjazz]

What's the purpose of these changes?

[functionzz]

Because I changed description to a div, I also want it to inherit css styling as well.

[mathjazz]

We should also add a test for the case when none of the locales passes a threshold.

[flodolo]

• Why don't we automatically opt in all is_staff users also for receiving emails and drop the settings? This is an altert system afterall. Or at least opt them in by default, if we really want to keep the ability to opt out.

I don't think all superusers are PMs interested in this information, so they should have a way to opt out. I have the feeling the majority falls into this category, hence the opt-in suggestion to Jamie.

[functionzz]

Why is the /insights page shown to and the notification sent to is_staff users , but the emails can be opted in by is_superuser users?

I actually think it should be only reserved to is_staff users - I made the change before you reviewed, but it seems I didn't completely change options. I need to change both user pool to be from is_staff.

Why don't we automatically opt in all is_staff users also for receiving emails and drop the settings? This is an alert system after all. Or at least opt them in by default, if we really want to keep the ability to opt out.

Just like the other email systems in Pontoon, I think we should keep the option to opt in given both the notification & email output very similar things.

Have we tested the notification in the translate view, which has its own notification implementation?

Not yet, will do that now.

The docstring says rows are "ranked by the size of that change", but the biggest gains come first and the worst regressions land at the bottom of the table. In an alert system, the regressions are the actionable half. Sort by abs(percentage) to match the docstring?

Sure.

The new command needs to be documented on documentation/docs/dev/deployment.md. We should mention it silently depends on cron ordering - it reads the current month's snapshot — which collect_chs_snapshots creates on that same day. We should also document the reporting feature for the Admins. Note that there's still #4338 (comment).

Sure, I'll make the changes in this PR.