Contribution

Whether you are a developer, designer, writer, or just someone who likes using Kubestro, there are many ways to contribute. We welcome contributions of all kinds.

Ecosystem #

The Kubestro ecosystem includes several pieces orbiting around the main project:

• the documentation site
• the components library
• the dashboard panel and the server behind it
• the agents that run the game servers

For now, all of these live in the same Codeberg repository . They may eventually be split out, but that is not the current priority.

How to contribute #

Triage issues and help in discussions #

Check the project issues and discussions . If you see something you can help with, jump in. Helping other users, sharing workarounds, or adding debugging details is useful work.

Create an issue #

Thank you for taking the time to create an issue.

• For bugs, check the reporting bugs guide .
• For feature requests, first verify there is not already an issue or discussion covering the same scope. If the implementation is still fuzzy, start with a discussion in the project forum .

Send a pull request #

We welcome contributions of all kinds.

Before you start #

Before fixing a bug, check whether there is already an issue describing it. If you are working on a feature, open a feature request issue first so maintainers can confirm the direction.

For typo fixes, batching several small fixes into one pull request usually keeps the history cleaner.

Commit conventions #

We use Conventional Commits so a changelog can be generated automatically. If you are not already familiar with the format, read the guide before opening a pull request.

Use fix: and feat: only for actual code changes. For documentation or typo-only changes, prefer docs: or chore:.

• fix: typo should become docs: fix typo

Making the pull request #

If you are not familiar with pull requests on Codeberg, read the guide .

When your pull request resolves an existing issue, mention it in the description with fixes #<issue-number>.

It is fine to have multiple commits in a single pull request. There is no need to rebase or force push for maintainers; the project can squash commits during merge.

Before opening a pull request, make sure the relevant lint and test scripts pass.

Keep pull requests focused. Avoid unrelated whitespace, formatting, or feature changes in the same submission.

Once you have opened a pull request #

Maintainers will review it as quickly as possible. If it is assigned to a maintainer, that person will take point on the review.

AI-assisted contributions #

AI tools can help, but you should remain fully responsible for the code you submit. Review any generated code carefully and understand it before you open a pull request.

We ask contributors to follow two core principles .

Never let an LLM speak for you #

• Write comments, issues, and pull request descriptions in your own voice.
• Clear human communication matters more than perfect grammar.
• Do not paste AI-generated summaries that do not reflect your own understanding.

Never let an LLM think for you #

• Feel free to use AI tools to explore ideas or draft code.
• Only submit contributions you fully understand and can explain.
• Contributions should reflect your own reasoning and problem-solving.

We want the project to stay collaborative and human, even in a time where open source risks being flooded with low-quality AI-generated submissions.

If you have ideas for improving the policy, we would love to hear them.

Documentation style guide #

Documentation should be as intuitive as possible. Here are a few guidelines that help.

• Avoid subjective words like simply, just, or obviously when possible.
• Prefer active voice .