Drupal.org Engineering Panel

This talk provides an update on Drupal.org, focusing on the engineering team's efforts to build tools that empower the Drupal community. The speaker discusses the significance of funding for infrastructure, detailing the budget breakdown and financing sources, including community donations, trade, and partnerships. Key initiatives such as the site template marketplace launch, recent infrastructure migrations to AWS, and upgrading the Drupal documentation process are highlighted. The importance of transparency in funding and operational challenges faced by the nonprofit Drupal Association is emphasized, along with ongoing improvements to project management and issue migration to GitLab. The team is committed to modernizing Drupal's infrastructure and enhancing community tools to ensure the platform's relevance and sustainability.

Okay, I think it's time for us to get started. You will notice our generosity in providing a table for every attendee. Thank you very much. Thank you. Thank you. Thank you. Um, no, I appreciate that it is the last session of a long day after a very fun gala and makes it a little tricky to still have any energy towards the end of the day. But appreciate

you being here. Appreciate you taking an interest in drupal.org or itself, the infrastructure that runs it all and the way that we build tools for the community. Um, so this is the Drupal.org update panel and it's all about building those tools which empower the community to do everything that you do while you're here in contrib room um that let us put on Drupal Con. We are the

501c3 nonprofit that supports the global community. We cannot do it without you. Um, I'm going to introduce the team. Some of us are here, some of us are not. Um, I could not be here today, but myself, Tim Lennon, Hestinet on Drupal.org. I probably know all of you by name, but um, you you um, I'm just here to really lead this engineering team, the CTO of the

Drupal Association, and the team that says that, you know, kind of our personal mission is to build the tools that help people build Drupal. Um, I'll hand it to Neil next to introduce himself. >> Uh, yeah, Neil. Uh I think my title is senior technologist but I I'm the do a lot of the architecting around our Drupal sites site building. >> Yep. And I'll introduce some of

the folks who aren't here. So B man Brendan Blaine um has went been with the Drupal association more than a decade as have most of us at this point. um and is often behind the scenes doing the crossmental cross departmental support for things like the events website, the other the fundraising team, partnerships team, all this sort of stuff behind the scenes and uh friend Garcia Lenares um

who is uh also a senior Drupal developer who's been working on feature development for all sorts of things across the site. I'll call out some of their work as we go. We've also invited our infrastructure partners from Tag1 Consulting to join us uh in this conversation because they work on some significant and important projects including just keeping the whole thing online. Um so Nan, I'll let you

introduce yourself. >> Sure. Uh my name is Nan Newton and um I also probably know everyone here. I've been the lead assistant for work for over a decade. Um newly >> two decades. >> [laughter] >> And then in the audience is Max. I actually have help now, which is shocking. >> Incredible, in fact. Um, so I'll kick off the conversation with talking about funding the infrastructure. This

is a topic that you've probably heard us say in several different places. There was a version of this presentation in Vienna. I've added another layer of transparency to this conversation. So, I'm speaking now also to the people watching the recording uh about this. Um hopefully that information helps you understand a little bit better what we do. Um you also saw a recent blog post from Drees, the

product founder uh the project founder about what it costs to run Drupal's infrastructure and a little bit of the background there and how the challenges that we face mirror the challenges of pretty much every open source project out there. um everything that's been there and there's been a conversation that has moved from the controversy that occurred in the WordPress community um in particular when the founder over

there decided that he would effectively sort of take legal action or take technical action against one of the major WordPress hosts and all the kind of cluffle that did on the on the grounds of them not supporting that project enough. That was certainly one route to choose. Um there was a group of folks there who then spun off and started the fair project. The fair project being

a sort of independent distribution model for distributing WordPress packages. And they recently posted, well not all of them, two of the folks who were involved in that recently posted that they were stepping back because having responded to what felt like the wrong way to do the solution, they came together to build what felt like the right way and nobody stepped up to pay for it. Um, so

