 All right, folks, we'll go ahead and get started. So hello, everyone. My name is Angie Byron, or WebChick on Drupal.org and other places on the internet. I'm here to talk about the Drupal community, where we're going, and how to get involved. So talk a little bit about how the community works, how the community's structured, all that kind of stuff. How do people hear, is this your first DrupalCon? Holy crap. Wow. What do you think so far? Woo, yay. Yeah, it hasn't even been the opening night party yet, and you're already having fun. This is good sign. All right, awesome. So my handle is WebChick on Twitter and Facebook and a couple of other things, but not on Gmail. So please don't send email to that person, because they get very confused with all these weird Drupal emails, I'm sure. I work at Acquia in the office of the CTO. I am a Drupal Association board member and one of the founding members of the Drupal Association. And I write a book called Using Drupal on O'Reilly, which we just finished the Drupal 7 book last week. So if you want a free copy of it, there's a stack of things up here, come on and get one after my talk, and that'd be great. There's also a little card if you want to give it to your friends, I'd appreciate it. So we're gonna talk about our agenda for a little bit here. First, we're gonna go through a few facts and statistics. I can't say that word, I swear, about the Drupal community. We'll talk a little bit about how you get involved, why you would want to get involved, how to be effective in your contributions, it's not just enough to just go in and start doing stuff. It's good to do it in a way that the community will be really happy about and really gets you a lot out of your effort in time. And then we'll talk a bit about where we're going and sort of what the future of Drupal holds and that sort of stuff. So we'll start by talking about the Drupal community. It's awesome. Drew's Bytar, the project founder who you may have seen on stage earlier, I don't know. He actually has this quote, which I think captures really well my feelings about this as well, which is that it's really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than the code base. And I think that that's really, really true. Because when you talk about what makes Drupal awesome, people will have all kinds of answers. You know, it's hooks or it's CCK in views or whatever it is, but that's all just code. And if you hire enough monkeys, statistically speaking, they'll churn out that amount of code at some point. It's going to happen by laws of physics and stuff like that. But what we don't have in a bunch of monkeys is we have this community of hackers and tinkerers, innovators, that all sort of work together and invent amazing things and sort of play off each other's creativity. Our community tends to double in size each release. So there's around, like if you look at raw user IDs on Drupal there's like over a million users on Drupal.org. I think in terms of active members or something like 800,000, which is pretty good. We have a really strong developer community. That little peak in the graph is when we migrated to Git and that sort of was a good solution because it went from there. So that's always good to see. There's over 200 local user groups all over the world. So no matter where you're from, there's going to be a local user group in your community, or if there's not for some reason, you can go ahead and start one. How many people here have been to a local user group meeting? Most people, okay, cool. Isn't it awesome to go into a room with someone who when you say the word Drupal they don't think it's some sort of non-dairy whip topping? That's pretty awesome. And they're really nice. They're sort of, some of them are like, go get a bunch of beers with people. Some of them are more educational. They do presentations and stuff like that. But regardless of what it is, it's a great way to reach out to local people who also know Drupal. It's a great way to get a job. It's a great way to find people who need jobs. Wow. Hello. I have to watch my talking with my hands. And all that kind of stuff. So if you're not part of your local Drupal community, definitely get involved because it's an amazing way to meet other people and just kind of feel as part of all of us. The Drupal community is made up of thousands of individuals and they're each scratching their own itches. This is a picture of little plastic cats because what they call sort of the stuff I do, which is sort of community management stuff, is they call it cat herding. Because cats are very individualistic. They sort of kind of go off in their own directions. And so as a community person, what you're trying to do is sort of take all of these people that are independently dropping water bottles on the floor and you try and get them all heading kind of in the same direction and that sort of stuff. We call our model of government a doocracy. And what that means is that if, well, it means a couple of things. One, it means that if you jump in and you start doing things, generally speaking, you're the one who gets to say how things go. And other people have opinions on that and that sort of stuff, but if you're the one kind of jumping in there and doing stuff, you kind of get to set the tone. Which is really empowering. Another thing that it means is that nothing gets done unless someone actually does it. So it's kind of an obvious thing, but there is no company who is behind Drupal. Drupal is a community of individuals. Some of them work for companies. I work for Aquia, some people work for Chapter 3, Pantheon, Lullabot, Palantir, all kinds of different things. But in terms of Drupal, nobody owns it other than all of us. So if there's no one to complain to in terms of a vendor, if Drupal's not doing what you want, you need to try and embrace that and say, okay, Drupal's not doing what I want. What part of that can I help push forward myself? We'll talk about some strategies on that. So we're a democracy. We don't really know what we're doing, but we have a lot of fun doing it. So you guys are at your DrupalCon. A lot of you are at your first DrupalCon. The community is pretty amazing. Hopefully that that's come across. I highly encourage you. I try to give this advice to newcomers to DrupalCon. Don't do the thing where you look at all the great sessions going on and you pack your schedule full of a session in every single time slot. You make sure you're always doing stuff. Like purposely leave holes in your schedule and just wander around and talk to people. Because it's amazing, you can just walk past a room and they're talking about some really cool thing that they're working on in Drupal 8. Or you walk by a sponsor booth and they've got some cool project that you're like, well, how did you do that? And you guys can end up talking about it and learning something new. It's really good to not leave here without meeting the community. So go to the parties, take in a buff session or two, go to the core conversations, all of that. So I'm sitting here saying, oh, isn't the DrupalCon awesome? And it's all great and stuff like that. And you're like, yeah, but I'm scared, you know? Well, you know, you're a web chick. Yeah, you're up there and you're saying all this stuff, but you know, you're the Drupal 7 core maintainer and you got on a magazine one time or whatever about that crap. So I get this, I really, really do get this because regardless of where I'm at in my career path, I can tell you a little bit about my background, okay? So my background is this, I am a huge geek, really Angie. I know this was be shocking to you, you know, but I'm a nerd, my first computer was a VIC-20 back when I was like three or four years old and I had those little three to one contact magazines. It was like a little science magazine. They have the programs in the back of the magazine and you like type like 7,000 lines of basic code and then it would make like a little rectangle go boomk and that's it. But you felt like such a total badass who's like oh, I made a computer do something, you know. So that was me, learned programming when I was young. I first installed Linux in 1995. This was back when Debbie and Linux fit on seven floppy disks and I think nowadays it doesn't even fit on seven like three terabyte hard drives. I don't even know how big it is anymore, it's huge. I am fiercely passionate and always have been about free software movement since learning its name. I thought that this was so awesome, you know. All of these really smart individuals all contributing what they know to create tools that are as good or better than proprietary alternatives for free, for people to learn from and extend. I just thought that was the most amazing thing. So I was like that guy or that girl who was sort of in class like hey, you know, if you're gonna teach us about Microsoft crap, you should have to teach us about PHP and MySQL and you know, don't teach us just about Oracle, you know. But of course nowadays Oracle and MySQL is the same thing. But back then it was kind of a different thing. So I was like that person and so I had all these things going for me, right? I was a nerd, I kind of knew how to program. I was like brilliant open source and I was like fiercely passionate, so I was like how many people fit into this mold? Couple of people? And I don't wanna make this sound like you have to code to like work on open source stuff because you don't at all and we'll get into that later. So I had all these things going for me and then you would think, oh good, she's like textbook would be great at contributing to open source. And yet, my first open source contribution was actually not until 2005, which was a decade after my obsession with open source started, okay? So I knew about open source, I installed Linux, I drunk the Kool-Aid, but yet I felt that there was no way for me to cross into that boundary of being someone who actually does stuff in the communities of these things. And actually if it wasn't for Google Summer of Code back in 2005, I think I probably still would be on the sidelines cheering people on because I wouldn't have realized like, oh, anybody, literally anybody can do this. Because what Google Summer of Code did was it sort of poked a tiny hole in that big wall between me and the smart people and it was like, oh okay, well they know that we're students, so I guess they must know we don't know everything yet and so I just tried it to see what would happen and then, and now I'm sort of making up for lost time, so that's why I'm so, ha, I'm not truthful, but. So my goal is essentially to make sure that my story is not anyone else's story ever again. So if you like Drupal and you really think the community kicks ass and you think you wanna get involved with that, but you're scared or you're intimidated or that kind of thing, I'm here to tell you like, you don't have to be, it's not a bad thing, we love you, please get involved. So let's do some Mythbusters. The first myth is what is a contributor, okay? So a lot of people think a contributor is someone like this, right? Kind of big and hairy and hunched over a monitor and has an infusion of caffeine going all the time, you know that kind of thing. Someone like me, yeah, yeah. But no, actually a contributor is not like that. A contributor is basically someone who has three traits. Okay, this is all you need. One, you need the ability to see something and say, well that's dumb. Okay. Two, you have to say I wanna see that dumb thing fixed. And then three, you have to say, I can do something about that, okay? If you only have two of those traits, I see something dumb and I wanna see it fixed, but I can't actually do anything about it or I could do something about it and I see that it's dumb, but I don't actually care about seeing it fixed. Then you don't get to power open source, but if you have all three of those traits, you're one of the people that powers open source. And none of that says you can code. None of it says you're a brilliant PhD mastermind. None of it, it's just three personal traits of being able to observe something, have the desire to see it fixed and then be able to enable yourself to do something about it. So, that's the first myth. The second one is that you have to be this smart to contribute to open source, right? You hear about people like Dries Bytar and you hear people who are like, Blaine is Torvalds and these guys are like PhDs, they have a million years of experience and all this kind of stuff and it's really intimidating, right? Like, you see someone like Dries and he's very smart, he's very articulate, he kind of feels like, well, he's the guy in Drupal, he's scary or whatever, but no, actually, you don't have to be this smart to contribute to open source because the way open source works is it works out this concept called wisdom of the crowds. And it's essentially a bunch of people sort of contributing the little bit that they know and then it all comes together in order to make really awesome things happen. Because I'm a Drupal 7 core maintainer which means it was essentially my job to, my job, my 10 p.m. to 3 a.m. second job that I didn't get paid for, but anyway, that to like go around and take all these contributions from like 1,000 people and figure out how best to incorporate them and that kind of thing. So you have rock stars and people like Larry Garfield and Chicks and Son and all these guys. I've seen all of their code, okay? Let me tell you, it's not that great the first time around, okay? Like it takes a lot of work to get the code to the point where it's like really good and core worthy and stuff like that. And it's all kinds of people that contribute to that process. So a lot of people think that how improvements are made in open source is like this, okay? You have Gina the genius, right? She's standing out there and of course her head is as big as a watermelon because she's a genius, right? Okay, so she's like doing something like, I don't know, something like calculating physics models or I don't know what she does in her spare time and she just thinks to herself she has this brilliant idea, right? It's like, oh, I have this brilliant idea so let me whip out my text editor which obviously is Emacs, right? Okay. And then everyone around her said, I'm a VI person by the way, but you know, but the geniuses, they use Emacs so. We'll have a battle later. There's gonna be a bath where we punch each other. It's gonna be great. Okay. And then everyone around her goes, wow, that's amazing and that's your best work yet, okay? How many people think that is how open source happens? Good, because that is not how open source happens at all. This is how open source happens, okay? So you have a Dweenna the end user, okay? And she's really ticked off, right? Er, because she just hit a bug of some kind. So she goes to the issue queue, issue queue, and she searches first, that's important, but she doesn't find anything and she files a bug report. And she says, oh, I'm angry because such and such a thing happened. If you do nothing else at all, then file a bug report that makes sense to another human being and has steps to reproduce how to do the bug so that people can understand it. That alone is the most amazing contribution to open source. I can't even explain how valuable that is. Because we get so many people coming in saying, like, I have this error. It's like, that, good for you. How did you get that error? What models did you install? What are you using? What is this? So filing a bug report that actually has reproducible steps says, I went to this menu and I clicked this thing and I hit this button and then I got this error. And what I expected to have it happen is this, but what happened instead of this, just basic English skills like that to be able to explain what happened to you, that is an incredibly valuable contribution. So it's one of the end user files a bug report and that might be all she ever does. We might never hear from her again because she goes and uses WordPress now. But the point is she made a bug report and that's awesome. So then Paula, the programmer, comes along. When she found the same bug, she searches the issue and she says, oh, hey, look, there's a bug report about my bug. That's cool. And there's steps to reproduce and she verifies, yep, that's how it goes. So she says, okay, I'm gonna try and fix it because I'm a programmer. I actually can code. So I'm gonna like whip up my thing. She posts a patch and marks it needs review. Okay, then Tatiana, the tester, comes along and she has big Coke bottle glasses, right? She just looks at bugs all day. So she looks at, and she looks at Paula's fix or her proposed fix and she kind of goes, ah, I don't know what's going on there. So, but I'll post some feedback to help you. So she'll say stuff like, well, you know, your coding standards are a bit off and also like you really don't have to do 37,000 SQL queries. There may be one to optimize that a little bit. So she'll kind of review the code and post back and she'll say, okay, I'm gonna mark that needs work now to kind of give a signal back to the programmer that there's a little bit more work for you to do. A lot of people are really scared to do that, right? They're scared to be Tatiana. They're scared to criticize somebody else's work, right? How many people like that sounds like terrifying? Like why would I ever mark Chicks's patch needs work because he will kill me, right? No, here's the thing. The thing that burns people out way more than somebody marking their work needs work is for them to post a patch and if it's sit there it needs review for months. That tells them nobody gives a crap about what I'm doing, like I'm sitting here contributing my heart out and nobody cares. That actually leads to burnout so fast. Having an actual human give a reason to review and say I actually tested this and this is what happened. That is a huge shot in the arm for people and they will go to the ends of the earth to get that thing fixed the proper way but they need people to actually do this work. So in terms of karma level, we have like, I would say contributing code is about here. Contributing documentation is up here. Then there's like Mother Teresa here-ish and then reviewing patches is like so far up I can't even get that high because I'm pretty short so yeah. So please review patches, people would love it. So anyway, Paula says aww, that's great. You posted feedback, that was really good. I'm gonna take two and I'm gonna post another one. Market needs review. And this back and forth and back and forth might happen several times until it gets ready. So she goes to these review. Then we have Wendy the poor soul stuck on Windows XP. Aw, Wendy, yeah. And you know what she says? You know what she says. She says it breaks an IE6. And the only reason she's using XP is because she's in a book author and so she has to use this really old version of Microsoft Word so she also looks at the comments and she says oh, in mind you're spelling. Because you type loose instead of lose or something like that. So then she marks it needs work. Finally, Paula comes back, she says okay, tried this one, last time needs review. Tatiana filters back in and she goes holy crap, that's a lot better. Not only did you address all my feedback but she also fixed up all your spelling mistakes. And it works in IE6. And she marks it reviewed and tested. And then it goes to someone like me or whoever the maintainer of the project is and then they will either incorporate the feedback or they'll have additional things to do. Say about that. By the way, one other really valuable contribution you can make, if you have IE6, that's a huge contribution because none of us do. So please, you know, contribute. All right, so another myth is what qualifies as a contribution. A lot of people think it's this. It's code and an IDE and editor. You have to have a million years experience to do it. All that kind of stuff, no. These are all ways that can qualify as a contribution, okay, so I'll just start listing them off here. Donations, advocacy, talking to your friends about how awesome Drupal is and getting them involved. Documentation, marketing, what's marketing? I have no idea, we're an open source project. How would we know what marketing is? So help us figure it out, that would be great. User support, QA testing, translations, graphic design. We can't design ourselves out of a paper bag, so if you could help us do that, that would be really, really nice. Event coordination, throwing out events like this. Even just holding like a, say, I'm gonna open up my offices in Denver to a bunch of nerds to come fly in and figure out some complicated Drupal thing. That's incredibly valuable. Bug reports, feature requests, issue queue farming. What that means is essentially like going into a module's issue queue and finding duplicate bugs, marking them as duplicate, stuff like making sure that you can actually reproduce a bug, that stuff is incredibly valuable. Usability testing, especially if you access to somebody who doesn't use Drupal and never will. Sitting them in front of Drupal, we can find out all kinds of interesting facts that way. So all of that stuff, and then coding too, okay? So please don't think that just because I don't know how to code, you can't help because you can definitely help. And also, coding is really fun and there's lots of people who would love to help provide you with resources and I get better at that. Another myth is perfection, okay? This is particularly relevant to developers because with open source, I mean, you're putting your stuff out there for everyone to look at, right? Like, oh my God, if I put this patch in the queue, son and web chick and chicks, they're gonna look at it and they're gonna like think I'm stupid if I don't get it right, right? How many people think that? Yeah, a couple of people, a lot of people, yeah, see? I get that. However, I'm gonna tell you a tale of two developers, okay? So on the left, we have sloppy Sam. That's pretty much how my office looks too. And on the right, we have perfectionist Pat who cuts grass with a scissors, okay? And they have kind of two different approaches that they go about fixing a different bug. So both of them will hit the same bug and this is how they'll go about it. So sloppy Sam, step one, she's gonna first search for or post an issue, first thing, you know? Which is great because, you know, if there is an issue out there already for whatever you just hit, it might have a patch attached and your four hour marathon debugging session might end up being like, oh, patch commit done, you know? Which is nice. That's the great thing about a community of like 800,000 people that use Drupal is a lot of times your problems are fixed for you. So first thing she's gonna do is kind of talk to the community and say, hey, I'm having a problem. Then she's going to like talk to other community members, whether that's through IRC, whether that's through Twitter, whatever it is, she's gonna say, I hit this problem. Does anyone else hit this problem? Does anybody have some code about this problem? Whatever that kind of thing. It might get some feedback back, might not, but the point is she's reaching out and providing transparency around what she's doing. She'll post something basic to the issue. It might be completely half-baked, like totally bad idea. So she'll mark it needs work already and just say, well, this is kind of loosely what I'm thinking about. And then she'll reach out to the other community members, incorporate their feedback, and over time we'll eventually get to this point where she's got this really nice patch. She sort of repeats this process over and over again. So that's the sloppy-sam approach. That's the approach that most of the people that you've heard of in the Drupal community do, this. Then there's the perfectionist-pat approach, okay? So when perfectionist-pat hits a bug, the first thing that he's gonna do is he's gonna pull out a debugger and he's gonna sit there and understand every facet of the problem and why it happens and analyze it really well. He's gonna write a solution and that solution is going to be excellent. Like absolutely above par, way better code than sloppy-sam was writing. It's gonna be perfect the first time out. Then he's going to make sure that coding standards, automated tests, all of that stuff is already done because he's perfectionist, right? He's all about all of that stuff as opposed to waiting for other people to tell them what's wrong. And then at the last point he's going to post a solution to the issue queue, okay? So I did all of this work up front and now I have this brilliant solution that's ready to go, okay? So what ends up happening? They both might come up with the same solution, but what happens is because sloppy-sam was out there in the community more than talking to people and providing transparency. Perfectionist Pat, we don't really know who he is. Like we know whenever he shows up he posts awesome stuff. It takes a long time for him to kind of get on the radar of what's going on. Sloppy-sam though, we know who she is. She's in the issue queue everywhere. She's really funny, she's nice, you know? And like she needs a little help here and there but she's learning and she's helping us. So sloppy-sam is actually gonna get the bigger reputation in the community and have like the bigger, you know, sort of like karma points behind her name. Even though she's churning out the same code as Perfectionist Pete because we know her better, you know? The community is all about personal interaction and people and stuff like that. So the moral of this tale is you should fail early, fail often, and fail in public, okay? Because that's how we get to know you. That's how you get to be part of the community. Another myth is they, right? They made Drupal confusing. They don't care about designers or content authors or whoever it is we don't care about this week. But there is no they in our community. There is only us, okay? There is no application process to get on the core development team. It's just people doing stuff. You don't have to get anyone's approval. You don't have to get it asked for permission from anybody. You just go in there, you see something that's wrong and you just like get it done, duocracy. So you, by virtue of sitting in this audience are part of us and you need to really own that and feel empowered by that because there's nobody who's going to tell you what to do. You just get to say I'm gonna do that and you can. And frankly, we need more of us to participate. Guess here are some statistics. I pulled this a couple of years ago, so hopefully it's better now because I've been giving this talk a lot, but we'll see. So this is a sample statistics from the Drupal project. So this is people who downloaded the software, you know, which is this big blue thing that takes up most of the screen. And that's like 99.63% of people download the software and then we never hear from them again. Which is sort of normal. How many people here have filed bugs against like Firefox or Patches or something like that? Couple of people, that's kind of selection bias. You are at an open source conference, probably, but. How many people said screw that, Firefox is stupid, I'm getting crone? Yeah. We have to watch that, right? We have to make triple awesome, but anyway. So then the little tiny red sliver you can barely see, that's 0.32%, that's how many of those people who downloaded Drupal who cared enough to register an account on Drupal.org, cool. Even if that was just to spam us with shoes, you know, at least they cared enough to register an account with us, so that's cool. And then you can't even see this because it's so small, it's people who did something with their Drupal.org account and that's 0.05% of people. They are the ones who actually make Drupal happen. So the thing to take away from that is it's an incredibly small amount of people that do an incredibly large amount of work and those people get burnt out, those people get frustrated and they really, really, really need you to contribute whatever you can to help them out. So let's talk about a couple of strategies on getting started. How many people here have installed Drupal before? Okay, good. Guess what? Here is 53,000 people who can't figure out how to get Drupal installed. Don't you feel better about yourself now? It's like, because if you think about what you need to know to install Drupal, it's like you have to know what a database is. You have to know what FTP or SSH or something is. Maybe you're even super special and you know what Drush is. All of this stuff that you needed to know, you take for granted other people know, they don't and they really need help. So if you know how to install Drupal, look for one support requested day that you can help. Just push it forward a little bit. How many people here know how to use views or organic groups or CCK or any add-on module at all? Just about everybody, awesome. So your task is to make progress on one issue a day. Okay, and I don't say close an issue, right? We talked about that. That's a lot of work. It goes back and forth a lot, but make progress, right? And all that means is that if there's a patch that needs review, review it. And either market RTPC or needs work. If there's a bug report that is new and doesn't have any replies, click on it and see if you can reproduce it. And if you can't, mark it as I can't. I don't know what you're talking about. All that kind of stuff. Because every time one of us does that, that means Earl Miles can work on views. And it's not nice, you know. Let Earl Miles work on views. Let us handle the bug squad stuff and we can all be a lot more effective. Did anyone here have to learn something new when they built their last site? Or do you just like click a button and just turn out the same Drupal site every time? Because that sounds incredibly terrible and heartbreaking. So probably most people had to learn something new at least once in their Drupal career. So if you have to learn something new, document it as you go. Because you have to figure it out anyway, right? You have to figure out how to solve your client's problem, you know, that kind of thing. And that's great. Because if you document it as you go, not only do you leave breadcrumbs for other people to like have them sort of learn how to do it too, that person who learns from your documentation could very well be you in six months. When you like completely forgot everything you ever knew about that. And then you go back and you're like, oh, thanks, past WebChick, that's awesome that there's documentation on how to do that now, yeah. So there's a couple of things you can edit pretty much any page in the handbook. It's basically a Wiki, so you can edit pages, you can add child pages, all that kind of stuff. So if you see documentation that's confusing and you like read the documentation, it makes no sense. Then you go off on your own, you figure it out. And then you're like, oh, well if it had just said X, I would have figured it out faster. Please make it say X. Because the thing about that is I can't do that. You at the point where your documentation is confusing are at the perfect point to fix it because you understand what was confusing about it right now. Because when someone who's been in the community for a long time tries and does that, it doesn't work. Because I'll start talking about hooks and entity API and fields and you're like, what's a module? And we're not even speaking the same language. So when people like me try and write documentation for people who are new, it just doesn't work out. So while you are new, while you are going up the Drupal learning curve, that is the ideal time to actually help out with the documentation team and stuff. And this doesn't have to be crazy. You can actually start with 30 minutes a day. Over lunch, you're munching on your awesome sandwich of some sort. To find something small, you can do. And there's all kinds of candidates for this. But you tell me, yeah, I don't have time. I'm busy, I have a life unlike you, which is fair enough. I have a family, I have a job, I have other things going on at this, this, this, this, this. The thing about that is though, every single person at 0.05% is the same. There's nobody other than a handful of people, actually not even a handful, there's nobody at all who gets paid full time to work on Drupal Core at all. If they work on Drupal Core, it's because something came up for their client or they find it fun and they just don't eat during those hours or whatever it is. So we all collectively, we need to make the time to do this. Because it's for the health of our entire ecosystem, because if these guys all burn out and girls burn out because they don't feel like they're getting enough help, that's actually terrible for Drupal, that's terrible for all of us as human beings. Why should you contribute? Because of kidneys, that's why, no. It's not just because of the more fuzzies, it's because the secret to Drupal's success is to be one of the 0.05% of people. And it doesn't take much to put yourself in that caliber because honestly, if you're doing anything at all, anything at all, you're actually helping move the project forward, it's a huge boost for you. It gives other people more incentive to help you. This isn't an elitism thing by the way, it's simply a time management issue. If I have 13 minutes between now and my next phone call and I look in IRC and there's 30 support questions, but I recognize your name because you were in the core issue queue helping me out, I'm gonna answer your question. Because you help me out, I help you out. It helps you learn faster and it saves you time and money because as you're getting involved in the community, you're going to make a lot of relationships with people, very smart people, very loving people, and you're gonna learn all kinds of stuff. If you're a business, it helps you attract more people, better people to your business. Someone like me, when they're changing jobs, they look for a company that has a commitment to contributing to Drupal, whatever form that takes. It might be like F off Friday afternoons and just work on Drupal Core because you're not gonna get anything done anyway. It might be something like a 5% time. It might be something like once a month they hold a little get together in the office for the local community, whatever it is. We look for that commitment from companies because that shows us you're serious about reinvesting in the platform that I work my ass off on for free for you so you can make money. It's a really good thing to do. It'll help keep your finger on the pulse of Drupal. If you're in IRC or you're in the issues you're going to come across this really awesome stuff way before it's on everyone else's radar. Stuff like Drush, Features, all of these kinds of things. If you're involved in the community you get to find about those things early. And the great thing is that you can have a stronger voice on the project to help set direction. So you can not only know, oh, there's this neat configuration management stuff happening in Drupal 8, but if you get involved you can actually make sure that it actually solves your problems as opposed to the people who worked on its problems. So that's pretty important too. So let's talk about how to be effective. Finding places to jump in is important. There's this Getting Involved section in the handbook which is pretty good. There's also the Community Initiatives page and this is sort of where the community documents stuff that they're working on. So like there's a bunch of people working on accessibility stuff, usability stuff. There's of course the official initiatives, all that kind of thing. These are really good places to look for stuff to work on and furthermore who to talk to about them. If you're new and you don't really know what get and patching and all that kind of stuff is, there's the novice issues. So if you go to your Drupal.org dashboard link on Drupal.org, there's a little block there called contributor links and at the top there's a list of novice issues. You click that and then you've got, and they're a little uneven in how they're graded, but essentially stuff like fix this typo here or make this sort of change the thing here like this in 50 different places or whatever it is. But there's smaller issues, more bite size, easier to wrap your head around, and it's really cool to like pick off one of those because you'll get people to help you sort of learn the ropes and all that kind of stuff. You're also gonna wanna seek out the doers in the community, so we document these in a couple of different ways. One is for Drupal.org we have a file called maintainers.txt, and this is gonna document everyone in the community who like cares about Ajax or cares about the database system or whatever it is that you're interested in. Find those people because they would love to talk to you about things that are on their radar that they don't have time to do. That might be fun and interesting for you to work on and could help you as well and get together. Maintainers on contributed projects, those are the people that are in charge of those, the same deal. In the documentation team, there's Jennifer Hodgdon. She's sort of doing all the coordinating work around that. So there's all kinds of like different structures that we have in different places. But the bottom line is if no one's doing anything in this part of the duocracy, step up. Don't ask permission, don't wait to be told by somebody of blessing to do this thing. If you wanna make your new mission in life to make sure that every comment in every file and core ends in a period, and you're gonna be period guy or girl, do it. That sounds great. You can totally own that and be period guy, girl. Yeah, periods for everyone. But there's nobody who's gonna own that and nobody who's going to find things for you to work on necessarily. So like if you see something that's lacking rather than asking why is no one else doing that, ask yourself what can I do to push that along? Whether that's I can actually write code, whether that's well I could write out how I think it should work, whether that's I can have money, I can pay somebody to look at that, whatever it is. There's many, many different ways. The other big thing is to get on IRC. I know, we party like it's 1981 here, you know. Woo, IRC. IRC for those who don't know, it's a group chatting program, sort of like I am, but for lots of people at once. Chaos in electronic form is essentially what it is. There's pretty much three channels. Pound Drupal is sort of like general chit chat. People sort of ask questions there, kind of get to know each other. Drupal Contribute is where the people who work on Drupal and Drupal Contribute modules and all that kind of stuff sort of hang out. And even if you don't feel ready to contribute yet, this is a great place to hang out and just kind of keep an eye on what's going on. Because man, this is like better than Drupal Planet. You learn all kinds of stuff by sitting around in this channel and seeing what people are working on. And then Drupal Support is for hand holding. So if you're like, I have no idea what views is. People at this conference keep saying views and I have no idea what they're talking about. That's a place to sort of get, is where the patient people hang out that like new people and like questions and talk to them in there. But again, Drupal Contribute, definitely get involved there. Also if you're interested in getting involved in core, you know, giving Dries' stance on like, we need to make Drupal 8 kick ass. If you're like, yeah, I wanna help him make a kick ass, but I have no idea how to do that. Come to core office hours, which should probably be called the core mentoring hours. So we'll get on that later. These are, sorry, it's central time because I'm too stupid to do math. But anyway, so it's basically, there's one at Tuesday nights and Wednesday mornings in North American time. So that we can try and hit all time zones. And this is where Jess, sitting up in front here, XJM. Hello, yay. Jess and then sometimes me, sometimes Tim Plunk and sometimes a few others here. But bottom line is like really involved core contributors are online specifically to answer the stupid questions, which there aren't any. And also to like give you stuff to work on. So if you're like, I'm really interested in like front end development, but I have no idea what is going on in those 13,000 issues in the issue queue, we can help you find something to do. We can help connect you with people that can help you sort of get it on boarded and involved. So this is dedicated time, twice a week, every week, except for this one, because this entire conference is essentially office hours to do that. And actually if this is something that sounds cool to you, Jess is going to be having a day long sprint on core office hours this Friday, correct? Did you want to come up here and say anything about that? Woo, you have two choices. Okay, well I'm gonna go with this one because holding things is awkward. So Friday, hopefully you're still staying in town, there's lots and lots of awesome sprints happening, but mine's the coolest because first of all, we're gonna be working on not the future Drupal for a year and a half from now, but working on Drupal right now. So if there's problems in Drupal 7, people's websites, on your websites, on your friend's websites, we're gonna fix that. And we're going to teach you how. So even if you're not a programmer, even if you've never contributed to core before, or you think that people like Angie are really scary and intimidating and she's famous, which I did, by the way, until last year I came to Drupal Con Chicago and people said, oh, you should come to the core convos and do all this stuff and I was terrified. So if that's you right now, if you're sitting there and thinking there's no way I could ever get involved with Drupal core, I don't even know, I'm just learning how to use views. I will prove you wrong, come this Friday, we'll do a training from 9 a.m. to 10 a.m., and then after that we'll be working all day. So please come. There'll be me and four other people there most of the day, so you'll have a personal mentor who can tell you, we'll help you set up a development environment, we'll help you install Git, and we'll give you issues to work on. You don't have to be a programmer, although if you are, that's awesome. We'll find something that you're interested in for you to work on, so please come. I don't actually know. It'll be in one of these rooms here. Yeah, they will have a list, I think, of where the rooms are by Friday, but I don't think it's actually online yet. It'll be somewhere in the conference center, so. Yes, thank you, Jess. Yes. I actually stay up here for a second. So Jess is one of my all-time favorite humans ever, because what she did is she saw a need, which was that there was all these people who wanted to contribute to Core and didn't realize that they could get involved, and she said, you know what, I bet we could fix this problem, and so she set up this Core office hours thing. Oh, no, no, I didn't, I didn't. Okay, someone else set it up and then dropped the ball. She picked up the ball and then got it actually doing something, and. He dropped the ball because he started maintaining Drupal. I know, I know, I know. We will give him too hard of a time. But seriously, can everybody please give her a huge round of applause, because she's awesome. And now you can be intimidated by her. Awesome, now I'm just kidding. Oh, I just saw Andrea's sitting over here. She's another one of the people who's gonna be mentoring. Yes. Andrea's awesome, and I just actually made a post on Drupal Planet that you should read. If you don't follow Drupal Planet, there's like a block on, you can put it on the bottom of your dashboard on Drupal.org, so I made a post to look for that. She's awesome, and she's seriously like, the reason I'm not burned out and dying right now, because she helped me organize the whole thing so I'm not the only person doing. Andrea, come up here. Yay! She has nothing to say. She says, come on Friday, and we'll tell her. Absolutely, come on Friday. I'd love to see all of you there, it'll be awesome. Yeah. All right, thanks so much, guys. Thank you, girls. Whatever, humans. Yay! All right, that's awesome. Change your plane ticket. You will learn so much, you won't even know how much you're gonna learn, it's gonna be great. All right. At the end of the day, though, when you're contributing in the community and you're getting involved, remember that we're all human, okay? Like I know, Earl Miles sometimes bites people's heads off in the issues, and you think, oh my God, you know, that kind of thing, but we're all human, right? We sometimes have bad days, bored days, sometimes, you know, you've been on a plane for eight weeks and you're kind of cranky, whatever. So we do make mistakes, but on the whole, I've never met a community as awesome as the Drupal community. I mean, the Drupal community is very much all about, you know, if you don't know something, it's not a, you know, it's that black mark on your name, it's not anything like that. It's like, oh, you don't know this awesome thing? Well, let me tell you about this awesome thing, and then we'll both know awesome things, and won't that be awesome? You know, it's really like that, and it's really welcoming, very strong mentorship model in that community. Though occasionally, you will run into an ass hat. And there are a few names that come to mind. So the thing to remember about ass hats when you run into them, and you will, because again, we're all human and some people are German. I'm just kidding. Okay. So, is, you know, the thing about an ass hat is this is really somebody who loves Drupal a lot, is really passionate about Drupal, but doesn't know how to channel that passion into something that's actually effective. And they get really frustrated because they see other people moving in what they feel is the wrong direction and they feel powerless to make it, you know, help. So now that you know all of this stuff, go and find those individuals out. Seek them out and help them. Find constructive ways to channel their passion. And that would be my recommendation. So, where are we going? As I said, I would say something about that. Drupal 8, these are the Drupal 8 initiative leads. For now, they'll probably be initial initiatives announced. All of these people, I want to stress, they are initiative leads. Because I see a lot of people like, you know, Driesel announced the layout initiative and the comments are full of people like, wow, that sounds great. Can't wait to see that. Boy, I wish it was done already. That, that, that, no, okay. These guys are not, and girl, are not going to get this done themselves, okay. And in fact, a couple of them are really frustrated, like, because they're solving problems that we all agree are problems that need to be solved and they have issues out there that need review and they have patches out there that like they wish somebody would work on and nobody's out there. And they're feeling very alone and they're feeling like, what has happening here? I'm trying to fix the things that everybody wants to see fixed and they're feeling like they're not getting enough support. So, if any of those topics sound interesting to you, those are the people to reach out to. And please don't feel intimidated to reach out to them. Please don't feel scared. These people would love to talk to you about how you can help them make Drupal 8 awesome, okay. If none of those topics are interesting, there's also a bunch of other topics. We do a GDO core group is where we announce sort of major things that land after they land and all this kind of stuff. So, if you're interested in keeping on top of stuff, go there. There's also a whole pile of community initiatives, usability, accessibility, unofficial media initiative, unofficial framework initiative, all kinds of stuff for people to work on. And I encourage you to wander around here and find people too. Distros is a big thing. Just like, what, last week or the week before we announced distribution packaging tools on Drupal. Basically all the things that sucked about them before and all these crappy limitations got removed. So, you can do pretty much anything in your Drupal.org distributions that you could do in a regular Drushmake file for people who know what that is. And what this means is that I think, hopefully, we are actually on the verge of an explosion in distributions that are highly targeted Drupal installations towards specific target markets. So, this is something to keep an eye on or something to possibly get involved in if you wanted to always build Drupal for your industry here. We now have the tools to support that on Drupal.org. Speaking of Drupal.org, we're also really working on making Drupal.org awesome. The Drupal Association is going to be making a major investment in Drupal.org development. Going to be porting Drupal.org to Drupal 7, which is going to give us all kinds of new collaboration tools. Going to be sort of helping the community on board and sort of pushing forward initiatives that they want to see. So, if Drupal Core sounds, oh, I don't know about that, Drupal.org is another avenue if you get involved. If you want to help make our collaboration process as much smoother. And then finally, if you're either a business trying to solve this talent pool problem, or you are a developer with way too much stuff to do and not enough time, or you're a student, currently a post-secondary student who really is interested in Drupal and wants to learn more, Google Summer of Code was just announced on Friday. They always do this. They announce it right when we're all on planes and stuff and we're out of here. This is an excellent program, which basically pairs students up with mentors for three months in the summer to get big things done for Drupal. So, if you always had this big plan in mind of I really wanted to create an X for Drupal, but I just don't have time to do it myself, but you do have a few hours a week to help mentor a student on how to do it, it's a great win-win situation because it gets students involved, young people involved in Drupal, it gets your stuff done that you want to see happen and if they work out really well, you can hire them after. But at the end of the day, when you ask like where is Drupal going, essentially it comes down to you tell me, is you're part of this community and I would love to talk to you about where you want to take it, so thank you very much. No idea how much longer I had to talk or anything. 12 minutes, all right. So if you want to ask any questions, go ahead and stand up behind the mic there. You probably have time for a couple of them or you can make me feel really awkward, that works too, you know, stand here. Hey, thank you very much. A couple of them, sounds great. No math though, okay. I've not slept very much lately, so yeah. You got started on Summer of Code. Hey, Jim, how you doing, man? Good, how are you? Good, you got started on Summer of Code, right? I did, yeah. So as you can see, it can work out really well for your career if you go into Summer of Code, yeah. Yeah. I'm just curious if you have some advice for, I've recently found myself behind the corporate firewall and how to convince corporations to allow you to contribute back the stuff you're writing internally. That's a great question. So how do you convince your corporate overlords to let you contribute back your stuff? It's all about legal, basically. What's that, I'm sorry? It's all about the legal department. All about the legal department. So a couple of strategies that work with that, there was one, don't tell them. I don't recommend that strategy, but it's something that you- I like my job, so. Yeah, yeah, yeah. What I would recommend is essentially, and it's to some extent an education process, right? A lot of people, a lot of legal departments, particularly they say GPL, they think viral, they think no to everything. What I try and communicate to them is that, yeah, there's certain circumstances where it doesn't make any sense to contribute the code back. If you are the New York Stock Exchange and you have a module that has all of your special sauce algorithm to figure out how to predict things, of course you don't put that on Drupal.org. That wouldn't make any sense. That would allow the European Stock Exchange to steal all your juice and start, I don't know what stock exchanges do, but whatever they're doing, they're evil. So I would say the thing that I usually approach that with is if the code came from Drupal.org, there is literally no reason I can think of, no valid reason to not contribute any fixes that you do to that back, okay? So that's the first thing, because it came from Drupal.org anyway, so if you end up fixing a bug, you end up adding a little feature or something like that, that should just kind of go back, because it's already GPL, it's already, and you're only going to hurt yourself by keeping fixes to those modules behind a subversion repository that nobody can see. So that's the first thing. The second thing is making it clear like, what's that, I'm sorry? Luckily we have that ability. That ability, okay, awesome, yeah. So the other end of it is like secret sauce, definitely don't. The theme, the custom module with the branding, and then also anything that's like just like a bunch of alters, don't do that either. So communicating that, then that's definitely hands off. The middle ground is where it's kind of interesting. So one example is like Sony, Sony BMG Records funded Lullabot to write the five star module, which is a module that attaches little like five star ratings to things, right? And it's essentially, it has nothing to do with their business, right? It's just like, it's a little add-on type of thing. And so they contributed back to the community. And then Warner Brothers, who's their direct competitor used that module, and they didn't have to write it. But you think like, ooh, that's like, you know, kind of an icky thing. You're helping your competition, you know? But then what happened is Warner Brothers ended up importing that to Drupal 6. And then Sony, when they ported to Drupal 6, just took that and kind of pulled it in. It was like a happy, lovely family for everybody. So, you know, I would try and like, tell stories like that, so kind of analyze the stuff. Because at the end of the day, if your secret sauce is just functionality like that, you're doomed, you know? Because a programmer can bang out functionality in no time at all. What your real value of your site is, is your community, it's your content, it's things that are specific to your actual domain. So I would try to enforce that on them. But it is a process. And I don't know right at the moment of any great resources that's like, print this off and show it to your business thing. There was a post I did on lullabot.com a few years back that sort of talked about this, but I don't actually know. So if anyone in here has experience with dealing with legal departments and having this discussion, it would be great to have you contribute some documentation to drupal.org to help us figure this out. Because we, I would love that one pager that explains this to legal departments and I don't personally know how to write it. So good question, man. Hi. Hi, my name's Ian. Great presentation. We're one of those companies that have a resource problem, but we're not doing glamorous drupal stuff. We just got sites we can't maintain because we don't have enough people. Okay. Does Summer of Code apply to us? Summer of Code isn't like, you don't get students to work on your sites. What you do is you get students to work on the stuff for like the drupal project. So it would help you in the respect that if you were to mentor a student that was doing that, you'd have a professional relationship with that student. As soon as they graduate, you'd be like, wink, you know, sucking them up. It's a little bit of an investment for that kind of thing, though. But in general, getting involved in Summer of Code would mean that you get to learn who a bunch of these students are and maybe reach out to them. So that's one avenue. Another avenue is getting involved in your local community. Because a lot of times there are freelancers or they're contractors that are in between jobs and they'll come to the local user group. So if you're not already going to those, definitely stop by and talk to them. No, I am going, but we're in the New York metro area. Oh no, that's terrible. We're getting crushed. Yeah, New York is tough. We're thinking high school computer classes. If you have a pulse and you live in New York City, please talk to this gentleman. Yes, please. My final question, I just went through one of the whiskey presentation. What do they mean when they talk about bike sheds? Oh, sure. What does bike shed mean? Basically, I can tell a little story there. So bike shed means when someone's building a nuclear reactor, you just gotta trust them to figure that out. It's like, I don't know, you're the rocket scientist or whatever, you just go build your nuclear reactor and that's fine. But when someone is building bike shed, a shed for a bike, suddenly, everybody's got an opinion on what color it should be. Like, oh, you should make it blue or you should make it purple because they can wrap their heads around that. And so bike shedding is essentially shorthand for you guys are dickering over little stupid details that don't matter and you're actually not the people driving the thing, so please buzz off. That's what they mean. Does that help? Absolutely. Okay, cool. And actually, if you go to, I think it's bikeshed.org. Every time you reload the page, it's a different color and it tells the story, so it's cool. Hey. Hey. You're in the forum, so now I get to see you in person. Hey, right on, man. So I've got a question. Let's say I take everything you say to heart. I take all your tips and at the end of the day, I still end up in needs review purgatory. What would be my next step? Good question. So I listen to WebChick and I drink the Kool-Aid and I try and take all of her steps and I still end up in needs review purgatory, meaning like I'm one of those poor suckers that has a patch sitting out there without a Tatiana the tester to take care of it. Yeah, that's a great question. My recommendation would be a couple of things. One is communicate about it, you know? Tweet it, blog it, go into IRC, talk about it, that kind of stuff. That's one avenue because you might reach somebody else who's like, oh, that's cool. I want to see that happen too. The second one is sort of, I call it patch bartering. It's like you scratch my back, I scratch yours kind of deal, where if you come in IRC, you say, hey, I have this patch that needs review. Does anybody else have a patch that needs review? And you trade, which is really interesting because you will end up getting exposed to weird random parts of Drupal you never would think you would get exposed to. And I guarantee you it's so weird. This has to be every time. Every time I do this, I like, you know, look at this weird part of code that you've never seen before. And I'm like, I can't think of a possible reason to ever have to know that, but that's interesting. And then two weeks later, I'm gonna come up with something and it's like, oh my God, I just did that two weeks ago on the core queue, it's amazing. It happens every time. So that's the second strategy is actually going into IRC and Drupal contribute and actually not only saying, I want somebody to review my patch, but also offering to review and return because people usually jump all over that. And then the third strategy would be come to core office hours. Was there be people there that want stuff to work on and you could be like, I got something for you to work on. Hey, hey, you know. So I would say a combination of those three things. But generally it's like, don't be perfectionist Pete, be sloppy, Sam, be out there in the community, be visible, be communicating with people. That's the best way to get eyeballs on yourself. Makes sense? Cool. And nice to meet you. Hi. Hi, I'm a software developer and I've worked for a long time with a different content management system whose open source community is somewhat less vibrant than the Drupal community. And I think I've been a little bit scarred by the asshattery of that community. Yes. And so I'm now sort of making a gradual transition to the Drupal world. I have some skills that apply and some that don't. So what do you think is good for a person in my situation? For your situation, are you a developer or? Yes. Oh, awesome. Then what I would recommend as a first step is like, if there's anything of those, so you're saying you're a developer, you're coming from another CMS and you don't know Drupal too well yet. Was your eager to learn and you wanna get involved? I've been to the module development training, done a little of this and a little of that. I do PHP and SQL, but I'm not fully up to speed with Drupalisms. Okay, awesome. I would say like, I would probably, if I were in your situation, I'd start with a couple of novice issues just to kind of get your feet wet, you know? Please don't do more than a couple of novice issues, by the way, because we wanna leave lots of them for other people. But yeah, start with a couple of those just to kind of get the patching process down, kind of see how the community works and that kind of thing. And then if I were you and you already are skilled at development, I think you're probably best rode in or be a look at the Drupal 8 initiatives and see if there's something in there that's interesting to you. Were you at the web services initiative talk for the configuration management? Does any of that float your boat, or is there anything particularly you're interested in? I'd say I'm good at importing and exporting data, moving things from among disparate systems. Wow, importing and exporting data. Okay, well we need that, so that's awesome. So maybe web services, maybe also touching base with like say the migrate module maintainers that do a lot of that kind of stuff for the feeds module maintainers and just saying, hey, you know, I'm new to Drupal-ish and I wanna like get my skills up and what do you need to help with? And it's amazing, like if you approach people in that way and you say like, I would love to help you but I don't really know how, you take these guys and they will charge $400 an hour for a client project. They will sit there with you for 18 hours and like explain to you painstakingly, step by step, did, did, did, did, did, and they'll help mentor you and all this kind of stuff because again, we are so starved for people to help us that a lot of times that's the way to do it. So what I would recommend in your situation then, if your work doesn't really overlap with too many of the core initiatives other than there is an issue open for like changing our upgrade process to use a migrate type deal instead. So most Weizmann would be a good person to talk to but in general, find those contributed projects that overlap with your interest and see if you can get involved there because then that would be like the most straightforward way to take your skillset to what is happening and then it would also allow you to apply the skills today in Drupal-7 with an eye towards Drupal-8 and helping with the future. And that's kind of general advice for anybody, you know. If you have development skills, you're interested in one particular area, look for the people, again, like look for the maintainers of those modules, look for the people maintainers.tex, reach out to them and ask them how you can help them. So, does that help? All right, thank you. Just one quick time check. Am I done? I'm done. I'm sorry, but please come up and I'd be happy to talk to you after. So, thanks everybody. Oh, and there's a survey thing. Oh, and don't forget to get a free book.