XSF Communications Team - 2020-11-04

Continuing discussion from the PR...

> We cannot handle more releases currently.

I understand that, and am certainly not asking for more frequent releases (since that would be a lot of work)

But at the same time, excluding content that is published and submitted before the deadline is not adding work

If the deadline for inclusion is 31st, please advertise that date instead, at least

I've seen a lot of news posted at "the start of the month", must be some psychological thing? Dunno. So there were plenty of times that we could have inserted one more link.

and I think we should

I think that "last day of month" is a giveaway given the name "October/September/etc news"

I'm not saying we should ever delay publication due to something coming up

There's always leeway, in this IETF case yes, better now than too late in the next one, indeed.

If "last day of the month" is the deadline, then please correct it here and in the announcements: https://user-images.githubusercontent.com/29168011/94992681-fe4d3d80-058b-11eb-8ddf-925fc8757ad0.png

and the final reminder should then obviously be removed before that point

For context my annoyance is partly because this isn't the first time this rule has bitten me. I announced Snikket with a blog post right before FOSDEM. A few days after FOSDEM, a newsletter goes out... the announcement wasn't allowed because of this "rule"

The result was that Snikket wasn't announced in the newsletter until... April

It's not like I care so very much that it was content I wrote, but more that generally emailing stuff to people that happened months ago should be something we aim not to do

I appreciate there was some changes to process after the FOSDEM one, so that was an unusual delay, and that hopefully won't occur again

> If the deadline for inclusion is 31st, please advertise that date instead, at least We do advertise that, right? Will take a look at the picture if thats bot proper. As said I am happy to make exceptions of course, as this time. Especially if there are events announced. However somewhere I have to draw a line to keep the workload clear. If there is a feature or client announcement. Thats usually not so pressing. I disagree on that "Newsletter = old news" argument. I guess its clear to everyone we are not Twitter. If they dont like this information they can stop subcribing. But so far numbers are growing. Many people are not involved into XMPP like we are I guess. Most things in there are not new to us, but many appreciate it. So, I think its fine that one can request "early" onboarding if news are really time depended. ✏

Hi SouL can you make a review this time? If not is fine, just that I know to wait

But may you push a tweet after release?

Hey emus, I'm sorry to say this but I'm struggling to find some free time lately. I know there have been some discussions here and on Github and I'll try to catch up, but I'm not sure I'll be able to review the fantastic and awesome Newsletter 🙁 I'll fire off a Tweet, Toot and LinkedIn message as well whenever we are ready, just let me know

No problem. Nothing to discuss acutally, only review. Is okay others read already

The new Newsletter draft is open for commits: https://github.com/xsf/xmpp.org/pull/830 As announced this will be the last release for this year! Thanks to everyone helping and contributing to this!

the timelines is this:

https://jabbers.one:5281/upload/dOFffumJiUXlbjMf/XMPP%20Newsletter%20Timeline.png

Is it that unclear?

:)

Yes?

Maybe I make us a new ultra-fancy design for the next year. 😀

Enough for tonight