 The microphone is on. I am mic'd. It works. Yay, cutie. Three tests. Coming down to unity. Testing three unity. The unity. How does it sound? Three two tests. From two o'clock to one o'clock. Microphone one ox and no one o'clock. Test, test, test. How does it sound? There has to be two of them. I've been hunting these two for the feature. And they've won the last of our doodah. Must look great, man. Fuck that doodah. I'm burning the bridge. It's so cool. I've got three copies of the box though. Just take the camera and you can do that over the load. Just because of these grinds don't mean what I'm speaking. Still a fucker turned around at my end. Where to get the keys? It's real. Keep it straight though. Brace your nose, man. Keep it still. Come on. Change up. Knock it. It's safe to chill. Waking it up. Waking it down. Waking it up. Waking it down. the door pointing out way too far, the bottom patient is like right now, and the patient is like an understatement. 7, 6, 5, 4, 3, 2, 1, 2, 3, 4, 5, 6, 7, 8, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 4, 5, 4, 5, 6, 7, 8, 9, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 4, 5, 6, 7, 8, 9, 10, 9, 10. All right, so it's 6 o'clock and my thing works. It's probably this nightmare that no one would come, but we've got five people. I'm going for quality over quantity. So this is actually just a slide deck pictures of my cats. So that should be fun. There are a lot of pictures of cats. But I'm here to talk to you about listening to the needs of your global open source community. This came about because I've been doing these open source community things for a long time now. In 2002, I started getting involved with some local groups. So I started attending Philadelphia Linux users group meetings, and then I helped a woman in my area start this Linux Chicks chapter. So we'd have meetings sort of around the Philadelphia Linux users group meetings, and then we'd all, you know, head over to those meetings. But it was a lot of fun, and that's sort of where I started. A few years later, I started actually running the Philadelphia Linux users group itself, so I was coordinating three chapters in the area. And that's around the same time that I started getting involved directly in open source projects, partially by doing like small code snippet contributions and documentation, and then packaging and Debian. More recently, I spent six years on the Ubuntu community council, which Michael, you're still part of it, right? This is one of the two governing bodies of the Ubuntu project. So we sort of had our hands in all the projects across the Ubuntu landscape. We would check in with them, which I'll talk to you about later, and help them find resources they needed and move along when they got stuck. Most recently, as of the end of last year, I spent four years working on the OpenStack infrastructure team. So I'm a sysadmin by trade, and so in that role there, I was working on the infrastructure team that runs all of the servers that OpenStack developers interact with every day. So I wasn't really developing on OpenStack, but we were creating the tooling that all the developers used, which is where I get a lot of my examples, because these developers didn't like talking to us very much, so they just have sneaky ways of passive-aggressively telling us when things went wrong. And then just in January, I joined Mesosphere as a developer advocate. This is the first time I've stepped out of my open sysadmin role, and into sort of more community-facing. And Mesosphere is a company. We employ most of the Apache Bezos developers, and then we have a product called DCOS that helps you manage Mesos. And that is also open source, but there is an enterprise version. Since I'm a developer advocate, I'm there on the open source team. So I'm going to a lot of conferences and talking to a lot of people and listening to people in our community about things they need. So through that, I've been drawing a lot of experiences from the work I did in Nupun 2 and in OpenStack. So I'll be talking about some of them in the form of eight tips for listening to communities. So I sort of wanted to start with a starting point. So the idea is that you have an open source project, and maybe it's small, or maybe it's only people in your company are working on it, and you sort of want to grow it beyond that. And so one of the things you need to do is actually listen to people who are going to be contributing or people who want to be contributing to your project and figure out what they need. If they just need you to throw the code up on GitHub and then they'll submit patches, that's great. But oftentimes they also need things like developer documentation, documentation around their SDKs and your APIs, and other sorts of things. So you sort of want to go out and listen to what these people are saying, but it's really hard to do that because if you're just a project on GitHub, like how do you know who is your potential contributor? You don't really until you have some frameworks around that. The first one is you want to provide a simple way for potential contributors to contact the project owners. So you can start out by just, if you're on GitHub, you can just start out by putting something in the readme, like this is how to contact a project creator, or this is how you contact the leadership of the project, or this is how you contact the mailing list. So first there's email. So first you might start off with an individual email, and then maybe move on to a list of contacts, maybe a bunch of people who are in control, and they can reach out to and talk to a real person rather than throwing out something on a public mailing list right away, saying like, I want to contribute, but I don't know how. It can be easier to email individuals especially early on. But mailing lists are great too for reaching out and seeing what they need. So that's if people want to proactively reach out to someone and talk to someone directly. So a bug or a ticketing system, so you can have people file issues. But again, when they're trying to contact you as a project owner, they're not necessarily wanting to file bugs against your project. They're saying like, I have this problem with contributing, or I have this problem getting involved, or I'm interested in creating this new feature, that's something you're interested in having. So you want a ticketing system that's specifically geared towards community questions and reaching out to listen to what they need. You might also have a chat channel. I recommend using the main project channel, whether it's on IRC or Slack, and accepting questions from your contributors in that channel too. You can later split that off if it becomes too noisy. But the first place people are going to join is that main IRC channel. So I just say be available to answer questions to potential contributors. I also say if your project is located in a single time zone primarily, like if all your developers are in the US, you should probably put something in your channel topic saying that. So when the European developers come by and ask a question and it never gets answered, they know it's because everyone's sleeping or partying. But it's not work day time. So just be sensitive to time zones. I gave this talk in Australia in January, and they were like, oh yes, I hate Americans. No, they're awesome and they have kangaroos. But they're totally on the wrong time zone, so we always miss each other. But they're hyper sensitive to the time zone thing because when a lot of people in projects in open source are in US and Europe, they're the ones that get missed out. Some projects still have web forums and other things like stack exchange and things. But again, having a section where they can ask specifically about contributing, that can be an option. Oh, and by the way, no one will ever actually do this. You give them all these things and they just don't use them. So we're going to have to move on to a bunch more tips because your contributors still, you should provide these. And some people will use them, but a lot of people won't. So the people who do reach out to you, I'm going to say you have to acknowledge every single piece of feedback you get. Whether it's someone dropping by your IRC channel or someone sending a mail to the mailing list, you have to at least acknowledge it because they have made an effort to reach out and that is more than so many people will do. They've already made an investment by reaching out and that's kind of a big deal, so you have to respond. Even when you don't like the feedback and you want to hide, remember we start with the cats. Even if you don't like it, even if you don't agree with it, just acknowledge it and say it's okay. Even when you have this very good reason for doing the way it is and the way they're trying to suggest it, it's just wrong and you're right. You should still acknowledge it and consider it and try to figure out whether it's going to make sense for your project. But again, acknowledging. And then even if it makes you feel unappreciated because maybe you put all this work into something and it's two contributors saying like, I don't think this is working the way I want it to be working. We should do it this way and you're like, I did all this work. Where's the appreciation? But no, acknowledge the feedback and let them know that you appreciate it even if it makes you feel bad. I mentioned I worked on the OpenStack infrastructure team and we're on the infrastructure team so we're providing all the tools for the developers in the OpenStack project and we're not volunteers. We're in OpenStack pretty much everyone's paid. So we're paid by our respective companies. The infrastructure team at the time was spanning across eight Hewlett Packard Enterprise, IBM, Red Hat, Rackspace, a couple of other companies. So we're all from different companies sitting in the infrastructure channel keeping everything running. So this guy comes into our channel and you can read this but it's like, I'm curious as to why everyone's ignoring my issues. And one of the guys is like, it was the weekend and he comes back with this snarky reply like, it sounds like IT from the 1990s. And we were like that. So we're kind of upset because we're like, dude, what are you expecting? We're not on call 24-7, we're not at your back and call doing all your things. So it was a little hard but we had to keep in mind that for every time someone comes to the channel and talks to us, we don't want the feedback even if it's bad to fall into this unresponsive black hole. We need to respond and we need to be nice. And what he was saying was probably something that other people were feeling. Again, even though he was being kind of a jerk, he came in and took the effort and made the time to talk to us and we just hadn't had time to get back to him yet. So this one contributor is probably echoing what other people are feeling. Which leads me to number three is stay calm. Don't be the angry cat or hide the angry cat. And just stay calm when people give you feedback that you don't necessarily like. It's important to remember during these times that it's not personal at all. Someone is legitimately wanting to contribute to your project. They're wanting to spend time with you. And just because they're finding an issue in the contribution chain doesn't mean that they're trying to take it out of you. And they're probably really frustrated because they've been trying to do this thing. They're trying to help. They're trying to do this good thing of contributing to open source and you're somehow standing in their way. See, this is what they think they're doing. And I am thankfully maintaining the project infrastructure for this open source software. But it's really hard because they're like, I'm just giving you my code. Why don't you take it and do the awesome thing? And we're like, well you didn't do it right. So they're thinking they're thanklessly contributing. We're thinking we're thanklessly running the infrastructure. And we sort of, you know, as people running infrastructures or leaders in a project, you sort of have to meet them more than halfway because they do think that they're contributing in a way that's going to be valuable to you. And you should be thankful that I'm coming to contribute. And ultimately the project will benefit from getting more contributors and more people caring about the project. So even if they fail on in there with an approach that's maybe less than optimal, if you bring them into the fold and start addressing their needs, it's going to help them, it's going to help you, and it's going to help the contributors behind them who are having similar problems. I also say whenever you want to make changes in your project, you should openly communicate them and ask for feedback. I've worked in projects where this didn't necessarily happen. And it was often not because of malice. It was just because people kind of get into their meetings and they get into developing features and they get into making plans. And they just forget to tell everyone else. And this is particularly hard when you're working in a company and you're doing some meetings internally and you forget to externalize some of that. Part of this can be helped by not having those internal meetings, but I understand that they are required for a lot of companies. But making sure it's a priority to communicate any sort of changes you're making as soon as possible is really important. And then reaching out to your community to say, hey, is this change going to impact you? How is this going to impact you? And doing that as early as possible in the discussion. You can do this by form of just doing a mailing list thread like reaching out and saying, hey, there was one thing in the OpenStack infrastructure team where we were changing the way we were building test images. And we wanted some feedback because previously we'd been just pulling them from whatever cloud provider had them. And we were moving into a way that was going to be more uniform across all of our platforms. So we talked to Mail in the mailing list and said, hey, we're going to do this change. Is this going to impact anyone? Is anyone relying on certain features, on certain clouds where they run their tests? Because if you are, you should stop doing that because we're going to, you know, even it out across the platform. So that was a mailing list discussion. We let everyone know. For different things that are maybe less technical or you want like a really big response from your community as far as numbers. Doing a poll of your community can help. Like should we do this thing? What are the drawbacks? And then maybe a free field saying like, what other comments do you have about this? Because polls can be really quick for people to fill out. You could also bring it up at a meeting your open source project has if you have a chat meeting or some sort of hangout or something. You can bring it up in a meeting and open things up for discussion and ask people for feedback. And this gives a formal meeting topic. Everyone knows it's on the schedule and if they're interested in that, they can make time in their schedule to come and talk about it. And this was just from a mailing list thread. Monti's a guy I was working with. And he raised this really long email about actually a pretty major change we were going to be making. And he's like, it seems like one of those things we should give you a heads up and ask for feedback on before pulling the trigger. Because in this case, we really wanted to be friendly with the community and making sure that we were reaching out and pulling in information from them when we were going to be making a big change. Oh, and I'll say, even when you go through all this stuff, just like the contacting you stuff, people won't read your emails and then when you make the change, they're going to be angry anyway. So this is also kind of like a, you can go back in time and be like, look, I sent the email, I warned you, please pay attention to our emails next time. So it can sort of cover you when you're going back and saying like, people are complaining about you changing something and you're trying to highlight it in retrospect. Because a project like Ubuntu or OpenStack, if you're making a major change, you can be impacting a lot of companies and actually a lot of money can be involved. So you want to make sure that you have that breadcrumb trail of like, I have notified you, I sent this email three weeks ago, I have done all the things to try to notify you of this. So it's not even just about being friendly, but making sure that your team is viewed well by the community out there. One of the things that we did in the Ubuntu community that we found really valuable was actually going out and checking in with teams periodically. Ubuntu is a very big project. There's the documentation team, there's translations team, there's dozens of development teams all focused on all kinds of different things. Ubuntu has laptops, Ubuntu has phones, Ubuntu has crazy drones that fly around. There's all kinds of communities inside the Ubuntu community. So when I was working on the Ubuntu Community Council, one of our jobs was making sure all these people were happy. And it was really hard because they were just all over the place. So we came up with a schedule each cycle, every six month cycle, where we would check in with a bunch of the teams that we identified in the community. And this ended up being really valuable because these teams wouldn't necessarily come to us otherwise. So we would have a time during our meeting and say, hey, during this chunk of time you have our full attention, we can help you with anything you want. So the desktop team would come and meet with us. And we'd ask them about any roadblocks they'd have. So is there anything that's preventing you from doing your work? Is there anything that can be made easier? And even if we couldn't directly help them as Ubuntu Community Council, being aware and having that in our head about what sort of things they're running into would help us the next time we had a conversation with someone who could help or say like, hey, oh, we were just talking to the desktop team about this. Like maybe you're having a similar problem. We could put people in touch. And oftentimes we could actually help them. But I think the most valuable, we would also ask people what's going well. So that was also an important part of this because something that was going well in one team, we could communicate that to other teams. And that was a really strong way of talking to them and sharing the knowledge. But I think the most valuable part about this is that as one of the governing bodies of the project, a lot of people in teams were afraid to come and talk to us. Or they would say things like, well, it wasn't important enough to come to this Community Council about it. But there'd be these little tiny problems that they'd have that would fester and turn into big problems. And by the time they were big problems, they were much harder for us to help with. So by checking in and being like, is everything okay? Really, is everything okay? Are you sure? Is there anything we could do? They'd be like, well, there was this small thing. It helped us hop on things faster and help the community really get the help they needed much earlier and it helped reduce people leaving the project. And other bad things that happened when little tiny things are annoying, especially in a project that has so many volunteers like the Ubuntu project. So lots of great things came with checking in. And it didn't take a lot of time, which was really key for us. Because you think, I mean, this was how many teams? There's probably like 20 teams on here that we check in with. And this is only a small fraction of the Ubuntu community. But even this, like this is six over six months. It's a half hour check in for each team. It really wasn't a huge investment of time for any of us. And we got a lot of value out of this. Right, so I talked about this. Yeah, do you have problems with tooling? Do you have problems with processes? Do you have all the resources you need? We found a couple of teams. I mean, every single team at Open Source is like, we need more people. There's not enough people to do the work, right? And that comes up all the time in check-ins. They're like, well, things will be great. But if we had more people, we're like, yeah, we can't help with that. But if you need help with your onboarding, or if you need help trying to attract more people, we can help you with some of these things if you want to split your resources. And asking things like, if there was one thing you could make your life easier, like snap my fingers and make it easier, what would that be? And again, just trying to nudge them along the way to thinking of solutions to think pain points that they might have. I mean, we started doing this, you know, what's working well in our project is like an icebreaker. Because once they were telling us what's going well, they seemed more inclined to say, but we just have this problem. Right, so I'll just repeat that for recording. But Michael here is on the Ubuntu Community Council, and he mentioned that the what's going well question can be like an icebreaker. But what's going well can often lead into what the pain points are. So that ended up actually being valuable for us getting feedback from them. Because I think in the case of what's going well, people get excited and they're happy, and they're like, I'm so happy about the project except for this one thing. And it kind of makes them feel more comfortable because it's not like they're just being like, what's wrong? And they're like, I don't know, everything's pretty good. So another tip and another cat, documenting all of your processes. So one of the things we found in the Community Council was that we were pretty opaque. People didn't know when to come to us. People didn't know exactly what we did. So I started writing some blog posts about what we did in the Community Council, like here's the things we do. And we couldn't talk about specific things because some of the stuff we do is dispute resolution, which is very private. But we could say that we do dispute resolution and that we do a lot of this other stuff so that people could be more in tune. And then when we'd have people join the Community Council, like after some other people's terms were up, it was really hard to onboard the new ones because they didn't really know what we were doing. And then in the OpenStack project, when we were working on the infrastructure, again, it was bringing on new people to our team. It was actually kind of hard because some of our processes weren't documented. So we started documenting processes, especially in the OpenStack team. And so people would come into our channel less often to ask really simple questions, especially about contributing. But we didn't beat them over the head with the documentation. So they would come in and they'd say, hey, I need the logging bot in my IRC channel. And we're like, okay, here's the documentation. Let us know if you have any questions. Not like, that's documented, just read it. It's here in our docs because we know that our docs are like a labyrinth of crazy and I can barely find things half the time even though I wrote them. So making sure that processes are documented so that people can help themselves and if they can't find what they're looking for, you can actually easily point it to them and don't have to repeat the same thing because we're all strapped for time. And I think when we do this RTSM thing, we're not trying to be mean or malicious in any way. We just are like, I spent a week documenting that. Can't you just go to the documentation and we're frustrated and they're frustrated and then you end up with this frustration war that doesn't make anyone happy. So write the documentation and have the documentation, but then give it out politely and then ask people to come back. Tip number seven is probably my favorite, reading between the lines. So this one came about because, again, I've got all these processes in place. There's ways to contact us. There's things that we're doing, we're checking in, we're asking people what they need, but they're still not talking to us. And this usually comes about because, again, they don't have time. They're starting to work around problems and they just don't have time to come talk to us. And, again, in the community council, they were like, well, you're too important. I don't want to bother you. In the OpenStack infrastructure team, everyone knew we were really busy and they're like, well, I'm not going to bother them for this little thing because they're busy keeping OpenStack running. So in OpenStack, we had to get really good at reading between the lines and finding pain points when people wouldn't actually directly talk to us. Yeah, I just said that. So this is a funny one. So I have some examples here. You know, there was this long thread and it had nothing to do with infrastructure, but very deep into this thread, this one guy times and he's like, without wanting to diverge too much from the topic at hand, I believe this is why those of us who only occasionally want to look at post-job output, we do a CI system. We just give up because keeping this mechanism to look up this job output is too hard. And so I'm reading this email and I'm like, looking at the output is too hard. Why don't you come tell us that? I don't know, I'm not running all these tests. So he just happens to offhandly mention this in the top end of the thread. I don't even know why I was reading this thread. It had nothing to do with us. So they were trying to find this thing. But this is something we could help with. So one of the people on our team, after a few more comments like this, they ended up building a health dashboard for OpenStack, which is so cool. And he was able to start helping with this problem. But we didn't even know it was a problem because no one had come to talk to us and we hadn't been impacted in a way that we noticed. And I think in our case, we were so familiar with the infrastructure that finding the specific URL for this job output, you just knew where it was. So we were blind to the fact that it was a problem for developers. In this case, someone created a workaround tool for not being able to figure out something, which is hilarious. So he created his own GetOpenStack job to create the formula for constructing this URL to find something. And we're like, people are writing whole open source projects around problems we have in our infrastructure. We clearly have a problem here. So yeah, people are writing, yeah, so they're like, oh, by the way, and they're writing tools to get around problems. And they just wouldn't talk to us. They were just making up these things. So when we found out about this, they also got rolled into the dashboard. So that was also helpful. But this happened, he just mentioned this on the mailing list. I'm like, oh, I'm sorry, because I weren't serving to you. This one is one of my favorites. This guy was in the QA team. And this was really early and sort of open stack days around when I started. Back when we only had several gigs per day, we're up to a lot more than several gigs now for logs. But what he was doing every day was in order to do his QA work, he was trying to look for job failures when the code wouldn't pass tests and look for patterns. So we found out, after seeing our server hammered at a certain time of day every day, we're like, why is our server all of a sudden getting all these downloads from this random IP in New York? So we figured it out. It was our QA tester in New York and we downloaded all of our logs every single day. And we're like, so why are you doing that? And he's like, well, I need a way to do analysis and all you do is put them up on like a static Apache web server. You don't have any way to analyze your logs. And he's been doing this for months. And we're like, well, that's something we can do something about. We can build something for you to fix that. So what we ended up doing is we built, okay, it wasn't a simple solution, but we built an Elk stack for them, Elastic Surge Log Stash and Kibana so that this community member could finally do these QA tests against all of our logs instead of having to download them all locally. So the best part about this was that not only was he able to do his job, he ended up writing a tool that started automatically catching and categorizing failures based on the log jobs and then that automation was able to go back into the review queue and tell people. So if someone ran a test on their code and the test failed not because of their code but because of a known bug in our infrastructure so sometimes a VM doesn't spin up when you want to run a job or sometimes it dies in the middle of a job because clouds are ephemeral. Something happens that we know there's a problem and it shows up in the logs but it wasn't because of your job. There was now a bot coming back and saying, hey, sorry, that was our fault. If you want to rerun these tests, just do it because it wasn't your code. So we finally had instead of humans doing that or instead of developers being like, what happened? My code is fine. I don't know why this failed. We finally had a bot doing that. And that was all enabled by this ElkStack that we brought up just because this one guy told us about this. It also allowed a bunch of other little projects to spin up around being able to consume and do a blog analysis that we hadn't even thought of. And they did it just because finally the tooling was there and they were able to use it. So that was pretty cool. We had to read between the lines of what someone was doing and actually he didn't even come to us and it was us finding a traffic spike and then trying to figure out what it was. And that was like serious reading between the lines. So tip number eight is about sticking to your principles. In the case of a lot of open source projects, you don't want to say that the customer or the contributor, they're not always right. They sometimes have crazy ideas. They sometimes don't know the history of the project. They don't know that maybe you've tried this before and you're doing something for a certain reason. So you want to sort of have principles. So the first step is that. You want to make clear that you have certain software choices. In the case of the OpenStack project, we could only use open source tooling for everything. Part of this was like a moral obligation by the team because of the people they hired to run the infrastructure. We're all like hardcore open source people. So if you shove proprietary software on your face, we're just going to be like, we're not running that. So part of it was like a moral thing. Just the people they hired happened to be old and grumpy. And then part of it was also that the OpenStack project works with hundreds of companies. If we chose one piece of software over another, that could actually cause problems in our community because no doubt HPE probably owns something and IBM owns something competing and then if we used one over the other, it just causes problems. We're like, listen, we're only using open source. So for us, that was a constraint. So every time a community member came to us and told us we had to use Jira, we're like, we're not using Jira. So much better if you use Jira. We're like, well, we only use open source. But we had these policies codified in our documentation saying we only use open source software. We're not going to depend on proprietary cloud things even. We're not going to depend on this API that's run by a company in a closed way. If you're not like us and we're in OpenStack having these sorts of constraints, maybe it's a cost consideration. So contributors come to you and they want to use Slack, but the only way you can effectively use it is if you pay for it. You say, listen, we're not going to use that because of cost. But make sure that these things are clear. So when people come with you, come to you. You don't just shut them down. I mean, you don't shut them down without reason. You say, like, here are our principles and here is what we have to abide by for the project. So you sort of have to develop things around software choices. There's also boundaries with which you'll want to support your developers and community members. So people would come to us in the infrastructure channel and want us to debug the code that they just wrote. They're like, my test is failing. Why is it failing? And we got really good at debugging Python code, but that's not really our job. If you don't know why this thing failed, you should learn more about Python debugging tools that were running on every single piece of your code. So we'd try to support them, but then we'd say, listen, we helped you debug it this time, but next time you're going to have to try to do it yourself. So we want to have places where we can help and then places where people really have to move on to another team to get help. We also wanted to be understanding what our threshold for compromise was. So when someone comes to us and wants to use a new tool or wants to do something in a different way in the community, we have to stop and think about that and wonder, like, what are we going to compromise on, principle-wise, or, you know, we've always done it this way-wise and make sure that's communicated to them and the people on our team, because we don't want to say no to everyone. We don't want to say yes to everyone, and we want to be willing to compromise. And I think putting a lot of trust in your high-level view of the project, whether you're a leader or you're running the infrastructure and whatnot, as someone who's listening to a community, you have a really interesting perspective of the community. You can see all the things, or at least you're trying to see everything in the project. So in the Ubuntu project, we'd run into cases where someone would come to us with an issue and we'd recognize it. Like, we'd see it had happened somewhere else or we'd see that it is related to another pain point or something's being done over here that's impacting over here, and we just have to close the gap and make people talk to each other. And understand that, like, since we have this view of the project that other people don't necessarily have, the ideas that they think they're really great, but we have to be prepared to talk to them and say, listen, like, this isn't the way we do things. So just as sort of another example of a way we sort of were listening to the community and going by our principals in OpenStack, we were using translation software in OpenStack called TransFX. They decided to go close source, so again, we're only allowed to use OpenStack software, but we were using their hosted version, because we're like, listen, this is open source, so it doesn't violate any of your principals. It's okay, but we're going to use the hosted version because we don't have anyone around to manage this right now. So a couple of years ago, TransFX came out and said, well, GitHub doesn't have to open source their software and they run a great service. Well, we're going to close source our software and run a great service, so we're going to continue, you know, we're really committed to open source. We're going to continue providing it to you for free. We're not going to work on this account, but we're not going to work on the open source project anymore. I was like, damn you, GitHub. You're creating this precedent I don't like, I know, but for us, that was a real killer. We could no longer use their software because we really couldn't compromise on the proprietary nature of their software. So we're like, we either need to fork their project, which, honestly, we don't have the resources to do, or we need to move them off of this. So this started a year and a half of my life as a translation team off of TransFX and onto an open source translation platform. When I started this, I didn't know anything about translations, really. I knew there were these things called PO files and POT files, but I had no idea what they were. I didn't know anything about translation strings. I'm an American, which means I speak one language. I mean, one that was born here, so yeah, English is it. I don't know anything about translation. We had to work on moving them off. So the first step in this was, I mean, this was like my boss level, like listening to your community, right? Because I'm suddenly interacting with this new translations community. Most of them are in Asia Pacific, it turns out. So I had a lot of 1AM meetings, which was a great time for them, 1AM for me. What I ended up doing is we had a series of meetings. So we started out by telling them they can't use TransFX anymore, and they were really upset. Because they're like, listen, in OpenStack, even though a lot of people were paid, a lot of the translators aren't paid for the time they're doing translating. Like they may work on OpenStack somewhere elsewhere for their job, but they're doing the translations as a labor of love. I think IBM was actually committing time, but a lot of people doing translations just really were passionate about OpenStack. And they were in underserved communities that were non-English speaking, so they felt they had a moral imperative so these people were doing it because they cared. And they're like, we don't want to learn a new tool because we're already just doing this for fun anyway. And you're going to ruin our world by moving us off and making us use this thing that we hate even when we just learned all the quirks of TransFX we're going to remove us off. So it was really delicate for me. I had to be really careful because I knew I had a hostile audience to begin with. So what we ended up doing is we first did some research. We asked them, do you know any open source projects or like, I don't know what it was. So I was like, okay, I'm going to go find some. So I found two big platforms that were doing translations. One was written in Python and one in Java. So I'm like, oh, the Python one, we should totally use this. Well, I set them both up as demo servers. And then for each one that I set up, I ended up contacting someone in that community and saying, hey, like, I set up this demo and OpenStack, which is kind of a big deal, you know, is going to maybe use this as their translation platform. Can you take some time and jump on a Google Hangout with us and like show people how it's used? So they are less scared of this new tool because they're really upset about having to move it all. So we set up one of them. We had someone join us and that actually went really well because the guy in the project, so many translation softwares are in the Asia Pacific region. So like, I always had really good luck finding someone who could talk to the community in time zones that were really inconvenient for me but great for them. So he would jump on a Hangout and show them all. And so I did this again for the other translation platform I had. And this started softening them up to the idea that we were going to move to a new platform. They still weren't happy about it and they still thought we were being silly about our whole open source thing. But they decided that it was okay to listen to these people. Unfortunately, the Python one didn't win out because the UI wasn't really pretty. The Java one had a really nice UI and they really liked it a lot. So what happened then is I worked with the guys who were working on the Java version that we ended up going with and they actually flew out to one of the OpenStack summits and we all got together and talked about things we needed and so we were working directly with this upstream project and they started satisfying the needs that our community needed. They were like, okay, we need statistics that we set out in a JSON format that we can consume. They were like, no problem, we can do that. We need different authentication mechanisms. We were using Launchpad's OpenID and they needed to support that login mechanism and there were a few other things that we needed. So I was able to be these liaison between the upstream community and the translations community saying like, I'll run this thing but you need to do this thing and so they did a lot of talking through this. So we finished that summit and we actually did a few iterations of this. Them satisfying our needs and talking to each other and working all through this. So finally, they had pretty much everything done and I set up a demo server and they spent like a month and a half kicking the tires and making sure it worked and then we finally went into production. We went into production. People were actually really happy and looking at this from like the beginning of this process when everyone was angry at us and thinking we were being silly for changing software since they were able to work with upstream and work with us and feel like they were listened to during the entire process and included. They suddenly had an investment in this new project. They actually got excited about getting to use it. They were excited about the new features they had that the old software didn't have but now since they were able to impact the development of this and they never had a say in the old one. We were able to give that investment to them and make them feel part of the process. So it ended up being a really successful thing for us. So with that story behind us this is kind of just a wrap up of the eight tips that I just left through. So when you're talking to your communities listening is a huge part of this. Making sure you're being receptive to listening and accepting the feedback. Checking in with teams ended up being really valuable because again they won't talk to you even though you've led all these ways that people can talk to you. Part of reading between the lines is being very engaged with your project. Some of the things we found we were just reading regular development emails and then we'd find pain points in the infrastructure and there was no reason for us to believe that there would be any infrastructure stuff in that email but since we were paying attention to the community and really tuned in we were able to see some of those things. We've got plenty of time for questions. We've got like 20 minutes before this is officially over and I can probably let you out early for dinner after some questions. If anyone has anything? The question is how social media fits into all this and if it's different. One of the things I've noticed so you engage with it differently because you use it differently I find I do the same because part of the thing is that with these social media things I don't engage with developers quite as often so it's a lot of user facing community stuff so it's mostly about quickly responding to them in ways that are just I guess direct and trying to push them into some of the official resources because often times the social media channels aren't as well looked after but at the same time like reading between the lines and finding things on mailing list that can be applicable to Twitter as well. I've found people complaining about the OpenStack infrastructure online like someone would send us a link like oh you should look at this Twitter thread and I'd be like oh my gosh why are they talking about it on Twitter? Because that's where people go to complain it turns out. But in those cases we can usually find the person who is tweeting and actually just chat with them on chat or something or drop an email and be like hey how can we fix this because they're writing this massive blog post complaining about things and I'm like where did that come from? I didn't even know any of these things so that can sometimes be a thing. But yeah there is slightly different engagement but I mean the same thing you know hold true you should probably respond to them and people will like it when you respond to them on social media because sometimes they don't expect it sometimes they just have like a rant and then if someone official responds to it they're like oh how nice how do I deal with problematic people? So in the community I'd like to say that there's no problematic people there are problematic behaviors but you have like sort of a like a whole scope of these things like you've got someone who's behaving poorly and if you just sit down and talk to them and say like listen what's going on and they're like my dog just died and I'm really angry and you're like oh okay so this is just like a temporary thing like you're just angry and you're taking it out on other people but let's just step back and calm down but you do have people sometimes people when they're burning out they're just so overworked and they're so tired and they just start being grumbly again you just have to take them aside and be like listen what's going on do you need to take a break? do you need us to help you with something? and you know I say like nine times out of ten just sitting down and talking to someone who's having a hard time or lashing out in the community that helps and stops things and in communities where a lot of things are chat based and like text based doing a call like a phone call or a google hangout or something like that sort of personal touch can help them feel more engaged and more committed and stop acting out in bad ways and then you've got the other 10% which are not resolved just by talking to people and in those cases sometimes you have to have a few rounds of talking sometimes you have to bring in some other people for perspective and sometimes you have to kick them out of the project which is the most painful thing to do because oftentimes the reason they're there is because they're important and they're doing good work but if they're doing good technical work that doesn't necessarily mean they're a team player they're driving people away and ultimately you have to make that decision too if your behavior is not going to be improving or if you don't see that your behavior is a problem then we're going to have to take steps to remove you and in the Ubuntu community we have a code of conduct and if we see people are violating that there is a clear path there open stack since most people are paid there's often an HR being involved so dealing with problematic people I'd say it's probably the hardest thing to deal with the community stuff is going to someone and saying listen your behavior is not acceptable because it's uncomfortable on all sides you don't want to go to someone and say that but you also don't want them hurting people in your community alright thanks everybody