Contributing

Table of Contents

• Workflow
• Commit messages
• Before opening a pull request
• Reporting a bug
• Reporting a security problem

Thank you for helping. This page describes how work flows from an idea to the main branch. Code style rules are in Coding conventions.

Workflow

1. Open or pick an issue. Every change starts from a GitHub issue that states the problem or the feature. Large changes are discussed in the issue before any code is written.
2. Create a branch from main. Name it after its topic, for example server-timeout or docs-protocol.
3. Commit small, focused changes following the commit rules below.
4. Open a pull request against main. Describe what changed, why, and how it was tested, and link the issue.
5. Get a review from at least one other team member. Address every comment before merging.
6. Merge once the review is approved and the CI is green.

Important milestones, such as each project delivery, are marked with a Git tag on main.

Commit messages

Commits follow Conventional Commits. The CI checks every commit subject and rejects the pull request if one does not match.

<type>(<scope>): <description>

Rule	Detail
type	One of feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. Lowercase.
scope	Optional, lowercase, names the area: server, client, network, engine, protocol, docs.
description	Required, starts with a lowercase letter, no final period.
Length	The whole subject line is at most 100 characters.
Breaking change	Add ! before the colon, for example feat(protocol)!: add a nonce to hello.

Examples:

feat(server): broadcast monster spawns
fix(network): drop packets with trailing bytes
docs(protocol): describe the snapshot payload

Merge and revert commits generated by Git are accepted as they are.

Before opening a pull request

• The project builds with make from a clean clone.
• The code is formatted with make format.
• Every new or changed public function, class and payload has a documentation comment, and make docs reports no new warning.
• Any change to a message or a payload is reflected in Network protocol specification.
• The change was tested by running a server and at least two clients.

Reporting a bug

Open an issue with:

• what you did, step by step,
• what you expected,
• what happened instead, with the console output of the server and the client,
• your operating system and compiler.

Reporting a security problem

Do not open a public issue for a vulnerability, such as a packet that crashes the server. Contact one of the maintainers privately by email, so that it can be fixed before it is disclosed.