Community edition

Every feature, in detail

The long version of the feature list on the project page. Running means built and in use on the beta install today. Planned means designed and scheduled, not started.

The plugin is the management layer. The public site around it is designed and built by hand, per community.

Access and identity

Access

Discord is the source of truth for identity. The plugin keeps its own record alongside it for everything Discord does not hold.

Running

Discord sign in

Members sign in with Discord and never set a password. Someone who already holds Staff in Discord arrives on the staff panel.

  • The roles a member already holds in Discord come across with them
  • Nickname and avatar follow whatever they change in Discord
  • Lose the Discord, lose the site access, at the same moment
  • Nothing to onboard beyond the server invite they already have
Running

Member records and roster

One record per person, holding what Discord does not: when they joined, what state they are in, their number, their hours.

  • Statuses: prospect, applicant, accepted, active, inactive, removed
  • The roster lists every member with their number, status and Discord roles
  • Staff notes sit on the record and are never shown to the member
  • On leave shows as a pill on the roster rather than a separate list
Running

Member numbers

Members request the number they go by in game. The request is checked against every number already taken and held until staff release it.

  • A request is checked against numbers already taken
  • Requested numbers are held until staff release them
  • The number shows on the member’s own hub page and on the roster
  • Freed numbers go back in the pool rather than being lost
Running

Roles and gates

What a member can reach is decided by their Discord roles and the state of their record. A page can require a signed document, an accepted application or a role.

  • A gate can require an accepted application, a signed document or a role
  • A member who fails a gate is told what is missing, not shown a dead end
  • The access checklist on their hub home is the same gate list, in plain words
  • Staff screens sit behind their own gate
Getting people in

Applications, tracks and waves

Four pieces: the form, the track it comes in on, the wave it lands in, and the staff review in between.

Running

Applications

Questions are set per intake, not hard coded. A roleplay server can ask for a character backstory where a raid guild asks for logs.

  • Question types include short text, long text, choice and agreement
  • Required fields, minimum lengths and help text are set per question
  • Answers are stored with the application so a decision can be re-read later
  • Statuses: draft, submitted, in review, accepted, declined, withdrawn
Running

Tracks

More than one way in, each with its own questions. A general track and a staff track can be open at the same time.

  • A general track and a specialist track can run side by side
  • Each track opens and closes on its own schedule
  • The review queue shows which track an application came through
Running

Waves

Applicants are held and admitted together on a launch date. A wave has an opens date, a closes date and a launch date, and anyone accepted in between waits for the launch.

  • A wave has an opens, closes and launch date
  • The countdown to launch sits on the staff overview
  • States: closed, open, in review, admitted, live
  • Applicants can see where their wave is up to without asking
Running

Review

Any staff member can vote and comment on an application, and the reasoning stays next to the decision.

  • Any staff member can leave a vote and a comment
  • Votes are visible to other staff, so it is not one person’s call
  • The queue shows how long each application has been waiting
  • Accepting one moves the member’s record and tells them
Day to day

Inside the hub

Everything below is a section inside the hub, on the community’s own domain.

Running

Member hub

A page on the community’s own site, behind Discord sign in. Home, documents, notifications, feedback, applications, time away and support are sections inside it.

  • Sections: home, documents, notifications, feedback, applications, time away, support
  • Home opens with an access checklist, so a member sees what is outstanding
  • Their member number, status and current wave are on the same screen
  • Staff reach the staff panel through the same rail
Running

Documents and sign off

Rules and policies are versioned. Publishing version 3 asks every member to read and sign again, and the report shows who has not.

  • Publish a new version and every member is asked to read it again
  • A grace period runs before a missing acknowledgement counts against anyone
  • Acknowledgement is matched on version, so a typo fix does not reset everyone
  • Documents can be marked as requiring sign off, or left as reference
Running

Notices and Discord DMs

Decisions and reminders land in the hub, and as a Discord DM if the member allowed one. Nobody hand types them.

  • Notices land in the hub and, when the member allows it, as a Discord DM
  • Members set their own preference for each kind of notice
  • Staff can see which DMs never landed, usually a member with DMs closed
  • Application decisions, document changes and ticket replies all use it
Running

Support tickets

