[Inpycon] Talks in PyCon India (was Re: Development Sprints)

[Puneeth Chaganti]

Hello!

I know a lot has already been discussed about improving quality, and I have
mostly been an observer.  I received an email from one of the volunteers asking
if I was interested to help with reviewing the talks, and I'd be more than
happy to do so. This email is an attempt to participate more actively in our
attempts to make PyCon 2015 better.

I have a few ideas/proposals for ideas, that I think would help improve the
quality of talks and workshops.

1. PyCon US provides links to a bunch of speaking resources[0] and I think we
   should do it too -- even if it means, just linking to their page. This would
   be especially helpful to the new/first-time speakers, but I wouldn't be
   surprised if more experienced speakers also pick up a thing or two.

2. Provide a sample proposal -- We could either make one up, or use one of the
   good proposals from previous conferences.  Allison Kaptur maintains a
   repository[1] of accepted/rejected PyCon proposals. Brandon Rhodes also
   maintains[2] a page of his PyCon proposals, along with a few thoughts on
   each of them.

3. I agree with Julia Evans, when she says "You can choose who submits talks to
   your conference"[3].  Just like we have invited more reviewers, to try and
   improve the quality of talks, we could and should encourage speakers that we
   would like to see, to submit a proposal. Co-workers, speakers from your
   local meetup group, folks that have interesting projects that they
   work/worked on, open source project contributors, folks whose blog posts you
   find interesting -- encourage and prod them to submit a talk proposal. It
   may be nice to have an "outreach team" that does this, but even all
   of us just doing it as individuals will go a long way.

4. Ask for a detailed outline of the talks, along with timing information for
   each part of the talk (a la PyCon US). It will give the reviewers more
   information to work with, to help the speaker improve the proposal and to
   predict how interesting/engaging the talk is going to be.

5. Encourage speakers to share videos of talks they have given previously, if
   any, when asking for code/other links.

6. Encourage (new/first-time) speakers to actively go out and practice
   their talk with a smaller, more friendly audience.

7. Encourage talks on work that has already been done, as opposed to proposals
   for talks about work that will be done in between now and PyCon.

8. All the reviewers should be encouraged to actively work with the speakers to
   help improve their proposals, as opposed to just being judges[4].  The post
   also presents a bunch of useful questions to ask, when reviewing
   proposals. It could go into the reviewer guidelines.

9. I'm not sure what the talk slots for PyCon this year are. But, I feel it is
   quite difficult, especially for inexperienced speakers to keep the audience
   engaged for 40-45 minutes. I think we should also have smaller time slots
   for talks - 20/30 minutes. It may be a personal preference, but I find
   short, densely packed more enjoyable, since only the most
   interesting/exciting stuff can be presented, given the time constraints.  I
   would even say that, speakers should be actively encouraged to choose
   smaller time slots.

10. Accept lightning talks also, through junction, allowing good talks that may
    not be suitable for a 20/30/40 minute slot to be presented as lightning
    talks. PyCon US allows poster presentations, but lightning talks may work
    well too.

11. Encourage/force speakers to leave *enough time* for questions. It would
    help make the whole conference more interactive and lively.

12. Assign time-slots (explicitly) for the speakers to try out their equipment
    -- projector, mic, any other hardware they will use in their presentation.
    Avoiding delays due to "technical snags" is relatively easy, and makes for
    a much better experience for the audience. Feedback on seemingly minor
    issues like font-size, editor theme, etc., during the review stage would
    also help a great deal.

I hope atleast some of these suggestions make sense, can be implemented, and
contribute to a better conference this year!  Apologies if we too far into the
process, to discuss (some of) these ideas. Also, would be curious to hear what
some of the folks with more experience with organizing conferences, and
reviewing talk proposals feel about these things.

Looking forward to great PyCon!
Puneeth

[0] - https://us.pycon.org/2015/speaking/proposal-resources/
[1] - https://github.com/akaptur/pycon-proposals
[2] - http://rhodesmill.org/brandon/2013/example-pycon-proposals/
[3] - http://jvns.ca/blog/2015/03/06/you-can-choose-who-submits-talks-to-your-conference/
[4] - http://doughellmann.com/2011/10/18/how-i-review-a-pycon-talk-proposal.html