Ruby for Good - CASA
I bought my ticket for “Ruby by the Bay” (West coast Ruby for Good event) on 23 December 2019 and checked the box for willing to be a team lead. I found out what team I would be one of the leaders for on 11 Feb 2019, around 10pm :)
Since then, I’ve been one of the lead maintainers on CASA! I paired with Eric, one of my co-teamleads to run rails new and create the very first models, controllers, and views. Those bones of the app are still there! Sometimes I wish that it were harder to confuse casa_case and case_contact but those are the names of the things. We spent hours all told discussing whether “contact” was the right descriptor. And we spent a painful ~30twenty minutes learning the hard way that rails is NOT happy if you name a model case - hence the name casa_case 😅
Contributors and maintainers have come and gone. It’s important to me that we make it easy and clear that we welcome new contributors and maintainers, and it’s totally ok if someone needs to step back or out, needs to come and go. One of the guiding lights of r4g is to not just produce software, but to help contributors gain skills. Honestly that’s why I chose and continue to choose r4g instead of other projects. Our current active crew is:
- Sean (founder of r4g and very involved in the day to day)
- Polly (r4g coordinator, does a lot of 10k-view work and also helps wrangle heroku/slack/zoom/github permissions)
- Zoe (one of my co-team-leads on CASA from the very beginning, and a really great PM!)
- Jennifer (CASA team lead)
- Jeanine (our newest CASA team lead!) There are LOTS of other people I would like to shoutout here, but honestly no one is going to read it and I have limited time & energy.
Maintaing open source is much easier with a team. And it’s even easier when Sean is there be the backstop and final safety net.
What IS this project? - see our readme or read more about Prince George County CASA (TODO add more here)
What I do, and what I don’t do:
- I don’t try to write all the code!
- I don’t try to get everyone to write the code exactly as I would!
- I don’t review and merge every PR- I have co-maintainers who do a LOT of reviewing and merging!
I do:
- Host weekly “office hours” where contributors can drop in to ask questions, pair program, or just say hi
- Attend weekly stakeholder sync meetings to present our work, ask questions about upcoming works, and stay in touch
- Review and merge PRs
- Set up PR templates and issue templates
- Create “technical” github issues about fixing pending” tests, making new tests for db seeds, making tests for db migrations, making tests for data loads
- Answer questions on slack
- Reply to questions on github
- QA functionality
- Design and create our CI pipeline
- Setup bugsnag, codeclimate, skylight etc integrations
- Sit in on user training
- Put sparkly emojis on everything
- Go thru project board “in progress” column and make sure that the issues aren’t already done (they should be auto-closed by PRs but sometimes are not)
Notable moments
- Pairing w/ Eric on v1 of CASA pre-conference, including laying the bones for multi-tenancy
- Betsy telling me that I should definitely not use Auth0 because it will make contributing harder
- Watching A-a-ron twitch stream pair programming with Sean on CASA and merging their PR while they were still live 😂
- Celebrating a contributor graduating from their bootcamp
- “auctioning off” issues and pairings during r4g remote 2020 - east coast time means that the sun wasn’t up in SF yet!
- “snack” hour during the 2nd remote r4g
- “Power week” prep & execution during my last week of day!job work 😅
- Octoberfest deluge of PRs (yay and also eek)
- Creating the r4g linkedin group before the r4g “company” existed