The TDK CLI Hall of Fame Has Ranks. Here's How to Climb Them.

Most contributor lists count pull requests. TDK CLI's hall of fame counts something harder to fake: which issues your merged work fixed, and how hard those issues were.

The list lives in issue #602 "Hall of fame: community contributors" in the tdk-cli-core repo. A bot updates it on every merge, and it currently lists 24 contributors who have had work merged. I read it as it stood when I checked. Numbers will have moved since.

How the ranks work

Every issue in the repo carries a rank: label. The scale runs from the easiest to the hardest:

• 8 kyu is the entry level.
• 7 kyu down to 1 kyu step up in difficulty.
• 1 dan is the hardest rank.

A contributor's rank is the highest rank label on any issue their merged pull requests fixed. The hall of fame table shows four numbers for each person:

• Merged PRs: how many pull requests of theirs were merged.
• Issues fixed: how many distinct issues those pull requests closed.
• Highest rank: the hardest issue they have fixed, on the kyu/dan scale.

The table's own note says the easiest rank is 8 kyu, and that you "pick a harder issue to rank up". That is the whole game: the rank is about the difficulty of the work, not how often you show up.

What the table shows right now

At the time of my check, the top of the list looked like this:

• @sb123sb123: 43 merged PRs, 38 issues fixed, highest rank 5 kyu.
• @AK-Lmn: 23 merged PRs, 18 issues fixed, highest rank 4 kyu.
• @minutechreview: 21 merged PRs, 21 issues fixed, highest rank 7 kyu.

Look at the second and third rows. @minutechreview has more issues fixed than PRs closed in a different way: 21 PRs, 21 issues, all at 7 kyu. That is a steady run of easy, well-scoped fixes. @sb123sb123 reached 5 kyu with 38 issues, so harder work and volume together are what move the rank up.

Most people in the list are still at 6 to 8 kyu. A handful of entries have no rank yet, because the table only shows a rank once an issue carrying one has been fixed.

How to climb

1. Start at 8 kyu. Documentation and translation issues are the usual first step. They are small, self-contained, and easy to review. The Hacktoberfest label marks many of them.
2. Move to 7 kyu. These are small fixes with a test. Test-coverage issues and tidy refactors are good examples.
3. Take one 6 kyu issue that touches code you have read. Pick an issue in an area you have already worked in, so the ramp is steep only once.
4. Keep the rank label in view. Filter the issues by rank: to see what is at your level and the next one up.

The rank is a signal of difficulty, not of quality. A clean 7 kyu fix that reviewers merge quickly is worth more to the repo than a 5 kyu that stalls for a month.

What counts, and what doesn't

Some things make the table work correctly, and they are worth knowing before you open a pull request:

• Sign off every commit. Use git commit -s for the Developer Certificate of Origin line. Without it, the pull request check fails and nothing merges.
• One issue per pull request. The table counts issues fixed, so a pull request that bundles several unrelated changes does not give you several entries.
• Maintainers are not on the list. The hall of fame counts everyone outside the maintainer team. The repo has a related issue, #604, about skipping maintainers by name.

The islands

The rank labels sit inside the repo's islands, which group work by theme. This issue carries the island: Growth Bay label, which covers adopters, community, adoption docs and DX for new teams. Other islands cover tests, the engine and the CLI. You can pick an island and climb its ranks there, without touching the whole repo at once.

Why it's worth climbing

A rank tells a maintainer what you have already done, without a long introduction. It also shows which parts of the codebase you have worked in, because each merged fix sits in a specific area. If you want a reference for your next role, a list of fixed issues with ranks is a clear record.

The hall of fame is open to anyone. Start at 8 kyu, and the table will show where you are after your first merge.

This is a contribution guide, not a DEV challenge entry. Current challenge rules require a new project built during the challenge window, and pull requests to existing projects do not count.