they kind of ran head first and it was a very interesting and provocative post where among other things they said maybe the bad guy had a point. Um, so we're hopefully not in that position but we're we're going to talk about some similar things and how we think about it in the Drupal space. Um, so Dre has said right um his goal is for Drupal to remain

relevant for years to come to continue to grow adoption and to find a sustainable model uh for continuing the infrastructure that we need. We've used a chart like this before to talk about to break down engineering funding sources and engineering expenses in different ways for the Drupal Association. There's about $3 million in engineering uh or general infrastructure related costs that's part of the Drupal Association budget. It's

the largest part of the budget. Um, so what you'll see in activities, there's about in the $700,000 range spent on the uh staff plus the associated expenses, payroll, taxes, benefits, all of those sorts of things. It goes together with our very small team. You saw them all on the slide before. There's infrastructure costs themselves. Uh this is combination of servers, SAS services, the pages that wake us

up at night, all of these different kinds of things that bundle all together. And there's a set of unfilled expenses that represent the technical de debt and deferred maintenance. So whenever someone at Drupalcon comes up to me and says,"Wh haven't you done X yet?" That's that bucket um of those things that we simply have to push to back to the back of the list because if they're

not actively on fire, we can keep working on some of the other higher priority items. Um I also do want to point out where the funding comes from. So this team themselves and you know on top of what our partnerships team does, but this team by themselves secures 1.2 million of that in in trade andor donations, right? So we more than pay for our staff cost and

for a significant part of the infrastructure cost depending on how you want to think about it. Um the community funding and community funding here means sponsorships and professional funding from uh partner organizations and conference ticket sales and all these things as well as individual donations from ripple makers and people supporting us that way represents about a million dollars. So by itself not enough to cover the infrastructure

but together with what we can get in in kind trade and everything else allows us to do what we do. Uh, and then there's that unfunded bucket, um, which would let us do a lot more that we would like to do in future. Taking a little long on this part, so I'll try and speed it up a little bit. We often think about this as, um, $10

of expense for every modern Drupal website that's out there, right? Those same numbers break down this way. Uh, those $10 that we spend annually for each of the modern Drupal sites that exists are broken down into revenue, inind support, unfunded technical debt. Those revenue sources are partners, members, sponsors, grants from time to time, Drupalcon events, etc. And [snorts] inind support is really, really important to us. Some

of that comes from folks who provide Drupal services and offer them in kind to us. Tag one being one of those partners through which we have an inkind trade agreement that really makes it possible for us to do some of what we do. And then other negotiated partnerships with various sorts of of vendors and providers who believe in open source and are willing to support us. Um

the unfunded stuff you see evidenced in projects outnumbering our engineering team the places where the 80% of something got done the 20% didn't etc etc. So just some key takeaways again I just want to emphasize the engineering team themselves ourselves offset twice the cost of our staff positions with these income trade and gratit services without touching the community money and all that community money that you provide

goes in directly to like supporting the test bots and covering the hosting of GitLab and all of those other sorts of things. So all that support you provide is really really important and anything we can do to enhance that we try to multiply every dollar that we receive. Um so um yeah the combination of all these other sources in community funding would cover about 30% of the

total cost or about twothirds of just the infrastructure alone in its current state. So one thing that I want to say people come up whenever there's these budget conversations are there ways to cut costs. Could we get cheaper hosting here? Could we put get servers here? Can we do more with less? At this point, there's no more blood to squeeze from that stone, right? We're a nonprofit

organization that has been operating in a nonprofit way, uh, running a break even budget for years. Um, sometimes a little bit less, sometimes a little bit more. So, that's some background setting. I've been asked to be transparent about that and about kind of the the details of things here. So, I've broken this down. I won't go through everything because this whole this is not supposed to be

a whole session about our finances but I have been explicitly asked about uh providing some more transparency. So again total budget that we actually have plus the unfunded expenses is how we arrive at that $3 million number. Um engineering positions uh it was five at the time. This comes from our 2025 budget. It was reduced to four last year. The associated benefits uh infrastructure pure server costs,

