> ## Documentation Index
> Fetch the complete documentation index at: https://na-36-mintlify-aebde2c5.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Contribution Guide
> How to contribute to Livepeer – code, documentation, governance, community support, and bug reports across all repositories.
export const LinkArrow = ({href, label, description, newline = true, borderColor, className = '', style = {}, ...rest}) => {
const linkArrowStyle = {
display: 'inline-flex',
alignItems: 'center',
justifyContent: 'center',
gap: "var(--lp-spacing-1)",
width: 'fit-content',
...borderColor && ({
borderColor
})
};
return
{newline &&
}
{label}
{description && description}
{description && }
;
};
Livepeer is an open-source project and community contributions are essential to its growth. You do not need to write code to make a valuable impact – documentation improvements, governance participation, community support, and bug reports are all valued contributions.
## Contributors Spotlight
}>
## Ways to Contribute
Fix bugs, build features, and improve tooling. Open a discussion before starting large features. Each repo has a `CONTRIBUTING.md`.
Found something outdated, missing, or confusing? Docs contributions are always welcome. See the workflow below.
Participate by voting on proposals, commenting on LIPs on the forum, or drafting improvement proposals.
Help answer questions in Discord or the Forum. Helping others onboard is one of the highest-value contributions you can make.
Found a bug? Open an issue on the relevant GitHub repository with full reproduction steps.
Share ideas on the Forum. Even if your idea does not ship immediately, it feeds into community thinking about what the network needs.
## Contributing to the Code
### Before You Start
* **Check existing issues and discussions** – search GitHub before opening a new issue or starting work on a feature. A quick "is anyone working on this?" can save everyone time.
* **Open a discussion for large changesets** – for major new features, open a GitHub Discussion or Issue first. This avoids investing effort in a PR that may not be accepted.
* **Read the repo's `CONTRIBUTING.md`** – each repository has its own contribution guide covering setup, testing, and PR conventions.
### Key Repositories
The Go implementation of the Livepeer Protocol. Contributing guide covers commit structure, changelog requirements, and PR conventions. Contributions classified by mode: General, Broadcaster, Orchestrator, Transcoder.
The Studio monorepo (TypeScript). Covers code of conduct, yarn usage (not npm), and issue/PR templates. Code reviews happen weekly.
The JavaScript/React SDK. Guide covers setting up a production Studio API key for tests, running the test suite, and PR etiquette. Discuss major API changes before building.
The containerised AI inference runtime. Contributions include new pipeline types, model support, and infrastructure improvements. See the README for development setup.
Solidity smart contracts. All contributions and bug fixes welcome as pull requests. Security vulnerabilities must go through Immunefi, not GitHub Issues.
The documentation repository (this site). See the Documentation Contribution section below for the specific workflow.
### General Pull Request Principles
These apply across all Livepeer repositories:
* **Keep PRs focused** – one logical change per pull request. Smaller, well-scoped PRs are easier to review and merge.
* **Write readable commit messages** – use [Conventional Commits](https://www.conventionalcommits.org/) format where repos require it: `fix:`, `feat:`, `docs:`, and related types.
* **Add tests** – when adding features or fixing bugs, include test cases covering the new or updated behaviour.
* **Update the changelog** – `go-livepeer` and other repos require updates to `CHANGELOG_PENDING.md` with each PR.
* **Respond to review feedback promptly** – do not force-push to a branch under active review.
* **Rebase and merge** – for larger changesets, maintainers may request a local rebase to clean up the commit history before merging.
## Contributing to the Docs
The Livepeer documentation is open source and lives at [github.com/Livepeer/docs](https://github.com/livepeer/docs) on the `docs-v2` branch.
### Quick Path: Feedback Without Code
You do not need to use Git to contribute to the docs:
* **Thumbs up/down** – on any documentation page to signal whether it was helpful
* **GitHub Issues** – [open an issue](https://github.com/livepeer/docs/issues) describing what is wrong, missing, or confusing. Eight issue templates are available.
* **Discord** – share feedback in the `#lounge` channel or tag a documentation team member
### Pull Request Workflow
Navigate to [github.com/Livepeer/docs](https://github.com/livepeer/docs) and click **Fork**. This creates your own copy.
```bash icon="terminal" theme={"theme":{"light":"github-light","dark":"dark-plus"}}
git clone https://github.com/YOUR_USERNAME/docs.git
cd docs
git remote add upstream https://github.com/livepeer/docs.git
```
```bash icon="terminal" theme={"theme":{"light":"github-light","dark":"dark-plus"}}
git checkout docs-v2
git pull upstream docs-v2
git checkout -b docs-plan/your-short-description
```
Always branch from `docs-v2`. Never commit directly to `docs-v2` or `main`.
Edit or create `.mdx` files in the relevant section. Follow the [Style Guide](/v2/resources/documentation-guide/copy-style/style-guide) for formatting and component usage.
Key rules:
* Use UK English
* No inline styles – use Mintlify global components or component primitives from `/snippets/components/`
* No hardcoded colours – use CSS custom properties
* Absolute imports only: `/snippets/components/...` (not relative paths)
The repository has pre-commit hooks that check structure, style, links, spelling, and MDX validity. Run them before pushing:
```bash icon="terminal" theme={"theme":{"light":"github-light","dark":"dark-plus"}}
./tools/lpd hooks run
```
Or run the full test suite:
```bash icon="terminal" theme={"theme":{"light":"github-light","dark":"dark-plus"}}
node tests/run-pr-checks.js --base-ref docs-v2
```
Push your branch and open a PR against `docs-v2` on the upstream repository. Use the provided PR template and fill it out completely. PRs are reviewed within 48–72 hours on business days.
### Review Assignments
Documentation changes are reviewed by section owners defined in [`.github/CODEOWNERS`](https://github.com/livepeer/docs/blob/docs-v2/.github/CODEOWNERS). Generally:
* **Developers section** – developer relations team
* **Gateways section** – Gateway team
* **Orchestrators section** – Orchestrator team
* **Resources / cross-cutting** – documentation team
## Contributing to Governance
Token holders can participate in Livepeer governance without writing any code.
Visit the [Livepeer Forum governance category](https://forum.livepeer.org) and [Explorer voting page](https://explorer.livepeer.org/voting) to see what is currently open for input.
Add your perspective on active threads in the forum before proposals move to an on-chain vote. Well-reasoned feedback is valued from all participants.
If you hold staked LPT, you can cast votes on active proposals directly from the [Explorer](https://explorer.livepeer.org/voting).
If you have a protocol improvement idea, draft it on the Forum under the Governance category and solicit community feedback before moving to a formal LIP.
## Grants and Bounties
If you want to contribute more substantially and receive compensation:
Two grant tracks: **Open Network Grants** (tools, educational content, node operations improvements) and **Video Disruptor Grants** (cutting-edge video research and novel applications). Grants are paid in LPT.
Scoped software tasks with defined acceptance criteria and compensation. A good entry point for contributors who prefer clearly-defined work.
Grant applications are reviewed bi-weekly by the Livepeer Grants committee. To discuss a potential grant application before submitting, ping the grants team in the `#governance` Discord channel.
## Community Contribution Principles
These apply across all Livepeer repositories and contribution types:
* **Read before you build** – check existing issues and discussions before starting major work
* **Keep PRs focused** – one logical change per pull request
* **Write readable commit messages** – use Conventional Commits format
* **Be constructive in reviews.** If a contribution does not fit, explain why and offer suggestions for improvement
* **Link to relevant documentation** – when closing issues or declining PRs, link to existing resources where possible
Not sure where to start? Search for issues labelled `good first issue` or `help wanted` across the [Livepeer GitHub organisation](https://github.com/livepeer). These are specifically tagged as appropriate entry points for new contributors.