Why labels matter
GSSoC scores PRs based entirely on the labels applied before merge. Labels are not cosmetic; they are the input to the scoring formula. A mislabeled PR either over-rewards a trivial change or under-rewards a genuinely hard one. Both outcomes erode trust in the leaderboard.
Project admins and mentors are the last line of defense. Before adding gssoc:approved, ask: "Does this label set accurately describe the work the contributor actually did?"
The scoring engine always picks the worst-case label. If you add both level:beginner and level:advanced, the engine scores 20 pts (beginner), not 55. This is intentional; it protects against accidental or deliberate inflation.
Difficulty levels
One difficulty label per PR. Apply the level that matches the cognitive demand of the change, not the time it took to write, and not how hard the problem was to discover.
Self-contained change in a single file or tightly scoped area. Requires no understanding of system architecture or data flow between components.
Fits this level
- +Fix a typo or grammatical error in docs or comments
- +Add or update a README section
- +Correct a variable name in an isolated helper function
- +Add a missing alt attribute to an image tag
- +Fix a broken hyperlink
Not this level
- ×A bug fix that touches multiple modules
- ×Adding a new feature, even a small one
- ×Any change that requires reading multiple files to understand
Change spans multiple files or requires understanding of how at least two parts of the system interact. The contributor needed to read and reason about existing logic, not just pattern-match.
Fits this level
- +Fix a bug that requires tracing a call stack across files
- +Add a new UI component with its styles and unit test
- +Refactor a function to improve readability without changing behavior
- +Add input validation with error messaging in a form
- +Migrate one deprecated API call to a new one
Not this level
- ×A change limited to one file that does not need cross-file reasoning
- ×A security fix, performance improvement, or architectural change
Non-trivial contribution that touches core logic, involves architectural decisions, or requires deep understanding of the codebase. The reviewer had to carefully think through correctness.
Fits this level
- +Implement a new feature with multiple interacting parts
- +Performance improvement with measurable benchmarks
- +Refactor a module to use a better pattern (e.g. extracting a reusable hook)
- +Add comprehensive test suite for a complex module
- +Integrate a third-party library with proper error handling and fallbacks
Not this level
- ×Anything touching auth, payments, database schema, or security (that is level:critical)
- ×A routine bug fix, even if it took effort to find
Touches a high-stakes area where a mistake has serious consequences: security, authentication, database migrations, payment flows, or core infrastructure. Use sparingly and intentionally.
Fits this level
- +Fix a security vulnerability (XSS, CSRF, SQL injection, exposed secrets)
- +Database schema migration with backward-compatibility handling
- +Authentication or session management change
- +Rate-limiting or abuse-prevention logic
- +CI/CD pipeline change that affects all deployments
Not this level
- ×A large but routine feature; large does not mean critical
- ×Any change where a mistake would not cause data loss, security breach, or service outage
Quality multipliers
Quality labels multiply the difficulty points. They are optional; absence defaults to 1.0×. Use them to reward contributors who went the extra mile, not as encouragement for every merged PR.
Well-structured, readable code. Variable names are clear. No dead code, no console.log leftovers. Follows the project's existing style. The reviewer did not need to leave nitpick comments.
Checklist
- ✓No commented-out dead code
- ✓Variable and function names are descriptive
- ✓Consistent indentation and formatting with the project
- ✓No unnecessary whitespace changes mixed in
- ✓The reviewer left only approval or minor suggestion comments
Goes meaningfully beyond what was asked. The contributor showed initiative, thought about edge cases, added tests without being asked, or left the codebase noticeably better than they found it.
Checklist
- ✓Adds tests that weren't in the original issue
- ✓Documents a non-obvious decision inline
- ✓Handles an edge case the issue didn't mention
- ✓Reduces complexity or technical debt alongside the fix
- ✓The reviewer learned something from this PR
Note: quality:exceptional must be justified in a review comment. Applying it without a written reason will cause it to be ignored during scoring.
Type bonuses
Type labels add flat bonus points on top of the difficulty score. Multiple types are cumulative. Only apply them when the primary purpose of the PR matches, not as a secondary label for something the PR briefly touches.
Fixes incorrect behavior that was already reported or demonstrably wrong.
Adds new functionality not previously present.
Improves or adds documentation, README, or inline comments.
Adds or improves tests: unit, integration, or e2e.
Restructures existing code without changing behavior.
Visual or UI/UX improvements.
Improves screen reader support, keyboard nav, contrast, or ARIA.
Measurably reduces load time, bundle size, or memory usage.
CI/CD, Dockerfile, GitHub Actions, or deployment configuration.
Addresses a security vulnerability or hardens a surface area.
Labels that block scoring
Any PR carrying one of these labels is excluded from scoring entirely, even if it also has gssoc:approved. The blocking label wins.
The PR does not meet the minimum bar for merging (off-topic, duplicate, or low effort) but is not malicious.
Fabricated contribution with no real value: empty files, lorem ipsum, automated generation without human intent.
AI-generated content pasted without understanding or editing. The contributor cannot explain the change. This is different from AI-assisted work where the human understands every line.
On AI-assisted work: Using AI tools to help write code is not automatically gssoc:ai-slop. The test is whether the contributor can explain every line and made genuine decisions. If they understand the change, it is valid. If they pasted output and cannot explain it, label it.
How scores are calculated
// capped at 175 pts per PR
approved base is always 50
Every scored PR starts with 50 points, regardless of difficulty. This base rewards the effort of going through the full contribution cycle.
difficulty × quality: lowest label wins
If multiple difficulty labels exist, the lowest is used. If multiple quality labels exist, the lowest multiplier is used. This cannot be gamed by stacking labels.
type bonuses are cumulative
Multiple type labels each add their bonus. A PR that is both a bug fix and adds tests earns both +10 and +10.
175 pt hard ceiling
No single PR can score more than 175 pts, regardless of labels. This prevents a single exceptional contribution from dominating the leaderboard.
first PR bonus: +25 pts
The first time a contributor gets any PR merged in the program, they earn a one-time 25 pt bonus. This recognises the barrier of making a first open source contribution.
Frequently asked questions
Can I apply multiple difficulty labels?
Yes, but the scoring engine always takes the lowest. Two labels never combine to give more points; they only protect against inflating easy work.
Can a PR have both quality:clean and quality:exceptional?
No, use only one. quality:exceptional already implies clean code. If you apply both, the scoring engine uses the lower multiplier (1.2x), not the higher.
How many type: labels can a PR have?
As many as honestly apply. Type bonuses are cumulative. However, labeling a plain bug fix as type:security and type:performance when it is neither will be corrected during admin review.
When should I withhold gssoc:approved even if the PR is merged?
If the PR was merged for project reasons but does not meet GSSoC quality standards, withhold gssoc:approved. Merging and scoring are separate decisions.
What is the difference between gssoc:invalid and gssoc:spam?
invalid is for low-quality but not malicious PRs, a well-meaning contributor who missed the mark. spam/ai-slop is for patterns that show no genuine effort or intent to learn.
Does quality:exceptional require a review comment?
Yes. The scoring pipeline checks for a substantive review comment (>30 characters) on PRs labeled quality:exceptional. Without one, the multiplier falls back to 1.0×.