简体中文
EnglishHow to Contribute to PaperMC Docs
Updated
PaperMC Docs accepts contributions beyond writing documentation: the site's Contribute section thanks people for code, feedback, typo fixes, and shared expertise. If you want to help, the practical path is to find the relevant page or repository, make a focused change or report, and submit it through the project's normal contribution workflow. The docs site itself does not publish a separate contributor form on its welcome page, so treat the Contribute section as an invitation and use the linked project resources to find the exact process.
What Counts as a Contribution
According to the PaperMC Docs welcome page, contributions include:
- Writing or editing code
- Submitting feedback
- Fixing typos
- Sharing expertise
The page frames this as a team effort and thanks contributors directly. That means small fixes are explicitly in scope — you do not need to be a project maintainer to help.
Where to Start
PaperMC Docs covers several projects under the PaperMC umbrella:
| Project | What it is |
|---|---|
| Paper | High-performance Minecraft server that aims to fix gameplay and mechanics inconsistencies |
| Velocity | Modern, next-generation Minecraft server proxy |
| Folia | A fork of Paper adding regionized multithreading to the dedicated server |
| Adventure | Java library for server-controllable UI elements in Minecraft: Java Edition |
| Waterfall | Discontinued BungeeCord proxy fork aimed at performance and stability |
| Miscellaneous | Other documentation and tools |
Pick the project whose docs you actually use. A typo fix or unclear sentence on a page you rely on is the easiest first contribution because you already know what confused you.
A Practical Workflow
- Identify the page and the problem. Note the exact URL and the sentence or section that is wrong, outdated, or unclear.
- Check whether it is a docs issue or a code issue. A wrong command example belongs in the docs; a broken behavior belongs in the relevant project's issue tracker.
- Make the smallest useful change. For a typo or wording fix, edit only that line. For a missing explanation, add a short paragraph with a concrete example.
- Submit through the project's contribution channel. The welcome page does not list a single submission form; use the repository or community links associated with the project you are editing.
- Verify the result. After a change is accepted, reload the published page and confirm the rendered text and any code blocks display correctly.
Common Stumbling Points
- Editing the wrong project. Paper, Velocity, and Folia have separate documentation areas. A fix for a Paper server setting should not be filed against Velocity.
- Assuming Waterfall is active. The docs describe Waterfall as discontinued, so new feature documentation for it is unlikely to be accepted; corrections to existing pages are more plausible.
- Skipping the example. Feedback like "this section is confusing" is harder to act on than "this command fails because the path assumes Linux." Include the specific case.
- Expecting a formal application. The Contribute section is a thank-you and an open invitation, not a registration process. Start with a concrete fix rather than asking for permission.
What to Expect
The site credits contributors for code, feedback, typo fixes, and expertise, so credit is part of the culture. The welcome page does not describe review timelines, contributor tiers, or a formal onboarding program, so do not plan around those. The reliable expectation is that a focused, well-explained change is the kind of contribution the project says it values.
If your goal is simply to report a problem rather than edit text, gather the page URL, the exact wording, and what you expected instead, then send it through the project's community or issue channel. That is feedback in the sense the Contribute section describes.