Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Newsletter #47

Closed
danielepolencic opened this issue Mar 7, 2018 · 10 comments
Closed

Newsletter #47

danielepolencic opened this issue Mar 7, 2018 · 10 comments

Comments

@danielepolencic
Copy link
Contributor

danielepolencic commented Mar 7, 2018

Kubernetes has a weekly newsletter: KubeWeekly. This is a dump of every link mentioning the word Kubernetes. I find it very hard to follow and not very informative.

There's a second and very young newsletter called Kubelist. The project just started, and I can count only three issues. It's curated ✅and human-friendly. But I think it lacks focus. It's about "all things Kubernetes", same as Kubeweekly.

There's a third newsletter KLWD - Last Week in Kubernetes Development. The newsletter is focussed primarily on maintainers and contributors.

The k8s community is not as mature as other communities. JS and Ruby have a long history when it comes to newsletters, and they have a lot of insights to offer when it comes to helping the community broadcasting news.

This is an opportunity for us to bring some of the learnings and the ❤️from other communities to k8s.

I spent some time thinking about what I'd like to read every week if I were:

  1. a k8s newbie and
  2. someone who wants to develop applications on k8s

I also did a lot of research into other newsletters. I targeted three large communities I'm familiar with:

  • Javascript
  • Ruby
  • Designers

You can explore newsletters from more communities from this awesome newsletter collection.

My findings in a nutshell:

  • A limited set of links. No one has time to read a wall of text
  • Curated content. I think this is probably the most significant learning for me. While the newsletter is already k8s focussed, it should be focussed on a particular aspect of k8s. KLWD is a good example: just news on development.
  • No Spam. Goes without saying.
  • No one wants to subscribe if they can't see the quality of the newsletter. But I couldn't find evidence of what quality means.
  • Author or curator play a significant role when it comes to trusting the content or quality of the newsletter
  • Newsletters are much more than just a list of links. There's an opportunity to share events, funny facts, etc.

So I came up with a newsletter idea in line with what learnk8s does best: helping others to get up to speed with k8s.

image

And this is the full newsletter

image

You may be asking... what about the content?

I collect daily news from r/kubernetes and twitter about Kubernetes. All the bookmarks I save are stored in Diigo.
I reckon we could get a digest of the activity of the Twitter account and the bookmarks I saved during the week to curate a newsletter.
Of course, the retweets, favs, bookmarks have to be learning k8s focussed.

Let me know what you think! @salmaniqbal @denhamparry @chrisns @valentin2105 @keithmifsud

@denhamparry
Copy link
Contributor

These are what I look for in Newsletters / Publications:

  • Latest news (< 5 mins / break reads)
  • Ideas, concepts and documentation (< 15 mins / lunchtime reads)
  • Tutorials (< 1 hour / personal development)

With that point, an example of a tutorial would be "Getting started with insert latest buzzwork on Google Kubernetes Engine". The content would need to be created / curatetd by learnk8s but feel that this can be reused else where to further promote learnk8s. Maybe this should be a separate issue?

@keithmifsud
Copy link
Contributor

@danielepolencic I really like the aesthetics of this draft. I also like that you've included jokes and good imagery.

I'm subscribed to several newsletters and I agree with you that most of them are simply a wall of almost automatically aggregated links. Your one makes me want to go through it even if I don't have the time or specific interest in a certain sub-topic/language.

Now being primarily a PHP developer, I would like to see more article about K8s and PHP. I'm more Dev than Ops and I believe most programmers are but as we've already seen on twitter and StackOverflow, there's a huge demand for PHP Devs / K8s Ops and we should target this audience. The PHP community is always and rapidly growing. I would want to see tutorials and practical guides focussed on small units and examples.

Also, the less content the better. I also agree with all the feedback from @denhamparry regarding reading times. When I receive a newsletter, I either have time to skim through it there and then or if I don't but see an interesting heading, I'll start it for later. If there's too much content, I'll normally just check if any of my work was published and if not, I delete it.

