[Inpycon] CFP/Session workgroup Meeting minutes | 20180412

Mon Apr 16 06:23:55 EDT 2018

On Mon, 16 Apr 2018 at 13:44 Ramanathan Ramakrishnamoorthy <
ramanathanhari at gmail.com> wrote:

> Categorizing by tags might not be the best idea as, if you let speakers
>> create random tags, they might be wildly different from one talk to another
>> even when they are around same topic.
>
>
Yes, that's what I meant - predefined tags. Users won't be allowed to
create new tags.

> I agree that the categories used in previous CFP are a bit vague and not
>> very useful. We can categorize talks based on some practical use case -
>> e.g. expertise level needed to comprehend, according to the speaker(easy,
>> moderate, expert etc), because we've had this conversation many times in
>> past(after PyCOn was over) when after the conference attendees say that
>> there are not enough expert level talks, or there were more beginner level
>> talks in comparison. Categorizing by expertise level needed will help
>> people choose which talks to attend.
>
>
> Regarding tracks and audience level, we have a proposal.  I am putting it
> out here for suggestions.
>
> At a high level, we can view the talks into two dimensions.
>
> *First dimension - Based on talk category*
>  - Web & GIS applications with Python
>  - Data science with Python
>  - General purpose applications with Python - At a high level, this can
> include anything from system programming, networks, any automation, etc,.
> In other words, everything that does not fall under the first two
> categories.
>
> There can very well be few cases where there is an overlap - We can deal
> with them on a case by case basis.
>
>
> *Second dimenstion - based on audience's expertise level*
>  - Beginner
>  - Intermediate
>  - Advanced
>
>
> The proposal is to make sure there is at least one talk at all the times
> in both the dimensions.
>
+1

>
> Based on the above we can probably have the following suggestions to the
> attendees.  Whenever non-Keynote talks are happening, there will be one
> talk in each line.
>
> *Green Line* - All beginner talks.  The talks will be explicitly marked
> and be beginner friendly.  The talk content will span across all three talk
> category. The beginner will get exposed all tracks of Python-related work.
> *Orange Line* - All Intermediate level talks.  Again, spans across all
> three talk categories.
> *Grey Line* - All Advanced talks.   Again, spans across all three talk
> categories.
> *Yellow Line* - All talks on General purpose applications.  Talks will be
> at all expertise levels.
> *Red Line* - All talks on Web applications & GIS.  Talks will be at all
> expertise levels.
> *Blue Line* - All talks on Data Science.  Talks will be at all expertise
> levels.
>
> We can maybe have one more line - *White Line* - Talks based on community
> and experiences sharing.  We can decide the number of talks to be selected
> under this category.  Talks in this line may not be available always.
>
> Of Course, it requires some more thought to make this proposal workable.
> Please let us know your suggestions.
>
> Thanks,
> Ramanathan.
>
>
> On Mon, Apr 16, 2018 at 11:36 AM, Bibhas Ch Debnath <me at bibhas.in> wrote:
>
>> Hi,
>>
>> Just want to add few comments.
>>
>> On Mon, Apr 16, 2018 at 8:19 AM, Jaidev Deshpande <
>> deshpande.jaidev at gmail.com> wrote:
>>
>>>
>>>
>>> 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*
>>> .
>>>
>>
>> Categorizing by tags might not be the best idea as, if you let speakers
>> create random tags, they might be wildly different from one talk to another
>> even when they are around same topic. I agree that the categories used in
>> previous CFP are a bit vague and not very useful. We can categorize talks
>> based on some practical use case - e.g. expertise level needed to
>> comprehend, according to the speaker(easy, moderate, expert etc), because
>> we've had this conversation many times in past(after PyCOn was over) when
>> after the conference attendees say that there are not enough expert level
>> talks, or there were more beginner level talks in comparison. Categorizing
>> by expertise level needed will help people choose which talks to attend.
>>
>> I agree that some talks fall under multiple traditional categories. So
>> maybe we can allow the speakers to assign multiple but predefined
>> categories, along with expertise level needed. that will be help I think.
>>
>>
>>
>>>
>>> 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.
>>>
>>
>> Upvotes are important. Gamification is not a huge issue. But upvotes can
>> be one parameter of judging. The reviewers should not discard a talk purely
>> based on upvotes. 
>>
>>
>>
>>>
>>> 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.
>>>
>>
>> This is needed. And from my experience, we should require the proposers
>> to submit a version of their slides (if any) when submitting the proposal
>> or within a given day limit and the content should be checked and made
>> changes to after every stage of review. Because more of then than not, the
>> slides will have contrast problem, font size problem, and in occasional
>> cases - violation of code of conduct. I've seen way too many times(not only
>> at PyCon) that speakers make some remark on stage(often as a joke in their
>> mind) that violates the CoC. We should take all possible steps so that that
>> does not 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?
>>>
>>
>> Ask speakers to submit a slide along with their proposal. Let them make
>> last minute edits, but make sure the edits are following the guideline.
>>
>>
>> If we have enough time, maybe a skype call with the speaker to judge how
>> good a speaker they are, can be arranged. I've seen it happen and it helps
>> with the quality of the talk. But this is something the editorial team can
>> take a call on.
>>
>> Just another thing, can I suggest that whenever the CFP team comes
>> across a gender or race related content in slides of rehearsal talks with
>> the speaker, they consult with the community? And also maybe make a
>> guideline for the speakers that mention compliance with the CoC? e.g. No
>> jokes like "this application is so simple that even my mother/wife can use
>> it" etc. (This will sounds wildly off-topic, but trust me, I've heard this
>> on stage in front of hundred of people where the context of the talk was
>> nowhere near this comment. And more often than not these gets overlooked on
>> the review stage.)
>>
>> Of course I don't mind the decision taken by the editorial team if it
>> takes diversity as a parameter of judging the talks. It can only help and
>> make things better. PyCon US has a diversity statement that helps -
>> https://us.pycon.org/2018/about/diversity/ and also a detailed CoC -
>> https://us.pycon.org/2018/about/code-of-conduct/
>>
>> CFP is one of the most crucial part of organizing a conference that makes
>> or breaks the quality of the conference for the attendees. So nothing is
>> less important here. Let's try to come up with a framework to review talks
>> that ensures best quality for the attendees.
>>
>> Cheers.
>>
>>
>>>
>>> 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,
>>>
>>> _______________________________________________
>>> Inpycon mailing list
>>> Inpycon at python.org
>>> https://mail.python.org/mailman/listinfo/inpycon
>>>
>>>
>>
>>
>> --
>> Thanks,
>> Bibhas Debnath
>> http://bibhas.in
>>
>> _______________________________________________
>> Inpycon mailing list
>> Inpycon at python.org
>> https://mail.python.org/mailman/listinfo/inpycon
>>
>>
> _______________________________________________
> Inpycon mailing list
> Inpycon at python.org
> https://mail.python.org/mailman/listinfo/inpycon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/inpycon/attachments/20180416/b23e0b5d/attachment-0001.html>