by Sumana Harihareswara, edited by Kim Wadsworth and Leonard Richardson, Creative Commons Attribution-ShareAlike
Published 9 October 2019, updated early November 2019

This document covers the why and how leading up to The Art of Python at PyCon NA 2019. It's in two parts: "Why I Did This" and "How I Did This".

I cannot be one of the co-organizers for The Art of Python at PyCon North America in 2020; I hope someone else steps forward to lead it so it can take place again. If you want to organize Art of Python at PyCon 2020, please submit a Hatchery proposal as soon as possible. The deadline for Hatchery proposals is January 3, 2020. If you are interested but need help to do it, post about that someplace public -- your blog, Twitter, etc. -- and tell me, and if I hear from multiple people, I'll put you in touch with each other.

I cannot be one of the co-organizers for The Art of Python at PyCon North America in 2020; I hope someone else steps forward to lead it so it can take place again. If you want to organize Art of Python at PyCon 2020, please submit a Hatchery proposal as soon as possible. The deadline for Hatchery proposals is January 3, 2020. If you are interested but need help to do it, post about that someplace public -- your blog, Twitter, etc. -- and tell me, and if I hear from multiple people, I'll put you in touch with each other.

Update, 11 November 2019: Kalila Shapiro and Liz Moy have stepped forward to co-organize "The Art of Python" for PyCon North America 2020; please talk with them if you'd like to volunteer!

Update, 27 December 2019: Actually, Shapiro and Moy are co-organizing a different festival ("No Signal: Python for Computational Art"), more about computer-generated art. If you'd like to co-organize a festival centering art about programming, I hope you will speak up soon!

Update, 2 Jan 2020: Meredith Finkelstein and Kyle R. Conway are proposing "The Art of Python" for PyCon 2020. Thank you!

Update, 19 Nov 2020: PyCon 2020 went virtual due to the pandemic. There are currently no plans for Art of Python at PyCon 2021; if you're interested in changing that, please email the Hatchery folks at pycon-hatchery@python.org!

Update, 3 May 2023: Check out PyGotham TV, online in late October 2023, which will hold an online film festival. Also: At PyCon US 2023, Jacob Kaplan-Moss and I presented our play, "Argument Clinic: What Healthy Professional Conflict Looks Like," as a regular session on the schedule. And the Hatchery hasn't been part of PyCon US for a few years. If you're interested in suggesting that PyCon US 2023 have a dedicated performance arts festival like The Art of Python (maybe call it "Performance Night" or something), email pycon-program-committee@python.org.

Why I Did This

This is an essay on why I started The Art of Python through PyCon 2019’s Hatchery program, what led up to it, and how I feel about its future.

What I Thought Was Missing

For years I’d been frustrated that, when we run sessions at technical conferences, we tend to use such a limited range of techniques to persuade and teach each other. You know the usual pattern - lots of lectures (sometimes with storytelling), panel discussions, and tool demonstrations, hands-on workshops and trainings and birds-of-a-feather discussion sessions. There’s a giant field of endeavor that is all about entertaining and reaching people who are watching you perform on a stage. I’m talking about theater, in the largest sense: music, drama, comedy, dance, and so on.

There are plenty of examples of songs and cartoons whose entertainment value helps us value and retain their lessons. I was hoping to explore how theater about technical topics can do things that are difficult to achieve in a lecture.

Theater can provide spectacle, creating an experience that’s larger than life. And when it comes to the emotionally fraught parts of how we make software together, the medium of theater seemed like a promising way to raise ethical questions and encourage empathy in the viewer. Code review, for instance, is a moment of great vulnerability, an opportunity for courage and healthy conflict. I thought a dramatic presentation--a live worked example--could show the emotional contours of this process better than a dry explanation.

Maria Farrell has observed that “people at all-day tech events are really, really glad to just relax and have stories told to them... actual stories, with, hopefully, meanings heading off on different trajectories, not TED anecdotes driving to One Big Lesson.” I’d seen this for myself, and I wanted to make more of it.