@danielepolencic
Copy link
Contributor Author

@keithmifsud @keithmifsud thanks for the feedback.

(< 5 mins / break reads)
(< 15 mins / lunchtime reads)
(< 1 hour / personal development)

and

When I receive a newsletter, I either have time to skim through it there and then or if I don't but see an interesting heading, I'll start it for later.

This is very useful. As I expected, no one has time to read the full newsletter. You skim through, glaze over anything that looks interesting, and then leave.

For launch I plan to have the following sections:

  1. Articles that I found useful to learn k8s. Here's an example of what I collected in the past days:
  1. Something funny. I collected loads of those too.
  1. Interesting libraries/repos such as:
  1. Some sort of way to
  • promote existing training events
  • encourage readers to share the newsletter

Your feedback applies to 1. There're a couple of ways we could go about this:

  1. having tags next to the article (as pictured above). As a reader, this should help me spot a tutorial on my favourite language + k8s, or just an update. I don't have to read the full article to get a feeling for it.
  2. having the reading time next to the article, like in Medium. This article takes 5 mins to read, etc.
  3. split the section in 3 sections like @denhamparry suggested. I think we could either have them grouped by topic (Latest news - Ideas, concepts and documentation, Tutorials) or time (5m, 15m, 1hr). If we go with the former, it's hard to guarantee the timing - there could be a latest news that takes 15m to read. In the latter, it's hard to guarantee the topic - we could have a news in 5m another in 15m and another in 1hr.

Have you seen anything similar in any of the newsletters you're subscribed to?

@keithmifsud
Copy link
Contributor

keithmifsud commented Mar 8, 2018

@danielepolencic Sorry I meant:

When I receive a newsletter, I either have time to skim through it there and then or if I don't but see an interesting heading, I'll star (not start) it for later.

@keithmifsud
Copy link
Contributor

@danielepolencic I think the reading time and reader's interest can be a bit of a hit and miss. An article might be long, and it can also be exciting to the reader, but if the reader is too busy upon opening the email or is just trying to clean up their inbox, then they may still not be able to read it.

Needless to say that longer articles should have an even more compelling headline and excerpt.

@almoretti
Copy link

almoretti commented Mar 15, 2018

Alright, good conversation on content all valid assumptions but it will all depend on the audience that actually subscribes so we will learn on the go.

@danielepolencic To get this off the ground and actually get some activation plan in place to start to send out some e-mail we have 3 streams we need to work on :

  1. Email marketing service - do we have one? A free and easy pick could be Mailchimp or if you want to go open source there is mautic. Probably I'll go MailChimp as it's mainstream and integrated with a lot of other techs out of the box

  2. E-mail List generation - I'm sure right now all those e-mails will sit in silos. (i.e on a paper form, or on sheet o someone computer). Where do we collect all the e-mail, can we list out all the active and potential sources of e-mail we could get online and offline? (i.e pop-up on the blog, website widget, form during a 2h workshop)

  3. Assets - We will need specific email templates. The first one is for the welcome journey, a Simple template that will confirm the user that he subscribes to the newsletter and further marketing communications. The second one is the actual newsletter. This should be built in a modular way, where we agree on the modules that we want to use, the frequency etc.

@keithmifsud
Copy link
Contributor

@almoretti I can see that we're already using Mailchimp for the subscription. You can see the form and subscribe here (above footer) https://learnk8s.io/blog/smaller-docker-images

@keithmifsud
Copy link
Contributor

@danielepolencic The subscribe button says "Join 1500+ others). If we have already have over 1500, then note that the free plan from Mailchimp has a 2000 subscriber limit. Let me know if you need me to do some work on this.

@almoretti
Copy link

almoretti commented Mar 30, 2018 via email

@keithmifsud
Copy link
Contributor

Superseded by #89

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants