Yesterday I wrote about Ground Control, the admin dashboard that nobody sees but everyone benefits from. Today it got a significant upgrade: a PRs tab that cross-references registration data with the scoring engine output, so I can debug any contributor’s scoring situation in under 10 seconds.

The Debugging Workflow That Was Killing Us

Here is a scenario that plays out multiple times a day during SSoC 2026:

“Bhaiya, I merged 3 PRs but my leaderboard score is still 0. Please help.”

Before today, debugging this meant opening three browser tabs:

  1. The Google Forms TSV, search for their Discord ID, find their registered GitHub username
  2. The scoring engine JSON, ctrl+F for their GitHub username, check if any PRs show up
  3. The project registry, verify the repo they contributed to is actually an SSoC project

If the username had a case difference between registration and GitHub (PraveenKumar vs praveenkumar), the scoring engine would silently not match them. If they contributed to a repo that was not registered, same silent failure. Every investigation was a manual three-way cross-reference that took 15-30 minutes.

With 3,000 active contributors and a growing number of merged PRs, this does not scale.

The Fix: One Tab, One Search

Ground Control now has two tabs: Registrations (the existing validator) and PRs (the new viewer). Click the PRs tab, type a Discord ID or GitHub username, and you get the complete picture:

Registration card, their name, role, GitHub, Discord ID, project, and email. Instantly confirms they are in the system.

Diagnostics panel, colour-coded cards that tell you what is right and what is wrong:

  • Green: Registered, they are in the master sheet, GitHub and Discord ID confirmed
  • Amber: Case Mismatch, registered as PraveenKumar but scoring engine has PRs under praveenkumar. This is the single most common cause of “missing score” complaints
  • Amber: No PRs Scored, registered correctly but the scoring engine has zero PRs for them
  • Red: Not Registered, PRs exist under this GitHub username but there is no registration record. Their score will never count until they register
  • Amber: Unregistered Project PRs, they have PRs in repos that are not registered SSoC projects

Five diagnostic checks, presented as cards, with green/amber/red colour coding. The admin reads the colours before the text. Green means move on. Amber means investigate. Red means there is a blocking issue.

The PR Table

Below the diagnostics sits a sortable table of every scored PR for that contributor:

# Project Title Level Score Merged
42 owner/repo Fix authentication bug Medium 45 Jun 5, 2026

Level badges are colour-coded (Easy in emerald, Medium in blue, Hard in amber, Advanced in rose). A summary row shows total PRs, total score, and a level breakdown, “3 Easy, 2 Medium, 1 Hard”, so I can see at a glance whether someone has been grinding easy PRs or tackling harder ones.

Columns are sortable. Click “Score” to sort by highest score first. Click “Merged” to see the most recent work.

Show All Mode

Sometimes the question is not about a specific contributor. Sometimes I need to browse all scored PRs. The “Show All” toggle loads every PR from the scoring engine into the table, adds an Author column, and enables a filter that searches across all fields.

This is useful for questions like “which PRs were scored in project X?” or “how many Advanced-level PRs have been merged this week?”

Two Search Modes, On Purpose

The search has a dropdown: Discord ID (default) or GitHub Username. I specifically wanted separate options rather than a single ambiguous search box.

Why? Discord IDs and GitHub usernames can look similar. A search box that guesses which one you typed will guess wrong at the worst possible moment. The explicit dropdown means there is never ambiguity about what the system is matching against.

Discord ID is the default because that is what contributors paste in support threads. They know their Discord handle. They do not always remember whether their GitHub username has a capital letter.

The Architecture Choice That Matters

The PRs tab reads from window.prs and window.userScores, JavaScript globals loaded via script tags from the scoring engine output. These are the same files that power the public leaderboard.

Registration data comes from the TSV via props passed down from the parent Ground Control component. But here is the thing: the TSV is localhost-only. It contains PII (emails, phone numbers) and never leaves the admin’s machine.

This means the PRs tab works on production even without the TSV. Anyone who knows the route can go to the PRs tab, search by GitHub username, and see their scored PRs. The registration card and cross-reference diagnostics only appear when the TSV is loaded locally.

In practice: I get the full debugging experience on my laptop. Contributors get a self-service PR lookup on prod. Same component, different data availability, graceful degradation.

What 10 Seconds Buys You

The debugging workflow went from this:

  1. Open Discord, copy contributor’s Discord ID
  2. Open Google Sheets, search for Discord ID, find GitHub username
  3. Open scoring JSON, search for GitHub username, check PR list
  4. Compare GitHub username casing between registration and scoring
  5. Check if the repo is registered as an SSoC project
  6. Reply to the contributor with findings

To this:

  1. Paste Discord ID into Ground Control PRs tab
  2. Read the diagnostic colours
  3. Reply to the contributor

Three data sources, five diagnostic checks, one search box, 10 seconds. At 50,000 participants, this is not a nice-to-have. It is infrastructure.


Ground Control lives at a route that is not in the navbar. That is by design. The best admin tools are the ones that make support threads shorter and programme operations smoother. If you never hear about Ground Control, it is working.

Image Suggestions

  1. Hero image: Screenshot of the PRs tab showing a search result with the diagnostics panel (green “Registered” card + the PR table below). Crop to show the search bar, diagnostics, and top of the table.
  2. Diagnostics close-up: Zoomed screenshot of all 5 diagnostic cards (green, amber, amber, red, amber), even if staged with test data. This is the most visually distinctive element.
  3. Before/After split: Left side shows 3 browser tabs (Google Sheets, JSON file, project config). Right side shows the single Ground Control PRs tab. Text overlay: “15-30 min → 10 sec”
  4. Tab switcher: Screenshot showing the two-tab UI (Registrations | PRs) to convey that this is an addition to an existing tool, not a standalone page.
  5. Show All mode: Screenshot of the full PR table with the Author column visible, showing multiple contributors’ PRs in one view.