Re: [DRAFT] EmacsConf 2020 Call for Proposals

[Amin Bandali]

Hi Karl, all,

emacsconf@Karl-Voit.at writes:

> Hi all,
>
> Amin Bandali (bandali@gnu.org) wrote:
>
>> emacsconf@Karl-Voit.at writes:
>> 
>> > Amin Bandali (bandali@gnu.org) wrote:
>> >
>> >> 1 Important dates
>> >> =================
>> >> 
>> >>    CFP opens              August 17, 2020          
>> >>    CFP closes             September 30, 2020       
>> >>    Speaker notifications  October 24, 2020         
>> >>    Schedule published     November 7, 2020         
>> >>    EmacsConf 2020!        November 28 and 29, 2020 
>> >
>> > Is there a reason why CfP closing and Speaker notifications are one
>> > month apart?
>> >
>> > If not, as a potential speaker I'd prefer more than one month for
>> > preparing the talk.
>> >
>> > Without knowing your experience from the previous EmacsConf events,
>> > I'd say that one week of potential CfP extension and one week for
>> > acceptance and notification should be sufficient. At least I'd say
>> > that we can manage the acceptance with one or two online meetings.
>> >
>> 
>> The reason is I thought I'd give us more time, compared to last year
>> where there was only one week between the CFP closing and sending out
>> the speaker notifications.  I thought I'd give us more time this year.
>> Did I overcompensate?
>
> What was the issue with last year's decision week? Was there a
> specific issue associated?
>

Unfortunately I don't quite remember anymore.  I don't think there was
much of a real issue, besides me feeling a bit overwhelmed.  That said,
this year we have more organizers onboard, which will hopefully greatly
reduce the workload on any one person.  So, if y'all are fine with the
one- or two-week speaker notification window, that's fine by me.

>
>> Do you suggest we move speaker notifications to October 14, to allow us
>> one week even if we end up extending the CFP by one week to October 7?
>
> Yes, this would be my approach. Again: I don't have EmacsConf orga
> experience. However, I was in the orga team for https://linuxtage.at
> for a couple of years. I try to transfer some experience from this
> event to EmacsConf but I don't want to change anything that already
> worked out good.
>

Thanks for the clarification.

>
>> That would probably be fine by me, especially if we can get started with
>> looking at the submissions we receive by September 30, rather than
>> waiting for the CFP to fully close before beginning.
>
> True.
>
>> To be sure, can you include a concrete complete timeline with all the
>> dates you propose just so we are all on the same page, Karl?
>
> Sure. I just moved the notification date to the 14th of October as
> you suggested:
>
>    CFP opens              August 17, 2020          
>    CFP closes             September 30, 2020       
>    Speaker notifications  October 14, 2020         
>    Schedule published     November 7, 2020         
>    EmacsConf 2020!        November 28 and 29, 2020 
>

Thanks.  I will go ahead and update the CFP with the new date.

>
> Optionally, we could decide to move the schedule publishing date to
> a prior day as well. I don't know if we expect much conflicts or
> effort here. However, with a fixed schedule, we're able to advertise
> with specific talks or the whole plan.
>

Yeah; I'd imagine the schedule publish date is in a way slightly less
critical for speakers.  But indeed, the sooner we can finalize a
schedule the better.  That would involve communicating with the speakers
about any potential times during the conference days where they may not
be available.  Actually, I think we should definitely ask for that in
the submission page, to make sure we don't have to email each submitter
one-by-one after the fact.  We can of course get in touch with them on a
case-by-case basis if we really need to.

>
> Do we expect issues caused by accepted speakers who reject their
> talk after being accepted from your experience from past
> conferences?
>

I think we had two instances of that last year, if I recall correctly.
While I was sad to see folks withdraw their submission, it is completely
understandable that people's availability changes.  And I don't think it
posed much of an issue for us, given that we already had *a lot* of
other talks scheduled for that one day.

[...]
>> 
>> We haven't yet discussed anything for this year, but judging by our
>> experience last year, I strongly think we should definitely have some
>> prerecorded talks.
>
> How hard was it to convince speakers to pre-record? Or were the
> pre-recorded talks the preferences of the said speakers?
>

Not very hard.  I seem to recall that most people helpfully prepared and
sent us a prerecording of their talk.  If I'm not mistaken, all of the
lightning talk speakers sent us a prerecording, which was awesome.  Some
of them in addition to sending a prerecording opted to present live, and
only fall back to the prerecording if absolutely necessary (e.g. due to
critical technical issues), which thankfully didn't happen last year.
I'm hoping to see a similar pattern this year.

