 Hey y'all, thanks for joining us to talk about contributing to Kubernetes. So let's get to it. We're here to talk about building a better communication system for the Kubernetes contributors with marketing. I'm Matthew Broberg. I work for Red Hat, Kazlan, and Rejula are up next and we'll introduce themselves. So let's hop right into it. When we say marketing, what comes to mind? I want you to keep that in your mind while we go through this talk and we'll revisit it towards the end. But most importantly, when we talk about contributor stories, who do you think tells them in the Kubernetes community? If we zoom out to this big quantity of human beings that make up the contributorship, we have over 40,000 people sharing and contributing in all the different ways throughout the Kubernetes community. We see that through blog posts on every place online from kubernetes.io to opensource.com to medium and dev to every corporate blog you can imagine. And there's all the ways in which we get the words out themselves. That's partly what we do as we contribute. We're sharing and amplifying each other. And then of course, there are special interest groups, the core functionality of how we get information out and how we organize into our clusters of people in the Kubernetes community. SIGs and SIG leadership, they're constantly trying to share what they're up to. And that's being facilitated by another focus group, the SIG contributor experience. So ContribEx, I'm a member of that. And we focus wholeheartedly on getting the story out for contributors, but also there's administration and other tasks that we're up to. So the comms is really a part of a whole, not the whole focus. So you think of another group. So maybe the CNCF, the cloud native computing foundation, maybe they share the story of contributors. They certainly share a lot of fantastic marketing for all of the cloud native landscape from service mesh to observability tools to all of kubernetes, of course, but they have a much broader range of topics that are separate from the day to day contributorship. So really, we're identifying a bit of a gap in our Venn diagram of people focused solely on connecting the dots of all these contributors and the stories that they can tell. So if you're a contributor, you stare into this space and you are looking deep into a void. You don't know exactly where to share your story or with whom or how blog posts get published or how comms really happen. You might show up to some things, but you don't quite have the story from the beginning. We're hoping to change that. And as you might imagine, we do so under the banner of SIG contributor experience, that umbrella group that manages a bunch of subgroups, including the people that manage the weekly meetings and the calendars for them, and our admins for all the different tools that we use on a daily basis from Slack to Google groups to calendars to discourse. And also now officially, we have the upstream marketing subgroup. And that includes our communication strategy, our storytelling, social media efforts and also automation around those pieces. So really to summarize it in a punchy marketing like note, we are focused purely on supporting the sharing of contributor stories. That's what we do. That's what the upstream marketing team is all about is as somebody stares into the void of community contribution in the Kubernetes community, you're staring into a wild group of very inclusive, very wonderful people who are saying, join us here, join us here. And here is fricking everywhere. It's every mailing list. It's every Zoom call. It's every Slack channel. It's every GitHub repo that you could star and participate in. It's a lot of information to consume as a contributor. It doesn't loan where to know how to know how to navigate that and then to contribute back in a meaningful way. So what we want to do in the upstream marketing team is to at least tell success stories of people who have navigated that space, who have told their story and to map as many of those as possible to different ways in which people can read about them. So the first thing we did was to literally map out how conversation happens in the Kubernetes community. This data is based on last year's survey of contributors and it shines a light on where people actually spend time participating in Kubernetes. So with a bias towards asynchronous communication so that people from all sorts of geographies can participate all the time, we defaulted to the Kubernetes developer mailing list being the main channel for information about what's happening in the contributor community. So if you sign up to just that one, that one mailing list, you can be certain that you're seeing all the main things happening in the Kubernetes community. That was not a guarantee years ago. And there are still very many channels that are wonderful and you should subscribe to and you should participate in to get the most out of the Kubernetes community. But not everyone has the time and energy to do so. So this one mailing list and mapping it, that is our multi-channel communication strategy and its core. So subscribe there to be up to date guaranteed. There are also ways in which people communicate and patterns that are some are more important than others or deserve more priority for the overall contributor experience to be effective for everybody. So we map those into four categories from the it's great if you saw it in case you missed it to the incredibly important action required. They have clear criteria and really solid examples because a code freeze with a specific date is very important for code to keep moving forward in the project. While monthly community calls and mentoring meetings very optional, wonderful to participate in. So we find these through the contributor calendar. We look at GitHub issues on a regular basis to see if there's anything newsworthy there and through slack discussions. But this is the heart of what we've done with the communication strategy starting to build a map of how people communicate and we're growing that into a map of where people communicate through their own stories. So storytelling is the next next aspect to really dig into and after that we'll talk about the robots that help us get our work done. So with that passing the microphone to Kazzlin to tell us a story. All right Kazzlin take it away. Well thanks Matt. Anyway, hi everyone I'm Kazzlin Fields and I'm a developer advocate at Google and I'm going to be talking to you about storytelling. As I mentioned I'm Kazzlin Fields and I'm a developer advocate at Google. I'm also a cloud native computing foundation ambassador and a member of the special interest group for contributor experience, which Matt just told you about. And I focus on containers, cloud native DevOps and Kubernetes type things. I also really like to draw fun illustrations and use fun analogies to explain things. So our work here is by me, not all of it throughout this presentation, but a little bit of it. So Matt told us a lot about the contributor marketing group. To start out talking about storytelling I want to give you kind of a more concrete look at what that group does and what it is. So here you can see a screenshot of the GitHub page where you can find information about the marketing team. We're located under Kubernetes slash community slash communication slash marketing team. And here you can find information such as our team charter, the handbooks for the different types of roles within the contributor marketing team, and other resources such as blogging guidelines and storytelling resources. So what is this storytelling thing? To talk about storytelling, I first want to talk about where do stories come from. We are the contributor marketing team. We also talk about ourselves sometimes as the contributor upstream marketing team. Our goal here is kind of contributors talking to contributors. If you are a contributor, what are the important things that you're doing? What do you want to share with your fellow contributors? What do you think would be interesting to them? Or as a contributor who might consume these types of stories, what do you want to hear about? What do you want to know that your other fellow contributors are doing? What kinds of stories would you like to hear? So our goal here is to take stories from the contributor community. We want our stories to come from you. And here's how that works. To tell us your story, you can come into kubernetes.com and go to issues. And there you'll find the option to create a contributor comms request. If you click that get started button, you'll see this issue template. This is a place where you can tell us the story that you want to tell. Maybe you're working on a feature that you think is really cool and you think that other people working on kubernetes would think it was interesting too. Maybe you've created a bunch of tips that help you when you're doing your kubernetes contributions. Maybe some get commands that you find really useful or useful tools for your development workflow. Whatever your story as a contributor may be, you can tell us about it here. We have options for promoting that story through creating blog posts about it, tweeting it out on Twitter. We can send information out on Slack. And we can also send things to the KDEV mailing list, as Matt mentioned. Sometimes stories involve many of these different types of venues. Sometimes one of them is the best fit. Maybe you already have an idea for a Twitter, a tweet, or maybe you already have an idea for a blog post that you've drafted up. And you'd like someone to review it. You can start here and we'll help you kind of get that through to completion and help you do any kind of marketing to make sure that it gets to your fellow kubernetes contributors. So let's take an example. This is the contributor experience marketing editorial board within GitHub. So it's a place where we can take a quick look at the different types of issues that the marketing team is working on in terms of editorials. So here's one. It's a Kates blog series. And the goal of it is to do a profile of each of the different special interest groups within kubernetes. So this is a job for storytelling. Let's look at how this works. Recently, I took on a goal within this issue of creating a profile of the special interest group for Windows. So kubernetes SIG windows. The first thing I did was I wanted to talk to the SIG chairs or someone within that special interest group who was passionate about it and could tell me about what they're working on and what they might want to highlight in a blog post about their special interest group. So I went to the Slack channel for SIG windows and I said, Hey, I'm from the contributor experience marketing team. I want to do a profile, a blog post about your SIG. And I'd like to know what you're working on and what you'd like to promote. Maybe this could be a good way for you to attract new contributors. So after that, the SIG chairs reached out to me and we started discussing what would be good things to highlight about the special interest group in this profile. My next step was to start writing up a draft. It's kind of unusual for kubernetes contributors to talk about windows. Kubernetes and containers are often thought about as Linux technologies. So a lot of people even within the kubernetes community may not be familiar with how kubernetes works on windows or the intricacies of windows containers. So I was really excited to tell this story to other contributors. It's something that I'm personally really excited about. And I think that you will be too if you haven't checked it out. So I started out with talking a little bit about what this blog post was and why I thought it was awesome. And then I started talking about an introduction to windows containers and kubernetes since that's not something I necessarily expect my audience to know everything about. And then I got into kind of the deeper subject of what the SIG was working on. We talked about who the users were for SIG windows. We talked about the new features that were coming up in the new kubernetes release. And we talked about what new contributors could expect as members of SIG windows and some of the skills that might be useful there. So once I had this draft done, I wanted to get it reviewed. So I chose HackMD to create my draft in because I knew eventually I would have to create a pull request. And the pull requests to add this blog to the actual kubernetes blog is going to have to be in markdown format. So I needed a tool that either let me write in markdown or that would let me convert my writings later into markdown really easily. But I also wanted to be able to do reviews right in the tool where I did the drafting. Of course, you could create a PR and then have the reviews happen on that pull request. But I wanted to make sure that the SIG chairs, any stakeholders on this actual content could review it before I went into the PR process. So that if there were any big sections that needed to be rewritten, any major changes that needed to happen, so that I could do those before we got into the GitHub PR process. Because that can make that a little bit more clunky. It's kind of a lot smoother if you focus on the smaller proofreading type of issues to fix in the PR process. So I wanted this tool to be something that I could use to do some early reviews of the content. So I had the SIG chairs check over it again. And I also had the Kubernetes contributor experience marketing groups editor, Matt, go over this as well within the HackMD tool. So then it was time for the PRs and even more reviews. Like I mentioned, the PR is going to need to be in Markdown. So I took the Markdown that I had from HackMD, created a pull request around that and attached it back to the issue that you saw earlier. And at this point, I needed to involve SIG docs. SIG docs actually owns the Kubernetes blog. So they needed to check through to make sure that all of my images were in the right places so that that would work correctly within the repository where all of the blog posts are actually stored. They needed to do a proofread, kind of walk through the blog post and make sure that everything looked good. So this was yet another set of reviews, which were kind of shorter. I actually ended up posting this blog post with a typo in it. And we had to go back and do a fixed typo later. So be careful with your reviews. But then once your PR is done and your reviews are complete, it's time to publish. And this is kind of what that looks like. This is that SIG Windows Spotlight blog post on the Kubernetes blog. As soon as it was merged in, it was available on the website. And you could scroll down and see the whole article. But that was kind of a pre-canned example of a story. We took an issue that was a blog post series that contributor marketing team had come up with ourselves. But a lot of the time what we really want to do is tell your stories. So what is it like when we get a request for a story? Sometimes we have to come up with a strategy like I mentioned earlier. There can be a blog post, there can be Twitter, there can be all kinds of pieces. Here's an example from the steering committee election in October of 2020. So this is a blog post announcing the 2020 steering committee election results. And a tweet announcing the results as well. An important thing I want to mention here is how do tweets work? If we are thinking from the perspective of the contributor marketing group, we want to tell contributors stories. That means we kind of want this contributor account, Kate's contributors account, to be open to whatever stories the Kubernetes community wants to tell. But of course we can't give the whole Kubernetes community access to the username and password. That would be a major security risk. So how are we going to make sure that this is a tool that's available to people to tell their stories? And that's where our bots come in. Thanks for joining everyone. I hope that you learned something new about storytelling. If you're interested in joining us, definitely let us know on the Kubernetes Slack. And now I'll hand it over to you, Rajula. Thanks, Katherine. Hi, my name is Rajila Benithredi. I work at CERN. So as mentioned earlier, we have a lot of communication channels and we also have a lot of content that we put out like announcements, updates and stories and also blogs. So how do we actually do the communication and different channels? So we've been working on trying to connect multiple communication channels through bots. So as of today, we have two bots which are up and running. So one is a Twitter bot, which is an integration with GitHub. So using a basic GitHub workflow, we should be able to tweet from the care's contributor account. On that, there is a Slack bot which lets us post announcements in multiple Slack channels through a single mode of communication. Let me give a brief overview of each one and how they work. So Twitter bot. So as Katherine mentioned, we have a Twitter account for care's contributors. So how do we tweet from it? So besides the basic login and password authentication, which we can't share with everyone, we have been using a cool GitHub action tool to let anyone make a pull request for a tweet. So this is a basic flow. You just have to fork our repo, which is contributor tweets and then add your tweet to a file and then commit it and then create a pull request. Like every other Kubernetes repository, so we have Pro and CLA integrated. So once an owner of the repo reviews it and then gives an LGTM label to it, once the CA bot merges the pull request, the GitHub action, which is integrated to the repo, tweets from our care's contributor account instantly. So we've been using an open source GitHub action Twitter together to get this done. Let me give a quick glance of how it is. So say I want a tweet about the steering committee election law. So I'm going to put the tweet in a file including the hashtags and then create a pull request and then Katherine reviews it and then gives me an LGTM label. As soon as the CA bot merges it, the GitHub action picks the file, takes the content from it and then tweets it out. So the tweet goes out instantly as soon as the pull request gets merged. So what are the benefits to the community? So using this basically anyone from the community can tweet. So it's a basic GitHub process and then because we have CA bot and CLA integrated, we can review every tweet before it goes out and because it's version control, we have an history of tweets and archival. So as of today, like I said, the tweet goes out instantly. So we are working on a scheduling mechanism to send out tweets at a given time on a given day. So having such a scheduling mechanism really helps us to tweet considering different time zones of our contribute audience. So coming to the second bot. So this is developed and deployed, but still not completely in use yet. So this bot is basically a multi-channel Slack bot which allows authorized Slack users to post announcements in multiple Slack channels at once. So given the number of six and working groups we have, this really comes in handy to do announcements like say code freeze, release info, etc. We have built this using a Slack API and it is deployed in our community infra. This has a very simple UI where you just have to pick your channels and then write a Slack message. So talking about the benefits of this, this really helps us map the announcements required to be sent to each of the special interest group and working group Slack channels. So we do have a restriction on who can use the bot so which is done using Slack user groups API. Also with a bot like this, the messages will actually be sent as a bot user rather than a different person at different times which enables a single point of communication for announcements. We're actively working to get more integrations and more channels connected through bots. Here back to Matt. Thanks Rajula. And with those pieces coming together, you've really seen the upstream marketing wins that we've been able to achieve so far. Step one being the communication strategy. Putting that in place has made it a lot simpler to participate and know you're seeing the most up-to-date information in our community. Second being storytelling where we've had a ton of success through telling stories in the way Kazlin showed us and by building a process around that that really helps you navigate the many spaces of contributor experience. And lastly but not least the bots that will support us by helping us scale by effectively connecting the dots, giving people access to really important things like our Twitter handle without it being something that's just sharing passwords around. It's a powerful collection of pieces that we've been able to map from needs of our community to the channels that we have available to us. Stories have been going out through the kubernetes.io blog while communications happening through KDEV as our main source and Twitter as a secondary source through the K8's contributor handle. But that's just where we are today. We absolutely have a vision for the future that's much broader and maybe a little ambitious for where we are today. We hope stories are going to go out across Kates, the kates.io website but also kates.dev, our contributor site. We can get more intimate stories of contributors sharing on that and we can syndicate those posts and cross link in meaningful ways to help grow both channels for both audiences. Communication is going to grow probably more complicated because we live in a complicated community. We have so many channels that we want to see and people want to consume them on their own time from different channels. We're sure to introduce more bots, more automation that connect the dots between all the different pieces we have, not to complicate things but actually to simplify so you can see more of the information you want where you want to be. The bots that we have so far that we've gone over we have a Slack announcement bot that's deployed but we haven't quite found the use that we need for it yet. And that's okay, we have an initial idea out there but we're not just going to use it to make more noise. We're going to be very intentional with use cases and we see that with the contributor tweets and the scheduler behind it that is active and in use by wonderful community members every day now. So let's go all the way back to that first question we asked of what does it mean when we say marketing? You might have come into this talk expecting something to do with the marketing funnel or to talk about converting people or maybe just sending emails that nobody wants. But what I hope you've seen is that marketing is really this complex connection of human beings and the stories that we tell. So when we say marketing I mean it in this way that I tweeted a little bit ago inspired by the kind of work we're doing here. It's really about connecting people through wonderful sites through incredible conferences through stickers worth sticking on your laptop and through community. Because community has always been a part of marketing and marketing when done well is a community. So when we say we're part of the upstream marketing team we mean we're here to tell great stories of amazing contributors with shared intention and through using our imagination really growing beyond what we think we can do right now by introducing new strategies and new work along the way. And if that sounds like the kind of way in which you want to contribute to Kubernetes please do start sharing your story open an issue in the Kubernetes community repository and we'll guide you through the storytelling process tag us on Slack if you need us or retweet stories that we already have out there through Twitter or if you're looking to contribute be a more week to week contributor to our project. You can volunteer to write a blog post and join our meetings on Fridays to talk through it. You can contribute to the comms bots if you're on the coding inclination of marketing or you can share a tweet through the Kubernetes SIG contributor tweets bot go to that repository and suggest a tweet or very many of them we appreciate it. Last but not least need to say our thanks the images here are from this under an open license on undraw or by Kasselin herself which she's really talented. We have images from phosphor and then a ton of contributors have made this project get off the ground from a working group into a subgroup. So props to everybody here and everyone I didn't list as well. Thank you for being part of this project. We absolutely heart you. So I hope you keep learning about upstream marketing and participate soon.