Skip to content

feat(frontend): improve participant display for owners and participants - #247

Merged
sabinem merged 1 commit into
mainfrom
feat/improve-participant-display
Aug 26, 2026
Merged

feat(frontend): improve participant display for owners and participants#247
sabinem merged 1 commit into
mainfrom
feat/improve-participant-display

Conversation

@sabinem

@sabinem sabinem commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

As an organizer, I open Manage Participants to approve people and remove people. Until now that page mixed everyone together: applicants waiting to get in sat in the same list as confirmed members, so the count at the top included people who are not in the hackathon yet, and every single row carried a collapsed table of that person's registration answers.

Now there are two tabs. Participants is the confirmed roster — clean rows, and each one links to that person's profile. Waitlist is the queue: the people asking to join, their answers open right there because reading them is how you decide, and Approve or Decline on each. Declining is new; before, the only way to clear an application you did not want was to approve it and then remove them.

As a participant, nothing changed about what I can see about my peers — and I can now read my own registration answers on my own profile, with a note saying only organizers see them and a link to change them.

Details

  • New route participants/manage/waitlist, with a tab bar shared by both halves.
  • Registration answers now live on the participant profile, shown to organizers and to you on your own profile. The roster marks who has not answered.
  • Settings gets a Waitlist tile and the "N waiting" badge moved onto it, since those people are no longer on the Participants page at all.
  • The four membership actions moved into $lib/server/hackathon/participantActions.ts, now that two pages call them.

Manage Participants listed waitlisted applicants alongside confirmed
members and unfolded everyone's registration answers under their row.
So its count included people who are not in the hackathon yet, and a
page whose job is approving and removing people carried a collapsed
table per row.

The applicants move to a Waitlist tab at participants/manage/waitlist.
It keeps the fold-out answers, because reading them is how you decide,
and gains Decline beside Approve — until now the only way to clear an
application you did not want was to approve it and then remove them.
The roster keeps a quiet "No answers" marker and links each row to that
participant's page, which is where the answers are read now: for an
organizer, and for you on your own profile.

Peers still see no answers section. ListParticipantAnswers refuses a
named user_id without hackathon write and silently narrows to the
caller's own answers when none is given, so there is no honest way to
show a participant a peer's answers, and nothing is stubbed for it.

Settings badges the new Waitlist entry with the waiting count, which is
where that badge sat on Manage Participants before.
@sabinem sabinem changed the title feat(frontend): the waitlist gets a tab of its own feat(frontend): improve participant display for owners and participants Aug 26, 2026
@sabinem
sabinem merged commit fb59101 into main Aug 26, 2026
2 checks passed
@sabinem
sabinem deleted the feat/improve-participant-display branch August 26, 2026 09:22
This was referenced Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant