How We Organized Processing Community Day NYC

The license for this documentation is CC0

This article describes how a team of organizers came together and organized Processing Community Day NYC in 2019. The goal is to provide some insight to those interested in organizing their own local Processing Community Day or for anyone interested in how to hold a conference or other learning event centered on programming, education, art, and activism.

Basic Info

PCD @ NYC

Website: processing.nyc

Organizers: Matilda Wysocki, rebecca (marks) leopold, Rushali Paratey, Saber Khan, Lee Tusman and Todd Anderson. Additional help from Amy Cheng, Cassie Tarakajian, Joey Lee.

February 9, 2019

@ The New School, Eugene Lang

How We Organized Processing Community Day NYC

Processing Community Day NYC 2019 was put together by a team of co-organizers, originally strangers to each other, who began a dialogue and found common interests and goals.

At the beginning, we came together from a few different routes: from a Processing Discourse forum post; from seeing a tweet from one person; and from word of mouth from friends and acquaintances.

One member of the initial group was teaching at a local university and arranged for us to be able to meet there on a Sunday afternoon. Despite most of us not knowing each other at the beginning, we started a dialogue and found common cause and mutual interests. In our first meeting, we talked about how we had initially learned about Processing and our interests. We made this initial list without thoroughly debating or discussing or evaluating them: just a list of areas we were interested in that we wanted to note down. From the beginning it was helpful to take some notes. It’s easy to forget things after a meeting, and our initial notes helped us to later clarify and turn our thoughts into text for a website and call for submissions to present at the event.

We found that we shared common cause and interest around community organizing, toolbuilding, using Processing as a bridge to other languages and frameworks, and joining up with a larger community around code. Many of us were excited about p5.js specifically, and a lot of the group were educators, students, or both. We wanted to learn new technical skills, see what other people were making with Processing/p5.js, and talk about teaching programming. We were interested in art, music, activism, decentralization, and code literacy. In our first meeting, we didn’t formalize anything, but we came up with some specific needs that we wanted to work toward: finding a date for our conference, starting to write text to put out a call for speakers, figuring out what we wanted to have happen on the date, and starting to create a website with a mission.

In an early meeting some folks discussed their experiences at an un-conference, and we discussed what we liked about these kinds of events: the fact that they are participant-driven and responsive to the needs of the community that participates. We also discussed their potential drawbacks: a much higher barrier of entry for beginners without easy on-ramps to participation. Since many of us were united around the welcoming nature of Processing, we decided we would go with a more typical organized / hosted conference format, with some tweaks. We solicited an open call, in order to get a wide variety of talks, and made sure that in our selection we had a variety of different topics and skill levels accounted for. Todd Anderson, one of our organizers, had for years organized an open projector session as part of his monthly WordHack event hosted at Babycastles. In this spirit we added in an “Open Projector” Session to our Processing Community Day as well.

We put out our call in the fall, and gave a 6 week deadline. During that time we put out calls on Twitter, Facebook, and printed flyers we could distribute on campuses and to bring to events. We gave information on the kinds of sessions we were interested in: talks, workshops, and facilitated conversations. This last designation let us include both panel discussions as well as group conversations. We also said to get in contact if someone had an idea that didn’t fit one of these formats. Having a larger group of organizers let us divide up and conquer tasks such as designing a website or writing text. When one person needed to take a backseat for work or family others were able to step in. Because we wanted to make our event friendly for those that might be new to the community, tools, or to these kinds of events, we tried to make the submissions fairly easy. We de-emphasized asking for one’s previous experience and instead tweeted and wrote that we would be happy to help coach those that needed a hand to write a proposal.

When our deadline passed, the organizers spent time alone reviewing proposals, then met as a group to go over them. We made note of which proposals were beginner-friendly, and started the tricky task of honing our selections down. There weren’t any bad proposals, but we needed to be selective because we only were going to hold a 1-day event. We knew we’d have a larger auditorium and a variety of smaller rooms and lecture halls to work with. We also made an early rough estimate that we’d like to shoot for an audience of 125 to 200 people, a pretty broad number, but probably realistic for New York City. We knew we’d be happy with as little as a few dozen attendees, and that we probably didn’t want to organize an event much bigger than a few hundred attendees in our first year.

During our organizing in the fall, we began a dialogue on whether we wanted to get sponsorship. That prompted a discussion on what funding is for. In our case, we wanted to provide a stipend to presenters, organizers, and to provide food and refreshments to those attending. We worked out several different scaled budgets, and brainstormed the kind of funding to look for. Using simple metrics of estimating how much money we needed divided by about how many people we expected would have helped us hone on a ticket price. But luckily we reached a partnership with the Department of Education Computer Science for All (CS4All) initiative. The New School provided hosting support, with additional funding from Code + Liberal Arts at Eugene Lang.

