How camp allocates Moodle component names ("frankenstyle", e.g.
mod_example), what happens when two plugins want the same one,
and how disputes are resolved. This operationalizes RFC §8 (component
namespace) and §9 (governance). Modeled loosely on PyPI's PEP 541 and
npm's package-name dispute policy, scaled to this ecosystem.
Moodle component names are a flat namespace: a site cannot install two
plugins with the same component, the index keys every listing by
component (plugins/<type>/<component>.yml), and the client and Composer
channels resolve installs by component. One listing per name is a
technical constraint, not a policy preference. The moodle.org Plugins
Directory historically acted as the name registry and its approval queue
caught collisions before they shipped; with that gone, collisions arrive
here. The registry's first collision (July 2026) involved two unrelated
plugins that independently chose the same name.
Before naming a new plugin, search camp-registry.org for the component name you want. The registry is now the ecosystem's de facto availability check.
-
Discovery is not reservation. A Tier 0 listing exists because the scanner found a public repository. It records that a repo uses a name; it does not grant the name. Crawl order allocates nothing. (Precedent: a seeded listing that had raced to a fork was later repointed to the plugin's canonical repository.)
-
Names are earned by publication, held by use. The strength of a party's stake in a name, in increasing order:
- a public repository using the name (Tier 0, informational only);
- a claimed listing (Tier 1, accountability established);
- verified releases through the registry (Tier 2+);
- a real install base: sites that would break if the name changed.
The registry allocates a contested name to the party with the materially stronger stake; between comparable stakes, first to publish a working release under the name prevails.
-
A claim is not a transfer. Claiming a listing requires control of the listed source repository. A claim from a different repository that happens to use the same component name is not a claim; it is a collision, and it routes to the process below. This closes both doors: squatting (reserve a name by creating a repo) and claim-jumping (take a name by claiming someone else's listing).
-
Disputes are resolved publicly (RFC §8): in issues on camp-index, labelled
name-dispute, decided by the review board (during bootstrap, by the maintainers), with the reasoning written down either way. No private adjudication. -
Renaming is the cheap exit. Before a plugin has an install base, a component rename costs almost nothing; afterwards it breaks upgrades for every site running it. Collisions are therefore resolved eagerly, at claim time rather than after distribution, and the party that renames gets help with the mechanics and keeps its listing under the new name.
Detection. A collision is recorded when the scanner finds a second
repository declaring an already-listed component, or when anyone reports
one. The colliding repository is never silently dropped: it is noted on
the ledger and a name-dispute issue is opened on camp-index.
Case A: the listed party is an unclaimed Tier 0. The registry posts a notice issue on the listed repository explaining the collision and the options (keep-and-dispute, rename, or request removal), with a 14-day response window.
- No response, or the listed party concedes: the name is uncontested.
The listing's
sourceis repointed to the other project on a verified claim; the previous repository may list under a different component name at any time. - The listed party wants the name: proceed to Case B.
Case B: both parties actively want the name. The review board
decides in the public name-dispute issue, weighing in roughly this
order:
- install base and distribution under the name (strongest);
- verified releases through the registry;
- first public working release under the name (tag date of the earliest installable release, not repository creation date);
- evidence the project is a maintained, working plugin (activity, maturity, responsiveness);
- bad faith disqualifies outright: reserving names without a working plugin, mass registration, registering a name to block or impersonate another project, or typosquatting (RFC §8's similarity check applies to new names generally).
The criteria are ordered, not mechanical: the board may depart from them with written reasons (e.g. an earlier tag from an abandoned experiment does not outweigh a maintained plugin with users).
Aftermath. The losing party renames; the registry assists and lists
the renamed plugin normally. The resolution stays linked from the
name-dispute issue. Decisions can be revisited if made on facts that
turn out to be wrong.
Utility listings (RFC §4.8) name themselves with plain lowercase slugs (moosh, moodle-docker) in a namespace separate from frankenstyle components: the trees (utilities/ vs plugins/), page URLs (/utility/ vs /plugin/), and keys never intersect, so no future Moodle plugin type can collide with a utility slug structurally. Within the utility namespace, first established wins, with the same dispute procedure as components. A slug should be the name the tool's own community uses for it; the registry does not arbitrate between a tool and an unrelated project elsewhere that shares its name, only between camp listings.
A component name may not be held by anything that is not a working
plugin. The board may reclaim a name whose listing exists only to occupy
it. Departed authors are the exception, by standing policy: a maintainer
who leaves via status: moved keeps their component name against their
return (AUTHORS.md). Published history is a real stake; an empty repo is
not.