Notes From the SciPy 2018 Post-Con Lunch¶

Notes from the post-con lunch at the end of SciPy 2018. Notes taken by Alexandre Chabot-Leclerc.

Grab bag¶

Have an “unconference room” + hallway track.
What about an official mentoring or pair programming room/session? Office hours? For people new to Python, or who just need some help. Maybe ask for experienced members of the community to volunteer a few hours during the week to “staff” the help room. It’s some kind of Help Desk++.

Good to have an actual organization
Master spreadsheet was good because it forced sprint leaders to fill out certain details
They should be better advertised. Do more work with Communications
Don’t like the word “sprints” (also echoed during the SciPy 2019 BOF). Need a more inclusive name.
What about a sprint for newcomers to get started? Maybe to work on their own stuff with experienced members of the community. See also the idea of a mentoring program discussed below under Activities.
Sprint financial aid didn’t work well. Not really needed this year. Maybe keep it as an option?

The bar for acceptance is very high. Some proposals are much more fleshed out than others. How to make it inclusive and “easy” to get started, without requiring all the materials up front?
Tutorials mentorships for more varied applicants?
Git reviews?
Add link to good past submissions in the submission form.
Explicitly prompt for timing information in submission form.
Reach out to more events (with comms), e.g. PyLadies, Meetups, etc.
Not enough reviews. Co-chairs reviewed all 55 submissions. Each reviewers did 5-6 reviews.
Prompting for submissions from past attendees and from particular organizations/projects/languages worked great.
Too many attendees. The rooms were really crowed. How to control? Check badges? Silly hats? Colored lanyards?
Could we live stream popular tutorials into another room?

Repeat of tutorials: The bar for acceptance is very high. Some proposals are much more fleshed out than others. How to make it inclusive and “easy” to get started, without requiring all the materials up front?
More submissions than last year.
Stickers + prodding works to get reviews done on time
Reduce the number of tracks (see alternating years idea below)
Pains with EasyChair (but with ETouches too)
We received “token submissions” (very weak) from VIPs. We should manage expectations. The submissions should good from everyone. There could be some guidance in the prompt.
Similarly for reviews; they should have some substance.
The general track turned out to be less popular than other tracks
What about tagging talks instead of tracks?
What about having single-talk tracks? It basically guarantees a track under a given name if there’s a least one talk.
Some tracks would need more slots so that there’s a critical mass of content for people who would normally not come to SciPy (e.g. some geoscience people). Pair with tutorials for that particular track? Maybe alternate years for certain tracks so there’s more space for them? Alternate between US and EU? The downside is that we might attract more people from a given field, but not from new fields.
What about entirely open process (public), e.g., Github? Not just double open? There are concerns for GDPR.

Rooms were far from each other, which negatively affected the “hallway track”. Could we use the 100 floor?
The poster sessions conflicts with the job fair. Turn the poster session into more of an event? Drinks? Even more posters?

4 people is good
Build server is great
Starting early was good
Not enough reviewers, some people didn’t do their reviews
Could abstract reviewers also be paper reviewers? Probably a big ask.
At prestigious computer conferences, there’s a technical committee who takes care of all the reviews. They’re invited. It’s a prestigious position. Maybe try something similar? Put the members’ names on the website? There’s a concern that it may affect the path from contributor to be involved in the proceedings committee. Maybe give different titles to people on the committee? Editors, Committee Chairs, etc.
Get more people involved in the development [of the toolchain?].

Eric hand-built a submission reviewing system (he doesn’t recommend doing that)
The expanded submission form was very valuable, but it was also more intimidating. It seems like a zero-sum game: too many boxes lead to fewer applicants.
Focus on financial aid as a way of bringing in new people (?) in addition to bringing in members of the community who would otherwise not be able to attend.
How to get more money?
How to manage financial aid for speakers? Should they get it automatically or not? Should the funds be separate? Timing with the talk acceptance is also tricky.

80 people signed up for Broken Spoke, 55 on bus + others with other means of transportation
General organization started too late
Vislab was super popular
More planning of some mentoring program. Ideas were: early career mentoring, new-to-python mentoring, and new-to-SciPy mentoring.
Clarify with committee members about the implications of being on the activities committee (tasks, deadlines, number of people, etc.)

Send sponsorship packages earlier in the year because of the timing with which some companies set their budgets.
Offer doing interview with possible candidates during SciPy to gold sponsors

Meetups were good
BoFs were great
Do more, earlier communications
Good discussions happened on Slack and during talks
Some people didn’t actually help even thought they said they would. How to get more dedicated committee members?
Offer diversity scholarships?
Schedule diversity BoFs in large room after big talk, so they have more exposure, and more would likely attend.

Don’t use two different sections about financial aid. Maybe differentiate them with footnotes?