I’d started thinking about the tropes in our mass-media stories about programming, and listing the types of stories that seemed to be missing. I often see galleries or other celebrations of computer-generated art, but I rarely see fine art or traditional media (such as film, theater, music, or fiction) about the experience of making technology.  I wanted to celebrate and encourage performances about the emotional experience of being in technology. I had already seen some examples of the impact of this kind of spectacle, like K. Lars Lohn's PyCon 2016 keynote, which incorporated music, storytelling, and theatrics to discuss education, elegance, and why we learn and teach. I wanted this kind of experience to become a regular occurrence at technical conferences.

I’ve been a performer for years. As a child I had small parts in school and community theater, and my sister and I wrote and performed in skits for Indian-American association get-togethers. Since college I’ve been a stand-up comedian. Bringing those skills into my conference presentations came naturally for me, as PyCon NA 2016 attendees experienced while laughing at the stand-up comedy bits in “HTTP Can Do That?!”.

I had the seed of a plot -- one code review, played several ways -- in my head. However, in order to write and present a full play at a conference, I needed a collaborator.  I finally found one in Jason Owen in 2017.

Minimum Viable Plays

Jason and I wrote a 25-minute short play – Code Review, Forwards and Back, in which a developer, who's written a chunk of new Python code that isn’t great, seeks out review from a team lead. Unfortunately, the lead nitpicks the new developer’s code to the point of missing the forest for the trees. We see the effects of that inadequate review on the team years later -- and then the team lead gets to rewind time and try the review again, à la Groundhog Day. In different iterations she’s abrasive, or nitpicky, or laid-back, or tangled in architecture policy meetings… We showed how the code reviewer’s attitude towards a difficult situation can impact the quality and evolution of the codebase, plus what it might to do the team’s culture, skill level, and sustainability.

Code Review, Forwards and Back debuted at PyGotham in October of 2017. We were happy to hear people say things like “I'm new to the industry, and this helped me learn things to watch out for,” or “I used to be that reviewer and I'm trying not to be anymore”.  Or “I don't code at all but this is a marvelous management parable.” And -- the most frequent comment we got from happy attendees -- it was a change of pace (no slides!).  

The feedback was so positive that Jason and I started thinking about future collaborations right away.  We submitted Code Review to PyCon NA in 2018 as a first step, but were not accepted – however, the PyCon organizers said it had been a very close call.  We also submitted an adapted version to RubyConf that year – we had to port it to Ruby – and were accepted, presenting it that November.  

Jason and I still attended PyCon in May last year – and in the train returning from PyCon, we noticed that PyGotham had just opened its call for presentations. Bright idea: instead of one play, we’d do an entire collection.

I was inspired by the Neofuturists’ theatrical show “The Infinite Wrench”, in which actors perform thirty short plays in 60 minutes, with plays moving in and out of rotation every week. As I tell friends when I bring them: if you’re bored, just wait two minutes and you might like the next play better.

Jason and I started working on our ideas for “Python Grab Bag: A Set Of Short Plays” while on that train back from PyCon, and PyGotham again accepted our proposal. We hired a former Neofuturist, Aya Aziz, as our director, and worked with her on a program of 18 short pieces, which would ultimately be curated by the audience.  The pieces were all different - plays, monologues, physical demos, jokes, tiny traditional conference talks - and the audience would choose each piece they wanted to see from a menu of presentation titles. I wrote most of them, we rehearsed and bought props and got help from a ton of friends, and then we pulled it off at PyGotham in October 2018, to a pretty good reception.

Throughout 2018 I kept remarking to friends that “there should be more of this!” beyond what I was personally writing. I’m an okay playwright but I’m not exactly the Lin-Manuel Miranda of GitHub. Science fiction author Ann Leckie talks about how some fiction feels amazing because, if all the other restaurants have waiters who punch you in the face, it feels amazing to go to a restaurant that doesn't punch you in the face. If we’re used to seeing our experiences misrepresented in art, then it feels special and rare to see our worlds properly reflected. A piece of artistic work may feature no huge innovation, may offer an average level of craft, but might still feel incredible to an audience just because it doesn’t get “us” wrong. I was getting great responses from audiences, but maybe I was just …. not punching people in the face.

I wanted to encourage others to join in, and see how much better the art could get with more participants. So the next idea was for a mini art festival in a con.

Making the festival