A member raises a problem once, in a thread staff can find again. The queue shows which side it is waiting on.

  • Tickets carry a category, so they can be routed and counted
  • States: open, waiting on member, waiting on staff, resolved, closed
  • The whole thread stays on the ticket, so a handover loses nothing
  • Staff can leave internal notes the member never sees
Running

Time away

A member requests leave with a return date. Staff approve it, the roster shows an On leave pill, and the activity report skips them until they are back.

  • A member says they will be away and for how long
  • Staff approve, decline, cancel or end it
  • Activity requirements stop counting while the leave is approved
  • States: requested, approved, declined, cancelled, ended
Running

Runs inside WordPress

One install, one host, one bill. The hub lives in the same WordPress as the public site, behind the same login and inside the same backup.

  • No second platform and no extra subdomain to point
  • Nothing else to keep patched or pay a seat fee for
  • Backups, SSL and hosting are whatever the site already uses
  • The hub is a shortcode on a page, so it drops into any theme
Hearing from members

Feedback

Polls, votes, and a way to raise something without a name attached.

Running

Anonymous feedback

A true anonymous ballot. Who was eligible and what was answered sit in separate tables, so there is no record to look up later.

  • The site can tell that a member has responded, not what they said
  • Staff see the answers and the response rate, never the pairing
  • A member can send something unprompted, not only answer a question
  • Nothing to turn off later, because the link was never stored
Running

Forms and polls

Build a short form with its own questions and open it to the members who should see it.

  • Useful for a vote, a temperature check or a sign up sheet
  • Questions are set per form, same types as an application
  • A form can be opened and closed without deleting it
  • Staff read the responses on their own screen in the panel
The game side

Game activity

Play on the game server is reported back to the site and attached to the member record.

Running

Activity from in game

A resource on the game server posts sessions back as people play. Two hours on a Tuesday night shows on the member’s profile on Wednesday.

  • Sessions are matched to a member through their game identifier
  • Daily totals per member feed the roster and the reports
  • Staff can see who has not been seen inside the activity window
  • Approved time away is excluded, so nobody is punished for telling you
Running

Servers and identifiers

A community can run more than one server, and all of them report into the same member records.

  • Each server has its own identifier, so sessions are attributed correctly
  • A member can have more than one game identifier on their record
  • Staff can see which servers are reporting and when each last did
  • A quiet server shows up as a gap, not as everyone going inactive
Running it

Staff tools

Staff run the community from the front of the site. No WordPress admin login is handed out.

Running

Staff panel

Everything staff need is in the same hub members use, behind its own gate: overview, members, servers, applications, waves, feedback, documents, tickets and reports.

  • Screens: overview, members, servers, applications, waves, feedback, documents, tickets, reports, settings
  • The overview opens with tiles for what is waiting right now
  • A wave countdown and an applications chart sit on the same screen
  • Nobody needs a wp-admin account to moderate or review
Running

Reports and compliance

Each report is a list of names you can act on: who has not signed the current document, who has not been seen in two weeks.

  • Who has not acknowledged the current version of a document
  • Who has not been seen on the server inside the activity window
  • Who is cleared to play, and who is missing one thing
  • Each row goes straight to that member’s record
Running

Privacy controls

Member counts, rosters and activity are tracked for the people running the community. Nothing about members is public until the community turns it on.

  • Nothing about members is public by default
  • Each community decides what, if anything, is shown outside the hub
  • Anonymous feedback is anonymous in the database, not just on screen
  • Staff notes and internal ticket notes never surface to members
Running

Audit trail

Staff actions are logged, so when a member asks why something happened there is a record rather than a memory.

  • Decisions, status changes and removals are logged
  • Useful during a handover, when the person who did it has moved on
  • Keeps a disagreement about what happened short
Not yet

Planned

Neither of these is running on an install yet. Both have a shape worked out.

Planned

Creator pages in a community

The Creator edition already builds pages for a channel’s characters, servers and the people it plays with. The same pages inside a community install.

  • Character and story pages owned by the member they belong to
  • Server pages that pull their activity from the same data the reports use
  • Cross tagging, so a video or a story attaches to the right people
Planned

Per game integrations

One module per game, each mapping that game’s own identity to the member record.

  • ARK: Survival Ascended is first
  • Discord roles drive the server whitelist, so access follows the record
  • Removing a member removes their access without a second job to remember
Partner

We are looking to partner with current communities

If you run a community or create for one, get in touch. We would rather build this with a few real servers than guess at what they need.