Status: Draft (2026-10-17), repository documentation + file inspection. Based on KubeVirt v1.9.0(commit 79d34c17)'s CONTRIBUTING.md, docs/reviewer-guide.md, docs/getting-started.md, OWNERS files, and PR template. Tests and builds were not executed.

Reading KubeVirt Source Code 8: Introduction to Contributing

Table of Contents

• 1. Intuition: Human Judgment and Bot Labels
• 2. Diagram
• 3. Re-examining the Map via OWNERS
• 4. Commands and Labels
• 5. What the Review Guide Tells You to Watch For
• 6. Good Spots for a First Contribution
• 7. How to Run Tests and Required Tools
• 8. Limitations
• References

1. Intuition: Human Judgment and Bot Labels

A KubeVirt PR requires the judgment of two people to be merged. A reviewer says "the code is good" and an/lgtm), approver says "it is acceptable to bring into this repository" (/approve). Who the reviewers and approvers are is determined by the OWNERS files in the directories touched by the PR, and their statements are made via slash commands in PR comments. Translating those statements into labels, running test lanes, and merging when all conditions are met is handled by a collection of bots called prow . Because it is the same approach as Kubernetes, learning it in one place allows you to use it in the other.

2. Diagram

3. Re-examining the Map via OWNERS

In v1.9.0, there are 141 OWNERS files (measured). The root OWNERS sets the default reviewers and approvers for all files to the alias code-reviewers·approvers , while build files (such asBUILD.bazel, Makefile ) are handled separately by sig-buildsystem . Directory-level OWNERS narrow this down further. For example, pkg/virt-controller/watch/vm/OWNERS from Part 3 is like this.

reviewers:
  - sig-compute-reviewers
approvers:
  - sig-compute-approvers
labels:
  - area/controller
  - sig/compute

Source: kubevirt/kubevirt v1.9.0 pkg/virt-controller/watch/vm/OWNERS(excluding comment lines, Apache-2.0). PRs touching this directory receive the sig/compute·area/controller label from Prow and select reviewers from sig-compute. The actual names behind the aliases are in OWNERS_ALIASES . Counting the personnel yields this (v1.9.0, measured).

This table is essentially another face of the code map. Network code from Parts 4 and 5 (pkg/network, converter/network) is handled by sig-network, storage code from Part 6 (pkg/storage) by sig-storage, and most of the rest by sig-compute. If you want faster reviews, it is best to keep your PR within the folders of a single SIG. Touching multiple SIGs requires multiple approvers.

4. Commands and Labels

Merging is not done by a human clicking a button, but by tide . Once both labels and passing tests are in place and there are no blocking labels (do-not-merge/…, /hold), it enters the queue. Draft PRs do not run CI and are not assigned reviewers, so opening a PR as a draft is polite when you want to ask about direction.

Three things are mandatory in a PR:

1. All commits must have a Signed-off-by: — DCO. Attached via git commit -s . Without it, the DCO check will block the PR.
2. The release-note block in the PR template — A single line if it is a user-visible change, or NONEotherwise. Release notes are generated from this block.
3. Tests — The baseline in the review guide is "Unit tests for new code, and at least one e2e test for new features and bug fixes" (reviewer-guide.md:103 vicinity).

Commit messages follow Kubernetes conventions (docs/commit-message-guidelines.md). The subject should be around 50 characters, imperative, with no period; the body should wrap at 72 characters, explain what and whyin the body, and put keywords like Fixes #123 in the PR description rather than the commit message. There are examples in the documentation of prefixing areas like net, vmi: . Also, the PR template checklist for v1.9.0 includes an item asking whether you complied with the KubeVirt AI Contribution Policy. If your PR was written with the help of tools, read that policy first.

5. What the Review Guide Tells You to Watch For

docs/reviewer-guide.md provides a brief backward explanation of why the designs seen in the previous seven parts are structured the way they are, letting you anticipate feedback during reviews.

• Do not add informers to node components(:43). This is why virt-handler watches VMIs filtered by node labels in Part 4. Conversely, virt-api is told to use GET instead of informers because virt-api is a component that scales freely, and maintaining caches would cause object transmission to explode.
• PATCH objects you did not create, UPDATE objects you created. This is why subresources in Part 2 modify VMs using JSON patch. If multiple actors share status, use PATCH with narrowed fields (VMI status in Parts 3 and 4).
• Events should occur only when status changes. Emitting events on every reconcile overloads the API server.
• Preserve list ordering. An example of how "update storms" occur when two controllers process the same condition list in different orders is the VMI conditions in virt-controller and virt-handler.
• Node operations requiring privileges belong in virt-handler, not virt-launcher. This mirrors the division of labor in Parts 4 and 5.
• Keep the upgrade path in mind. New virt-handler instances must be able to communicate with old virt-launcher instances (proto in Part 4).
• Coding style follows goimports·shfmt, and common Go mistakes are caught during builds by Bazel's nogo analyzers.

