Repository navigation
[Applications Open]: Join the GoodBounties reviewer group #285
Description
We're growing our group of reviewers and are looking for 3 more people to join us. You'd help review pull requests across our participating repositories as they become ready.
- Applications: open on a rolling basis, so apply whenever you're ready. The sooner the better
How assignments work
- Reviews are assigned as they're needed. Assignment is partly automated, and the team checks every assignment.
- We aim to share reviews fairly across the group. We look at past reviews and at how complex each review is likely to be.
- Some review requests also include QA work. The payment structure and requirements explains how the two roles and their payments are separated.
What you'll do as a reviewer
- Check the work against the issue and its acceptance criteria
- Check out the changes and test them, including error and edge cases
- Look at correctness, security, code quality, and whether existing components are reused
- For UI changes, try the real experience on desktop and mobile, and compare it with any shared design references
- Leave clear, specific feedback with evidence, then confirm fixes when you re-review
- Summarise the outcome and ask a maintainer to sign off when it's ready
You'll get Triage access to the repositories. Please leave your reviews through GitHub's built-in "Add review" flow.
AI tools can help you, but the judgment and the checking are yours. A careful review that finds no problems is still a valuable review.
The Human Reviewer Role has more detail.
Before each assignment
When we set up a review, we look at the repository, the type and risk of the change, your experience, and your availability. A few things to know:
- Tell us if you have a conflict of interest or can't take an assignment.
- The team will confirm that you're eligible and agree on the scope before you start.
- The same person shouldn't build, review, and QA one piece of work. Each role goes to a different person unless we say otherwise.
Rewards
For Rare and higher bounties, a separate code reviewer currently receives 30% of the total bounty. You'll know the exact reward and scope before you accept an assignment.
For details, see the payment structure and requirements and the Contributor Growth Path.
How to apply
Leave a comment below that includes:
- Your GitHub profile, plus the repositories or technologies you know best
- Links to 2–3 reviews you've done, in GoodDollar or anywhere else. Tell us about one thing you found or a call you made, and what happened next.
- Your testing, security, or UX experience, with examples if you have them
- Your availability which days of the week, maximum of hours available, your timezone, and any kinds of work you wouldn't feel comfortable reviewing on your own.
Please use work you've already done as your examples. Don't start reviewing a live bounty as part of your application. Wait until the team confirms an assignment with you.
What happens next
We review applications on a rolling basis and will contact the people we'd like to add to the rotation. Your first assignment will come with its scope and reward set out clearly.
Questions? Ask here or in the GoodBounties Telegram. We'd love to hear from you.
Activity
Ryjen1 commentedon Nov 6, 2026
Application: Code Reviewer Role
Profile: @Ryjen1
GoodDollar contributor with merged PRs in GoodSDKs and GoodWidget, plus 175+ merged PRs in open-source projects outside GoodDollar.
GoodSDKs (merged: #25 whitelisted-root claim fix, #35 GoodReserve SDK), GoodWidget (merged: #53 GoodReserve widget), and GoodWallet (wallet login + transaction flows).
Outside GoodDollar I contribute to Tracer-Cloud's OpenSRE (Python AI/SRE tool). Five merged PRs (#764, #851, #1010, #1084, #1157) covering config fixes, unit tests, and refactoring. I check out and run the code rather than rely on the diff alone.
My review-side evidence is QA and verification work rather than formal PR approvals. Two examples:
Independent QA of reserve swapping with delegation-marked wallets — GoodWeb3-Mono #275. I tested GoodWeb3-Mono PR #274 and GoodProtocolUI PR #645 locally against the expected delegation-marker, rate and trade-limit behaviour. My report was accepted. One finding became its own tracked issue: in Microbridge, the TokenInput Max button filled the input with the balance but the output stayed at 0. I traced it to
setMaxupdating local state without propagatingonChange, and filed it with the root cause as #279 — noting it was pre-existing, not introduced by the PR under test.A judgment call from my merged work — OpenSRE #764: the shipped config defaults pointed at placeholder NVIDIA NIM model IDs that would not have worked in real use. I replaced them with verified defaults so the provider works out of the box. Merged.
Testing, security and UX experience
I reproduce issues locally and run full test suites on every assignment. On OpenSRE I added unit tests for existing rendering helpers (#851). Security-sensitive work includes account/session isolation across wallets, making sure failed or cancelled transactions never report as success, and proper dApp session teardown on logout. Also did UX work on GoodWidget (including the merged GoodReserve widget #53) against design references.
Availability and limits
Available most days, up to 10 hours per week, and can usually start a review within 24 hours of assignment. I won't review a workstream I built or QA'd, and on specialist smart-contract security I'd ask for a specialist rather than approve alone.
robertocarlous commentedon Nov 6, 2026
Hi @L03TJ3
1. GitHub profile and relevant repositories
GitHub: https://github.com/robertocarlous
Relevant repository: https://github.com/robertocarlous/GoodWidget
I am a full-stack developer with experience working across JavaScript, TypeScript, React, Node.js, Solidity, smart contract integrations, REST APIs, and Web3 applications.
I have contributed to several collaborative repositories and have at least 158 merged pull requests visible in my GitHub history. These contributions cover smart contract development, backend functionality, deployment tooling, testing, documentation, and frontend/backend integration.
Some of the repositories represented in my contribution history include:
I have also worked directly with the GoodDollar ecosystem through my GoodWidget fork.
2. Previous code review and collaborative development experience
My experience includes working with pull requests, assessing implementation changes, collaborating with contributors, and maintaining project code.
One example is my contribution to the NeuroWealth Frontend repository, where I approved and merged a contributor's pull request addressing an orphaned service-layer directory.
Reference: Neurowealth/NeuroWealth-Frontend#727
I have also contributed to projects involving smart contracts, backend pipelines, deployment verification, and automated testing. My merged contributions include:
These experiences have helped me become comfortable examining changes in the context of an existing codebase rather than evaluating individual code snippets in isolation.
3. Testing, security, and user experience
I can review contributions from several perspectives:
Code quality: Checking readability, maintainability, consistency with existing project conventions, and unnecessary duplication.
Functionality: Comparing submitted changes against the original issue requirements and acceptance criteria, including identifying missing functionality and edge cases.
Testing: Running applications locally, checking test results, examining failure scenarios, and verifying that changes do not break existing functionality.
Security: Identifying common application-level risks, particularly around API authentication, authorization, input validation, data handling, and smart contract interactions.
User experience: Checking interface behaviour, responsive layouts, component consistency, and usability across different screen sizes.
My development experience with React, Node.js, Solidity, and Web3 applications gives me a useful foundation for reviewing both application-level and blockchain-related contributions.
4. Availability
I can commit approximately 20 hours per week, with availability spread across weekdays and weekends.
Timezone: West Africa Time (WAT, UTC+1).
I can accommodate asynchronous reviews and coordinate with contributors across different time zones.
5. Areas I would not independently review
I am comfortable reviewing general frontend, backend, and Web3 application changes. However, I would not independently provide final security approval for highly specialised cryptographic implementations, complex smart contract audits, or protocol-level security changes without involving an appropriate specialist.
Where a contribution falls outside my expertise, I would communicate the limitation rather than approve changes I cannot adequately assess.
6. Why I am interested in reviewing GoodBounties
I am interested in contributing to GoodDollar because I have already explored its ecosystem and worked with the GoodWidget codebase.
I understand that reviewing a bounty contribution involves more than checking whether the code runs. It requires understanding the original issue, checking whether the implementation meets the requirements, testing relevant scenarios, and providing clear feedback that helps contributors improve their work.
I would bring a practical development perspective, attention to implementation details, and a willingness to engage constructively with contributors. I am also interested in helping maintain the quality and reliability of projects within the GoodDollar ecosystem.
L03TJ3 commentedon Nov 6, 2026
@Khemmie-Ray please read the issue and share the requested application details
edehvictor commentedon Nov 6, 2026
Application: GoodBounties reviewer group
Profile: @edehvictor. I would like to review GoodDollar work that I did not build or QA. My strongest areas are React/TypeScript interfaces, wallet and SDK integrations, transaction-state correctness, and evidence-backed testing.
Relevant GoodDollar work
Reviews I have given
How I assess work
Availability and boundaries: Monday to Saturday, up to estimately 20 hours per week, across different time zones. I will disclose conflicts and will not review or QA a bounty I helped build unless the team explicitly agrees otherwise. I would need specialist support for complex smart contracts or security-sensitive changes. On an assigned review, I will test against the issue criteria, leave specific feedback in GitHub's review flow, re-check fixes, and give the maintainer a clear outcome.
Khemmie-Ray commentedon Nov 6, 2026
Hi @L03TJ3 , sorry about that.
GitHub: @Khemmie-Ray
What I know best
TypeScript, React, and Next.js on the frontend, Solidity, hardhat and Foundry for contracts, and wagmi, viem and ethers.js in between.
Reviews I've done
I did the QA sweep ([QA] Streaming widget — full exploratory sweep (ties to PR #256) #263) for the streaming widget's light theme update. I ran every Storybook fixture in light and dark themes, at 390px and 1280px, and confirmed the PR's known open items. I flagged buttons overflowing their container and a duplicated screen in the online and offline network states.
As a mentor, I reviewed student PRs on a Hardhat/Foundry task that included a testnet deployment. One student said their contract was on Lisk Sepolia, but when I checked the deployed address, it was the wrong contract. I flagged it and closed the PR, the student resubmitted with the correct one. That's the call I'd point to: I verify what's on-chain instead of trusting the PR description.
Testing, security and UX experience
Start from the issue. I check the PR against the acceptance criteria, including missing states and edge cases.
Run it locally. I review the running code, not just the diff. On GoodWidget I worked through each Storybook fixture in both themes and at two screen sizes.
Run the existing tests. I run the repo's own test suite to catch regressions, then check whether new behavior has tests.
UX. Frontend is my main lane, so I check responsiveness, empty and error states, and theme consistency.
Availability
Wednesday and Friday, up to 8 hours a week
WAT (UTC+1)
I won't review core contract changes that move funds on my own. If something is outside what I can properly assess, I'll say so rather than approve it.
deamybro commentedon Nov 6, 2026
Application: Code Reviewer Role
MavDavis commentedon Nov 6, 2026
Hi @L03TJ3, I'd like to apply for the reviewer role.
GitHub: @MavDavis
I've been a software engineer for over 5 years, working mainly with React, TypeScript, Vue and Node. I review code as part of my day-to-day work, and I care most about the things that actually break in production: transaction state, security checks, and edge cases nobody tested.
What I bring
Security: I built HMAC signature verification for webhooks on TradeFlow-API, scoped API key permissions on Stellar-Micro-Donation-API, and a CORS allowlist on ChronoPay. So I know what to look for when a PR touches auth, signatures or permissions.
Transaction correctness: on axionvera-sdk I added a way to wait for a transaction to actually confirm before reporting success, plus batch simulation before sending. On hermes I made bet placement validate everything up front so a bad input can't leave state half-written. A failed or pending transaction showing as success is the first thing I check for.
Testing and accessibility: I've written test suites for API endpoints and UI components, and added accessibility tests and fixes for a multi-step wizard on Commitlabs. I also wrote the focus ring spec for buttons, inputs and links on Fluxora.
How I'd review for GoodBounties
For the bridge widget QA on #277, I planned it like this: run the build and the widget's tests, then test every QA case by hand in Storybook on desktop and 390px mobile, in light and dark mode, with keyboard and contrast checks. For the live transfer, I'd only mark it as passed once the transaction is confirmed on the destination chain, and I'd also test a real rejected wallet prompt followed by a retry. I'd compare the build against the design references and finish with a clear accept, hold or retest.
I review every PR the same way. I start from the issue and its acceptance criteria, pull the branch and run it, and go after the cases that usually break: rejected or cancelled wallet prompts, wrong network, failed transactions, stale sessions, and empty or error states. My feedback goes through GitHub reviews with steps to reproduce and screenshots, and I re-check once fixes are in.
I can start right away, any day of the week. I'm on WAT (UTC+1) and can usually pick up a review the same day it's assigned.
Just to flag it: I've also asked to do the QA on PR #266 (#277). I'm happy to take either role there, whichever works for the team.
cyzcz commentedon Nov 7, 2026
Application: GoodBounties Reviewer Group
1. GitHub profile & strongest technologies
viem/wagmi/ethers(Celo, XDC, Fuse, Base, and Ethereum Mainnet RPC & contract integration), Node.js, Solidity (Hardhat / Foundry), and Go.GoodDollar/GoodWidget(Storybook fixtures, mocked-RPC Playwright specs,goodreserve-widget,citizen-claim-widget,superfluid-campaign-widget),GoodDollar/GoodSDKs(@goodsdks/good-reserve,@goodsdks/bridging-sdk,@goodsdks/citizen-sdk),GoodDollar/GoodWeb3-Mono(@gooddollar/good-design), andGoodDollar/GoodServer.2. Code review, verification & audit calls
My review-side evidence comes from code-verification, regression-hardening, and security/correctness PRs where I audited existing implementations, identified subtle root causes, and shipped verified fixes:
sorotrail/SoroTrail#1347 & #1349):POSTrequests checked the current count before inserting outside a serialized transaction boundary, allowing callers to exceed their tenant quota under concurrency. Rather than just adding a superficial handler check, I serialized the cap check inside the store transaction and followed up with a property-based test suite (#1349) exercising cross-tenant isolation across every API endpoint. Both PRs were reviewed and merged by the maintainers.sorotrail/SoroTrail#1343, #1344 & #1348):HyperDevTools/stellar-toolkit#24, #25 &HyperDevTools/stellar-defi-analytics#10):3. Testing, security & UX experience
receipt.status === 'reverted') mistakenly treated as success, decimal mismatches (e.g. 6-decimal USDC vs. 18-decimal USDm/G$ across Celo and XDC), and wallet session/account-switch cleanup. See also my security & encryption verification work in SoroBeacon #703 and soroban-test-suite #10.1280x800) and mobile (390x844) viewports, checking light/dark theme tokens, disabled/loading/error states, wallet rejection recovery, and faithful adherence to design references.4. Availability & review boundaries
Fuma2514 commentedon Nov 7, 2026
Application: GoodBounties reviewer group\nProfile: @Fuma2514\nI'd like to review PRs in the participating repos. My background: smart contract auditing and LLM-integrated apps \u2014 I run adversarial review passes as a service, so reviewing other people's work with fresh eyes is literally what I do. Recent public examples: dreamdex-feedback and payment-coroner under my profile, plus a live demo integration (Groq-based assistant with deterministic reservation flow) at https://fuma2514.github.io/bella-roma-demo/.\nStrong areas: Solidity/security review, JS/TS integrations, API keys & config hygiene in PRs. Timezone UTC+7, can keep a <24h review turnaround.
Fuma2514 commentedon Nov 7, 2026
Following up on my comment above — the working sample is still up if it's useful. If you'd like the full version, I can deliver it as a fixed-scope project (I'm available for hire: https://github.com/Fuma2514). If this isn't a priority right now, no problem — feel free to close or ignore this thread.