DamageBDD Contractor Development Process
Purpose
This page defines a lightweight, self-managed workflow for contractors contributing to DamageBDD. It is intentionally simple. You do not need to understand Behavior-Driven Development (BDD) to start. You only need a GitHub account and a BTC wallet.
Over time, you will naturally learn BDD because every task in the project is verified using it.
Communication Rule
All communication happens via GitHub Issues. No email, no DMs, no meetings unless absolutely required.
Each issue represents:
The scope
The expected output
The acceptance criteria
The payout
The payment address (one-off BTC address or Lightning invoice)
This protects both sides and removes management overhead.
Workflow Overview
- Find an issue labelled
openorhelp-wanted. - Comment “/claim” if you want to work on it.
- Maintainer assigns the issue to you.
- Open a branch, build the solution, and push a PR referencing the issue.
- Maintainer reviews & merges.
- You get paid in BTC to a one-off address/invoice you provide inside the PR.
That’s all.
BDD only becomes relevant later when the issue itself contains a feature file you must implement.
Step-By-Step Process
1. Pick an Issue**
Go to the repository’s Issues page. Look for:
bounty
open
help-wanted
easy, medium, or advanced
Each issue already contains:
A short description
A task breakdown
Payout amount listed in sats
Expected “definition of done”
(Optional) BDD feature to implement
If you need clarification, ask inside the issue, not privately.
2. Claiming Work**
Comment on the issue:
/claim I agree to deliver this task for the quoted sats. Work will begin now.
The maintainer will assign you. This avoids schedule / responsibility confusion.
—
3. Working on the Task**
Create a branch in your fork:
git checkout -b feat/<short-task-id>
Implement the solution.
If the issue includes BDD, just follow it as best as you can. If you don’t know how yet—don’t worry. The maintainer will help clean it up. The key is: deliver the thing.
—
4. Submit a Pull Request**
Open a PR with this exact structure:
### Summary Fixes issue #<id> ### Verification Describe: * What you changed * How you tested it (manual is OK initially) * Any output or logs ### Payout BTC Address or Lightning Invoice: <insert your one-off address/invoice here> Amount: <as listed in issue> I confirm this address is safe to pay. ### Notes Anything extra we should know.
This is your invoice. There is no extra emailing or admin.
—
5. Review & Merge**
Maintainer reviews your PR. If changes are needed, they are requested inside GitHub. Once approved and merged, you mark the issue as:
/ready-for-payment
—
6. Payment**
You are paid in BTC to your quoted address or Lightning invoice. This is finalised inside the Issue thread so the record is permanent.
DAMAGE token liquidity, pricing, or conversions are not your concern. The treasury handles that.
—
Best Practices for Contractors
- Never reuse BTC addresses. Always generate a one-off.
- Put all questions inside the issue.
- Keep branches small—one issue = one PR.
- Don’t wait for permission. If it’s assigned to you, build.
- If you’re stuck, comment in the issue.
Over time you will see that nearly every problem in DamageBDD ends with: write the behaviour in Gherkin and let the platform verify it.
You’ll naturally transition into BDD-driven development without being forced.
—
Why This Workflow Works
- Maintainer doesn’t micro-manage.
- Contractors control their own time.
- GitHub holds the full audit trail.
- Issues → PR → Merge → Pay.
- Scaling team ≠ scaling overhead.
- No off-platform chatter.
- No dependency on contractors learning BDD on day one.
Everything else—BDD pipelines, DAMAGE token, Aeternity receipts, Lightning settlement—runs behind the scenes.
—
One Sentence Summary
Do the work, open a PR, get paid in BTC. GitHub is the contract.