[Inpycon] CFP/Session workgroup Meeting minutes | 20180412

[Jaidev Deshpande]

On Sat, 14 Apr 2018 at 17:20 Ramanathan Ramakrishnamoorthy <
ramanathanhari at gmail.com> wrote:

> Hello All,
>
> We had our first CFP/sessions workgroup meeting on Thursday, April 12,
> 2018.
>
> Attendees: Anand C, Navin, Joinal, Vijay Kumar, T K Saurabh, Chirag,
> Ramanathan.
>
>  - Jaidev was not able to attend due to some prior commitment at his
> office and had informed that offline.
>
>
> *Minutes:*
> 1. A mutual introduction among the members was done.
>
> 2. An update on the confirmed Keynote Speakers was discussed.
>       - Based on suggestions on mail and other channels, we reached out to
> multiple Keynote speakers and have gotten confirmation from the following
> speakers:
>           a. Travis Oliphant
>           b. Armin Ronacher
>           c. Carol WIlling
>
> 3. It was decided to go with 4 Keynote speaker.  A proposal was floated
> for 6 Keynote speakers. However, a majority of the workgroup felt 6 was
> heavy and 4 is reasonable. It was decided to go with 4 Keynote speaker as a
> unanimous decision.
>
> 4. Proposals for the fourth Keynote speaker from India were discussed.
> The following names came up as proposals.  (I will follow up this on the
> Keynote suggestion mail thread).
> - Sidu Ponnappa
> - Rishabh Mehta
> - Anand S
> - Professor Janakiraman from IIIT
> - Dhanunjaya Neni
>
> 5. It was decided not to have any other invited speakers apart from
> Keynotes and go via selections from CFP for all non-Keynote sessions.
>
> 6. The second hall in the venue can hold up to 220-240 people.  Anand C
> mentioned it might not be sufficient and if there are ways to make it
> bigger.  The local logistics team will work on this with the venue partner
> and see how this can be dealt with.
>
> 7. It was decided to have Whatsapp as the primary form of quick
> communication within the workgroup.  All discussion points and decisions
> taken in the meeting will be published to the wider audience via e-mail.
>
> 8. It was decided to have a weekly recurring meeting on Thursday 9 PM
> IST.  The agenda would be published at least a day before the meeting.  The
> meeting will happen in [1].  Anybody interested can feel free to join the
> meeting.
>
> 9. Next week's primary points of discussion would be on themes and
> structures of the conference in terms of tracks and talks.
>
> [1]  https://hangouts.google.com/call/4voxuNI20vnb7WZTLYoRAAEM
>
>
Apologies for not being able to join Thursday's call. I wanted to bring up
certain points of discussion about the proceedings, which I've gathered
over the last two years from many people in the community. These are things
on which I myself may or may not have an opinion or even a solution, but
they definitely should be discussed here. For some of them, we may have to
come to a decision before we open the CFP, others can wait.

1. Changing the proposal categories:
The current categories under which proposals are invited (you can see them
here: https://in.pycon.org/cfp/2017/proposals/) are somewhat outdated.
Talks that are actually catergorized under them don't really fall under
them. Some talks may belong to multiple such categories, some may belong to
none. The point is that these categories have largely lost their utility.
We normally try to have talks uniformly distributed between these
categories but that just ends up making us select one more
less-than-perfect proposal simply because it belongs to an underrepresented
section. Instead of specifically categorizing talks, I suggest we let
people submit proposals, and ask them to tag their proposals, like they
would a blog post or a tweet. Then we can categorize them *a posteriori*.

2. How important are upvotes?
There's enough evidence on both sides. The most upvoted proposals can be
terrible and also very good. So far they've been used only as tie-breakers,
and I suggest we don't change that. However I'm happy to hear other
arguments.

3. Double-blind reviews:
I'm not sure how easy this is to implement. I'm not even sure if this will
have a positive impact on talk quality. I'm personally in favour of this,
since it gets rid of all bias both ways, but I am also aware that this will
involve changing a *lot* of things on Junction and in the review process.

4. Multi-stage reviews:
This involves multiple rounds of proposal->feedback->edits_to_content
between the reviewers and the proposers. We have partially done this in the
past. The most common reason why this fails is because people don't follow
up on their proposals on time. That itself may be happening because we
(reviewers), from our side, are not being clear in our intentions to carry
out reviews in this manner. People probably think that one negative comment
from a reviewer amounts to a straightforward rejection. We must explicitly
communicate (maybe through a blog post or on the Junction page itself),
that multi-stage reviews *will *happen.

5. Detailed debates among reviewers about talks:
I don't remember the last time reviewers sat together or were involved in a
common email thread debating for or against a contentious set of talks. The
Thursday call is one big leap in this direction. IMO this is critical - not
least because it ensures better quality, but also because it is immensely
educating. I had one-on-one conversations with almost every reviewer during
PyCon 2016 and PyCon 2017, but I did not try hard enough to get them all
together. This leads to all their feedback / thoughts / wisdom being locked
up in my brain alone, which I might have easily forgotten.

6. Codifying what a proposal is scored on.
Most reviews end up being very subjective since we don't have a formal
scoring system. Candidates quite often receive piecemeal feedback and end
up skewing the effort they put into improving their proposal.

6. Learning from other conferences:
What's your favourite FOSS community-driven conference? How do they handle
their proceedings?

Everyone is welcome to add to these points or suggest solutions. I'm also
aware that not all of these are solvable, or have to be solved right away -
so do share your thoughts as to how these issues should be prioritized.

Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/inpycon/attachments/20180416/7f566a9a/attachment.html>