In this article
Proxmox separates three questions that are easy to conflate:
- Are you correcting existing documentation or proposing new content?
- Is the new material setup-specific or generally useful?
- Does the information apply only to a particular Proxmox VE version or CPU architecture?
The first question separates corrections from new contributions. For new content, the second distinguishes the wiki from the reference documentation. Version and architecture define how broadly a claim should be stated; they do not erase the distinction between a correction, a tutorial, and general reference material.
The documented destinations
| Contribution | Documented destination | Applicability note |
|---|---|---|
| Correction or improvement to existing documentation | Proxmox bug tracker[^1] | Identify the relevant version or architecture when known |
| New content about a specific setup, how-to, or tutorial | Proxmox wiki[^1] | State important setup boundaries |
| New, generally useful information about installing, configuring, using, or troubleshooting Proxmox VE | Reference documentation[^1] | Do not imply support beyond the versions or architectures covered by the evidence |
| Material affected by an arm64-specific difference | Destination depends on whether it is a correction, tutorial, or general reference contribution | State the architecture qualification explicitly[^3] |
The important first step is to decide whether the proposed change corrects existing documentation or adds new material. Only after identifying it as new content does the wiki-versus-reference distinction become the main routing question.[^1]
Corrections go through the bug tracker
If you find an error or another opportunity to improve existing Proxmox VE documentation, the administration guide says to file a bug to propose the correction.[^1]
Topic alone therefore does not determine the destination. An incorrect statement about a particular setup remains a correction if it already appears in the documentation. Conversely, a new tutorial does not become reference material merely because it covers an important feature.
This rule establishes where Proxmox directs correction proposals. The cited page does not specify review times, prioritization, or an acceptance guarantee.
Use the wiki for specific instructional content
For new content, Proxmox identifies the wiki as the appropriate destination for:
- Specific setups
- How-to guides
- Tutorials[^1]
These categories cover material organized around implementing a particular setup or completing a defined task. Commands alone do not settle the classification: both tutorials and reference pages can explain installation or configuration. The documented distinction is between specific instructional material and general information intended to help all users.[^1]
Some proposals may fall near the boundary. A narrowly scoped example could support a broader reference section, while a long, end-to-end deployment guide may fit the wiki more naturally. The administration guide provides the categories but does not define how every borderline proposal will be classified.
Use the reference documentation for generally useful material
Proxmox directs general content that will be helpful to all users toward the reference documentation. It specifically includes information about installing, configuring, using, and troubleshooting Proxmox VE features.[^1]
The basic distinction is:
- A particular setup, how-to, or tutorial points toward the wiki.
- A generally useful explanation of a Proxmox VE feature points toward the reference documentation.[^1]
“Helpful to all users” is a routing criterion, not proof that an instruction applies unchanged to every release or architecture. A broadly useful contribution can still require an explicit version or platform qualification.
The guide also says the reference documentation uses AsciiDoc and directs prospective editors to the pve-docs Git repository and its README.adoc.[^1] That is the extent of the repository guidance established by the cited page; it does not document a complete review or merge workflow.
State version applicability explicitly
A versioned administration guide is evidence for the version it describes, not automatically for current or later releases.
For example, the guide under the /pve-docs-6/ path contains material explicitly referring to Proxmox VE 6.x.[^2] Claims drawn from it should use wording such as:
The Proxmox VE 6.x administration guide states…
Or:
This observation is limited to the versioned Proxmox VE 6.x documentation.
That source alone does not show that the same behavior applies to newer releases. It also does not establish when a feature was introduced, changed, or removed. A difference between a versioned guide and another page is insufficient evidence for reconstructing release chronology.
Likewise, material from the unversioned administration guide should be described as coming from the current documentation, rather than generalized across every historical Proxmox VE release.
Add architecture qualifications when they matter
For the arm64 release described in the Proxmox roadmap, configuration, tooling, and documentation are said to be identical to x86-64 except for a small set of architecture-specific differences.[^3] That exception matters: it rules out an unconditional claim that every instruction applies identically across both architectures.
The roadmap identifies several differences:
- arm64 hosts must boot through UEFI and describe their hardware through ACPI.[^3]
- Device-tree-only single-board computers, including Raspberry Pi, are not supported.[^3]
- SeaBIOS for virtual machines, AMD SEV, and Intel GVT-g are unavailable on arm64.[^3]
- Live migration is possible only between nodes of the same architecture.[^3]
These are examples from the roadmap, not an exhaustive list of every architecture-specific difference.
A suitable broad qualification is:
Proxmox describes the arm64 and x86-64 documentation as shared, subject to architecture-specific differences.[^3]
When a known difference affects the instruction, be more direct:
This instruction assumes x86-64 because it uses SeaBIOS, which the arm64 roadmap identifies as unavailable.[^3]
Version and architecture are separate dimensions. Evidence from the Proxmox VE 6.x guide is version-specific; it does not by itself establish arm64 applicability. Similarly, the roadmap’s arm64 guidance does not establish identical behavior across every software version.
A compact decision rule
Use this sequence:
- Existing error or improvement: propose a correction through the bug tracker.[^1]
- New specific setup, how-to, or tutorial: use the wiki.[^1]
- New generally useful feature material: propose it for the reference documentation.[^1]
- Versioned or architecture-dependent information: state the limitation beside the relevant claim.[^2][^3]
This classification describes the contribution surfaces documented by Proxmox. It does not promise acceptance or establish undocumented review procedures. No hands-on test or contribution submission was performed.
Sources
[^1]: Proxmox VE Administration Guide, “Improving the Proxmox VE Documentation”
[^2]: Versioned Proxmox VE 6.x Administration Guide
[^3]: Proxmox VE Roadmap, “Highlights”
No comments yet