 Welcome, everyone. I hope you're having a good conference so far. It's a little bit of a marathon, the first part of Monday, getting into the swing of things, going to the Dries Note, seeing all the sessions, getting your schedule together. But I do hope it's going well. You are here today at the Drupal.org Accelerating Contribution Panel. So hopefully that's where you intended to be. There's still time to run for the doors. But we're gonna be talking about what we do at the Drupal Association and together with partners to support the community in building Drupal. The tools that you use to collaborate on Drupal.org, the infrastructure behind the scenes. And we're also here to answer questions, talk about possible future features, talk about kind of what's behind in going into these things. So to kick things off, here are some of the faces that you're seeing on stage. I guess you probably want to see mine as well. And the top row is members of the staff of the Drupal Association engineering team. The bottom row are either sort of volunteers or partners who help us with infrastructure, security, and things like that. So we're really grateful to be with you here today. I think I'll hand the mic down the row or we'll share mics down to do some brief introductions. So I'm Pestinette. You've seen me all over Drupal.org, Drupal Slack. Today I'm the CTO here for the Drupal Association. So mostly what I try and do is block and tackle so these folks can actually get things done. Hi, Neil Traum. I do development for Drupal.org, architecture planning, and yeah, bit of everything. Hi, I'm Brendan, Beeman on Drupal.org. I build things, break things, fix things for Drupal.org and subsites. I'm Alex Moreno. I just joined the Drupal Association a couple of weeks ago. So very exciting to be in my first Drupal con North America. And I will talk about me and what I'm going to be doing in the next years. Hi all, I'm Fran Garcia. I work as well with engineering team. I've been helping a lot migrating some of the sites from D7 to D10, as well as helping out with Drupal.org features, yeah, broken things. And as well with the GitLab acceleration which you will listen to in a little bit. Hi, I'm Norton or Narayan Norton. I am the lead systems engineer for Drupal.org. I was here when we upgraded Drupal.org from four, seven to five, but for some reason I'm still here. Right now focusing on modernizing our infrastructure and moving to Kubernetes and split between the cloud and OSL. Awesome, I do want to do a few thank yous. So Narayan is also the CTO at Tag1 Consulting who are our infrastructure partners in supporting all of the back end of Drupal.org in making this work. We also host at the Oregon State University open source lab, which is a place that we and many other open source projects have been at since the very early days of open source projects realizing they had to get out of someone's dorm room and maybe do something slightly more professional. So many thank yous to them. I want to talk a little bit about what the Drupal Association invests in engineering resources. When you become a member, when your company becomes a supporting partner, when you sponsor DrupalCon, when you buy a ticket, a lot of that money goes to directly support this team and our operations and support. We have close to $500,000 in direct costs. We get more than half a million dollars in in kind trade for services we could otherwise not afford salaries for personnel. More or less 50% of the net revenue of the Drupal Association goes just to pure engineering programs, Drupal.org support infrastructure and this team. So your support goes a really long way in making what we do possible and in turn making Drupal possible. So let's talk about Drupal Acceleration in particular. And as you saw in the keynote and as you've been hearing a little bit throughout the conference so far, the Drupal Association is trying to take a greater role in accelerating innovation in the project and Alex with his third week on the job is gonna talk a little bit about where we're going with that. Yeah, so I'll keep it sweet and short. As I said, I just joined the Drupal Association so the only update I really have about this is, hello, my name is Alex Moreno. I've been working in the industry for more than 15 years and I've been doing so many roles between small and big and huge and enterprise companies. So I think I have a little bit of context and experience on what we need to do here. And at some point, a few weeks out, I became jobless and something, first I got very scared, but something amazing happened that some people at the age contacted me. It's like they show me the strategic plan for the next few years. I thought to my goodness, this is huge, right? I will be crazy enough not to accept this and at the same time I will be crazy enough to accept it. As you know in here, so I accepted the role. Some of the things I'm going to be doing is trying to talk to all the actors in the industry, trying to find what we need to do to keep Drupal as it is. Drupal has been innovative for 20 years and we need to keep Drupal that way otherwise we are not going to survive, right? So that's going to be mostly my role. There are going to be things like project coordination, find where we need to put investment from the DA on which projects and in general trying to enable individuals and organizations to try to make Drupal, try to accelerate Drupal. And if you do have thoughts, questions, suggestions about the way that we enable contribution and these sorts of things, please do come up during the Q&A portion and share those with us. And if you have ideas about what we can do to improve things like issues with three years in there or things like, you are more than welcome to come up Dr. Me. Please. Awesome. And speaking of contribution enablement, one of the big things for the Drupal Association the last several years has been trying to provide incentives for organizations themselves to create a contribution culture. So if you are building a business on Drupal, there is a sort of enlightened self-interest that, hey, maybe you should give back to that open source project but there's also now sort of concrete benefits to doing that. The marketplace on Drupal.org is built on the contribution credit system. If you're a contributor, you've seen this before. The maintainer of any project, whether it's core, contrib, theme, whatever it might be, can find any issue that you might have contributed to and said, yes, you helped us solve this and when that issue is closed, that can be factored into the organization you work for and their position in our marketplace and in our community we're trying to create a flywheel of energy and investment to increase that. Brendan's been working on some tools related to this to help the organization owner. So if you're one of those people who owns a business that either contributes now or is interested in contributing, he's built a few features to support you. Yeah, so I should preface this, the right image is work in progress. Currently, the owner tools are visible to organizational authors and it gives you a window into where you stand as far as your contribution and on the right, it's just a much more fleshed out. It's basically most of the things that go into determining marketplace rank, gives you an idea of how you're doing in the ecosystem of contribution. Yeah, not super exciting because it's not super public facing but I'm hoping it will help organizations work with us to have a better understanding of how they can help contribute going forward. And part of the increasing transparency we're trying to create is if we want to point to some specific initiative and say this is strategic for Drupal, we wanna be able to go to an organization and say here's how you can contribute to that, here's the concrete benefit that that contribution will have and here's how you keep track without having to have a one-on-one conversation with an engineer or a salesperson on the Drupal Association staff because we want that contribution enablement to be scalable. Correct. Brendan's also done some work to support those of you out there who organized local and grassroots community events. Hopefully you're familiar with this feature but Brendan, why don't you walk us through it? Sure, yeah, we built the community events system. Oh shoot, I don't know, two years ago now. And since then have gone through a few iterations, adding features, fixing some things. We're now recognizing sponsorships of organizations on, or sponsorships of events on org profiles. We can export event data, just recently, events became a multi-select field, event type became a multi-select field so you can have a contribution camp as you can see. A lot of smaller cleanups too, some big ones hopefully on the way related to time zones, time is hard people. But yeah, just anywhere we can, we're trying to support what we can. Another piece of work that I've been doing is getting Drupal nine, sorry, events.drupal.org onto Drupal nine. We partnered with 611 for the theme migration. Leveraging paragraphs now, it's much easier to use for our content editors and content creators. We no longer measure page load times in full seconds. And now that we have the new D9 infrastructure in place, we can use DDEV and do development locally, which is fantastic, thank you Narayan. Awesome. So the next thing we'll start talking about is how the Drupal association is collaborating with core on certain initiatives. This is something that Neil in particular is kind of in the middle of in a number of different areas. And this was the seed for the Drupal association taking an increasing role in product innovation in Drupal. To do automatic updates or project browser, it was going to become necessary for Drupal.org to provide that data. We serve the updates, so any feature of Drupal that requires updates data requires Drupal.org. And our experience in getting involved in this says, hey, perhaps we should be involved in other ways with product innovation. So I'll turn it over to Neil. Yeah, so if we're doing automatic updates and project browser, we want a stronger security around what your site's running since your site's gonna be writing its own code. So that's supply chain security. There's a project called the update framework, tough from the cloud native computing foundation, I believe, and they designed a standard for software updates, metadata, and downloading the updates themselves to mitigate a number of types of attacks that someone might try. So then we implemented rugged with help from our contractor or consensus enterprises to do automatic signing of targets. Targets are as tough term for just something that's signed. So all the metadata, all the package zip files, everything that composer does. And yeah, we have a proof of concept deployed in a staging environment and we're working towards the next steps. So we need even more metadata, security related, like what's the security release, what's the security advisories, and need that signed as well. And Drupal Core is actually on, it's on packages.org, not packages.drupal.org. So we need a way to sign that even though we don't run packages.org. And yeah, the next steps are testing, finding, fixing edge cases, and third party security audit. Yeah, which is something we're working on and something that takes a lot of funding. As an example, we've been working with the open source technology improvement fund. And they estimate between $85, $115,000 to do a proper audit of the code involved in this package signing, which is an investment we have to make as a project to ensure that the update system is going to be secure. But it is a place where again, we simply can't do that without the support of partners and individuals to make that happen. And certainly if you're interested in the domain of supply chain security and the things involved in this, you can learn more in the auto updates channel in Drupal Slack or you can come talk to us somewhere at the event. We're happy to tell you a little bit more about why we chose this model for Drupal's update system. From here, we're gonna talk a little bit about Drupal.org project endpoints. So Fran, can you explain what this feature is and what it's for? Yeah, sure. So you may have heard about Project Browser. Right now, Project Browser is consuming data from our old unofficial kind of D7 API, which has its own formatting. And it could be ideal for Project Browser to read live data. We decided that rather than spend more time on the D7 site that we would need to migrate at some point, we could start building things on Drupal 10. So that's how we started. We migrated the project's content to get it with the related information, like users and supporting organizations, et cetera. And then we exposed all that data using JSON API as you can see over there in the screenshot. And then based on that JSON API endpoint, we built Project Browser plugin. That's how we are calling them, a source plugin where we can read information from. And then once we created that plugin that allows, actually, Project Browser to show real life data from all the projects that are on Drupal.org. This right now is a little bit of work in progress. So a lot of the ground work has been done, like the migration, exposing data on the JSON API, but we still have some challenges as we do have an old database and we do have a new database. We need to leverage the new infrastructure for it. And then we need to have all those processes running in parallel, both D7 and D10. So this is something that should be coming up soon, but yeah, this is the endpoint that will feed eventually Project Browser. Awesome, and we should talk a little bit as well. Well, did I miss anything, Fran? Yeah, okay, good. We should also talk about Drupal 10 upgrades for Drupal.org. So as some of you probably know, Drupal.org is often one of the last sites to upgrade to the latest version of Drupal because Drupal.org does some unique things that know where the Drupal site does. Most of you out there are probably not serving the updates data for Drupal sites to update with, for example. Most of you are not serving a localization server and multi-lingual in these other sorts of features. So to migrate these things, we rely on the help of the community and on the allocation of time of this internal team when we have that time available. So there's been a variety of progress towards these updates and we'll go through briefly some of these things. First of all, I wanted to thank the community volunteers for localize.drupal.org who basically completed and handed off a Drupal 9, Drupal 10 update of the localize site. Not completed yet, but... Well, are in the progress of doing. Yeah, significant progress. Yeah, yeah, the core translation modules are all in really good shape and there's a few things we have to do, like the theme for Drupal.org is not completely migrated and things like that. I'll go back to the slide briefly. So as Brendan mentioned earlier, events.drupal.org is complete. API.drupal.org is sort of waiting for deployment on the appropriate infrastructure. We've been hard focused on the secure signing problem that we've talked about before and that takes priority over these migrations but these are in the queue ready to go localized.drupal.org and then www.drupal.org starting with the project browser endpoints that Fran just talked about and then other features like contribution features that we're gonna be talking about in the GitLab acceleration portion. Yeah, and should say for www.drupal.org we'll end up running both in parallel for a while. So if you update a project on drupal.org you'll be updating on Drupal 7 and then that'll migrate to Drupal 10 and get to the project browser endpoint JSON API and we'll keep shifting more and more things towards the 10 or 11 column. So from there, what's left before we actually start deploying these sites? I think I'll hand it to Neil again here to talk about a few of these features and then also to Ryan to talk about kind of getting production ready for some of these things. Yeah, so all these sites have single sign-on with each other in Drupal 7 and before that we had a project called Bakery for managing the cookies for single sign-on but we're moving towards key cloak so there'll be different customizations around that to authenticate a single sign-on and also enable social sign-on and third parties to be able to authenticate against your login with your Drupal.org ID. So a lot of that migration's ready for review and it's been waiting on time to deploy. The theme, the people working on Localize did a lot of work on Blue Cheese, which is our theme. So that's in a good spot and Blue Cheese is actually mostly CSS that we really avoid PHP code in the theme so hopefully we can maintain the two branches of that and parallel and merge from one to the other as we can't put everything on pause and start updating, concentrate on updating sites because people keep asking for features. So Narayan, could you speak a little bit to the infrastructure that backs the Drupal 10 sites and in particular how it compares to what existed before for Drupal 7? Yeah, so what we've been doing for quite a while now is kind of chewing through some tech debt and this is our first opportunity to kind of build from scratch something that we actually want to run and is using technology that is well understood and often used these days and not like Jenkins running puppet. So we built that for first events and API and we're using those as tests. Events is up on it, is running on Corentes. With the cluster deployed via Pulumi we use Rancher for the developer experience and then consistent deployments via Argos CD. Events and API are pretty good first test cases because they didn't require live migration. The project browser endpoints and Drupal.org itself will require live migration so that's where we're gonna have to actually connect our old database cluster or make our old database cluster connectable from this new infrastructure which means having a VPN endpoint from the OSL into an AWS VPC so that's the next part of this. Our old database cluster is old like capital OLD. So it's something that we want to have an actual live migration from because just dumping it out and restoring it to a new version is gonna be troublesome. It's always troublesome for Drupal.org because of our international user base. So yeah, so basically what I was talking about right there. The next step is the DB upgrade. We have been focused on tough signing which is what we were talking about earlier where we were taking the work from the rugged project which is the PHP implementation of the tough protocol and making it deployable in a modern best practices way. And building out containers that we want to run long term and are actually maintainable to run long term. That has gone very well and we have that running and staging. We'll probably pivot to production fairly soon to have a production-ish endpoint for testing and then we'll go to the project browser and a lot of this will be fairly set. The one exciting thing on the list here is Tecton which is a CI CD system where you can define the pipelines and tasks that are associated with a site right next to the site in the deployment manifest so that developers are more able to contribute and define exactly the tasks and pipelines they want running alongside the site. A lot of people don't understand that like Drupal.org is not just to the site. We have a Jenkins instance that is truly terrifying of just all the various tasks and pipelines to build packages and clear caches and aggressively unclear caches and having all of that defined in code right next to the actual site that can be cleanly deployed in between environments and even locally for testing is gonna be a huge step forward for us. Awesome, thank you. So now we wanna talk a little bit about the GitLab Acceleration Initiative and in particular the very specific tools that you use on a regular basis to contribute to Drupal. So this is how you get the work done when building Drupal and making the project better. So we've made a lot of steps in this direction. You've also probably seen these updates in a variety of Drupal cons. So it's an involved process and a careful process because we need to ensure that we don't disrupt the release cycle of Drupal by suddenly pulling the rug out from under all the tools and at the same time we wanna ensure that when we move to a new tool set we preserve some of the key innovations of the Drupal project like the credit system. No other project has this way of incentivizing individuals and organizations or even just measuring the sponsored versus purely volunteer contributions to a project. So this has been really important to the work that we're doing. So Neil, can you talk through some of the goals and kind of the outline of what we're doing here? Yeah, so yeah, the overall goal is not just to use GitLab, it's to make contribution to the Drupal project easier and GitLab happens to be a big part of that. And yeah, more standard tools, you know, more around get, you don't have to, well, you have to learn to get instead of the learning of patching and deaf and everything. And yeah, preserve the collaborative nature of Drupal. The kind of unique thing about the Drupal project is we have contribution times and encourage people to, widely encourage people to contribute back to the project and any single issues, especially core issues are handed off among, you know, three, four, five, seven people. So since this is making contribution easier, a single sign-on is kind of part of that initiative umbrella. And we're also working on simplifying Drupal.org. So Drupal.org, we used to have the database of all the commits that you made. We don't have that anymore, so there's one last thing to migrate to past Drupal 7. That's the solution for a lot of the, or some of the migration things. It's easier to not migrate it. And GitLab CI, that's available today. Anyone can put a GitLab CI.yaml file in their project and use GitLab CI. We'll talk a little bit more about that, I believe. And Fran has been working on prototyping how issue collaboration is gonna work and issue credit once we're, and also the migration towards GitLab. So yeah, the next kind of things you'll see next are GitLab CI, contribution credit. That's something you will be able to switch independently of the, you know, before we start moving issues, you'll see the contribution credit move off of the old Drupal.org onto a Drupal 10 hosted system. And same with issue collaboration. We're keeping mostly the same issue fork process, but the UI for that will be on Drupal 10. So as Neil said, today, as of today, any user who wants to switch to using GitLab CI for your project, if you're a project maintainer, that's available now. Up until this date, we have been in a sort of limited test window with about 20 contributed projects who volunteered to opt in. And we've done a lot of work to sort of get this ready. So GitLab CI needed to be, and still needs to be, sort of feature complete with Drupal CI. We needed to work with Core and Contrib for both current sort of modern Drupal and legacy Drupal 7. And for Contrib testing in modern Drupal, that's available today. It's enabled for every project on Drupal.org. There is a template that we are providing that you can find by going first to the source code link on the main page of your project, going to the ad file UI in the repository browser, typing in the name.gitlab.ci.yaml. You'll be presented a list of templates and the one right at the top, template.gitlab.ci, automatically configures GitLab CI for you, following all the patterns that you're used to from Drupal CI. So it uses include files to set up variables to let us centrally manage and keep track of what's the next supported version of Drupal or what was the last security release or what's the minimum supported version of PHP. Those are all preset variables that we'll update over time as they change without you having to manually commit a change to this file to keep track and keep on top of it. As I said, we're updating that template for you. You'll see the include files when you're browsing the template when you first save it. But for most users, especially if you're a project maintainer who is not super well-versed in testing or CI, you should be able to save that template, commit it to your project and not have to do anything further to have sort of the standard level of testing that you've been used to with Drupal CI. And a lot of work from the community and ourselves on staff went into making that possible. But the advantage of this is you now have all the flexibility and customizability of GitLab CI pipelines. You can override these variables to say you want to target a different version of PHP, a different version of core. You can change the template workflows. Anything that you might be used to from GitHub in terms of GitHub actions can be replicated in CI pipelines. So there's kind of an unlimited horizon of how you can customize CI. And I think we may see some significant innovations in sort of new tools being adopted, new types of testing, because you're no longer relying on Drupal Association to centrally provide that configuration. We do provide a central base configuration, but any project can update and override it. So next steps is we're optimizing core testing in particular. You may not know this, but today every Drupal CI test of Drupal Core runs on a 32 processor, 64 gigabytes RAM spot instance in AWS. Everything is mounted into a RAM disk. We're not reading directly from a disk. We are highly paralyzed these tests, and it still takes an hour and 20 minutes to run. There is a lot of work that goes into trying to get the core test suite to come back quickly, as quickly as we can. Right now we're working with some folks on the core team to replicate all of the work that made core tests run that quickly. On GitLab CI right now, their last attempt, I think they've gotten better in the day since I wrote this slide. The last attempt was still running in about three hours because a lot of the tricks we had used in Drupal CI to really optimize and paralyze those tests wasn't quite ready. Another way to think of it is every core test costs about a dollar from the Drupal Association infrastructure, and we run easily 10,000 in a month. I also mentioned Drupal 7 testing, and you might be thinking, oh, God, why? But the truth is we are continuing to support Drupal 7 through the end. It still has security support. There'll be another session today talking about the end of life, so we must continue to support it, make sure that we're not holding back keeping Drupal CI around just because it's our only way to test 7. So we will be working on an option that basically skips the composer steps involved, allows people who are still maintaining their Drupal 7 versions to continue testing that. So now let's talk about contribution credit and then issues, so I think I'm back to you, Fran. Thank you, Tim. So yes, he said previously we are not trying at first to reinvent anything. We are trying to get what we do have now as we can see there into a new system. So right now if we want to attribute contribution when working on issues, so you can say whether you are volunteering or whether you are working for a certain organization or customer, and then at the end of the issue, before fixing the maintainer will select which users are credited for the work on the issue. So that is what it is now, and this is how it will look like in the new system. As you know, we will talk about this in a bit. Issues we migrate from Drupal.org to GitLab, but the credit's won because we have a very unique way to grant credit to people. So right now, because we have the two systems running in parallel, both issues on Drupal.org and issues on git.drupalcode.org. So this is kind of how the new system will look like. You will just have a source link where the contribution credit comes from. We will have related information that may or may not have activity like merge requests linked to that issue. And then we will again bring a list of users whether they are contributing, which companies they were working for. We will even bring the kind of activity like how many comments did they do in all those in the issue and in the related merge requests, or even if they gave emoji reactions to the MR. So this is how the previous screen is how it will look to everybody. The new screen is how it will look for a maintainer. So by default, we are not granting the credit. We are giving the maintainer as much information as we possibly can to have them make the right decision. In this case, the UI will be pretty simple. It's just check boxes. You will just select which users you want to credit. You click on Save and that's about it. Certain other things like crediting other people. We will still remain. We do have now in the current system. And for example, users that are brought that way will be automatically credited. But yeah, we have that kind of difference between how a normal user will see it and how the maintainer will see. But we are keeping feature parity with what we do have now. And one of the things about this system is it's now sort of decoupled from the source of the activity, right? So that activity is an issue, a merge request, one that happened on Drupal.org in D7 or a new one that happens on git.drupalcode.org when we've migrated those issues to GitLab. Yeah, definitely. It's as decoupled as it gets. I mean, we do have three systems talking to one another. We have the D7 issues, the GitLab issues, and the D10 and Drupal.org endpoint. And those three systems are talking together. Yeah, yeah, APIs. So speaking of issues going to GitLab, why don't you keep going and tell us like what you've built in prototype so far to actually move us over there? Yeah, certain. So yeah, as we already mentioned, we are trying to keep what we already have. But in the new system, a big part of it is to migrate issues from Drupal.org to git.drupalcode.org. Here is just an example of how a current issue will look in the new system. I actually did a quick demo for the TrisNode last year in Prague, where we show how the issues go from drupal.org to GitLab. That's how they will look like. So parting from that basis, we migrate all the metadata as labels, so things like the status, the priority, category, version, component. We be labels in the new system, as we can see in there. You can go ahead. And then, yeah, I did talk about this as well in the past. We have Kanban boards that we can just configure. And we can even automate certain things, like applying certain labels or removing certain labels. But yeah, this is going to be the new way of managing issues. And I think I can see a real value for folks. For example, on the accessibility teams who want to see needs review issues or RTBC issues in core tagged for accessibility on a board where they can drag those around more easily rather than just a bunch of sort of saved searches. Also, we've been talking about it a few times. So issues by default, the way we work on them, they are collaborative. So it is as well, we do have a very custom way of dealing with forks, with who has access to those forks. We try to make an issue open to everybody to work on. So they just need to request access. I mean, if they have access to the parent kind of project, they have access straight away. But what happens if I'm just a contributor that I want to help into a project that I don't maintain? So this collaborative approach is very special for us, from the community. Again, that's something that we currently have on Drupal 7. We can create a fork. We can create MRs. We can request access. So we are trying to do exactly the same in the new systems. So from GitLab issue, we will have a bot post some automatic messages. One will be about contribution records, which I just spoke before. And the other will be about managing forks, merge requests, access. And if we go ahead, we can see how that link looks like in the new system. And we can see how the new page starts to look. Basically, we will have the issue linked. All the forks that are attached to that issue, we will be able to create new forks from the UI. If we need to, we will be able to request access to create MRs. I have to say here that when possible, we are trying to leverage GitLab UI. So for example, to create MR button, you can see there is a GitLab icon. And that's just because you will be directed in there and you will create the MR from there. So that's kind of educating the users on how to use the new system. Yeah, that means that they could create MR directly from there if they learn. Once everything is done, then we can also see all the merge requests that are linked to the issue. And of course, we have a link to the contribution record. So we are trying to go back and forth between the different systems. And yeah, basically all these features is what we do have right now on this seven, but built in the new D10 system. And there's a few ways that you can help with this process. So there is a meta issue for the entire GitLab Acceleration Initiative that covers GitLab CI, Contribution Credit, and the issue migration. There's a channel in Drupal Slack called Pound GitLab where you can join the bi-weekly initiative meetings, test things out, try things out that we're doing. It's really important that you help test these things as they become available. So if you are of the old school, for example, and you're still primarily using patches on your project, we really encourage you to start using merge requests now. Patches will be deprecated. GitLab's model is not built to do patches. It can't run CI tests on patches. When we've fully moved over, patches will not be a standard way to contribute anymore. It will all be in merge requests. And so, you know, that's something to move forward on. And also, as I said, GitLab CI as of today is available for every project on Drupal.org. So in the contrib space on Wednesday, you can spend some time setting that up. And there will be folks from those sort of 20 test projects that first helped us figure this all out available to help you. And perhaps once you've got it figured out, you can help someone next to you get their project running on GitLab CI. So with that, we have about 10 minutes left. And I believe we're ready for question and answer. So if you would like to ask us any questions about Drupal.org, about GitLab, or about kind of the history of keeping Drupal running behind the scenes, feel free to come up to the mic. Ask any of those questions. And if you don't have any questions, well, thank you very much for 10 minutes back. But I'll give it a minute or two for anyone to jump up. Hi, thanks everyone for the talk and all the hard work. It's amazing to see the GitLab CI stuff go live for everyone. I'm curious for that work, is there a possibility, or even maybe there is a way already, for contributors and maintainers to run tests locally when they're working on their work to identically replicate what GitLab CI is going to run when you push up your... Yeah, GitLab has some tooling for exactly that. I don't remember what they name it or how they brand it offhand, but they have run GitLab CI locally. Yeah. And so as far as... As far as we know, that should be possible today and that might be a great thing to try out Wednesday in the contrib room and let us know if perhaps we've overlooked a config feature that might be necessary to support it. But as far as I'm aware, that may be possible right now. Awesome, thank you. Any other questions, thoughts, feedback, special requests? Well, if not, thank you very much for your time and attention. Thank you especially for your support of this very small team, trying to do a lot of things with the Drupal.org infrastructure and trying to enable you to move faster in your contributions. There's also a lot that we have kind of learned and explored supporting a project of this scale. So again, if you wanna find us later and chat a little bit about CI for an enormous project or Pulumi and Rancher and a bunch of keywords that I maybe have not heard of, I'm sure you can ask us those questions as well. Oh, and it looks like we do have another one. Yes. Do you need the volunteer help to get this project to go back? The question was, can volunteers contribute to getting sort of any of these different sorts of projects done? GitLab in particular maybe comes to mind. Yeah, depending on people's expertise and what they are interested in doing, there are ways that you can help. There were, like I said, there were about 20 volunteers who first migrated their projects on an opt-in basis to GitLab CI to help us figure that out. There may be other sorts of things like that. So again, I'd look out a little bit for a table on Wednesday and then in general, in terms of supporting Drupal.org on a volunteer basis, Neil, maybe you had some comments on that. Yeah, so I, with GitLab CI, those templates are brand new. There's gonna be a couple rough edges. So helping improve the templates themselves also will be key and really that's something we hope the community can run with and we don't need to be responsible for maintaining those templates ourselves along with the containers they're backed up by. Yeah, we can't move everything to kind of standard containers since Drupal supports a lot of things, a lot of environments to run on. And yeah, for general, like Drupal site building, we have dev sites so that's available and yeah, there's opportunities depending on what you're interested in. To go into that in a little bit more detail, if for example you wanted to, you had a great idea for a feature, actually an example of a contribution that we did have that came from the community was the ability to set your pronouns on your Drupal.org profile. A community member requested in the Drupal.org issue queue to have a development site made available. They built that feature and they sent it back to us and said, hey, can you review this and deploy it if it's ready to improve Drupal.org? May I ask a follow up? Yes, please. Okay, that was in built for Drupal 7, right? It was that particular feature. And is there any opportunity to do volunteer work to in Drupal 10 for Drupal.org? Let's see. So, you know, the localize, the people that are on that slide, they're all doing that. And yeah, api.drupal.org, I don't know, probably needs more time. The API module itself, I mean api.drupal.org, it's 99% one country module, 1% us doing some site building. So, there is a huge opportunity in there. There's a lot of testing people are opening new issues that people are actually submitting new patches. There is even an install script for you to like have a API site running locally. And then you can test it with pretty much any contrib module available. And then, yeah, you are free to submit any issues. I will most likely get the notifications or any of us will review and yeah, be able to, yeah, allow you to do it. Yeah, and for Drupal.org itself, we do have a repository with the code base on Drupal 10 or nine somewhere, but it's not, we haven't had time to look at it lately. So, I don't know, last time you touched that, but yeah, it's not quite inactive development yet, but it's moving in that direction. I would stick with the subsites and the GitLab work for the moment for areas to contribute and we'll continue to post issues with the plans and places where people can become more involved. I'm a big fan of the tugboat support that's rolled out on Drupal.org. Yes, true. For projects and I feel like not enough projects and maintainers, many don't even realize that that's available. I'm curious about ways that we could highlight that or even I was thinking about it when you were showing how the GitLab CI template and how that's configured to be added through the GitLab UI, is it, are we open to the possibility of things like that of allowing like the ability to add a tugboat template in that way? You know, that's a great question. There is a project, Drupal.org slash project slash GitLab templates and right now the main template it has is a GitLab CI template, but there are absolutely other third party tools that need a CI, that just need a YAML file to get them configured like tugboat and like others. I personally would be open to, yeah, someone opening a merger quest saying hey, we'd like to help people use this third party tool, that third party tool. There's also some integrations built directly into GitLab that at some point we might enable. There's a Gitpod integration. I don't know if it does everything we need to do the full Drupal pod experience that some folks are used to yet, but I think that's something we should work on. Great, thanks. Awesome, any final questions? Feel like every time I start it, someone jumps up to the mic, so that's why I gotta ask again. No, but again, thank you very much. We really appreciate your support. We appreciate your interest in this kind of very behind the curtains, very technical kind of content. And understanding that what it does is it feeds the ability of you and everyone out here at DrupalCon and around the world to actually make these contributions to Drupal to try and make those innovations we talked about and Dries' main stage really happened. So we appreciate just that this moment in the very bright spotlights to tell you a little bit about what happens behind the scenes, and we appreciate your support. So you'll see anybody on here on stage around throughout the conference, again especially on Wednesday during the contribution day. Feel free to say hi, ask us more. We're happy to go into details. And thank you again and enjoy the conference.