For discussion: change newsletter publication date to Friday
harding opened this issue · 20 comments
| Current | Proposed | Activity |
|---|---|---|
| SOD Fri UTC-10 | EOD Sun UTC-10 | Cut-off for additional news stories and merges (exception: security stuff) |
| EOD Sun UTC-10 | EOD Tue UTC-10 | Open PR |
| EOD Tue UTC-10 | EOD Thu UTC-10 | deadline for reviews, additional content, and edits |
| ~Noon Wed UTC | ~Noon Fri UTC | Publication |
| ~14:30 Thu UTC | TBD | Podcast |
(EOD = End of Day; SOD = Start Of Day)
Main motivation: under the current schedule, I tend to put off writing
the newsletter until the weekend. That worked fine when I was single
and weekends felt mostly like any other day to my work-at-home self.
Now I have a partner with a regular Mon-Fri job, so I want my weekends
free to spend with her.
Other advantages of this approach:
- At present, the podcast day conflicts with the #bitcoin-core-dev weekly
meeting. If we start publishing on Friday, the podcast will probably
not be on Thursday any more.
Disadvantages:
-
Change is annoying.
-
Friday is supposed to be one of the worst times to publish things as
some readers are already mentally checked out for the weekend.
However, the podcast could be Monday morning U.S. Eastern Time, which
might be a boost for it and could help bring attention back to the
newsletter topics.
Please discuss! I'm not in any rush to make changes, I'm not tied to
this particular proposed schedule, and I don't want to proceed unless all
regular contributors are onboard.
From a news perspective, publishing things on friday is a good way to have them missed, isn't it? People are busy thinking about the weekend, leave early, or are in timezones where it's already the weekend. If you have a persistent reminder like an rss feed, that's fine; but if the newsletter scrolled past on twitter, you might just miss out.
Not sure what "EOD UTC-10" is exactly; I'm going to guess 6pm, so ~0400 UTC the next day, and SOD as 10h earlier. Skipping out the versions where publication would end up on a weekend:
| cutoff | open pr | comment deadline | publish | podcast | writing days | comment days |
|---|---|---|---|---|---|---|
| Fri 1800 | Mon 0400 | Wed 0400 | Wed 1200 | Thu 1430 | Fri, Sat, Sun | Mon, Tue |
| Sat 1800 | Tue 0400 | Thu 0400 | Thu 1200 | Fri 1430 ? | Sat, Sun, Mon | Tue, Wed |
| Sun 1800 | Wed 0400 | Fri 0400 | Fri 1200 | Mon 1430 ? | Sun, Mon, Tue | Wed, Thu |
| Wed 1800 | Fri 0400 | Mon 0400 | Mon 1200 | Tue 1430 | Wed, Thu, Fri | Sat, Sun |
| Thu 1800 | Sat 0400 | Tue 0400 | Tue 1200 | Wed 1430 | Thu, Fri, Sat | Sun, Mon |
I'd probably go for "publish on monday" out of these, with a bit of extra time for comments, perhaps something like:
- Cutoff for news: Tue 1800 UTC (SOD Tue UTC-10)
- Open PR: Thu 2200 UTC (Noon Thu UTC-10)
- Podcast invites: Fri 1200 UTC ?
- Comment deadline: Mon 0400 UTC
- Publish: Mon 1200 UTC
- Podcast: Tue 1430 UTC
If that's not enough time for review/comments, push back to Tue publish/Wed podcast?
@ajtowns's "publish on Monday" schedule works for me, but it does seem to imply everyone else will have to work on Friday or the weekend.
everyone else will have to work on Friday or the weekend
I don't mind at all.
I'm also fine with reviewing on weekends.
I’m in a similar situation as @harding and I generally try to avoid looking at work stuff on the weekend. I would probably not review the newsletter at all, if the review days were only on the weekend. On the other hand, I have already been contributing less to review recently due to other additional commitments I took on, so maybe my time-preference does not matter that much for the review days.
I would generally prefer if the Recap didn’t fall on Thursday, since it collides with the Bitcoin Core IRC meeting and we usually schedule NYC BitDevs on Thursdays, and therefore tend to have office guests more often on Thursdays.
I had a quick out-of-band discussion with @bitschmidty about this and he asked me whether I was sure I'd want to be responding to review comments on the weekend. I'm ok with that, but it's not ideal. Given that and @murchandamus's comments, I'm again advocating for my original proposed schedule:
- Open PR on Tuesday (my time) == Wednesday UTC
- Additions and comments Wednesday & Thursday
- Final edits Thursday evening (my time) == early Friday UTC
- Publish Friday noonish UTC
Regarding @ajtowns concern about Friday publishing leading to lower readership, I think we could possibly try an experiment:
- Announce that we're experimenting with different publication days (without saying what day).
- Publish the newsletter to some readers on Friday
- Publish an identical newsletter to some other readers on Monday
- See what the difference in open rates is
That isn't a perfect experiment as that's multiple possible conflations, but it's something. If there's a huge difference in open rates, then maybe we put more effort into making Monday work. If it's a small difference, then maybe we use whatever works best for us.
Sounds like a useful experiment to run. While readership matters, but I would prioritize sustainability above all other considerations. Acknowledging my own dwindling participation in the process, I think given this newsletter's bus factor, I would support whatever Dave/Mike thinks is the best schedule for them.
"Friday noonish UTC" is Friday 10pm here, meaning it'll probably sit in my RSS feed until Monday anyway, so at least personally, it's the same thing :) If it were me, I'd still change "Publish Friday noonish" to "Publish Monday noonish" (keeping the other times the same) though. Moving the recap to the start of the week would be already a good win here too.
I'd still change "Publish Friday noonish" to "Publish Monday noonish" (keeping the other times the same)
It feels like a disservice to our audience to have a completed newsletter, which might include timely information like security announcements, and to sit on it for a few days because we want more views from our least dedicated readers.
I think we should run the experiment to see whether there's a major difference between Friday and Monday (which, alas, does mean that we'll be delaying news for some of our readers on at least one occasion, making my previous argument a hypocritical). If there's not a major difference, I think we should choose the schedule that's most convenient for us. If there is a major difference, then we should discuss it further.
It feels like a disservice to our audience to have a completed newsletter, which might include timely information like security announcements, and to sit on it for a few days because we want more views from our least dedicated readers.
If a vulnerability gets released the day after a newsletter is published, it'll still be a week before it's covered in the newsletter no matter what day it's published. Doesn't make sense to me to worry about a few days delay any which way for optech newsletters. (Likewise for if you spend a week or two reviewing a post before doing the optech write up; it's less timely, but the higher quality of the write up is much more valuable) If you want really timely updates, you should go to the source, not the weekly newsletter?
(Which is just to say (IMHO) that you shouldn't feel bad about it; not that you shouldn't release on friday if that makes you feel good!)
I think someone brought this up before, but if the newsletter is published on Friday, doing the recap on Monday would also draw additional attention to it. I would suspect that a lot of people track the newsletter via email or RSS, so it would land in their inbox either way. I support running the experiment, but my gut feeling is that Friday should work out fine.