Moderate the Rumble

Rumble moderators protect a fair, reviewable competition. GitHub automatically assesses routine bot submissions; Flemming handles uncertain submissions, client registrations, disputes and automation health. There is no hidden admin panel: moderation happens through pull requests and the policy files in rumble-bots and rumble-data.

The repository policies remain authoritative. This guide explains the normal workflow and points to those policies when judgment is required.

Review a bot submission

Bot submissions arrive as pull requests in rumble-bots. A PR that changes exactly one bot directory, passes source and security screening, and completes a full round against a trusted reference is approved and merged by the moderator App. No human action is needed for that result.

When the bot-moderation check stays pending, GitHub comments with the reason and calls for Flemming. Review that case as follows:

1. Read the stated uncertainty and the assessment log. Never merge a submission with a failing check.
2. Confirm that the pull request changes only the author's bot or team entry and does not edit generated catalog files.
3. Check that the directory contains source rather than binaries, generated dependencies, archives, or unrelated files.
4. Confirm that the bot uses an official Bot API and declares an allowed SPDX license.
5. Review restricted-code diagnostics and suspicious or confusable names. Ask the author to resolve anything unclear before approval.
6. For an existing bot name, confirm that the submitting GitHub account owns it and that the version increased when source changed.
7. For a TwinDuel team, confirm that it has two member slots backed by active individual bot versions and contains only its team JSON. Repeated member identities are valid within one twin team.

If a pending case is acceptable, comment /moderation approve <reason> on the current PR commit. This records the human decision and turns the required check green; merge the PR manually. A new commit requires a new assessment. If the bot does not run, GitHub requests changes from its author; do not override that failure. Team metadata and non-bot changes always take the human path. The exact permissions and recovery steps live in rumble-bots/GOVERNANCE.md.

Review a client registration

Client registrations arrive as pull requests in rumble-data.

1. Confirm that the PR adds clients/<account>.json and does not change result facts or generated projections.
2. Check that the filename and account exactly match the submitting GitHub account.
3. Check that clientIds is a non-empty list of stable, non-empty identifiers.
4. Require the Verify Rumble data workflow to pass.
5. Merge after one moderator approval.

Ordinary code, catalog, ban, exclusion, and policy changes in rumble-data follow the same green-CI and one-approval rule. CI is the only writer of accepted facts and generated projections on main.

Handle disputes and abuse

Every action below is a reviewed pull request with the reason recorded in its description. Preserve the facts; change whether they count.

Exclude a disputed result

Add its battleId to rumble-data/exclusions.json. The next aggregation omits it from rankings without deleting the accepted fact. Removing the exclusion restores it on a later recomputation.

Ban an account

Add the GitHub account to bannedAccounts in rumble-data/bans.json. Future submissions are rejected, and earlier facts from that account stop contributing when projections are regenerated.

If the account owns catalog entries, add those entries to disqualifiedBots in the same file. The generated catalog excludes disqualified bots, but their existing result facts remain in history. Bans may be temporary or permanent.

Resolve a suspicious name or submission

The validator detects identical normalized name skeletons and restricted code constructs. Treat the diagnostic as a reason to inspect the submission, not as proof of bad intent. Resolve impersonation, name squatting, unsafe code, licensing complaints, account recovery, and appeals under rumble-bots/GOVERNANCE.md.

Keep the automation healthy

The organization-owned Tank Royale Rumble Moderator App supplies the review and merge identity. Its exact registration fields, repository permissions, installation scope, Actions secrets, branch rule and recovery steps are in the rumble-bots moderator setup.

Result submissions normally trigger ingestion when GitHub applies the result-submission label. A scheduled fallback runs at 17 and 47 minutes past every UTC hour. Catalog checks run at 23 minutes past every UTC hour and skip aggregation when unchanged. Changed writers explicitly request Pages, while a 41-minute-past hourly reconciliation deploys only when the site differs from the latest successful deployment. See Rumble rankings and APS for the public freshness, active-version, and immutable snapshot contract.

If GitHub disables scheduled workflows after repository inactivity, re-enable them. A newly labelled result issue also wakes the ingestion workflow, but moderators should not rely on incoming traffic as the only health check.

Once a month, follow the rumble-data compaction procedure for facts older than three full months. It must produce verified rollups without changing the generated projections before the individual facts move to the archive branch.

Once each quarter, run the fork drill: fork the repositories, enable their workflows and Pages, run validation and aggregation locally, and record the result in a governance issue. The drill proves that another maintainer can recover the Rumble from its public repositories and documentation.

Operational details and decision authority live in rumble-data/GOVERNANCE.md and rumble-bots/GOVERNANCE.md.