 Good afternoon, everyone, and welcome to PTLs and Cores. We are not as scary as you think. The idea for this presentation came around earlier this year. I'm Amy Eukasic, and I work for AT&T, and I was helping build AT&T's community team, which was comprised mostly of new college hires. And we went to the summit in Austin, and they were afraid to ask questions. They were afraid to introduce themselves. They had an idea that, oh, PTLs are these terribly scary people. Don't talk to them. Don't do anything. And it carried over from Austin into the day-to-day workplace. So at the working breakfast in Austin, I had come up with this idea. And later on, Jessica Marillo, who's sitting in the front row here, she ran with it and submitted it. And here we are. So with no further ado, I'd like to introduce our scary PTL panelists. On the right is Steve Martinelli, well, the only guy that's easy to tell. And Yifat Afak and Lana Brindley. So to start out, I'm just going to have the panelists kind of introduce themselves. So Steve. Thanks. My name is Steve. I'm the current Keystone PTL. I have been for the previous two releases as well. I started to work in OpenStack back in 2012 when it was the grizzly-ish release. Yeah, just been really working on Keystone since then. Hi. So I'm Yifat Afak. I'm a system architect in Nokia and the PTL of Vituage. Vituage is a root cause analysis for OpenStack to help organize, analyze, and extend OpenStack alarms. Vituage started exactly one year ago just after the Mitaka Summit. We were a group of developers, Java developers, from Nokia doing root cause analysis. And we identified a need for doing this in OpenStack. So we started a new project. And six months later, we were accepted into OpenStack with a big tent, which made us very proud. And now Vituage is stable, up and running. But we have a lot more work to do. We are looking for new contributors. And that's about it. Hi. I'm Lana. I'm the Docs PTL. I started contributing to OpenStack back in Icehouse. And I became the Docs PTL taking over from and gentle in Liberty. So I've been around for a little while now. Great. OK. How did you guys scale the OpenStack learning curve? What kind of experience did you have when you started out? And did you encounter any scary people? Lana, why don't we start with you? So I came to OpenStack as an experienced technical writer that I was completely new to OpenStack as a technology. I was also an experienced manager in the traditional sense. So when I started, I had to learn OpenStack from the ground up for starters. And then when I became a PTL, I had to learn how to lead a community as opposed to managing staff. And I think possibly the second thing was harder than the first thing. It was extremely challenging for me to learn how to get a community working all in the same direction when they didn't have to. Nothing I said they had to do. So one year ago, me and most of the other vitrage contributors were new to OpenStack. We didn't know anything. So I really remember what it was like to be a newbie. And we had to learn everything from scratch, like Garrett and Launchpad and all of this. And lucky for us, we had colleagues that were used to working with OpenStack. So they helped us. But it was not easy to get started. And as a new PTL, I had a lot more to learn because I wanted to work by OpenStack guidelines from the beginning. And one of the things was doing the weekly RLC meetings. And we did the first RLC meeting on the very first week that vitrage started. And I remember us sitting like 10 or 12 people in a big meeting room and talking to one another on RLC. And the first time that someone actually joined our meeting, we were so excited. Like, wow, someone is talking to us. We are not talking to one another in the same room. And I'm still learning. I mean, I just learned how to release a new version when vitrage was released as part of Newton. And the first time I did it, I was wrong. And second time, I was also wrong. So I just went to the RLC of the release management and they helped me. And so step by step, we are learning. Yeah, I think you're going to notice a trend in my answer. I didn't know anything when I started. Came from like a Java developer background. But yeah, we were just told to start contributing to OpenStack. So it took me about a week to figure out DevStack. Not my proudest moment. It was less stable back then. That's my excuse. And you just kind of go and you poke people. And sometimes you've got to poke it. What you think are the scary people. So the PTL at the time was Dolph Matthews of Keystone. And I thought he was very scary, terrifying. How is he terrifying? Give us an example. Well, when I first started, he was just always correct. And if you know Dolph, he's still always correct. But he's less scary now. No, Dolph's awesome. He was PTL and as PTL, you're encouraged to teach new contributors and that's exactly what he did. You eventually learned the ropes and became a core contributor. And from there, I was interested in the PTL role and I started to just shadow what the previous PTL Morgan Fainberg did. And here I am. Interesting answers. So what's the worst thing that ever happened to you as a new contributor? What's the worst thing that? What's the worst thing that ever happened to you? Oh. I can't say that. Sure. I'll tell mine first. So when I started, like I said, I was an experienced technical writer but I knew nothing about OpenStack. So I thought what I need to do is find a good editing job while I'm still learning things. I'll go through one of the books and I'll learn the repo and everything. Unfortunately, I picked a really bad book. For starters, it was written in a language I was not familiar with and it was a language that was different to the rest of the doc suite at the time. So I had to learn a whole new language for starters and I was absolutely determined. I can be a little bloody minded, it turns out. And I was absolutely determined to get through this thing. So it was terribly written. It had been more or less abandoned and I got through it. I edited the whole book and in the next release it got ditched. And that book no longer exists. So when I first started OpenStack I had never used Git before. So the whole rebasing and doing several branches on top of each other was kind of weird but I thought I had figured it out. But then I was working on a feature with another guy and I tried to pull his patches down, do a small change and push it back up and I completely caused a rebase nightmare for him. And I don't even remember what I did but I totally caused more work for the guy. But either way, the point of it is it's just software and you can just revert things and it's pretty, and for those more experienced in Git it takes them about like two seconds to figure out what took me probably two hours to try and revert. So I just got to poke people for help and ask them, how'd you do that? Can you show me the magic trick sort of thing? Well speaking, did you have anything to add if I? I just sympathized with him. Without him I'd get to a nightmare. You could say speaking of Git and Garrett and patch sets how many patch sets was your first commit? I know we were talking about that in the hallway before. I can answer the first one but the worst one. Okay, the worst one. The worst one was probably like 65, 70. Wow. Well for me, it didn't, I mean I'm working on a new project which I know from scratch so I'm not in this game. Yeah. Doc's people can be a little bit notoriously picky. I don't think we've ever gone to 60 or 70 to be honest. I think the biggest I've seen was around 20 or 30 and I'm fairly certain some of my early ones were up in the teens at least. Okay so you said you've seen 20 or 30. Steve you mentioned you'd seen patch sets that were much larger than that. Well that was my own personal. My own personal was like 67. I've seen like up to like 100. Wow, okay so as a, you know as a PTL if you come across a patch set that's that large how do you manage that? Do you step in and help? What do you do? Well normally I try and stay, normally it's a feature and normally all the features I try and stay involved early on. Yeah you just had, in this case, this particular case it was just weird. The guy had broken it up and then put it back together even though we didn't ask him to do that. Yeah it's always just better to keep patches small. Like under 400 lines is great. It's much, much easier to review and you can just you know put patches in sequence after that and it makes the reviewer's life much, much easier. I think sometimes it's important to work out why there's so many patch sets as well. In some cases, like I said, docs can be a little bit picky on and we get a little carried away on commas and capital letters and things occasionally. And sometimes I do actually step in and go look guys this is fine. It's fine as it is. It's better than, we have what we call the is it better than we already have test? If it's better than we already have but it needs further iteration or it needs wording improvements or something. We can do that in another patch set later on. So sometimes I do actually step in and go look everyone just step down, let this merge, create a bug and we'll go back and review it later. So it's another test as well. Well yes in the project we don't have like 20 patch sets but I think that most of the times there is an improvement. And eventually we approve it and we tend not to push really very big patches at once because it makes the review much harder. What's the worst thing a new contributor has ever done since we're talking about contributions? What's the worst thing a new contributor has done? I don't think a new contributor could do much worse. I mean someone can make mistakes but it's not so such a big deal. You're very unlikely to break anything. It's almost impossible to get a bad patch through the gate. And even if it does, I mean I've seen bad patches go through and you don't realise they're bad until the last minute for whatever reason. And even if bad patches do go through we pick it up and we can revert it. That's the beauty of CI. I did have a small story related to this. Please tell us. It didn't break anything but it did cause a little upset in the core team at the time. We had a brand new person actually came through Upstream University and had done a patch while at the course before Summit and had decided they just needed to do a little patch to test things and to work it out. And the commit message was actually something along the lines of this is just a test, I'll do another patch and revert it later on. And what she changed was the very first line in a config file that would stop the book building. If it had merged it would have pulled the entire book down off our site. So of course all the cores noticed it almost immediately because we have a lovely core team. And they're very on the ball and they all jumped in and everyone gave it a minus two real fast. And I think on the one hand that's great, nothing broke. We spotted the problem and we had to revert it. On the one hand that's great, nothing broke. We spotted the problem very easily. But for the poor woman, this was her first experience of doing an open stack patch. That would have been a little scary. So yeah, I think I can understand where the scare factor comes in situations like that. I don't think new contributors can do anything too scary. But if I could just kind of twist the question a little be like, what's the worst thing a contributor can do is probably just like empty promises. Hey, I'll do this and leave me that bug and a few weeks go by and nothing happens. That's just annoying as a P.T.L. Because at least for me anyway, I'm tracking all these things both in Launchpad and in my head and it's just kind of waiting like twirling your thumbs. It's like, hey, what happened? You poke them and nothing, this is very annoying. So then what should a new contributor do to not annoy you? Don't do empty promises. No, just properly set expectations probably. Don't over promise, set expectations, be realistic. If you're not working 100% upstream then don't try to take on three features and 20 bugs. Do it one thing at a time. Don't try and do everything at once. Do like serial instead of parallel. Yeah, that's it, just be realistic about it. And be honest about what you can and can't do. It's okay to admit that you don't know something. I think there's a tendency sometimes to want to look like you're a little, you know a little bit more than you do and then go, sorry, I'll work it out. And so it's very easy to say, I'll take on that bug even if you don't fully understand. I'll go and work it out over here in secret. It's much, much easier to say, look, I don't fully understand this, can you help? Can we step through this? Or just ask questions as you're going along and discovering what you don't understand and it's okay to admit that you don't fully understand something. No, nothing to that. Well, okay, so we're talking about how to not annoy a PTL. Is it okay for new contributors to contact you? And if it is, how should they contact you? They should start with hi, Lana. I always like that. I think it's great if they contact me. Feel free to ask any questions that you have. In most cases, it's better to ask the entire managing list because maybe someone else has the answer and is more available to answer faster than me, but it's always fine to contact me. No problem. For the most part, I'm okay with it. People have contacted me through my work email, my private email, IRC, and the one thing that does kind of bug me is when people contact me through direct messages on Twitter. That one's just like, don't cross that line. That was just weird. Yeah, but I think in general, just kind of keep context in mind when you're contacting a PTL. If you're doing it through instant messaging, make sure I'm around and even if you're private messaging me on IRC, make sure I'm around. Don't run off after five minutes, even though I'm not there, because I have a bouncer set up but just records the message and I'll answer it when I get back. That's why I prefer people messaging the general Keystone channel so other cores can jump in and talk to them instead. But it depends. If someone's looking for work and they're looking to help out, then make sure you set the context of the email properly and say, again, set expectations and be like, hey, I found this issue and I would like to resolve it. How can I go about doing that? That's great. But I'm not a support team for you. Be like, my Keystone's not running. Can you fix it? No. File a bug for that one and yeah. I'd like to add a comment in there. If it's not obvious, I live in Australia. And really, I know, right? Australia is on the other side of the world, which means I'm asleep when a lot of you are awake. So that means if you ping me on IRC, you're in for a long wait. My nick will be on there because I have an IRC bouncer as well and there's a really good chance I will see it in scroll back, but by the time I see it, you're not there anymore. So if you can, try and be a little bit aware of the fact that we are a global community. So if you don't get an answer straight away on within a couple of hours on IRC, it might be because we're asleep. It's a good idea in that case to just drop an email because it's asynchronous, we'll always be able to get back to you. And you can give us a little bit more context. Like Steve was saying, you can give us a bit more context in an email and we can get back to you with a more thoughtful answer as well. Well, since we're on the subject of communication, how can a new person start contributing to a project? I mean, what steps should they take? So the obvious is look at bugs, but there are other ways. Like first of all, you need to install the new project and if you're facing troubles with the installation, then maybe the documentation is not good enough. So okay, if you fix the problem, go ahead and fix the documentation. It will help you, it will help the next developers and it will help us. We are always happy to see such a pictures. And other things that you can do is like add tests, which is something that... I mean, we are writing tests, but it's a very good way of knowing the code and learning how to use it. I think that's a good way to start. And when you start, after you install the product and you start using it, you might see that some things are missing or something are not looking so well. And these might be things that we don't see because we are so used to working with it as is. So we are always happy to hear comments of someone who's seeing it for the first time. I think it was mentioned in the keynote this morning, just code reviews, just more and more code reviews. And meaningful ones too. Cores are not perfect. Even if you're not a core, do a code review and don't be afraid to minus one. Even if another core is already plus-duded, just minus one, if you think it's justified. You won't upset anyone. Yeah, just code reviews. That's how I... I think that's a great way to learn the code base. It's a great way to learn kind of like the criteria that the core team uses to justify a plus-two versus a minus-one. You'll get to know how the... Just in general, how the team works. So, code reviews. I think with documentation, there's quite a few entry points, and it really depends. Each contributor has their own strengths and weaknesses. If you're a documentation person, if you're a writer and you're not necessarily familiar with OpenStack, then there's probably some proofreading, some editing you can do. If you're an OpenStack developer and you want to come and help out with docs, then there's always going through, say, the install guide or our user guides and, you know, for whatever project you're familiar with and finding out what needs to be updated. If you're more comfortable with, say, networking, go and review the networking guide or whatever, there's lots and lots of entry points in docs other than the obvious going and looking at bugs. Great. I'm going to circle back to Stephen, his code review, code review, code review. I agree with that for what it's worth. I think everybody agrees, you know, start with code reviews, but, okay, so if you're a brand new contributor, you don't really know the project. How can you do a meaningful code review? And, you know, I know you mentioned it's okay to already comment or leave a review when a core has plus two, but how do you start, you know? It's like, what do you write down? How do you do a meaningful code review when you don't know the code? I got very, sorry, I got very hung up when I started on what makes a good review and review rigour and that kind of thing, especially with documentation, because I could look and work out that the words were English, but I couldn't necessarily tell you if that was correct in a technical sense. So I did get very hung up on what is considered a good code review in docs, and I did end up writing a whole bunch of that down. It's now in our contributor guide, so you can go read that if that interests you. I think the best thing to do is expect that there will be reviews you don't understand, and it's okay to withhold your review if you don't feel like you understand it enough, but still read it, still go and look at that patch set, go and look at the diff, read what the other commenters have said, and you will, over time, as you do this over and over again, you will learn more, and when you do have an opinion, even if that opinion conflicts with what other people have said, that's okay, it happens time and time again, where we have a minus one, like Steve was saying, we have a minus one even after a cause come through, and it means that you've picked up on something we actually missed, and that's wonderful. We get, I think, cause look at so many reviews every day, we do get a little bit automatic with it sometimes, we go, yep, yep, yep, and we also have, I know what I do, I fall into that problem, oh yeah, that guy, I know him, yeah, he's good. Yeah, I mean, I still think you can do meaningful code reviews even if you're not totally familiar with the code base. There's some obvious ones out there, I mean, if someone's adding functionality and there's no test, minus one. New functionality, no docs, minus one. There's an automatic checklist in my head that goes off every time I do a code review, and it's pretty easy for me to just minus one something if it's not meant in that list. And then there's simple things, just basic programming, I mean, if someone's doing the same thing twice, suggest factor this onto a method and just do it once and call that method. I've seen that a bunch of times where people just have common code everywhere and it could be factored onto a private method. And even if, say you minus one something and say, I think this should be blah, blah, blah. And a core comes back saying, no, actually, if I saw that, I would correct the person and be like, no, this is actually, we're doing this because of X and I'd correct the person and at least there's a mental note going off my head saying, okay, well, this guy had at least, you know, feedback. It's not just a, the ghost minus, the ghost plus one is annoying, I think. Or someone just drops a plus one and leaves, no comment, no nothing. Even if you completely agree with the code, just leave some indicator that you understood what was happening. Like say, oh, this was a nice refactoring or this is a slick way of doing this method. Something that shows me spent more than five minutes on the code review. I don't know if we're taking questions but there was a question over there. Yeah, sure. Yeah, that happens in docs a lot because as I was saying before, we've got the technical aspect of it as well as the writing aspect. And so it is absolutely okay to go, yes, this looks like good English, I haven't tested it, you know, for technical accuracy. And it's, like you say, exactly, it's absolutely okay to have a zero review. Feel free to have zero if you've got something to say, you wanna weigh into a conversation or have a comment about it but don't have an opinion either way. I know there's been, there was one or two posts on the mailing list that people were kind of getting annoyed that folks were minus oneing and all the reviews, all the comments were actually just questions. And it was more they didn't understand the code base completely and it was just kind of a form of a question. So if you're asking just questions about why are you doing this, then I'd say leave it at zero but each project's gonna be different. Like I don't mind if you do that in Keystone, that's, you know, it's not gonna bother me. Yeah, so each project's gonna be a little bit different the way they treat minus ones and zeros. So basically if you're unsure, contact the PTL and ask. Yes. Okay, so now I've done code review after code review after code review. And I think I'm actually ready to tackle something. I wanna write some code but there aren't any open bugs. What is this magical project? They just, you know, pretend. I know this is open stack, there's always bugs. But pretend, okay. So there aren't any open bugs that are at a level that I think I can do. Okay, let's rephrase that, okay. You know, what should I do? What, you know, what kind of steps should I take? You know, should I just find some bug I can do and bump the person off of it who grabbed it? Or, you know, what should I do? Well, maybe you can find a new bug. This is something that happened for us. If you find a bug, go ahead and fix it. If you can, I mean. But it's a good way to start. Or if you see that a bug is, you know, someone is assigned to it, but for a long time nothing happened, maybe email it and ask for getting the bug. Go and read a book and find a problem in it. From the doc, PTL. Which I think is the same answer. Okay, so, you know, I'm wondering, is it okay to basically email the PTL and say, hey, this is my background? Yes. What can I do? You know, is there something for me to work on? Yes. You can always email the PTL. You can always email the PTL. This is what I see the PTL's role as it's very much more community than anything else. So obviously there's the technical aspect of it. But my job as a PTL, as I see it, is to make sure we're all swimming in the same direction. We're all heading towards a set of common goals. And it's my job to make sure that I'm removing the impediments to you doing that. If you're having trouble getting started, if you don't understand a piece of the technology, if you're struggling with getting a blueprint approved, any of those impediments that you run across in the course of your day-to-day trying to improve OpenStack code, that's what I'm here for. That's what I'm here to help with, is to remove those impediments. No, I just think it's fine to email the PTL. Just, you know, frame the email properly and set expectations and set your contacts correctly. You know, if you're willing to help out, great. You know, we'll find something for you to work on. Okay, so now I've started working on something. And I'm stuck. And I've emailed the dev list and I've put my question on an IRC and I've waited and I've done it again and everybody seems to be ignoring me. What should I do? The status? I hope they're ignoring you because they're actually really busy and not because they're being horrible. If you've been completely ignored, there is something wrong in our community for starters. And I would definitely email the PTL in that case, if you've been ignored or if someone's been mean to you because you asked a simple question. There's no such thing as a stupid question. Yeah, I think personally it depends where the problem you're having is. The problem's with a patch. Go ahead and email the people who've commented on your patch. Especially if there's cause who've commented on it, email them directly and go, hey, why did you give me that score? Why did I just need to more understand your comment. You can email people and you can talk to them all the time. I know docs have their own mailing list separate to the dev mailing list. So sometimes email to the dev list will go missing, I think. I know I don't read every email on the dev list because otherwise I didn't forget any work done. And I think you need to be aware of the volume of that list is quite difficult to manage sometimes. So things do get missed on the dev list, I admit that. So if your project that you're interested in does have their own mailing list, email there, it's usually lower traffic. You can find the core team, you can find a mailing list for the core team for your project through Launchpad. Feel free to email that. It's again, a low traffic mailing list that will just get the cause for your project. And yeah, definitely email the PTO. Same thing, I mean, either find someone relevant for the question or email the PTO, ask for help. And most likely people just meant to answer later and didn't get to do it or, and if you ask again, you'll probably be answered. Yeah, so kind of what they were saying, just it could be a mix of things. It could be, it depends how long have you been waiting. I saw someone reply to their own post on the mailing list, literally a few hours later, saying why isn't this been answered? Yeah. So have patience. And to be honest, sometimes I will leave something unread in my inbox and make a note of trying to get back to it. But the reason why I haven't gotten it back to immediately is because sometimes it's just a generally hard problem. And it's not that I'm trying to be mean and ignoring people, it's just this one deserves a little bit more thought and I need to go do it when I have some free time, more than 10 minutes. Alternatively, you could also, if it is a hard topic, like I mentioned, go to the project meeting, propose it to the agenda and this way it's a very active setting and people are kind of forced to answer you. Don't be afraid to edit meeting agendas either. They're all community created. It's not up to the PTL to write that thing. We generally have a core, I do anyway, have a core list of standard agenda items on my meeting list that just stay there every week. If you want something to be mentioned, this is why we have them in a public editable place. Just go and edit it and add something in and that way it'll definitely get raised. Even if you don't make it to the meeting because time zones are hard, it will get discussed. For sure. We've covered a lot of great ground here and a lot of good advice, but I would like to know, in kind of wrapping up, what's one piece of advice for new contributors? One piece of advice. You can't break anything. I think, yeah, don't be afraid. Just do it. Email people, make patches. It'll be fine. I would say, don't wish I ask questions. Questions are a good thing. If you ask a question, we understand that there is interest in the project and you might help someone else who was wondering the same thing and he was shy to ask, so everybody will see the answer and there is always a chance that you are thinking about something that we didn't think about, so your question might inspire us to change something. In any case, there is no stupid question and we will always try to help. Yeah, just know the fact that every OpenStack guru, PTL, core, everyone has been a newbie at one point in time and has done something equally silly, so don't worry. I mean, we'll pay it forward and we'll be nice. So don't be shy and poke us. Excellent advice. You're gonna be poked a lot, I imagine, on the next couple of months. So that kind of wraps up the questions that I have for the panelists. Are there any questions from the audience? Yes? I'm making a project in a code of conduct and all that good stuff. Yeah, that's a long answer. Like I say, I see my role as a very community-minded one and you do come across people who are toxic. It happens everywhere, especially in open source, can I say? And in that case, what usually happens is we'll get notified, it's usually a core team member, will come up and take me aside and go, hey, this guy. And so then what happens is usually a series of private conversations and a little bit of coaching and we'll come to some mutually reasonable agreement. And I haven't had it too much better than that. Well, I was lucky not to run into such people yet, but I'm learning of how to handle them, yeah. The worst I've had to do was ban someone from the channel because they were being just verbally not, or not verbally, because it's over IRC, but, you know. They were just... Textually? Textually, yeah. They were just being borderline abusive, so I just had to ban them and I let the info team know. But I feel like it could be a case of, I think some of the folks in the community can be a bit short, a bit curt, and they don't mean it, it's just kind of their personality. So even though they may seem like a jerk, it's probably not what they mean. It's just some folks are just, they'll just be very direct and when they're doing code reviews. And if I notice that, I will just poke them be like, hey, can you just be a little softer? Just, because, you know, especially if it's a newcomer, especially if it's a newcomer. And if you do run across anyone who is really, truly abusive or toxic, we have a code of conduct for that. And definitely in that case, just ping someone, senior, whether it's a PTL or someone in foundation, and we will deal with it and enforce the code of conduct as it needs to be. That was an excellent question, thank you. Any other questions? Yes, here, let me. Yes. I think that's a yes to, a constant yes, that all projects are looking for contributors. Any other questions? Any other questions? Well, thank you very much for coming to the PTLs and Cores. We're not as scary as you think panel. Synopsis of the panel will be available after the summit on the Women of OpenStack Wiki page in the past speaking sessions, past speaking sessions section. Thank you all for coming and supporting the Women of OpenStack. Thank you. Thank you.