add notebook

2 files changed, 183 insertions, 0 deletions

diff --git a/2023/organizers-notebook.md b/2023/organizers-notebook.md
new file mode 100644
index 00000000..01ee0c75
--- /dev/null
+++ b/2023/organizers-notebook.md
@@ -0,0 +1,106 @@
+<!-- organizers-notebook.md is exported from organizers-notebook/index.org, please modify that instead. -->
+[[!sidebar content=""]]
+
+This file is automatically exported from [/2022/organizers-notebook/index.org](/2022/organizers-notebook/index.org). You might prefer to navigate this as an Org file instead. To do so, [clone the wiki repository](https://emacsconf.org/edit/).
+
+
+# Table of Contents
+
+-   [Timeline](#org7f988ad)
+-   [Lessons learned from previous years](#org91fec84)
+
+
+<a id="org7f988ad"></a>
+
+# Timeline
+
+Last year, these were the actual dates:
+
+-   July 17: CFP sent
+-   Sept 18: Original CFP deadline
+-   Sept 30: CFP closed after extension
+-   Oct 1: acceptances sent
+
+
+<a id="org91fec84"></a>
+
+# Lessons learned from previous years
+
+
+## CFP and review
+
+-   Ask for public e-mail or contact information, IRC handle in CFP
+    -   Added to submit page.
+-   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 &ldquo;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?&rdquo;
+    -   sachac: I&rsquo;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.
+-   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.
+    -   sachac: Who wants to help me with this?
+-   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&rsquo;ll want to extend by only one week.
+-   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.
+-   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.
+    -   Let&rsquo;s see if we can do two streams again. That was fun.
+-   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&rsquo;s see if we can do two streams again. That was fun.
+-   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.
+-   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.
+-   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.
+-   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&rsquo;t have a schedule
+        yet, so we should go ahead and plan
+
diff --git a/2023/organizers-notebook/index.org b/2023/organizers-notebook/index.org
index 7e21eaea..337624ea 100644
--- a/2023/organizers-notebook/index.org
+++ b/2023/organizers-notebook/index.org
@@ -20,4 +20,81 @@ Last year, these were the actual dates:
 - Sept 18: Original CFP deadline
 - Sept 30: CFP closed after extension
 - Oct 1: acceptances sent
+* Lessons learned from previous years
 
+** CFP and review 
+
+- Ask for public e-mail or contact information, IRC handle in CFP
+  - Added to submit page.
+- 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?"
+  - sachac: 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.
+- 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.
+  - sachac: Who wants to help me with this?
+- 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.
+- 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.
+- 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.
+  - Let's see if we can do two streams again. That was fun.
+- 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.
+- 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.
+- 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.
+- 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.
+- 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