domains, DNS, etc. Seeing these sorts of things, software subscriptions for IT stuff like password management, all this stuff. Some of these things, yes, there's nonprofit discounts, open source discounts. We pursue those wherever they exist. Um professional services is we need to occasionally outsource work to a Drupal shop to get something done for us quick. um or something done for core um or something done for the auto

updates initiative or whatever the case may be. Right? This is a 2025 snapshot. This is the greatest services where that 1.2 million in negotiated um supplementary uh support comes from uh in as much detail as I I can give in a public presentation. So, just wanted to share all of that. Um, and what we would like to do with some of those unfunded things, mostly positions that

we'd love to have on the team, capacity expansion and things like that. So, that goes through the painful part of the conversation and the the the plea for support, but also the request that you share that information, refer back to this recording when you hear from other folks, maybe people within your organization, well, what does the DA do really? or where's all our money going when we

sponsor, right? Like here's a good solid answer for for a lot of those things. And I'm happy to talk one-on-one with anyone about that. But we've been doing some really cool projects recently, too. So, you saw in the Dre note that we launched the pilot of the site template marketplace. This is the sort of beginning of the um uh and this session occurred on Tuesday, so it's

already done and gone, but you can go back and check the recording for more detail. uh where we spoke to some of the first partner participants in building the original site templates got their experience of working with CMS canvas the site template architecture uh working with Adam Honik uh working with Pam on all of this process um and it's kind of a a bit of a transformative

new thing here um there are things that we're going to do more with site templates I'm not going into them in detail because there is that whole session to refer to but we're hoping in the July time frame to um launch the round two set of templates with more automated support in reviews with better installation support in Drupal CMS with uh license management and commerce solution that

we can provide rather than the individual vendors who want to go premium providing them themselves etc and then by Roderdam uh to see if we're ready to really double down and go full general availability for applications and things like that. So if you happen to be someone who is interested on an organizational or individual level in building site templates, there's an application process that's open now. So

we'll talk about community and contributor features. Um Brendan on our team unfortunately fell very ill and was not able to make it. So I'll talk about some of these and maybe uh Neil could you take a couple of these as well. Um, so minor ones were uh just for this event adding a new digital birds of a feather schedule so that that you've been using throughout. There's

a few bugs we know we'll get them fixed. Um, but the that's hopefully been helpful to you throughout the event so far. Uh, an interesting one though is Doc's code and more features to submit to support that. So Neil, if you would. >> Uh, yeah. Uh, one of the uh, things people have been asking for is uh, doc's code. We've had uh, GitLab pages uh, for a

while uh, available, but that's not really integrated with google.org. It won't show up in the site search. It won't uh, harder to edit uh, since it's marked down. the repository structure for this is is really quite quite straightforward. There's a docs directory within any project repository. Um and you can use um what's called maked docs material which is the original gitlab sort of recommended markdown solution to

commit this code. There's another option called zensle that's coming around. Uh so this shows the zensle kind of repo structure. This shows the traditional maked docs material structure I believe. Um and then yeah where you can learn more. So if you again Neil would talk a little bit about this. Uh yeah the uh gitlab templates project is uh where we have both uh this uh these jobs

and the uh you know general Drupal CI jobs. So >> yeah get that pages. >> Yeah. So if you'd like to switch from wikiedit documentation to version control documentation um that is the information to get you started. The other thing I will add to that is there's a feature still sort of work in progress to create a um uh what's the way to put it >> birectional

editing. So >> thank you. >> Uh yeah that part uh we'll be able to import that documentation if it's sensical into drupal.org itself and have a suggest change button. Uh so you change the markdown and then it will create the uh an issue on your behalf and then a work in the merge request. So go through the whole review process, >> right? >> So kind of bringing

