Talking Drupal #502 - TD Cafe #001 - Martin and Jake

Martin: I've ended up as maintainer on a bunch of other things. But yeah, there are a few that I actually sort of created from scratch and, you know, I feel like as a maintainer, I feel a different level of connection, responsibility. All of those things. It's not like, you know, they say you should love all your kids.

Martin: The same, I feel like with contribute projects, there are certain ones that I care more passionately about than others. And I think that's just, you know, the, the nature of inheriting some modules and developing others from scratch as well as, you know, just some that, that come out of passion projects and some that are just, you know, code that you needed to write to solve a, a particular problem on a project that may have ended years ago kind of thing.

Martin: Do you feel the same way with your projects? Yeah, yeah.

Jake: I, I, I like that I, you're bringing up the, like there are different types of projects we contribute and I, I almost feel like we should just [00:01:00] have the conversation of quantifying them. 'cause I think they're kind of fun to do. I, I will say that I love that we have sandbox modules.

Jake: I use them all the time. I will put personal stuff up on a sandbox just 'cause I'm like, well, I need a place to store it. It's on Drupal, people can get to it. And I'm familiar with the process and you know, it's easy to track. And those, I never expect to go anywhere. And then, yeah, there's work projects where you put up there where they just need it.

Jake: You're like, well, it should be, it's generic enough. It should be on drupal.org. You'll benefit from the automated test and the upgrade pass and stuff like that. And then, yeah, then there's your passion projects, which you brought, like Webform is definitely a passion Project form was, and by the way, I need to say was a passion project.

Jake: And now schema.org blueprints is a work project that I'm contributing a lot to, but it's totally driven by work. Like I, I mean, I think one funny thing is we're both passionate about our coats or whatever we do. There's a certain amount of ourselves in there. And yeah, you bring up, and I don't do it as [00:02:00] much, but the inherited project, I would call it like where you just, 'cause you're on drupal.org, you're like, you become the maintainer of something defacto 'cause you need to do an upgrade.

Jake: Are there any other projects you could think of when you're.

Martin: I need, I mean, I have a certain number of kind of like, shim projects where it's almost like I debated about whether or not it really made sense as kind of its own thing, but it was almost like there were as an example, I've got one that basically creates a different cache context for, I think it's certain aspects of the user profile.

Martin: And I, it just so happened that I was wanting to create two modules that needed the same, and so I was like, do I, do I just copy the, the same class into both projects or, you know, like the right thing to do is to sort of make that its own standalone piece, and then both projects can depend on it. So it wasn't really like, you know, mm-hmm.

Martin: That [00:03:00] one thing was you know, I was inspired to create it in its own right. It was just one of those like, well, it kind of makes more sense to, to make it a standalone thing. And then the irony is that that piece has actually now been used more than either of the other two that depend on it. So it's like, well obviously there was value in releasing it on its own.

Jake: I mean, I, we could quiz me on this one. It's just a funny, there's like different types of scales of projects. Like, like you're describing an API kind of, I don't even know what the module is, but it's like an API like it does one thing, does it? Well, you put it on drupal.org, people could use it, not use it, it's used by other projects.

Jake: It can have its own little life. And then you get into, you're solving a problem, which I think smart data and web form are definitely. In that realm. And, and there's some irony, like something that changed in the last 10, 15 years with Drupal is I see no issue having lots of modules enabled. As long as you know what they're doing and they're doing something and doing it well, it's not like you get a performance hit.

Jake: And that makes it easier and contribute to create small little, like what you just [00:04:00] brought up. Like well extract this into its own thing that other people could use. As I'm saying that I'm contradicting something I, I am guilty of doing in the community. I'm probably the worst person at it, is I do a lot of submodules.

Jake: I like submodules, I like small things, but I don't like to maintain, I could maintain web form if I had 40 sub modules out in the community trying to keep them upgraded at the same time. Like, I, I, I don't even, it's almost like I have to revisit that problem. 'cause it really, I, I, I can't, man, it's very hard to manage that.

Jake: I don't know how you find it with man, like how I have. Like managing dozens and dozens of modules. Even getting to upgrade it, it's getting easier. But it used to be, it's, it used to be really arduous. Like you'd have to go into command line and do a whole bunch of steps to tag a release. And now I, I can do it in about three minutes with GitLab.

Jake: And what's your take on, like do, you don't do a lot of sub modules, right? You do 'em outta necessity?

Martin: Yeah. I think probably the [00:05:00] project where I've got the most submodules is event platform. And it's gonna be interesting because one of the things that I wanna do with that later this year is move as much as possible into recipes.

Martin: And for recipes there is no concept of like sub recipes. You, I could do a thing like they've done with Drupal CMS and do like a monorepo with a Subtree split. Mm-hmm. But I still haven't kind of quite got my head around exactly what that looks like to implement. I have no idea. Yeah. So it's, it's, it's gonna be one of those, like, do I go down that path and have to learn, you know, the, the sort of you know, procedures and, and setup of, of what that entails.

Martin: And does that mean, you know, as you say, actually having to cut releases for each of the sub recipes anyway. I don't know that that's something I have to explore, but yeah, I would say in general, I've like Smart Date has, you know, one submodule Yeah. For making a recurring in general. Yeah. I don't, I haven't tended to go too far down that, that [00:06:00] sub module path, like even with Smart Date, there have been a few times where somebody who's requested something and I've kind of said like, just make that its own project and you maintain it more or less.

Martin: 'cause I don't want to be in my code base.

Jake: That is a good point. Yeah, no, that. Drawing that line, which I think I, I semi made a mistake in Webform is that line of like, this is the core and then this, you go off and do your own thing over here and you break those into own projects and you're like, I'm not responsible for this.

Jake: Is is really a best practice now. And I mean, I, I almost wanna, and I'll come back to ECA, I want to give a shout out to ECA where I think they've done that pretty well, where it works really well. They have a lot of submodules, but then there's a point where they're letting projects just start happening and they're trying to tighten the core up where frankly I don't see it evolve, changing much.

Jake: Or they, they're, yeah, I know there's some big API changes, but that's kind of the point. They're trying to get this architecture right, where could, everyone can go at it. And I mean, webform, it's still, there's a [00:07:00] lot of plugins. So people, I mean there's hundred, I've lost count at this point. I guess I went down that rabbit hole, but you brought up recipes and I find it so funny.

Jake: It's like I still haven't netted out. What's the right best practice for recipes in the sense of like, Drupal CMS breaks things down into small, tiny little recipes that merge together to create the whole system. Like every media type is its own recipe. And I get it, but I don't see how to maintain it outside.

Jake: You know, like I I, the subtree split that practice. I, I couldn't maintain it. Like I, I actually, right now, I love, I, I'm gonna tell everyone, like use recipes for any demo, anything you gotta show off, use a recipe, don't, don't do anything else. Just get used to it. But I've ever a sandbox a schema auto blueprint recipe sandbox where I've dumped 20 recipes in that, or it's like dozens of recipes in there.

