Skip to content

Latest commit

 

History

History
36 lines (24 loc) · 4.61 KB

CONTRIBUTING.md

File metadata and controls

36 lines (24 loc) · 4.61 KB

Contributing to the NetObserv projects

These contribution guidelines apply to all projects / repositories in the netobserv organization.

They 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.

There should be mutual respect between contributors and maintainers.

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.