Goals for 2026

HackHelp version 1 was built in 32 days, and as such, had some bugs and shortcomings.

Known Issues

Keep an eye out

Test styles rigorously in dev

Many fixes had to be made day-of due to text wrapping improperly, more tickets in the mentor view than could fit on screen, etc.

Bugs

Users "escaping" past the account setup page

The system was supposed to prevent users from getting to the home page if they had not accepted the invitation to the Github organization. However, there is a bug that allowed a users' state to change. Other API requests would then fail (and they wouldn't be able to see stuff in Github) as they didn't have the requisite permissions.

This was easily resolved by accepting the invitation. Many participants came to the mentor rooms where I (Henrik) was able to resolve it manually. However, not all people who encountered this issue came to get help; some manually granted each other access to repositories. This was possible because when the system created the repo for the team, it gave the team administrator permissions on that repo.

Resolutions

• Make the check more robust, possibly utilize webhooks
• Utilize OAuth to allow the system to accept invitations on the users' behalf
• Do not grant teams administrator permissions on their repos

Wishlist

Ordered by priority, here are the guiding principles behind HackHelp v2 for 2026.

1. De-center GitHub (thus, open up to be used by all event volunteers and participants) This system should work for all event organizers, mentors, and participants. Primary login should be institutional OAuth/OIDC and magiclink/passkey. Users can then link their GitHub accounts if they need code access.

2. Handle sign-up and other information gathering V2 should be able to handle participant signup and collect certain information (like shirt size, dietary restrictions)

3. More Robust System The system should generally have more features and be more robust