Skip to content

/vetting — Slash Command Spec

Not yet implemented. This page is a spec for a planned feature.

Commands

/vetting session new [date] [time] [@attendee ...]
/vetting session timeful

General Notes

Vetting_sessions schema is confirmed. Writable fields relevant to the bot:

  • vetting_datetime — DateTime
  • vettees — ReferenceList("People") — write target for vettees
  • vetting_panel — ReferenceList("People") — write target for panel members
  • no_shows — ReferenceList("People")
  • notes — Text

vettees_person_id is a read-only formula that returns rec.vettees.person_id — it is not a write target. Do not write to it.

Prevetting_vetting_notes is confirmed to contain heavily PII-laden fields (ideology, activism, support system, opsec). No bot access to this table.

/vetting session new [date] [time] [@attendee ...]

Signature

/vetting session new [date] [time] [@attendee @attendee ...]

Access

Representative+

Purpose

Creates a new row in Vetting_sessions for a scheduled vetting session, with panel members and vettees pre-populated.

Parameters

  • date — parsed flexibly, same as /event new
  • time — 12h or 24h format, combined with date into a DateTime for vetting_datetime
  • @attendee — one or more Discord mentions. Bot will need to determine from context or a follow-up param whether each mention is a vettee or a panel member. Two options:
  • Option A: separate params /vetting session new [date] [time] vettees: @a @b panel: @c @d using named param groups
  • Option B: single list, bot asks a follow-up to classify each
  • Recommend Option A — cleaner for the dev and the operator

Pre-flight Checks

  1. All @attendee mentions resolve to $People rows
  2. Panel members have an active officer role (check Discord_users.Officer_roles_role)
  3. Date/time is in the future — warn but don't block if in the past (data backfill case)

Writes

Create new Vetting_sessions row: - vetting_datetime — parsed from date + time params - vettees — list of $People row ids (integers) for vettees. Same ReferenceList pattern as all other people lists in the schema. - vetting_panel — list of $People row ids for panel members - no_shows — omit at creation (empty by default)

Response

Ephemeral:

✅ Vetting session created
  Date: Sat Jun 14 2025, 6:00 PM
  Vettees: @alice, @bob
  Panel: @carol, @dave

/vetting session timeful

Signature

/vetting session timeful

Access

Representative+

Purpose

Surfaces a scheduling link or workflow for finding availability across vettees and panel members for a new session. Exact behavior depends on what tooling your org uses for scheduling (Schej, based on $People.last_schej_RSVP and Availability_provided table references).

Options

Option A — Bot provides a Schej link If new Schej polls cannot be created via API, bot returns a pre-configured link to create a new availability poll manually, with context:

📅 Schedule a vetting session

Create a new Schej poll:
  [link to Schej]

Current vettees awaiting scheduling:
  @alice — in vetting since Mar 3 (104 days)
  @bob — in vetting since Apr 1 (75 days)

Panel members available (have no conflict on file):
  [list from Availability_provided if queryable]

Option B — Bot queries Availability_provided If Availability_provided is accessible to the no-PII Grist user, bot can return current availability data to help pick a time without an external tool.

Recommend Option A to start — avoids dependency on Schej API access and keeps scope tight. Revisit Option B when vetting workflow is being optimized.

Vettees Awaiting Scheduling

Query $People where most_recent_status = "unvetted (ready for vetting)" and Vetting_session_date is null or in the future. Display sorted by start_vetting_datetime ascending (longest waiting first).

Fields to display per vettee: - default_handle / Discord mention - start_vetting_date - days_waiting_for_vetting (pre-computed) - MIA flag — if True, flag prominently: ⚠️ MIA

Vetting Notes Wizard — Deferred

The brain dump mentioned a possible wizard for capturing vetting answer notes in Discord. This is deferred for the following reasons:

  1. Prevetting_vetting_notes schema not yet reviewed
  2. Vetting notes likely contain PII (names, personal details shared during session) — incompatible with the no-PII bot user
  3. The freeform nature of vetting notes makes Discord a poor capture interface vs. Grist directly

Recommendation: Leave vetting notes in Grist. If a lightweight Discord interface is wanted later, revisit after the no-PII access boundary is re-evaluated or a separate higher-privilege bot action is scoped.

Open Questions

  1. Schej API — does Schej expose an API for creating new polls? If yes, /vetting session timeful becomes much more powerful.
  2. No-show logging — should there be a /vetting session noshow [@member] command to log no-shows after the fact? Would PATCH Vetting_sessions.no_shows and potentially trigger a status update in Status_actions.
  3. Status update on vetting completion — passing vetting requires adding a Status_actions row with status="vetted" and the person reference. Flag for a future /vetting pass [@member] command at Representative+ access — the passed_vetting_button action in $People shows exactly what that write looks like.