docs(rfc): add 0010 user flow #15
No reviewers
Labels
No labels
needs/docs
needs/research
needs/upstream
type/bug
type/external
type/feature
type/refactor
urgency
high
urgency
immediate
urgency
low
urgency
medium
No milestone
No project
No assignees
10 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
ScottyLabs/terrier!15
Loading…
Reference in a new issue
No description provided.
Delete branch "rfc/0010-user-flow"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The objective here is to explain the user flow in a way that can inform a more concrete implementation in the future.
Interested in feedback on where this might be unclear or edge cases might exist which I've overlooked.
Todo: create complete list of features, and map the availability of those features to each of the individual “roles.” This should be clearer on expectations and lead to a more straightforward path to implementation.
Will work on this when I get the chance. In the meantime, open to other comments.
This is super helpful for the API. These roles and permissions map perfectly to SLAC (RFC 0009).
A flowchart for role transitions would be great for clarity too. Once the feature mapping in your todo is ready, we can merge and move straight to implementation (at the API-level, at least).
I definitely would like another set of eyes to ensure the document is clear, but I feel it now covers the featureset nicely and can provide a straightforward path to implementation, despite not focusing on implementation details.
Is there anything else (for example, is this something we want to address) we want to do for this RFC? It seems much of the discussion is around how other systems will need to be redefined because of it1. Is this RFC ready to merge?
Example: https://codeberg.org/ScottyLabs/terrier/pulls/15#issuecomment-15932162 ↩︎
docs(rfc): add 0010 user flowto docs(rfc): add 0011 user flowI think we can go to this next after API is finalized, or maybe we should divide up the user flow into separate RFCs...will need to think
Actually, now that I think about this, this one is probably better to finalize first
docs(rfc): add 0011 user flowto docs(rfc): add 0010 user flowre: the
applicant-rejectedquestion, I think we ought to include the role in addition toapplicant-submitted. I think it's expected for applications to be view-only after rejection; in case a hackathon organizer would like to go through the applications afterwards or whatever. It also means we are more flexible in the future and won't have to introduce a new role. Similarlytr-deniedshould be a role (it doesn't make sense to allow editing of the TR info after denying it; I feel like this could cause issues w/ documentation or something in the future).re: communications, I agree with what Krit said in meeting today: email, text, and Discord are most important in that order. I don't think any of them need to be on the initial rollout though -- in the meantime the app should just provide a convenient way to get email lists of a certain role.
re: team size, it should be fluid. "wrong team size" would be such a bad reason for another hackathon to not want to use terrier.
For attendance and check-in: it would be simpler to just let checked-in participants submit regardless of whether the rest of their team has checked in. I could be wrong but I don't really see a reason to require that everyone in the team has checked in. If someone no-shows then they're just not there, doesn't seem like too big a deal?
If an attendee declines after joining a team, they could just be automatically removed from the team. Not quite sure what happens if the leader declines/leaves their team. Maybe just make them select a new leader before they go
For team management, what happens if a team lead doesn't officially drop out but becomes unresponsive? Would other members be able to request a leadership change and if so, I think we would need to have a system to verify the legitimacy of those requests and have an internal process for reviewing and approving them.
Also would teams be allowed to edit their projects before the final deadline? If this is the case, we would need a system to ensure that judges are always evaluating the latest version. How would this be taken care of?
Currently, it seems like the RFC will allow an accepted applicant who has declined their spot (
attendee-declined) to directly switch back toattendee-confirmedwithout requesting for any type of approval. (shown below)If declining releases an accepted applicant's slot to another applicant, likely from the waitlist, the original accepted applicant who had declined should not be able to reconfirm without some form of organizer approval req.
I'm currently not too sure about why the application manager role can allow them to view application drafts. It says that this is for the sake of troubleshooting for participants who have not yet submitted, but will this leave an option for managers to base their decisions on unofficial application details?
@ -0,0 +106,4 @@______________________________________________________________________#### `applicant-rejected`Because application status is already stored and has rejected, the role for applicant-rejected seems unnecessary. Is it being considered as a way to remove the permissions of applicant-submitted?
@ -0,0 +151,4 @@- Confirm attendance (transitions to `attendee-confirmed`)- Decline attendance (transitions to `attendee-declined`)Does this automatically become attendee-declined after a certain deadline set by an admin/organizer?
@ -0,0 +190,4 @@**Features:**- View declined status message- Change attendance status to `attendee-confirmed`There should be a deadline for this, so they can't switch to confirmed last minute.
@ -0,0 +315,4 @@- Team member info (see Open Questions)- View judging results and winners for the company's prize tracks (per-track summaries, easy access to slides/video/repo, clear metric descriptions)- Self-select as a `judge` for any of the company's prize tracks (via scanning the main prize track QR code, with the option to judge only some of the prizes)- Select the winner of their company's prize tracksCan a sponsor and judge choose different winners? Are the different ways of selecting a winner compatible?
@ -0,0 +414,4 @@- **Attendance and check-in:** Confirmed attendees can form teams; participants can submit projects after check-in at any event. Confirm whether this is the intended eligibility rule. Is one checked-in member sufficient for a team submission, or must every member check in? What happens to team membership and submission access when an attendee declines after joining or checking in? Which manual corrections may organizers perform?- **Team management:** The creator is leader, joining uses requests and approval, and users may have one pending request at a time. Can leaders delegate approval or transfer leadership? What happens when a leader or the last member leaves? Who may edit details, remove members, or delete a team? Who may view team details before joining? Do requests expire or reserve capacity, and what happens when eligibility changes? Which corrections may organizers perform?I think leaders should be able to transfer leadership in case they decide to leave the team.
mentioned during work session, but it might be simpler to rely on the oldest
joined_dateto determine who becomes the new leader of the team (so the 2nd oldest always becomes the new leader, and the final member leaving deletes/deactivates the team)Regarding open question #2
Regarding which fields remain editable, I think that things that don't impact whether the application is actually accepted, like name, shirt size, etc) should be able to be edited all the way up until the submission deadline, at which point editing should be closed along with submitting. For the other important fields, like essay questions or resume uploads, if the hackathon accepts based on a rolling basis, then it could be left to the organizers to set a custom date when they lock.
For changes, the application managers could just select specific submission to see using their timestamp as an identifier (saved drafts don't count since they're not part of the application unless the applicant actually submits the draft).
I think waitlisting should be supported since most of the time the application happens a lot earlier than the actual hackathon and plans change (also some peoples' ability to attend could be dependent on them getting a travel stipend). They could probably just have the same permissions as
applicant-rejected, but we might want to call it a different name likeapplicant-waitlisted.View command line instructions
Manual merge helper
Use this merge commit message when completing the merge manually.
Checkout
From your project repository, check out a new branch and test the changes.