Jake: 'cause I can't maintain those as separate projects. It just does. And that's, that goes [00:08:00] against the policy that each recipe should have its own composer, JSON, that you can kind of collaborate together. I don't know where we're going with it, that that's the, but I do, I hope it makes it easier for us to maintain modules.

Jake: Even doing demos, you could use a recipe over a module.

Martin: Yeah. I mean, so to me, the, the thing that's interesting about recipes is when I started using Drupal now many years ago it felt like most of the modules that I was using were really sort of pre-baked solutions. So there was a module that I think technically I'm still maintainer of, that's called Jobs Board, where it was, you know, it defined, you know, jobs and then it sort of generated a list of those, like this was, you know, not views or content types or any of that stuff, but sort of like a, a hard coded, you know, database queries and, and all those things.

Martin: And. And there was even, you know, on the project page, like if you want it customized, contact the [00:09:00] maintainer for, you know, basically custom work because there was no like, go in and, and just update the configuration to match your specific needs. Then I feel like as a community we swung really far the other way where everything was tools, right?

Martin: So it was all, you know, views and field UI and, and all those things which made Drupal incredibly flexible. But it meant that unless you went in already knowing how all of these things worked to, to solve a particular problem that you had, you kind of would install Drupal and be like, okay, now what? Right.

Martin: Like, you, you sort of, you know, there, it sort of actually made a steeper learning curve, I think, in terms of, of understanding Drupal and I, I feel like recipes promises to sort of bring it back to where somebody could go in and say, okay, I wanna make a website. I want to have, you know, site wide alerts. I want to have you know, person profiles and locations and events and all of these things.

Martin: And by installing recipes that, that basically give them a, a good [00:10:00] starting point for all those things. Mm-hmm. I mean, I guess technically you could do the same with schema auto blueprints, but you know, I think we're getting back to a place where, where people have solutions that allow them to, to have a good starting point without having to sort of do all, you know, start with a tool set and then build from there.

Martin: They, they have. Better options to, to actually have solutions that they can start to iterate on and, and refine.

Jake: I, I would take it a step further. I mean, we're talking about a starting point. Recipes is a great starting point. We do, I wanna call out something that's great about recipes is they don't technically need to be maintained.

Jake: You put it out there, someone uses it, they're on their own, which is great. You know what I mean? Like, you can improve it or you can update it, but at the point when the person uses it, that's it. That's your respons as a maintainer, that, that change, that's the end of your responsibility. What, what's interesting about starting points also is we're, we're also evolving tools, and we're gonna have the AI moment of this conversation.[00:11:00]

Jake: Our tools are getting better to help evolve the site. And the AI module in that initiative is doing amazing things and has so much promise where, I mean, the, the demo that we're seeing now is give me a blog, install the recipe, but then you're like, oh, I need to add this field to that blog. And the AI module is capable of understanding that request and helping you and maybe even just guiding you.

Jake: I mean, I, I, I, go on, I'm on the fence on whether AI should be generating these things. Does it really do it well? Is is, by the way, I'll, I'll be very clear on my own stuff. I am super experimenting with schema.org and AI where you can, AI understands schema.org. So ridiculously Well, it's like a lesson to be learned.

Jake: 'cause it's such a well documented spec. You can say I'm doing a government demo. I'm like, give me a content architecture based on schema.org for government in Drupal and just specs out everything. But the AI module, you can't say generate an entire government framework website. Like there's a disconnect there.

Jake: But I guess [00:12:00] I'm bringing up the AI stuff 'cause our tools are getting better. Even with maintaining code. There's a conversation. It, it's potential. We could have AI agents on drupal.org helping us tag a release. You know, oh my God. Think about how great that would be for someone who had no experience just having a chat interface to tag a release.

Martin: Yeah. I mean, you think about like I regularly use the, the tool that Matt GL put together, that MN dev, which is fabulous. But if it could even go further and you use AI to generate sort of a, a boilerplate summary based on the issues, you know, that would, that would change it from being a five minute process to a 32nd process.

Martin: And, you know, because you have maintainers that maintain dozens of modules, you know, there's a, a pretty real benefit there to both the maintainers themselves as well as the community in terms of being able to, to get out all of those releases that achieve sort of major level [00:13:00] compatibility in some of those things.

Jake: Yeah, it, it, the work of doing a release and even managing a release is a, a, a tricky one. I I, I almost wanna switch gears as to say I, I struggle with, with webform, deploying a release is such a stressful thing because then I'm gonna get all this feedback on issues that no one caught. And then you gotta wrangle that.

Jake: And, and even summarizing the issue queue would be spectacular. I, I, that, that's, there's just this AI can do summarization so well, like, where it could tell you, well, these are the things you should work on. 'cause based on, you know, there's this problem in multilingual, you've got 10 issues on multilingual.

Jake: There seems to be a a, a pattern. Here's a guess at the root cause. Yeah, I hope we improve the tooling. It, it's like, seems like that's, we are, I mean, I always like that mantra. Always keep improving the tooling on, you know, like drupal.org and like, I. F frankly, I feel like it evolves really fast. Like I use PHP storm and that evolution is incredible.

Jake: They're, they're [00:14:00] basically bringing new tools in every release. Yeah.

Martin: That being said, even on, as part of the Drupal community, we've got the project update bot. Mm-hmm. You know, we've got Drupal ci, so there's, there's already a quite a few things that the community has been working on in terms of easing the pain of, of maintainer ship, even beyond just sort of the, the raw like, you know, extensions and, and different things that way.

Martin: But yeah, I think something that could allow maintainers to, to look at the issue queue and even almost like, you know, at the, at the bottom of a product on Amazon where it'll use AI to generate a summary of like. You know, people are generally happy, but have this issue if, if you could say, you know, give me a maintainer analysis and it could say, you know, there are four issues that are RTBC and you know, have, you know, a bunch of of comments supporting that.

Martin: And then there's two that are critical issues and, and basically almost like triage it for [00:15:00] you as opposed to having to look through in some, sometimes, you know, quite a number of different issues on there. Some kind of high level analysis that could be provided for you could be quite a benefit.

Jake: Yeah. As a community, I think we have to lean into this, which we're doing in the CMS, but is, you know, there's some hesitation to have AI generated modules or code and I can say I, you know, it's 50, it, 80% of the time it's okay and then there's a, it gets things so wrong.

Jake: You're, it's scary. You're just like, and, and I, I heard someone talking, it might be that way for a very long time with AI is it's not going to. Get it all the way there over the hump and we gotta figure out how to, you know, check it and throttle it. But we, I, I do think it's important to lean into it in, in terms of developer maintainer ship to bring in new maintainers.

