Contributing

How to contribute to the NaaP platform and community.

Overview#

NaaP is an open platform and we welcome contributions from the community. Whether you're fixing bugs, adding features, improving documentation, or building plugins, there are many ways to get involved.

New to NaaP? Read the Development Process guide for the full branch strategy, PR workflow, and team-specific guidance.

Ways to Contribute#

Build Plugins#

The most impactful way to contribute is by building plugins that extend the platform's functionality. See the Plugin Development Guide to get started, then follow the Development Process for how to set up your team's workflow.

Report Issues#

Found a bug? Open an issue on GitHub with:

A clear title and description
Steps to reproduce the issue
Expected vs. actual behavior
Your environment (OS, Node version, browser)

Improve Documentation#

Documentation improvements are always welcome:

Fix typos and clarify wording
Add missing examples
Update outdated information
Translate docs to other languages

Submit Code#

For bug fixes and features:

Fork the repository
Create a feature branch following the naming convention: feat/<team>/<description>
Make your changes following Conventional Commits
Write tests for new functionality
Run the test suite: npm test
Open a PR against main

See the full PR process for details.

Development Setup#

Terminal

# Fork on GitHub, then clone your fork

$git clone https://github.com/<your-username>/NaaP.git

$cd NaaP

# Add upstream remote

$git remote add upstream https://github.com/livepeer/naap.git

# First-time setup + start (setup is automatic)

$./bin/start.sh

# Daily development:

$./bin/start.sh # smart start (~6s): auto-detects changed plugins

$./bin/start.sh community # shell + one plugin (~6s)

$./bin/start.sh --all # all plugins (~10s warm)

$./bin/stop.sh # parallel stop (~2s)

# Login at http://localhost:3000

# Email: admin@livepeer.org Password: livepeer

Code Style#

TypeScript: All code should be written in TypeScript with strict mode
ESLint: Follow the project's ESLint configuration
Prettier: Format code with Prettier before committing
Naming: Use camelCase for variables/functions, PascalCase for components/types
Comments: Write JSDoc comments for public APIs

Pull Request Guidelines#

Target main: All PRs target main directly. Vercel PR previews serve as staging
Keep PRs focused: One feature or fix per PR, under 400 lines when possible
Use Conventional Commits: feat(plugin/name): add feature
Write tests: Include unit tests for new functionality
Update docs: Update documentation if your change affects the public API
Follow conventions: Match the existing code style
Describe your changes: Write a clear PR description

Community Guidelines#

Be respectful and inclusive
Provide constructive feedback
Help newcomers get started
Share knowledge and best practices

Getting Help#

GitHub Discussions: Ask questions and share ideas
GitHub Issues: Report bugs and request features
Documentation: Browse these docs for answers
Development Process: Full guide for plugin teams and core contributors