some of the wiki functionality that we've had with the CMS back into DOC's code. >> Yeah. So developers have been asking for a long time to have version controlled docsis code and pages publishing, but we didn't want to leave behind regular editors who can make meaningful suggestions and improvements to Drupal's documentation. And so automating that whole merge request creation process for people who've done this uh is

another project that uh Brendan in fact has been has been working on uh quite a bit. Um also I mentioned cross departmental support right we're the ones who launched the Drupalcon websites the uh landing page for Orlando all of these sorts of things. So that's there. And we also manage the contribution credit system for the whole community. And there's recently been an increase in credit for certain

key roles. Community working group members, the Drupalcon global executive committee, advisory committee, and association board members are all getting uh significant boosts because we want to recognize that just the sheer volume of time that they invest in what's going on. And also we've added credit to a variety of more parts of various strategic initiatives. So there are sub projects that are parts of the AI initiative or

various other sorts of things um that we're incorporating into this as well. Um one of our recent major projects though has been an infrastructure rebuild and migration. I'm going to hand it to Nion for this one. Um we [snorts] were sort of under the gun with with a little warning, maybe a longer countdown, but I'll let you go into the history and and and the details here.

>> Yeah. Um, so we've been working on modernizing Drupal works infrastructure for a while, but it's been tied to new sources and migrations. So we had two infrastructures basically and everything new went on the new one and everything old stayed on the old one. Um, and if anyone's done that before, basically what that means is all focus ends up on the new one and everything on the

old one rots on the vine. And that is what happened for the most part. uh things were going along and then we kind of hit a forcing function recently. most of Drupal or historically is run on physical servers such as the OSL. We started moving to AWS when we were expanding CI and testing because I don't know how many people know this but our CI and testing

runs on absolutely gigantic VMs. I I in other areas of work host very large events and still rci spins up the biggest VMs I ever deal with. It's insane. Uh so we use spot instances for that and that was our first major usage of AWS. We lift and shifted uh gitlab git. Drupal code um before Drupalcon when it was starting to pretty significantly fail on the hardware

that we had available at the OSL uh and be slow and it was just more central to development. we're using more of its features and it required more resources and then all of our new deployments that are being deployed on Ketty's EKS uh for standardization and ability to scale and ability to deploy in hybrid cloud eventually. So the new platform we're very much eyeing being able to

split across and expand into AWS but not necessarily be tied there. And then this happened. Um, >> Oregon State's data center is the CUR data center or was the Kurr data center. Uh, that's where I used to work and it's old as well as our hardware. >> Let's I'm going to interrupt you for a second to talk about how old this is. So Dre has um Dre

has told the story uh a number of times about the uh his personal computer melting down in the early days of Drupal because it suddenly spiked an interest, right? What happened from there is he put out a call to figure out what the heck am I going to do? Sun Micros Systemystems donated a couple of servers and you have to put those servers somewhere and this institution

Oregon State University had an open-source lab and you found projects like Drupal like Apache like a number of the very early open-source pioneers all in a studentrun data center sort of in racks right next to each other and that's still been true and is still true for a lot of the the infrastructure up all until all up until this point So I think that's really important and

interesting history. >> Yep. Uh and some of those servers are still there. Anyway, those servers themselves were starting to have issues. People may remember that there was a major outage around uh like holidays Christmas break. My wife really loved that one. Um and it's both side like HA does not work if both sides of the cluster fail. So that was happening. And then the cur data center

itself stopped being able to be fixed from a power supply and power distribution and power backup perspective. So they were migrating and they're migrating to a bigger better run data center. What that meant for us is that we were scheduling with them something that could have looked like a 10-hour outage as the rubber met the road metaphorically and physically. um they needed to literally tack up servers

and move them. So we scheduled heavily with them max put in a huge amount of effort and we decided to move the legacy Drupal to work sites because currently we have new deor legacy or classic Drupal.org um and we moved that into the new state. So converting it to containerization of conser converting it to a home chart site itself. You could do that in a few days.

