I’ve ranted before about PyCon not meeting my expectations, and I even skipped going to the last PyCon. Somehow, I hoped that it would be better this year, but no such thing happened.

• I should strictly not attend any talks, at the next conference I am at. Even if the topic seems interesting, I should refrain from attending any talks, unless I know that a speaker is entertaining.

• I should be going there to meet old friends, meet a few new people, and mostly hacking on my stuff. May be aim to show something at the lightning talks at the end of second day, based on what I did during the rest of the event.

• Participate more actively in open spaces, and may be initiate or suggest some myself. Sprints for bug fixing, adding new features to a project may be a good way to get new developers to start contributing to FOSS projects. It would be even better to be in touch with folks before the event, and use this opportunity to iron out kinks.

I think the talks could be improved drastically. A lot[1][2] has been said, already. Here’s a summary of how I see it.

• Beginner/Novice talks doesn’t mean bad talks. A talk with a good narrative, that drives home a point, that may be familiar to most of the audience, would still make a good talk. I don’t mind reading a good blog post/book on a topic I already know, because there is joy in reading/listening to “good” stuff.

• Talks cannot be judged by titles or an abstract. Taking inspiration from PyCon US, we could

  • Ask for a video recording of a previous talk or a short home-made recording of the speaker presenting some topic.

  • Ask for a granular outline [6] along with rough timing information, instead of just an abstract.

  • Have a bunch of resources [3][4][5] available for speakers to improve on their proposals/accepted talks.

  • Have a bunch of 20 or 30 minute talks, and very few longer (45 min) talk slots.

  • Encourage speakers to try connecting their laptops and iron out “presentation” kinks on the day before their talks/lunch/other allotted times. Technical issues like fonts being too small, mics not working, adjusting the volume/other settings for the speaker, etc. can and should be fixed before hand.

  • The talk review committee could also take notes from attending some of the talks, and compare it against their notes when they accepted the talk, to improve the talk selection process. Some of it could be valuable feedback for the speakers too.

[1] https://plus.google.com/+sankarshanmukhopadhyay/posts/8QY4o3hiyLT

[2] https://mail.python.org/pipermail/inpycon/2014-October/009189.html

[3] https://us.pycon.org/2015/speaking/proposal-resources/

[4] http://doughellmann.com/2011/10/18/how-i-review-a-pycon-talk-proposal.html

[5] http://www.craigkerstiens.com/2012/06/19/pro-tips-for-conference-talks/

[6] https://us.pycon.org/2015/speaking/proposal_advice/samples/SpacePug/