Contributing to the NetObserv projects

August 14, 2026 · View on GitHub

These contribution guidelines apply to all projects / repositories in the netobserv organization. Almost the source code is licensed under Apache v2.0, with the exception of our BPF code which is GPL.

Contributions can take the shape of pull requests for documentation or code change, providing feedback, opening bug reports or even writing blog posts. They are always welcome! For large changes, it is recommended to start a discussion prior to opening a pull request. Or as an alternative, you can reach out to the team on the CNCF slack channel #netobserv-project (to create an account, get an invite from https://slack.cncf.io/).

There should be mutual respect between contributors and maintainers.

Project management and roadmap

You can follow the project management and roadmap on GitHub: https://github.com/orgs/netobserv/projects/1.

Code of Conduct

See CODE_OF_CONDUCT.md.

Security vulnerabilities

Unlike other contributions, if you think you discovered a security vulnerability, please do not report it publicly or even fix it publicly. Please follow the instructions described in the GitHub private reporting process instead.

Documentation contributions

Upstream (community) documentation can be found in their respective component repositories, either in the main README or in their docs directories. For example:

For the documentation related to the downstream OpenShift product (Network Observability), you should follow the specific OpenShift documentation guidelines. Still, don't hesitate to get in touch with the team first.

Code contributions

Code contributions are very welcome. As said, it's recommended to have a discussion prior to doing any large change. When adding a new feature, we need to understand which use case it is going to solve, and assess whether that is something the core development team is going to maintain in the long run, or if the maintenance can be delegated.

If you don't really know where to start among the different repositories, take a look at the architecture document: it should guide you through the components. You can also open a discussion.

We use GitHub's pull request system to merge contributions. The process is:

  • You fork one or more of the repositories with your GitHub account
  • You make changes, build and test them (the build process should be described in the respective repositories - contact us if you need help)
  • Once you are happy with them, you can push them to your fork and open a pull-request
    • If you don't think the PR is ready but still would like to get some early discussion, you can open a draft PR.
  • The changes should start being reviewed within a week. If that's not the case, don't hesitate to mention any of the maintainers in your PR. Maintainers are listed in the OWNERS file.
  • There probably will be some back and forth discussion during the review process. You may be asked to change some parts of your code as a result. New changes should be added as new commits rather than amending / squashing the commits, so that reviewers can focus on the new diffs. Sometimes you may also have to rebase it.
  • As part of the continuous integration, there are some automated checks that will be executed in the PR. In general we want all of them to pass, however and unfortunately, some of them aren't 100% reliable and might fail for reasons unrelated to your changes. As a rule of thumb, the GitHub action checks (with the GitHub icon) are reliable and should always pass. If they don't, you probably broke something. If other checks don't pass, don't worry too much, the maintainers will check if it's ok anyway or not.
  • When you and the reviewers consider the PR is ready, it can finally be merged. Commits will be squashed in a single one (unless exception), then merged into the main branch.

AI-Assisted Contributions Policy

  1. You MAY use AI assistance for contributing to NetObserv, as long as you follow the principles described below.

  2. Accountability: You MUST take the responsibility for your contribution. Contributing to NetObserv means vouching for the quality, license compliance, and utility of your submission. All contributions, whether from a human author or assisted by large language models (LLMs) or other generative AI tools, must meet the project’s standards for inclusion. The contributor is always the author and is fully accountable for the entirety of these contributions.

  3. Transparency: You MUST disclose the use of AI tools when the significant part of the contribution is taken from a tool without changes. You SHOULD disclose the other uses of AI tools, where it might be useful. Routine use of assistive tools for correcting grammar and spelling, or for clarifying language, does not require disclosure.

  • Information about the use of AI tools will help us evaluate their impact, build new best practices and adjust existing processes.
  • Disclosures are made where authorship is normally indicated. For contributions tracked in git, the recommended method is an Assisted-by: mention either in the commit message trailer, or in the pull request description.
  • Examples:
    • Assisted-by: generic LLM chatbot
    • Assisted-by: ChatGPTv5
  1. Contribution & Community Evaluation: AI tools may be used to assist human reviewers by providing analysis and suggestions. You MUST NOT use AI as the sole or final arbiter in making a substantive or subjective judgment on a contribution. This does not prohibit the use of automated tooling for objective technical validation, such as CI/CD pipelines, automated testing, or spam filtering. The final accountability for accepting a contribution, even if implemented by an automated system, always rests with the human contributor who authorizes the action.

The key words “MAY”, “MUST”, “MUST NOT”, and “SHOULD” in this document are to be interpreted as described in RFC 2119.

Source: This policy was originally based on the Fedora Project policy.