Conventions and Process
The standards every DPC repository is held to — documentation layout, testing, CI, and release automation.
The organization writes its standards down. DPC Conventions is the repository that holds them, and Medieval Factions is the worked example most of those documents point back at.
The documents
- Two-Tier Documentation — which docs live in the repo and which live in the wiki, and why the split exists.
- Release Automation — a release triggers a build that attaches a JAR.
- Release Channel — whether a server gets published releases or a rolling build of
main, chosen per plugin. - Testing and CI — Gradle for unit tests, Docker Compose for a real server.
The shape of a repository
A repository that follows the conventions has, in its root: README.md, CONTRIBUTING.md, USER_GUIDE.md, COMMANDS.md, CONFIG.md, usually CHANGELOG.md, and a .github/copilot-instructions.md giving coding agents context about the plugin. The presence or absence of those files is the quickest audit of whether a repository has been brought into line.
Why it is centralised
Standards written into one repository can be cited. A note in this zettelkasten that says "DPC plugins document their commands in COMMANDS.md" is a claim, and it needs a source — DPC Conventions is that source. Standards held only in a maintainer's head cannot be cited, verified, or handed to a new contributor.