 If you're not in here for this presentation, then enjoy it, I guess. My name is Geerling Guy, or Jeff Geerling, and I've been using Drupal for about nine years, Ansible for about four years. I've been involved in a lot of different things in open source, but mostly in those two communities. I also work for Aquia, started working there a couple of years ago. I also write a lot. I wrote quite a bit to make a book, and I do a lot of blogging right for many different places. And one of my passions in the software world is to automate, so automating processes and automating builds and automating basically anything. I also like to find ways to automate the rest of my life, but oftentimes it's impossible, like with sleep. But I'll give you tips, I guess, how to automate those kind of things, too. And I've been highly involved in Drupal, but in terms of notoriety, I've been compared to Dave Reid, but in the Ansible community. For those who don't know, Dave Reid, he's not quite as crazy as he used to be in terms of his Drupal module contributions, but he used to maintain something like 50 or 100 modules, and a lot of them in, like, the top 50s. It's pretty crazy. I maintain a lot of open-source projects, and a lot of them are widely used. There are, I think, 10 or so that are over a few hundred stars on GitHub, and there's lots of forks, there's lots of activity, and a lot of people ask me a lot of times, like, how do you do all those things and have a family and write and do all these other things? I don't think it's too crazy the way that I do things. I'm going to tell you about how I do it and some tips, but I think a lot of people feel that it's a daunting task, but it's kind of like all the other sessions on the imposter syndrome. You might feel that until you start doing it, and then you realize it's just one of the priorities in my life, and I can schedule it, and I can do things with it and be productive because of some of the things I do. My claim to fame is that I'm the highest ranked open-source contributor in St. Louis. But, you know, I guess if I stay in the Midwest, I have a good chance of keeping that, but over on the coast, probably not anywhere near that. But open-source is actually just a small part of my life. Besides this week at DrupalCon, there's no times in my life really that I spend more than an hour or two a day doing anything open-source. I'm a husband and a father of three kids all under the age of five. Things get pretty crazy at home. This is a common ritual in the Geerling household. It's the changing of the diaper genie. And as the kids are getting older, one of them is not in diapers and the other two still have productive bowels and things like that. So, there's things like blowouts and explosions of things that you'd rather not be touching. And this often happens at the most inopportune times. I also deal with meltdowns and I have activity time and family game night, all these different things that I, it's really important to me. And I think most people that have families, probably all of us to some extent or another, the family is a driving issue for why we do what we do, an open source and in our work and all that kind of stuff. I also have a passion for photography. Before I was a web developer, I was both doing video and photo and some media work and that's kind of actually what got me into Drupal because I was doing videos and photos and I needed a place to put all that stuff to share with people in my college and I found this awesome thing called Drupal with a module that lets you upload files and I went to town on it and I think that site actually still exists. It's using the Garland theme or I think that was Drupal 5, I don't remember. Maybe it was Drupal 6, but anyway, it led me into Drupal and I still do a lot of photography but it's mostly of my kids and birds and things like that since I don't have the time to be able to devote to it otherwise. And I still do it here at events like this. I like to share that gift that I was given to be able to have a nice camera and to be able to take a picture and it's not blurry, that kind of thing. So I enjoy photography. I also enjoy not making drugs. I'm building an office. This was when I was building an office in my house for my aquia job. It's a remote job so I needed a place to stay and work. I was removed away from the kids who can kind of distract and I like doing things like building and remodeling and light gardening even though if you talk to any of my plants, they're all perennials when I buy them but they seem to turn into annuals at the end of the season. Every year I have to replant all of them. And the last thing that has a big impact on my life is I have Crohn's disease. So it affects me on a daily basis almost every day of my life since I've had it. In this picture, this was a few months ago, I had my first surgery. A lot of Crohn's patients have one, two, three, many surgeries to assist with it. I'm doing fine right now. You can see I'm standing up. I'm not on morphine or whatever that was. But one of the things that this has taught me and also raising kids and all these things that I do has taught me that the people that I work with and open source, the people filing issues, the people who submit pull requests and patches, I have to have compassion for them. I don't know what they're going through. If I didn't show you this picture and you saw me in the hallway, you might not even know that I have Crohn's disease. There's a lot of illnesses. There's a lot of mental issues. There's a lot of relationship issues that you'll never see it because people are good at masking it and hiding it. Or it's something that's just under the surface. So I always try to treat everyone like I would want to be treated. And the point of that is that all of us, the maintainers of open source projects, contributors, the people who really get on your nerves, we're all people, we're all in this together. We all have human needs and desires. I have things going on in my life that affects the way that I do my work and the time that I have for my work. And it's important for me to be able to somewhat compartmentalize that and do things in a way that supports the rest of my life and doesn't tear it down. And really, a lot of times when there's burnout, when there are issues that cause somebody to leave a community or to stop doing some sorts of development, it's because of the other things in their life getting impacted negatively. And open source is not seen as something supporting that. Therefore, open source is the first thing to go. So this presentation, the whole point of it is I want to show some of the ways that I make sure that my open source work is supportive of the rest of my life. And also, the rest of my life can support my time doing open source as well. So this pie chart shows my average day. And anybody who has a significant other, who's an engineer, programmer, that kind of thing, they realize that you compartmentalize your life just like you have the food on your plate separated because you can't have things mixing up. You have to have nice categories for everything. Most of my day is spent either working, getting my W-2, or sleeping. So already a large chunk of my day, every day, at least on weekdays, is spent doing things that aren't supporting that family life necessarily. So there's things that can help with it, but it's not something that directly impacts my ability to be with my family and grow in love with them and everything. I also do things like eat. It's necessary, unfortunately, for our growth and potential. Someday we'll figure out a way to automate that. And then I also, well, it says read there, but it's really that's the time that I binge on Netflix, read some Reddit, Facebook, those kind of things. And there's this little sliver of time left. It's about one to one and a half hours in my daily life, and that's the time that I dedicate to open source work. So like I said, that's usually the first wedge that will get consumed by something else. If you're work, if you're being overworked, or if you're having family issues, hopefully not eating for more than three or four hours a day. But if you have issues and you're spending too much time browsing the web or doing things that aren't really helpful towards your own family, your own life, all that kind of stuff, the open source is usually the part of the wedge that gets closed up first. And so I want to go into the ideas that I have by showing you here's what my typical day starts off like when I'm going to do some open source work. The kids are in bed. I have my hour or so of free time without having them kind of going all over the place. Anytime that I'm at my computer, they will flock to it and start to hit the keys and things. So once they're in bed, I have about one to one and a half hours. So I'll open up my email and click on my open source folder and yikes. There's a lot of unread notifications. Obviously, I doctored this a little bit. I just marked them all as unread so that I'd have a cool screenshot. Usually, though, there's between 30 to 100 messages on a given day. And it's a daunting queue. So today I'm not going to do that. I'll go to GitHub instead and see what are the things going on just there. I'm going to ignore Drupal and ignore some of the other issue queues. Just GitHub. And maybe I won't even do that. That's just too much. It's an overload. So I'm just going to jump right in and find an issue to start working on. And this one actually looks pretty good. There's some good things about this here. I think tonight's looking pretty good. First of all, this person added a description that had all the reasoning behind the change. It shows me, it even links to some documentation saying like this is why this is a good idea. It explains the small change that is in there very well so that I don't have to spend time thinking about what's going on. So if you're somebody who contributes to open source, take some mental notes here. These are the things that get your things merged in quickly. It also has one small change that's only 14 lines of code. That's really nice. That means that I can click over to the files change, look at the patch or look at the changes. And I'm going to be able to keep them into my head so I can see, oh, is this a good thing? Is this a bad thing? And it also has one commit. So that means that either they were doing a lot of work and they cleaned up their commits into one commit. And also, I don't have it in here, but the commit message described what was going on. So that's good. All these things are great signs. And it even passes the automated test. This is great. So if you're ever submitting a patch, submitting a pull request, these are the kind of things that maintainers love to see. So I merged it. You can see it's merged up there. And today's going really well. This is like, I'm going to finish 10 issues at least, maybe 20. But then reality is going to hit. And I start finding these other issues. It's actually, you know, the next issue in the issue queue has been open for six weeks. And nobody's ever responded. Another issue has been open for a year and a half. And I replied and said, hey, can you try doing this? And he never responded. And then the third one has been open for four days. And it's something that's answered in the documentation. And I linked to it and they never responded. So these issues and some other types are very common in my issue queues. And I'm sure in many of yours. And I'm going to introduce you to some of the characters of these issue queues. As the ghost writer, when the original poster just up and leaves, disappears from the planet, you never hear from them again. And if you look at Drupal Core's issue queue, you're going to find probably thousands of these. I mean, there are good excuses for why it happens. But if a maintainer comes back with a question or something, I always try to follow up. And if they've answered my problem or if they've fixed it or something, I will close it since I posted it. And that way my issue queue can be a little cleaner. There's also three other types of issue. The CNO docs, read no docs, and fix no docs. CNO docs I already described, I'll give somebody a link. And it's obvious that they don't read them because they reply again and say, no, this isn't working. And I'm like, well, if you take your error message and paste it here, then here's the answer. Like, just do it. And then the read no docs is when you put them in and... Actually, that was read no docs. Sorry, I'm flipped. CNO docs is when, like, the first page of your read me or documentation says do X and they do Z and they wonder why it's not working. And then last is fix no docs where somebody says, hey, this documentation line is wrong. And then the issue kind of sits out there forever and nobody ever fixes it. And you as the maintainer don't care too much because it doesn't affect you. But if somebody would put up a pull request and just put a one line sentence and they're saying what it is, it would be merged immediately. So these issues sit out there forever. These issues are very dangerous as people on the Titanic discovered. Icebergs are issues that it's a tiny patch or a tiny issue or something that seems really simple. And then you realize an hour and a half later when it's time for bed that all of your open source time is gone for the day and you just looked at one issue and it was something simple, like a one line change. And at the end of it you're thinking, man, if I would have known that, I just wouldn't have touched this issue. I would have left it off for some other time. So those are the icebergs. And if you're a maintainer, you've probably seen lots of these. The person who prods you to merge an old patch that's passing tests or something. These I call the foreshamer. A lot of times there's a little passive-aggressive undertone of why haven't you merged this, or hey, it looks like this is great, please merge it. Now, a lot of times these are well-intentioned, but I guess my advice for somebody posting an issue is try to think of what your language is saying and try not to make the maintainer feel bad by what you say. So I'm all for plus one. I'm all for bump. That's fine. Or even like, this is a really cool change. I'd love to see it. That's great. Notice how it's a positive tone. When you say something like on this one, you know, why hasn't this been merged yet? All of a sudden, myself as a maintainer feels accused. Like, I'm unjust for not merging this ticket. So be careful with those. The next one is the Dung Heap. These are very easy to identify. It's a pull request or a patch with a thousand lines of changed code, zero description. It breaks automated tests. It has 20 or 30 commits if it's on GitHub. It doesn't follow the coding style. And these are usually pretty easy to just close right away, but sometimes the person gets offended when you close it, and then it takes maybe a few hours of your time cumulatively to teach them the process. These aren't the worst because a lot of times, people who do these, you can teach them. Like, here's how you actually do it. Next is the Diamond and the Rough. These are a lot of times the same thing as a Dung Heap, except there's one change, usually in the middle of the commit history, and it's usually tied in seven different places in code, just enough that it's hard for you to pull it out, where there's one really good change mixed with three or four bad changes. There's three or four changes that you don't want to approve yet. And these are often also combined with a ghost writer, because somebody dumps the change, and you say, I just want this thing, can you change it? And you never hear from them again. And then after a few months, a few foreshamers pop in the queue and start asking why it hasn't been merged. Next is the Imposter. These are when you meet somebody at DrupalCon and you shake their hand, and then they tell you about their life story, and then they realize that you're a sucker for helping people. So they'll post in your issue queue something not entirely related to your project, just because they know that you're going to help them. So those are the imposters. Usually I'll ask them to email me directly or something. The issue queues aren't the place for asking general help often. Then there's the black hole. These issues, I have a very pertinent example. Who here has seen the issue about the DrupalCon and DrupalCore changing the DrupalCon? Okay, so a couple people have. This issue has been open, I think, for four or five years. It started off saying, the DrupalCon disappeared from Drupal's installer. Let's update it and refresh it for a new millennium look. And what is it, 380 comments or so later? We're still on square one saying, let's figure out a way to update this. These are the issues where it's a simple task or a simple change, but a few conflicting opinions turn it into a, maybe four to 20 year ordeal. And Drupal has plenty of these. They often devolve into bike sheds. A bike shed is when you want a bike and you're about to deliver the bike, but then three or four people start arguing over what color to paint it. Something like that. There's something about a shed, but basically it's an issue that goes forever. So whether or not you know who Dory is, if you have kids, I'm sure you do, if you don't have kids, then you probably have at least seen Dory somewhere or another. She's a fish with a problem with short-term memory loss. And she's a very optimistic character, though, and she has a good reminder for us to just keep swimming. If you feel like you're drowning in your issue queues, you can keep swimming with some of these tips that I have. That's as far as that analogy goes, sorry, if you're expecting a whole Finding Nemo chain of slides here. One of the things that helps me a lot is to add some personality to my projects. So if you were at DrupalCon, I think a year or two ago, I don't remember which one it was, I brought my little Raspberry Pi cluster with me. I called it the Pi Dramble. So I gave it a name. That was one little thing that helped me to relate to it. It's not like the Raspberry Pi Drupal cluster, it's a Dramble. I made the term and it means something about like if you're drugged up and stumbling around, but that's not the definition I was using. But I gave it a logo, too. And once I did that, I was like, it has a name, it has a face, and it's something that I feel, it's very under the surface, but I feel attached to it in some way. And other people have kind of responded a little bit. When you have a logo or a name or any kind of branding at all, it can really help your project to be relatable and people will kind of, sometimes you can fall in love with it. People have fallen in love with Drupal through the DrupalCon, I'm sure. Except I just noticed it was half deflated out there, poor guy. But another thing you can do is build some informal branding guidelines. Drupal VM was something, I started it three or four years ago, and it was actually called the Drupal Development Virtual Machine or something like that. Then I realized that's quite a mouthful, it's not really easy to roll off the tongue or anything. So I spent a little bit of time, once there were a few other people using it, I was like, I want to have this be something and not just a thing on GitHub. So I said instead of the Drupal Development VM or the Drupal VM, I said it is Drupal VM, and I use it in sentences as a noun. Drupal VM is this and that. So I can relate to it just like with the Raspberry Pi Dremel. And I also kind of, there's no branding guidelines in my repository or anything, but informally I have a rule of it's always capital D for Drupal, space, VM. And doing that has added some consistency. It makes the project look a little more polished, and I added, it's not a very good logo, but it's something. Whenever you see Drupal VM, that's, you know, there's a star with it, and stars are happy and stuff, I guess. I'm not a logo designer, so I don't know the psychology of things. It's just, I thought it looked nice. But it is good. People know that it's Drupal VM by the fact that it's consistent. There are a lot of other projects, too. The ones that you feel like that could be good, a lot of times it's because there is a brand, there's a logo, there's some meaning behind it. I see you got your doxel shirt. When I first saw it, I'm like, man, that must be really good. I didn't even try it or anything, but it's like, there's a shirt and there's a D with a thing. It is something, it is nice. It is something that's helpful. Another thing, I was actually reminded of this yesterday, so here's another tie-in with finding Dora, I guess, short term memory loss. Yesterday in a Composer Boff, I had mentioned something about something with Composer and how it's ruining our lives and all that kind of stuff. I actually do like Composer, so don't quote me on that. Anyway, I said something about it and somebody said, oh yeah, there's this issue, and I'm like, oh really? I didn't know that. And then he said, oh yeah, it's issue, whatever. He found it and I scrolled down and I had the most recent comment two years ago, or two months ago, if it was two years ago, it'd be fine. And I'm reminded pretty much on a weekly basis, sometimes daily when I'm really working on something, that, I mean, this is open source. Open is a very important part of it. And when you're developing on something or when you're changing something, if you want to have other people be involved and if you want to remember what you did, because 1.5 hours is not a lot of time to do a large change. So a lot of times you'll start something one day and then two weeks later get to pick it back up. If you keep your notes somewhere that is not able to be easily found or Google-able or anything like that, or if you don't put down any notes at all, it's going to be really hard to have long-term history of maintaining something. So I always, if I'm going to work on something, even if it's like a one-line change, I might not open an issue for it. But anything bigger, I'll open an issue, I'll put the problem, I'll put the proposed solution, I'll do the work and I'll push up a patch or on GitHub put a pull request up against it. That way, if I'm not finished with it, then someone else could take it. And if I need to come back to it in two or three weeks or some things, it's like six months later, I have the context. I don't have to spend the time. So as an open source maintainer, even if I'm contributing to my own project, I don't give myself like one of the contributors. If I don't give myself the context and the information that I need to continue something. The other benefit of that is, if I ever look on Stack Overflow or Drupal Answers or something and I see an answer that's like, pretty good but not perfect, I'll comment on it. Leave the comment there. Or if I find a question that's not answered after five years and I found the answer, I'll go back there and spend a little time answering it and hopefully a year or two later, I'll have the exact same issue again. I'll search it on Google and I'll be like, oh, yeah, that's exactly what I need to do. Oh, I wrote that. It's not something that means I have a lot more time or anything. It's the same amount of time that I spend either way, whether I document it or not. It might take a minute or two longer, but the amount of time that saves me in the future and potentially, and most likely, saves hours or hundreds or thousands of hours throughout the course of history of these open source projects. So try to work in the open. Oh, and one other thing too is my blog, like a lot of people ask, how do you have so much time to write these blog posts? Like sometimes it's like one or two a day. It's because when I'm working on something, I use my blog as my scratch pad and usually I'll write like the steps that I'm doing something or whatever. I probably have 100 or 200 posts in there that I never finished. It's like 20% of the way there, but I never finished that bug or I found something else somewhere else that I could do. But I just document as I go. I write a blog post as I go and a lot of my blog posts aren't like Pulitzer Prize winning reports. It's just, I have this problem and here's how I solved it, step one, step two. A lot of times those posts are posts that end up helping people a lot and they're having the same problem. They Google it, they find the answer or you do a year later, which happens all the time. And I put this here just because I like Tesla and no. There's a reason I put Tesla up here. They are, right now they're by market capitalization, the largest automotive manufacturer in the world. Not in the world, in the US, sorry. And a lot of people are wondering like why is that and one answer could be well they're an energy company, not a car company. Sort of true maybe, but I think the reason is more fundamental and something that Elon Musk who owns Tesla and a lot of other companies, he said that we focus on designing the machine that makes the machine. They turn the factory into a product. I think that that's a lot more inspirational and foundational and the reason why it's a valuable company. They're not about making batteries, they're about making cars or semi-trucks or space x's and only about making rockets. They're about transforming the process so that they can make cars better and so that they can make billions of batteries and they can make things much cheaper. And as open source developers, we're software developers and in the past five to ten years automation has become something that can help accelerate our growth and our ability to do things and bringing that way back down to our level, there's a lot of things that we can automate and that's one of the reasons why I have 160 projects and not like one or two. Almost every one of my projects has almost full coverage of automated tests. Like if somebody pushes up a pull request, it'll break if it breaks the project. I don't have to every time grab the code and run it locally and do all these manual tests and things. I have some pretty solid assurance that at least the main parts of my applications and programs and things are all running fine. So automated testing is really important. Another great example of this is Drupal itself and Drupal 6 had, I don't think any tests. Drupal 7 had like 30 or 40 percent test coverage. Drupal 8, I don't think it's 100 percent but it's getting there and Drupal, at least Drupal Core has been incredibly stable, at least per release. Upgrades and things are a little bit different because they're harder to test. Automated tests are essential to maintaining a good long-term open source project and being able to refactor things and update things and take out chunks of it and put in new things. It's very important. Another practical thing is if you're on GitHub, you can actually add an issue underscore template file in a .github folder. In the presentation later, I'll have a link to it. The link to the documentation. You can put in there some of the things like the foreshamer and the dung heap and all those. A lot of those things can be prevented by just having a couple simple instructions. Please, you can put in this template delete this line and put what OS you're using or delete this line and put what browser you're using. Little things like that because a lot of times issue queues get clogged up by issues and you have all the facts available. You ask for the facts and then of course it's a ghost writer so you're never going to see the facts. If you ask for them up front like that people will put them in. On Drupal.org right now, there's no way to do that in the body template. There's a way to add a message above the form or something that nobody ever reads that. I should probably open an issue to ask for an issue template thing for Drupal.org. Another thing that's important to me is that every single open source related thing whether it's a GitHub notification or Drupal.org or any of that kind of stuff it all goes into a separate mailbox and that mailbox is not included with my unread count. If it were I would never get to any of the open source stuff and I would interfere with all my other stuff so we have enough email as it is. But one thing that I do like to do is I still have all my projects notifications sent to my email when I'm starting my work every day on open source. I can at least click on the bottom one and go up up up and look through each one to see is there anything critical like if there's somebody reporting like I installed this and my database is gone I will take a look at those pretty quickly but other than that I'll just see is there anything interesting are there any PRs that look like they have a good description and all that and I'll go ahead and merge this with your issues and pull requests. And finally I mentioned Doxel earlier and Drupal VM to a certain extent is similar in this you need to have tools that will help you to get your project running very quickly and Docker is a great tool to help with that nowadays if it takes you more than maybe 5 to 10 minutes at the maximum to set up your project and get it running and put a patch on it or pull down a pull request or something if it takes longer than that then that 1.5 hours of time is going to be a waste it's going to take you longer just to deal with your local environment to reproduce something so always have an issue template if you can always add automated tests find a way to make your infrastructure quick to set up and add some email filters those are the four ways I mostly automate all my projects there's some other things you can do too but that's what I do the next important thing and the reason why we're all here today is we're a community of people that use Drupal or that are affected by Drupal in some way and as your project starts getting more popular you'll have to interact with people you'll get to I'm an introvert so I say you'll have to interact with people but there's some things that are important to do one of the things that basically the only reason I've been able to continue working with some of my projects is there are some people I'm calling them fans it's not like they're a fan of me or my thing necessarily usually it's people that need your thing to work so they want it to work well and they'll help you you need to connect with them and make them allies so not just fans and not just people that like your thing but you want to see what they need see what they want start working with them sometimes like for instance with Drupal VM there's three or four people two of them are now maintainers alongside me they have consistently shown that they have a good issue they have pull requests that have all four of those criteria I was talking about earlier and they've been consistently coming back into the issue queue you can start seeing that pattern after 10 or 20 issues total in a project and a lot of times they'll start doing more than you can do and that's one way like in terms of the Drupal project we have a bunch of core committers we have hundreds or thousands of core patch submitters and people can come and people can go it doesn't break anything because we have a strong community and a lot of that is because people got attached to Drupal or people needed Drupal and we kind of worked together and I think that's important is giving people fake internet points otherwise known as karma open source is for the most part a volunteer driven effort I'm not paid for anything I do with Drupal VM I'm not paid for anything with Ansible except I have a way of getting some money back through my book I guess but when money is not actually available then gratitude is the currency that we have for open source and gratitude is something that makes people feel better about themselves and it makes you feel better for thanking them and having that relationship so give them karma through mentioning them on Twitter putting in the changelog you can say thanks to this person if there's somebody that is working for a company giving them time thank the company and be very flattering because that's why I do open source because I want to feel better about myself so if you flatter people I'm only kidding a little bit about that but if you flatter people they will feel better about doing work for your project and if you don't flatter them a lot of times there's not a lot of personal incentive that they do and we've seen this in the Drupal community as we've started incentivizing some things like contributions and you see your profile has more like more commits and more projects and documentation statistics and things people will do things just to get that little endorphin rush another thing which is fairly pertinent at this period in our Drupal community I'm not going to deal with any particular issues right now I take a philosophy of to any extent possible avoiding any drama a lot of times drama comes up and it's usually between a person and someone else or a person in some code or something like that most of the time if you don't step in as a maintainer, if you don't step into the particular situation it will resolve itself sometimes you do have to step in and when you do make sure you take a lot of time and don't ever like I have a rule for myself if there's something that's going on or if there's some sort of issue unless it's like dangerous I will have a 24-hour rule if I won't respond to it I won't even I'll think about it a little bit I might try to communicate with somebody outside of the issue queues really quick just to see like what's happening but I will not respond to it until 24 hours have passed just because all of us we're all human and we all have knee-jerk reactions and we all bring our own we bring our own issues into these situations so giving it that day time to simmer a little bit lets you have a bit of a clearer head and a nice thing that we have in the Drupal community is to reason through things and one of the hard things is drama always takes a lot of time to resolve and a lot of people are not very patient especially when you're used to software and getting things done quickly or the code speaks and all that kind of stuff but it takes a long time to heal wounds or to resolve differences that kind of thing so I guess the best thing about it after that 24 hours is what you're saying going to be helpful if it's going to be helpful sure go ahead and do it if it's not going to be helpful maybe you need another 24 hours or maybe you need to take a short sabbatical and stay away from the situation and let your users know that and some of the things that I've been talking about are summed up or written about much more eloquently the third one is one that I wrote earlier this year or I guess last year I still think it's 2016 but one of the things that's really been invaluable is a cool new guide that GitHub set up, that top link and the links will be in this session's URL on Drupal.org they have a series of guides like guides for contributors guides for maintainers guides for people who are just using the software guides for businesses using open source they're really good I don't know how they put them together but I saw them one day and I'm like this is actually great if I wanted to I could have just pulled off some of that information and presented it to you and acted like I thought of it myself but anyway these are all some good links but really in general what this whole presentation comes down to there's a lot of things in community a lot of things that are that are things that you share with other people but especially if you're a maintainer but even if you're just not just contributors are important people if you're a maintainer, a contributor or somebody that's just involved in using software and being part of the community the most important thing of all of it since we're human and since we have needs and desires and things outside of our open source work is that you need to know that when you say yes to others you need to make sure you're not saying no to yourself and thank you so I wanted to end there and leave some time for discussion because I'm sure that there are other people that have really good insights these are the things that work for me but what are some things that work for other people and also you can ask any questions just don't be an imposter and ask me about Drupal VM right now anybody? yeah can you use the microphone for the benefit of the people who will be watching this in 20 or 30 years so when you spend an hour and a half per day is it an hour and a half per weekday or are your weekends a completely different schedule it depends I didn't mention but some days that can become two or three hours if I had a flow state then I'm going to tell my wife that she can watch the TV show on her own or whatever and I'm just going to finish that issue that might happen once a week maybe once every other week but usually it's about an hour to two hours and I do generally do things on weekends too for me like I said it's partially true that I get kind of an endorphin rush out of doing things open source that's the reason a lot of people do things like this so I'd usually do something on weekends Saturday and sometimes Sunday night but I also trade that off by sometimes on a weekday if I had if we did a lot of crazy things at work or something and I'm kind of stressed you know kids can be kids and sometimes you have a really stressful evening I'll just watch something on Netflix for three hours instead of 30 minutes I'll just binge a little bit could you talk about how you work writing in there yes so that's a good question because the book is something that was completely out of this flow for me I decided it was I think starting before I started working for AQUIA it was in a very strange time of my life because I started working for AQUIA I had our second child and was getting this like working in a new way with a new team and all that and I was like yeah and I'll write a book too and that's also when Drupal VM started becoming a little bit more popular so I had more time to have to maintain it I did that and this is also where my Crohn's disease kind of comes into the equation I wasn't for some crazy good reason I wasn't having any symptoms or any issues with it so I decided to wake up at about 5am every morning and I wrote from about 5 to 6 and so I had that time in the morning and I did the time an hour or two at night working on writing and then the cool thing about the book is and for anybody who does a lot of open source work or even if you do a lot of work with a certain technology if there's something that's good to write about and you like writing or something you can actually use your book to work on cool things for the project and you can use your project as a source of examples and inspiration for the book so a lot of times I'd spend an hour or two writing in the morning the dog is asleep that's good sorry for putting your dog to sleep there you go but anyway I'll spend an hour or two writing something in the morning and then I'll be implementing that or I'll be expanding the work that I did to support that writing that night so unfortunately this has been, it's always anybody who has Crohn's or any of those inflammatory diseases it's a constant struggle I haven't had that kind of availability because of that for the past year or two so use the time that you get wisely and schedule things and try to control those aspects and you can do things like that yeah prioritizing things that families kind of one thing prioritizing work from open source where there's so much overlap can be pretty challenging how do you deal with that? well I work for Aquia I'm fortunate to have a company that open source is at the core of what we do like we do a lot of Drupal and a lot of people here are in the same boat so open source work is part of our day job and it's not always money but sometimes there is money involved too or there is some people who can work on a project either full time or part time and some things that I do with Drupal EMR I can work on it during the day like windows support I don't do windows things out of the charity of my heart I do them because people ask me with dollar signs to do things like that so I think that it's easier to separate things if you do it when you're working and then you carry that over into night you have this blurred line of work versus open source and especially if your work is difficult or challenging or something you can bring those things into your open source and that can cause burnout too so I try and I'm not perfect at this but I try to work out and just focus on community and open source and the hallway track and those kind of things because they're the things that keep me attracted to open source not what I do at work and if my work is ever making my open source stuff not as fun or interesting or something that's going to be hard and a lot of people fall into that situation though so don't have a great answer for you maybe this is not an issue for you it's kind of dependent on personalities involved but how do you make sure that your family realizes that you have a lot of individual pursuits that may not directly involve them how do you keep them realizing that you're not putting those pursuits over them when you have young children they don't know a whole lot anyways but it's important I think that family for anybody that has even if you just have a girlfriend or boyfriend or significant other of any type but especially if you also have children and young children especially they don't see they don't see that it's like something that really fulfills you or makes you feel good and you have to you have to share that passion with them someone like my wife knows what Drupal is and she even knows the Drupal song and my son can sing the Drupal song for you they don't have that same same motivation I don't think my wife cares too much about whether something is open source or not but I tell her about it I check in with her when I'm at these events and it's also something where at night I think it's something that's your personality too at night time we usually sit together and I'll be on my laptop we aren't necessarily talking to each other or something at that time but we will also do other things throughout the day like that four hour family time that I have it is family time I have my work laptop in the basement and I don't touch it once it's five o'clock or something that stays down there and I usually don't even open up my laptop or iPad or anything until the kids are asleep so they see that I have family as a major priority because outside of my work hours family is what I do I think it's mostly just showing them that you can be fully devoted to family and you can have a strong devotion to other activities and passions too and I teach my kids too if they like something we will support them in trying to explore that further like playing a piano or not hitting each other or biting each other but have you ever had the temptation to use delegation as a management to manage the overwhelming number of issues and stuff and could you talk a little bit about benefits and drawbacks of handing over control to other people? I am like the case study and not invented here so sometimes it's hard for me to delegate I guess because a lot of times these projects are like my babies and but like something like Drupal VM or my Ansible book or some things like that, larger projects can't succeed if I'm the only one touching them so the first level is and everybody should be able to do this is somebody submits a patch and you'll work with them on that patch the second level is having people like giving them a little bit more control saying you can close issues or you can label things and then the third level is to maintainer I trust you to make decisions on your own and I think it's just learning to trust other people and having the ability to trust other people some people aren't necessarily able to do that and the sad thing is a lot of those projects will never become what they could be because one person I really believe like one person can't make an entire product that is cohesive and complete and you can do some things and do libraries and things like that or do an aspect of a product really well but it takes a community to build major things like Drupal and Drupal VM at this point I probably only have touched half of the code base a lot of people have contributed a lot of code and a lot of people have also found ways to delete a lot of code which is even better and that's something that I wouldn't do necessarily but somebody else shows so I think if it's a small project you can still keep it on your own or if it's something that's something easily forkable you wouldn't need to necessarily delegate but once you if you want to grow at all you have to start delegating and for Drupal VM it was it was only six or eight months before I gave someone else access to control issues and things and then it was a year or so before I gave Oscar Schildström I'm trying to pronounce his name right he's he's been like super awesome he's he was one of the early guys who I'm like man he keeps just giving me these great pull requests and he keeps responding to these issues with great follow-ups and things like that so I gave him maintainer access and he's he's been like he probably does more it's not a sad thing it's a good thing I guess he probably does more coding work on on Drupal VM at this point than I do I just look at his things and like accept accept yeah so you mentioned you you are having 160 open source projects so where do you start like these are the tools you use on daily basis which you you want to make it open source or as for a new contributor where do you start open sourcing stuff that's that's a good question I a few years ago I started deciding like basically I'm not going to do any closed source things for anything that I work on obviously for for work there's things that I do that aren't open source but at this point like if I'm building a new type of server for something or if I'm changing one of the services I run like hosted solar server checking or something I'll first work on abstracting something into a library or module or something put that up and then I'll start working on getting it working for my application and there's two good reasons for that one is it's open source and it can help other people but it's also selfish reason I don't have the time to spend to make things better and fix things and all that for all these projects so if they're open source other people do that work for me some of them you know there's never been a nobody's hit the star button and nobody's posted any issues but even so if you check the stats on any github anything that's been on github for more than six months or a year there's at least a few people cloning it or coming from search or something like that so it's that comes back to working in the open like for me Google is my notepad I just I just make sure everything's indexable and then I can find it later it's better than like having a giant notebook or something because I would never be able to search that any other questions yeah so I first would like to thank you for your blog efforts because that was very helpful and inspirational for me as well as a maintainer because when we started using Ansible Vink in the beginning my question is how did you start with that like is it is it just that you realize at some point that it's much easier to keep all your notes and just open source your notes or did you spend some time kind of realizing that that's because you mentioned you are an introvert right so but online you are actually extrovert so how did you convert from one to the other one I think it was just it's mostly I think related to the imposter syndrome of when I started working with Drupal Drupal was the first open source project I ever touched and I think I went to Drupal Khan Chicago and realized like these people I saw online who were very prolific and the smartest people ever they were shy just like me some of them not everybody of course and I was like they're human this is amazing so then I started to I had been blogging like just random things for a few years before that but I had never had anyone really see it or do anything with it so I was kind of used to writing stuff that would be out there but when I realized that other people were like me that kind of just changed my perspective of this stuff isn't perfect and it might not might not work everywhere might not even be like the right thing or whatever but I can still share it and somebody might get something out of it but like I said I usually end up getting something out of it later so I think it was overcoming the imposter syndrome not to think that I'm not an imposter but knowing that everybody's in the same boat and I have valuable stuff that people will appreciate no matter what it's related to and even if nobody ever appreciates it it's just it's no skin off my back to write something or publish something or do whatever as long as I feel like it was something that was good to do or felt good about or whatever it's a lot of it is just I like to share and for an introvert especially I don't like sharing in a public space as much and I it's hard to be comfortable in a big party or something but I find that on the computer and online and stuff I can share a little easier because I don't have to talk to people and stuff thanks looks like there's nothing else so have a good last session and I'll see you at the closing session and also if you want to review this and give me like five stars out of five for everything