 Hello everyone. My name is Tim Lennon. I'm the CTO of the Drupal Association and Hestanet on Drupal.org. I'm here today to talk to you about contributing to Drupal. Contribution is the foundation of open source. Open source depends on that spirit of collaboration across individuals and across organizations. Instead of all building individual solutions, we can build one bigger and better solution together that creates new opportunities for everybody involved. So let's talk about the types of contributions that you can participate in in the Drupal community. They fall into two broad categories, code and non-code contribution. Both are important. Code contribution includes writing new integrations for Drupal, new modules, new themes, updating existing projects by fixing bugs, adding new features, writing tests, contributing to Drupal Core. Non-code contribution can include updating documentation, organizing events, mentoring other contributors, or writing promotional materials for Drupal. All of these are important to the Drupal project, and all of them can create credit and reputation in the community for both you and your company. So let's talk about the basics first. To start, you're going to need a Drupal.org account. You can get this from Drupal.org slash user slash register, and either a trusted colleague who already has an account or another contributor can then confirm your account so you can get to work. When you create that account, make sure to add your company. As long as your organization has a profile, you can add that to the work section of your user account. You can put in your title, the organization you work for, and mark it as your current organization. This is important. You'll need this if you want to attribute your work to that company so they get credit for sponsoring your time. One thing I do want to say is about the company's responsibility. If your company is asking you to contribute to Drupal as part of your job, it is their responsibility to provide you with materials on making meaningful contribution, and all the training and contribution support that you might need. So they should provide you with materials and they can work with me to help develop those materials if you need something. At the same time, the Drupal Association and the community is happy to help. You can reach out to myself at the Drupal Association or to people in the Drupal community on Drupal.org or on Slack at any time. You don't have to learn this all by yourself. Let's talk about working in issues where most of the contributions happen today. So the issues for any given project, whether it's core or a contributed module or a theme are linked to in the sidebar of that project. Before working on these issues, it's really important to read and understand the issue etiquette documentation. You can go to Drupal.org slash issue etiquette, and these guidelines will make sure that you are making meaningful contributions, and that maintainers don't think that what you're doing is just spam. One of the most useful things that you'll find on this page is an example of a constructive review. So there's lots of things that you can do in an issue as part of the contribution. You can directly do work, or you can review other people's work. One of the most useful parts of this particular page is an example of what a constructive supportive review looks like. Perhaps even more important than the etiquette though, is understanding the guidelines for what is a creditable contribution and what is not. So Drupal.org has a core credit policy that was written by the core maintainers and explains the guidelines for a contribution that will usually receive credit and one that usually won't. They don't use this language, but I'd like to say that these guidelines help demonstrate the difference between a superficial contribution and a meaningful contribution that really moves the issue forward. So on that core credit policy page, you'll find two really useful sections. Examples of what receives credit and examples of what does not. These examples can be very specific. So they'll tell you things like, hey, you're not going to receive credit for simply re-rolling a patch or for giving a plus one to an issue without explaining exactly what you did to test that issue or just a screenshot that doesn't really illustrate the change. So you can use this as a guideline to see, is my contribution in depth enough to receive credit on this issue? It's really important. If you don't read anything else, if you don't remember anything else, remember this page and the guidance that's here. So here are those two sections and the direct links to those sections. Bookmark these, read them a few times. They're going to be your best friend as you get working on your first contributions. So how do you get started? What are the first issues that you can do? One thing I highly recommend is starting with a novice task. So these are tasks that have been tagged by contributors or maintainers as being good tasks for a first contribution. That usually means the technical scope is well understood, the changes will be easy to review and accept when they're complete. And so it gives you a good, complete experience of the contribution process. Don't be put off by the fact that they're called novice tasks. If you're an experienced developer, they're still a good choice for you, even if you have 10 years of druple experience to get used to what the contribution process is like. You might also want to contribute into contrib projects. In fact, it might be easier for you to work on a module or a theme or something like that. I think one of the most important recommendations that I have is that your first contribution on a contrib project should be to an existing issue in that project. Now, why do I say that? Almost every project on druple.org has plenty of issues open already, dozens, hundreds, possibly a thousand or more issues open. And so the maintainers of those projects and the previous contributors have things they really want to get done, things they want to do. So if you come in and help complete one of those existing open issues, that'll make a big difference in your credibility and in your reputation with that maintainer and those contributors. On the other hand, if you come in, open a brand new issue, close it right away and then disappear again, it won't build a great relationship with the maintainers or contributors. And that leads us to our next point, which is that you need to be collaborative. You need to work together with everybody who's working on an issue. This random example had 10 followers on the issue. So there's possibly as many as 10 people who might be working back and forth on this solution. This is where that etiquette page can come in handy in helping you understand how to communicate among that kind of group. As you go through a contribution, follow along with the existing contributions that are on that issue. So folks might be working in a patch, they might be working in a merger quest, some issues might have both. You have to read through the issue to understand which one is the most active work. And you should try and follow along with the way the people in that issue are working. So if they're working in a merger quest, you should keep working in the merger quest. If you're proposing a completely new solution, you could open a new branch in a new merger quest. If they're working in patches, you might wanna keep working in patches. You can switch to an MR convert a patch to a merger quest, but you shouldn't do that unless you're also going to contribute a significant change. So just converting a patch to an MR is not necessarily valuable, but doing that so that you can make the patch better so that you can then solve another part of the problem. That's a great reason to convert it, but don't convert it without any other changes. The most important thing perhaps is respecting maintainer and contributor feedback. There are other people in the community who want to help you, but when they post suggestions or tell you, hey, this other kind of patch would have been better or this is a better solution, it's important that you acknowledge that feedback. And the next time you work on a similar issue, you follow those guidelines. If you don't follow that feedback, or if you repetitively do the same thing without showing that you're seeing the feedback that's being given, maintainers might think that you're just spamming the issue to harvest credit and that you're not really trying to advance the project, not really trying to contribute. If that happens, you might find yourself getting marked as a spammer or you might risk getting temporarily banned on Drupal.org. So respect that maintainer feedback, show that you understand what they're saying and follow their suggestions to improve the work that you're contributing. Of course, as you're doing your work, you want to attribute that work to the employer who sponsors you. You can do that with this checkbox on the comment form of the issue page and you could also attribute work to a customer or client. So again, if you had to make improvements to a module or bug fixes as part of a client project, contributing those back is really great. It helps make that project better for the next user and by showing which customer you did it for, you show a future customer, hey, you did something important, powerful and useful and you gave it back and maybe they want to work with you on the next project. Another important thing to know is that it's the maintainer or maintainers of a project that ultimately grant credit. So this sort of table will appear at the bottom of every issue and a maintainer will check or uncheck these boxes to decide which contributors to the issue actually made a difference in moving the issue forward. Now, if you have followed the core credit guidelines, if you followed the issue etiquette, you are much more likely to actually receive credit for the work. There's also a variety of tools for contributing that might be useful to you in your journey. So let's talk about a few of those. First of all, Drupal.org uses GitLab for all of the code repositories and GitLab has a web IDE built in where you can make simple code changes, make it commits and open merge requests without having to set up a local development environment or use the command line. And these merge requests can be reviewed by maintainers and accepted and all of that. Again, make sure that the work you're doing is consistent with any other work that might already being done on that issue. There's another tool called Drupalpod, which is a browser extension built by the Drupal community that spins up a Gitpod developer environment with all the tools you need to do really quite serious and robust contributions. Here's an example of what that looks like. It has some guidelines for contributing. It has a terminal. It has a browser showing a preview of the work. It lets you browse the Git tree, all the things that you might need without ever setting up local development tools. On core issues, there's also a live preview generated by Tugboat on core merge requests. So usually that will let you see the changes. And this often saves us from having to take screenshots or do other complicated things to test issues because we can just take a look at the preview. Similarly, there's a tool called simply test.me or simply test me, which was created by the community and allows you to quickly test what a particular module or project looks like with a particular version of Drupal. Just kind of creates a sandbox. You might not use this directly for contribution but it helps you evaluate whether an existing project does what you're looking for. So let's talk about some specific do's and don'ts. These come again from the Drupal.org core credit policy which I think is the best place to really look for this sort of material. So do learn those standards. Do read those pages. Understand the examples of contributions that get credit and the ones that don't. Really internalize that and it'll help you on your contribution journey. Do contribute back the work that you did for a client. I've talked about this several times. As long as you have permission to share that code back and perhaps to attribute the contribution to them, it's a great way to build reputation, relationships and make a meaningful contribution. Do look for novice or beginner friendly issue tags that will help you find issues that are a good entry point into your contribution journey. Do focus on issues that are already open, especially when it's your first contribution to a new project. If that project already has issues open, solving something that is already there will help build your reputation with the maintainer. And then if you have additional issues to open yourself, it'll give you some cred and credibility as you wanna move forward. It's also really valuable to participate in contribution events. So Drupal.org slash community events, lists, camps, meetups, Drupal cons, all sorts of contribution opportunities that you can participate in. And many of these opportunities will have some form of mentored contribution or at least informal contribution. And getting to sit one-on-one with someone who can help you learn how to contribute is really the best way to advance your contribution skills. You should also not underestimate the value of updating documentation. There are a lot of issues tagged with documentation or needs documentation. And if you have strong technical writing skills, you can make a good contribution here. Whether that ultimately results in docs on Drupal.org or inline documentation within the code base itself. Now here's a really important don't. Don't use automation, bots, bulk updates, these sorts of things. We don't want to use human power on things that a bot could do that we could script. So if a contribution could be done by automation, it probably won't receive credit. So this will include patch re-rolls, rebasing of merge requests, file name changes, a lot of things like that. Now what you can do instead is you could submit a feature request to us at the DA and we might be able to fix that in bulk. And if we do, you will get credited for that contribution. And we've done that a couple of times before. Don't just re-roll patches that already exist. So something you might not realize is a patch will often still apply even if a new version of Drupal has come out. If that section of the code hasn't really changed. So most patches don't need a re-roll automatically just cause there's a new version of Drupal. Now, if they don't apply anymore and they do need to be re-rolled, it's important that you create an interdiff which is a text file that shows the difference between the old and the new patch. And that documents the changes you made to make the patch work and shows demonstrates the work that you needed to do and why the patch was necessary. I'll also add that patches won't be on Drupal.org forever. So it's not a great idea to invest most of your time here cause we'll be moving to all merger quests fairly soon. Don't do simple conversions of readme files and things like that. So there are some maintainers who would like your help changing from a readme.text to a readme.md so that GitLab will actually render the markdown they've used. And if they're looking for that help, that's fine. But it shouldn't be your first contribution to a project you've never participated in before. And it is also something that we could automate. So it's not the best choice for a contribution. Similarly, changes to license.text or changes to the core compatibility version string. If nothing's really broken, those sorts of things are not good candidates for contributions. So to summarize for automatable tasks, code style, patch re-rolls, rebasing, short file name changes, any of those sorts of things, you might consider opening a request to automate that fix across all projects in the Drupal.org issue queue. But you should not spend individual time doing dozens and dozens of those small changes. They really, most of the time won't get credit and they increase the risk that someone will think that your contributions are just spam. You might even get a temporary ban if too many folks flag those contributions. So to summarize, focus on meaningful impact. And what do I mean by that? Well, there's a lot of potential definitions, but some guidelines are ask yourself, will this contribution add a feature or fix a bug that affects end users? Will they notice when an end user actually recognized that something changed after your contribution goes in? Or will this contribution make the work of developers working on Drupal or on that specific project easier? Or does this contribution help the maintainer with their project in some way that they need? Meaningful impact means contributions that move that project forward that make a significant difference. So what if you need more guidance and more help? Again, your company that is sponsoring this work should be putting together materials for you, but there are also community resources. One thing you can do is work with whoever is supervising your contribution efforts to write up a contribution plan and you can submit that to me at the Drupal Association in like a Google Doc or something like that. And I can help comment on it and make sure that you've got all your ducks in a row for the contributions that you want to make. I can give feedback and guidance. You can also use Drupal Slack to connect directly with the community. There are channels for individual initiatives. There are meetings going on constantly. Even if you're not jumping in and contributing right away, it might be good to read up on how other people are interacting when they're making contributions in this space. Might help you learn a little bit about what the sort of regular way of doing things is among other contributors. Again, participate in a contribution event if you can. And we know it's not always possible to travel, but many of these events are virtual. And furthermore, some of this information has been recorded. So you might be able to find something like a contributor workshop or guidance for new contributors on the Drupal Association YouTube channel or on a camp archive. If you can make it to DrupalCon though, some of the best contribution opportunities are at our event. So you could join the first time contribution workshop, which I think everyone should do at least once, regardless of your experience in Drupal. You might be an absolute expert, but you should still join this workshop to understand the way to get involved in the community more deeply. You might go to mentored contribution where you know the basics, but you're trying to learn something a little bit more specific or just get more help. Or once you've found your feet, you can go to general contribution and work with others on the things that they're doing to advance the Drupal project. So with all of that, I want to thank you and your company for your commitment to making Drupal better. And together we can build a better open source project. Thank you for your time.