This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. # Bounties To encourage community participation and reward good work on the protocol, bounties are established from time to time. A [Tari Improvement Proposal](https://rfc.tari.com/TIP-0001_tari_improvement_proposals) describing policy and budget elements for bounties is planned, but not yet written. This document describes the **process** of how bounties are tracked and rewarded. It is for reference to anyone interested in claiming bounties and anyone administering them, and should be updated as the methods change. ## Bounty Process Overview [The bounty board](https://github.com/tari-project/bounties) lists all open bounties across Tari repositories. A scanner checks a configured set of repositories in the [tari-project GitHub organization](https://github.com/tari-project/) about once an hour for issues that a repository maintainer has tagged with a sizing label: | Bounty size | GitHub Tag | Reward Size | |-----------------|-----------------|------------------| |Small|`bounty-S`|15,000 XTM| |Medium|`bounty-M`|60,000 XTM| |Large|`bounty-L`|150,000 XTM| |Extra Large|`bounty-XL`|450,000 XTM| The sizing label is what the scanner keys on. Only repository maintainers can apply labels, so an issue anyone can open only becomes a bounty when a maintainer labels it. If your repository is not on the bounty board, ask the bounty administrator to add it. To claim a bounty, open a Pull Request that references the issue. The standard way is to add the line: ``` Fixes #XXX ``` where `XXX` is the issue number, somewhere in the PR description. **Include your XTM payout address in the PR description as well**, on its own line. If no address is found when the PR merges, the bounty bot will post a comment on the PR asking for one. Only an address posted from the PR author's own GitHub account is accepted; addresses posted by anyone else are ignored. Once a maintainer merges the PR, the bounty is queued for payout. The bounty administrator sees it on their dashboard, confirms the payout address, and runs a payout batch, usually within a week or two. Payouts are recorded manually; the bot queues, a person pays. ## Retro Bounties Contributors may request a retro bounty for a contribution, or maintainers may advocate for one on a contributor's behalf. There are three routes, depending on the state of the work. **The pull request is still open.** A maintainer creates a new issue for the contribution and applies a sizing label as described in the [bounty process overview](#bounty-process-overview). The contributor adds the `Fixes #XXX` line to the PR description. Once merged, it is handled like any other bounty. **The pull request is already merged, in a repository on the bounty board.** A maintainer applies the `retro-bounty` label plus a sizing label (`bounty-S`, `bounty-M`, `bounty-L` or `bounty-XL`) directly to the merged pull request. No issue is needed. The scanner picks it up and queues a payout for the PR author. Note that the labels go on the pull request, not on an issue. **The contribution is not code, or was merged somewhere the scanner does not watch** (for example a vulnerability report without a fix, or community work), see the [special contributions](#special-contributions) section. ## Special Contributions Contributions that involve no code, or code already merged elsewhere, are rewarded through the [special contributions](https://github.com/tari-project/special_contributions/) repository. This lets the standard bounty process run without changes to the main repositories. Issues in this repository are created by repository maintainers only, on request from a Core Contributor or the council. The maintainer creates an issue describing the contribution and applies a sizing label. The scanner recognizes only issues carrying one of these labels, and only maintainers can apply them. **Do not create issues or pull requests in this repository unless a maintainer has asked you to. Unlabeled issues and unsolicited pull requests are not tracked and will not be paid.** Once the issue exists, the contributor opens a Pull Request following [the pattern of previous pull requests](https://github.com/tari-project/special_contributions/pulls?q=is%3Apr+state%3Amerged), with `Fixes #XXX` in the description and their XTM payout address on its own line. A maintainer merges it. The bounty is then queued for payout [as described in the overview](#bounty-process-overview).