>
>> I think we ask all Lightning talk speakers to submit a prerecording of
>> their talk.  As for Standard and Extended talks, we ask the speakers to
>> either submit a prerecording or otherwise do a tech check with us before
>> the conference, to make sure we are all on the same page and hopefully
>> reduce the likelihood of issues on the day(s) of the conference.
>> 
>> Thoughts?
>
> I'm not sure if "please do a pre-recorded talk" is a burden which is
> too high. I myself have never pre-recorded a talk so far. I'm
> interested enough to try but I can think of speaker who do not want
> to add this learning experience to the preparation effort.
>
> Therefore, it should probably an optional thing we can ask our
> speakers for in the CfP: Would you be able to pre-record your
> contribution so that it results in a video?
>

A burden in what sense?  From a technical point of view, there are
plenty of readily available and easy to use free software tools for
recording one's screen plus mic audio, some of which we had listed on
<https://emacsconf.org/2019/tips/>.  In terms of preparation efforts, I
think it is quite reasonable for a lightning talk.  For the longer
Standard and Extended talks, I understand there would be more effort in
terms of planning and potentially video editing involved, which is why
we are giving people the option of not submitting a prerecording if they
will instead do a tech check with us before the conference.

That said, I guess it would be fine to not make prerecording mandatory
for lightning talks, so long as people do tech checks with us, and we
receive at least *some* prerecorded lightning talks that we could play
back on the stream while we resolve technical issues, like last year.

Thoughts everyone?

>
>> >> 4 Submission
>> >> ============
>> >
>> > Is there a policy on orga team members and talk submissions?
>> 
>> There has not been a concrete discussion, but how we did it last year
>> was to have people email <emacsconf-submit@gnu.org> with their
>> submission, and it worked out reasonably well.  Sacha and I gathered all
>> the emails and went through them and selected/scheduled the talks.
>> 
>> Our <https://emacsconf.org/2019/organizers-notebook/> from last year
>> lists "Consider anonymized conference submissions to reduce bias." as a
>> possible improvement.  I agree, and I think we could make that happen.
>
> Certain topics are specific enough that you would recognize my
> topics for example ;-)
>

True :-).  I guess reasonably anonymous.  Complete anonymity would be
nearly impossible to achieve, given that we will be judging people's
abstracts and writing.

>
>> So, my thinking is that for this year, now that we have more organizers
>> onboard than just me and Sacha, I can act as a proxy receiving the
>> submissions sent to <emacsconf-submit@gnu.org>.  I will then collect and
>> relay to you all the submissions, but without the name and email of the
>> speakers, so the selection of the talks could be done in an anonymized
>> way.  As for me, since I will necessarily see the names and emails for
>> each submission as I collect and process them, I will not participate in
>> the selection of the talks.  Also, I can also keep an eye on things like
>> if any of you and up submitting your own talk, I'll make sure to have
>> someone else review your submission. :-)
>
> My take would be: organizers are allowed to hand in a talk but must
> not be part of the acceptance decision for it.
>

Yeah, makes sense.  That's included in what I'd proposed. :-)

>
> FYI: I don't know if I do have a suitable topic for this year - I
> just wanted to know the policy.
>

No problem!  Just putting it out there, and the "you" was applicable to
all organizers.  If any organizer submits a talk, I'll be sure to have
another organizer review their submission.

>
>> Also, I wasn't sure how much of the above we should include in the CFP
>> and how much we should mention on the site or in separate announcements,
>> since the CFP is quite long as is.  I definitely think it will be
>> valuable to talk about and post to emacsconf-discuss with details about
>> these policies/decisions in the interest of transparency.  For instance,
>> SeaGL (the Seattle GNU/Linux conference) published an entry on their
>> site about their talk selection process for their 2019 conference:
>> <https://seagl.org/news/2019/11/04/talk-selection-process.html>.
>
> I would not mention it on the CfP since all persons that are
> affected are reading on this mailing list. In order to make the
> policy transparent, I would mention it on the web page only.
>

Ha, I'm not sure if we can count on everyone reading emacsconf-org,
since it's a very recent addition, but emacsconf-discuss would be a more
reasonable assumption.  As such, I will not include those details in the
CFP, but will post them separately on the site, potentially accompanied
by a post on emacsconf-discuss.

>
>> Thanks again for the feedback, Karl; please keep them coming, y'all!
>
> You're welcome. I can't keep my mouth shut anyway ;-)

Haha. :-)

signature.asc
Description: PGP signature