Discussion about Redesigning Community Recognition: Graduated Badges, Multi-Repo Impact & Beyond GitHub

Meshery
, , ,
1

Hi everyone ,

We are actively revamping our community recognition and badge automation pipeline across Layer5, Meshery, and our broader ecosystem.

During our Dev meet on 7th Oct 2026, Lee Calcote and community members highlighted a core philosophy: psychology and meaningful recognition > raw automation. Badges shouldn’t just be an automated counter, they should provide a clear journey of progression, reward high-impact work, and celebrate contributions both inside and outside of GitHub.

We want to open this discussion to get everyone’s thoughts, ideas, and preferences. Here are the key proposals :-

1. Graduated / Tiered Recognition Order

Rather than isolated, one-off badges, we want to lay out recognitions in a graduated order (e.g., Novice → Contributor → Specialist → Maintainer/Champion or Bronze → Silver → Gold).

  • The Goal: Gives contributors a clear sense of milestone achievement and a visible path to grow within the community.

  • Question for you: How do you prefer badge tiers to be named and structured? (e.g., Tier numbers, metals, or role-based titles?)

  • Which badges should be tiered ?

    Should every contribution area follow this graduated structure (e.g., repo tracks like Meshery, Sistent, Docs, Community Support)?

    Or should tiering apply only to core tracks while keeping certain special achievements as standalone badges?

2. Multi-Repo Breadth vs. First-Timer Milestones

Our ecosystem spans dozens of repositories (meshery, meshery-operator, meshsync, sistent, docs, etc.).

  • First-Timer vs. Repo Badges: Currently, a badge is awarded at >= 1 PR per repo. We are evaluating whether to have a universal “First-Time Contributor” badge, or rename repo badges so they explicitly celebrate this first milestone.
  • Cross-Repo (“Ecosystem”) Recognition: Introducing a badge track for contributors who contribute across multiple different repositories, showing broad architectural and cross-project versatility.

Poll on First-Time Recognition:

  • Dedicated Universal First-Timer Badge
  • Keep repo-specific badges with updated milestone naming
  • Both (Universal first-timer badge + graduated repo badges)
0 voters

3. PR Quality & High-Impact Contributions

As raised in the meet, PR count alone doesn’t reflect true effort:

  • Should we introduce recognition specifically for PR / Contribution Quality (e.g., major architectural enhancements, complex bug fixes, significant test coverage additions, or complex refactors)?
  • How should we determine this? (e.g., maintainer nomination / label-based triggers like major-feature or high-impact?)

4. Beyond Git: Slack Activity, Community Help & Advocacy

Not all vital contributions happen on GitHub PRs:

Poll on Recognizing Community & Slack Help

  • A dedicated new badge (e.g., Community Guide, Slack Helper etc)
  • Included as qualifying activity within the existing Continuous Contributor badge
0 voters
  • Slack & Forum Activity: Recognizing members who actively unblock others, answer questions in #general/#support etc , and guide newcomers through their first dev setup.
  • Advocacy & Social Tracking: Recognizing community members sharing knowledge outside the repo (technical blogs, YouTube tutorials, talks, and tracking posts on LinkedIn, Reddit, and X/Twitter mentioning “Meshery” or community keywords).
  • High Impact but Non-Quantifiable: Acknowledging the people whose work isn’t easily tracked by a script (e.g., peer support, meeting coordination, code review assistance).

5. Scheduled & Milestone Tracks (Periodic Evaluation)

Some recognitions depend on sustained habits and consistency over a time window rather than a single merged PR:

  • Issue Reporter / Bug Hunter Badge:

    • Awarded for active, high-quality issue creation and triaging (e.g., opening > 10 verified issues/bug reports over a defined time period).

  • Consistent Designer / Catalog Creator Badge:

    • Awarded to community members who regularly publish infrastructure models & design patterns to the Meshery Catalog (e.g., publishing at least 1 verified design every month over a period of 3–6 months).

  • Issue & Catalog Design Badges Which of these scheduled/milestone tracks would you like to see implemented?

    • High-volume / High-quality Issue Reporter Badge
    • Consistent Catalog Designer Badge (monthly recurring catalog designs)
    • Both
    0 voters

