Discussion: File Moderators and Game Moderators

Discussion: File Moderators and Game Moderators

Type: Enhancement (discussion / scoping)

Area: Files / Games / Moderation / Permissions

Current Behavior:
Moderation on 6502ish is presently scoped to forums only. The forum_moderators table assigns owner and moderator roles per forum, and category_moderators layers a supermod role over an entire category. Neither the Files section nor the Games section has a dedicated moderator role. File issues flow through the existing file_reports table (reasons: corrupt, miscategorized, copyright, other), but resolution is only available to SysOps-level admins. Game listings (c64_games, platform_games, door_games) have no review or flagging mechanism at all — a broken emulator target, a missing thumbnail, or a card with no description sits until an admin happens to notice.

Requested Change:
Open a discussion about adding two new moderator roles, modeled on the existing forum / category moderation pattern, with enough shared infrastructure to avoid building three separate moderation systems.

Roles to consider:

• File Moderator — keeps the /files section in order. Responsibilities would include: triaging file_reports, enforcing categorization and description quality, flagging likely pirated warez or copyright-violating uploads, and either correcting metadata directly or returning an upload to its submitter for fixes.
• Game Moderator — keeps the /games section in order. Responsibilities would include: verifying that games actually launch in the embedded emulator, ensuring each card has a thumbnail and a short description, flagging missing or broken ROM paths, and curating which games surface on platform hub pages.

Open questions for the discussion:

• Should these roles be scoped (e.g. a mod for Atari-ST files only, or for door games only) or global (one pool of file mods across every platform)? The forum system already supports both forum-scoped and category-scoped, which is a useful precedent.
• Should file/game mods be an extension of the existing role hierarchy (a new level between Registered and Moderator) or a per-section membership layered on top of the existing role field, the way forum_moderators works today?
• Do we surface these roles on the user profile the same way forum moderator badges are surfaced now, or keep them back-of-house?
• What's the application / appointment flow? Reuse the existing "Apply to be a Moderator" path from /forums/apply-mod, or a new section-specific form?

A supporting ecosystem would need to be designed alongside the roles themselves:

• Admin oversight — SysOps-level visibility into everything a file/game mod does, with per-mod activity views, and the ability to revoke the role at any time. No moderation action should be invisible to admins.
• Privilege use logging — every mod action (hide, recategorize, delete, restore, approve, request changes) recorded in audit_log with the actor, the target, the reason, and the before/after state. The existing forum-mod audit entries are the model.
• Rollback / undo — soft-delete with a restore path for file and game changes, not hard-delete. A mod who removes a file by mistake should be able to put it back, and an admin should be able to reverse any mod action.
• Issue / appeal reporting — users need a path to flag mod misbehavior (e.g. a file removed with no stated reason), and mods need a path to escalate difficult cases to SysOps. Mirrors the Escalate to SysOps control that already exists for forum mods.
• Moderator application / onboarding — a documented set of expectations (what a mod is and isn't allowed to delete), plus an onboarding checklist so a new mod doesn't immediately break something by action.
• Metrics — a mod-facing dashboard showing queue depth, reports handled, average time-to-resolution — partly to help mods pace themselves, partly so admins can tell when a section is understaffed.

Pros:

• Offloads work from SysOps. Right now a single admin is the only person who can resolve a file_reports row or fix a broken game card. That does not scale.
• The communities who care most about these sections (the file uploaders, the homebrew game authors) are the ones best positioned to spot problems quickly — giving them tools is faster than routing every issue through SysOps.
• Reuses patterns the codebase already has: per-forum moderator table, category-scoped supermod, audit-log conventions, "apply to be a moderator" flow, soft-delete with restore. Very little of this is net-new machinery.
• Makes piracy / copyright takedowns materially faster. A file flagged as warez at 2am doesn't have to wait for a SysOps login to come down.

Cons:

• Moderator burnout and abandonment are real. A mod who vanishes takes their section's queue depth with them; we need a clear policy for reassigning or stripping inactive mods.
• Three moderation models (forum, file, game) means three sets of permission edges to reason about. If they drift apart in semantics, cross-section consistency gets expensive to maintain.
• Game moderation especially is opinionated — "this game doesn't work" can be emulator config, ROM version, user error, or a real problem. Mods will need tooling to reproduce before removing.
• Risk of in-group / out-group friction if mods are chosen badly. Appeal and admin-oversight paths must be built in from day one, not bolted on after the first complaint.
• Audit log volume will grow. The existing audit table already carries forum mod actions; adding file and game mod actions will meaningfully increase write rate and storage growth.

Expected Outcome:
If the proposal moves forward, 6502ish gains two new moderator tiers that mirror the existing forum-moderation pattern, SysOps workload on file and game sections drops significantly, response time on piracy / copyright / quality issues drops from "when an admin sees it" to "when a mod sees it," and the appeal and audit paths ensure nothing a mod does is invisible or unrecoverable.

Notes:
This request is intentionally open-ended — the goal of posting it is to collect opinions on scope (per-platform vs. global), on how the application flow should work, and on which section (Files or Games) should be built first. Please reply with thoughts on any of the open questions above, or on other concerns that aren't yet listed. If the shape of the proposal firms up, a follow-up implementation-focused request will be posted separately.