Without this funding, we would have needed to charge an entry fee. We were interested in making this event as open as possible, so we were really thankful for the sponsorship. With this funding, we learned about the Department of Education’s goals, and through this process identified we were both interested in supporting students learning p5.js/Processing and bringing K-12 teachers to be part of a wider community of artists and those working in technology. They also helped promote our call for submissions by sending it out to their list of teachers.

Our budgeting and sponsorship included funding for: breakfast pastries and coffee; boxed lunches; speaker stipends; organizer stipends; donated materials for workshops; planning support; use of campus classrooms and auditorium for meetings and for hosting the event. CS4All also helped supply workshop supplies such as paper and markers, post-it pads, HDMI cables, extension cords, adaptors and lots of little things to make our lives easier. Because our event was free, we struggled with whether to charge a small ticket entry. One argument for doing so is that by making people put a little money up front, they are more likely to show up to the event rather than just sign up and not show up. Ultimately, we decided we’d not charge anything. Instead, we moved our schedule around so that there was at least one large talk/presentation happening all day. Everyone that signed up by a certain deadline was guaranteed to be able to attend, and to be able to participate in at least one workshop. We limited the number of workshop attendees believing that would best support the hands-on approach we favored. We did not use a ticketing service, finding problems with the various options we checked out, so instead created a google form for registration, which seemed to work fine, with the one caveat that it has no built-in way to force registrants to only sign up for a single workshop. We had to manually go in and then contact folks directly who had signed up for more than one and ask them to pick just one.

We had just under 300 folks sign up to attend the conference, and our onsite attendee was about 200 folks attending, though it’s possible there were campus students that joined as well that were not counted for (and that’s fine). We had 24 talks/workshops/discussion sessions, with 3 happening simultaneously most of the day. We recruited volunteers from local universities, and from our website and Twitter, and were lucky to have about 20 people sign up to help, participating in check-in, filming, photographing and assisting workshop presenters.

If you look at our detailed schedule, you’ll see we began the day with a brief Welcome event. At that time the organizers introduced themselves, explained the day’s purpose, our code of conduct, and then gave an overview of the day, before everyone dispersed to different talks and workshops. We met back near the end of the day for a big Open Projector session, and ended with a performance. Because so many of the organizers were educators themselves, and the event was held at a university, and sponsored by the Department of Education we had a large number of students and those working in education. We also hosted a number of people involved in creating art or music with code. Our event was open to and had in attendance both adults as well as a smaller number of children, who were welcome to participate as long as they were accompanied by adults.

After the successful and positive feeling of that day, we were ready to rest a bit. We sent out an optional survey about a week after the event, asking for feedback, and we placed resources from our workshops and talks on the website. One of the areas that felt like it didn’t come together as well as we hoped were in lunchtime meet-up sessions. This was an early idea organizers had that participants could sign-up for informal lunch conversation groups. Going forward, it seems like participants met new friends and formed groups on their own without the need for additional structure on this.

Some ideas to keep in mind based on the first Processing Community Day NYC that seemed to work well:

1. Organize with people you like and trust. Spend at least a few sessions getting to know each other, sharing strengths and weaknesses, hopes and fears. Build goodwill and try to divide up responsibility and tasks.
2. It’s common to underestimate just how much time it takes to organize an event of this scale. Make sure you have a number of hours available to work on this every week, and even more in the month before the event.
3. Put a lot of time into continuing to promote your call for participants.
4. Empower your speakers to help pull in their audiences and networks as well.
5. Determine the size of the event you want to put on, and make backup plans for smaller/larger amounts.
6. Pay attention to the holiday calendar. Put out your call for submissions well before holiday periods.
7. We borrowed an idea from Processing Community Day LA and created a Signal chat group for use on the day of the event that volunteers, organizers and speakers could all join. This let us quickly ask questions, and put out (metaphorical) fires as they arose (“Can anyone help? We need 10 additional chairs moved to ….”).
8. Make sure you build in time on the day of the event for your group organizers to attend talks yourselves. Spread the work around. If you don’t attend some of the talks you’ll feel like you’ve missed the event after the day ends.
9. Include social time. In addition to lunch, we built in some downtime during the day and held an afterparty at a nearby pub.

Hopefully there are some useful ideas for you here. Get in touch with any questions. And follow our Processing Community Day NYC twitter for news including a call for speakers and info on the 2020 event.