Plugin submission rules
Every plugin published here follows these rules. Sections A to D are based on Poggit's Plugin Submission Rules, with the same ids, updated for PocketMine-MP 5; E and F are ours.
Rules marked as checked automatically are looked at when you upload; a moderator checks the rest. A moderator who rejects a release cites the rules it breaks.
A. About the plugin
The idea of the plugin. Plugins whose purpose breaks these rules are not accepted.
A1 Complete and useful rejected
The plugin must be complete and serve a purpose. Unfinished parts are fine if they are disabled by default.
A2 A specific purpose rejected
The plugin must serve a specific purpose that is useful to most servers. "Core" plugins made for one private server, and bundles of unrelated features, are not accepted.
A3 No duplicates rejected
If another plugin here already does everything yours does, do not submit yours, unless that one is outdated and unmaintained. Explain in the description what makes yours better.
A4 No remote code execution rejected
External services must be reputable or fully transparent, and the plugin must never be usable as a backdoor. Downloading and running code is forbidden, including auto-updaters that download from anywhere other than this repository.
A5 Payment must be optional rejected
The plugin must be usable without paying, at least by a small server (about 5 players). A paid external service needs a reasonable free plan.
A6 Libraries are virions rejected
Libraries must be published as virions, not as plugins. The only exception are API plugins that make other plugins work together; they need clear documentation for developers.
A7 Only your own plugins rejected
Do not publish plugins written by others without their permission. To take over an abandoned plugin, follow rule F3.
B. About the code
If the code breaks these rules the release is rejected: change the code and upload a new version.
B1 Only released API versions checked automatically rejected
plugin.yml may only list API versions that have been released, and only the earliest one of each major version (5.0.0, not 5.0.0 and 5.3.0).
B2 No obfuscation checked automatically rejected
The code must be readable. Obfuscated or minified code is not accepted.
B3 No useless startup messages checked automatically rejected
Do not print messages such as "plugin enabled" or the author's name on start or stop, and do not add commands that only show the version. Real warnings and errors are fine.
B4 English by default rejected
Translations are welcome, but the default language of messages and configuration must be English.
C. About compatibility
So that plugins work well together. If the code breaks these rules the release is rejected.
C1 A unique namespace checked automatically rejected
Use a namespace like AuthorName\PluginName (never pocketmine). Every class of the plugin, including bundled libraries, must be inside it. Do not change it between versions.
C2 Commands rejected
Commands registered directly in the CommandMap use the plugin name as fallback prefix (not initials), and every command implements PluginOwned.
C3 Permissions checked automatically rejected
Permission names start with the plugin name and only use letters, digits, hyphens and dots.
C4 Events rejected
Choose @priority and @handleCancelled on purpose (NORMAL when unsure), and never change an event at MONITOR priority.
C5 Files and stored data rejected
Only write files inside the plugin's data folder (except plugin managers), do not use chdir(), and keep data the plugin adds to worlds, entities or items under a tag named after its namespace.
D. About the listing
The information on the plugin page. If it breaks these rules the moderator sends it back: fix the form and upload the same file again.
D1 A detailed description checked automatically fix the listing
Explain what the plugin does and why it is useful, without assuming the reader knows the terms.
D2 Description in English fix the listing
The description must be available in English. Translations can follow it.
D3 A clean description fix the listing
Only information about the plugin: no advertising and no unrelated content. A few contact links are fine.
D4 A well formatted description fix the listing
Use Markdown headings, lists and code blocks so the page is easy to read.
D5 An informative changelog checked automatically fix the listing
Every update needs a changelog that says what changed for users, not lines like "Updated README.md".
D6 A proper license checked automatically fix the listing
Choose a real license (an SPDX identifier such as MIT, GPL-3.0 or LGPL-3.0). Informal custom licenses are not accepted.
E. Security and privacy
Server owners must be able to trust what they install. Breaking these rules gets the release removed and can get the account banned.
E1 No malicious behaviour checked automatically rejected
No backdoors, hidden operator or permission grants, crashing or slowing servers on purpose, cryptocurrency mining, or running system programs without a clear and documented reason.
E2 Disclose network access and data checked automatically rejected
If the plugin connects to the internet, say in the description which services, why and what data is sent. Statistics and telemetry must be opt-in or easy to turn off, and must never send IP addresses, XUIDs or chat to third parties without the server owner's consent.
E3 No hidden or generated code checked automatically rejected
No PHP code hidden in non-PHP files, no writing PHP files at run time, no encoded blobs that are decoded and run.
E4 Report vulnerabilities rejected
If you find a security problem in your plugin, publish a fixed version quickly and tell the moderators, so a security advisory can be shown to the servers that use it.
F. Names and ownership
Plugin names are unique and servers download plugins by name, so names are handled with care.
F1 No name squatting rejected
Do not reserve names you do not use, and do not use a name that impersonates another plugin or author. Names that were never approved are freed when their releases are rejected.
F2 Plugins from Poggit rejected
The name of a plugin published on Poggit belongs to its Poggit author. If someone else took it here, the original author can claim it back from the moderators with proof (for example the repository).
F3 Adopting an abandoned plugin rejected
A plugin can be adopted when it has not worked on the latest VanillaMine API for 14 days, or a serious bug has been open for 28 days. Fix it in a fork, offer the fix to the author, and ask the moderators. The author has 7 days to object or publish a fix. The first adopted release may only update the plugin, without new features, and must respect the license.
Based on the Poggit Plugin Submission Rules (A-D) and its adverse possession policy (F3).