coderit/hackathon-manager

All-in-one platform for hackathon registration & logistics.

hackathon-manager's Issues

Migrate to mountable engine

Right now it's a "full" engine that lives in the same namespace as the host Rails app. "full" makes the transition easier, but it should be moved to a mountable engine before an official release.

This will also require some changes in order for other gems to support this, such as Devise.

Add support for automatic email upon being waitlisted

Same as how an email is sent when someone's accepted, the same functionality should be added for waitlist status

Improve SASS variables

Right now we just use $primary and $secondary. It'd probably be more useful to have things like $page-background, $div-background, $button-background, $link-color, etc

Copy over tests

Tests are still on the main BrickHack repo - everything should be moved over to this repo

More visual confirmation of updating RSVP status

Don't send follow-up emails to admins

Steps to reproduce:

1. Create a new account & application
2. Promote the new account to an admin through the UI (which deletes their questionnaire)

This causes a follow-up email to be sent, reminding the user to fill out their (in-complete) application. However, an admin obviously won't be completing their application since it was deleted.

The follow-up job should be halted if the user is an admin. Should just be another check here: https://github.com/codeRIT/hackathon_manager/blob/master/app/mailers/mailer.rb#L43

Link school seeds into `rails db:seed`

I copied over the database seeds in db/ from BrickHack, but they don't actually get pulled into the parent application - so running bin/rails db:seed ends up not doing anything.

Looks like there's an easy solution according to https://stackoverflow.com/questions/12821550/rails-engine-how-to-use-seed - my guess is we just need to add HackathonManager::Engine.load_seed to https://github.com/codeRIT/hackathon_manager/blob/master/lib/hackathon_manager/engine.rb

Validation:

• Running rails db:seed in the wichacks repo will result in several thousand schools being imported (usually takes ~30 seconds).
• Removing the existing seeds from the brickhack repo and running rails db:seed will do the same

Use official MLH school list

MLH maintains a manually-verified list of schools, available at https://github.com/MLH/mlh-policies/blob/master/schools.csv

This list doesn't include city/state information, which is needed to generate the applicant map. Could probably use our existing school data to add to MLH's list where possible, and leave other school's city/state blank for now.

Show duplicate school name mappings on school detail page

Various misspellings of school names get re-mapped to the correctly-named school, however the data behind this is hidden. A table should be shown on the school detail page that shows which names are mapped to the specific school being shown.

Rename "Sign up with MyMLH" to "Continue with MyMLH"

Saw the "Continue" wording recently on another website and thought of it as an interesting solution to the problem: both the "Sign up with" and "Sign in with" buttons lead to the exact same page/flow.

Customizable dashboard chart colors

Right now the chart colors are hard-coded in a chartkick.rb initializer for BrickHack colors, which can't be customized. Instead they should be customizable per-hackathon.

As a bus captain, I should be able to search for applicants

From @sman591 on February 17, 2016 22:28

For liability reasons, we can only let students board if they've signed the BrickHack agreement.

We should provide a way for bus captains to check if someone's registered and therefore allowed to board the bus.

Copied from original issue: codeRIT/brickhack.io#363

New management UI

The management UI should operate separately from the public, user-facing UI.

