Commissioning a Minecraft Plugin: Acceptance Criteria
Before commissioning a custom Minecraft plugin, agree on the environment it must support, the behaviour players and staff should see, and the evidence required to accept the delivery. A working demonstration is useful, but the handover should also show what happens after a restart, an unauthorised command or a failed dependency.
For an established community, this turns “we need an event plugin” into a project that can be scoped and checked. The example below is a registration plugin for a single Paper server. It is an illustrative specification, not an existing Mineando product or a tested implementation.
Start with the decision the plugin must make
Describe one complete player journey before listing commands. For example: an eligible player registers for an event, sees confirmation and remains registered after reconnecting. Staff can close registration and inspect the final list. Decide whether cancellation frees a place and whether registration guarantees participation.
Then separate essential behaviour from optional additions. Team assignment, rewards, website registration and Discord notifications are different deliverables. If the first release only needs an in-game registration list, specify that boundary. An existing maintained plugin might already meet it; custom development makes sense when the missing behaviour or integration matters to the project.
Name one person who can resolve ambiguous rules. A developer cannot infer whether a moderator may override a full event or whether a disconnected player should lose a place. Those are operating decisions that change the implementation and its tests.
Freeze the compatibility target
Record the Minecraft version, Paper build, Java runtime, relevant plugins and their versions, plus any proxy or crossplay setup. Give the developer a representative test configuration with secrets removed. State whether the work covers one server or shared state across several servers.
Paper's plugin descriptor documentation explains API version declarations and required dependencies. These declarations help loading decisions; they do not demonstrate that your complete plugin combination works. Ask for a tested compatibility list attached to the delivered release.
For this example, acceptance covers one specified Paper environment. Support for Folia, another server implementation or a future Minecraft release needs an explicit decision and its own verification. Do not turn “Minecraft compatible” into an open-ended assumption.
Write observable acceptance cases
Use a starting state, an action and an expected result. The following cases are proposed requirements for the registration example. Command names and permission nodes should be agreed during implementation.
| Starting state and action | Expected result |
|---|---|
| Registration is open; an eligible player registers. | One entry is stored and the player receives confirmation. |
| The same player repeats the request. | The existing entry is reported; no second place is consumed. |
| Two eligible players request the last place together. | Only one gains the place; the other receives the agreed full-event response. |
| A normal participant tries to close registration. | The action is denied and registration stays open. |
| Staff close registration; another player tries to register. | The request is rejected without changing the list. |
| The server stops normally and starts again. | Confirmed entries and the open or closed state match the agreed persistence rules. |
Use separate test accounts for participant, moderator and administrator. Test denied actions as carefully as permitted ones. Paper documents permission declarations and command permissions; your acceptance check should verify the actual behaviour with the community's permission configuration.
For each case, record the plugin release, setup, steps, expected result, actual result and supporting log or screenshot. Leave the result marked “not run” until someone executes it. A checklist is not evidence by itself.
Specify failure and data boundaries
Decide when the plugin may tell a player that registration succeeded. In this example, require confirmation only after the entry is durably stored. If storage is unavailable, the agreed behaviour could be to reject new registrations with a clear message rather than claim success. The developer must design and demonstrate that behaviour.
Treat a clean restart and an abrupt process failure as separate tests. State which acknowledged entries must survive each, how the interruption will be simulated safely in a test environment and what evidence is needed. Passing a normal restart does not prove crash recovery. Also decide who can export or delete registration data and when old events are removed.
If you add a website or external API, define which system owns the registration list and how retries or duplicate requests are handled. Include the response to timeouts and a way for staff to resolve uncertain outcomes. A single-server acceptance result does not establish consistency across a network.
Slow external calls also need technical care. Paper's scheduling guidance warns about time-consuming work on the main thread and unsafe world access from asynchronous tasks. Ask the developer to explain the boundary; “everything runs asynchronously” is not a sufficient design.
Agree how performance will be assessed
Replace “must not lag” with a repeatable scenario: the agreed number of connected players, registration attempts over a defined interval, representative world activity, hardware, server settings and test duration. Choose measurable limits with the technical team before acceptance. This article supplies no universal player capacity or response-time threshold.
Record a baseline and repeat the scenario with the feature active under comparable conditions. Capture timings, errors and the user-visible result. When investigating a slowdown, collect a profile while it occurs, as the Paper profiling guide requires for useful diagnosis. A quiet-server demonstration cannot stand in for the opening burst.
If the environment itself needs preparation, managed infrastructure can be scoped around deployment, monitoring and load testing. Keep the measured scenario with the release so later changes can be compared fairly.
Make the handover usable by your team
Agree delivery of the versioned JAR, configuration reference, permission list, installation and update instructions, data locations, known limitations and completed acceptance record. Settle source-code access, build instructions and third-party dependency requirements before development starts. These items should be explicit project deliverables.
Document how to return to the previous release. Replacing a JAR may be insufficient if the new version changes stored data; ask for the supported recovery procedure and test it separately. Assign responsibility for deployment and approval of unresolved defects.
For a fixed event date, keep plugin acceptance ahead of the full event rehearsal, leaving time to correct failures. Agree maintenance, future version updates and live support separately.
To discuss custom Minecraft development, bring the player journey, compatibility target, acceptance cases, deadline and budget. Mineando scopes and quotes paid projects individually; these documents make that conversation concrete.