Jake: It's almost a good question to go into, like, where do we see ship going in the future with maintainer ship? And I, I'm gonna interject one interesting thing, which I am a huge, so I'm struggling to learn [00:16:00] ECA. Event condition action where it provides a UI to build little things, to do little things. It literally could replace 25% of the modules and contribute conceptually, like it's in that space.

Jake: Drupal CMS showed that because there was like eight modules that were gonna be installed, and now there's eight rules sets that are being set up. And I think that's a huge opportunity, like in terms of modules, maintainer, ship, it's making things simpler and easier, and then it's allowing, contribute to focus on bigger things, you know, not like what happens when someone logs in.

Jake: Where do you redirect them to? You don't need a module for that anymore. I'm wondering where you see Yeah, like contribute going, I mean, even with, you know, where with a starter template what are they calling that site Templates. The, the whole ecosystem could shift. We need to get more people contributing, right.

Jake: I don't, and I don't, I haven't heard, we have more or less contributors than any keynote DRE notes in a long time. True. It's that, [00:17:00] so I'm just guessing. Yeah.

Martin: Well the, the stat that I heard recently, excuse me, was that if you look at companies who contribute to Drupal, that there was actually a big uplift last year and the theory was that Drupal CMS was a big driver of that.

Martin: Mm-hmm. That, you know, that sort of rallying cry around Starshot was successful in, in getting a bunch of companies engaged, that that maybe hadn't been as ga as engaged. How that translates into individual contributions or any of those other things. I haven't seen any data on that, as you say, in quite some time.

Martin: Mm-hmm. But it's an interesting question. I mean, I definitely agree that we need more maintainers. You know, when you think about some conversations around things like IXP mm-hmm. It would be great if the process of getting people engaged, not just with Drupal, but the Drupal community could partly be, you know, go in and.

Martin: You know, be active in the issue queue. Maybe pick one module that you're interested [00:18:00] in and help out that maintainer or help get some, some issues resolved, you know, test some patches even, and provide feedback in terms of whether they worked or whether they didn't. I, I definitely feel like there would be a lot of value both for, you know, people who are aspiring to have a Drupal career as well as, as you say, the community in general, to just have more people who are familiar with the process of contribution.

Martin: But then the other thing too is I, I see more and more these maintainers that have, you know, dozens of modules that they are listed as a maintainer for. Mm-hmm. And I worry that if we have a smaller and smaller number of developers that each maintains a growing list of modules, that, you know, the capacity for burnout is very real and, and will only exacerbate the problem.

Martin: And so we need. You know, some way to, to sort of share the load a little bit more. You know, maybe there are automated tools that, that help with that. But I definitely feel [00:19:00] like to the extent that we can just, as you say, get more contributors within the ecosystem, that that would definitely be a huge benefit.

Jake: Yeah. I'm just making it easier. No, you're right. Burnout is a real problem. I mean, I've talked about it and I've burned out here and there and you know, my contributions have changed over the years. 'cause it's just like, you're like, I don't have the time. Or just personal stuff, getting the, you know, personal stuff happens and that prior, that Trump's work.

Jake: I mean, yeah, it's, I'm pausing 'cause I'm trying to think, like, one thing I will say that I succeeded with work is they're fine with people contributing to Drupal. Like they don't care. As long as it doesn't slow things down, more than 20%, where you're just like, well we gotta just create a project page.

Jake: And frankly, if we can make that easier and easier, and even now, I'm, I'm definitely. I'm using AI for all my commits. That saves about a minute or two of writing for every single commit to even summarize a project page. I'm experimenting with that, you know, if we can make it easier and easier for people to [00:20:00] contribute or to review or to that can, that can make a big difference and, and work.

Jake: I, I just hope more and more companies are just like, I, it's fine. At some point you're like, Microsoft lets people contribute. That's the big paradigm shift that's happened is like, I, I mean, if I was gonna criticize companies, apple feels like the last big holdout where their open source contributions still are.

Jake: There's a wall and you have to throw it over the wall and you can contribute. But most other companies have a strong policy and I think smaller projects can do it. I do like Drupal CMS in the sense of it. It really did inspire a lot of contribution, even by definition. I. Boy. Yeah. I just wanna point that out with Drupal cms, which is just amazing.

Jake: Is someone new to Drupal installs Drupal cms and they see something off they can fix that not core, you know what I mean? Like, it's not like some core module that they're struggling with. It's a, it's a collaboration of a bunch of contr modules. They have all these opportunities to go in, well, I need to improve this, [00:21:00] or you need to extend this and, and maybe we need to lean into that.

Jake: It's yeah, I like Drupal. It's such a, Drupal CMS is such an interesting opportunity for new people and it's hard for us old people to fully recognize that capability and how you can I mean, geez, just the simple fact that, you know, the person who stole Drupal CMS is new to Drupal. I just wanna like, like even the language of that experience is they're new to Drupal.

Jake: Because I, and I just, I have a question and I don't want to, I don't know if I would use Drupal CMS for a new project, would you? I. I would use it to introduce someone to Drupal and say, this is your mental starting point. Especially 'cause we're working on big sites. That's where I, I struggle with where that fits in.

Martin: Well, that's what I was gonna say is I feel like Drupal CMS was, was explicitly designed to be more of like a Wix replacement. Mm-hmm. So I would, if I was talking to somebody who wanted a site like that you know, they're not [00:22:00] a technical user. They want something that's just sort of outta the box, does a bunch of things, don't necessarily have specific requirements of like, I need all of these things to work in very particular ways that I've already kind of thought through.

Martin: Then Drupal CMS could be a great starting point. You know, it's got lots of different capabilities you can add, you know, additional SEO features or it has, you know, privacy things outta the box. Like a, a bunch of great features. But it is opinionated in ways that, you know, I don't, I. Necessarily agree with all of them.

Martin: Mm-hmm. Which is not really a criticism. I mean, that's, that's the nature of creating an opinionated CMS like Drupal CMS I think there was a blog by Josh Miller earlier in the year where he mentioned, you know, he looked at, at Drupal CMS in depth and said, you know, there's a lot of assumptions or, or opinions in there, and he agrees with 80 to 90% of them, and that's actually really good.

Martin: Mm-hmm.

Martin: But, you know, as you say, as a, as an experienced Drupal developer, you may have particular ways that you want [00:23:00] things to be set up. And Drupal CMS doesn't necessarily follow that model because it's not really thinking of more of the power user use case. It's really trying to do things that are simple outta the box.

Martin: Which, you know, just won't align with every use case of, of how you want to use Drupal.

Jake: Yeah, that is, I mean, what I see with new projects is their big projects. So where Drupal CMS doesn't, you know, like a government, you know, a hospital, a government website wants to go to Drupal, they have all their pre-defined notions that they can't, you, it's very hard to be like, well, you gotta change your whole paradigm to this paradigm.

