GUIDANCE & SCORING
Understand how Repo Rescue evaluates open-source issues using the V2.3.1 Evidence Accumulation Engine, awards RR Points, and measures contributor engineering effort.
HOW IS AN ISSUE GRADED?
Every scored issue receives an RR Difficulty score on a deterministic 0.0 to 10.0 scale. Under Repo Rescue V2.3.1, difficulty estimates contributor engineering effort suggested by evidence available in the issue itself rather than isolated keywords, repository popularity, or maintainer reputation.
The 5 Weighted Factors (V2.3.1 Standard)
Algorithmic depth, system execution complexity, memory structures, and architectural logic suggested by the issue text.
The expected breadth of the change, inferred from the issue evidence — such as localized changes, multiple files/modules, packages, or architectural boundaries.
Specialized technical background inferred from issue evidence (e.g. compilers, distributed consensus, MVCC, async streams, RLS policies).
Inferred testing and validation requirement suggested by the issue description, labels, and system area.
How much additional triage and investigation the issue appears to require based on the available description and evidence.
Consider a localized syntax fix issue (e.g. Issue #1 "unexxpected syntax error"):
THE 0.0 – 10.0 DIFFICULTY RANGE GUIDE
The table below serves as general guidance to help you understand how engineering tasks map across the difficulty spectrum under V2.3.1. These bands describe typical issue types, not guaranteed score ranges. The final score is determined strictly by accumulated issue evidence.
Trivial documentation fixes, typos, README corrections, broken links, i18n translation strings, code formatting.
Very small localized changes, function call syntax fixes, localized syntax corrections, minor style tweaks.
Simple localized bugs, small UI component padding fixes, null-check validations, simple date/string helper updates.
Standard bug fixes and feature work requiring meaningful code changes, route validation, or API response field updates.
Multi-file bug fixes, moderate refactoring across components, non-trivial unit/e2e testing setup.
Substantial subsystem work, security/RLS access policy enforcement, multi-file auth token invalidation, parser edge-case crash handling.
Significant architectural refactoring, cross-package event bus changes, complex subsystem interactions.
Highly complex issues involving worker thread pool concurrency, mutex race windows, database schema migrations, or compiler AST passes.
Very high-complexity engineering: distributed systems consensus, Raft split-brain recovery, storage engine compaction, MVCC serializable isolation.
Exceptional core-system engineering requiring major architectural rewrites or fundamental low-level engine overhauls.
IMPORTANT SCORING PRINCIPLES
Repo Rescue evaluates the intent and execution context of an issue as a whole, preventing keyword collisions, PR diff dependency, and artificial inflation.
Words are interpreted within their technical context. The engine prioritizes explicit action markers over isolated domain words:
Stuffing an issue body with advanced technical terms does not artificially increase its difficulty score:
If an issue title specifies a typo/README fix, inserting body text containing compiler, AST, deadlock, concurrency, or distributed consensus without code blocks or stack traces remains locked to doc-tier difficulty (0.4 – 0.7).
WHAT DOES NOT AFFECT RR DIFFICULTY
RR Difficulty measures implementation effort suggested by issue evidence BEFORE implementation. The following factors explicitly do NOT determine or inflate difficulty:
A typo fix in a 75k star repository scores 0.5, identical to a 100 star repository.
High traffic or popular status does not inflate engineering difficulty.
The PR diff, source files, or AST changes do NOT determine issue difficulty.
Framework prestige does not turn a 2-line UI tweak into a hard task.
Technical words (e.g. database, schema, security) do not inflate score without evidence.
HOW DO I EARN RR POINTS?
Repo Rescue enforces a strict distinction between RR Difficulty (issue complexity evaluation) and RR Points (awarded reputation).
The difficulty score (0.0 – 10.0) estimated deterministically from evidence contained in the GitHub issue itself before implementation.
RR Difficulty × 10, posted to the immutable Points Ledger ONLY when a maintainer merges your PR and audit verification succeeds.
Points are awarded strictly after Repo Rescue verifies a qualifying maintainer-merged contribution.
Explanatory Implementation Examples
Fix spelling in intro paragraph or broken link in README.md
Fix syntax error in print function call or add null check
Validate email format in signup route or update API endpoint
Fix RLS policy bypass or worker thread mutex race condition
Raft consensus split-brain recovery or LSM-tree engine redesign
WHAT COUNTS AS A VERIFIED CONTRIBUTION?
To protect competitive integrity, Repo Rescue enforces strict automated audit rules before posting transactions to the authoritative Points Ledger.
- ✓Qualifying PR is merged (merged == true)
- ✓Correct repository ID match
- ✓Correct issue association in PR title/body (#number)
- ✓Contributor identity verified via GitHub OAuth
- ✓Maintainer-authorized merge (prevents self-merge farming)
- ✓Repo Rescue HMAC signature verification succeeds
- ×Opening an unmerged PR
- ×Commenting on an issue
- ×Claiming an issue in comments
- ×Filing/Opening a new issue
- ×Starting local work on an issue
- ×A closed but unmerged PR
YOUR REPO RESCUE REPUTATION
Your public profile accumulates verified contributions, language expertise, and difficulty achievements into a permanent engineer profile.
READY TO RESCUE SOMETHING?
Browse open-source issues and find your next challenge.