diff options
| -rw-r--r-- | 2021/meetings.org | 412 |
1 files changed, 412 insertions, 0 deletions
diff --git a/2021/meetings.org b/2021/meetings.org index e33e8e38..21c34688 100644 --- a/2021/meetings.org +++ b/2021/meetings.org @@ -3203,3 +3203,415 @@ rganising the names on that page in a more relevant fashion? pad, for e-mailing out? - Braindumps welcome =) - Week after: public meeting/recording +* Some notes from the debrief after last year's conference +Proceedings: + +** On tech +*** Observations +- BBB worked better than last year's Jitsi. It was nice to be able to set up several moderators and have consistent URLs. This year's Jitsi + seemed more polished than last year's Jitsi, so maybe they've resolved their technical issues, but it was still nice to have a reliable host. +- amin generally happy. Leo ran into technical difficulties with BBB, also some speakers may have had Internet connectivity issues or BBB issues +- gstreamer seemed to hold up fine; might want to figure out how to switch scenes or send only the BBB audio + - amin: Very nice, happy about that, gstreamer not as harsh on laptop. +- low-res stream was handy, and running the ffmpeg command on live0 was fine + - amin: Super happy about that +- Audio check with a decibel meter was great (sachac) +- ffmpeg splitting had an i-frame issue when using -c:v copy: + https://superuser.com/a/704118 and + https://trac.ffmpeg.org/wiki/Seeking#Seekingwhiledoingacodeccopy + - https://etherpad.wikimedia.org/p/7XrMLmwLBQ0mp2RQ8S6l - technical + notes, looks like we can adjust -ss to the keyframes that happen + every 4 seconds in the captured stream +- karl: BBB doesn't audio-level as well as other platforms. bandali + was loud, zaeph is not as loud, need to manually adjust. Other web + conference platforms handle it better. + - zaeph: BBB seems to aggressively add gain. Video fairly + low-quality when viewing both webcam and screensharing, probably + lost a lot of pixels. Recording quality is not that great, big + quality difference compared to prerecs. + - Might need to be more active shifting between webcam+screenshare and just screenshare. + - OBS can stream with picture-in-picture, maybe, but a burden for live presenters if there are too many technical hoops + - Cheese etc. can display their webcam while they're sharing their desktop + - BBB didn't handle multi-monitor sharing desktops well - one of the presenters couldn't share just one monitor's desktop + - Bit wasteful use of screen real estate. Jitsi might do it better. + - Focusing on speaker webcam during Q&A might help. +*** Improving +- Can test improvements throughout the year instead of waiting for next conference +- System audio out isn't captured by BBB. Maybe presenters can set up a virtual audio loopback device and test during the tech check? +- Play intermission audio from Emacs, naturally ;) +- Normalize audio for prerecs? + - We could also use a compressor on all the ones which are 'voice-only' (i.e. not those with music/video in them) +- Re: decibel meter, it might have been even better to use PulseEffects which would have allowed bandali to apply auto-gain and a limiter to the sound output of selected apps on his sytems (mpv & FF for BBB). ( https://github.com/wwmm/pulseeffects ) + - In my experience, it very rarely misbehave. + - It could also save us the trouble of applying gain to the talks which happened live. +- Make sure I've copied the right low res command line into my notes, and test it again +- Start streaming even earlier if possible, so that there's plenty of room to stress out about mirroring, update the status page, etc.=) +- Write a script to curl the total live viewers across streams. + - I prototyped something during the breaks, but gave up halfway because making it with scrapy would have been much faster than what I'd been doing. + - live0.emacsconf.org tracked peak viewers, so it was fine to not worry too much about it +- Find a better solution for streamers to toggle mute/unmute for BBB and the stream + - As a temporary backup, I visualised the stream's audio spectrum to make sure that, when bandali was speaking, I could see speech waveforms on the stream. + - mpv --config=no --quiet --vo=tct --lavfi-complex='[aid1]asplit[ao][a1];[a1]showwaves=mode=cline:colors=white:rate=25[vo]' "https://live0.emacsconf.org/main.webm" --mute +- Have an easy command to show local time. + - On GNU/Linux: + - watch TZ=America/New_York date + - http://www.tmzns.com/ looks nice but it doesn't understand "UTC" as a time-zone and you need to find a matching city +- If we find a way to publicly serve the icecast dump, I wonder if we can make it quickly viewable with offsets on the day of, like with videojs-offset, so that people can access quick replays of talks they've missed +- It might be interesting to have an overlay of time - talk title - speaker name - info page etc., maybe on the bottom of the stream. That way, people tuning in mid-stream can see what's playing. People would need to plan for that in their recording. +** On emails +*** Observations +- bandali struggled a bit getting all the speakers in the Bcc, always seeming to forget some of them. +*** Improving +- Create lists. +- Have one source of truth (in the private wiki), and use that to prepopulate the emails. + - TODO sacha: export uniquified list for copying, also do mail merge (maybe based on https://github.com/jkitchin/jmax/blob/master/mail-merge.el ) + - index.org doesn't contain all the e-mail addresses at the moment. Maybe an org-capture for grabbing the initial submission from the e-mail might be nice in the future. +** On time-keeping +*** Observations +- We managed to stay on schedule throughout the entire conference with minor adjustments. + - This was totally surprising because I expected the schedule to be + penciled in, given our experience last year with dropped talks and + technical issues. + - Come to think of it, automatically scheduling all the sessions + with some nifty Org code worked great for both planning (do we + have enough time for the talks?) and timing on the day of the + talk. In 2019, we relied on playing pre-recorded talks with no + live Q&A in order to manage our time, playing them ahead when we + needed to cover technical issues and sticking all the rest at the + end of the conference when we reached the end of the time. In + 2020, we actually followed a plan instead of adjusting on the fly, + and it was great! +- Check-ins were done sufficiently in advance (we said 15 minutes, but + ~30 min before was nice). +- Problems with check-in were minimal due to prior tech-checks with + the speakers. Thanks to all the people who helped with tech checks, + and to Amin's repeated nudges to do tech checks! +- Small adjustments were pushed when needed. +- The pre-recorded talks had set durations, which removed variables. +- zaeph watched time like a hawk. +- zaeph even called people thanks to the emergency contact information + we collected during the tech-checks. + - Karl is curious: how often did you call people via phone? + - 5 phonecalls total. +- We allowed for 3 minutes of buffer between talks, which let us juuuuust squeeze in the talks with a little bit of overtime. +*** Remarks +- Time-keeping on D1 was good, but on D2, it was great. +*** Improving +- More buffer might have been nice for questions, but then we would + have had to say no to talks. Switching between talks was smoother + last year because bandali used OBS to stream prerecorded videos, so + he could join the other conference room while the prerecorded video + was playing. But OBS killed his laptop, so that's why he used + gstreamer. Maybe we can look into a way for gstreamer or another + tool to stream a file while bandali joins the next room? Then we + don't have the echo test showing up in the stream, and bandali can + more smoothly give the go-ahead off-camera. +- People had strong fear-of-missing-out despite the heads-up about + prerecorded presentations. If we have the opportunity to do so, it + might be good to build in more breaks. +- We can make a list of pre-recs and their durations to avoid bugging + Amin all the time. It was challenging for Amin to deal with late + pre-rec submissions, but maybe he can stash the submissions on the + shared server, or have a shell script that can list all the + filenames and times and copy them to a file on the server. He made + me a list of prerecs that I could use to quickly check which talks + were actually available, so it just needed duration to be perfect. +- I wonder what an Org command for quickly adjusting timestamps could look like... What would that interface be? + - Don't we have a way to shift <...>--<...> timestamps by min ? + - Oh, we recalculate the timestamps for all talks based on + MIN_TIME properties, actually, so I'm thinking more along the + lines of an interactive command that lets me say that [talk] + actually started at [time] and then it adjusts all the talks and + republishes the schedule files and pushes them. I already have + something that goes off the FIXED_TIME property, so I think it's + more like a matter of kicking it off with fewer keystrokes and + making it part of the talk transition process. And maybe + something that sets a QA_START property for the timestamp of the + Q&A. +** On starting early + Observations Starting early caused frustration for some people + who had written down the times. We had disclaimers, but of + course people skipped right over them. =) Explanation Our + opening remarks were designed to buffer technical problems, but + we didn't have any. Well, I was stressing over the 480p thing, + but that wasn't worth holding up the talks. Remarks It's better + to be early than late during those events. (Well, maybe... + People regret missing out on talks they were looking forward + to, but we also don't want to run way past our time.) Improving + The problem was addressed live by prepending all the times with + ~; we could do the same next year. Since we were great at + keeping time this year, we might do away with with the + buffering time at the onset. *knocks on wood* +** On accessibility +*** Observations +- jcorneli and dto did an amazing job of describing the talks. +- jcorneli and dto had to sign off at times, and despite calls for volunteers in #emacsconf, nobody took over. +*** Improving +- Get more volunteers on-board beforehand. +- (possibly) ask volunteers to commit to various morning/afternoon + shifts ahead of time so that there is always at least one planned + volunteer, but preferably two "on duty". I.e. a simple schedule for + volunteers. + - I said I was probably mostly available for day 1, but day 2 might + be a bit tougher. I can make sure people are more comfortable with + checking in people in case kid stuff comes up +- I recommend breaking things into two-hour shifts, the transcribing + is a bit brain-heavy and kind of burned me out. +- Choosing particular time blocks would make it a bit easier to + coordinate "interruption free" times with family/housemates. (This + was a big factor for me on Sunday afternoon, multiple kids and dog + plus other people. Next time I'll probably commit to transcribing + more on Saturday and then Sunday morning, and see if we can find + someone besides me for Sunday afternoon) + - Hah, there are no real interruption-free times with a 4-year-old +- Get OK from jcorneli, dto, and other volunteers to add the + timestamped logs as possible descriptive text for the videos as + temporary subtitles while there are no proper transcripts. + - (ok from dto) +- have opportunities for different levels of time sensitivity of + commitments (e.g. stuff people who can just drop in sometimes can + usually learn to do pretty easily and that helps). +- A green-room could be fun, inviting speakers a "quiet" place to + talk about things before they "happen", answering questions, even + FAQs for speakers on a priority then becomes both a thanks and an + easy starter voluntering opportunity with obvious perks built in. + - I thought about having speakers check into a green room so that + the audio alert from it could be always available, but I thought + that having them check in directly to their room would be less of + a hassle than two successive echo checks. It was nice to have + zaeph join me as I checked in some people. +- Cuttings streams as point-in-time markers collectievly assembled + could provide a path to CI/CD flows toward speach-to-text during the + event, or at least faster and eventually less manually after. + - The pad had timestamps with some formatting differences, so I was + able to pull them out and set them as properties. I ended up + manually reviewing the stream to see where to set the timestamps + anyway, since that felt like it might be easier. It mostly worked + except for the part where I accidentally included the prerec that + followed one of zaeph's talks. =) Maybe if we displayed a clear + timestamp at the start of the stream and then had some code that + would take that timestamp and calculate the correct offset for any + timestamps from the file... Yeah, that could work. + - So, like, a step in the check-in process that tells Emacs "All + right, this talk has started" (or "Oops, this talk started at X + time and I was distracted"), and it announces it to IRC and + stores the timestamp, and maaaaabye even spits out the ffmpeg + command to extract the previous talk out of the Icecast dump +** On the pad + Observations The pad was opened by many people. I believe we + peaked at 145. On top of being opened, many people used the + pad. People appreciated being able to immediately access links + and notes from previous talks publicvoit kept the pad up to + date and super clean. It probably was quite exhausting to do + all this by himself, even though he had some help from ??? (b- + something, I've closed the query in IRC. :( ) Karl was the only + person who contributed to the time-stamp logging. As long as + Karl is at the event, that's perfectly fine but I had to leave + earlier because of time-zone shift and exhaustion. Clearing pad + colours periodically helped speakers focus The Q4: Q3: Q2: Q1: + template that evolved by the end of the conference was really + handy, since experienced volunteers could keep adding slots and + people could add in the convenient blank spots. Might be handy + to keep a copy of the boilerplate ready for pasting in. The pad + got zapped once, and the Wikimedia Etherpad didn't have an easy + way to restore to a certain point aside from copying and + pasting. If there's another pad with good revision history + management, that might be worth checking. Winding back a few + minutes and cutting/pasting the contents back to the current + pad, worked okay in a pinch but probably isn't ideal. Karl + agrees: restoring content once for the whole event with ~140 + people reading/contributing is actually much better than + anticipated. However, when there is a better alternative: let's + switch. Reverse-chronological order worked better than + chronological order for typing things in. I don't know if + chronological order might be manageable if we have a Q1: Q2: + Q3: Q4: template so that people aren't accidentally pressing + enter in the middle of someone else's question. Also, + chronological might require more scrolling on the presenter's + part, and the questions move when people type things above + them. Karl: I don't see any advantage with + reverse-chronological order but several disadvantages: People + had hard time to add a new itemize-item at the top: I had to + fix many questions that were normal paragraphs. This cancels + out the main reason we had for starting the reverse order IMHO. + Everybody had to learn not to use the "normal" order of things + people are doing all the time: from top to bottom. Most + speakers on day one started with the topmost question for + answering as well. Karl: If the majority thinks, this is worth + the effort, let's continue with that. Otherwise, my guess would + be that having a few Q1, Q2, Q3 (in order), people will be fine + adding questions. I think some IRC questions fell through the + cracks. For people only posting questions on IRC, we would need + to teach them to prepend them with something like "Q:" or + similar. Otherwise, IRC is hard to skim for questions among the + chitchat. +** On the topic of the talks +*** Observations +- Plenty of topics. +- Varied topics. +- People enjoyed the more personal talks. + - shoshin's talks. + - Pierce Wang's talk. + - My user/developer story. + - People liked the face-to-face. + - I'm so happy about that! I think people's stories are an important part of humanizing Emacs, and I'm glad we made space for those talks. +- People liked the sequence of talks, too, which meant the time that we spent fiddling around with the flow of the talks worked out. +- Even though it was tough for speakers to squeeze their talks into even smaller timeframes than they asked for, I think it worked out well that people got a taste of lots of different topics + Q&A time afterwards. I'm glad we were able to accept all the talks. As Karl pointed out before, most conference committees have to make tough decisions about which talks to accept and which talks to reject. If we can figure out a way to make it happen time-wise, I'd like to make our role more of accepting as much as we can, and then sorting and shaping talks so that they flow well together. +*** Questions +- Should we develop the idea of tracks? + - This year, we had an org-mode track which allowed people interested in org-mode to tune in at a precise time, and have many topics that could interest them in quick succession. + - Parallel tracks split organizer attention and result in high fear-of-missing-out; not sure we could have pulled it off this year, but maybe with more practice? I think it would be super-cool to have workshops if volunteers wanted to do them, like an Emacs Lisp workshop or an Org workshop where people can just drop in and ask questions or show stuff. Gotta have people, though. + - dto: I like the workshop idea + - Karl would love to see a switcher-track since approx. 97% of all people I work with are using vim and still do think that it's just about editing. Furthermore, a switcher-track overlaps with the newbie-track - so it's probably a matter of track-name marketing ;-) +*** Improving +- Finding more use for the alt-stream. + - ~30 people, 10% of the stream, like I thought! =) Didn't have the brainspace to pull it off on the first day, and narrowly had enough brainspace to do it on the second day. Might be able to do it more easily next time, now that I've remembered my laptop has a mute shortcut. That was only an issue because wasamasa couldn't play a game full-screen while looking at the Etherpad. Other speakers would have been able to look at the Etherpad on their own, so I wouldn't need to read things out to them and can stay muted for the whole time. It also tied me up attention-wise, so it was great that zaeph could handle checkins too (and I appreciated how he could drop in and say stuff). If I get bbb-recorder or some other virtual framebuffer-based streamer working next time, I might be able to run the alternate stream with less attention. + - Wouldn't it be amazing if next year we nailed the implementation of alternate streams and were able to pack in tons of talks, maybe with 10 minute summaries on the main stream and then extended demo/Q&A on the alternate streams... +** On coordination +*** Observations +Stellar coordination on #emacsconf-org. +*** Improving +- We lost contact with mplsCorwin during his talk because the rtmp stream was one-way. + - We should have told him to keep an IRC window opened. + - Phoning him did the trick, but it was definitely more stressful for the speaker than just casually looking at the IRC window. + - I had the wrong channel open and wasn't watching the right screen. Thanks so much for the call Leo! The personal touch, like a call from an organizer when things aren't going right, can be huge. +** On tech-checks +*** Observations +- We had a check-list to make sure that we weren't forgetting anything. +- Asking for emergency contact info was a great idea. + - It saved our butts many times this year. =) =) +*** Improving +- Filling a table with all the info we gather (pre-rec or live: Q&A: live or pad/IRC, contact information, IRCnick) + - Our private repo was a good start, but we didn't prepare enough for the format. + - I like formalized processes, even when their steps might seem a little pedantic. Often there are complexities that we have the opportunity to prepare better for "between the lines" given such orginization. Maybe tech check is an easy place to start? IDK. I'm going to be trying to take this approach to everthing now, having hit upon it over the course of the conference at. al. Can we have too much org? ¯\_(ツ)_/¯ +- It was nice being able to add things to the tech checklist, such as making sure speakers knew how to check in via IRC. +- Karl would like to be able to use a BBB room for tech-check so that we could share the load on those checks. +** On asking for pre-recs +*** Observations +- We pushed speakers to send us more pre-recs this year. +- As a result, we received more pre-recs (% ? I'd eyeball it at 60%) +- Speakers mentioned struggling with recording. Maybe we can provide more explicit help: here are the settings for recording with OBS, here's a tutorial for video editing, here's an ffmpeg example for stitching images/videos+audio together and converting them to the right encoding +*** Questions +- Pre-recs are nice for us, but aren't we losing a bit of interaction with the public? + - Especially if we're having more tracks in the future like org-mode, it's nice to have the ability to react to what was said before you (cf. the talks on org-roam) + - We encouraged interactions between talk topics by asking speakers to coordinate beforehand, and I think everyone took us up on our suggestions. Tech demonstrations are always a little nerve-wracking, so it's nice to have everything smoothly running. (And it's hard to properly focus on someone else's presentation when you're worrying about yours and whether it'll still work... =) ) +- If pre-recs have a negative impact on interaction with the public, do we feel capable of handling more live presentations? + - Some moments during the conference were particularly stressful: on the one hand, I couldn't take a pause for 3h straight on D2 because of the late check-ins. On the other hand, some other moments were particularly calm. I believe we've gained some valuable experience on this, and we might be better at this the next time. + - We can stress a little less about checkins knowing that we can either check people in during the playing of their prerec or say that the Q&A for them will be deferred, or by asking people to check in even earlier if they can. It would be nice to get their IRC nick during the tech check, so we can check if they're around. +- Short prerecs worked better than expected. Short prerec + live Q&A. 40-minute prerec talks are a little harder to stay engaged with +** On animation/hosting +*** Observations +- My style of animation seems to have gone well with the public + - Self-deprecating humour. + - Making fun of tech-problems. +** On check-ins +*** Observations +- Check-ins were done efficiently. +- Protocols helped us streamline the process so that 1) we didn't forget anything, and 2) we could get things done quickly. Final protocol: + - Say hello, thank them + - Check if people's mics/screensharing work + - Check screen readability + - Check live talk vs prerec preference, live Q&A vs IRC/pad, and whether they want to read the pad themselves or have Amin read questions to them + - Let them know that they can answer questions in any order and skip questions if they want + - Tell them Amin will join and then give them the go-ahead + - Remind people about personal information (especially Org) + - Coach people to start their segment by saying their name and a quick intro to their talk (so that Amin doesn't have to stress out about remembering pronunciations) + - Give them a brief heads-up shortly before Amin joins + - Start recording when Amin joins + - Track timestamp of start + - Announce topic in IRC + - Leave + - TODO: automate scheduling, announcement, publishing previous talk, etc. +- I like the ERC commands I made for sending people URLs and telling Amin who's ready where. =) They're in emacsconf-2020-private/index.org. +** On live Q&A +*** Observations + Check-in involved asking speakers if they wanted to do a live Q&A. +*** Improving +- Our tech-check should include if speakers want to do a live Q&A +- Letting speakers know that they're almost out of time + - bandali suggested warning them via BBB whilst keeping his mic muted to the stream + - Problem: Speaker are startled and look like they're hearing voices :o) + - A bell? A chime? Something instrumental? If BBB webcam video is visible, Amin can hold up a sign. + - fun video of time-boxing Ig Nobel talks you need to watch: https://www.youtube.com/watch?v=xAnVNXaa5oA +- sachac had a great idea of writing it in the pad, so that the speakers may know that they only have one minute/one question left. + - Yup, especially since most people were able to watch the pad for their own questions, and the ones who didn't were getting questions from Amin. +** On publishing the recordings +*** Observations +- Figuring out the timestamps and splitting up the bulk recording into individual talks/Q&A takes time +- We can satisfy the initial "Aaaaah! I want more!" by posting the + prerecs. If Amin keeps all of the day 1 prerecs in one folder, he + can just mv them into a public folder, and add any last-minute ones + as they come in. If we want to be super-fancy, maybe we can even + move them one at a time after each talk. although I think Amin likes + keeping them on that uwaterloo server, so it would be one more thing + he has to do. +- Slicing is actually pretty fast and can be done on a partial copy of + the stream, so we might be able to do it in the future. We can + quietly replace them with higher-quality versions if we want to. ** + Improving +** On publishing the Q&A logs (brought up by bhavin192) +*** Observations +- Some of the logs have lots of '+1' which are a tad useless now. +- We've mostly plopped whatever was in the pad in the relevant section on emacsconf.org. +*** Improving +- Process the logs to remove the extra stuff. + - It's definitely not a hgih-priority item, and I'd much rather have us on publishing the recordings as we have this year. (zaeph) +- Rethink the format. + - Go for a newspaper style. + - Questions in bold. + - Answer below with the name of the speaker prepended. +** On live viewership + ** Observations +- We peaked at ~400 viewers during RMS talks. + - dto: wow! + - Last year peak viewers = ~270 +- D1 averaged at ~340 viewers. (eyeballing) +- D2 averaged at ~250 viewers. (eyeballing) +** On asking feedback +*** Observations +- Viewers gave us quite a lot of feedback in the Other Pad™. +*** Questions +- How are we going to ask speakers for feedback? Etherpad/email + - Form to fill send via email? + - FOSS online form? + - (Off-topic: Do we have news from the Emacs Developer Survey?) + - I think the number-crunching from the Emacs Survey will take a while +** On having talks which could be construed as 'commercial product pitches' +*** Observations +- gmj`` on #emacsconf brought up the fact that Rainer König's talk + could have been associated to his Udemy course on org-mode (which + requires a fee). + - His Org talks are actually also available on Youtube for free. I + would have had no problem with Mickey Petersen plugging Mastering + Emacs update, too. +*** Remarks +- There's a general aversion to 'paying for stuff' in FOSS because it's often conflated with non-FOSS practices. + - This sentiment is problematic because it makes it hard for developers and community-figures to sustain themselves financially. + - FOSS has always allowed people to get paid for it; F doesn't mean $, but freedom. Also, it looks like the sentiment is shifting - more people are looking for ways to support the people who work on the stuff they like + - The systems of donations and patronage are the most widely accepted, but they're also the poorest in terms of results. + - Donations disproportionally favour prominent members of the community. + - The 'buy me a coffee' attitude downplays the amount of effort that goes into writing and maintaining software. + - A better solution for developers is project- or milestone-based financial goals: 'To develop feature X, it's going to take Y amount of money.' + - The idea is developed in https://sustainoss.org/ + - To quote François Élie, an influent FOSS advocate in France: + - Free/libre software is free once it has been paid for. + - Having a service industry around FOSS is what allows plenty of non-dev actors (educators, tech-writers, etc.) to sustain themselves. +*** Improving +- Develop arguments to use with people who conflate 'paid services' with 'non-FOSS practices'. +- Anticipate those problems by asking speakers how they sustain themselves in the FOSS world during the CFP. + - What would we do with the information? +** On the CFP +*** Observations +- People appreciated the nudge to talk to people who might be having imposter syndrome +*** Questions +- Do we want submissions to be anonymized next year? I think it adds quite a bit of load on the volunteer handling the incoming submissions. +- Do we want to experiment with the accept-as-much-as-possible approach next year as well? +** On BBB +*** Observations +- Audio quality was all over the place. + - BBB aggressively adds gain to participants, but it doesn't seem to be doing it in an intelligent way. +*** Remarks +*** Improving +- Prefer pre-recs? + - Has problems, cf. previous point on pre-recs. +- Find other tools? |