Flags Laravel Package

Product Decisions This Supports

• Moderation & trust-and-safety roadmap. Flagging is a baseline primitive for any user-generated-content surface. This package informs whether "report content / report user" ships in the next community release or gets deferred.
• Build vs. buy. Choosing between adopting an existing, MIT-licensed flagging extension and commissioning a bespoke report-and-review pipeline. The former is a config-and-configure decision; the latter is a multi-sprint engineering commitment with ongoing ownership cost.
• Feature scoping for the moderator experience. A flagging extension implies a companion workflow: review queue, triage states, moderator assignment, resolution outcomes, and audit trail. Use it to size that adjacent work, not just the "report button."
• Prioritization against community-health metrics. Flag volume, time-to-first-review, repeat-flag rate, and upheld-vs-dismissed ratios become the KPIs that justify (or retire) the investment.
• Compliance and policy posture. A documented, in-product reporting channel supports notice-and-action obligations for harmful or illegal content and gives legal/policy a defensible process artifact.
• Platform upgrade planning. As a Flarum extension, it couples to the host forum version. Adoption creates a recurring "test on upgrade" line item that belongs in the release calendar.
• Support and staffing models. The presence or absence of queue tooling directly affects moderator headcount, on-call rotation, and SLA commitments to the community.

When to Consider This Package

Consider it when:

• You operate — or have committed to operate — a Flarum community. This is not a general-purpose Laravel package; it is a Flarum extension and delivers no value outside that host.
• You need native, in-product reporting rather than routing users to email or an external help desk. Friction in the report flow is the single biggest driver of unreported abuse.
• You want low lock-in and low procurement friction: MIT license, no contract, no per-seat pricing.
• You have, or can assign, PHP/Composer maintenance capability and are comfortable tracking an extension ecosystem rather than a vendor.
• Your community volume is small to mid-scale, where a human-review queue is operationally tractable.

Look elsewhere when:

• You are not on Flarum. Evaluate dedicated moderation or ticketing services instead; do not attempt to port this.
• You need automated classification, toxicity scoring, or ML-assisted triage. This is a workflow tool, not a detection engine.
• You require vendor SLAs, indemnification, or 24/7 support. This is community-maintained software.
• You moderate multiple surfaces (forum plus chat, mobile apps, marketplace). Consolidating into one queue usually argues for a commercial platform.
• You need out-of-the-box moderation analytics or BI export. Assume you build reporting yourself.

Diligence note before committing: the repository is described as a read-only subtree split of the extension. Splits are mirrors, not the distribution channel — confirm the correct install path through Flarum's extension manager and verify whether flags is already bundled with your Flarum version, which would make this a zero-cost toggle rather than an adoption decision. The star count (10) and the future-dated release (2026-10-14) are both unreliable signals for a split repo; validate actual commit activity, issue responsiveness, and compatibility matrix against your pinned Flarum version before it enters the roadmap.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed component that gives our community a built-in way for members to report abusive or off-topic content, and gives our moderators a queue to act on those reports. It is table stakes for operating a user-content platform, not a differentiator — but its absence is a visible safety and compliance gap. Cost is effectively zero in licensing; the real investment is moderator time and a modest amount of engineering to wire up and maintain.

To engineering: It is an official Flarum extension with a narrow surface area, installed and versioned via Composer like the rest of the stack. Treat the linked repository as read-only — do not fork it; changes belong upstream. Pin the version, add an upgrade test to the release checklist, and budget a small allowance each Flarum upgrade for compatibility work.

To policy/legal: It provides a documented, auditable intake path for content reports, which supports our notice-and-action posture. It does not by itself satisfy reporting timelines or transparency obligations — those require process and record-keeping on top.

The ask: Approve adoption on the community platform, confirm the extension's current maintenance health, and assign a named owner for upgrades. No new headcount is implied; the risk is ongoing low-grade maintenance, not a large build.