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 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

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