Jake: I do love going back to developers'. It's an amazing tool. It, it's like the old days when you wanted to learn how to build a website, you'd right click and view HTML source. That's what Drupal CMS provides. It's like, this is how things should work. This is a anyone coming in. It's this amazing training starting point.

Martin: And it's also given visibility to a bunch of projects that, you know, some people would've heard about, like the [00:24:00] trash module that yeah, you know, some people knew about, but probably a lot more. Oh, websites would've been using it if, if more people had known that it even existed. I think that's, that's pretty interesting as well.

Martin: Mm-hmm.

Jake: I don't know, we, we went, it's funny you go on the AI Drupal CMS train and then you get away from maintainer ship and like the, the challenges there. I almost want to, like, is there anything we feel like we can give some insight to maintainer, ship, or challenges or, or just, well, so here's one thing

Maya: I've been to a lot of tech events over the years, but Evolved Drupal really stands out, and the next one is coming up on June Fix in Boston. What I really love about this event is that it's small enough that you can really talk to people, share ideas over coffee and not get lost in the crowd. But at the same time, it actually brings together a great mix of people from higher education, healthcare, nonprofits, government, and agencies, and everyone's sharing practical ideas about design digital [00:25:00] strategy.

Maya: Of course, Drupal and adjacent Technologies. There's gonna be a full day of sessions, lightning talks, and opportunities for networking with the whole community. And if that sounds like your kind of vibe, you could get all the details @evolveddrupal.com. Hope to see you there. I.

Martin: I think would be interesting to get your perspective on.

Martin: I can't remember if we've talked about this already, but one thing I've noticed is a small number of projects starting to use a different notation for the, like, Drupal major version that they require. So instead of it being like 10 double pipe, 11 double pipe, you know, 12 in the future, just doing like a greater than or equal to 10.

Martin: And I feel like there's definitely, that's not something that should be like a widely adopted pattern, but I could definitely see, again, going back to that idea of there being sort of different classes of projects, you know, a small project that isn't likely to need a bunch of changes over time. [00:26:00] Yeah.

Martin: Probably isn't gonna need, you know, much maintainer ship from between major versions. It's probably fine to use that model and then that's just one less project that, you know, when Drupal 12 gets released, you have to go in and just update the info at yaml.

Jake: I, I agree with that. I mean, you we're, we're getting into different classes of projects, but True, I, I mean, I was fascinated many, many years ago, I heard about a guy who had a node project that had enough enough test coverage where he just automated when he fixed something, it tagged a new release.

Jake: That was his mindset. He was just like, it does this, it does it well. Someone files a bug, I write tests. The bug is fixed. I know there's no regressions. As soon as I merge that, it's a new release. And I think there are opportunities where we can have that, where we're just like, this is for Drupal deprecated coded and we're catching things earlier.

Jake: So yeah, it, I mean, I do think test coverage is key. You can't really [00:27:00] pull that off by saying we'll see what happens. You kind of want to have some, and, and what is fascinating with deprecation notices is if you have the most minimal test coverage, usually you can catch 'em, it like it with the changes between different versions of Drupal, that, that, and I'll nudge people like it, it's always helpful to have even the most basic, you're loading the module and just confirming it loads, gets you 60% there.

Jake: I, I kind, I agree with you. I, I find it very, I. And then as you get to bigger and bigger modules, it gets harder depending on the changes. What, what's good is we're getting better at not making massive breaking changes. I feel like I, I call that Nick on his object oriented hooks improvements to Drupal, which it's a huge hurdle.

Jake: Once we get there in terms of our code, I think it actually is gonna become easier and easier for us to do upgrades. 'cause, and just to emphasize what he did is he took hooks out a functional, you know, our own [00:28:00] Drupal is, and moved it into object-oriented code with attributes that's stable, that's easier to maintain if we need to rewrite a hook.

Jake: It's that you can automate and is a lot easier and yeah, we're getting better and better at it. Yeah, I, I kind of agree that like we can. I slowly say the next version. I do like that we have the lenient repo or Mac and Mac layman give him credit. I think he came up with like a composer plugin to allow you to just upgrade modules as needed.

Jake: And it's that simple. Like it's not, it's not, well Doc, I think that's not well documented. Am I right? Like maintainers know about this? It's,

Martin: I mean, I think you're right that it's probably not widely known and sort of understood exactly how to use it, but there's probably also a bit of what's the word I'm looking for?

Martin: There's a danger if it was too widely used, if you know what I mean. Right? Mm-hmm. So there's maybe some value in it being, you know, [00:29:00] something that people have to have a certain amount of Drupal knowledge or like, community connections before they would sort of know to use it, but it shouldn't be sort of, you know, almost like secret knowledge in a way.

Martin: Mm-hmm.

Jake: Yeah. It brings up, like we, it'd be almost nice if there was recipes for developer tools, like a, like, because there are a bunch that can be used. And I, I'll even throw out like if we can get better at like, what's the best way to profile, you know, your site? Because there's a couple of different ways and there's add-ons and it gets a little dodgy.

Jake: And I, I've had problems with web profiler. I think it looks amazing, but then it hits something and it can't keep going. I'm pausing 'cause I'm like, I think you just bring up this, this question of where we are with maintaining, like there's modules that are easier to maintain should we start consolidating modules?

Jake: I'm starting to become that mindset of we need to kind of start going through, contribute and see if we can merge modules, not merge, but [00:30:00] ECA can replace a whole bunch of modules. Do we? Actually say we should do that. Like it's, and you know, by the way, if I am talking about ECA in this way, where it starts replacing modules, it becomes, should that be part of core when we're trying to do a small core, but at the same time, just want to emphasize good board did a great session at DrupalCon.

Jake: What should be in core, what shouldn't be in core? If it's used by a bunch of things and relied on by a whole mess of things, it should be in core, it's why views is in core. It wasn't contri and ECA has that potential where it goes into core and then we just trim the modules we're maintaining and, and, you know, focus on bigger things or I, I don't know.

Jake: Individual features, not behaviors, by the way, that's what ECA does. It does behaviors. Right. Is that a fair?

Martin: Yeah. I mean, I, there's probably some semantics in there that I don't necessarily wanna Okay. Yeah. Dive too deep on, but you raise an interesting point about, you know, sort of revisiting [00:31:00] that whole conversation around what's in core and what isn't.

Martin: I mean, I, I have had the same thought that ECA feels as transformational as views was mm-hmm. Back when it gained popularity in terms of really allowing for a much lower reliance on code for, you know, a very common sort of class of tasks. That being said, I will say I've had some interesting conversations in the last year or so as I dug deep into some particular issues that I ran into with, as an example, the way the view system interacts with the menu system and some, some things that it, if I'm honest, it seemed like it probably worked in view seven.

