cs169 / audience1st

A zero-installation, zero-maintenance, open-source, all-in-one system for ticketing, subscriptions, development, and backoffice functions, designed expressly for the needs, budgets and constraints of small to medium community theaters.

Spring 24 Team Badges

Audience1st was written by Armando Fox with contributions from: Abhinav Dhulipala, Xiao Fu, Matthew Fyke, Jasper Gan, CiCi Huang, Xu Huang, Xiaoyu Alan He, Anthony Jang, Kyle Khus, Wayne Leung, Autumn Li, Yowsean Li, Anthony Ling, Jason Lum, Sanket Padmanabhan, Andrew Sun, Tanji Saraf-Chavez, Jack Wan, Alex Wang, Kevin Yen, Casper Yang, Hang (Arthur) Yin, and Justin Wong

This information is for developers and deployers

Perhaps you intended to learn about Audience1st features and/or have us install and host it for you?

You only need the information in this repo and its wiki if you are deploying and maintaining Audience1st yourself. If so, the wiki assumes you are IT-savvy and provides the information needed to help you get this Rails ~>4 / Ruby ~>2 app deployed.

The high order bits for developers:

• You need Rails ~>4 and Ruby ~>2.

• You need a Stripe account, though you can use just the test-mode keys during development.

• Audience1st is designed for multi-tenancy, and by default uses Heroku Postgres schemas per tenant. The wiki includes instructions on how to make multi-tenancy work with non-Postgres databases or disable it entirely.

• Audience1st uses Sendgrid to send transactional emails, using ActionMailer pointed at the Sendgrid SMTP server. However, you can easily disable transactional email even in production, so you don't need a Sendgrid account.

Want to help with hosting or front-line customer support?

We want to make it appealing for as many small-to-medium-sized nonprofit theaters as possible to adopt Audience1st. That involves customer/tech support, onboarding, and many other crucial but nontechnical roles. Contact me if you want to help!

Want to contribute? Found a bug?

That'd be great! I use Pivotal Tracker project (not GitHub Issues) to manage the project. Contact me if you want to help, there's lots to do.

1. Fork the repo and make your changes on a branch.

2. Changes must include good comments, 100% test coverage (a combination of RSpec and Cucumber is fine, but any change that directly "touches" the UI definitely needs Cucumber scenarios), no net decrease in code quality/maintainability score on CodeClimate. The tests must run and pass in CI. Cucumber scenarios use PhantomJS for headless Javascript testing. There are some Jasmine tests for testing JavaScript detailed behaviors.

3. Rebase against main and open a pull request.

Questions welcome!