> 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

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.

<figure><img src="/files/aA3xJc72LfqlbyvgPhHP" alt=""><figcaption></figcaption></figure>

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

<details>

<summary><strong>Getting Review Permissions on GitHub</strong></summary>

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)

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.gooddollar.org/for-developers/contributing/open-source-contributors/human-reviewer-role.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
