You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, organisers check people into an event in the admin platform, but usually manage student/coach pairings separately: often in a spreadsheet or Google Sheet.
That gives us two problems:
Two sources of truth during the event. We sometimes need to reconcile the pairing sheet with the platform to make sure nobody has been missed.
Pairing knowledge is mostly lost between sessions. What an organiser learns about making good pairings in one session isn’t easily available to organisers running another.
I’d like to explore making pairing part of the organiser platform.
The smallest useful version could be very simple: let organisers pair checked-in students and coaches in the platform. That alone removes the second attendance list and gives us a shared workflow we can improve together.
Once we have that, there are interesting things we could build incrementally.
For example, the platform could eventually suggest pairings based on what students want help with, what coaches are comfortable helping with, and potentially previous pairings. A lot of that information is already written as natural language, so an LLM may be useful for interpreting it; although it doesn’t have to be an LLM-based solution.
There are privacy considerations if we involve external models, but I think that’s a solvable design constraint rather than something we need to decide upfront.
The broader goal isn’t really “AI pairing”. It’s to make pairing something the platform can help organisers with and improve over time, rather than a separate process we recreate for every event.
Before thinking too much about implementation, I’d particularly like to understand:
How do other chapters currently do pairing?
What information do you actually use when deciding who to pair?
What makes a pairing good or bad?
Are there things you deliberately optimise for, or avoid?
Would having pairing in the admin platform make running a session easier?
That should give us enough information to work out what the smallest useful version looks like.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Today, organisers check people into an event in the admin platform, but usually manage student/coach pairings separately: often in a spreadsheet or Google Sheet.
That gives us two problems:
I’d like to explore making pairing part of the organiser platform.
The smallest useful version could be very simple: let organisers pair checked-in students and coaches in the platform. That alone removes the second attendance list and gives us a shared workflow we can improve together.
Once we have that, there are interesting things we could build incrementally.
For example, the platform could eventually suggest pairings based on what students want help with, what coaches are comfortable helping with, and potentially previous pairings. A lot of that information is already written as natural language, so an LLM may be useful for interpreting it; although it doesn’t have to be an LLM-based solution.
There are privacy considerations if we involve external models, but I think that’s a solvable design constraint rather than something we need to decide upfront.
The broader goal isn’t really “AI pairing”. It’s to make pairing something the platform can help organisers with and improve over time, rather than a separate process we recreate for every event.
Before thinking too much about implementation, I’d particularly like to understand:
That should give us enough information to work out what the smallest useful version looks like.
All reactions