Design Discussion: Contributor Recognition Architecture

[Tanishq-mellu]

Hi, I’ve been reviewing the OWASP Nest codebase to better understand the Contributor recognition program milestone.

I noticed that contributions_count and contribution_data are already stored in the GitHubUser model, which seems like a strong foundation for building a recognition system .

I’m considering implementing the recognition layer as a tier-based system (e.g. , Bronze/Silver/Gold) built on top of these existing metrics.
Before moving further, I’d like to clarify the intended direction:
Should recognition be based purely on total contribution count ?
Or should it incorporate weighted metrics such as PRs, issues, reviews, leadership roles, etc.?
I’d appreciate guidance to ensure alignment before proceeding with the architectural design.

[zenowinged]

hi @Tanishq-mellu i'd like to work with you on this issue if it's cool with you. Could you explain the issue to me once so i can understand it better?

[Tanishq-mellu]

Hi @zenowinged,
Yes, absolutely - happy to collaborate

The idea here is to design a Contributor recognition system on top of the existing contributions_count and contribution_data fields in the GitHubUser model . The goal is to introduce a tier- based recognition layer (e.g. , Bronze/Silver/Gold) based on contribution metrics .
Right now, I’m trying to clarify whether the scoring should be based purely on total contributions or include weighted metrics like PRs , issues, reviews, and leadership roles .
Happy to discuss and shape the design together .

[zenowinged]

@Tanishq-mellu,
i honestly think that the weighted metric system would be much better...relying purely on total counts might lead to stuff like opening tons of minor issues just to rank up. if we go with the weighted metrics, we could decide something like 5 points for each PR raised (or merged, whichever seems fair), 10 points for an issue, and so on...we can discuss the details accordingly. lmk your thoughts on this.

[Tanishq-mellu]

I agree - a weighted system makes more sense and would help prevent misuse like opening minor issues just to increase count.
Maybe we can define clear categories first (e.g. , merged PRs , reviews , meaningful issues , leadership roles) and then decide fair weights based on impact rather than just activity .
We can start with a simple model and refine it after reviewing actual contribution patterns .
Happy to iterate on this together

[zenowinged]

sounds perfect. let me know once you've come up with a design or if you'd like any input, and then i can code it out. or the other way around, whichever works.

[Tanishq-mellu]

That sounds great
I’ll draft a simple design outline covering the scoring logic , tier structure , and data flow so we have something concrete to review . Once that’s in place , we can refine it together and then split the implementation accordingly .
I’ll share a draft here soon .

[Tanishq-mellu]

Thanks! I’ve been thinking of keeping the first version simple and practical.

The idea would be:
1] Use existing contribution data (merged PRs, reviews, issues, leadership roles).
2] Assign basic weights to each category (for example, PRs = 5, reviews = 3, issues = 2, leadership = bonus points).
3] Calculate a total score.
4] Map that score to tiers like Bronze, Silver, Gold, etc.
5] Store the calculated score and tier so it doesn’t have to be recomputed every time.

We can start simple and later refine the weights based on real contribution patterns.
Let me know if this direction makes sense, and we can adjust the scoring logic together.

[zenowinged]

this direction makes perfect sense. let's lock in the exact math for V1 so we can actually start building this out and mapping it to the database.

let's start with these numbers:

The Weights:

Merged PRs = 10 points (highest impact, keeps focus on shipping code)

Code Reviews = 5 points (encourages helping others)

Issues = 2 points (keeps spam low, but still rewards bug finding)

Leadership = +50 point flat bonus (for maintainers/org members)

The Tiers:

Bronze = 10 points (easy entry; just 1 merged PR or 5 good issues gets you on the board)

Silver = 50 points (shows consistent contribution)

Gold = 100+ points (dedicated contributors)

if this baseline looks good to you, let's consider the logic finalized for now. i can start looking into the GitHubUser model to see how we'll handle step 5 (storing and caching the score so it doesn't recompute). sound good?

[Tanishq-mellu]

Thanks , this looks like a solid baseline for V1
The weights and tier thresholds make sense and starting simple will help us iterate later if needed .
I’ll start working on a basic scoring logic prototype based on this structure so we can map it cleanly to the models . Once that ’s in place , we can look at how to store and cache the calculated score in the database .

Let me know if you’d prefer the logic to live in a separate service / module or directly near the GitHubUser model.

[Tanishq-mellu]

I’ve started prototyping the scoring logic locally based on the weights you suggested (PRs , reviews , issues , leadership bonus) so we can easily adjust the numbers if needed .
Once we finalize the scoring math, the next step could be mapping this to the GitHubUser contribution data and deciding where to store / cache the computed score .
Let me know if you'd like the logic implemented directly inside the GitHub app or as a separate module .

[zenowinged]

nice, being able to easily tweak the math locally is perfect.
regarding the logic, building it as a separate module would be much cleaner, and it'll keep the scoring engine decoupled and easier to test or update later without cluttering the core app. For storage, caching the final computed score directly on the GitHubUser model makes total sense.

[arkid15r]

These are related to what you're discussing here:

• Improve OWASP Nest member ranking algorithm with calculated scores #4200
• Track and capture OWASP contributions across platforms beyond GitHub #4208

[Tanishq-mellu]

Thanks for linking these issues . They seem closely related to the contributor recognition and ranking logic we’re discussing .
I’ll review them to ensure the design aligns with the existing direction of the project .