 everyone, thanks for coming. As Josh said, our session is called From Them to Us, Demystifying Drupal Contribution. I'll just give you a quick overview. So Lee and I are going to each talk a little bit about how we started contributing and then how we ended up joining the Committer team. I'm going to go through a little bit about who contributes to Drupal. Lee's going to talk about how you can get started on your contribution journey or if you've already started how to progress it. And then we hope you have some questions at the end. My name is Pam. I'm the CTO of Technocrat, which is a remote Drupal agency primarily based in Australia. And I'm also currently the core Committer team facilitator, which means I help with meetings, release notes, and other coordination tasks. I've been contributing to Drupal since 2012. And my first core patch was in 2013. And it was actually also the first Drupal core issue that I created. So I think I probably nervously followed all the instructions. And I created an issue for this visual regression that I saw. There was just a text contrast issue with the shortcut links. And up to that point, I had been involved in going to meetups. And I had been to many conferences and had done a little bit of organizing. But I hadn't ever really made a Drupal.org contribution. So I created the ticket. And I thought that was the end. I was very proud of myself. And then Mike Gifford, who is a longtime Drupal well-known contributor. He's the accessibility maintainer, replied to my issue saying, yeah, it looks great. Can you roll a patch? And I thought, oh, hadn't planned on rolling a patch. But I know how to write CSS. So I'll give it a go. And I think probably with a lot of encouragement and assistance from Lee, who I was working with at the time. So I'd never actually done a patch at all in Drupal let alone anywhere. So I had a go. In the end, I actually created four patches because there were a few problems. So for one thing, I didn't know about right to left styles. So I had to redo it for that. And there was just some general feedback about CSS in core. Not only did I learn a bit about that, but I also learned that there was no such thing as a simple CSS patch in core. And then within a month, this issue was committed by Angie. And I found this comment. Just to be really super encouraging, this whole experience was really positive for me. Because not only did I start off thinking my contribution was minor, and I was going to create the issue, in the end, I actually fixed the issue. And this really felt like a transition to me. I felt really welcome. And it really made me feel like part of the community. So even from Mike, who didn't know me, had no idea who I was, just to say, hey, can you roll a patch? That was a huge motivation for me, because I think otherwise I probably would have been too shy or too nervous. But he didn't know who I was. He said, all right, yeah, can you write a patch? And I was like, yeah, OK, sure. So my path from that first patch to joining the Committer team was kind of long and winding, which you'll see later at least is a bit more sort of linear. I started attending Sydney Meetups in late 2011 and connected with agencies. I started working at Previousnext in 2012, which encouraged me to contribute. And they funded a lot of that contribution. I attended a lot of conferences, did some conference organizing, spoke at conferences, and attended Drupal cons in the US and Europe as well, which was great, because I met a lot of contributors from around the world. And that was a really important part of the contribution journey for me, because not only did I make connections that kind of maintained over the years, but just kind of became someone who was known in the community for volunteering. So I did contribution sprint mentoring. I helped organize a Drupal camp in New York City. All these different kinds of things led me to meet people and pursue opportunities that I wouldn't have otherwise had. I took some time off from working in general. And then when I came back, I started getting back into Drupal. And at the same time, they were looking for a Committer Team Facilitator, which was a new role that they were kind of trialing. And they invited me to join. Just to quick note, as well, we're looking for more facilitators. We would love to have more than one, but so far, we've been sort of unsuccessful in recruiting. So then just since 2019, I've been doing the core Committer Facilitator. And then I've also gotten involved in the Bug Smash Initiative, which I'll talk a little bit about. And one thing I'll talk about later, one thing I just want to highlight as well is that most of my contributions to date are not coding. So where Lee's path is very much centered around development and coding, mine is pretty much on the edges of that. So now I'm just going to hand over to Lee to talk about his journey. Hi, everyone. So yeah, I'm Lee Rollins. You can find me as LA Rollins on most places on the internet. And my current role in the project is core Framework Manager. And my first core patch was to do with theming. So as you would know, you get a page that was tpl.php in the day. And for every pattern in the path, it would make a new theme suggestion, so page dash dash node. And it was broken if your path had a hyphen in it. And so that was my first patch. And it was the same sort of experience as Pam. A lot of encouragement from people. I had to write a test to go with it, never written a test. And the community sort of encouraged me to do that. And my contribution path actually came to Drupal from UberCart. I had an account on the UberCart site for 15 weeks before I joined the Drupal site. And my journey into contribution was through UberCart. So I was the maintainer of the UC hotel module. Anyone ever use that? That was one. I was expecting that to be zero. Yeah, so back in the day, if you were able to commit to any module, then you could create any modules that you liked. And it was much easier to get involved at that point. So I started adding more modules, and most of them was to do with UberCart. And then I started to drift towards the core issue queue, mostly as a lurker to start with. So I would follow a lot of issues and sort of watch the dynamics between contributors. And it did seem to me like this far off sphere that I was outside the bubble. I wasn't part of that. And they were kind of like, I thought there was an elite group of developers, for example. So I started contributing a few fixes for Drupal 7, things like the one I saw before. And one day I saw an issue, which was a call to action, which was make core maintainable. So this QR code is the link to the issue. But it was effectively a cry for help from Drupal Core developers at the time. Drupal 7 had just come out. There were thousands of bugs. There were modules that had kind of been added to core and no one was supporting them, like shortcut overlay toolbar, if anyone remembers any of these modules. And so I thought, well, I use Drupal. I kind of know what I'm doing. And it's part of my income source. So I'll go and put my hand up. And this is a blog post from Chicks, who's a longtime Drupal contributor, wrote the form API. He said, yesterday I saw this guy on IRC. He said, he'd look after the forum module. And so I opened an issue for it. And again, Angie was the person to commit that. Awesome. It was a very, very welcoming experience. And I think the thing to note here is that I wasn't asked to do this. There was no, you must pass these five tests to be admitted type thing. It was like, thank you. We'd love to help welcome aboard. So I think, as with Pam said before, that it's a very welcoming experience. And the impression that I had originally that was this wall garden was completely, completely wrong. So from that point, I got involved in a lot of Drupal 8 initiatives. I learned a lot along the way. And I kept writing patches. For 2 and 1 half years, I did one patch a day just to try and help get Drupal 8 out. That was the sort of thing I started. And I learned a lot. And fast forward six years, I got an email from Dries and said, hey, would you like to be a core main committer? And obviously the first, my first reaction was very much imposter syndrome. I didn't think that I was up to that, but I thought I'd be mad to say no to that. And so I was brought on as a provisional committer, which meant you can only commit to the unreleased branch. So for example, that would be 10.2 in the current site. And yeah, that was very welcome again. And after 12 months, I was promoted to a full committer. Yeah, so I think I'm gonna pass back to Pam now. So there are two reasons that I really wanted to do this session. The first is just to show how it all happens. So as Lee said, he just did a lot. He volunteered for stuff. And then eventually he got an email from Dries inviting him to be a core committer. And the second reason was just to gently nudge the conversation around core development and the release cycle away from the mentality that Lee alluded to earlier of there's this group of they that the core developers who are separate to me, I have no link to them whatsoever. They're making decisions that I don't understand and just kind of scoffing. You say things like, oh yeah, of course that bug's been open for 10 years, it's Drupal. There's no docs. The docs are terrible in Drupal, or that's probably not gonna happen because it's Drupal. And I'd really just like to reframe the thinking around this. Because really Drupal is just the output of a very large group of people who are mostly volunteering their time. So it's really good I think to keep this in mind when you're making generalizations or complaining about stuff. If you are here, you are a user of Drupal and so you are a part of the us in some way or another. There's a blog post that Jess, one of the core committers wrote about this which is linked in the QR code there. Just about the thing that you're complaining about or the thing that you're criticizing. Someone probably spent a lot of time on that. So just some things to think about. And just quickly going through kind of who the people are that contribute, there are sort of different types. So there are contributors, which is just anybody, pretty much anybody who participates in an issue. So creating it, testing it, triaging, writing a patch, whatever it is, there are thousands of these in any given year. I think upwards of nearly 4,000 people contributed to Drupal 8. There's no gate for this one, so anyone can do it. All you have to do is create a Drupal.org account and again, create an issue, comment on an issue, whatever it is. Then there are maintainers and there are a few dozen of these, probably less than 100. These are people who've put their hand up to oversee a particular part of core or a subsystem and they're generally a subject matter expert. So as Lee said before, he did that for the forum module originally. That's how he kind of made a jump in his contribution. They review issues. They make decisions about these subsystems but they ultimately, they don't commit. So the committers are then the sort of last group which are, there are about 18 on the core committer team now and they have right access to the code and they're the sort of final gatekeepers. So most of them are unpaid, at least partially. So some of them are paid full-time, some of them are paid part-time, but a lot of the time that they do is volunteer and Lee's company does provide a contribution time but I know that a lot of the time that he does spend is in his own time, he's not getting paid for that. And also most of the things that these guys end up doing is review, which is not that much fun and I think in many cases they wish they were able to write more code but that's sort of the thankless job of a committer. And I also just want to say to kind of call out as I mentioned, Lee's company, Previousnextus, pay for some of his time. They also fund another core committer, Vicky Spagnolo, who's quietoneondruple.org and other companies like Acquia that are actually spending money on this and it's really important, I think, to call that out because I don't think that the Drupal release cycle would be what it is as reliable and as robust as it is without those companies paying for it. So just some quick stats from Drupal 8. 3,750 contributors. So there's a big group of contributors. I mean, that's actually a drop in the bucket when you think about how many people are using Drupal so that number actually seems small to me now in hindsight. And then 270 of those people worked on more than 20 issues so that's 7% of which Lee and I are in that group and then 128 worked on more than 50 and that would be certainly 3% inclusively but I don't think me. So yeah, I mean, we consider ourselves part of the us for sure, we contribute in different ways and our contributions vary greatly depending on what's happening in our lives so as I said, I took a year off from work in general where I did absolutely nothing and then I came back and I was like, hey, I'm back, what can I do? And that's totally fine, you know, there's nobody that's gonna be sending you an email saying, oh, what's going on? You know, your commit rate has dropped. You know, you don't have someone breathing down your neck because there is definitely a very, very healthy respect for the fact that you're volunteering your time so there's really no sort of set expectation. And I also just wanna call out that there actually is a lot that one person can do so just really quickly an initiative is kind of a, it's just a loose term that we use to describe like a targeted attempt to achieve some goal whether it's adding a new system and core or a new feature or the one that Lee proposed back in 2020 about three years ago, Lee proposed this initiative called Bug Smash which was really just an attempt to get the number of open bugs in Drupal core down from what it was which was very, very high. So he noticed that in the list of patches for core and his composer files was just getting longer and longer and you know, every time there's a re-roll you have to update your build scale and all that kind of stuff. So he just thought there's gotta be a better way and he also figured that bugs are easier to review because they're quite clear and contained whereas a feature could go round and round and round and the scope is kind of unclear. Bugs are kind of a little bit more concise. So Lee started that, it was genuinely just a, hey guys, I've got this idea, does anybody object? And of course everybody thought it was a great idea and now three years later these stats I think speak for themselves. So 809 issues are actually fixed because of the Bug Smash initiative and more than 3,000 worked, more than 3,000 closed. So that could be closed because their duplicates are closed because they were outdated and then almost 6,000 issues worked on and we've got for 541 people in our Slack channel. The other one then is the needs review queue initiative which was started by Steven Musgrave just back in November and he had this idea because he found that the needs review queue was had more than 2,700 issues in it and as somebody who was frequently contributing he felt like his issues were just kind of getting lost in the wash. So he said, there's gotta be something we can do to make this a little bit more manageable and he pretty much single-handedly has made this happen. So other people are helping and there has been definitely participation it's nowhere near the scale of the Bug Smash kind of community but amazingly they've touched almost 2,000 issues. They've fixed 419 and there are currently as of an hour ago only 22 issues Mark's needs review in the Drupal core queue which is down from 2,700. Yeah, in three months, yeah. So why not you? If you're feeling like you're in the camp of like, no that's them, not me, then this next part is for you just to kind of get maybe a place to start. So I'll hand you back to Lee for that. Thanks Pam. So as Pam mentioned before with her contribution journey it all starts with an issue. This is the QR code to the issue queue and the next time you think, well that's annoying or why doesn't this feature exist? Think about how you can help or what you can do to help move that forward. So first of all would be to go to this issue queue and search to see if someone else has had the same problem and if they have then maybe follow it up or follow along, make a comment or see what the next steps are and see if you can help any of those. A lot of the issues will be stuck on needs review or stuck on needs manual testing or it's things that for all different skill sets it's not just development. And so if an issue doesn't exist you could create one or it just could be a simple issue to improve some documentation. You might have found something that was really difficult to understand and then you worked out and you think the docs could be improved. And if you're not sure, ask in Slack. There's nearly 600 people in the Australian New Zealand Slack channel. Through this conference you probably get some faces to go to the names and you feel comfortable messaging people in there. And as I said before I was a bit of a lurker and so chime in when you feel comfortable. 90% of the issue discourse is fairly civil and there's little risk of drama as long as you're polite and you follow the process and be respectful. But I think one of the big issues is knowing who to ask and hopefully out of come to this session you now know at least two people you can know to ask and we may not know the answer but we might know who to ask so we're happy to help direct you towards the people that might have a better answer than us. Core is very large and we're not gonna pretend to say we know everything about it but there are people who know their specific subsystems. And then we also have a separate issue queue for the ideas queue and that's where big ticket items so more blue sky thinking goes in there and we kind of agree to work on that before people start committing resources to it. So before you do get involved I encourage you to try and think about why you want to contribute. We spoke about our motivation. Maybe you want to learn. Maybe you want to improve your reputation or your profile in the community. Maybe you want to network or friendship. Maybe you want to ensure Drupal's livelihood or maybe you just want to fix something interest to you in terms of why should you contribute. We've got a lot out of it. For me I learned a lot of PHP so when I started contributing to Drupal 8 I had no idea what a namespace was or what an interface was or what a unit test was and I learned all that stuff through putting up patches and getting people who knew more than me to review that provide constructive feedback. I also then started reviewing other people's patches and you read someone else's code and you look at something that you've not seen before and you take that as a jumping up point to learn some more. Pam, do you want to talk about multilingual stuff? Yeah, well, obviously being in Australia we don't have much opportunity to build multilingual sites but we actually recently had a requirement on a project and I was able to completely build a multilingual site from scratch with almost no sort of assistance because I'd done so many issue triages of multilingual issues. So that's purely, you open an issue it's got steps to reproduce you go through the steps to reproduce and from that alone I learned how to build multilingual sites so yeah, definitely there's huge value in it besides just the gratification of giving back. I think one of the other sort of non tangible benefits is the karma that you get in the community. If you've earned karma from contribution and people recognize your username and you have, let's say a specific issue in a module that you know the maintainer on Slack and you can message them and ask for help. Even if it's specific help to your project you're probably gonna get more traction if you've built some of that karma than you would if you just went to a support channel and asked off the blue, out of the blue, sorry. And again, your networking and friendship there's a really large community of really smart people all around the world building this and we can also say build a lot of connections with people out of it. And so that's the why but how about the how? And I think one of the easiest ways to get started is just to get into a habit. I try to do certain things on certain days because as Pam mentioned, there's a lot of reviewing so I try to do that on a Monday and Tuesday and then maybe on Wednesday I work on Contrude projects and Thursday I might work on some patches and Friday I might work on security team stuff but I like to keep a routine. Pam, she likes to use triage sometimes for a change of scenery or distraction so it might be just finish the client call and need something to reset, might go into the bug smash and get a random issue to triage and that kind of is a nice change of scenery. Yeah, I think if you put in that small investment regularly it won't happen overnight but it does happen as said before at asking learning. So you should check egos at the door and do not be afraid to ask questions. So this is from two months ago. I introduced myself as the core framework manager but there was a patch from someone about Postgres and I didn't understand what that was. I didn't have any knowledge of Postgres having used it for 15 years. So here I quite clearly ask can you explain to me what it's doing? And this is Daffy who's one of the subsystem maintainers for the database system. More than happily explains that to me and I go away from that issue having learned something. So if you're unsure or uncomfortable just ask but most people in the issue you're willing to politely explain their patch or the issue to you if you ask politely. I also encourage you to find your niche. There's something that interests you or something you have expertise in or something you care about or in my case forum something no one cared about. Find something that annoys you in a job like if something frustrates you every day for me getting involved with the block content module was born out of frustration with have to write update books in Drupal 7 to deploy blocks. Bug special needs review the same thing Steven's motivation was no one was reviewing his patches and there was 2700 things to review it's very hard for someone to find that. And then a fun thing is to to work in initiative to help find your feet faster. We talked about bugs bash don't need to review but there's a lot of community initiatives when you're working in a team it's much easier to see traction because you've got multiple people working towards the same thing. Building a contribution culture in your organization Pam mentioned before about previous next if you're a business owner or a leader here or your senior in your company you can try to build this culture of contribution and start with celebrating things internally previous next when someone gets something committed we all have a message and say congratulations and make a big deal out of it come from the smallest thing for a first patch to a big sub system like changes to the revision API that got into Drupal 10.1 this just gives visibility internally in the company and sort of communicates that it's something that is important and valuable. Fun time for it if you can and interclerated into your client beads so let's say you responding to an RFQ and there's a feature in it that you know doesn't exist but it's a patch for it or it's 80% along and when you go for that big include time to try and get that across the line you might not get it across the line but you might move it forward and the next company that comes along might get it across the line and talk openly with your clients about it a lot of our clients are happy to support open source contribution a lot of them have their own project other own profile page on Drupal.org that lists their contributions and they're very proud of those so yeah just don't think that it's a okay there's no solution let's not bother and then one final thing Yeah I just want to also throw this out there because I think that a lot of organizations think well we don't have time we don't have the resources we don't even have devs that actually can contribute patches to Drupal if your team is not able to do that you can definitely find someone who is and you can pay them to do it on your behalf so we had a situation years ago where a client wanted a feature in web form that was not built and you know we had developers that were more than capable of doing it but felt that they probably weren't the best people to do it in order to roll it back into web form module so we reached out to the maintainer of Drupal 7 web form and we offered him some money to build the feature that we wanted and he did it and the feature went into the web form module the client got what they wanted the you know Dan got paid and now that feature was available for everybody to use so I really just want to make that option very clear there's no sort of official channel for this to happen but there are plenty of developers out there who would love to get paid for their contributions so I do think that you know as much as we're talking about you know contributing to core and talking about volunteering there is no expectation that anyone in the world just should volunteer their time for free and I don't want that to be your takeaway I'm I certainly am making a living off of this I suspect that the rest of you are too all of most if not all of you and so there is money out there circulating and if there's something that's really annoying you if there's a bug you on fixer if there's a feature it's definitely an option to pay to have that so that's our sort of final note and I mean the fact that you're here we hope you have some interest in joining us if you're you know if you were just looking for a push we hope that this helped and as Lee said now at least you know who we are and if you have any questions or now or later you know we're on Slack all the time and and yeah we're around so