That art festival, “The Art of Python”, was part of the 2019 PyCon conference, thanks to PyCon’s Hatchery Program, which helped me develop the concept.

My co-organizers were Erty Seidohl and Brendan Adkins. Brendan and I have been friends for years, and not only did he study both computer programming and theater at the University of Kentucky, he’s participated in 24-hour play festivals, acted, and made art in several media. And Erty, also a programmer, had experience with theater, and was one of the coordinators for !!Con, a con I love and regularly attend.

Structurally, !!Con is sort of cousins with the Neofuturists. !!Con describes itself as “two days of ten-minute talks (with lots of breaks, of course!) to celebrate the joyous, exciting, and surprising moments in programming.” !!Con puts a ten-minute limit on each featured talk at its conference, and makes sure to have a variety of topics, which together sends attendees the message: “If you give everything a chance, some of it will delight you.” !!Con offers all programmers and programming-adjacent folks the opportunity to discover a new fascination. So Erty not only agreed to co-organize The Art of Python with me, but similarly opened up the !!Con call for submissions to solicit more “non-talks”.

Once my organizing team was in place, we worked on the call for submissions. To encourage participants -- especially first-time art makers -- we also created a play creation guide, complete with a list of inspirations and a “play production basics” guide.

I was worried we wouldn’t get enough good proposals -- what if the people who wanted to make art about technology didn’t hear about this opportunity? I made up a 92-item list of people and groups to call to solicit proposals. Most of the list was based on my past personal and professional contacts, and people I met at a tech zine fair in December. I made it through about 55 of those contacts, during spare moments while taking care of family stuff, on a portable keyboard with my phone.

Ultimately we got about 14 submissions and selected five for the festival – and three or four came from people I personally solicited.

Our final program was about 90 minutes long:

• "A Postmortem on the Ingen Incident", a play by Hayley Denbraver about the computer systems failure in Jurassic Park.
• "The Interface", a play by Shauna Gordon-McKeon about different ways technologists sort people and data into boxes.
• "The Programming Saga: A narrative music video" by E Waldo Dow: a remixed video about the frustrations and triumphs of a learner coming to grips with Python.
• a 5-10 minute intermission
• Music by Russell Keith-Magee -- specifically, a rendition of the parody song “I am the very model of a modern Django ModelForm,” which I arranged last-minute at the convention itself.
• Performance by MNF Chang: a monologue about the blockchain, losing and finding one's soul, and sharing prayers and yearnings.
• "Hello!!! ... World?", a wry, moving play by Kyle R. Conway about the experience of learning to program, and of meeting other programmers for the first time.

Credits for the festival:

• Chair: Sumana Harihareswara
• Co-organizers: Brendan Adkins and Erty Seidohl
• Stage manager: Mel Chua
• Advisor: Elizabeth Yalkut
• Name of the festival: Jackie Kazil
• Thank you, PyCon, for encouraging and accepting this through the Hatchery program!

Chang’s work underwent a dramatic transformation during the weeks leading up to the performance. She had approached us with a funny lecture-with-slides, but during the proposal and rehearsal process, her work started to change. Erty and I, along with other volunteers, spent hours discussing Chang’s piece with her about what she really wanted to convey. She revised her work several times, turning it into a personal monologue that used Python as a springboard for an even deeper talk about being lost and making connections. At times we got really deep and passionate talking about how to respectfully talk about something like prayer in an arts festival at an industry tech conference. It was such a great culmination to see her deliver a monologue about yearning as mediated through technology, accompanied by a very understated single evocative slide (a vintage woodcut of a forest) and an audio intro ("Via" by Catherine Bergvall).

Just before the performance, we added Mel Chua to the staff as a stage manager.  Mel and I have been friends for years, and I can rightly say that Mel saved me, both as a stage manager and a person who kept me grounded.  Mel is deaf, and had a mobility impairment so she was in a wheelchair or on crutches throughout PyCon. Accessibility accommodations made it possible for her to do the stage management we needed; PyCon provided sign language interpreters to aid communication, and the venue was physically accessible as well. She managed volunteers, worked out how to smoothly get sets set up and removed swiftly throughout the night, and generally ensured that the entire festival went off as smoothly as possible. The debut wasn’t entirely without hiccups – the A/V manager for the venue had to calm me down, and I’d somewhat foolishly decided to do double-duty as emcee and as audio-visual operator, realizing by intermission that it was a bit too much. (I hastily recruited Hayley Denbraver to step in as the emcee for the second half.)