But Drupal.org as a whole is the updates infrastructure, the FTP infrastructure, the signing packaging pipelines. We have a gigantic Jenkins instance that's terrifying. And now we have Argo workflows that are equally terrifying but versions. Um, and so we got that done and moved barely. I think we got it moved on a Friday and debugged it over the weekend and then the servers were physically moved that Monday.

Uh some of the subsites took a hit. Uh localizing shops for example went down for the physical move but the main site packaging signing all of that were up during the move. >> I don't want to steal your joke but you made a very funny remark about one of these servers during the move. Do you remember this? >> No. Um [laughter] uh just the remark that uh

at at during at the midst of this move somewhere between Corvalis and Salem some of these servers were the fastest they've ever been 65 miles. [snorts] So now we are more and more in AWS. The general goal is to turn around and rebuild the OSL stamp because some things don't make sense to run in AWS from a cost perspective. That gets complicated within kind and stuff, but

still we're going to turn around and do that. We could not rebuild it in place. We don't have service for it. So migrate and then turn back and move some things that make sense to move back to the OSL but on a Kubernetes platform that we can deploy to each or have a dev environment OSL and then deploy in stage of AWS more of a hybrid cloud

platform. Um we are using their managed services for things like database. Uh we are switching from a really old repository to a mix of anible and plemy. Uh we have a GitLab geoccluster which is probably going to be our next focus uh but currently it's running omnibus on very large VMs and then we are now heavily using Argo workflows which is replacing the pipelines that were in

Jenkins with something that is not better but is version controlled and auditable and produces logs. It's a >> all those things are better. >> Yeah, it is in itself, it's not better. It's better to look at. So, in general, we're moderniz modernizing. Um, I've been talking about that for years at this point, but it was actually forced to happen. Sometimes that has to happen, especially in a

nonprofit, especially with a small team. Um, so we are on a much more modern platform, much faster platform. Uh, we skipped eight years forward in Maria DV versions. We skipped 10 years forward solar versions. Uh we've replaced Mailman 2 with three plus full text full text indexing. I don't know how many people noticed that, but you can actually go to list.org and get something besides mailman 2

and search the archives back to the beginning. Uh we have rolled out some things to make this easier on us. Uh we have renovate a tool that basically autocreates PRs for us to move our pinned container digests forward. So we all of our software is deployed in a way that the specific version of that software is pinned so we don't get things updated underneath us and then

PRs are open for us to automatically move that forward so that we see them but also also it nags us. I get a lot of we all get a lot of emails from renovate nagging us to keep things updated which is a lot better than what it was in the past. Uh we are going into autoscaling now that we can uh legacy autoscales. When this conference started

it scaled up and has been scaled up ever since uh and is a lot faster. Uh it was struggling and now it's struggling with more hardware. >> Very good. So this is all the sort of underlying the skeleton the skeletons that were in the closet and then were loaded into the back of the van and moved to another closet and now some of the skeletons are in

the cloud. All of those things um that we used to build drupal.org but when we talk about drupal.org we are talking about multiple properties right we are not talking about a single website that is the homepage for the project. We're talking about a lot of things. So I'll hand it to to Neil here to talk a little bit about everything involved. Uh yeah, so works multiple sites

and uh we're in the process of upgrading and replacing those. Uh so yeah, these were all Drupal 7 at some point uh groups that never made it to Drupal 7. Uh so in the last couple years, events.gruple.org and and API were just rebuilt from scratch on uh modern Drupal uh association.org that was a small website just for the Drupal association we realized it was more it was

not worth it to maintain it but that was a separate site so that was moved into merged into drupal.org itself uh I'll come back to drupal.org itself uh security.ruple.org that's uh in the process of being merged into both drupal.org and uh GitLab localized uh some volunteers are uh making progress on that. They have a uh pre-production and a draft of that uh they're uh finding bugs and

