# DamageBDD Contractor Development Process

Scope work in a GitHub issue, agree acceptance and sats compensation, then record review and BTC or Lightning payment.

Canonical HTML: <https://damagebdd.com/contractors.html>


## Table of Contents

-   [Purpose](#purpose)
-   [Communication Rule](#communication-rule)
-   [Workflow Overview](#workflow-overview)
-   [Step-By-Step Process](#step-by-step-process)
    -   [1. Pick an Issue\*\*](#1-pick-an-issue)
    -   [2. Claiming Work\*\*](#2-claiming-work)
    -   [3. Working on the Task\*\*](#3-working-on-the-task)
    -   [4. Submit a Pull Request\*\*](#4-submit-a-pull-request)
    -   [5. Review & Merge\*\*](#5-review-merge)
    -   [6. Payment\*\*](#6-payment)
-   [Payment & Wallet Rules (Strict)](#payment-wallet-rules-strict)
-   [Legal & Relationship Clarification](#legal-relationship-clarification)
-   [Best Practices for Contractors](#best-practices-for-contractors)
-   [Why This Workflow Works](#why-this-workflow-works)
-   [One Sentence Summary](#one-sentence-summary)


<a id="purpose"></a>

## 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 or Lightning wallet.

Some issues include executable BDD acceptance criteria; others specify a
review or another verification method. Follow the criteria in the assigned issue.

This is a contribution workflow with acceptance and payment terms recorded
on the work item. It does not establish that every platform account or
payment interface is non-custodial. See [payment flows](payments.md).


<a id="communication-rule"></a>

## Communication Rule

****All communication happens via GitHub Issues.****
No email, no DMs, no meetings unless absolutely required.

Each issue represents:

<a id="the-scope"></a>


#### `The scope`

<a id="the-expected-output"></a>


#### `The expected output`

<a id="the-acceptance-criteria"></a>


#### `The acceptance criteria`

<a id="the-payout"></a>


#### `The payout`

<a id="the-payment-method-one-off-btc-address-or-lightning-invoice"></a>


#### `The payment method (one-off BTC address or Lightning invoice)`

This protects both sides and removes management overhead.


<a id="workflow-overview"></a>

## Workflow Overview

1.  ****Find an issue**** labelled `open` or `help-wanted`.
2.  ****Comment “/claim”**** if you want to work on it.
3.  Maintainer assigns the issue to you.
4.  ****Open a branch****, build the solution, and push a PR referencing the issue.
5.  Maintainer reviews & merges.
6.  ****You get paid in BTC (on-chain or Lightning)**** to a one-off address or 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.


<a id="step-by-step-process"></a>

## Step-By-Step Process


<a id="1-pick-an-issue"></a>

### 1. Pick an Issue\*\*

Go to the repository’s **Issues** page. Look for:

<a id="bounty"></a>


#### `bounty`

<a id="open"></a>


#### `open`

<a id="help-wanted"></a>


#### `help-wanted`

<a id="easy-medium-or-advanced"></a>


#### `easy`, `medium`, or `advanced`

Each issue already contains:

<a id="a-short-description"></a>


#### `A short description`

<a id="a-task-breakdown"></a>


#### `A task breakdown`

<a id="payout-amount-listed-in-sats"></a>


#### `Payout amount listed in sats`

<a id="expected-definition-of-done"></a>


#### `Expected “definition of done”`

<a id="optional-bdd-feature-to-implement"></a>


#### `(Optional) BDD feature to implement`

If you need clarification, ****ask inside the issue****, not privately.


<a id="2-claiming-work"></a>

### 2. Claiming Work\*\*

Comment on the issue:

```text
/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.

&mdash;


<a id="3-working-on-the-task"></a>

### 3. Working on the Task\*\*

Create a branch in your fork:

```sh
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****.

&mdash;


<a id="4-submit-a-pull-request"></a>

### 4. Submit a Pull Request\*\*

Open a PR with this exact structure:

```markdown

### Summary

Fixes issue #<id>

### Verification

Describe:

* What you changed
* How you tested it (manual is OK initially)
* Any output or logs

### Payout

Payment Rail: BTC (on-chain) | Lightning

One-Off BTC Address or BOLT11 Lightning Invoice:
<insert your one-off address or invoice here>

Amount: <as listed in issue>

I confirm:
- This is a fresh, one-time payout destination.
- I control this wallet.
- This is a non-custodial wallet.
- This payment is for completed work only.

### Notes

Anything extra we should know.
```

This is your **invoice**.
There is no extra emailing or admin.

&mdash;


<a id="5-review-merge"></a>

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

```markdown
/ready-for-payment
```

&mdash;


<a id="6-payment"></a>

### 6. Payment\*\*

You are paid ****in BTC (on-chain or Lightning)**** to your quoted address or Lightning invoice.
This is finalised inside the Issue thread so the record is permanent.

For Lightning:

-   Only ****BOLT11 invoices**** are accepted.
-   Use a receiving wallet whose keys you control; the invoice format alone does not establish custody.
-   Expired invoices require resubmission.
-   Lightning payments are final.

DAMAGE token liquidity, pricing, or conversions are **not your concern**.
The treasury handles that.

&mdash;


<a id="payment-wallet-rules-strict"></a>

## Payment & Wallet Rules (Strict)

-   ****Never reuse payout addresses.**** Always generate a fresh one.
-   ****Never submit exchange deposit addresses.****
-   ****Never submit custodial Lightning invoices.****
-   ****One work item = one payout destination.****
-   ****All payout details must live in the PR.****
-   ****No payout details via DM, email, or chat.****

Failure to follow these rules may void payout eligibility for security reasons.

&mdash;


<a id="legal-relationship-clarification"></a>

## Legal & Relationship Clarification

By participating in this workflow, you acknowledge:

-   You are an ****independent contractor****, not an employee.
-   This is ****not an investment****, not revenue sharing, and not equity.
-   Payments are ****final compensation for completed work only****.
-   You are responsible for your own ****tax, reporting, and compliance****.
-   This contribution workflow requests a payout destination you control; it does not create a hosted wallet.

&mdash;


<a id="best-practices-for-contractors"></a>

## Best Practices for Contractors

-   Never reuse BTC addresses or Lightning invoices.
-   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.

&mdash;


<a id="why-this-workflow-works"></a>

## 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.
-   Lightning provides a payment rail; record the actual settlement outcome.

A passing feature or merged PR does not itself prove payment. Record acceptance
and the payment receipt separately. Automatic payout integrations need their
own release-specific evidence.

&mdash;


<a id="one-sentence-summary"></a>

## One Sentence Summary

****Do the work, open a PR, submit a one-off BTC address or Lightning invoice, get paid. GitHub is the contract.****