But I still saw that out in the audience, it was all working.  I’d watched a few rehearsals of Shauna Gordon-McKeon’s piece “The Interface,” and during the performance, Shauna and I were standing next to each other, off to the side of the stage. So we both got to enjoy the crowd reaction when one of her characters accused their co-worker of being “non-technical”; when he said this, he got a round of boos.  Shauna was delighted. And, similarly, the video art piece got laughs of knowing recognition, and so did the part of Kyle R. Conway’s piece where he prefaced a sketch: “On submitting my first question to StackOverflow”.

Kyle heard another reaction from an audience member after the show. Kyle has a Ph.D. in theater, and was recently a novice programmer, and put all of that artistic craft into a script and a delivery that conveyed the experience with vulnerability, heart, and joy. After the performance, one woman approached Kyle and told him that her performance actually made her cry.  “In a good way!” she insisted.  

Next

I started “The Art of Python” to showcase a different kind of technical presentation, in the hopes that the idea would be carried forward and not be limited to a one-time event.

Erty started that process going: !!Con 2019 called for “drama, comedy and magic” in submissions -- anything that conveyed “the emotional experiences of programming.” When I attended !!Con, several days after PyCon, I was thrilled to experience several musical presentations that were inspired by this call. For instance, Anjana Vakil & Natalia Margolis taught us about recursion and finite-memory call stacks via a Disney-inspired musical that had much of the room singing along. And Dawn Xiana Moon took a fine-art approach, using her computer as a creative tool to write songs. Erty spoke at the conference’s close about loving the new dimension this brought to the conference.

I spoke to one woman in the audience at !!Con, who’d grown up loving Disney musicals but who’d felt pressure to put away childish, girly things when entering the tech industry. She was overcome with joy when the whole room sang along to Vakil’s and Margolis’s song parodies, and cried happy tears at feeling that she could, in fact, be valued and accepted as all parts of herself in this tech community.

Tech musicals are in the zeitgeist (example). Next year, in Detroit, a new project - < title of conf >, a tech conference that will be entirely composed of musical performances - will run for the first time, alongside self.conference. More and more people are learning this skill, of making theater about their technical experiences, and finding that doing changes knowing.

In July 2019, months after !!Con, I got to watch the film "Bathtubs Over Broadway" and started learning about the long history of industrial musicals, which also combine the creative and the technical. The difference I saw is that most industrial musicals were written by professional musical-writers and performed by Broadway actors. Only the audience engaged with the subject matter of the performance on a day-to-day level. The performances I’ve seen at technical conferences are powerful partly because they build on a shared understanding between the creator and the audience--the understanding of what it’s like to write software.

Chang’s reflection after “The Art of Python” articulated:

the need for tech workers, project managers, customer success agents, engineers, and so forth, to create a narrative language around their work. We are the ones building the cathedrals, maybe the stain glassed windows should reflect our own mythology.

Instead of treating engineering as purely an application of mathematics and physics, I’ve always preferred a holistic and humanist approach, in which we value literature, art, history, geography, and psychology as much as we do computer science. I’ve made conscious steps to combine art with engineering and am encouraged others are now doing the same. But I, personally, won’t be driving this going forward.

I hope you will.

Mary Anne Mohanraj, one of the founders of the science fiction magazine “Strange Horizons”, spoke about her involvement in online publishing:

“I like seeing a need, figuring out how to fill it, getting the structure up and running — once it’s running smoothly, I generally move on to the next thing.”

I’m writing this document (along with “How I Did This”) to create a baseline for “running smoothly”. I’m sharing my ideas about how I made this work and why I think it provides value to the people in the audience and the people on the stage.

Mohanraj writes:

“If you see a lack — and our field is wonderful, but there are still lacks and problems and it could certainly be better — then step up and figure out what could be done to fix it. If there’s an organization doing good work that you believe in, join them, and give them your time, your energy, your ideas — maybe even your money, because you know that most of these organizations are operating on the thinnest of margins and a few extra dollars are always welcome.”

