# Contribute

We value contributions from the Portainer community and encourage developers to propose fixes, improvements, and new ideas. 

The following guidelines outline our engineering workflows, please review these before making a contribution to ensure any changes can be integrated smoothly. 

## Contributing to the Portainer CE codebase

The Portainer CE codebase is available in [GitHub](https://github.com/portainer/portainer). Please follow our [build instructions](https://docs.portainer.io/2.33-lts/contribute/build) and the following guidelines when making a contribution.

### Repository structure

* Our main development occurs in private repositories, which are mirrored to public GitHub repos (e.g. [portainer/portainer](https://github.com/portainer/portainer/)).
* The `develop` and `release/*` branches in public repositories are **read-only**: merges into these branches are blocked to preserve synchronisation with our internal repositories.
* We maintain a separate `community` branch in each public repository to accept and review external contributions.

### Contribution process

1. **Fork the repository**
   * Create your own fork of the relevant Portainer public repository.
2. **Create a feature branch**
   * Base your changes on the current `develop` branch (not `main`, `release/*`, or `community`). This ensures you are working off the latest version of the codebase.
3. **Submit a Pull Request (PR)**
   * Open your PR against the `develop` branch.
   * Portainer engineers will update the target branch to `community` when the contribution is ready to be merged.
4. **Review and feedback**
   * Contributions will be reviewed by Portainer engineers.
   * We may request changes to align with coding standards, tests, or design decisions.
   * In some cases, we may adapt or refactor a contribution before merging.
5. **Integration**
   * Once approved and merged into `community`, Portainer engineers will cherry-pick contributions into the upstream private repository.
   * These changes will then flow into `develop` and subsequent releases through our normal sync process.
   * Not all contributions will be integrated upstream. Decisions will be based on roadmap alignment, technical fit, and quality.

### Contribution expectations

* **Coding standards**: Please follow existing project style and conventions.
* **Tests**: Include tests where applicable. Contributions without tests may be delayed.
* **Documentation**: Update relevant docs (e.g. README, usage notes) when changing functionality.
* **Scope**: Focus on well-defined features, fixes, or improvements. Large architectural changes should be discussed in an issue first.

### Communication

* For significant changes or new features, use [GitHub Discussions](https://github.com/orgs/portainer/discussions/categories/ideas) to start a discussion before starting the change.
* PR discussions are the best place for clarifications on specific contributions.

## Reporting bugs

If you find a bug, [please tell us](https://github.com/portainer/portainer/issues/new?assignees=\&labels=bug%2Fneed-confirmation%2C+kind%2Fbug\&template=Bug_report.md\&title=) so we can triage it. All bugs are managed in the [GitHub issues repo](https://github.com/portainer/portainer/issues). When you click through, our template makes it easy to record all of the details. Check the list of [open bugs](https://github.com/portainer/portainer/labels/kind%2Fbug) before reporting to avoid duplicates.

[This article](https://docs.portainer.io/2.33-lts/faqs/contributing/how-do-you-decide-which-bugs-and-features-to-work-on-first) covers how we prioritize bug fixes.

## Feature requests

You can request new features by posting an Idea in our [GitHub Discussions](https://github.com/orgs/portainer/discussions/categories/ideas) forum. Please check to see if someone has already requested the feature you want, and give it an upvote if so.

Learn how we prioritize feature development [in this article](https://docs.portainer.io/2.33-lts/faqs/contributing/how-do-you-decide-which-bugs-and-features-to-work-on-first).