 We're going to get started, guys, because I think we're supposed to start five minutes ago. So here, welcome to Drupal South Melbourne, 2015. I'm here to talk to you about contributing to core. When I proposed this session, I saw it as a bit of a niche thing, and I envisioned it in a small theatre, like the little back rooms that we had at DrupalCon Sydney, you know, a handful of people. And so I was a little bit taken aback to be on this in the bigger room. So let's see if we can make this work. Yeah, so we're talking about contributing to core, and it's basically a summary of things that I've kind of picked up as I've gone through the core process. I was told by someone that I should make my first slide a bit of a who slide. So here it is. Yeah, so I've been doing Drupal since 2007 or 2008, I'm not sure, because as I'll tell you later, I didn't sign up for a user account when I started. And yeah, as Angie said in the previous session of Top 20, contributed to Drupal 8. And my main motivation for getting involved in core was that I took a car trip between Bundaberg and Rockhampton, which is about 300 Ks, and I was a passenger, and in that time I read what was required to upgrade to Drupal 6 modules to Drupal 7, and after that three hour car ride, I still hadn't finished reading it, and I thought it's not enough just to be a contrib developer and not worry about what's going on core, I just need to see what's happening as it happens and kind of get my kept track of what's going. So I'll work for previous next based out of Sydney. I maintain four modules in core now, contact, comment, forum, and the new module that Angie mentioned before, the block content, which is kind of like makes blocks do fieldable stuff. I'm also part of the security team, and yeah, I've been kind of around about Drupal in Australia, yeah, probably since 2008 I guess is where I got involved heavily. So this is kind of where it all starts with Drupal. If you want to get involved in contributing, the first thing you've got to do is register, and as I said before, I didn't register when I first started using Drupal, I had built two sites and I didn't have a user account. I didn't even, couldn't see the point, but the first time I signed up for a user account was when I had a patch to post. I worked on the GMAP module, which if anyone remembers was the go to mapping solution in Drupal 5, and I added some functionality to make it so you could use image fields in balloons on your marker. Now, in hindsight, the patch was hard coded to use particular fields, and it wasn't the best thing, but I still wanted to share what I'd built, and I signed up for a user account. And now, knowing what I know now, if I had have known then, I would have signed up as soon as I first got to the site, because the longer you've had your account on Drupal.org, it's like a credibility thing. So if you don't have an account on Drupal.org now, and you're here today, this is your first point of call, get an account. And so when people talk about what Drupal is, they'll describe it as three things, and I think Angie may have said this recently on a podcast with Cal Evans, that it's a content management system, and it's a content modeling framework, and it's also a kick-ass community. And so if you're not sort of actively involved in community, you're missing out on 33% of the community. And from my point of view, I was based in Bundaberg, which is obviously the mecca of Drupal, right? And it wasn't even in Bundaberg. I was 15K outside Bundaberg, and I had a side heart in three acres of paperback swamp, and I worked on stuff in isolation. And I didn't know there was this thing called community. And there was a service provider's page on the groups.drupal.org AU site, and I contacted Simon Hobbs and said, can I get an account on there? And he said, yeah, do you ever go on IRC? And I was, what's IRC? Well, if you don't know what IRC is, IRC is your window to the Drupal community. It doesn't matter how isolated you are. It doesn't matter where you are. If you can get onto IRC, then you can be part of a Drupal community, even if you're out on your own in the middle of a forest in a side hut. And so this is what I can't stress hard enough or can't press on the most is to get involved in IRC. And we have experts waiting for your call. It's kind of the way it is, right? You can see there's 286 users online at this time. I took this screenshot, and that's just in one channel. We have channels for everything. So this is where you say hi. So I'm sending some homework for you. If you haven't used IRC before, your homework for today is to get into Drupal AU and come and say hi to me. My username is LA Rowland. I want you to say hi to me. I want you to make that contact in the IRC channels and get involved in our community. And that's what I said. If you're not, you're kind of missing out on that third of the thing. If you're working on Drupal projects and you're like, what is this hook menu or what is that? And you think you're on your own, you're not. There is this vast community of people out there who are all too willing to take your call and help you out. And then when you've decided that you want to contribute something back, Drupal contribute is the place to go. And so that's more about I want to do this, what can I do? Or if I'm working on this patch, what can I do? So we have a great page on drupal.org, drupal.org slash IRC. You can't forget that. And that's got how to get contact, what clients you can set up. You can name your platform, there's a client. And even if you don't have something in store, you can still get in by the web client. But yeah, as I said, that's your homework. If you haven't been on IRC before, get on IRC. It feels like some technology from the Dark Ages. And but it is, you know, a thriving hub of activity. And that's where you go to, you know, the critical office hours that we run on Friday at noon. They all happen in IRC, you know. Okay, so getting involved in call, the first thing you need to work on is negotiating issue queues. And the first step is to watch an issue. Now, as I said to you guys before, I made that conscious decision that I wanted to be involved in Drupal 8, so I didn't get left behind when things changed. And in hindsight, it was a good decision because the changes from 6 to 7 were nothing compared to the changes from 7 to 8. And the first step to do that is once you've signed in, you can hit this follow button on any issue. And that doesn't, there's no obligation. You can hit follow and that's it. And that's just like that first step of getting involved is to follow. Then you can go to the, into the, let's see if this works, yeah, it does. You can go into this little link, email notifications, and then you can say send me an email for issues you follow. And so that's when the issue that you're following has had some changes, someone comments, you get an email telling you what's going on. And so once you've got that going, you can just observe. And I did this for probably six months. I just stood back and watched the interactions between core developers, learned the characters, learned the names, you know, saw the process. And look, in hindsight, I probably could have gone into IRC and said, hey, what's this? How does it work? But, you know, the observation was key. And absorb the way things worked. And I was kind of fairly passive in core. I had one patch in Drupal 7, and that was from a bug that I found in 7.0 for a site that I was building, and I needed it to fix a site. And you said it can be a long process. It was a long process, and I thought it was exhaustive at the time. But in hindsight, I looked back at it as a great learning experience. So yeah, it's to just absorb. And the input is for me to actually get involved was kind of finding my niche. And so there was a post by Daniel Cudwin, his username is son, that said, make core maintainable. And essentially it said, Drupal 7 is giant, massive pile of spaghetti. And if we can't get people to help us maintain it, then we should rip stuff out. And so it was cry for help, I thought, from core developers. And I was making a living from Drupal. And I thought, well, you know, if the bedrock that my livelihood is built on is in this state where these people are frustrated and there's too much work and et cetera, this is kind of like a call to action for me. And so if you want to find your niche, first one thing you could do is you could scratch your niche. So, you know, if you're interested in a particular thing, we've got issues for everything. I think the Drupal core mentoring sites slogan is we have issues, you know, and we do. If you're interested in CSS, if you're interested in documentation, if you care how many spaces come before or after a bracket in the if statement, you know, we've got everything you could possibly want to work on. If you want to help mentor people, if you want, yeah, there's a niche. And if you want to scratch niche, that's one way to find it. But one thing that commonly motivates people is to find something that annoys you. So that block content module that I talked about before, that's in Drupal 8 that lets you field blocks and have block types like you do with a node. I hate working with blocks in Drupal 7. I hate the fieldable panel panes being none of them are deployable, et cetera. So out of frustration in my day job, that was my driving factor for that module. You know, I hated that when I deployed a block that was placed, it was done by a serial ID and while it was block ID 4 on my side, when I deployed it, 4 was already gone and it was block 6 and nothing worked anymore, you know? So, you know, that was the motivation behind the design of that. You know, it's done with UUIDs. It's done in a deployable manner. Yeah, so find something that annoys you and, you know, out of that, you can make your day job easier. Like, it's the fact that you're gone probably working with Drupal for another five years or maybe longer, maybe even longer again. So if there's something that frustrates you in your day job, that's a great niche. So find something you care about. Like I said before, you might be a pedante, you can, you know, you care about CSS selectors and you want to work on that. Go for it. Find something no one cares about. This is my in, right? They were going to drop modules from core and they said, unless someone steps up to maintain form, it's gone. I said, I'll do it. And I remember CHX posted on the issue, there was this guy on IRC who said he's going to look after forum model. You know, what an idiot, you know? And, but I'd been in this Contrib land, I'd been in this land of, you know, the wild, wild west of Contrib where people commit stuff without even an issue, you know? And I went and had a look at the issue queue for forum. There was only 100 issues. And like, if you've come from Contrib, like, if you're looking after a module, you know that like 100 issues isn't that many. And I was like, yeah, I can do this. I'm going to do this. This is a great way to get involved in core. And forum was one of the first modules ready for Drupal 8. We haven't had anything to do for forum for quite a while. We had some issues with CMI, you know, interactivity. But, yeah, like, getting forum module ready for Drupal 8 taught me a lot about Drupal 8. We refactored a lot of things. We got rid of a lot of the crazy stuff. There was stuff in Drupal, there is stuff in Drupal 7 where forum module directly accesses the global post variable. It doesn't use form state. Forum was the redhead stepchild of core. And now it's kind of like modern our way of practices. We have a forum manager service. If you don't like how forum does anything, you can swap that whole service out. And so, you know, that forum was the no one cared and that was my in. And from there, you know, forum was ready, but it relied on comment and comment had some issues. And so I thought, well, I ported forum module to CMI. How hard could comment module be? If you want to see how hard it was, have a look at issue. And I know the number, 731-724. 1010 comments later across three issues. I had to clear some space on my hard drive because I had over 25 megaworth of patch files for that one issue. I re-rolled it for 18 months, but you can have a comment on any field now. Now, in hindsight, I got advice from son, don't try and do it all in one step. And I said, I can do it in one step. And it probably would have been, you know, better served waiting for it. But, you know, I learned a lot and I got there. So, yeah, find something no one cares about. Just find something. And if you can't find something, we can help you find something. But once you've found that something, you can use the issue queue search. So if you've not seen it, I'm assuming everyone's seen the issue queue search functionality.drupal.org. And there's an advanced search button and you can filter and, you know, get it down to that. You can find that niche list of issues that you care about. And then you can hit this button, this subscribe with RSS button and stick that into your RSS feeder. And so, yeah, I subscribe to the RSS feed for all Drupal 8 issues. That was my, okay, I'm not letting Drupal 8 run away on me like Drupal 7 did. I'm gonna follow every issue. And, you know, I don't care about that next. I don't care about that next. But when something comes in and you go, oh, yeah, I care about that. On my phone, I hit follow, you know what I mean? And so that way I'm engaged in that issue. A lot of those issues I follow, I don't do anything at all for. I just watch what happens and see. But if something comes along and I think, I don't agree with that or I think we could do this better, you know, then I get involved. Or if there's something like, hey, that's fun, I wanna do that. Then I get involved. So yeah, we have great tools for this. But there are some limitations. And you have to find what works for you. And I use Gmail labels, right? So this is, I have a folder in Gmail and every email that comes from Drupal.org goes into this folder on its own. It stays out of my inbox. So it's not interrupting me. I don't think, oh no, I've got 150, 100 messages in my inbox. I can read them when I feel like it. And I tag them because we can tag stuff on Drupal.org but those are global tags. And no one cares that I think, you know, that this issue here is a quick fix. And so if I've got 25 minutes spare, I can work on that. So I use these Gmail tags. And I have a lot of them. I have, you know, how about this one, Meaty? You know? That's the stuff I've got three hours to burn and I wanna do something that's pretty involved, you know? And so there is some work involved in keeping these tags up to date. I even have a needs triage of my labels. But yeah. And like this is how I keep track of where things work. But so you need to find the tools that work for you. Some people use Trello boards. You can set up into automation to have, if this, then that automatically create, you know, things on your Trello board. There's some new ContribCanban.org website where you can put in the name of a project that you're tracking and it'll give you a Kanban board. So there are tools. And I know that Angie has talked before about having a system where you can have this Google spreadsheet that automatically keeps up to date with the issues that you follow. And so, you know, at with time, we'll probably get more sophisticated about this, but I find this works for me. And this is the big one, Git and Patch workflows. Drupal is one of the few remaining projects left that still use patches, okay? And there's good reason for this and I'm not gonna get this into a flame war about we should use Git or we should use pull request, et cetera. We use patches, that's the way it is. And I'll talk a little bit later about one aspect of that that is really advantageous to Drupal. But just because we use patches doesn't mean we can't use the power of Git. So it's pretty simple. My solution, it's not a solution. It's not even revolutionary. It's just one branch per issue. So this is about six months old, but I have 157 Drupal 8 branches on my local. Because Git is distributed, you can do whatever you like on your local repo. You can commit, you can, whatever you like. Because only Angie, Dries, Alex, and Nathaniel and Jennifer can actually push to core. So you do what you like on your repo because when you have one branch per issue, everything becomes a lot easier. So you can commit your patch locally. So this is me working on issue number. You see, I give the branches a name so I can remember them because no one knows the number. But I also put the number on because it's a bit of a reference. But that wasn't patch seven. I did a new patch and I did some fixes. That was common 18, 19. I did a merge, et cetera, et cetera. You know, everything comes a lot easier when you start committing your patches locally because if you want to do an interdiff, because everything you previously committed is committed, Git diff becomes an interdiff. Now what an interdiff is for those who don't know is the way you start reviewers from stabbing you because if you put up a 150 kilobyte patch up and they say, can you change this? And you go, sure. And you put up a 150 kilobyte patch, they have to review the whole thing again from scratch to make sure you did actually change that. Whereas an interdiff is the difference between your previous patch and the next patch. So if they've reviewed the 150 kilobyte patch and asked you to change some comments here and that, and that's where you change, if you put up an interdiff, they can just eyeball that smaller file and not the 150 kilobits. And we have some people who do a lot of reviewing. Gibran's down the front here. He's probably reviewed, what, how many issues would you review if you're reviewing in thousands? Thousands, yeah. And so I'm sure that if you say to him, yeah, interdiff or no interdiff, he would like burn you with eyes, his laser eyes will, yeah, yeah. But so if you wanna do a re-roll, you can fetch the origin and you can merge. And there's a lot of things that patches won't apply on drip.org because patch, the way that we apply the patches isn't as sophisticated as a merge. So more often than not a re-roll, git fetch origin, git merge, git will be smart enough to merge it and then you can generate a new patch with git diff origin 8.0x into some file. So, yeah, it's a lot, everything is a lot simpler when you have one branch per issue. And you can even do stuff like fetch a patch for someone else's written and apply it straight to git. Yeah, so I'll get talking about this a little bit more later in terms of automation, but yeah, the fact is that if you have one branch per issue, things get a lot easier. Now this is kind of the elf in the room. There are some politics and personalities involved in core shock horror, okay? The fact is there are some big egos and as most of you are from Australia, it's not always a problem. We're pretty, you know, we have the tall poppy syndrome. So most people in Australia are pretty, you know, they're critically aware of ego, you know? Ego is a dirty word. And so, but that's not always the case for other countries. And so there are some times where people are like, you know, your patch is rubbish. I am supreme leader, you know? And that's the way, look, you have to allow for cultural differences, but you also have to say that some people are very highly invested in this. And so, you know, for some people, this may have been, you know, their life. They've done this for a long time. And so the stakes are high. Or for some people, this might be a critical part of their livelihood because their business relies on it. And so, you know, there are some high stakes, but my advice would be to sleep on it, you know? So if you do find that happens, you know? Sure, write your reply, you know, saying, what do you feel like saying at the time? But sleep on it and put in your response the next morning, you know? Some people work in long hours or the end of the day. And if you, you know, just do that knee-jerk reaction, you could do a lot more damage than you, than just, you know, having to sleep on it and changing your mind. And I'm not, don't want to call you energy, but there was an issue where, for that common issue, like towards the end of the 18 months, there was like a just 7-3-1, 7-2-4. Towards the end of it, there was a decision that we don't really want to do this. And look, and I was kind of, oh, okay, I've been re-rolling this for 18 months, I couldn't be doing other things. And I wrote a reply and then I slept on it. And in the morning, I still felt the same way, so I wrote it. But I thought about it in the time and what I basically thought was, why did I get involved in CORE? Well, I got involved in CORE to learn how Drupalate worked and why did I learn through those 18 months? Well, I touched every subsystem in those 18 months. I touched the entity system, the case system, you name it. So at the end of the day, it sounds mental, but after those 18 months, if that happened again, I really didn't mind because I'd fulfilled my goal of learning what Drupalate was. And so if you've got something you want to, if there is a heated discussion or an argument or something, just take a step back and sleep on it. And then the next morning, in the light of day, you might feel differently about it. This is one that the Drupal community working group will tell you about, is don't get drawn into the Cabman drama triangle. Now, there is a name for this. It's a psychological or like triangle that they have. There's three roles in the Cabman drama triangle. There's the aggressor, there's the victim and there's the rescuer. And every person in that triangle is paying part in like the game. So if you might think you're doing the right thing by coming to someone's rescue, who's being abused by someone else, but you're actually being part of that triangle. So if they're, you know, don't jump to someone's defense and say, oh, don't do this, but don't be the victim and don't be the aggressor either. And there are people that will play all three of those roles, sometimes in the same issue. And I think it's good to take a step back and recognize that, okay, that's one of those three roles and I don't wanna be part of one of those three roles. And this is why we have a working group. And some people know what this slide's about, right? Yeah, sometimes people are just jerks. And yeah, we have processes to work through this. We have the code of conduct. We have the community working group. So if you see something like this in an issue queue or a comment on Drupal.org, don't stay silent. Go through the proper procedure, go through the proper process and don't get drawn into the triangle. And ask questions when unsure because real-time communication is greater than issue queue. So if someone says something to you in an issue queue or something about your patch, and let's remember it's your patch, not your child or not your partner, it's code, right? The end of the day. If someone says something, get in on IRC and talk to them in real-time. And you can more than often not solve the issue without name calling and, you know, et cetera. But when things do go wrong and that doesn't cover a solution, we'll call out inappropriate behavior by going through the process, the code of conduct, the working group. Don't forget language barriers. Yeah, well, there's... Yes, exactly. Yep, 100%. And that's, I've got this as a slide. This is an important, and, yeah, I can't stress that enough. One of the co-maintainers of... A lot of the co-maintainers of core English is their second language. And so what you may take offence at, because it may come across as direct, was probably lost in translation. So, you know, don't forget language barriers. And that's where, you know, real-time communication or even someone who's more proficient in two languages can mediate for you, you know? And this is one I can't stress enough. Switch off. As I said, at the end of the day, it's just code. It's just, you know, something you do for a hobby or a job. It's not life and death, you know? I was talking recently to another core contributor who co-maintains the modules with me, and he was in a country on holidays at the time, and there was a large camp going on, and he was planning to go. And I said, how did it go? And he said, oh, look, in the end, I didn't go and I spent the weekend with my wife, you know? And that is important for the health of Drupal in the long term, because if your world is Drupal and you live in Drupal and you live in sleep Drupal and you don't do anything else, but you have nothing outside that, you can sometimes lose, I guess, the keel or the balance or the, you know, so, yeah, switch off if you hit those issues. And don't sweat details. And that's just the straightened way of doing things. So we've already got an advantage here, right? She'll be right, mate, you know? But, Andy talked before about if you put stuff up, sometimes no one reviews it, and that's one of the most frustrating things. And I would agree, it is frustrating, but if you patch it, they will come. And what will come, well, reviewers will come, commit credits will come, crudos will come. It all takes time, you know? You might work on an issue and not do anything on it. And the thing is that you put your patch up. It's not that you saw it through to completion and you didn't sleep for three months and you hassled people continuously until it was done. That's not what you should be focused on, you should focus on. All right, there's my patch. Off you go, go fly, you know what I mean? You can put it out into the wild. Don't be tied to, okay, I'm not doing anything until this patch gets in, you know? So, there's a good post I'll come back to later, but review trades is one way to help get those reviews. So if you've got an issue that you care about and you've written a patch for and it's stored, go on to IRC and say, hey, who wants to trade? Because there's guaranteed someone else in the same boat as you who's written a patch and they want someone to review it. You can build upgrade rapport with people by helping them review their patch advice first. And this is one that, when I brought this up, we talked about this internally at work and I've said that a broken patch is better than none and this was a bit of a surprise to some people who thought that they had to make their patch perfect to the nth detail before they put it up. They're afraid of being judged and I would say that a broken patch is better than none. Right? Because the fact is, it doesn't matter how good you are, there is, this is the strength of open source, it's like the collaborative knowledge of a massive group of people and there might be something that you don't know that someone else does and so until you put your code up to get feedback, you don't know what things you may have missed and so a broken patch is better than none and so if you've been working on something for a long time and you think, I just want to get it right, I just want to get it right, by the time you get it right, someone else might have, it might have been fixed and so there's an article by Angie here called A Tale of Two Developers, sloppy Sam, perfectionist Pat. I'm the sloppy Sam, I'll work on something, I'll go, hey, what do you reckon? Stick it up and someone will go, you're mental or that's wrong or fix that or what is this and you fix it and through that process, you learn from that person, you learn, they share their knowledge with you. If you work on it in isolation as perfectionist Pat, by the time you've got to posting the patch, it might already be fixed, by the time you've got to posting your patch, some other subsystem might have come along so it sounds bad but this is the preferred approach, is the sloppy Sam approach because from that you benefit from the collective knowledge of the community. So yeah, patch early, patch often I guess would be there. Yeah. So learning through reviews, I don't have a computer science background, I have an engineering degree and I have a mathematics degree and programming was a hobby from when I was grade five through the basic typing out a whole game and hitting run and then it's a syntax error and starting again. So programming was always a hobby, all of my lectives at uni I took programming in and I'm eternally grateful for Druful because when I moved states, I had trouble finding work and my wife didn't so I spent time as the home dad, doing all that sort of stuff and in my spare time I continued tinkering with things and that led into employment and that led into, opened so many opportunities for me. So through the process of working on core I would say that I've improved my development knowledge and skills tenfold at least. Even the first issue that I worked on, I had to fix for it and I put it up and it was knocked back because it needed tests and I didn't know what tests were. So I went away and I learned and people helped me and out of that process I learned automated tests and so now I use that in my day job and that means the code that I write is high quality and I sleep better at night. So core is vast, right? And so this is something that can be daunting for people and they think they need to know everything and you cannot know everything in core. You cannot, okay? There are people who've been working in core for 15 years and they don't know that the strength of core is made up of individual people being specialists in this particular subsystem and collectively we form Voltron super developer, right? So you have to, you know, if you can acknowledge that straight up and people openly do this in the issue queue and I think by people who have established reputation doing that in the issue queue totally lowers the barrier for new people coming along. So if we have this aura that core developers know everything and they are awesome and don't ask them questions because they are delicate geniuses, like the barriers are there, right? But if you see a core developer say, I don't know how that works or why is that or something, I think that as a newcomer seeing that, you go, hey, they're just like you and I, you know? But reviewers teach as they review. So someone will review your patch if you do the sloppy sand approach, you put it up. Someone will review and say, hey, did you know about this or you should consider using that. And so out of that, you learn something and you learn something out of every review other than say coding standards and stuff. And, but the reviewers learn as they go as well. So for example, if you review other people's code, you might see something that you weren't familiar with or you didn't know about in the past and that's how you build your knowledge and expertise as well. And you explore a new area as a reviewer. So even if you don't feel like contributing to core or with patches and you don't have the time, just reading other people's code will make you a better developer because you will see things that you were not aware of. So you can learn new techniques as a reviewer and you can basically get a free CS education. And I like to say that I've got my computer science education in the Drupal issue queues. I know about dependence injection. I know design patterns and I've learned all of those through the issue queue. I think that you cannot underestimate how important that is for the development of Drupal in the future because it means there is no barrier to entry. If you come along and you're willing and you're able, you can learn the rest from there. But there's flow and benefits. You can build networks and friendships. So when you want to go and talk about an issue, the first thing you want to know is who handles it. So you might have a patch for the entity field system and you think that this is the bee's knees and you need to know who you should speak to. And so you need to know that first before you can go off and collaborate with someone on it. So the first thing you should do is look in maintainers.txt. So this is the text file that ships in Drupal that tells you who's in charge of subsystems and modules. So you might ask an RC. It's your window to the Drupal community. So if you get on RC and you ask in Drupal, hey, who knows about the cache API or who's in charge of the cache API? There will be people standing by for your call and say, yeah, it's so-and-so. And you can ask the bot in the room if they're not online, when they were last online, and you can even leave a message for them. And yeah, I think that by interacting with these experts in each of these areas, you build new networks and say, well, I was talking in the forward just before about some people planning some work on Drupal 8 and they talked about some functionality that they needed. And so I happen to know that there's people working on that on the other side of the world for a similar reason. And so why should we have two people reinventing the wheel? We should collaborate. And so if you can build these networks through contributing to call, it will help you in your day job. It will help you with what you're trying to achieve. And you can build karma. I think that karma can't be under-a-threaded in open source. If you go into the Drupal Contribute channel and you ask a support question and no one knows who you are because you haven't been actively... You know, people don't know who you are because they haven't seen your name around or they haven't... They don't know what your contributions are. You're likely to be told, I'll go and ask that in Drupal Support. You know, this is about contributing. But if you have built karma and you have a question about a Contrib project and you know the maintainer and you ask them in Drupal Contribute, they're like, oh, yeah, I know you. I really appreciate the work that you did. I don't mind answering your support questions or helping you out. And the value of karma in the community cannot be underestimated. I think it's not tangible, but it does have a value. And you can build respect. I think through the way that you conduct yourself in the issue queues and on IRC, you can build respect from your peers in the community. You can build comrades. And I chose the word comrades there because you are working towards a collective goal and you can also build friends. And I'd like to say, you know, for example, Jim Brown again, we'd not met until last night. We have worked together for probably 18 months on call. And so, I mean, I had to asleep because we just had so much to talk about. Because, you know, I think that you can't value those kind of friendships that you can build through that. So I think I've got some time left. I want to talk a little bit about automating your processes with Fing. Nick had proposed a session for here called, if you liked it, then you should have put Fing on it. And Fing is a build tool for PHP, like Ant is for Java. And basically, that we have a fairly solid set of build steps in this particular repo that this is a VD8 is a vagrant image for Drupalite development. It's not the one that we'll be using on Saturday in the code sprint because really, we don't want everyone cloning giant VMs over the conference network. But if you go back, it's worth looking at because it's part of the Drupalite process. A lot of the time, we change the data structure and you have to reinstall your site. Now, if you want to do that with drives, like Drush, SI, and then I've got to pass in the URL, the database, and kind of put a password in it. Like, who can remember that, right? Fing reinstalled, done. Forget about it. To run a simple test test from the command line, it's sudo user bin PHP minus www data. You know, like, this is just Fing simple test class. The day that you've been added that to that, my life changed. Yeah, so automation is better in memory stuff and the same goes with git aliases, right? The stuff I showed you before about, you know, git diff into a file, I just have a git intitiff command. And so I work on something, git intitiff, and I know that there'll be an intitiff file in my folder ready to upload to www.drupalite.org. Merge adex, that's a reroll for me. Git gen patch number. So say I'm working on comment 34 and I've made some changes and I've committed them to my local branch because that's what I do. Type git gen patch three. Based on my branch number, branch name, it'll generate me a patch file and put the dot three in the name of it. So, you know, a lot of those things you can automate and fetch patch is my favorite. So say you want to work on someone else's issue, you know, stuff they've done. You get the URL to their patch file and you do git fetch patch URL and it brings it down and commits it to theirs and you're ready to go. Commits it to your local branch and you're ready to go. So these are up. There's some aliases you can get from and just add them to your git alias file and then you can benefit from that. I talked about automated tests before and I just don't, I just want to say that there is some scariness around automated tests if you've not used them before. Particularly simple test is a bit of an unknown. It's kind of a dribble-ism but it is worth learning how to write automated tests. You become a better developer and if you're not using automated tests, I think that you should really, as a developer, invest the time to learn them because you can transfer the skills you learned to your day job that you're doing call and you can sleep easier at night. So yeah, I've got some resources here. I think I had another slide but I don't know where it went. Bear with me. It's not there. Must have taken it out. Yeah, so the resources. This is a blog post by Gabor Hoisey about managing your own issues. So it talks about what I said before. Some people use Trail-O, some people use, you know, some good resources there. The Drupal code of conduct is for when things go bad and hopefully you don't need that, but it may be. Burnout, I didn't really talk about but I did talk about switching off and I did talk about taking a step back. So that's there. And there's a thing there about automated tests but yeah, any questions? I think we've got five minutes left. So I'll see you at the sprint. Yeah. We've just got a little something. Oh, thank you very much. Time. Thank you. Yeah. Do what you say and I'll tell you how that's in. Whoa. Hi, I'm Angie. A lot of people come up to me at sprints and stuff like our before sprints and they kind of have this, we would call it imposter syndrome. As far as where it's like, they feel like they look at people like you and all that you've managed to accomplish and they sort of put people like you on a big pedestal and think that they could never be that good and they don't know programming as well as other people or they're not really a developer or various other types of things like that. What would you say to people in that boat who feel like they really love Drupal, they depend on Drupal for a living, they love the idea of contributing but they just don't think they've got it in them to do something. That's a good question. Yeah, I mean, I think first of all that it's false, you know, isn't there like a thou shalt not worse false idols type thing? Yeah, that definitely applies. And I think that I was also in that boat, I saw like Cora's this, you know, world garden of brilliance type stuff. And like that, as I said, that call for help issue that I originally got involved in kind of broke down some of those barriers. So I saw that, hey, you know, I can help here, you know, I can help. And the fact is that there's many layers that which you can contribute on. And this was a lot focused on code, but, you know, we have jobs for everyone, I guess, in the community. And if you meet and talk to these people in IRC and you realize that they're just the same as you and I, they're just normal people. They're not, you know, I mean, there's always this, I still have this level of people that I call like mad geniuses that are just their intelligence is off the charts, right? But there's under the skin, they're still the same people as you and I with the same, you know, idiosyncrasies and issues. But yeah, I would say the first step is to just say hi, you know, like no one's kind of, I don't know of anyone in the community who's this is the beauty of our community. There's, I don't know if there's anyone who would be so arrogant as to not, you know, appreciate someone saying hi to them. And I want to talk about their story and what they've done in Drupal and yeah. And come along to the sprints are a great way to get involved but if you're like myself, when you are like based in a remote area where there isn't a thriving community on a regular basis. Yeah, IRC is that, is that, is the answer to that. You know, I was working in isolation on stuff and tear my hair out, you know, Drupal 6 and having that resource just to, even just to rob a duck stuff off is like the invaluable. Is that answer to the question? Or is that just like more rambling? I've got a little bit to say on that question as well. Yeah. As Andrew will know. Because there was an issue that we have a connection on. I think it's really true that if you've got some motivation it's the persistence that makes it happen, not your ability. Yes, absolutely. And then my other question was how do you deal with time zone differences because. Well, that was the slide I was looking for. Now where did that go? I must have missed, you know how when you build your markdown slides you've got to put those two lines in. That's what's saying about times of difference before and also about why patchwork flows are so much better. So thank you. We are sometimes called down here the magic fairies in the night, all right? Because, you know, folks in the Northern Hemisphere or the, what's called the Western Hemisphere, they'll work on something and they'll go to bed and they'll wake up in the morning and we've kicked it along a little bit more. Now, if we were using pull requests couldn't necessarily do that without having open access and five different forks just for the one issue. But with the patch based workflow, someone can put up the work, you know, I'm going to bed, this is as far as I got it and they go to sleep and they wake up in the next morning and the patch fairies have resolved it, you know? And it's the converse is true as well because that same happens for us. If we put up a patch and the next morning we come back it's done. But yeah, the times of differences are difficult. I find that I get most of my email in the night and most of the Twitter feed stuff in the night because, you know, but I think that there's always a bit of an overlap. So the North American folks overlap with our morning and the European folks have, well, the night hours in Europe overlap with our morning and the people who work normal hours sort of overlap with our evening. So there is a time if you need to meet someone that you can organise in advance, most of the communication is done through the issue queues or with IRC tells. And so if you do use IRC don't know what a tell is then say hi on IRC and I'll tell you what it is. And if you don't use IRC, well your homework is to get on IRC and say hi. And then I can show you what a tell is, but a tell is basically letting the robot pass on a message for you. And yeah, it's invaluable. Yeah. How do you say hi IRC? All right. Come to the sprints on Friday. It's Saturday, Saturday. That's one of the community tools. That's part of the community tools. I'm not online, so hang on a minute. But have we got time? No one is kicking me out till we've done this. How much time? If you want to go and have coffee. If you want to have coffee, go and have coffee. I'm totally happy with that. But if you want to stick around for saying hi on IRC. So I use Addium as my client. There's like Lime Chat. And if you're still lucky enough to be able to use a Linux based system you can use Pigeon. And I think there's a Pigeon for Windows, XChat. There's a FreeNode web client. I probably would have to connect to the Wi-Fi. What was that password again? DSM 2015, exclamation. Web Chat. Right. Am I online? I'm online. Thanks everyone for coming too.