• Makes user-facing UI changes much easier to make (don't have to worry about the admin)
• Simplifies variability in admin across hackathons - style variables no longer have to work perfectly across user and admin UIs
• Complexity of admin UI doesn't have to be supported by user-facing UI
• Admin UI can take full advantage of a UI framework, such as bootstrap, for easier maintenance (would help #8)

Copy My MLH dropdown values to local form

When MyMLH was originally integrated, the dropdown/select inputs were removed in favor of a generic text input, under the thought that MyMLH's dropdown values could change at any time and we wouldn't want to be dependent on always syncing up between the two.

However, now that users can apply without using MyMLH, filling out fields like "Level of Study" become extremely open-ended and vague without a dropdown to choose from.

I think giving the user some sort of guidance with a dropdown is ultimately better than worrying about MyMLH and our forms getting out of sync; we just won't be able to enforce validation on the inputs.

Add docs for easy local development

Eg, how to work on feature development alongside the brickhack repo

Enable attendees to sign up for *any* bus during RSVP

Instead of being dedicated one just the one bus a school is associated to, enable everyone to see a list of busses and optionally sign up for one.

Requires significant code/DB changes plus a careful migration.

Old:

• School has bus_list_id association
• Questionnaire has riding_bus boolean
• Know if someone's riding by having riding_bus + their school has a bus list

New:

• Questionnaire has bus_list_id association
• Know if someone's riding a bus by presence of bus_list_id

Add generators

Required files should be generated during gem installation/setup.

• config/hackathon.yml defer to #14
• app/assets/stylesheets/variable-overrides.sass
• school DB seeds - #36
• Add default root to: in config/routes.rb

As an applicant, I should be able to remove my resume during the application process

From @sman591 on February 15, 2016 0:15

If an applicant uploads a resume, they should be able to remove it without restarting the application process.

Copied from original issue: codeRIT/brickhack.io#350

Users are making duplicate MyMLH accounts when trying to RSVP

From @sman591 on January 27, 2017 3:36

This could partially be fixed by #366. However the issue still exists: people click an RSVP link, or just simply log in, and at some point in the My MLH process they make a new account instead of signing back in.

This may be an issue with the UX of MyMLH, but I feel there are steps we can take to minimize the issue without significantly degrading UX.

At a minimum, there should be something added to the admin section that flags these sorts of users so organizers can know it's happening and fix it.

Copied from original issue: codeRIT/brickhack.io#458

New user-facing UI

UI changes to match upcoming BrickHack design, but generalized for anything

Automatically remind people to RSVP

From @sman591 on February 1, 2017 20:0

Just like we send follow-up emails for anyone that hasn't finished their application, we should send a follow-up email to those who haven't RSVP'd yet.

Loosely based on the following rules:

• Send follow-up 7 days after they were accepted (if signed up > 2 weeks before event)
• Send follow-up 5 days before event (if signed up > 10 days before event)
• Send follow-up 2 days before event (if signed up > 3 days before event)

Copied from original issue: codeRIT/brickhack.io#472

Auth via MLH occasionally fails on first few tries

From @sman591 on January 7, 2017 5:48

If the time between browser sessions is long enough, the user gets logged out automatically. However, logging in afterwards via MyMLH fails the first try, but clicking sign in the second time works.

Copied from original issue: codeRIT/brickhack.io#436

Replace BrickHack text with config variables

Things like:

• Hackathon logo
• Hackathon name
• Hackathon date
• Site title
• Agreement PDFs
• Email logo and/or layout custom logo can be defined by a custom template
• And more...

One-click RSVPs without logging in

From @sman591 on February 18, 2016 18:30

I think it's safe to have email token-based authentication, with a time window where that token is active. This would likely simplify the RSVP process a lot.

Copied from original issue: codeRIT/brickhack.io#366

Show exact school locations on interactive map

Right now, we display a high-level overview of where applicants are applying from, as well as the quantity.

However, if this were an interactive map (e.g. Google Maps overlay), this map could be zoomed in to see:

• Exact location of applicants for planning bus routes
• Visibility into which schools have a bus list active for them

For example: University Abc has a bus, but just down the road is another school with 5 applicants. Right now it's hard for someone to connect the dots, but if this was more precisely visible on a map, someone could see the close distance and be sure to reach out to those students about the bus.

Add message recipient option for all non-checked-in attendees

Or a non-checked-in per acceptance status

Show open & spam stats on sent emails

From @sman591 on March 29, 2017 17:31

Providing simple statistics - such as email opens and clicks - can be super helpful when tracking the performance of the emails we send. This should be easy if we:

• Include campaign IDs in our emails (requires moving from SMTP to Sparkpost's API, #393)
• Cache email events from Sparkpost (since Sparkpost doesn't keep events, #494)

Copied from original issue: codeRIT/brickhack.io#495

Create core layout for user-facing content

Things like the application, RSVP, and bus list pages. Right now it's just a bare sidebar with two buttons and a logo, with minimal customization

Refactor management layout

It's a bit cluttered, and pages beyond the main dashboard don't have a perfect layout hierarchy/flow.

Maintain live copy of resumes & links

From @sman591 on September 14, 2016 7:17

We're offering our sponsors the option for early access to attendee resumes & links. To make this easy, the process of maintaining the Google Drive folder of shared resumes & links should be automated - or maybe just a customized portal on the website, as to not deal with Google Drive's APIs?

Copied from original issue: codeRIT/brickhack.io#394

Promote users to admin without requiring them to apply

E.g. with a "users" tab instead of just "questionnaires"

Benefits:

• Enable admins to see what accounts exist but don't have applications yet, and mange them
• Can promote accounts to admin status without having an application

Move protected environment variables to DB or Redis

Things like the Slack invite URL and carpool doc link should be easier to customize than requiring a dev to update an environment variable

Publish as a gem

Flashes show up twice on questionnaire page

As an applicant, if I visit the RSVP page and get redirected, I should know why

From @sman591 on March 3, 2016 3:33

Copied from original issue: codeRIT/brickhack.io#383

Denying someone should include reason for denial

From @sman591 on February 23, 2016 21:52

Right now, our denial emails are a bit generic and emphasize our large number of applicants. This is true for most of our applicants, however for some, they are denied for other reasons (such as age requirement).

We should provide the ability to specify a reason - such as a predefined list of "over capacity" or "age", as well as the option to provide a custom reason

Copied from original issue: codeRIT/brickhack.io#374

Add basic readme docs

The readme is currently the default gem readme, which isn't useful and doesn't describe what this is

Denied status shows thank you message

As an admin, I'd like to see a history of actions made to a user's application

From @sman591 on November 12, 2015 23:18

It'd be cool if we could see an audit log for a user's application/questionnaire. Things such as:

• Account created
• Questionnaire completed
• Questionnaire updated (list which columns and/or values updated)
• Questionnaire status (accepted, denied, waitlisted) updated
• RSVP status updated
• Signed up for bus

With each of the logged actions, the user that made the action and timestamp should be saved.

Could be useful in the event something were to go wrong with someone's application, and could be used to analyze use trends if anyone wanted to analyze the data.

Copied from original issue: codeRIT/brickhack.io#258

Configure settings from UI instead of YAML file

For configuring things that change more frequently. We currently have a hackathon.yml config that provides more static information (hackathon name, logic, etc), however there also exist things that are more variable:

• Slack invite URL
• Carpool doc link
• Contact information (general, travel #53, sponsorship)
• Sponsorship PDF link
• More...

Adding a simple admin UI + easy to use Ruby interface would make this much more accessible to non-devs, possibly even for some of the hackathon.yml variables.

Integrate CI testing

Probably on Travis like we have for BrickHack

Switch to ActiveJob /w Sidekiq backend for job processing

From @sman591 on January 7, 2016 16:37

Rails 4.2 introduced ActiveJob. Due to the current timeline I'm not upgrading us to it right now, but its something to look into for the future. I found a great guide here.

Copied from original issue: codeRIT/brickhack.io#285

Move all sass into hackathon_manager namespace

And rename variable-overrides.sass to something more hackathon_manager-specific - like hackathon_manager-overrides.sass maybe

This eliminates the potential for app-specific files to conflict with hackathon manager's files

Reduce AWS gem dependencies

Version 3 of the AWS gem moved every service-specific API into separate gems. We still depend on the generic aws-sdk, which includes all of the gems, except we really only need one (aws-sdk-s3 for resume PDF storage)

Add strong parameter tests

From @sman591 on October 20, 2016 6:28

With the move to strong parameters, the tests against mass assignment were removed. Testing against correct strong parameters should be added, and is simplified with shoulda: https://github.com/thoughtbot/shoulda-matchers/blob/master/lib/shoulda/matchers/action_controller/permit_matcher.rb

Copied from original issue: codeRIT/brickhack.io#411

Slim down stylesheets and javascript

There's likely a lot of assets, styles, etc that are BrickHack-specific, and shouldn't be included in this gem

Login page does not display errors

From @sman591 on January 11, 2015 7:29

If the user submits a blank login form, or submits incorrect information, an error message should display. However, this is not the case.

Both devise_error_messages! and f.error_notification return nothing, and resource.errors.empty? is true.

Copied from original issue: codeRIT/brickhack.io#57

Highlight "Dietary restrictions" field on Questionnaire admin

From @sman591 on February 2, 2017 2:0

So people at registration don't miss it

Copied from original issue: codeRIT/brickhack.io#473

Establish consistent display of alerts/notices on all pages

Right now, every single template has to implement support for Rails flashes (eg = flash[:notice] or = flash[:alert]). This causes inconsistent appearance, as well as causes some alerts to not be shown until navigating to a page that implements flashes.

With the new user-facing design coming in #48, there's a great chance to have this normalized to something that shows up on all pages, eliminating the requirement of having it implemented in each individual template file.

Cache email events for open & spam stats

From @sman591 on March 29, 2017 17:27

Sparkpost's API provides a very limited history of events - only up to 10 days or 1000 events, which we easily exceed when sending out bulk emails.

We can easily track these events by opening a webhook that Sparkpost notifies when new events come in.

By doing so, we can display stats like:

• Open rate
• Spam rate
• Unsubscribe rate
• Others?

Providing simple statistics - such as email opens and clicks - can be super helpful when tracking the performance of the emails we send.

Copied from original issue: codeRIT/brickhack.io#494