Rukpak is an Apache 2.0 licensed project and accepts contributions via GitHub pull requests (PRs).
This document outlines some conventions on commit message formatting, contact points for developers, and other resources to help RukPak contributors.
By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the DCO file for details.
- Email: operator-framework-olm-dev
- Slack: #rukpak-dev
- Working Group: olm-wg
- Fork the repository on GitHub.
- Clone onto your local development machine via
git clone https://github.com/{$GH-USERNAME}/rukpak
. - Add the operator-framework/rukpak as an upstream.
remote:
git remote add upstream https://github.com/operator-framework/rukpak
. - Create a new branch from the default
main
branch and begin development.
Any new contribution should be accompanied by a new or existing issue. This issue can help track work, discuss the design and implementation, and help avoid wasted efforts of multiple people working on the same issue. Trivial changes, like fixing a typo in the documentation, do not require the creation of a new issue.
Proposing larger changes to the RukPak project may require an enhancement proposal, or some documentation, before being considered. The maintainers typically use HackMD to prepare small design drafts for any new features. These docs are linked in the Designs document.
Any change to RukPak's existing behavior or features, APIs, or changes and additions to tests do not require an enhancement proposal.
This is a rough outline of what a contributor's workflow looks like:
- Identify or create an issue.
- Create a topic branch from where to base the contribution. This is usually the main branch.
- Make commits of logical units.
- Make sure commit messages are in the proper format (see below).
- Push changes in a topic branch to a personal fork of the repository.
- Submit a pull request to the operator-framework/rukpak repository.
- Wait and respond to feedback from the maintainers listed in the OWNERS file.
Thanks for contributing!
Contributing PRs with a reasonable title and description can go a long way with helping the PR through the review process.
When opening PRs that are in a rough draft or WIP state, prefix the PR description with WIP: ...
or create a draft PR.
This can help save reviewer's time by communicating the state of a PR ahead of time. Draft/WIP PRs can be a good way to
get early feedback from reviewers on the implementation, focusing less on smaller details, and more on the general
approach of changes.
When contributing changes that require a new dependency, check whether it's feasible to directly vendor that code without introducing a new dependency.
Currently, PRs required at least one approval from a RukPak maintainer in order to get merged.
The coding style suggested by the Golang community is used throughout the RukPak project:
In addition to the linked style documentation, RukPak formats Golang packages using the golangci-lint
tool. Before
submitting a PR, please run make lint
locally and commit the results. This will help expedite the review process,
focusing less on style conflicts, and more on the design and implementation details.
Please follow this style to make the RukPak project easier to review, maintain and develop.
If the contribution changes the existing APIs or user interface it must include sufficient documentation to explain the new or updated features.
The RukPak documentation is primarily housed at the root-level README, and there is also provisioner-specific documentation located in the provisioners directory.