 All right. Good afternoon. Let's go ahead and get started. If you're here to learn how to maintain projects in Drupal.org, you are in the right room. So a little bit about me first. My name is Chris Burge. I'm a technical account manager at Acquia. I started that position about a year and a half ago. Prior to that time, I spent around 10 years in development. I built my very first Drupal site when I was for a program site at Creighton University. And at that time, I was still a grad student. It took me a few years, but eventually I did create an account on Drupal.org, and I got my first issue credit in 2015. And then in 2019, I created my first project on Drupal.org. And that was an opportunity that was afforded to me by the University of Nebraska-Lincoln and my boss there, Bob Crisler. And that's why we're here today to talk about creating and maintaining projects on Drupal.org. So let's begin. Today's presentation has been as a high level overview. There's simply too many details to cover each of these things in detail. In fact, almost each one of these could be its own Drupal.com presentation. So we're going to fly pretty high on this one in terms of where we go over today. And then one note, there is multiple types of projects on Drupal.org. But to keep things simple for this presentation, we're going to focus just on module projects. Okay. So first and foremost, Drupal is open source, and it's also a community. And all of us in the room here today are part of that community. But for most of us, getting here was a little bit of a journey. Come for the software and stay for the community. I feel like that statement sums up the Drupal journey for many of us. It certainly does for me. I initially came to Drupal for the software. You can download Drupal and build some really cool stuff right out of the box. Eventually you're going to run into a bug, though. We're going to identify a feature request. And early on in my Drupal career, I was fortunate to have a mentor who coached me how to open issues, how to create and submit patches, how to provide feedback. And I started attending camps. And today I'm actually, this is my first Drupalcon today. And for open source to work, the community has to be engaged, though. And the community has to give back. This includes both code and non-code contributions. This presentation today is a non-code contribution. But if you're around the community long enough and you're contributing, something like this eventually might happen. Hey, you've made some great contributions to fill in the module name. Would you be interested in being a co-maintainer? And even as I read this now, my heart rate picks up a little bit. What does it mean to be a project maintainer? That's why we're here today. Most of us in the room have probably been active on the contributor side of the equation. Today we're going to be taking a peek behind the curtain so you can see what it's like in the life of a maintainer. My goal at the end of today's presentation is to enable you to take that next step so you can maintain a project on Drupal.org. Alright, so let's jump in. There's a good chance that your first project maintainership won't be a new project, but it'll be an existing project. That was actually the case for me. My first project was requested to be a co-maintainer for the CK Editor Config project, and that's how I got my start. It wasn't with a new project. Sometimes, though, it is necessary to spin up a new project, and that's where we're going to start. But before you start coding, you need to stop and take stock of where you are. The first consideration is probably the most important, is if you're going to push code that's specific for your use case, then how can anyone else use it without also forking it for their own specific use case? That largely defeats the purpose of sharing code. So you need to think about how others might use the features that you're building. Next, and this is important, identify any projects on Drupal.org that are similar to the project you're thinking about creating. It could be that your idea is best implemented as a feature request on a project that already exists. So definitely attempt to collaborate first. And then also take advantage of existing code and APIs. Leaner projects are easier to maintain. And there are also real benefits to contributing a project to Drupal.org instead of just keeping it under module slash custom. So when we talk about generalized use cases, this is an example that I like to use. The Layout Builder Component Attributes module what it does is allows content creators to add HTML attributes to blocks in Layout Builder. This module is something that I built when I was at University of Nebraska, Lincoln. We needed to allow our power users to add classes that were part of our design system. But instead of asking how can we allow our editors to add our design system classes to layout builder blocks, we changed the framing. How can we empower Layout Builder users to add CSS classes to blocks placed in layouts? I know this sounds subtle, but it will affect how you approach the issue. We then expanded the scope a little bit to include ID, style, and data attributes as well. But at the end, we had a generalized use case that we could build from. Before writing any code, I surveyed Drupal.org for similar modules. And there were a few that I noted on the project page when we got launched here. In the case of the Layout Builder Styles, it did a similar thing but it was more user-friendly more for your everyday users opposed to power users. The other two had support maybe for blocks but no Layout Builder. And then the finally block class had an issue that was open but it had to be committed and it wasn't available. So I did my research and we decided this was the way to go forward. We did in fact need a new project. But if you do find a module that would be a good fit, then by all means collaborate. The Layout Builder Restrictions module is an excellent example where that collaboration can pay off. Again, while I was at the University of Nebraska, we were using this module but we wanted more granularity in its controls. I reached out to the maintainers at the University of Texas Austin. We set up a Zoom call. We made a plan and coded away. Instead of building a new module or forking this, we were able to work together. In the case of Layout Builder Restrictions, worked with Mark Fulmer there. They actually created a 2X branch of their module and moved to a plugin-based system. So not only could we add the functionality we wanted, but anybody in contrib or in custom code could extend Layout Builder Restrictions going forward. So it wasn't just a one in this one instance. It's continuing to pay dividends. In this instance, we never considered creating a new project. Collaborate first, code second. One of the major mindset shifts that came with Drupal 8 is the idea profoundly found elsewhere. If you've watched Dries' notes over the years, you've heard him say that phrase, Dries. We were maintaining a lot of core code. By significantly reducing the amount of core code by using symphony components, that allowed us to take advantage of a much larger open-source landscape. That allowed us to spend less time on maintaining core systems and more times adding and extending features to make Drupal really cool like Layout Builder, JSON API, and so on. This same mindset will benefit your project. Drupal ships with a lot of APIs in existing tooling, so definitely start there. Use what's already available to you. There's also contrib modules that provide APIs that your module can leverage. In fact, some modules only provide APIs for other modules to use. I know it's different in some other CMS ecosystems. I'm not going to call people out here, but in Drupal it's 100% okay. It's often expected that one module have dependency on another module. Finally, we also have the larger PHP community to draw from. They have a plethora of open-source projects available on Packagist. If your module needs a CSV generator, you definitely don't need to code your own. Sure, you can create a module and you can stash under module custom in your code base, but there are some benefits to contributing it to Drupal.org. The first one is free reviews. This is something I wasn't expecting when I started putting modules up on d.o. I've had contributors review my code to make suggestions about refactoring and optimization to make it better. I've also had more times I can count somebody find a bug, an edge case or a scenario that I hadn't thought of, and they found it and they provided a fix for me. So just by putting the code out there on Drupal.org, I'm winding up with a code. It can also be an opportunity for mentorship. I've worked with some newer developers and I helped coach them through the process of submitting a patch, giving them feedback, improving the patch before finally committing it. That's something we can really do to help out the community as a whole. Finally, by hosting a project on Drupal.org, it provides exposure within the Drupal community. If you're maintaining projects on Drupal.org, that's going to boost your street cred. That's something you can put on your CV. Now we're going to talk about the process of creating a new project on Drupal.org. In order to create a new project, you'll need two things first. You'll need a Drupal account and you'll need to get access. If you're an active contributor you're probably already this far. One thing to note though is only humans get access. If you have a user account for an organization, it won't be able to push code. So just a note there. To get started, all we do is navigate to Drupal.org. I haven't tested this but I would assume that you can't have a project called add because the namespace is already taken. But it would be fun to try. But we're not doing a live demo here. When we head there, we're going to get to create a project page and I mentioned there's different types of projects. We're not going to talk about any of these except for the module project so we're going to go ahead and we're going to click there. This is just a Drupal form. We've seen lots of Drupal forms. Let's talk about this one. The name is the human readable name or title and it can be changed later. Below that we have the project type and we select full project here. There's still an option for sandbox but that option's been deprecated so don't use it. And then the next one is short name. This one's really important. This is the project's machine name. When it goes to add your project with composer require, this is the part that comes after Drupal slash. And importantly it cannot be changed. So if you make it this far and you have any doubts about what you want to call your module like stop and regroup. As soon as you submit the form, it's a done deal. And then when we get below that there's a couple of other fields. One of them is going to be maintenance status and development status. And don't get caught up too much on these. For a new project you're probably actively maintained and under active development. But these change over the life cycle, over the lifetime of a project. So these can't be changed and they often do be changed. Next is we scroll down farther in the form. We get to description field. And this is what you see in the main body of project pages on Drupal.org. It's a WYSIWYG field. But it does come with a template and so this is the template that comes with it. And you put your own information in there. What makes a good description is going to vary a little bit from project to project. But people should be able to figure out what your module is doing and what it's for. It's also a place where you can list similar projects. As I just demonstrated earlier. And then it's also a good place to put pertinent information that maybe for those of us who don't always do a great job of reading the readme. And a good example of this would be if there's things that people need to be aware of when they upgrade from the 1x version of your module to 2x version of the module they need to be aware of. This would be a good place to put it because just because it's in the release notes or in the readme doesn't mean they necessarily see it. We're going to skip some optional fields in the interest of time. But one optional field I do want to cover is the supporting organization field. If your organization is sponsoring a project then they deserve visibility for your efforts. Now the organization field in Drupal speak is an entity reference field so the organization has to exist as a node on Drupal.org first before you can reference it. Okay now we're going to talk about managing branches and creating releases. Again if you've been on the contributor side you've seen some of this. Now I'm going to maybe show you a little bit about how the sausage is made. Drupal.org now leverages GitLab for hosting all of its repositories and in this day and age like almost every developer is used to get and if you haven't it's easy so don't get caught up on that. So for Drupal projects you'll use semantic versioning that's x.y.z. The convention used by the Drupal community is for the branch names to correspond with your release versioning. So for example if you have a branch 1.x you could use it for releases 1.0.0 or 1.0.1 or 1.1.0 and so on. In Drupal in the contrib space there's really no concept of a master branch or a main branch. It'll be semantic versioning like 1.x or 1.0.x is also supported. I have my preference there's other people have their preferences but we don't have time to get into that today. And then if you've been around the community for a bit you've probably heard the term Drupalism. Our legacy version format is definitely a Drupalism. Before Drupal 9 we had branches like 8.x-1.x which meant that projects supported Drupal 8 and this is the 1x version or 1x branch. And that changed when we really wanted a community wanted to make upgrades a bit easier and so many of us have been through like the Drupal 8-9 and 9-10 upgrades and one of the things that makes that possible is that modules can support multiple major versions of Drupal. So today when you see 8.x anything all that means is that it supports some version of Drupal 8 9 or 10. The configuration the support is actually declared an info.yaml file. Now branches can be designated supported and is recommended. If a branch is supported then its releases are going to show on the project page on Drupal.org If a branch is unsupported, if you uncheck a box and click save, then it's no longer going to appear on the project page and when site owners go to the available updates page on the individual sites they're going to get a big red warning that the branch of the project they're using is unsupported. If a branch is recommended then its releases will appear in green on the project page. If it's not recommended then it will appear as yellow and this is all quite normal. Often a maintainer will continue to support an older version of a module for a period of time while recommending the new version to give people a chance to upgrade. But if you've seen the different colors on the front end that's what's going on there and like you can check boxes and check boxes and change the colors but there's like meaning behind it. When it comes to creating releases, git tags are used for releases and the tag name verbatim will be the release name number. So what all you have to do is create a tag and then you push it to origin. So 1.0.0 that could be a tag. I should mention that pre-release version is also allowed so you can do like dash alpha dash beta dash rc for those. So what we would do is on our project page we would go to release edit and releases and then down to add a release and this is the first page you get to. It's an interstitial page but what you would do here is select the tag that you want. You can also do branch releases that you can run automated tests against. But today we're just going to do like a regular release and the important thing here is that once you've created a release you can't take it back. So if you accidentally release a bug your only option is to fix the bug in the subsequent release and I actually did this very recently. It happens. Now with any project release notes are a best practice and now we're on the second page. We clicked the advanced button to get here. It's again just a whizzy wig form and this way you can put your release notes. And the cool thing about this is all of this jazz in here I didn't have to do any really work on that because Matt Gloman, he's a developer of Aquia, he created a release note generator. So go to this URL and all you have to give it is your project's machine name the version from, the version 2 and it creates all of this for you. At that point it's copy and paste and maybe you tweak a thing or two but every time I use, every time I make a release this is what I use. Okay then we get down to the very bottom of the form and there's a couple of other fields. If you choose to put a short description it'll appear on the project page in the download section. Typically I don't unless it's something major like add Drupal 10 support. That's a place where I've used it. There's also release type tag and that'll, something that will appear on the releases page. In this case I was releasing a bug fix. This might have been that second release where I was fixing the bug fix. The bug I released like two hours before. The last step is to go ahead and click save. Remember when you click save there's no going back. So at this point you just have to wait a second for Drupal.org infrastructure to go ahead and create the release. Once the release has been created the release page will one be published and then the latest version will be available for both manual download as well as for composer to download. In this you don't even have time to go get your coffee. It happens pretty quick. Okay. Now let's talk about the issue queue. Issues are the primary way for the open source community to interact with the project's maintainer. They're a place to document and they're also a place to collaborate. So most of us have probably seen this page. This is one for the Ombed Providers module but we're familiar with this. But we're going to talk about today things like category component and some of the different statuses and what those mean. Okay but at a high level first issues are categorized to help maintain a sense of order and sanity. Issues have statuses which identify where they are in the issues life cycle. Then we're also going to talk a little bit about the day to day like how do you actually manage the queue. And then finally we get to the point where if you have an accepted contribution how do you grant credit and then at the end talk about committing the code. Issues can be categorized as a bug report, a task, a feature request, a support request, or a plan. Additionally they can be further categorized by something called component. The default components are code, documentation, miscellaneous, and user interface. And the difference between the two is these are not configurable, the categories, however the components are configurable on a project by project basis. And typically where you see components, seeing those customized is on modules that are way more advanced and complicated than anything I've written where they may have multiple systems and they want to provide a way to target specific tasks. In core they have a whole bunch of components. I've always stuck with these for me and for your first project you probably will too. Now in general the life of an issue will go through several states. At the very beginning you have the active state and what that means is the issue is open but no code has been offered yet. When code does get offered and it's ready to be reviewed then it goes to the needs review state. We'll talk about this here in a second but if you're using Drupal CI the needs review state will also kick off automated testing. And let's say that the code gets reviewed but it's not ready to go in yet it can go to the needs work state. Once the community depends on how many people are active on the issue it's concluded that it's good to go ahead and commit it will move to reviewed and tested by community. You'll see RTBC is an abbreviation quite a bit. One important thing though is like you can't RTBC your own code. It needs to be someone else. And if the maintainer agrees and it gets committed then the maintainer will go ahead and move it to fix. After two weeks infrastructure will automatically change that state to close fixed after which point only the maintainer can reopen the issue. So anyone can change the status from here to here to here to here except when it goes to close fixed. So I may go ahead and have some code. It's a contributor that needs review. I can go ahead and make some reviews on it. Say hey we need to address this particular situation here. I'll set it back to needs work and hit save on the form. So it moves around. And they can also get the issue summary. But the good thing is that that's all tracked through visions. There's some additional status as well. Postpone just means it's being blocked by something. There's also a postpone in the instance where you need more information. So maybe you got a report and it's like well hey I need some more information on this. And you don't hear back for maybe a hot minute. You can go ahead and move it to this state. Oftentimes you'll not oftentimes you'll run into situations where somebody will open an issue. But it's already being worked in another issue. In that case you can go ahead and link it over to the original issue and close it as duplicate. In terms of won't fix maybe a feature request is out of scope for your module. Works is designed. Maybe their bug is your feature. You also can run into situations where you follow their steps to reproduce but you can't reproduce it. And so you don't close it outright. You give them an opportunity to respond. But if it's been a while then you go ahead and close it. It can't reproduce. Outdated you don't see that one used as much. A situation that might happen is that the bug was open for the 1x version of your module. The issue was open for the 1x version of the module. And you're already on the 2x version and 1x is supported and it's just not relevant anymore. You can close it as outdated. Now all of this begs the question in the day to day how involved should a maintainer be? Because as the maintainer you're responsible for keeping an eye on the issue queue and for merging code. But you have to balance that with the fact that you're also a human with a job and a life outside of Drupal. So if you walk away with nothing else today, retain this next part. It's not all on you. Open source projects are a two-way street and this connects us back to the opening and the presentation. Keeping a project live and well is a shared responsibility between you, the maintainer, and the community. You don't have to do everything, nor should you try. There's only so many hours in a day and there's only so many hours you can reasonably allocate to a given project. What I recommend is to give priority to urgent matters and major, sorry, urgent and major issues. Then also to pay attention to issues that have been received in community engagement. Use your judgment. If someone's identified a major bug with reproducible steps, that's important and actionable. If someone opens up, the module is broken issue and we know those look like. There's really not much you can do with that. So maybe post back to ask you for some details. But it's the reporter's responsibility to create a quality issue. That's why the issue template exists to begin with. And I recommend setting aside some time from time to time to just go over the issue queue for your modules. And a repeating calendar item is a good way to do this. Finally, many, if not most projects on Drupal.org have multiple maintainers. Co-maintener could be a coworker who sits a couple cubicles down from you. It could also be a collaborator from the other side of the world. The key is that all the maintainer responsibilities we discussed here don't have to be just on you. You can have a small team. Next, we'll move on to committing code and granting credit. But let's start with contribution credits. A key part of the Drupal community is granting credits for contributions. And what that boils down to is did the community member make a substantive contribution to move the issue forward? That's the definition I've come up to kind of make sense of like when you grant credit or when you don't. A little bit of a gray area. But all community members should be aware of the review abuse, sorry. Abuse of the contribution system, credit system policy. So you need to review that as an action verb. What that boils down to is there's been an issue with inauthentic contributions. And so if you've been in an issue queue and you'll see something like update readme from readme.txt to readme.md. Like there's people out there that just like Karp Obama issues with that. They have like a script friend that they have do stuff like that. That's an abuse of the credit system. So both as a contributor and as a maintainer, that's something to be aware of. I've talked to some other maintainers about this. If you have somebody open on one of those on your issues, take a look at it. If they're just getting started and they haven't done very many of these, that might be an opportunity to coach them as well. And that goes back to that mentorship thing we were talking about earlier. Okay, well let's commit some code. Now this next part assumes that you've offered patches and opened merge requests on other people's projects. Additionally, Drupal.org only supported patches. So a contributor makes a diff locally and they upload it to the issue. But now because of the Drupal community's collaboration with GitLab, this has opened some new doors and one of these is merge requests. I just quick note here, as a best practice, anytime you commit code, it should be documented by an issue. Because future you will thank you. Alright, well let's start by committing a patch. So if we were to look above the form, this would be everything that you see normally as a contributor about all the comments that have been posted and commits, or commits to merge requests, etc. This bottom part here is what you'll see as the maintainer. So the first step we would do is we would download the patch that we want to use, that we want to commit. We download and we apply it locally to the release branch. And we wouldn't commit it yet though. Next we'll come back to Drupal.org to grant credit. And under the by column here, go ahead and check the box for everyone who has been contributing to the issue. This is going to, who's going to get credit. Now as you're doing this, this field down here to Git command is going to be automatically updating as you add people here. And the commit message, this is what this is, it just grabs from the issue title. And you can customize it here if you want it to be something different. And then it'll get updated down there. And I do all my Git stuff by command line. So I just copy this, take it over terminal, paste, and hit enter. So that point has been committed. And I go ahead and push to origin. And now we can change the status of the issue to fixed. Let's move on to merge requests now. DUI looks identical with the exception that we had at the bottom now, I think most of us can see that. There's going to be a field for merge requests. So often the first step is going to be to rebase and address any merge conflicts you might have. Once it's mergeable go ahead and we're going to grant credit like we did before. So check the check boxes. And then down here in this case there was only one merge request open against an issue. You can have multiple merge requests open against an issue. So make sure you select the one you actually want to merge. And click the merge button. What's going to happen is all the commits are going to get squashed and merged in the commit message which is going to be whatever you have up here. And in this case there's like no additional steps because you already merged it. So just go ahead and change the status to fixed. And you're done. Okay. The Drupal communities governance around security is one of the things that I really think sets this apart from other open source communities. Community members have a process to confidentially report security issues to the Drupal security team. If you've signed up for the security advisory emailing list then you've seen the Drupal security team in action. So while security coverage is optional it's highly recommended. I specifically highly recommended. What it does is it gives users of your, users of your code more confidence in the quality of it. And some IT departments and corporate IT people get like really persnickety about this. So having this on the bottom of your module is assurance. Now to get security coverage is a two step process. The first thing you'll need to do is a one time application for your Drupal.org user. And the application process involves a code review. So you're going to have to have some code that's going to be available for security team members to review. Now once you've been approved your Drupal.org user will be granted a role that will then allow you to opt your individual projects into security coverage. So that's a second step. Once you have the role you'll need to go through your individual projects and opt them in. And at this point I should mention that only stable releases can be opted in. So if your module is still an alpha, beta or release candidate at that point you won't be able to opt it into security coverage. Now as the maintainer one of the most important things you can do to ensure the integrity of your code is to leverage automated testing. Automated testing could be its very own Drupalcon presentation. So I'm not going to tell you how to do it but I'm going to tell you why it's a good thing to do. I just want to acknowledge up front the writing unit tests can be a real pain. At least when you get started I'm getting better at them. The thing is you have the upfront cost of writing the test. However you get the benefits every time you commit code after that. Every single commit on every single merge request will benefit from this because it will kick off automated tests. And running an automated test is way more efficient than manual testing because it also takes out the human error element. With test coverage you can catch bugs before they're committed and when you're writing new tests for existing code there's a good chance you'll find bugs or code issues that you didn't even know were there. Every time I've added test coverage to a new module I've written I've always found bugs that I didn't realize were in my code. So not only is the benefit future me it also benefits current me. And the best part about tests is that they're configured to be running in an automated fashion. When code gets pushed to a merge request tests automatically run against it. You can also run your tests to regular intervals. I run mine once a week and this is important because maybe something in Drupal core like one of your upstream dependencies breaks your module which does happen from time to time. The automated test is probably going to catch it before users do and so it's a way to get on top of that before you have people upgrading to a major version of Drupal and running into issues there. So currently on Drupal.org we have two ways to run tests. The first one is Drupal CI and this one's been around for years. It supports both the patch workflow and the merge request workflow. When you're setting up these tests you have to define the Drupal core version, the PHP version and the DB version. Now just right off the bat here Drupal CI has been deprecated in favor of GitLab CI. So let's talk about GitLab CI. This was made available to all projects on Drupal.org back in July and it's way more configurable and way more customizable than Drupal CI. The only catch is that it supports only merge request workflows. It doesn't support patch workflows so there may be a little bit of a weird transition period here where you have patches and I don't know if you put them in merge request but I'm still figuring it out myself. Now with this the Drupal association they provided a default template that we'll take a look at in a second and the thing to know about it is it uses includes to reference files that are centrally managed. So this allows you more or less to put on set it and forget it mode in terms of Drupal core version, the PHP version and the DB version. There's also a pre-desets set of tasks that run against it so like linting, any tests that you have are going to be run and the best part of all of that is that that can all be overwritten if you really want to leverage GitLab in your project for CI CD. When I was putting together this presentation I hadn't used GitLab yet and I was a little annoyed that I had yet another thing to learn but it was super easy. Just download the Drupal CI file from the Drupal association, committed to the project supported branches so if your project has multiple supported branches you'll need to commit it to each one of those branches and then push it and then the pipelines will start running and then when people visit your page they'll see that you have GitLab set up and your stuff is passing. This is the template file and there's only like there's seven lines that actually do anything. Call them a couple variables here and some includes. It's actually mostly comments up and below but you can definitely customize this and do your own thing but for all my projects right now this has been enough for me. So you can access GitLab so you can see the various pipeline jobs. The bottom one was when I first added GitLab the YAML file and pushed it. The second one would happen there was that I committed a patch and pushed it but there were some coding standard violations so it just shows up as a warning that doesn't fail it but I'll need to go back and fix that in the future. Having said that though had that issue been started as a merge request that coding standard issue would have got caught before the merge request got merged. Further projects may need to do more advanced things and this could include manually set in the Drupal core version, PHP or MySQL versions. In some cases your project may need to test against different versions of Drupal core and this is going to be accomplished in matrix testing. We're not going to go in any of that today but there's some good documentation and some good examples on Drupal.org. Okay, we're almost done here. Now we have to talk about the open source license. This is probably one of the less fun parts of the presentation but it's something we do need to cover. Drupal is licensed under GPL 2.0 or later. If this is something that actually interests you you should go to the license page on Drupal.org and it's covered in some detail there. The takeaway we need to talk about today is that Drupal modules and Drupal themes are considered derivative works so if you choose to distribute your Drupal code it has to be under this license. You don't have to distribute your code though but if you do it's automatically going to be under this license. And in your project you don't need to add a license file. That automatically gets added to that infrastructure when releases are packaged. Okay, then the very last thing is dealing with abandoned projects. Sometimes a maintainer will need to step away from Drupal. Life happens. Maybe they got promoted into management, maybe they left their employer, maybe they had a significant family event. Like I said, life happens. This raises the question how do we deal with projects which abandoned might be a strong word but maybe aren't being actively maintained. He has a multi-step process for this and again I'd refer you to the official docs but on a high level it's a two-step process. The first one is to attempt to contact the maintainer by both the issue queue and by their contact form on Drupal.org. Then if you don't hear back, the prescribed time is two weeks but if you don't hear back from them then you can escalate the issue. And this can be, you can have one of two goals in mind for this. The first one is to simply have the project marked as unsupported because it's not unsupported. Or it can also be with the goal of taking over as a maintainer. So this might be how you become the maintainer of your first project. Good Governance is one of the things that has allowed Drupal to be successful and this policy is an example of that. Many of us have run into abandoned projects on packages and for those of you out there who like to do PHP coding, you've run into this like it hasn't had a release in five years. And now there's two or two forks. By having this Governance model that allows us to avoid that situation. So that's it. I want to thank you all for attending today. I hope you feel both equipped and inspired to take this step into project maintainership. And maybe by the time we get to Drupal on Portland we'll have some new maintainers. We have a couple of items here we need to cover. So the first one is there are still contribution opportunities that are available. And then finally the Drupal association would appreciate feedback. So go ahead and make sure you're filling out the surveys. With that we have a couple of minutes if anyone has a question. So we have a new maintainer took over a module and created a Drupal 10 release. The question is about how to tag it. All of the release type. That wouldn't really be a new feature or bug fix or security release. You don't have to have a release type. You don't have to check me in those boxes when you create a release. So there's sometimes I don't but most of my releases include bug fixes because you know bugs seem to pop up a lot. It's kind of like whack-a-mole. But if it's just for Drupal 10 then you wouldn't have to check any of those boxes. It's an optional field. Alright with that we're at time. Thanks everybody for joining us.