Skip to content

15 - Your First Contribution

What this session is

The whole thing. Walk through making a real contribution to a real K8s-related OSS project, end-to-end.

The workflow

Identical pattern:

  1. Fork on GitHub.
  2. Clone your fork.
  3. Add upstream as remote.
  4. Branch off main.
  5. Set up: test the chart / operator installs cleanly on a fresh cluster.
  6. Change the file(s).
  7. Run lint + test locally (same commands CI runs).
  8. Push to your fork; open PR.

Step 1: Fork & clone

GitHub → Fork. Then:

git clone git@github.com:<you>/<project>.git
cd <project>
git remote add upstream git@github.com:<owner>/<project>.git
git fetch upstream

Step 2: Branch

git checkout -b fix/chart-readme-typo

Step 3: Set up

For a Helm chart:

helm lint .
helm template . | head -50
helm install test . -n test --create-namespace
kubectl get all -n test
helm uninstall test -n test

For an operator:

make test
make manifests
make docker-build

For a kubectl plugin:

go test ./...
go build -o kubectl-myplugin .

If anything fails on a fresh clone, fix that first or ask in the issue.

Step 4: Make the change

The change should be: - Small. 1-10 lines for a first PR. - Focused. One issue per PR. - Tested. Re-run the lint and test commands locally.

For Helm chart docs: edit README.md or comments in values.yaml. For chart template fixes: edit templates/<file>.yaml. For operator docs: usually README.md or docs/.

Step 5: Re-run CI's commands locally

Whatever the workflow runs:

helm lint .
ct lint --config ct.yaml
ct install --config ct.yaml          # actually installs against a fresh kind cluster

For chart-testing's install command, you need kind (or any local cluster) running.

For operators:

make test
make lint

All green? Push. Red? Fix locally first.

Step 6: Commit and push

git add <files>
git commit -m "chart: fix typo in README installation section"

If DCO required:

git commit -s -m "chart: fix typo in README installation section"

Push:

git push origin fix/chart-readme-typo

GitHub prints a URL to open the PR.

Step 7: Open the PR

On the upstream repo, "Compare & pull request."

  • Title. Short, descriptive.
  • Description. What changed, why, how tested. Reference issue: Closes #123.
  • Checklist. Address every item.

Submit. CI runs. Fix anything red by pushing more commits.

Worked example: improving a Bitnami chart's README

Suppose you noticed bitnami/postgresql's chart README has an outdated example using apiVersion: v1beta1 for a long-deprecated resource. You'd:

git clone git@github.com:<you>/charts.git
cd charts
git remote add upstream git@github.com:bitnami/charts.git
git fetch upstream

git checkout -b docs/postgresql-update-apiversion

# Edit bitnami/postgresql/README.md, fix the apiVersion example.

# Lint:
cd bitnami/postgresql
helm lint .
cd -

# Commit (Bitnami uses DCO):
git add bitnami/postgresql/README.md
git commit -s -m "[bitnami/postgresql] Update outdated apiVersion in README"
git push origin docs/postgresql-update-apiversion

Open PR. Wait for review.

What review looks like

Standard: 1. "LGTM, merging." Done. 2. "Could you change these?" Address each. Push commits. 3. "Not what we want." Rare for first PRs. 4. Silence. Polite check-in after 1 week.

For CNCF projects, reviews are often more rigorous (multiple reviewers required, formal LGTM/Approve labels). Read the project's review guidelines.

After the merge

  • Update fork's main.
  • Delete branch.
  • Take a screenshot.
  • Sit with it.

After your first PR

  1. Pick another issue. Familiarity compounds.
  2. After 3-5 PRs, become a regular. Review others.
  3. Build your own kubectl plugin or Helm chart. Publish.
  4. Move toward operators (requires Go).

What you might wonder

"PR sits for weeks?" Polite check-in. CNCF projects can have multi-week review cycles by design (formal LGTM/Approve flow). Patience.

"What about Kubernetes itself?" A category of its own. CLA required, multiple reviewers, conformance tests. SIG-Docs is the on-ramp - documentation contributions are well-shepherded and a respected path into the project. Don't start there for a first OSS PR; build experience with smaller projects first.

"Maintainer rude?" Disengage. Try another project.

Done with this path

You've: - Installed kubectl and a local cluster. - Deployed pods, Deployments, Services. - Managed config and secrets. - Used PVCs for persistent storage. - Set up Ingress for routing. - Installed Helm charts. - Debugged with kubectl power tools. - Read a real K8s OSS project. - Submitted a PR.

What you should do next: keep deploying things to your local cluster. Apply Helm charts of tools you actually use. Read their YAML. Familiarity compounds.

Recommended next paths on this site:

Congratulations. You are no longer a beginner.

Comments