Martin: Mm-hmm. When it was a contr project and then maybe didn't sort of completely successfully make the jump into Core. But now the problem is [00:32:00] that because these things exist in core but are maybe not common use cases, to get those fixed is much more of a challenge than it would be if used was still a contribute project.

Martin: And so there's, there's kind of a double-edged sword there, right? Because it's like if you, if you can have it perfect and get that into core. You can, there's a pretty high level of confidence that it's, it's never gonna be broken again. Mm-hmm. But if there are, you know, issues that it goes into core with the rough edges and getting those fixed or, or even iterating and, and evolving them over time is a much slower process for anything that's in core than, than for something that exists outside.

Martin: And then the other thing you could argue is in the age of, of Drupal cms, how important is it for things to be in core anyway? Because if, if we do get to a place where most people install Drupal via Drupal CMS, or maybe there is some developer variant that's some less opinionated, but has a lot of the same features, then, [00:33:00] then the question of, of what's core and what's contri, you know, becomes less of an issue really.

Jake: Yeah. I mean, we can argue the benefit in core is it's conceptually better maintained and. Contribute. It's, but it can move faster and contribute. And I ag agree with that. You bring up the interesting thing. Yeah. It's like we say, most people don't start with Drupal cms, but everyone should look at Drupal CMS for their base modules.

Jake: And that's what we're kind of batting around here is Drupal. CMS is making some opinions that we all should, probably every developer needs to pay attention to, like trash module. Frankly, at this point, every site should probably have a trash module. If you have more than 10,000 notes, it just, we may as well adopt that feature.

Jake: You're right. It's like adopt that feature. It does definitely shouldn't, doesn't need to be in core. But why wouldn't you at an enterprise scale, want that feature? And, and it works. I mean, now I'm shocked how well it start. I gotta, we gotta [00:34:00] give a shout out to the trash module and it does what it does and does it well.

Jake: Yeah. It's such, I. So I, I do really appreciate what's happened in the last year. 'cause it throws a lot of questions out there and we have to come up with answers in, in, in the, the contrib space.

Martin: I mean, you know, one other sort of recent development that definitely I feel like is maybe technically adjacent to sort of particularly module contributions, but I feel like is, is not unrelated by any means, is is the whole concept or the conversation around marketplace.

Martin: Mm-hmm. And, you know, this idea of having site templates, some of which could be paid notionally will depend on contrib modules.

Jake: Yeah. I, I pushed back on that one 'cause that's a really tricky one.

Martin: Yeah. I mean, I.

Jake: I, I, I can even call out my specific concern, and I know we're not [00:35:00] going there, but theoretically, I did all this work on webform.

Jake: I could be compensated for it. And someone could do a site template for forms where they're designing the forms, but they're relying how to, they're gonna put a beautiful front end. Maybe they'll bring in, you know, a external, API, you know, like a tool for forms and put it on top of it. But then most of the work is in that contrib module.

Jake: And then how do you compensate the contrib maintainers or, or at least support contri. And that's, that's very, very tricky. I also, I'll just start out there with this, the marketplace where people are like, well, you brought up this thing. People are gonna generate ai. They're gonna use AI to generate a bunch of templates, and then they're gonna try solving.

Jake: And I'm like. Yep. We just have to embrace that at this point. That's where I'm at with AI is if you're theoretically thinking it's gonna happen, guess what? It's gonna happen. So you just have to accept that it almost should be a given. Like we should almost be like [00:36:00] the marketplace is, and I don't know how you monetize that properly, you know what I mean?

Jake: Like, it, it's like, are you providing this, you're paying for the service that the AI will generate the code. Yeah. I,

Martin: yeah. Oh, I was just gonna say, I've, I've seen some interesting conversations around that. Some people saying maybe there should be, you know, almost like, of. I don't know if membership is the right word in the marketplace where it's like at a certain level you can only contribute one site template a day and then, you know, maybe you can move up based on the popularity of the templates that you contribute, or, you know, different ways to sort of not restrict people who have demonstrated that they're doing things in good faith.

Martin: Mm-hmm. I don't know, it's, to me, the, there's so much around, like notionally the idea of a marketplace as something that is going to, to get us more themes is something I completely agree that we need to do. [00:37:00] But I feel like there's so many of these little, like devils in the details kind of things around, like, you know, as you say, if, if a particular template is really built, almost exclusively on web form mm-hmm.

Martin: The idea that they could charge, you know, whatever, even $5, let's say, for each site that wants to use it and none of the $5 directly goes back to web form. Is that right? I mean, you know, what I've heard is that there's this notion that the DA will, will take a cut of what that, you know, theoretical $5 and then somehow, you know, bring that back to the community in some way.

Martin: So whether that's, you know, better developer tooling or, or those kinds of things. But, but there hasn't been any discussion of, you know, a more direct, like the, the template use these modules and so we'll try to, to somehow directly benefit those modules. Even if you try to do that, like, you know, there's, there's also the notion [00:38:00] of with a site template, there's probably, you know, I'm guessing one user that, that contributes that.

Martin: And so the, the money that they collect goes directly to them, whereas with a project, you might have dozens of maintainers for some bigger projects. And you know, is there any way that you could feasibly try and decide how that that gets filtered out to, you know, a large number of maintainers? There's, there's a lot of, you know, potentially thorny issues and, and I feel like anytime money becomes part of the conversation Yeah.

Martin: You know, the, the temperature goes up on all of those conversations as well.

Jake: I mean, one thing just to point out, it has not been, I, maybe I just missed discussing it, but, you know, there, I, I've even blogged about it, but there is an opportunity to do bounties to fix things. I. You know, like that's a marketplace is service.

Jake: And I want to be clear, our community is driven off of the service around the free software. People pay for the service on top of the free software. So that's not a foreign [00:39:00] thing. Thing. The thing that has changed is the gig economy is so real now. It's a given. People are used to that. I need this fixed. I pay 50 bucks.

Jake: It goes, gets fixed. That's an i I mean, the problem is it's an uncharted territory in our, like, people are scared of that. 'cause then it could change the whole nature of how things evolve in Drupal. And the one problem is we're, and people said the marketplace we're trying to create is something that exists everywhere else.

Jake: We're trying to catch up with other people and things evolve so fast. That might just be a thing of the past where you pay for a theme or a module. It it, you really, and, and yeah, things are evolving so fast. It's like, where are they really going? What's the real future? Of monetizing these thi of monetizing building a website.

Jake: And if AI's generating the website, hence you're paying the ai, the service fee. It, it, it is a really big challenge. I think it's good if we [00:40:00] try something, but I'm, I'm scared if we fail. Honestly, it, it looks really bad if you have this languishing site Yeah. With no traffic and you spent all this money.

Jake: Yeah.