fixing them. Uh jobs uh we'll figure out what to do with that later. We have a job for it. [laughter] groups uh there were some discussions offer earlier today. There's people motivated motivated to help us merge that into drupal.org itself and uh get that code uh code.org is uh our self hosted gitlab instance. this is kind of the same. >> Yeah, it's kind of the same. uh

for uh drupal.org itself. Uh yes, it's a big website. Uh yes, it's hard to migrate. Uh so we're doing it in phases. Uh so the same website's also on new.ruple.org. Uh and in the background, there's actually a lot of migration that's done. Uh that uh is kind of preparing for the next steps of uh let's let's make sure that data migrated okay and start showing more content

types on the job.org itself. So content type by account content type uh we built the system for landing pages uh ahead of one of the Drupal cons uh uh so those are gradually moving uh be great to rebuild that again on Drupal canvas someday uh and functionality bit by bit like recipe browsing and the sites template marketplace those were built from scratch on uh uh new.org The

reason it has to be two sites is there were uh paths like admin node uh I think system ajax was like kind of like that's like okay we shouldn't try to hybrid host this on uh seven and 10 at the same time uh on www.pool.org. So we have to have a separate subdomain. When we're done migrating uh we'll switch everything back and be drupal.org to ww.upruple.org. So

think of it as the one website with two URLs. >> Awesome. Um we've also been working on issue migration. So you know the great developer tools initiative that's been going on since technically 2018 in multiple multiple phases. It went from evaluation to where we would do repository hosting to where we would do CI to eventually now we don't we don't want to continue doing hybrid issues and

and the system we want to move issues as well has been a major major project. Um Fran who's also not able to be here with us today has done a lot of work on the process of moving issues to GitLab. Um, one thing I would say it's always hard to call something done, but sort of the fundamental feature development part of of the migration to GitLab is

effectively done and we are now in kind of the migration and opt-in mode, some validation mode. There's a few pieces there like some custom work that's done around the security migrations in particular, but um so issues continue to migrate to GitLab because some already have a lot of the Drupal Associationowned projects have already been migrated and are using GitLab issues. Now uh we have a big optin

issue um for a bunch of other projects. The AI initiative is on the list to move a couple weeks after we get back from Drupalcon with a big old list of the sub projects that are part of this. Um, but some things are still not changing. Some things are still fundamentally part of drupal.org. So project and releases will continue to stay on drupal.org. So the project home

will still be the drupal.org page and release management will still happen there because that also allows us to manage packaging to put things in our packages endpoint for composer all these other kinds of pieces that are very very important. Um, you've already seen CI and merge requests uh have have been over for for years now and had immediate improvements and all sorts of customizations and some really

cool inheritance of central configuration that gets pushed and available pretty much automatically to contrib whenever they want to to use it so that you don't have to be a CI expert to do your testing. We did have to decouple issues from the site itself to for those issues to exist. So issues used to be entity referenced into change records, related issues, parents, um counts and summaries, all

these kinds of things. Those have all been extracted so they don't depend on being the on the same site and either changed to regular like full URL links or other kinds of things like that. And we fully rebuilt issue credit so that it can still work with an external system because that's been central to the in incentive structure of Drupal and encouraging companies to sponsor developers to

keep contributing. Um so you've probably seen this if you've worked in any issues. You've seen the new the new UI um that works both with your if you're still on a project with the old issues or if you're on a GitLab issue project. One of the many different kinds of things that you'll see as things move over, as your particular project moves over, is all the historical

meta. Well, first of all, all the historical issue information for project is migrated. We don't throw it away. Um, so that information gets migrated over. All of the metadata gets migrated over as labels. Those labels are managed by that project maintainer. So, you're allowed to um use a different set of labels in the same way that you could customize your own components on your old old issues,

all of those things. Um, and you get a bunch of new features like using the canban boards, issue boards as they call them, various other things that are built into GitLab as that goes. Um, so again, a handful of projects have been migrated, migrating every issue, including the closed issues. We've had a couple edge cases that we've been catching along the way and fixing, which is why