I saw a lack. I was not and am not a professional playwright, performer, or festival planner. But I didn’t have to be, and you don’t either. You don’t have to be a professional performer to show what you experience when you’re programming -- you just need a stage, and I wanted to create the stage. And now we have. I hope the show goes on.

How to Do This

There are a lot of other event-planning guides -- ConRunner.net, SMOFCon resources, the AdaCamp toolkit, Community Event Planning -- and a ton of "how to run an arts festival" guides as well.  However, none quite captures the specific scenario of “coordinating a performance festival that's part of a larger tech conference”.  Since I cannot be one of the co-organizers for The Art of Python at PyCon North America in 2020, I’ve prepared these notes to assist instead, as a form of conference mentorship.

If you want to organize Art of Python at PyCon 2020, please submit a Hatchery proposal as soon as possible. The deadline for Hatchery proposals is January 3, 2020. If you are interested but need help to do it, post about that someplace public -- your blog, Twitter, etc. -- and tell me, and if I hear from multiple people, I'll put you in touch with each other.

• (And in this guide I don’t assume that you’re leading a performance festival at PyCon -- maybe you’re thinking about RubyConf, or working on Title Of Conf!)

Broad schedule

• Gather co-organizers: -6 months
• Start drafting call for submissions: -5.5 months
• Announce & publicize call for submissions, and start helping collaborators find each other: -5 months
• Close call for submissions: -4 months
• Notify acceptances and rejections, start helping with editing, feedback, logistics guidance: -3.5 months
• Checkin video calls with organizers: -2 months
• Full rehearsal video calls with organizers: -3 weeks
• Schedule announcement: -2 weeks
• Organizers start arriving at venue: -2 days
• Full dress & tech rehearsals: -1 day
• Finalize print program and make copies: morning/afternoon of the fest
• Festival: Date 0

Assembling Your Staff

Your pre-festival staffing needs will be a bit different than your needs at the festival itself.  In the preparatory stage, people can double up and hold multiple roles:

• communicating with con-runners about logistics
• publicizing call for proposals
• reading and selecting submissions
• providing editing, feedback, logistics guidance and helping performers rehearse
• preparing/designing/printing program
• publicizing festival

It may also be helpful to solicit people in different time zones for your pre-show staff.  This can help with smoother communication once you start approaching the participants - if you’re working with a playwright in Honolulu, but everyone on your pre-show staff is based in New York, you’re going to have frustrating problems with delays in communication.  Having pre-festival staff in a range of time zones makes it easier for someone to get on the phone with “we need to know about this ASAP” kinds of questions. And I think it’s good to have colleagues with different aesthetics and tastes, because that will help you curate a varied program, including music, theater, dance, and mixed media performances about joy, melancholy, and disappointment.

At the festival, your staffing needs will be a little different.  You will need to have dedicated staff focused on each of these tasks:

• overall fest-runner
• emcee
• stage manager
• dedicated A/V person for running music and slides (separate from the conference venue’s A/V person who’s managing amplification and projection)
• 1-2 stagehands to hand props to performers, move furniture onstage, give and take microphones, and so on
• ushers to hand programs to visitors and guide them to seats, ideally up front

The ushers can be volunteers solicited by the organizers of the conference itself.  Stagehands can also be volunteers, but you should prescreen them a bit before the conference first, since their roles have more of an impact on the performance itself. Check whether stagehands can take directions well and remember details.

On the other hand, the stage manager is someone you will want to secure as far in advance as possible.  A stage manager’s very job description involves oversight of all the performance, rehearsal, and technical needs for your participants, so they already have a head start in knowing how to help find and schedule rehearsal spaces, check on prop and light cues, notice where you'll need stagehands (and how to find good ones among the volunteers), and so on.  The sooner they can be brought into the festival prep, the sooner you can have those tasks off your plate. Your stage manager can also handle communication with the A/V lead at the venue.

Speaking of the A/V side of things - you may be very tempted to have the Emcee do double-duty as the A/V operator. Resist that temptation; these really should be two separate roles (if for no other reason than: if the A/V system goes down in between acts, the Emcee can be onstage chatting with the audience to cover time while the A/V operator is getting things back up and running).