Martin: Now, I will say on, on that question you raised, or the topic of bounties, you know, the, the idea that I've had and, and I've actually suggested it as part of the. Main talking Drupal podcast before, but if, if we could actually stake the contribution credits that we've collected as individual developers and use those as bounties, I could see that as potentially being a way to help funnel the efforts of people who are motivated by contribution credits.

Martin: And if you look at the number of people who are trying to game the game, the system in ways that, that don't help the community, if we could use those contribution credits as a way to focus that energy to help move along things that individually we're passionate about [00:41:00] getting resolved. So like, you know, there are a couple of issues around views that I would love to get.

Martin: Mm-hmm. You know, moved along or maybe even on modules that I maintain, I just want somebody to go in and, and do more testing on it to make sure that it handles edge cases properly and, and other things that way. Or even to say, you know, this issue works well, but I'd love to get some, some additional testing written.

Martin: Could, you know, here's whatever, five credits to somebody who can, can give it the test coverage it needs as a way to sort of get things done that we as maintainers either don't have the you know, the time or the expertise or, you know, sometimes you just need a, a fresh set of eyes. Being able to, to get that.

Martin: You know, specific help at the specific time that you need. It seems to me like it would be a great way for those of us who don't necessarily need contribution credits for their own sake.

Martin: Mm-hmm.

Martin: To potentially use that as a way to get help without it, it becoming more of a, like an actual money [00:42:00] system.

Jake: I feel like that's a very safe suggestion just to be I I'm a hundred percent for that. I, I, because you're not, you're right. It's just goodwill creates more goodwill and you can use that. I mean, something I just wanna throw out there that you bring up as a maintainer, I want to call out 'cause I've thought about it a lot is.

Jake: I would love, and I don't see it in a lot of places, level of effort being added to tickets. 'cause it makes a huge difference when it comes to wrangling a queue. When someone comes into an issue and it says, listen, the level of effort is, this is difficult. Like enough people have said, this is difficult.

Jake: One that helps with the commit credit system. 'cause you know, this is a difficult time consuming thing and just people coming in understand and then there's easy tickets. It even helps with new contributors 'cause you're like, the level of effort here at Trivial. This is just a, a review. You know, and by the way, that's the tricky part you bring up.

Jake: There could be something difficult but easy to review, you know, but it's still, I do like the idea of just more information on drupal.org to help things along. And people probably don't rate modules. It would help. It, it [00:43:00] it, yeah. I, I feel like all those metrics help and we're, they're inevitable. Now I want to also emphasize, you could probably type into chat GPT, is this a good module?

Jake: And it will go out and aggregate. External outside of drupal.org, the blog posts on is this a recommended module or there are alternatives and, you know, read Reddit and, and go through that. I know, I, I it's, oh, sorry.

Martin: Oh no. Well, okay, so the one thing I was, I was gonna just mention on there is you know, I feel like certainly one of the metrics a lot of us use when we're looking at a module in terms of trying to decide, is this something that is.

Martin: It's worth installing into a particular site that I'm working on. You know, there's a variety of factors that, that are worth looking at in terms of like, test coverage and number of sites installed. And, you know, a few other things I used to, to personally, like when it had the the archive size listed on drupal.org, because if there are two modules that kind of do the same thing and [00:44:00] one is huge and one is tiny, I'm gonna go for the tiny one.

Martin: 'cause it's probably like easier to fix if I need to go in and poke around myself. Oh. That's funny. But but I feel like one of the challenges with recipes is at this point, we don't even have any, any data being captured in terms of how often they're being used and, and some of these things. So the idea of being able to, to help a guide a user towards the best solution for a particular problem could be a real challenge.

Martin: And, and that's why it makes me nervous when there's, there's. You know, growing conversation about being able to generate recipes when we still don't necessarily have, I think at least an implemented way to, to sort of curate or, or guide people towards, you know, what are the best recipes to use for a particular problem.

Jake: I, I mean, guiding is a great word. 'cause what, what is triple CMS It is a guide to get you started in Drupal and get the best starting point. I think we need to, [00:45:00] and I feel like it's been successful in that like, we, like any, you meet a client, you're gonna use Drupal, cms, like a new person to Drupal, be like, you gotta use this.

Jake: This is gonna guide you a little bit and we're gonna help you. And I agree in, in modules, I, you brought up that, like what, what's your factors for modules? And my number one thing is, is this module gonna alter the database? Because then it's hard to under uninstall. Not hard to uninstall, but if it, you know, like I'm making a commitment here, verse.

Jake: It's a UI u exchange. I have modules that just do tiny stupid little UI things that it's nice if, if you update the module and it doesn't work the way you want, just turn it, just uninstall it. There's some modules you can't uninstall, like you're with Smart Date. That's a commitment. You have obligated and web forms, you're going after a specific solution.

Jake: But then there's little UI modules that both of us have created where we're like, eh, it does it, you can decide not to use it. It, it would be helpful to give people that information to guide them more and more guidance. Going back to the site [00:46:00] templates, it's hard to say, don't do this. 'cause it's, it's another mechanism to guide people.

Jake: It's another way to be like, here's a good starting point. You know, here's, here's the a good theme or recommended themes or, you know, and there'll be free and maybe there's freemiums in there or not. We're almost at time. I have a great. I wanna almost pivot to a question. Use the word adjacent. Okay.

Jake: And I want to talk about it. 'cause both of us have used the term occasionally with our work of being somewhat Drupal adjacent. And I, I think with Drupal CMS, it's created this op reality that there are things that are in Drupal cms and then outside of Drupal cms, and they're adjacent. I, I'll just throw out like Schema, our blueprints is going to be adjacent to Drupal CMS because it's its own content model.

Jake: And Drupal CMS has its version. And I think that's a good thing. But I think we almost have to embrace that as a community. There's gonna be, like, now there's two different tiers of modules. There's modules that everyone's using in modules that do something adjacent to, or [00:47:00] adjacent meaning alongside, or yeah, adjacent someone means you're going in a whole different direction.

Jake: But sometimes I think it's alongside, maybe it's three. It's like what's going on in Drupal CMS. Then there's things that go alongside Drupal CMS, and then there's things that are departing in different directions. You know, from Drupal CMS and I, I, I just want your opinion on that is, is that a good thing?

Jake: Is that, I mean, should we recognize it? Should we lean into that? Should we be stating that, should a module that's in Drupal CMS have a star on the module project page to say this is included in Drupal CMS?

Martin: Yeah, that's an interesting question. I mean, I do feel like, as you say there, that that concept of treat treating Drupal CMS as a guide is, I would say definitely a best practice because, you know, there's a much stronger likelihood that something that's in Drupal CMS is going to have timely releases to be, you know, updated for the next major version of Drupal.

Martin: If there's any security issues, [00:48:00] those are, you know, more likely to, to be merged in, you know, kind of right away. You know, there are definitely advantages to sort of aligning how you want to solve certain problems with the way the Drupal CMS solves those same problems. I, I, you know, I guess I'm, I'm sort of of two minds, right?