we've tested with our own projects first and managing things like race conditions between the queue for the issue migration running and when various things actually get saved and [snorts] happen. So, um, notifications are one of these things, right? As we're populating issues in GitLab with all of the old history, we don't want to renotify every single user of everything that ever happened, especially because some of those

issues are just about old enough to drink. Um, so yeah. Um, so we've had to do a couple different things there. Unfortunately, it's not super easy within the tools that GitLab gives us. So we've had to work around that a little bit. Anyway, ongoing from there, we'll be migrating the more projects that have opted in, make it the default for all new projects, starting with lowrisk stuff,

etc., etc., etc., um, and eventually the rest of the projects, including core. There will come a time when we simply ma mass migrate everything that's left. we will probably choose that date based on our discussions with the core team about the date for doing core um because that's the point at which moving issues between projects suddenly becomes difficult when they're on two different systems. So we'll probably

coordinate that with when core moves. Um so yeah um there's a lot of things uh that you could potentially do. Um there's with the issue migration there's a plan issue about it. you can opt in to have your project be one of the ones being migrated early, etc., etc. Um, I mentioned earlier earlier that security issues are a special case, so I'll let Neil talk a little

bit about the extra work that goes into moving security.org into GitLab. >> Uh, so yeah, our security site was uh kind of the same stack as drupal.org uh uh projects and issues. Uh, and you know, we want to completely get rid of uh uh the Drupal issues uh that go around it. So uh so we're just not maintaining it. Otherwise, GitLab is twice as much work. Uh

and GitLab comes with this little turn on confidential confidentiality check box for uh for every issue. Uh so it's a great place to uh report security issues. Maybe we'll even get a better uh rate of people uh I will probably get more people miscatategorizing things as security issues that aren't security issues but it's better than another way around. Uh but you know we need some customizations around

that. Uh these are per project. So the maintainers are notified security team and we want the Drupal security team as a back stop for uh you know if maintainer doesn't uh proactively get uh fix a security issue, we find a way to triage it and uh either get new maintainers or uh you know make clear that the project has security Uh so some of the integrations we're

doing are uh the uh when we finalize security issue, Drupal bot will make a private fork primarily for access control, but that also gives us uh private branch and merge requests uh to collaborate on any fixes that that are needed. Uh add some context about the security support and advisory process that security adoptable.org had and and uh you know from there the maintainers and security team can

both begin triaging uh and has have some automations uh slashcomands for managing access. So uh especially on core issues we'll bring in the subject track manager matter experts and only the specific maintainers for that subsystem uh or you know for contra if there's a pattern over a few different contra modules sometime sometimes we'll have them collab uh related maintainers uh and the advisory drafting security advisory drafting

that moved to got other upgrades in the group in the process of that [snorts] and we've been using the GitLab triage bot to uh kind of bi-weekly reminder certain reminders every picked uh for certain issues. >> Awesome. Uh so with that we move on to question and answers but this is pulling the curtain back on a lot of the things that people maybe don't fully understand about

what goes into maintaining Drupal as an open source project at the scale that we are. we continue to be much larger than a lot of other open source out there, right? There's um [snorts] it's interesting to me because there's a u there's a version of the open source program for hosting your project on GitHub or hosting your project on GitLab and they're like what's your repository as

if you have one. There are 60,000 Drupal repositories. Um so like you know the understanding of scale and of the necessary infrastructure required to support it is is not always there. And so we like pulling the curtain back. You may not find all of these things super sexy, but hopefully you find them interesting and you kind of understand what they're for. And if you do find them

super sexy, good on you. Um, but yeah, we're happy to take questions. Um, perhaps it relates to the infrastructure that you want to run. Perhaps it's about what you'd like to see going on on drupal.org. Anything in the back? Jess, >> I feel correctly that project maintainers are now going to have to add security. instead of the opposite current. >> So let me repeat the question. Um