6. Peer-to-Peer Recognition (“Recognize One Another”) & Ad-Hoc Awards

  • Peer Shoutouts / Nominations: We want a mechanism where contributors can endorse, shout out, or nominate fellow community members who helped them out.
  • Ad-Hoc Maintainer Awards: Ensuring Maintainers, Community Managers, and MeshMates can easily grant recognition for unmeasurable, exceptional contributions.
  • Synced Profiles: Making sure recognitions are seamlessly displayed across Layer5 Cloud and the Discussion Forum.

We’d love to hear your thoughts!

  1. Which of these badge tracks (e.g., Multi-repo, Quality PR, Advocacy, Slack support) would motivate you most?
  2. How would you like peer nominations to work (e.g., a dedicated Slack command/channel, forum topic, etc)?
  3. Any new badge / creative badge name ideas you’d love to see in the community?

Drop your thoughts and suggestions below!

2
  1. Slack activity and advocacy badge excites me the most. Though PR counts or multi repo needs to be enabled for motivating people. But slack and advocacy are the two that will boost the people/community side of open source.
  2. Regarding that peer nomination (if we are restricting to successful pr merges) then we can have a command, like whenever a pr is merged, then the author gets notified to give shoutout to people who have helped him/her during that process. But we should also have some pipeline or a slack workflow in which if someone is helping communities in other ways than that of code contribution, then how could we give track them up? (can’t really think of how can we automate this.)
3

1.Totally agreed ! Rewarding people who guide others and represent the project externally ensures that newcomers actually stay and thrive.

2.The idea to prompt the PR author upon merge is fantastic. A couple of ways we could make this work -

  • Bot Prompt on Merged PR: When our recognition workflow merges a PR, the bot could leave a small comment:

    “Did someone in the community help or unblock you on this PR? Give them a shout-out with /kudos @username!”

  • We could also automatically award recognition to contributors added via Co-authored-by: in commit messages or active non-maintainer PR reviewers.

A few lightweight ways we can automate the Tracking Non-Code / Slack Help :

  1. Slack Slash Command (e.g., /kudos @user [reason]):
    • Contributors can give a shoutout when someone unblocks them in Slack.
    • It sends a message to #recognition and logs into our backend.
    • To prevent gaming, members could have a weekly limit of 2–3 kudos to give.
  2. Emoji Reactions :
    • Using a specific emoji (like :layer5-kudos: or :clap:) on a helpful answer in #general or #support. If a maintainer/MeshMate or community member reacts, a webhook captures it.
  3. Threshold-based Badges:
    • Once someone receives a certain number of verified kudos from peers over a month, the system automatically awards the Community Guide / Slack Helper badge.

What do you think ?

4

I really like the first workflow of prompting author to give shoutout to people who have helped them during the process of issue to successful merged pr. Though I am not sure about co-authored one cause nowadays most of pr are co-authored by Claude, so would that make sense or not (if we have any other collaborative pr with real contributor then it is a fantastic idea to acknowledge both contributors).

Other than this regarding the slack cmd to acknowledge non-code contributions, we can definitely limit to avoid spam but still I feel like this can be misused in some ways like 2 people/contributor acknowledge each other so that they can get that badge. Are we verifying the reason of shoutout with the actual contributor made by them?

5
  1. Quality PR / Architectural Impact- This track will be a huge driver for meaningful contributions. Rewarding refactoring, complex bug fixes, or major features shifts the focus away from “PR farming” (tiny doc edits) and incentivizes contributors to tackle high-effort technical challenges.Slack Support & Community Guide- Unblocking others and providing newcomer support is the backbone of community retention. Having a visible badge for non-code support ensures active community helpers feel valued for their time.Multi-Repo / Ecosystem Breadth- Given that Meshery spans multiple repositories (meshery, meshsync, sistent, docs), a badge that rewards cross-repo capabilities encourages contributors to learn the broader architecture rather than staying siloed in a single project.
  2. PR Merge Bot Prompt (Lightweight & Immediate)- Prompting authors upon a merged PR via a bot comment (e.g., “Did someone help you on this PR? Give them kudos!”) catches feedback right when appreciation is freshest.Auto-capturing- Automatically parsing commit headers for Co-authored-by: or recognizing active non-maintainer reviewers ensures technical collaboration is credited without extra manual steps.
  3. Support & Community Tracks-

    • Beacon / Unblocker (For frequently resolving issues on Slack/Forums)

    • MeshMate Vanguard (For onboarding and guiding first-time contributors)Code & Quality Tracks:

    • Code Craftsman (High-quality refactoring or complex feature implementation)

    • Bug Hunter / Bug Wrangler (Consistent, detailed issue reporting and reproduction)