Things To Add To Your Budget

These will help things run a bit more smoothly.

• A fund to pay for conference tickets/registration and travel for performers who wouldn’t be able to afford it otherwise.  The conference committee may be able to help with this, so speak to them early on.
• A fund to help performers pay for production-related needs like props, a director, rehearsal space, etc.  Many performers may have all the items they need and may have their own production staff on hand, but a fund to defray last-minute expenses may be a big help to participants.
• Dinner at the dress rehearsal.  Not a full-course meal, but you will want to order takeout/delivery to feed people while they wait to go onstage.
• Printing the programs.  Your program will likely be simple, but you still need to pay the copy shop!

Liasoning with Conference Committee

While conference organizers know a lot about the conference and its subject, they may not know so much about the particular needs of performers, so they may not be prepared to automatically anticipate those needs. So it’s worth it to have a detailed conversation with the conference organizers early on, about the following:

• How much time has been allotted for your festival, and whether that time will be entirely for performances or for a mix of performance and mixer.  ("The Art of Python" we did was slated for two hours, but we ended up using 90 minutes for performances, and used the remaining 30 minutes for mixing/socializing; this worked well for us.)
• Whether they can provide your applicants, staffers, and performers financial aid or arrange for group rates for travel and lodging, props, rehearsal spaces, insurance, or other needs.
• Whether the applicants, staffers, and performers will need to buy a conference ticket, or whether performing gives them a free ticket to attend the rest of the conference in whole or in part.
• Whether they can provide rehearsal space at the venue, and if so, how much (be prepared to note down the sizes of the rooms available for rehearsal space).
• The technical specifications of the venue and its audiovisual capabilities -- how many mics are available, and can they all be on simultaneously? Will you have videorecording and CART captioning? Will your performers have a ramp up to the stage, for accessibility? Will you be able to play music or project slides or videos? What kind of lighting is available at the performance venue, and can each performance piece make changes to the “look” of the lights (and if so, how much)? What is the exact size of the performance space at the venue?  (These questions may require a second conversation with the A/V lead at the space, so make sure you get their contact information.)
• Whether they can provide on-site volunteers, especially for stagehand and usher work.  (Make sure your stage manager can contact the stagehands in advance to confirm they are up for the task, and that they will be available during all on-site rehearsals and performances!)

In addition, enlist the conference organizers to announce and promote your call for proposals, and announce the date and time of the festival in the con's opening remarks and in the online and paper schedules.

Your Call For Proposals

Now that you have a better sense of the venue, it’s time to put out a call for proposals!  

You'll most likely need to do a bunch of outreach for proposals, including personally inviting people to propose their ideas. At Art of Python we got about 14 submissions and selected five of them for the festival, and I think three or four of the proposals we accepted were from people I personally solicited.  Note: I have a list of 92 people and/or groups who would make good candidates which I can share privately. Please email me if you are one of the organizers for next year and I’ll share it with you!

Your call for submissions/proposals should include:

• Who you (the organizers) are – include a paragraph-length bio of each of you.
• A broad description of what you're looking for (Are you open to videos? Static visual art such as paintings? Purely computer-generated art? Dance? Solo monologues?).  If you have links to past examples, all the better.
• Any information you currently have about the festival date, venue, and what kinds of performances you can accept (length, number of performers, the room and stage configuration, technical limits, if there is any financing available, etc).
• Whether there would be pay, and whether performers will need to buy a fest or conference ticket.

Ideally, each applicant’s proposal should include:

• The applicant's name, and a brief bio (including pronouns) of each of the performers (a few sentences is fine).
• Some kind of contact info including phone number.
• The number of performers in their work.
• A one-paragraph synopsis of the planned work.
• Documentation of the planned work (be that an outline, a lyric sheet, or a script), inline or linked (plain text, PDF, JPEG, PNG, or Open Document Format preferred). Emphasize that they need not have completed the work before submitting a proposal.
• Musicians should be handled separately as their needs are different.  One big thing to ask is whether they can travel with their instrument, and whether that travel may require extra compensation (double-bass players flying with their basses have it rough!), whether they have a song in mind, and how they would describe their genre. (Mike Pirnat may be leading this next year for PyCon North America 2020 in Pittsburgh, so you may want to speak with him about the particulars of musicians.)

