summaryrefslogtreecommitdiffstats
path: root/2023
diff options
context:
space:
mode:
authorSacha Chua <sacha@sachachua.com>2023-06-16 22:56:12 -0400
committerSacha Chua <sacha@sachachua.com>2023-06-16 22:56:12 -0400
commitea951d2ad0c0f1cd74282354d79e54c86d6822ae (patch)
treef5de806c55c423c4bb042b38f26aef3e1db69308 /2023
parent1276c4f3a2707cf8f3c7ae6936de3b58144d49fd (diff)
downloademacsconf-wiki-ea951d2ad0c0f1cd74282354d79e54c86d6822ae.tar.xz
emacsconf-wiki-ea951d2ad0c0f1cd74282354d79e54c86d6822ae.zip
add notebook
Diffstat (limited to '')
-rw-r--r--2023/organizers-notebook.md106
-rw-r--r--2023/organizers-notebook/index.org77
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