> For the complete documentation index, see [llms.txt](https://docs.gooddollar.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gooddollar.org/for-developers/contributing/open-source-contributors/human-reviewer-role.md). # Human Reviewer Role Reviewers require approval before picking up bounties. See Getting Reviewer Access below. As a Reviewer, you validate the Contributor's corrected version of the AI-generated PR before it moves to QA. You are not reviewing the AI's original code — you are reviewing the Contributor's fixes. Getting Reviewer Access. > Contributor and Reviewer must be different people on the same bounty. **The Reviewer's job:** * Check out the Contributor's branch locally and test it * Validate that the fixes are correct and complete * Check for anything still missed — logic, security, edge cases, consistency * Submit your review: **Approve**, **Comment**, or **Request Changes** * After approving, request a maintainer sign-off from the `goodbuilders-maintainers` GitHub team * Re-review within **48 hours** when the Contributor pushes changes and tags you > See the image below for where to find the GitHub Teams. **Green** is for contributors requesting a code review, and **purple** is for reviewers requesting a maintainer sign-off.
### Getting Reviewer Access Reach out in the [`goodbounties`](https://t.me/gooddollarbounties/4115) Telegram channel or tag a maintainer on GitHub. Permissions are granted manually within 24–48 hours. **What this unlocks:** * Assignment as a Reviewer on incoming bounty PRs * Eligibility for review payouts * After **3 accepted reviews**, you become a Senior Contributor and Reviewer — you get a vote on who joins the contributor pool, what gets built next, and can propose your own ideas You can use this template to request access: ``` Hi everyone! I'd like to join the Contributor + Reviewer pool. Name: Previous open-source contributions: Availability (hours/week): ``` Your job is not to rewrite the solution. It is to validate it, catch what the AI missed, fix errors noted and ensure it is production-ready. > **Note:** Once approved for Human Review, you join the reviewer pool and are assigned PRs. Assignments can be delegated to other approved reviewers ### What Makes a Review Accepted A review is accepted when it is substantive — you have actually tested the code or caught something meaningful. > 🚫 **Not acceptable:** "LGTM" with no substance. Purely stylistic comments. Generic feedback not tied to the actual changes. Any of these will result in payout rejection. **✅ Good review comment:** \`File: StakeModal.tsx — line 147 Issue: The distribute() function does not check whether `amount` exceeds the pool balance before transferring. If it does, the transaction will revert on-chain but state will already be updated on line 143, leaving the contract in an inconsistent state. Fix: Add a balance check before the state update: require(poolBalance >= amount, "Insufficient pool balance"); Or move the state update after the transfer so it only commits if the transfer succeeds.\` **❌ Weak comment (not acceptable):** `"This function looks a bit risky, might want to double check the logic here."` *** ### Timelines * First review response: within 48 **hours** of assignment * Re-review after changes: within **48 hours** of being tagged * If your assigned PR has been waiting more than 2 days with no response, ping in [GoodBounties Telegram](https://t.me/gooddollarbounties) ### Review Process & Ground Rules **As a reviewer, your job is to bring judgment the AI can't — context, common sense, real-world testing, fixes and familiarity with how the codebase is actually used.** **Ground rules:** * Do not resolve comments left by the maintainer or AI — reply with what you changed, and let them resolve it * Share progress at least every 3 days; draft PRs are fine for visibility * If no update or response after 3 days, the issue may be unassigned * You may use your own AI tools to assist your review, but the human review judgment must be yours *** ### PR Review Checklist When reviewing the AI-generated PR, check for: * [ ] Does the solution actually solve what the issue describes? * [ ] Are there edge cases or error states not handled? * [ ] Does the code follow existing patterns and conventions in the repo? * [ ] Are there any TypeScript typing issues or linting failures? * [ ] For UI changes — does it work on both desktop and mobile? * [ ] Is anything over-engineered or unnecessarily complex? * [ ] Are there fixes that need to happen to make code acceptable? * [ ] Are existing helpers/components reused where they could be? *** ### Tips for a Good Review * Read the issue carefully before looking at the code — understand the intent first * Run the changes locally where possible; don't just read, test * Check edge cases the AI may have missed (error states, empty inputs, mobile views) * Look for consistency with the rest of the codebase — patterns, naming, component reuse * Ask questions early if the scope or approach isn't clear — on the issue or in the Builders Telegram
Getting Review Permissions on GitHub Once you have 2 merged PRs, reach out on the telegram channel or tag a maintainer on GitHub. Permissions are granted manually — it usually happens within 24–48 hours. **What This Unlocks** After **3 accepted reviews**, you become a **Senior Contributor (Level 3)**. You get a vote on who joins the contributor pool and what gets built next. →[ Revisit the full growth path](https://app.gitbook.com/o/-LdiTCmTgO528x-BXAcj/s/-LfsEjhezedCgGFXCkms/~/edit/~/changes/303/for-developers/contributing/open-source-contributors/contributor-growth-path)