As an example, here’s one such email we used for Art Of Python:

Subject: Open for proposals: art about the experience of making technology
Hey [name],
I'm leading an arts festival this year https://us.pycon.org/2019/hatchery/artofpython/ and would deeply appreciate if you could spread the word to other media-makers.
We're seeking many types of narrative, performance, and visual art about the experience of programming and making technology -- not necessarily in Python. Some of our inspirations are Ellen Ullman's novel "The Bug", Randall Munroe's comic "xkcd", and Anat Deracine's "The Divine Comedy of the Tech Sisterhood".
The festival will be Friday, May 3rd, at PyCon in Cleveland, Ohio, USA. The deadline for submissions is Feb. 28th. I regret to say that there is no pay involved.
And please feel free to spread the word and to share this email.
Thank you,
[YOUR NAME TK]

Feel free to check out the Art of Python call for proposals and our tips for play creators for other examples.  Speaking of that Art of Python call, incidentally – you’ll notice we used PaperCall for our system, but found it wasn't very flexible; every proposal we received was automatically categorized as a "talk" and we heard that sometimes our notifications were going into spam. But we have heard promising things about YakBak as an alternate.

Deciding what to accept

Some decisions will be easier than others! I suggest you go for a mix of tones, approaches, lengths, and dramatic styles -- some funnier and some more serious, some about specific technologies and some about generally being a technologist, some multiperson and some solo, some heavy on props/AV/staging and some not, some five minutes and some 15-20 minutes. If you have any musicians, you could scatter some songs in between the other performances.  And don’t forget your venue’s technical limits as well (a performance art piece celebrating the concept of “Beautiful Is Better Than Ugly” may sound amazing, but if the piece calls for eight extra spotlights, a full choir, a ten-foot-tall stage set or some other item that takes 20 minutes to set up, you may not be able to accommodate that).

Also, make sure that any proposals fit the Code of Conduct of your event - and even if they do, remember that your audience will most likely be diverse, and will be bringing their own experiences and histories to your event which can impact how they receive references in a given piece.  For example, if someone proposes a comedic play about how tabs-versus-spaces stylistic arguments “feel like a religious war”, that may touch sore spots for religious people in the audience. You don’t need to reject every proposal that has problematic content. Instead, be open to talking with the candidates about how they could make their work fit the Code of Conduct.  This may take several discussions as they develop their work to examine how they can make their point while still being sensitive to diverse audiences.  Many artists welcome this kind of collaboration and feedback as they develop a new work, so you will probably be able to have productive discussions if the issue comes up.

You also have no obligation to fill up all of the time you have allotted. You can give your audience multiple intermissions, or an unconference/mixer, or end early. However, I also recommend you accept one or two more items than you can comfortably run in the festival, or at least have one or two simply-staged pieces on standby, so that you have a little buffer and you can choose to cancel a few performances if the performers miss rehearsal deadlines.

If you’re having trouble deciding, feel free to follow up with applicants, via email or phone call or chat, to ask for more information about what they have envisioned for their project or if they have prior work you could review to get a better idea of their approach.

Notifying the Participants

Performers should be notified at least three and a half months before the conference, if not even sooner.  When you send out the notifications, make sure you give them the following information:

• The conference schedule, including all deadlines they must comply with for reserving travel, lodging, rehearsal rooms (if available), sending you information and photos for the program and other promotional material, etc.
• Details about audio/visual capabilities, the room and stage configuration, etc.
• A reminder to buy conference tickets right away, if they are required to purchase tickets.
• Information on whether funding is available for travel, lodging, production expenses, etc., and how to obtain it.

This is also a perfect chance to re-confirm that you have the most current contact information for each performer or group, including a current phone number.   Even if they included this in their application, it is worth asking them again.

Rehearsal and development period

About two months before the festival, hold checkin video calls, where each accepted participant speaks with one of the organizers and talks about where they are in the development of their piece. This is a good time to do some light project management with performers, helping them plan out whom they need to recruit and what they need to schedule.

