Re: Draft call for participation (maybe June 26?), lessons learned from last year

[jc@tlo]

Hello Sacha,

Thank you for starting all the preparations.

> On Jun 17, 2023, at 12:00, Sacha Chua <sacha@sachachua.com> wrote:
> 
> Hi everyone!
> 
> Quick update from last e-mail about proposing a timeline: Looks like
> we're good to go for EmacsConf probably Dec, with varying availability
> leading up to the conference. We're still ahead of last year's schedule,
> slowly ramping up. Let's see what we can pull off!
> 
> Started drafting the call for participation. Please feel free to review
> and tweak:
> - https://emacsconf.org/2023/cfp/

“This year, we’d like to experiment with accepting proposals throughout the CFP 
process, particularly for 10-20 minute talks. If there are similar proposals, 
we’ll work with people so that the talks can cover different facets.”

How is that different from the previous years?

> - https://emacsconf.org/2023/submit/
> - https://emacsconf.org/2023/ideas/

There are 2 “2021” links, which point at empty (idea-less) pages.

Is there a reason why the pages were not used in the past 2 years?

> - https://emacsconf.org/2023/
> 
> Shall we try to get the CFP ready by June 26 (next next Monday)?

Yes :)

> Lessons learned from last year's CFP and review phase:
> https://emacsconf.org/2023/organizers-notebook/
> 
> - Ask for public e-mail or contact information, IRC handle in CFP
>  - Added to submit page.

Nice.

> - Be even more stringent about the 10/20/40-min splits. A lot of
>  speakers still default to the 20- or 40-min formats without
>  providing us shorter formats, and that puts strain on our schedule
>  and requires us to use a different template for the notification
>  (which can be confusing). We need to stress that not respecting the
>  format makes it harder not only for the organizers, but also for the
>  speakers themselves (since they will have to rethink their
>  presentation). Maybe we can have an e-mail template for a quick
>  reply that says something like "Just in case we need to squeeze
>  talks into shorter times, could you please also propose an outline
>  for a possible 10-minute talk that could get people interested in
>  your topic and point them to where they can find out more?"
>  - I'd love to experiment with rolling acceptances. If people have a
>    good 10-20 minute version of their talk and we want to accept it in
>    the program, it would be nice to be able to say yes early so that
>    they can start working on it. We can work with any duplication of
>    content in later proposals.

+1

> - Two people is the sweet number of reviewers to have for the
>  proposals before sending the notifications, and there’d be
>  diminishing returns with more. Two is enough to release the pressure
>  on SCHED, verify the metadata (esp. speaker availability), and
>  suggest a different ordering where appropriate. It can take a long
>  time to comb through the proposals (roughly 10 proposals per hour),
>  and whilst it’d be difficult to justify more in-depth reviewers,
>  other orgas can do a shallow-pass to catch red-flags or discuss the
>  submissions as they come in. Other organizers can always chime in on
>  topics they particularly care about so that their encouraging
>  comments or suggestions can be included in the acceptance e-mail.
>  - Who wants to help me with this?

You mean for the proposal review process?

If yes, I’m in.

> - We extended CFP-end by two weeks this year, but that made it coincide
>  with speaker-notifs, and that’s awkward.  Next time, we should only
>  extend the CFP by one week to avoid having to scramble with the
>  schedule until the very last day.
>  - Proposed dates in https://emacsconf.org/2023/cfp/ have similar
>    spacing, so yeah, we'll want to extend by only one week.

+1

> - Some people assume that they have to suggest longer formats even if
>  they intend their talks to be 10′ or 20′.  We should change the
>  wording on the CFP to ask them to only provide alternatives for
>  shorter formats, not longer.
>  - Added a brief note to CFP.

I think the current wording is an incentive to push the presentation to 40 
minutes:

“As you think about your talk, consider what you can share in:
- Up to 10 minutes total...
- Up to 20 minutes total...
- Up to 40 minutes total...

..."


What about something along those lines:

“As you think about your talk, consider whether you can squeeze everything in:
- Up to 10 minutes total...
- Up to 20 minutes total...
- Up to 40 minutes total...


Think of 20+ minutes presentation as extensions of the 10-minute presentation.

If you are aiming at the 10-minute presentation, just write an outline of what 
you plan to talk about if you have 5-10 minutes.

If you’d like to propose a longer talk, add an outline of what you might add to 
the first part if you had more time to present (up to 40 minutes, including 
Q&A).

Here are examples for the 3 types of presentations:

        • up to 10 minutes: quick demo of the abc package working together with 
xyz package.
        • up to 20 minutes: same as above, with some customization options to 
accommodate a different workflow.
        • up to 40 minutes: all of the above, including modifying the behaviour 
of the package in order to add something new.

..."

What do you think?



> - It was hard to squeeze all the org/hyperbole talk on day-1.
>  Generally, the people who submit these kinds of talk come from all
>  over the world, and US mornings are more accommodating than US
>  evenings when it comes to timezones.  We might consider having two org
>  *mornings* rather than an org *day*; it would give us more flexibility
>  with those talks.

+1 (maybe ask the org people to organize a parallel org conference ;-)

>  - Let's see if we can do two streams again. That was fun.

+1

> - We’re starting to reach critical mass on the org-talks.  We might want
>  to consider splitting the org-talks and the dev-talks into two
>  distinct events to allow them to grow independently.
>  - Let's see if we can do two streams again. That was fun.

Haha! +1 (maybe ask the org people to organize a parallel org conference ;-)

> - We should associate time-of-day with CFP-deadline; otherwise, the
>  scheduler has to be on edge until the very end of the day.  It’s worse
>  this year because we made CFP-end coincide with speaker-notif, so this
>  might not be as much of a problem next year.
>  - If we do rolling acceptances and we extend by at most one week
>    instead of two, this should be fine.

I was not involved last year so I’m not sure I understand the issue, but +1

> - It’s easier for us to extend beyond 5pm than to go before 9am
>  (especially for the West coast).  Extending beyond 5pm puts strain on
>  European organizers and volunteers, though.
>  - Time pressure should be alleviated with multiple streams.

+1

> - Sometimes, ikiwiki on front0 took a lot of time to process the new
>  commits.  sachac assumed this is due to a faulty regex parsing.  We
>  should be able to find out more by looking at the logs from ikiwiki
>  after a slow commit.
>  - Seems speedy at the moment.
> - Ask for preferred timezone in CFP
>  - Added to availability.

Nice.

> - Check with John Wiegley re: schedule - we always happen to coincide
>  with his work trips
>  - I checked with him and the people at his work don't have a schedule
>    yet, so we should go ahead and plan

Nice.


-- 
Jean-Christophe Helary @jchelary@emacs.ch
https://traductaire-libre.org
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/