so the question was will the project maintainer have to add security team members to a reported security issue? Neil >> uh that's what it would have been if we didn't built the automations. >> Okay. the automation the automation will not be on either maintainers or maintain that >> correct yeah so the so the automation makes sure that all of the people are tagged in without having to

figure out if someone's in Fiji when they need to be responding to this issue >> so the health that was on it said security issue. That would be a lot of people without >> uh yeah I mean that's uh that is how that works. Uh that's not something you can control and get loud. >> Yeah. So there are there are some limitations there. Some of it is

like bear in mind that we are it does create uh private forks and projects. So there's some access control stuff you can do because it's not just the parent >> but the initial report >> yeah the initials >> possibility is very different from offenses and that >> yeah so uh one question might be if we can map those to a different if we can map the people

who have those roles for that purpose right now to a different lower privilege role because they won't need it anymore if the issues are there if certain things are different so we'll we'll have to find it out but we are limited to the feature set that ships with GitLab it's you know as we say in Drupal we you don't hack core and we can't hack core in

GitLab but we also can't write modules for GitLab uh they don't have an extensible plug-in system. >> Matt was an idea about using to manage that explor what's you know [snorts] the process of making a friendly user experience or using those bots to provide more access. Neil Neil has been working on a number of these things with that Drupal bot automation and some some there's already private

security issues happening in GitLab. So some of the security team is already experimenting and able to see some of these things. So both inside and outside of the security context the Drupal bot is providing some some helpful features some extra slash commands. Uh I don't know if I have the specific details but would you like to add anything? Yeah, I mean we don't have anything specifically planned

for core uh mostly because we haven't done discovery on what is needed but a lot of uh and actually already core has been more empowered to uh build their own uh automations. So uh one of the core uh core maintainers uh built something retargeted all the branches uh when uh for merge requests uh when uh the main branch before it was opened. So, uh yeah, both core

maintainers and every project maintainers more empowered to use GitLabs APIs and automations and uh yeah, we'll certainly look at places where it makes sense to uh do something special for core on drupal.org. Uh and yeah, that'll be something to discuss in the future. >> Yeah, go ahead, Matt. Is there a slash custom slash command for or is there planned to be a custom slash command for updating

issue description summary? >> Uh so the question was a custom slash command for updating an issue summary. Uh I'd say no because that's a be terrible UI. Uh the custom slash commands don't have uh like nice autocomplete uh for uh if you start typing slash uh gitlab issue, it'll come up with a menu of here's all potential things. Uh custom slash commands are not discoverable at all.

Uh and then uh let's say you do discover it if you're editing issue uh you know how There's I imagine there's a lot of ways to uh make mis you know small mistakes when copying and pasting things around like what's the spacing what's the markdown and like do I put the comment above uh above or below the slash commands does that make difference so yeah kind uh

that uh sort of thing uh the a comment a text box for a comment It's not a good UI for that. Uh what we could do is build UI on drupal.org and that's kind of what uh GitLab has done uh for if you want to contribute to GitLab itself, they have a contributor platform lives alongside GitLab. They didn't build GitLab themselves uh for things like relabeling issues

and I believe they might have some issue summary editing. uh their use case is a little different than ours since uh uh you know we have contribution credit they have if you fix enough issues like itself you get like a git getlap socks uh time for another question maybe two or else we will wrap here well thank you very much for your attention I really appreciate it

I hope you'll help spread the word about what all of the investment from the community and from the team within the DA goes into doing and accomplishing for the project. Um it's really a boost to our spirits when there's other advocates who kind of understand a little bit what's going on. And otherwise um we'll see you in the contr space. We'll be there to support you. We'll

be there to make sure uh that you can actually get in and make your contributions. Uh hopefully knock wood it'll keep going well as it has gone all week. So yeah, thanks very much everyone. We appreciate your time. >> [applause]