As part of the on-going efforts to help webmakers the world over build & learn together, we’re collecting specs for event infrastructure. The Mozilla event menu is a piece of this, guiding community members to the event formats that best suit their needs and interests.
Once they’ve decided on an event type, organizers need a simple way to write up the event, spread the word, communicate with participants, and track outcomes.
Thanks to conversations with Ben Simon, Jess Klein, Ross Bruniges, Matt Thompson, and others, we’re getting crisper on what features are essential to the Mozilla event infrastructure.
As an initial strawman, I proposed these features:
- super simple event creation & categorization
- easy & secure data portability
- good developer APIs
- participant email capture and ability to mail them
I also think payment support is important, but not essential. At first, I argued strongly for it, because some organizers may need to recoup costs. But perhaps this is addressed by clearer sponsorship options and encouragement to use additional payment services, rather than a core requirement of our event infrastructure.
Another bonus feature is if the tools are already widely used and familiar to our communities. I think this is important for ease-of-use and discovery. For example, my friend Johannes uses Lanyrd to explore interesting upcoming events. Just yesterday he booked tickets to a festival he just discovered on Lanyrd that day. This suggests that if we don’t use popular listing sites, we miss out on potential participants. At the very least, strategic cross-posting should be encouraged.
Ben Simon has written an excellent post in response to the feature requests strawman. In it, he argues for these additional functions:
- Ability for event organizers to organize over time: Communicate with participants before & after an event, plus allow sign-ups for single instances & repeated events
- Groups: Search & find relevant events by geography, theme, skill level, etc.
Both of these are right on the money in terms of what we want our event infrastructure to support.
Big questions we have now are:
- Are the above features the most important?
- Are we missing any?
- And, once the list looks right, how to we deploy/build the infrastructure?
Over the coming weeks, I’m hoping to chat with people who’ve already organized events like the talented Heather Payne in Toronto (check out her upcoming Hive Toronto Pop-Up), Mozilla Kenyans Cliff Argwings & Alex Wafula and Product Dundee’s Jon Rogers & Mike Shorter, as well as people who’ve expressed interested in hosting something like Nick Doiron from CodeforAmerica, Christian Villum from Platform4, and Henrik Sandklef from FSCONS.
I’d like to get feedback on whether we’re prioritizing the right features and what would be helpful for them in future events.
There is also a big effort at the Mozilla Corporation to improve their event infrastructure, and we should definitely sync up & share solutions as much as possible.
3rd Party Audit
In parallel, we’re preparing for an audit of 3rd party event sites.
Considering there are companies that spend all of their time building event platforms, I argue that we should use those services, insofar they meet our needs, rather than coding something from scratch and maxing the bandwidth of our software team.
Ideally, the 3rd party site will feed into make.mozilla.org, a yet-to-be-coded aggregator for all the Mozilla webmaker activities.
On the list to investigate:
- Controlshift (still being built)
- BlueStateDigital (which we currently use for some events and for Mozilla’s membership program)
- also the Mozilla wiki, Where is Mozilla? and other in-house solutions
What other event sites do you really like? What do you use or see other people using well?