Martin: Because on the one hand there is definitely a benefit for the community to say, let's not solve the same problem in five different ways. Let's consolidate our effort and then, you know, figure out which is the best approach and then make that more robust and more, more feature rich. But then there are also times where somebody comes up with a great new approach to solve a problem.

Martin: And if we're too consolidated in saying, let's only solve that problem this way, then somebody who comes up with this like amazing new, much better approach. We'll never get people, you know, willing to sort of. You know, veer from the sort of canonical solution for that problem if you, if you will. So it's sort of like, [00:49:00] yes, I, I feel like there's definitely value in saying let's figure out the, the best solutions and, and get people focused on, you know, that, that common solution.

Martin: But we still should leave some leeway in there for, for new solutions to bubble up, even if they're just to, to maybe bring new ideas to solving those problems. Because the other, the other issue is once something becomes too big, it can be difficult to really sort of like, you know, change course in a way because there, you know, sometimes it has so much code or, or, you know, submodules built around a certain idea of how to solve, you know, a particular problem as an example.

Martin: Does that make sense?

Jake: Yeah, yeah. No, I, it's, we want these things to exist. I mean, I really, listen, I, I, I am for experience builder, I think it's really important, but there's going to be adjacent. Drupal adjacent page builders that are not experience builder, and some of them should still exist. I mean, I, I use Mercury Editor and I'm a big fan of it, and I see it [00:50:00] fits into a slightly different niche.

Jake: It does it differently. It's simpler. It's not trying to, it's, it's meant to be very low code. You just go in, you put your paragraphs in and you use it. It's not a complex ui and that, that and experience builders trying to solve, it's a much bigger, going after a bigger audience, a bigger solution. So there'll be it.

Jake: I, I'm all for there being some adjacent solutions in the Drupal community. It's it, but it that's funny. I'm the maintainer of web form. We don't want a hundred. Form builder modules. I'll even make a shout out. I think we're gonna have to start thinking about the next generation of Form Builder because to your point, we can't just say that's the solution.

Jake: And I'll even criticize my, I'm not criticizing my own code, I'm recognizing Form API is a decade plus old. Hence, it needs to be updated. Hence we go into that problem you're calling out. We can't be locked into this one frankly monolithic solution [00:51:00] that we have. We have to probably, you know, move on to the next thing and someone's going to have to come up with, it's gonna be adjacent for a little while and then mainstream and even the ECA was adjacent to rules, and then we're replacing it.

Jake: And that's a great, a great thing that, that happens in our community. Yeah, it's like how do you foster that? Those other things that are happening, there's what is the community led initiatives that happen sometimes too, you know, like the side. Like Twig would never have happened if we're like, well we're doing it this way, we've done it this way.

Jake: We'll never do it a different way. And then suddenly a bunch of people are like, no, we need to integrate Twig in. And they just did it. Yeah, it's a, I dunno, this conversation just goes over, it's just a massive challenge on how to move these things forward. I wondered, is someone done a postmortem Drupal CMS?

Jake: 'cause that's what we, we were hinting at a postmortem of Drupal CMS. What does it really mean? What happened? And it's all positive. That's what's kind of great about this. I mean, everyone should be incredibly proud of themselves after one year to [00:52:00] have a, we're having a conversation about a year's worth of work that shifted the community.

Jake: And if we post mortem that right, we can figure out what's next and we still have more to come, which is, is really amazing.

Martin: Yeah, I mean I, I, I do think experience builder will really, at least, you know, the way it's been talked about should provide a much better opportunity to have people have not the, the flexibility out of the box that people have on the content architecture side mm-hmm.

Martin: On sort of, you know, the design and formatting side. And I feel like if, if we get that right, then it really becomes something that, that people without a lot of technical expertise can sort of jump in and, and adopt, you know, particularly if we can have either, you know, site templates as a way to, to be able to visually customize things and, you know, ideally a couple of clicks.

Martin: Mm-hmm.

Martin: Maybe there's, in the same way that we've got. Already demonstrations of using [00:53:00] AI to update the content model. There will be ways to use AI to say, you know, I want the background to be, you know, green instead of red. And have it go through and, and make whatever updates are needed so that it becomes more, you know, chat driven way to, to make those same kinds of formatting, even though they can be done through the ui.

Martin: We know that things in Drupal are sometimes possible through the ui, but still, you know, sort of like complex or like require a fair amount of understanding how the system works to be able to use effectively. And particularly as we are in a society that I think is going to be, you know. Especially for younger generations more and more understood as accomplishing things through like a chat interface.

Martin: Yeah. Being able to have a CMS that can work that way, I think is, is potentially extremely powerful. It's, it's, it's stunning.

Jake: I, I mean it really, it's like we are, what's, what could potentially happen in that experience of, of building and maintaining a site is, is [00:54:00] incredible. It's incredible what could, what what we're, we're looking at.

Jake: I'm so glad we're in that position and it's so challenging. I just wanna, it's like the AI people, we both know Jamie and, and Marcus and the people working on it, it's like so challenging. 'cause sometimes it doesn't work. Sometimes you, you're asking for a miracle to happen that we never thought was possible and suddenly in a year it's possible.

Jake: And now some things are ridiculously stable. I mean, there's things in that are happening that we're like, oh yeah, all text is a given. Any, any new co any company coming into Drupal doing a new site, you're like, that's a given. Just do that. Why, why wouldn't you? I know. Wow. We went in so many different directions.

Jake: How do we wrap this up? It's like I'm umming because it's so many things.

Martin: Yeah. There is. There's, I guess maybe one other thing I'd like to, to touch on in sort of the, the remaining time that we have, I feel like as a maintainer, you know, you've done a couple of things that I think were a little bit [00:55:00] controversial.

Martin: For example, with Webform, you know, after you install it, it puts that banner up to say, Hey, you should, you know, support. I mean, it also drives people to like, here are some of the resources and different things that way. Mm-hmm. But I can remember when you did that, there was, you know, there was some mixed opinions about that.

Martin: I mean, certainly we, we wouldn't have wanted like, dozens of modules to be doing that, and then all of a sudden you go to the extend page and there's, you know, sort of like a, you know, times square collection of, you know, ads and different things mm-hmm. Sort of bombarding you. But I mean, a, i I, I wanted to say you know, certainly as a Contribu maintainer myself, I appreciate you being kind of an advocate to say, you know, this is, these are things that re require effort and you should support the things that.

Martin: That you rely on. I feel, feel like we've seen some, some similar things more recently with the gin admin theme where, you know, as you talked about, like sometimes as a maintainer for one reason or another, the thing that you've been maintaining becomes less a part of your day-to-day life.

Jake: Yeah. [00:56:00]

Martin: And so you just naturally have to be less involved.

