The QA Process

Read below how to do QA.

The QA Process

1. Claim a needs-qa issue

2. Test against every criterion listed in the issue

3. Document what you tested, what passed, what failed

4. Submit your QA report as a comment on the issue (use the QA report format)

5. If bugs found, file separate bug reports

🚫 Not acceptable: Vague claims with no steps. Non-reproducible reports. AI-generated content not verified against actual behaviour.

✅ Good bug report:

`Severity: Blocker

Summary: Staking flow fails silently when wallet has insufficient G$ balance

Environment: Chrome 123 / MacOS 14.4 / MetaMask 11.9 / Fuse network

Steps to reproduce:

1. Connect wallet with 0 G$ balance

2. Navigate to the Stake tab

3. Enter any amount and click Confirm

Expected: Error message — insufficient balance Actual: Modal closes, no error shown, no transaction sent

Evidence: [screen recording link]

Related to this PR? Yes — balance check removed on line 89 of StakeModal.tsx`

❌ Weak bug report (not acceptable):

"The staking thing doesn't seem to work on my end"

Bug Severity

Severity	Definition	Examples
Blocker	Feature broken, data loss, security issue, or breaks existing working feature	Transaction fails silently, funds to wrong address, previously working flow now broken
Major	Feature works but behaves incorrectly under normal usage	Wrong amount shown, confirmation missing, edge case affecting many users
Minor	Small cosmetic or UX issue	Typo, misaligned element, brief flicker

When unsure, go one level higher — maintainers can downgrade. Maintainers may cap bug bonuses per PR; if a cap applies it will be stated in the PR announcement.

What counts as an accepted bug: Reproducible with your steps, directly caused by changes in this PR, and not already a documented known issue. Pre-existing bugs should be filed as a new GitHub issue — they may become a separate bounty.