Repository navigation
[CI] End-to-End Badge Assignment Automation #116
Description
Current Behavior
Currently, only a few badges (like Design Pioneer / first-design) are programmatically assigned in Layer5 Cloud when a user performs a first-time action, while others rely on manual trigger scripts or Slack commands (badge-award.yml). Most badges on badges.layer5.io require manual tracking.
Desired Behavior
Automate badge assignments programmatically across ~30 eligible badges on badges.layer5.io using quantifiable criteria, categorized into 4 core execution tracks:
- In-App Cloud Events: Backend triggers when users perform first-time in-app actions.
- Project Contribution PR Merges: Reusable GitHub Action running on merged PRs to grant project badges.
- Monthly Contributor Crons: Scheduled GitHub Action calculating multi-month / cumulative milestones.
- Org & Role Webhooks: Automated badge sync for GitHub Org & Slack role grants.
Implementation
- Track 1: In-App Cloud Events (Layer5 Cloud Backend)
first-application(Application Pioneer): InterceptPOST /api/application.first-share(Sharing is Caring): Intercept catalog publish / visibility change inPUT /api/pattern.bring-a-buddy(Bring a Buddy): Award upon invitation acceptance.gitops-connected(GitOps Connected): Trigger on GitHub App installation webhook.first-deployment(Shipped): Telemetry event on successful deployment.need-for-speed(Need for Speed): InterceptPOST /api/perf/profile/result.first-interactive-terminal-session(Hip Hacker): Pod exec websocket open telemetry.first-log-streaming-session(Log Streamer): Pod log stream websocket open telemetry.
- Track 2: Project Contribution PR Merges (GitHub Actions)
- Reusable PR merge workflow mapping merged PR paths to contributor badges (
sistent-contributor,meshery,meshery-operator,meshsync,meshery-docs,meshery-catalog,landscape,ui-ux).
- Reusable PR merge workflow mapping merged PR paths to contributor badges (
- Track 3: Monthly Contributor Milestone Crons (GitHub Actions)
- Scheduled monthly workflow (1st of every month) querying GitHub GraphQL API for
continuous-contributor,longevity-legend,review-rockstar,code-cleanup-crew,security-sentinel.
- Scheduled monthly workflow (1st of every month) querying GitHub GraphQL API for
- Track 4: Org & Role Webhooks
- Webhook integration for
employeeandmeshmatebadges.
- Webhook integration for
Acceptance Tests
- Merging a PR in project repositories automatically triggers badge award API calls for authors.
- End-of-month scheduled workflows calculate contributor thresholds and issue badges accurately.
- In-app actions trigger badge assignment and notifications seamlessly.
Contributor Guides and Resources
- 🛠 Meshery Build & Release Strategy
- 🎨 Wireframes and designs for Layer5 site in Figma (open invite)
- 🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack
PARTH-TUSSLEQuantification of Badge Assignments & Automation Architecture
This proposal incorporates feedback from the community recognition discussion, including the Track 5 peer-recognition proposal, poll outcomes, and pending maintainer decisions.
Items marked Proposed are suggestions, not approved implementation scope. Open decisions are explicitly documented in Section 10.
1. Overview & Evaluation Strategies
This proposal defines quantifiable eligibility criteria, data sources, and automation boundaries across eligible Layer5 and Meshery badges.
Badges are organized into five operational tracks based on their data sources and evaluation mechanisms.
This revision also proposes two poll-driven ba…
Activity
[-][CI][/-][+][CI] End-to-End Badge Assignment Automation[/+]k-anushka14 commentedon Sep 12, 2026
Hi @PARTH-TUSSLE ! I’d like to work on this issue, particularly Track 2: Project Contribution PR Merges — implementing the reusable GitHub Action to automatically assign contributor badges when PRs are merged.
Could you please assign this track to me, or let me know if there’s any existing design/API implementation I should follow before starting?
PARTH-TUSSLE commentedon Sep 13, 2026
Hey @k-anushka14 , thanks for showing interest however this issue isn't for assigning to anyone at the moment.
Maanvi212006 commentedon Oct 4, 2026
Regarding Track 2:
What I found
POST /identity/users/badges. It needs the recipient's Layer5 user UUID (userId), and the caller can't be the recipient.Signed-off-by) and outputs a/award-badge <email> <slug>Slack command, which matches the current manual flow.Two approaches
A layered mix is also possible: GitHub ID, then email, then manual award.
Questions
PARTH-TUSSLE commentedon Oct 6, 2026
Thanks for digging into the Cloud and Kratos side @Maanvi212006!
Thoughts on Direction:
The Email approach in #122 can be shipped without any Cloud-side changes and matches the existing manual award flow. It leverages the exact Slack bot workflow already used manually, and PR #122 already has robust fail-closed handling (DCO verification, terminal trailer parsing, and noreply safety).
A GitHub ID lookup via Kratos is a great Phase 2 evolution, but it depends on Cloud team bandwidth to build/expose a lookup endpoint and only covers contributors who signed up via GitHub OAuth.
Recommendation: Proceed with the layered roadmap:
Phase 1 (Immediate): Merge and ship #122 (Email / Slack dispatch) to get immediate PR-merge automation working.
Phase 2 (Future): Once Cloud implements a GitHub ID lookup endpoint, add GitHub ID resolution as the primary tier before falling back to email.
For direct Cloud calls (POST /identity/users/badges), the bot account would need global admin permissions (or a dedicated service role like BadgeAutomationService) capable of granting badges across all organizations/users, rather than being bound to a single user's org.
Having Lee or someone with Kratos DB access share the percentage of users with linked GitHub accounts would definitely help scope the coverage for Phase 2!
PARTH-TUSSLE commentedon Oct 6, 2026
Quantification of Badge Assignments & Automation Architecture
This proposal incorporates feedback from the community recognition discussion, including the Track 5 peer-recognition proposal, poll outcomes, and pending maintainer decisions.
Items marked Proposed are suggestions, not approved implementation scope. Open decisions are explicitly documented in Section 10.
1. Overview & Evaluation Strategies
This proposal defines quantifiable eligibility criteria, data sources, and automation boundaries across eligible Layer5 and Meshery badges.
Badges are organized into five operational tracks based on their data sources and evaluation mechanisms.
This revision also proposes two poll-driven badges:
first-contribution— Universal First-Timer (Poll 1 winner: "both"). Placed in Track 2.catalog-designer— Consistent Catalog Designer (Poll 3 winner: "both"). Placed in Track 1.Both remain proposals pending the decisions documented below.
Operational Tracks
Evaluation Strategies
assignBadge(). No asynchronous event bus is introduced.pull_request_target: closed. Appliesbadge-awarded:<slug>labels for PR-level duplicate protection.release: publishedfor the First Release badge.layer5io/recognition, together with the existing manual award flow. The location and implementation of the Slack/award-badgecommand remain open questions./kudoscommand intake from GitHub PR comments and Slack, stored as events in Cloud and evaluated by a monthly cron. Includes Mentor of the Month voting and maintainer verification.Global Invariants
Identity
Cloud awards require the Layer5
userId, but a merged PR or GitHub event provides a GitHub identity such aslogin, numericid, and commit emails.The method for resolving a contributor to a Layer5 user remains an open decision (Section 10, Decision 1).
PR #122 currently resolves identity through commit email. A GitHub ID lookup through Kratos is an alternative under consideration.
Track 5 also requires a mapping between Slack users and Layer5 users (Section 10, Decision 14).
Exclusions
Automated evaluations skip bot accounts (
type == "Bot"orloginending in[bot]) and the system userl5io.For Track 5, bots and
l5iocannot give or receive kudos.Idempotency
Cloud's
assignBadgeskips users who already hold a badge. A repeat award must not create a second award event or send another notification email.This behavior is verified in
assignBadgeWithNotificationinbadge_helpers.go.Non-Exclusivity
Track 2 evaluations are non-exclusive. A PR satisfying multiple badge rules receives all matching badges.
Kudos Are Events, Not Badges
A kudos is a thank-you that is counted toward recognition. A single kudos does not itself award a badge.
Allowlisted Repositories
For Tracks 2 and 3, the allowlist below is the proposed baseline. It matches
SUPPORTED_REPOSITORIESin PR #122 (utils/badge-evaluator.js), which currently covers Track 2 only.Whether Track 3 uses the same list must be confirmed by maintainers (Section 10, Decision 13).
The proposed Track 2
first-contributionbadge also uses this allowlist. The First Release badge uses stable releases from these repositories.layer5io/layer5layer5io/sistentlayer5io/docsmeshery/mesherymeshery/meshery-operatormeshery/meshsyncmeshery/meshery.io2. Badge Decision Matrix
first-designdesign-pioneer; remove duplicate award block in save handlerfirst-applicationfirst-sharefirst-deploymentfirst-interactive-terminal-sessionfirst-log-streaming-sessionneed-for-speedStoreResultsfirst-collaboratorbring-a-buddyAcceptInvitationgitops-connectedkanvas-snapshotmeshmap-snapshotin favor ofkanvas-snapshotcatalog-designer(slug proposed)sistent-contributormesherymeshery-operatormeshsyncmeshery-docsmeshery-docsversusdocs; create slug in Cloud; identity mappingmeshery-cataloglandscapeui-uxfirst-contribution(slug proposed)architectural-impact(slug proposed)impact/architecturalwriters-programmeshery.ioposts count; identity mappingreview-rockstarcode-cleanup-crewsecurity-sentinelsecuritylabelevent/security-slam*; create missing security labels; identity mappingcontinuous-contributorlongevity-legendhacktoberfest-contributor(yearly slug, e.g.hacktoberfest26)first-release(slug proposed)meshery-explorer(slug proposed)bug-hunter(slug proposed)communitymeshmatecncf-ambassadordocker-captainui-ux(design work only)advocate(slug proposed)community-guide(slug proposed)mentor-of-the-month(slug proposed)3. Track 1 — Product / Event-Driven Badges
Track 1 uses Strategy A.
first-design— Design PioneerAlready implemented in Cloud (
meshery_patterns.go) across saves, clones, and imports, while skipping anonymous users.design-pioneertofirst-design.first-application— Application PioneerStatus: Blocked.
No verified Applications persistence or event model was identified in Cloud handlers.
Implementation is paused pending clarification on whether the Applications feature is deprecated or whether an alternative product construct applies.
first-share— Sharing is CaringTrigger on explicit sharing (
users.go) or access grants (resources.go:209).first-deployment— ShippedStatus: Cross-repository dependency.
Kubernetes deployments execute inside Meshery Server, and Cloud currently receives no deployment event.
Award on the first successful deployment where
dryRun == falseandundeploy == false.Validation runs do not qualify.
Terminal and Log Streaming Badges
first-interactive-terminal-sessionandfirst-log-streaming-sessionrequire cross-repository telemetry.terminal_session_openedwhen an interactive terminal session is established.log_stream_openedwhen a log stream is established.need-for-speed— Need for SpeedTrigger on successful
AddMesheryResultwithinStoreResults.Award the user on their first SMP result published to Cloud.
Exclude background polling through
UpdateResultsWithMetrics.first-collaborator— GitOps with FriendsTrigger on a design save.
Award the design owner when an authenticated non-owner edits and saves an existing design.
Exclude presence pings and administrative edits.
bring-a-buddy— Bring a BuddyHook the
appendedbranch inAcceptInvitation.Award the inviter (
invitation.Owner) when an invited user accepts.Exclude self-invites and open-organization links.
gitops-connected— GitOps ConnectedStatus: Blocked on identity mapping.
GitHub App installation webhooks carry GitHub account or organization IDs, not Layer5 user UUIDs.
Ignore
deletedandsuspendevents.kanvas-snapshot— Kanvas SnapshotTrigger on the success branch of
PostGithubArtifact.Award the initiating user.
Standardize on
kanvas-snapshotand retiremeshmap-snapshot.catalog-designer— Consistent Catalog DesignerStatus: Proposed; Poll 3 winner: "both".
Recognizes contributors who regularly publish designs to the Meshery Catalog.
Rule: When a user publishes a verified design to the catalog, Cloud checks whether the same user also published in each of the two previous UTC calendar months. If yes, the badge is awarded. In effect, it is awarded on the publish that completes three consecutive months.
See Section 10, Decision 28.
4. Track 2 — GitHub Repository Activity
Track 2 is evaluated in CI when a PR is merged using Strategy B.
All Track 2 awards depend on the identity-mapping decision in Section 10, Decision 1.
Universal Exclusions
Exclude:
**/*.test.*,**/*_test.go,**/__tests__/**package-lock.json,yarn.lock,go.sum.github/**,LICENSE,README.md,CONTRIBUTING*.mdMinimum threshold: At least one qualifying merged PR authored by a human.
Repository Rules
sistent-contributor— Sistent ContributorRepository:
layer5io/sistentsrc/**,examples/**system/**(documentation),src/assets/**,package.json,tsconfig.json,Makefilepackages/**is excluded.meshery— MesheryRepository:
meshery/mesheryserver/**,mesheryctl/**,ui/**,provider-ui/**models/**,install/**(Helm/YAML), rootmain.go,go.mod,ui/docs/**,ui/public/**,ui/scripts/**meshery-operator— Meshery OperatorRepository:
meshery/meshery-operatorcontrollers/**,api/**,pkg/**,cmd/**zz_generated*,bundle/**,config/**,go.mod,go.summeshsync— MeshSyncRepository:
meshery/meshsyncinternal/**,pkg/**,meshsync/**integration-tests/**,go.mod,go.sumplugins/**andcache/**are excluded.meshery-docs— Meshery DocsRepositories:
meshery/meshery,layer5io/docs.mdand.mdxfiles underdocs/content/**inmesheryandcontent/**inlayer5io/docs.pages/**, theme layouts, site assets,catalog/**,integrations/**,data/**,meetings/**,static/**,archive/**,proposals/**.meshery-docsversusdocs) must be confirmed.meshery-catalog— Meshery CatalogRepositories:
meshery/meshery.io,meshery/mesherycatalog/**andcollections/_catalog/**inmeshery.io;models/**inmeshery.models/**inmesheryqualifies strictly formeshery-catalogand must not qualify for the generalmesherybadge.landscape— LandscapeRepository:
layer5io/layer5src/collections/landscape/**ui-ux— UI/UXRepositories:
meshery/meshery,layer5io/sistent,layer5io/layer5meshery/meshery: PR must carrycomponent/uiand modifyui/**orprovider-ui/**. The labelsarea/uiandarea/uxdo not exist.layer5io/sistent: Modifiessrc/**orsystem/**; no label required.layer5io/layer5: Modifiessrc/components/**,src/sections/**,src/reusecore/**,theme/**,templates/**, orpages/**; no label required.src/collections/**(blog/news) andsrc/assets/**.Offline flyers and graphic design work remain eligible for manual recognition through Track 4.
New Badge: Universal First-Timer
Proposed slug:
first-contributionStatus: Proposed; Poll 1 winner: "both".
Recognizes a contributor's first merged PR anywhere in the ecosystem. It complements the repo badges and does not replace them.
Rule: The first qualifying merged PR by a human in any allowlisted repository.
sistentearns bothfirst-contributionandsistent-contributor.See Section 10, Decision 27.
New Label-Gated Badge: Architectural Impact
Proposed slug:
architectural-impactProposed title: Code Craftsman
The evaluator cannot reliably determine architectural significance from changed files alone. A maintainer-applied label is therefore the qualifying signal.
Rule: A merged PR authored by a human qualifies when it carries the label
impact/architecturalat merge time.See Section 10, Decision 18.
5. Track 3 — Derived GitHub Activity
Track 3 uses Strategy C: scheduled jobs querying the GitHub GraphQL API over defined calendar windows.
First Release also runs on
release: published.All Track 3 badges depend on the identity-mapping decision in Section 10, Decision 1.
writers-program— Writers ProgramProposed rule:
.mdor.mdxpublications underlayer5io/layer5:src/collections/blog/**.meshery/meshery.io:collections/_posts/**should also count remains open.review-rockstar— Review RockstarProposed rule:
APPROVEDorCHANGES_REQUESTED) across allowlisted repositories.Review quality cannot be fully measured by a script. Helping first-timers and identifying meaningful issues can also be recognized through Track 5 kudos and the Track 2 architectural-impact label.
code-cleanup-crew— Code Cleanup CrewProposed rule: At least five merged PRs authored by a human and carrying the agreed cleanup label.
The current repository-label assessment indicates:
kind/cleanupdoes not exist in the allowlisted repositories.area/refactordoes not exist in the allowlisted repositories.kind/choreexists in all seven repositories but may include trivial changes.Maintainers must choose the qualifying label before this badge can run.
security-sentinel— Security SentinelProposed rule: At least one merged PR authored by a human and carrying the
securitylabel.The label is the machine-detectable qualification signal.
Open decisions:
event/security-slam*PRs also count? They mark a security event and may not all represent actual fixes.securitylabel be created insistentandlayer5io/docs, where it is currently missing?The label exists in
layer5,meshery,meshery-operator,meshsync, andmeshery.io.continuous-contributor— Continuous ContributorProposed rule:
The current draft counts merged PRs only.
Slack-help routing remains unresolved. The forum poll was 6–5 in favor of folding qualifying Slack help into
continuous-contributorrather than creating a dedicated badge. The current draft provisionally keeps Slack help in Track 5 pending maintainer sign-off.See Section 10, Decision 24.
longevity-legend— Longevity LegendProposed rule:
hacktoberfest-contributor— Hacktoberfest ContributorStatus: Seasonal and provisional.
hacktoberfest26.New Track 3 Badges
first-release— First ReleaseStatus: New, proposed.
Recognizes a contributor whose qualifying change reaches users in a stable release.
Trigger:
release: publishedin an allowlisted repository.Rules:
Higher recognition for shipping in several releases is a tier candidate.
See Section 10, Decision 20.
meshery-explorer— Meshery ExplorerStatus: New, proposed.
Recognizes contributors who work across different parts of the ecosystem.
Proposed rule:
Potential tiers could recognize activity across three, five, or seven repositories. These thresholds are placeholders.
See Section 10, Decision 21.
bug-hunter— Bug HunterStatus: New, proposed.
Recognizes consistent, high-quality issue reporting. Unlike
code-cleanup-crew, which rewards merged PRs, this badge rewards issues opened by contributors.Proposed rule:
The threshold, time window, and quality signal require maintainer approval.
See Section 10, Decision 22.
6. Track 4 — Manual Recognition
Track 4 uses Strategy D when reliable machine-readable triggers are unavailable.
community— Communitylayer5io/recognition.meshmate— MeshMatecncf-ambassadoranddocker-captainui-ux— UI/UX (Design Work Only)layer5io/recognition.advocate— AdvocateStatus: New, proposed.
Recognizes verified advocacy outside the repository, including talks, videos, tutorials, technical blogs, and social posts about Meshery.
layer5io/recognition.The slug, submission template, evidence rules, and any future partial automation require decisions.
See Section 10, Decision 23.
Ad-Hoc Recognition
Maintainers, Community Managers, and MeshMates may use the manual award flow to recognize exceptional work that no script can measure.
Who may award badges depends on the decision about the existing manual award flow.
7. Track 5 — Peer Recognition
Track 5 is new and uses Strategy E.
It recognizes contributions that may not show up in merged PRs, such as:
It requires Slack-to-Layer5 identity mapping, a Cloud location to store kudos, and a defined location for the Slack command.
See Section 10, Decisions 12, 14, and 15.
7.1 Kudos: Events, Not Badges
A kudos is a thank-you from one person to another. Each kudos is stored as an event in Cloud and counted for the recipient.
Intake in GitHub
/kudos @user reasonon a PR.Intake in Slack
/kudos @user reason.#recognitionand records the event in Cloud.The command's implementation location and authorization mechanism must be defined before rollout.
Limits and Validation
l5iocannot give or receive kudos.Co-authored-bytrailers and emoji reactions are not used because they are noisy or easy to game.7.2 Community Guide
Proposed slug:
community-guideProposed rule:
Counting unique givers reduces the impact of repeated kudos from the same small group. Weekly limits, required reasons, mutual-kudos flags, and maintainer confirmation provide additional safeguards.
The unique-giver threshold N remains open.
See Section 10, Decision 16.
7.3 Mentor of the Month
Proposed slug:
mentor-of-the-monthThis badge is separate from Community Guide. Both use the same kudos data and the same counting method (unique givers), but each is awarded independently.
Proposed process:
Open details include:
See Section 10, Decision 17.
8. Tiered Recognition
The community discussion supported graduated recognition, including a path from an initial contribution to sustained contribution, reviewing, and mentoring.
All tier structures in this section are Proposed and need maintainer confirmation.
Proposed Recognition Path
The path below is a progression map, not a mandatory gating system. Contributors may earn individual badges independently unless maintainers explicitly approve prerequisites.
first-contribution— Universal First-Timercontinuous-contributor— Continuous Contributorreview-rockstar— Review Rockstarmentor-of-the-month,community-guide, or manual community recognitionThe ladder must not imply automatic promotion or mandatory prerequisites unless maintainers explicitly choose a gated model.
Graduated Repository Badges
Poll 1 chose "both": a universal first-timer badge plus graduated repo badges.
sistent-contributor,meshery,meshery-operator,meshsync,meshery-docs,meshery-catalog,landscape,ui-ux) stay as the first level, earned at the first qualifying merged PR.impact/architecturaltoward higher levels.Other Tier Candidates
architectural-impactcommunity-guidemeshery-explorerbug-hunterfirst-release, for shipping in multiple releasesadvocate, based on the number of verified advocacy itemsDefault approach: Track 1 firsts and Track 4 credentials remain single badges unless maintainers decide otherwise.
Cloud implementation question: Tiers could use a separate slug per tier or a tier field on the badge. Maintainers must decide how to represent tiers in Cloud, how tiers are named (numbers, metals, or role titles), and whether the progression is display-only or gated.
See Section 10, Decision 19.
9. Suggestions Considered and Not Adopted
Cross-Repository Review Activity as a Separate Badge
review-rockstaralready measures reviews across allowlisted repositories.Review quality cannot be fully measured by a script. Kudos and the architectural-impact label provide additional ways to recognize high-quality contributions.
Automatic Awards from
Co-authored-byTrailersNot adopted because AI tools can add these trailers and the signal is easy to game.
Verified kudos on a PR are proposed instead.
Emoji Reactions as Awards
Not adopted because reactions are noisy and easy to manipulate.
Scraping Social Platforms
Not proposed for initial implementation because scraping is fragile and unreliable.
The proposed Advocate badge uses submitted evidence links and maintainer verification.
Slack Help Routing: Poll 2
The poll was 6–5 in favor of including qualifying Slack help in
continuous-contributor, rather than creating a dedicated badge.The current draft provisionally keeps Slack help in Track 5 pending maintainer sign-off. This does not yet implement the narrow poll plurality.
Maintainers must decide whether to adopt the poll outcome or retain the current routing.
See Section 10, Decision 24.
10. Open Decisions Before Implementation
The following decisions must be resolved before implementing the affected automation.
Decision 1 — Identity Mapping
Affects: Tracks 2, 3, and 5, and
gitops-connectedin Track 1.Which method should resolve a GitHub identity to a Layer5 user?
Options include:
Additional questions:
This blocks
gitops-connected, all Track 2 badges (includingfirst-contribution), and GitHub-derived Track 3 badges.catalog-designerdoes not need this mapping because Cloud already knows the publishing user.Decision 2 — Applications Product Status
Affects:
first-application.Should
first-applicationbe permanently archived, or is a replacement product concept planned?Decision 3 — Deployment and Session Telemetry
Affects:
first-deployment,first-interactive-terminal-session, andfirst-log-streaming-session.What HTTP endpoint or telemetry contract should Meshery Server call in Layer5 Cloud to report successful deployments and opened terminal/log sessions?
Decision 4 — Meshery Docs Slug
Affects:
meshery-docs.Should the canonical badge slug in Cloud and
badgesInfo.jsonbemeshery-docsordocs?Decision 5 — Missing and Proposed Slugs
Affects: Existing badges with missing slugs and new proposed badges.
The following existing slugs must be created if they are still missing:
landscapewriters-programhacktoberfest26The
meshery-docsslug is covered by Decision 4.The following proposed slugs must also be checked and created if absent:
architectural-impactfirst-contributioncatalog-designerfirst-releasemeshery-explorerbug-hunteradvocatecommunity-guidementor-of-the-monthDecision 6 — Writers Program Scope
Affects:
writers-program.Should publications in
meshery/meshery.io(collections/_posts/**) count alongsidelayer5io/layer5:src/collections/blog/**?Decision 7 — Review Quality Threshold
Affects:
review-rockstar.Should a review require a comment or minimum body length so empty approvals are excluded?
Decision 8 — Cleanup Labels
Affects:
code-cleanup-crew.kind/cleanupandarea/refactordo not currently exist in the allowlisted repositories.Should maintainers create one of these labels, or should the badge use
kind/chore, which exists everywhere but is broader and may include trivial changes?Decision 9 — Security Label Scope
Affects:
security-sentinel.Should
event/security-slam*PRs count toward this badge?Should the
securitylabel be created insistentandlayer5io/docs, where it is currently missing?Decision 10 — Hacktoberfest Criteria
Affects:
hacktoberfest-contributor.Should Layer5 retain the historical threshold of at least one merged PR, or adopt external campaign criteria, such as Hacktoberfest's own PR-count requirements?
Decision 11 — MeshMate Source of Truth
Affects:
meshmate.What authoritative roster should determine MeshMate appointments: a GitHub team or a maintained file?
Decision 12 — Manual Award Flow and Slack Commands
Affects: Track 4 badges and Track 5 kudos intake.
Where does the Slack
/award-badgecommand live, and how does it authenticate? It is not present inlayer5io/recognition.The same questions apply to the proposed Slack
/kudoscommand.Decision 13 — Track 3 Allowlist
Affects: Track 3 badges.
Should Track 3 evaluators use the same seven repositories as Track 2, or a different list?
For example, should
layer5io/recognitionbe included?Decision 14 — Slack Identity Mapping
Affects: Track 5.
How should a Slack user map to a Layer5 user and, where necessary, a GitHub login for PR kudos?
Who will implement this mapping?
Decision 15 — Kudos Storage
Affects:
community-guideandmentor-of-the-month.Where should Cloud store kudos events, and who will build the endpoint called by the GitHub bot and Slack command?
Decision 16 — Community Guide Threshold
Affects:
community-guide.What is the minimum number N of distinct kudos givers required during a UTC calendar month?
What should the maintainer-confirmation process look like?
The proposed model counts unique givers rather than total kudos to address the anti-gaming concern raised in the forum. The same counting is used for Mentor of the Month nominees.
Decision 17 — Mentor of the Month Voting
Affects:
mentor-of-the-month.Decision 18 — Architectural Impact Label and Rubric
Affects:
architectural-impact.impact/architectural?Decision 19 — Tiers and Graduated Recognition
Affects: Candidate tiered badges, graduated repo badges, and the proposed Contributor → Consistent Contributor → Reviewer → Mentor / Champion path.
impact/architecturalPRs, or both?Decision 20 — First Release Rules
Affects:
first-release.Decision 21 — Meshery Explorer Threshold
Affects:
meshery-explorer.Is the threshold three different repositories? Should the count cover all-time qualifying contributions or a defined window?
Decision 22 — Bug Hunter Threshold and Quality Signal
Affects:
bug-hunter.Decision 23 — Advocate Evidence
Affects:
advocate.What evidence qualifies for advocacy recognition, and is any partial automation worth exploring later?
Decision 24 — Slack Help Routing
Affects:
continuous-contributorand Track 5.The Poll 2 result was 6–5 in favor of including qualifying Slack help in
continuous-contributor.Should the poll outcome be adopted, or should Slack help remain in Track 5?
The qualifying Slack-help event and its verification method must be defined before implementation.
Decision 25 — Weekly Kudos Cap
Affects: Track 5 kudos intake.
Should the limit be two or three kudos per giver per UTC week? The forum proposed 2–3. This draft uses 3.
Decision 26 — Recognition Profile Synchronization
Affects: Layer5 Cloud and the Discussion Forum.
Should recognitions be displayed across both Layer5 Cloud and the Discussion Forum?
Maintainers must decide:
Decision 27 — First Contribution Backfill
Affects:
first-contribution.The badge uses the Track 2 CI workflow. The open questions are:
Decision 28 — Catalog Designer Qualification
Affects:
catalog-designer.Define:
1. What constitutes a verified catalog design
A verified catalog design is a design whose catalog request has status
approved.The request statuses are
pending,approved, anddenied. A request reachesapprovedin two ways:pending. A curator then approves it inchangeCatalogRequestStatus. This requires theCatalogManagementApproveCatalogRequestpermission and non-empty catalog data. The design becomesPublished.PublishCatalogPattern. The request is saved asapprovedimmediately.The badge check must run in both places. Checking only the curator path would miss auto-approved publishes.
Only
pendingrequests can be approved or denied. Approval is therefore final.The design owner is available in both paths, so no GitHub identity mapping is needed. In the approval path the owner comes from the design record (
dbPattern.UserID).Duplicate-request behavior. Before creating a request,
PublishCatalogPatternlooks up any existing request for the design and refuses to create another one, whatever its status. A design therefore has at most one catalog request in its lifetime. Re-publishing the same design cannot count twice. To count in a later month, the user must publish a different design.Open point (needs maintainer decision). Unpublishing makes the design private but leaves its
approvedrequest row unchanged. The design creator or a curator can unpublish. Maintainers should decide whether an unpublished design still counts toward the streak. To exclude unpublished designs, the check must also require the design's current visibility to bePublished.2. Whether Cloud records catalog publish events with a usable timestamp
Partly.
catalog_requeststable hascreated_atandupdated_at. It has noapproved_atcolumn.updated_atis therefore a usable approval time.created_atandupdated_atare the same.catalog_request, actionapprove). That event is owned by the approving curator, not the design owner. It is not suitable as the primary source for the owner's streak.content_idto the design'suser_id.Recommended data source:
catalog_requests.updated_atwherestatus = 'approved', joined to the design owner throughcontent_id.Verified:
UnPublishCatalogPatternsets the design's visibility toPrivate, saves the design, records an unpublish event, and dispatches a catalog-delete workflow. It does not save or delete thecatalog_requestsrow, and no server code deletes fromcatalog_requests. The request row, including itsupdated_atapproval time, therefore survives unpublish.3. UTC month-boundary behavior
created_atandupdated_ataretimestamp without time zone. The database stores no zone label.database.ymlset noTZvalue.poplibrary (v4.13.1) stamps these columns withtime.Now()in the server's local zone, and no.UTC()conversion is applied.Proposed rule: Count calendar months in UTC. The check must explicitly interpret stored values as UTC, for example with
.UTC()in Go, and must use UTC month boundaries (first day 00:00:00 UTC to last day 23:59:59 UTC).Needs maintainer confirmation: run
dateinside a production Cloud pod and confirm it reports UTC. If the production clock is not UTC, historical rows need conversion before this rule is applied.Remaining dependencies
catalog-designerslug must be created in the Meshery org by a maintainer.layer5io/recognitionunderstatic/assets/badges/catalog-designer/. It does not exist yet.Decision Impact Matrix
gitops-connected, all Track 2 badges (includingfirst-contribution), GitHub-derived Track 3 badgesfirst-contributionbackfillcatalog-designerqualification and Cloud publish eventfirst-applicationfirst-deployment, terminal-session and log-streaming badgesmeshery-docsslugmeshery-docslandscape,writers-program,hacktoberfest26, and proposed badgesmeshery.iowriters-programreview-rockstarcode-cleanup-crewevent/security-slam*security-sentinelsecuritylabels and count only qualifying labeled PRshacktoberfest-contributormeshmate/kudoscommunity-guide,mentor-of-the-monthcommunity-guidecontinuous-contributorand Track 5mentor-of-the-montharchitectural-impactfirst-releasemeshery-explorerbug-hunteradvocateImplementation Principles
To keep implementation maintainable and avoid premature scope expansion:
Summary
This proposal defines a structured recognition system spanning product events, repository activity, derived contribution metrics, manual recognition, and peer recognition.
The two new poll-driven proposals are:
first-contribution— Universal First-Timer (Track 2), recognizing a contributor's first qualifying merged PR across the allowlisted ecosystem.catalog-designer— Consistent Catalog Designer (Track 1), recognizing verified catalog publishing in three consecutive UTC calendar months.The proposal also introduces a concrete graduated recognition path:
Contributor → Consistent Contributor → Reviewer → Mentor / Champion
The path is a proposed progression map, not an automatic promotion system.
Before implementation, maintainers should resolve the blocking identity, event, slug, qualification, and integration decisions documented above. Remaining thresholds and policy choices should be explicitly approved or retained as provisional rather than silently treated as settled.
Maanvi212006 commentedon Oct 6, 2026
Reviewed the proposal and these are few things and open questions that need to be resolved before moving forward.
Track 1:
design-pioneerfirst-designon a new design, a clone and an import (meshery_patterns.go), and skips anonymous users. The main save handler has the same award block twice (lines ~475 and ~509).first-designand mark the badge as already implemented. Remove the duplicate block (harmless, since awards are idempotent).first-applicationfirst-shareusers.goshare handler) and the access grant (resources.go:209). New designs arePublicby default, so visibility alone must not trigger it.first-deploymentfirst-interactive-terminal-session,first-log-streaming-sessionfirst-deployment. Define the trigger as "session opened". Cross-repo work.need-for-speedStoreResultsstores a result without checking whether the run passed. The source is results, not profiles.AddMesheryResultsucceeds inStoreResults. Define the trigger as "first result published to Cloud". IgnoreUpdateResultsWithMetrics.first-collaboratorbring-a-buddyappendedbranch inAcceptInvitation. Awardinvitation.Owner. Exclude open-org invites and self-invites.gitops-connectedinstallationbranch for actioncreated. Ignoredeletedandsuspend. Reuse the shared GitHub-to-Layer5 user mapping.meshmap-snapshotmeshmap-snapshot(created 2023) andkanvas-snapshot(created 2025) exist in the live API with identical descriptions. The upload endpoint doesn't check for a PR.kanvas-snapshot(the one the badge site lists) and retire the other. Award in the success branch ofPostGithubArtifact, which already knows the Layer5 user. Accept any successful snapshot upload.Track 2:
sistent-contributorpackages/**doesn't exist.system/**is docs only. Tests,src/assets/**and lockfile/config files (package.json,tsconfig.json,Makefile) would qualify bot and bump PRs.src/**andexamples/**. Exclude tests,src/assets/**,system/**. Drop config and lockfiles.mesherymain.godoesn't exist.models/**is about 26,000 generated JSON files and is also undermeshery-catalog.install/**is Helm/YAML.ui/**includes docs, tests and scripts.go.modis touched by Dependabot.server/**,mesheryctl/**,ui/**,provider-ui/**. Exclude tests,ui/docs,ui/public,ui/scripts. Removemodels/**,install/**,main.go,go.mod.meshery-operatormain.godoesn't exist (it iscmd/main.go).bundle/**,config/**andzz_generated.*are generated.go.modandgo.sumare mostly Dependabot.controllers/**,api/**,pkg/**,cmd/**. Exclude generated files,bundle/**,config/**and tests. Dropgo.mod,go.sum.meshsyncplugins/**andcache/**don't exist. Themeshsync/folder is missing from the rule.go.modandgo.sumare mostly Dependabot.internal/**,pkg/**,meshsync/**. Exclude tests andintegration-tests/**. Dropgo.mod,go.sum.meshery-docsmeshery-docs, handbook:docs).pages/**doesn't exist.meshery/docsis a whole Hugo site, and much of it is synced byl5ioor is theme, data or meeting notes..mdunderdocs/content/**(meshery) andcontent/**(layer5io/docs). Excludecatalog,integrations,data,meetings,static,layouts,assets,archive,proposals.meshery-docsordocs?meshery-catalogcollections/catalog/**doesn't exist (real:collections/_catalog/).catalog/**and_catalogare mostly bot-synced byl5io.models/**is also undermeshery. 21 files undermodels/have a bad extension that*.jsonmisses.catalog/**andcollections/_catalog/**in meshery.io, plus any file undermodels/in meshery. Keepmodels/**only here.landscapesrc/collections/landscape/**is correct (8 files) but narrow; the badge description says "layer5.io website".ui-uxarea/uiandarea/uxdon't exist in meshery. Since 2026-07-01 onlycomponent/uiis used (168 of 549 PRs in meshery; 0 in sistent and layer5). layer5src/**includes blog content. Flyer and design work can't be detected from a PR.component/ui+ui/**orprovider-ui/**. sistent:src/**,system/**, no label. layer5:src/components,src/sections,src/reusecore,theme,templates,pages, no label. Exclude tests, lockfiles,src/collections,src/assets. Flyers: manual award.Track 3:
writers-program.md/.mdxpost undersrc/collections/blog/**. Award at 2 by human authors (no bots, nol5io). Drop "project docs" until it has a path list.meshery.ioposts (collections/_posts) count?review-rockstarcode-cleanup-crewchoreis broad, so 5 PRs may be too easy.kind/chorecount?security-sentinelsecuritylabel exists only inmesheryandlayer5(62 merged PRs, all inmeshery). Advisories can't be checked automatically (needs admin rights). One mislabelled PR earns the badge.securityPR by a human author. Drop "resolving advisories".event/security-slam*PRs count? Add the label tosistentandmeshsync?continuous-contributormeshery/meshery, 7 of about 150 active people hit Jul, Aug and Sep 2026, so the rule is realistic.longevity-legendmesheryclone, 61 of 396 recent authors qualify, but only 16 have a 24+ month span.Track 4:
communityrecognition. "Welcoming, encouraging, supporting" is not measurable.recognition, and a maintainer awards it with the existing flow.meshmatecncf-ambassadordocker-captaincncf-ambassador, and the Docker page has no handles, so it can't be matched automatically.cncf-ambassador.hacktoberfest-contributorhacktoberfest-24-contributor,hacktoberfest25), and none exists for 2026. "Participation" is undefined, and nothing inrecognitionautomates it.hacktoberfest26). Award at 1 merged PR by a human author in allowlisted Layer5 repos during Oct 1-31 UTC, run by the monthly cron at month end. Skip users who already have the badge.PARTH-TUSSLE commentedon Oct 6, 2026
Thanks Maanvi, this review is really helpful. I agree that the proposal needs to distinguish between existing Cloud award paths, GitHub-derived automation, cross-repo dependencies, and manual-only badges rather than treating all badges as the same automation problem. I'll revise the proposal into a badge-by-badge decision matrix, incorporate the concrete repository/path/threshold definitions you've suggested, and separate the remaining open questions that need community/product decisions before implementation.
PARTH-TUSSLE commentedon Oct 6, 2026
@Maanvi212006 , I've update the proposal aligning with your review kindly take a look
Maanvi212006 commentedon Oct 6, 2026
yes, just few more points:
hacktoberfest)userId, and nothing defines how one maps to the other. The above thread has not settled this: PR #122 uses commit email, and a GitHub ID lookup is only a proposed alternative. The mapping is listed as an open decision only forgitops-connected, but it blocks every CI badge.review-rockstarsecurity-sentinelevent/security-slam*now counts without discussion.securitylabel, or restore this as an open question.event/security-slam*PRs count?ui-uxui-uxentry to Track 4.meshmate,hacktoberfest-contributorMaanvi212006 commentedon Oct 6, 2026
Updated the proposal!