feat: add some per country/affiliation meeting registration statistics

[evyncke]

Very simple (read trivial) attempt to present some registration statistics using pie-chart (from charts.js).

Missing is some percentage data (only participants count for now), expand country code to country name, be able to change the meeting number (beside fiddling with URL).

Alas, no data is kept on the ticket creation date, i.e., cannot have a timeline of registration for a specific meeting.

[evyncke]

Could also do stats per affiliation ;-)

[codecov]

Codecov Report

❌ Patch coverage is 95.37037% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.48%. Comparing base (15b2abd) to head (138e936).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
ietf/stats/views.py	95.37%	10 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10550      +/-   ##
==========================================
+ Coverage   88.42%   88.48%   +0.05%     
==========================================
  Files         331      332       +1     
  Lines       44557    44808     +251     
==========================================
+ Hits        39399    39647     +248     
- Misses       5158     5161       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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

[evyncke]

Meeting statistics are done, so, this PR could be merged (I won't work on it unless tools-team requests so to fix issues).

Next codesprint will handle the documents statistics but this should not prevent already merging this PR.

[jennifer-richards]

Looks really nice. Before merging, we need to move code from the inline <script> tag into a module. This commit illustrates what's involved, but I'm happy to handle that if you'd prefer.

We may want/need to add some caching to the views as well.

[evyncke]

If you do not mind, then please go forward with the move to a specific JS script. And the caching would be useful as it takes 2-3 seconds on my laptop to generate the data (and the data does not really change hourly). Could generate a big JSON every day ?

[jennifer-richards]

If you do not mind, then please go forward with the move to a specific JS script.

Ok, will do.

And the caching would be useful as it takes 2-3 seconds on my laptop to generate the data (and the data does not really change hourly). Could generate a big JSON every day ?

I'll see about adding at least basic caching before we bring this live.

Thanks!

[evyncke]

If you do not mind, then please go forward with the move to a specific JS script.

Ok, will do.

And the caching would be useful as it takes 2-3 seconds on my laptop to generate the data (and the data does not really change hourly). Could generate a big JSON every day ?

I'll see about adding at least basic caching before we bring this live.

Thanks!

@jennifer-richards any news ? I understand that it is low priority for you and if you cannot do it, then I will give the 'moving JS out of template' part a try.

Unsure about the caching, any pointer/reference/example on how to do it ?

Thanks again

[jennifer-richards]

@evyncke

My apologies. I expect that the next datatracker release will be next week and do plan to get this wrapped up for that. If you want to work on it a bit I don't object, but it's just been slow, not forgotten.

[jennifer-richards]

I've put the refactoring + caching on a PR here: evyncke#1 - if you merge that in your fork, it should appear in this PR