feat(frontend): improve participant display for owners and participants - #247
Merged
Conversation
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.
This was referenced Aug 27, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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