Since 2015 I have been going to regional Burn event – something like Burning Man but smaller and not in a desert – called Firefly. (This is not to be confused with the popular music festival of the same name.)
As part of my participation in the event, I’m co-lead of the Art Grant Core, which is the group of volunteers tasked with giving money to artists for creating and bringing new works to show at the event. Last year we distributed over $30,000 in funds.
While all of our deliberations as a grant committee are done in person, we also use a software portal to collect proposals and organize the meeting. This portal is a custom platform built with Ruby on Rails, and we call it the Firefly Art Grant Portal.
I didn’t know any Ruby when I started working on the platform, and it’s still not my preferred platform, but I’ve been able to wrangle the codebase well enough to fix many of its problems.
- Eliminate pervasive need for database hacking to do basic site setup.
- Countless UX improvements, such as AJAX-y behavior during the voting process to prevent page reloads.
- Sophisticated in-portal management of artist email notifications.
- Recruited and led an Actual Ruby Developer, who did an amazing job revamping the entire codebase in a very short time frame.
- (Fixed all the regressions that the revamp caused, in time for launch.)
- Template-based creation of pdf contracts.
The portal is essentially feature-complete and I am trying not to add much more functionality. There are a few outstanding issues, but I’d like to put it in maintenance mode and just keep up with gem updates.
We have talked to other regional events about using our codebase for their grant processes, but there’s a lot of custom business logic for how we do our meetings.