6. Good Spots for a First Contribution

Based on the map in this series, starting with a spot touching only a single file and its testis recommended.

• Choosing by label. good-first-issue·help-wanted·kind/bug label (guidance inCONTRIBUTING.md , line 49).
• Discrepancies between documentation and code. We actually encountered one while writing this series. docs/components.md describes the libvirt daemon inside the pod as libvirtd , but v1.9.0 runs virtqemud (Parts 1 and 5). Documentation PRs carry low testing overhead and help you read the code precisely in the process of fixing them. A PR adding size calculations to documentation on the CDI side (#4318) falls into the same category (Part 6).
• A single converter configurer. pkg/virt-launcher/virtwrap/converter/compute/ files correspond to individual devices, accompanied by _test.go (Part 5). Since this is a unit test looking only at VMI to domain structs without a fake cluster, it is easy to run.
• Webhook validation and messages. admitters/ functions have clear inputs (specs) and outputs (StatusCause lists) (Part 2). Refining error message field paths or phrasing is also what the review guide refers to as "reasonable error messages."
• Logs and events. Using the method of finding code via log pos (Part 1), you can discover places where the exact same line is logged too frequently (like device inspection logs in Part 7) on a real cluster. It is best to ask via an issue first before fixing.

7. How to Run Tests and Required Tools

We did not run tests while writing this article, nor did we install the tools below. Only the necessary items are listed.

Unit tests. The most reliable path is the builder container designated by the repository.

make test                                    # Bazel 로 전체(빌더 컨테이너 안)
make go-test WHAT=./pkg/virt-controller/...  # Bazel 없이 go test (역시 컨테이너 안)

Required are Docker or Podman, rsync, and the builder image downloaded once at the start (quay.io/kubevirt/builder:<판>, hack/dockerized , line 19). To run go test directly outside a container, you need the Go version matching go.mod 's go 1.26.0 and the libvirt development headers used via cgo by the virt-launcher package (libvirt.org/go/libvirt). We did not verify this time how far package execution extends outside a container since that requires tracing imports (unverified). Containers are convenient to start with. Since unit tests also use Ginkgo, you pass -ginkgo.focus='문자열' when running a single test.

Functional tests. make cluster-up kubevirtci creates a cluster running nodes as VMs, make cluster-sync uploads your build, and make functest runs tests/ . To run only a subset, use FUNC_TEST_ARGS='--focus-file=…' (docs/getting-started.md , line 221). Required are a Linux machine supporting nested virtualization(difficult on a Mac), ample memory, and the node images downloaded by kubevirtci. Since Prow test lanes run these tests on your behalf for PRs, you can start by running only unit tests on your local machine and reading the test lane results for functional tests.

8. Limitations

• Prow lane names and counts, and exact merge conditions for tide, are in the kubevirt/project-infra repository and were not opened this time (unverified).
• ). Alias personnel counts reflect files at the time of v1.9.0 and may differ in main.
• Build and test durations are unmeasured.

Tidbit from Tito. The smaller your first PR, the better. One file, one test, one paragraph explaining why you changed it! And review comments aren't attacks—they're filling in the blanks on the map. Just say thanks and fix them one by one!

References

All accessed on 2026-10-17.

• CONTRIBUTING.md: https://github.com/kubevirt/kubevirt/blob/v1.9.0/CONTRIBUTING.md
• Review Guide: https://github.com/kubevirt/kubevirt/blob/v1.9.0/docs/reviewer-guide.md
• Commit Message Conventions: https://github.com/kubevirt/kubevirt/blob/v1.9.0/docs/commit-message-guidelines.md
• PR Template: https://github.com/kubevirt/kubevirt/blob/v1.9.0/.github/PULL_REQUEST_TEMPLATE.md
• Prow Command List: https://prow.ci.kubevirt.io/command-help
• KubeVirt AI Contribution Policy: https://github.com/kubevirt/community/blob/main/ai-contribution-policy.md
• Development Guide (Testing): https://github.com/kubevirt/kubevirt/blob/v1.9.0/docs/getting-started.md