6

1. Graduated / Tiered Recognition

I like the graduated order. It gives contributors a clear path to move forward and makes it easier to see their progress within the community.

2. Multi-Repo & First-Timer Recognition

I don’t think PR count should matter much here. The focus should be on the impact and quality of the contribution, rather than how many PRs someone has made.

3. PR Quality & High-Impact Contributions

I think contribution quality should be recognized based on the actual impact of the work, not PR count. Maintainer nomination could be a good way to identify high-impact contributions.

4. Scheduled & Milestone Tracks

I’d suggest the Bug Hunter badge. It could be a good way to recognize contributors who consistently find and report quality issues.

5. Peer-to-Peer Recognition & Ad-Hoc Awards

I like the idea of having a dedicated Slack command for peer recognition. If someone provides good mentorship or support that isn’t easy to measure automatically, we could also give them a badge manually. The synced profile idea sounds good too.

7

  1. Quality PR/architectural impact would be the most motivating for me. PR depth: I agree with Ankit: the impact and difficulty of the work should matter more than the number of PRs. I also like the multi-repo and graduated recognition ideas above.

  2. I prefer a simple Slack command for peer nominations. I agree with Tejaswi that kudos when a PR is merged could be a good idea.

  3. Meshery Explorer: For contributors who go beyond their usual area and start contributing in different parts of the ecosystem.

8

I think one area that could be considered as part of the recognition system is PR review activity.

A contributor’s impact isn’t always reflected by the number of PRs they open. Someone who regularly reviews other contributors’ work, tests changes, finds issues, suggests improvements, or helps a first-time contributor get their PR into a mergeable state can have a significant impact on the project.

It could be interesting to have a recognition path around this, for example:

  • Recognize contributors who consistently provide meaningful PR reviews.

  • Give additional recognition for reviews that identify bugs, improve tests, catch regressions, or lead to better implementation/design decisions.

  • Recognize contributors who regularly help first-time contributors through reviews and feedback.

  • Consider cross-repository review activity as another indicator of broader ecosystem involvement.

  • Reward consistency over time rather than only looking at the total number of reviews.

I think the main thing to avoid would be making this purely “number of reviews = badge”, because that could encourage quick approvals without much value. The quality and impact of the review should matter more than the raw count.

This could also fit nicely with the proposed Quality / High-Impact Contribution recognition. A review that catches an important issue or significantly improves a contribution can be just as valuable as writing the original code.

Overall, I think there could be a progression from Contributor → Reviewer → Mentor/Champion, where contributors are recognized not only for what they build, but also for how they help other contributors succeed.

9

Thanks for the detailed proposal! A few thoughts building on the points above:

1. Make kudos verifiable
If /kudos requires a link, we can verify it automatically. For example, a PR kudos should come from someone who actually reviewed/commented on that PR. For Slack, the link should point to the relevant thread. The receiver could also confirm the kudos before it counts.

2. Keep it hard to game
Count unique people rather than total kudos, limit how many someone can give each week, and reduce/remove reciprocal kudos.

3. Co-authored-by
Since AI tools can add Co-authored-by, I think we should only count it when the person has other activity on the PR, or just rely on verified kudos instead.

4. One more idea — recognize work that actually ships
A PR being merged doesn’t always mean it reaches users. We could trigger recognition when a qualifying contribution is included in a stable release. For example, a First Release badge for someone’s first shipped contribution, with higher recognition for contributions shipped across multiple releases.

This seems quite objective and could be automated through the existing release workflow.

10

I’d be most motivated by the Quality PR and Multi-repo Contributor badgs , as they recognize both the impact of an individual contribution and involvement across the Layer5 repos.

For peer nominations, I think a dedicated forum topic or Slack channel would work well, where community members can nominate contributors with a brief explanation of their impact. Maintainers could review nominations periodically to keep the process fair and meaningful.

One additional badge idea could be a “Mentor of the Month” badge to recognize people who consistently help newcomers, explain technical concepts, review others’ work, or help contributors overcome blockers. I think recognizing these contributions would encourage a more welcoming and collaborative community.