[Feature Request]: "Most Improved" & Streak Badges for Daily and Weekly Leaderboard

[Vachhani-Tapan]

Description

To boost user motivation and recognize daily consistency and acceleration, we want to introduce dynamic badge decorations next to user names on the leaderboard. These badges will be calculated automatically during the daily sync run by comparing historical daily files.

Proposed Badges

1. [HOT_STREAK] — Awarded to students who have solved at least 1 problem every single day for the past 7 days.
2. [SPEEDRUN] — Awarded to the top 3 students who achieved the highest problem-solving velocity (most problems solved) over the last 7 days.
3. [UP_LINK] — Awarded to students who jumped up by 5 or more positions in the ranks compared to the previous day.

---

Implementation Plan

1. Sync Script Updates (scripts/sync-leaderboard.js):

   • Enhance the script to parse JSON files from the past 7 days.
   • For each user, track daily difference counts over the week to check if they solved >= 1 problem each day.
   • Compute rank movements and problem acceleration compared to historical logs.
   • Save these computed badges (e.g. badges: ["HOT_STREAK", "SPEEDRUN"]) into overall.json, daily.json, weekly.json, and monthly.json.

2. Frontend UI Rendering:

   • Update renderLeaderboard(data) in leaderboard.html to look for user badges.
   • Style these badges to match the existing privilege tags ([ROOT], [SUDO], [EXEC]) but with distinct thematic colors (e.g., violet for [HOT_STREAK], red/cyan for [SPEEDRUN]).
   • Add tooltips to explain why each badge was awarded when hovering over it.

[github-actions]

Thank you for opening an issue.

Please review our CONTRIBUTING.md guidelines before getting started.

A maintainer will review this issue shortly. If you would like to work on the issue yourself, please leave a comment requesting assignment.

[Vachhani-Tapan]

Hi @jagdish-15 Sir, Please Assign me this Issue under GSSoC'26

[anirudh5-creator]

Hi @jagdish-15
I am Anirudh Gowri Sankaran and I am a GSSoC 2026 Contributor and would like to work on this issue. Could you please assign it to me??

[jagdish-15]

This seems like a fair feature direction overall, but I think it would make more sense to keep this backend-only for now and defer the frontend badge rendering until the user-specific profile/details page from issue #8 is implemented.

Displaying too many inline badges directly on the leaderboard risks making the UI feel overly cluttered, especially with the existing tags, rank indicators, compare mode additions, etc.

For now, I’d suggest:

• generating/storing badges during the sync process,
• creating a badges.json file in the data repo,
• and exposing badges through /api/student/:username.

The API can simply return an empty array if a user has no badges.

For the badge logic itself:

• [UP_LINK] makes sense using the existing rank-change comparison against the previous day’s final leaderboard snapshot.
• For [HOT_STREAK], instead of loading and diffing 7 separate historical leaderboard files, it would probably be better to first filter users with weekly solved count >= 7 and then verify the actual streak using the LeetCode submission calendar data/API.
• [SPEEDRUN] can simply be allotted to the top three users in the weekly.json leaderboard.

Feel free to suggest any other meaningful badges that might be nice as well.

Once the user-specific frontend/profile page exists later, the badge rendering/UI side can be implemented much more cleanly there without cluttering the main leaderboard.

[jagdish-15]

@Vachhani-Tapan
Feel free to open the backend PR for now, keeping the suggestions above strictly in mind. Once issue #8 is resolved later, we can move toward implementing the frontend/profile-side badge rendering as well.

[Vachhani-Tapan]

@jagdish-15 Ok Sir i will work according to the above suggestion , and please sir review my last pull request so that after this work of issue is done so that i can open the new pull request . Thank You !

[jagdish-15]

Also, you can work on both this backend PR and the earlier comparison PR of yours simultaneously if you want to. This backend badge implementation won't overlap with the files modified there, so you should be able to work on both PRs without worrying much about merge conflicts.

No need to wait for one PR to be merged before opening the second one in this case.