Martin: And you know, from, from a support standpoint, what could we as a community be, be doing better in terms of helping to maintain some of these projects? I mean, I think about the WordPress community has this concept of five for the future, you know, so the idea of like, if you're doing a WordPress project, you should take 5% of the budget for that and contribute that back to the community in some way, you know?

Martin: Mm-hmm. Should, should we as a, as a community be trying to drive people more towards an idea of supporting the projects in some way or another? I mean, for me personally I don't necessarily need people to be donating money, but if they could say, you know, if we're gonna spend. 2000 hours on a project.

Martin: If, if we're going to carve off a chunk of a hundred hours and use that to, you know, contribute patches to the projects that we're using or, or things like that, like, to me, that would also be a significant benefit. You know, just sort of embedding that [00:57:00] idea of giving back into, into how we use things. I feel like, I'm not sure exactly how that could materialize, but do you have any thoughts in terms of, of what we could be doing to, to help foster that, that kind of an idea of giving back more?

Jake: Well. It's interesting with the promotions in the web form. 'cause I backed out of promoting myself because frankly it wasn't sustainable. I just gotta emphasize like the money I get in Open Collective is great, but it's actually not, it's a barely sustainable amount for my larger career. 'cause my career's focused on maintaining a large website for healthcare institution and Webform was a secondary thing.

Jake: Schema was working better because it's, it aligns more. The thing that I feel, and I pulled back on that a little bit, but what was successful and still is successful in the webform module, is being very welcoming in the UI and the code to give people direction. I have videos, those helps promote me, but it really also welcomed someone and I think fostering that, like creating a, a.[00:58:00]

Jake: This in the code, in the Drupal CMS experience, how to bring people into the community. We have announcements now, which is great, but it's very minimal. We don't have a Welcome to Drupal video, which seemed, and, and with ai you're just reaching a point where this stuff is trivial to do, you know, like welcoming someone to Drupal community.

Jake: What's the right way to, how do you get started? Where do you, where do you want to go? How do you get help? We can do amazing stuff now with that. And I see nothing wrong with, I, I can't emphasize, I see nothing wrong with AI generated content as long as it's vetted. I'm literally doing a presentation. I switched my schema presentation to just ask AI all the questions that I know the answers to, because it's a better way to get someone to understand what I'm doing.

Jake: 'cause you're getting a wealth of information and then you just have to correct it. I, I feel like we just have this huge Yeah, like the AI chat bot you're asking, you have to engage it. It would be nice if it engaged someone like, how can I help you? [00:59:00] You know, contribute back. How can I help you with this module?

Jake: Do you need help with this module or that module to, to get more engagement? Yeah, it's engagement and maybe it is a gamification of the system. I always love this idea that you, you're first commit, it's unlocking an achievement and balloons should float up above the screen when you do that. And I see nothing wrong with that.

Jake: I think we should lean into that. I think, I mean, I, I know the da, you know, tracks people, but we should have A-A-C-R-M behind every developer and let them opt in. But most people will, at this point of gauging where they're at, tracking their engagement, helping them with their engagement, seeing if, you know, they're running into too many bugs and saying, well, you know, there's this other way to go about this.

Jake: Maybe you should go to a conference. That, I mean, that's the opportunity. I, I hope I un like the needle. I moved in the web four module as I'm showing that like, maybe you can say welcome. In a really nice way and, and give a, and, [01:00:00] and really not just welcome, but here's a video here. Here's how to get started.

Jake: And, and I will even just say there's a problem that I have with my videos. They're hard to maintain. We gotta solve that, that that's why if you use automated generated content, you can keep improving it. You could have a script that just keeps I, oh man. Someone talked about like automatically updating screenshots, you know, like your placeholders in, in your, your slide deck or your video.

Jake: What else to say about that? I, it's, I hope we move the needle more. Yeah. We need to be more engaged with people coming into the community. Community and the maintainers, you know, where I, I feel like we talked about a lot of things here. It's like hard to, you know, wrapping it up. I, I, I lean towards, you know.

Jake: Nudging people to get involved. I always think that's the, the most important thing to say and say, start small. Don't have to start big. It just don't be afraid to do [01:01:00] it. It's not a lot of, you know, you just want to go into an issue, respond if you see a problem. Throwing any fix up is good. And then gradually, maybe you write a test if you need to, but you, you just little nudge it.

Jake: Little nudges. I always like that nudging, nudging people in the right direction. Or even nudging people in the right behavior. 'cause we've expressed concerns of people trying to game the system to get commit credits. You just nudge 'em against that. And even the DA was successful. I want to emphasize DA was successful in that.

Jake: There was like a sh they were like, we need to nudge people in the right way to make commits. And I, I saw Tim talk about it. It worked. Where would you want to end up on, on this, this discussion?

Martin: I mean, I, to me that, that, like, I think ending it. With a conversation about kind of, you know, sustainability of contribution like we've done is probably a good spot.

Martin: You know, I feel like not surprisingly, we, we've had sort of mentions of AI sprinkled through, which is appropriate to where [01:02:00] we are in 2025. So yeah, I mean, it, I think it's been a great conversation. I feel like anytime, yeah, you and I get the opportunity to sit down and, and talk about Drupal.

Martin: It's always a good, a good conversation. Yeah, appreciate the time and, and looking forward the next time we're able to do that.

Jake: Yeah, yeah. No, Martin and I go back a long ways. I almost, and I look forward to seeing you in New York at some point and at the upcoming, I don't know what my next conference is, but yeah.

Jake: And hey, hey, you know what? We should nudge with that little promotion. Go to a conference. It makes a big difference. It makes a huge difference. I, it's transformative now, more and more of what's going on in the community. You, you know, you meet people that maintain the code and you meet, you get ideas on what's going on.

Martin: Yeah, absolutely. That was certainly true for me. I was working on a module when I was at dev days last month, and managed to get connected to the perfect person to answer my question and sort of get me unblocked. And, and there's really, as you say, no substitute for kind of that hallway track experience of just, you know, having the you know, [01:03:00] fortuitous connections that you have with whoever might be sitting next to you or, you know, having lunch next to you, you know, those kinds of things.

Martin: So yeah, definitely great opportunities to connect. My next appearances are gonna be at mid camp and then Asheville. You know, for anybody listening would, would love to, to connect with you at either of those.

Jake: Yeah, I, I, I'll, 'cause we're on talking Drupal, I'll promote New England Drupal camp 'cause I go every year.

Jake: It's an amazing, and Rhode Island's an amazing city, so I want to give them that nudge of like, that's totally worth a little trip to. But I'll probably go to some other conferences before then. Well, Martin's great talking. So let's, what, what's the tagline we need? It's been, I forgot you. You must know the talking Drupal,

Martin: you know?

Martin: Yes. If you've enjoyed listening, we've enjoyed talking.