Then, about three weeks before the event, hold full rehearsal video calls with organizers, where each accepted piece is rehearsed, in full, during a video conference call with one of the organizers. This deadline helps all the teams avoid procrastination, and gives organizers a chance to say “whoa!” in case the in-progress work is way different from the proposal. And if one or two of the accepted proposals aren’t ready for rehearsal by this deadline, it’s okay to let them know they won’t be in this year’s festival, and encourage them to get ready for a future one instead.

After organizers have witnessed rehearsals with all the accepted proposals, you can put together and announce the program online, and start prepping the paper program.

Preparing the Paper/Online Program

The paper program can be fairly simple -- one page may be enough. Make sure to include:

• the sequence of acts and a rough end-time
• names of performers, and very brief bios and links if possible
• thank-yous

Adding photos to the online program can draw people in as well, and participants may have production photos to share.  You can of course also add photos to the paper program as well if there’s enough money in the budget.

At the Con & Festival: The Rehearsal Phase

Your participants will be rehearsing on their own at home, but you’ll still need to arrange for some rehearsal time at the con, if only to run the entire program through to spot and fix any technical hiccups, transitions, and such.  

The day before the festival, you will want two rehearsals of the full festival – one an abbreviated technical run-through, focusing on the technical aspects like props, blocking changes, lighting transitions, any complicated costume changes, transitions between acts, and the like, and then a full dress rehearsal.  To avoid performance fatigue, abbreviate the first rehearsal (only practice the transitions and technical elements) unless the performers in one of the pieces specifically need or want a full run through, or unless you have a play with lots of cues or lots of props and blocking changes.

Your participants will likely also want to do some independent rehearsing as well.  Have dedicated rehearsal space and time blocks on site the day (or two) before performance, and if there is time, give each performer a chance to run through their piece on the stage itself so they can “get to know” the space.

Feed everyone at the full dress rehearsal – people will spend a lot of time waiting, and free pizza will go a long way to cheering them up.

At the Con & Festival: The Performance

It’s showtime! Excitement will be running high, and so will nerves a bit.  There are some things to do just before the live performance to ensure everything goes as smoothly as possible.

• Firstly, check and double-check that everyone knows who does what during the performance itself - who is the stage manager, who will do the A/V, who will be Emcee, who are the stagehands, etc.  Your stage manager may very likely have taken care of this task already the night before, but confirm this the day of the performance; there may be an extra volunteer or two who’s just turned up for the first time that day and needs to know who is doing what.
• Speaking of volunteers: make sure volunteers know the Code of Conduct for the event, and empower them to step up and enforce it -  even if it means potentially interrupting a performance.  Also, of course, empower them to interrupt a performance in the case of an emergency (fire, serious injury to a performer, etc.). Again, your stage manager may have already handled this, but check in with them to be sure.
• Make sure you have permission to take photos for your scrapbook, blog posts, web sites, etc. This may seem like a small thing, but there is a small chance some of the performers may be bound by certain film or stage actor union rules that dictate how their images can be used.  Most likely this will not be the case, but it is important to check.
• Accept that things will go wrong during the performance -- a slide won't display, a chair will fall over, a performer will forget their lines and need to look at their script, an audience member’s phone will go off.  Fortunately, audiences can be very forgiving, and will be rooting for you.
• Have your thank-you’s prepped to say for the end of the program, and invite all the performers to join you on stage for a bow at the end of your post-show address.
• Finally: remember to breathe!

After the Show

You did it!  Before everyone jumps in to post-show socializing, there are three things you’ll likely want to do:

• Grab a few people to help with cleanup. Unless your performances are unusually complex, this will likely be minimal, but it’s the kind of thing everyone assumes someone else will handle.  Making sure you’ve delegated the job to someone ensures it will get done.
• Try to capture any notes about the production, even if fragmentary, as soon as possible.  Think in terms of "what went great, what could have gone better", for both the individual pieces and for the production as a whole.  The performers may be interested in feedback about their own production, and the notes about the event as a whole will help with planning next year’s events.
• Speaking of next year - if anyone approaches you offering to help with next year’s event, great! Seize that opportunity by getting their info right then and there, and give them yours.

Good luck!

Back to Sumana Harihareswara's homepage