Talking Drupal #522 - New Contrib Records System

Nic: This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 522, new contribution record system. This episode of Talking Drupal is sponsored by am amazee.ai. On today's show, we are talking about the new contribution record system, how it's changed, and what you may need to do differently with our guest, Brian Garcia Lina and Tim Lennon.

We'll also cover Config Notify as our module of the week. Welcome to Talking Drupal. Our guest today are Fran and Tim. Tim leads the engineering team of the Drupal Association, the nonprofit that supports drupal.org and the Drupal Project. Their mission is to build the tools that empower the community to build Drupal.

Fran is a Drupal web developer, but most importantly, a problem solver. So he likes being involved in any project that helps Drupal in the community move forward. He lives in the south of Spain and loves being outdoors with his family. Enjoying the sun in nice weather.

Tim and friend, welcome back to the show and thank you for joining us. Cool. Hi. Thank you for having us. Happy to be here.

Tim: Yeah, great to be back. Excited to be here.

Nic: I'm Nic Laflin, founder at nLightened Development, and today my cohosts are Martin Anderson-Clutz Principal Solutions engineer at Acquia.

Martin: Hello, internet friends,

Nic: And joining us as guest hosts for the next four weeks, Hayden Baillio, head Dragon at Hero Devs. According to chat, GT Hayden is a very large Texan who spent a decade hurling heavy objects for a living, including shop, puts, logs, hammers, and basically anything that isn't bolted down before pivoting into tech marketing meets cybersecurity, where you now hurls punchy copy instead of 20 kilo stones.

Welcome to the show and thank you for joining us.

Hayden: Thanks for having me, Nick. Yeah, I appreciate it. That's about right. Chat. You nailed it.

Nic: I have to say I went to so there's a, a Highland Festival in Vermont this weekend or this past weekend, which is a Scottish festival festival and they have the log throwing, I dunno if it's called Throwing Taber to the tab Tabor.

To, to, yeah. Yeah. They have one of the, I went there, I don't know, 15 years ago, 10 years ago, something like that. It was, it was a lot of fun. I did not sign up. I am a scrawny web developer and would probably pull something if I tried that, but it's fun to watch.

Hayden: Definitely enjoyed it. It's a great time and you don't have to be good at throwing to, to throwing in the Highland Games.

That's the fun part about the games. It's just throwing rocks and sticks in a field and you add whiskey. That's it. That's all you do.

May maybe, if, I think the adding whiskey part is the part where you might get, you start to get Yeah. Hurt later in the day, but, you know.

Nic: Sounds good. And now to talk about our module the week, let's turn over to Martin, a principal solution engineer at Acquia, and a maintainer of a number of Drupal modules and recipes of his own Martin we have for us this week.

Thanks

Martin: Nick. Have you ever needed to maintain a site where a site owner had access to update site configuration and wanted to be notified whenever they did? So there's a module for that. It's called Config Notify, and it was created into Feb 2020 by Fran Garcia ris, one of today's guests. It has an eight point x dash one 11 version available, which supports Drupal 8.8 and newer.

It is actively maintained and has security coverage, and it has two open issues, neither of which are bugs, which is pretty good considering it's officially in use by 194 sites according to drupal.org. Now, just like it sounds, this module lets you trigger notifications when the configuration deviates from the config management code in production.

You can choose for the notifications to be sent immediately or via chron with an update for a daily digest. The notifications can be sent by email or via Slack using the Slack module if you have that enabled. Now this should be an easy to implement solution if you support a site where users may be updating the site configuration in production.

A different approach was discussed on this show back in episode number 2 36 called Top-Down Configuration. So let's talk about config Notify maybe Fred, do you wanna give us a background in terms of what inspired you to start it?

Fran: Yeah, so I, I was gladly surprised to say it mentioned the main reason for it, it was because in my previous job I was working on the maintenance thing and we were working daily with 40 50 sites where actually yeah, many of the clients or even the, some of the developers would just go ahead and change configuration on production sites and we know how source truth that could be.

So. We could not monitor everything every day. It was taking a lot of time and then just chatting with one project manager. We just said, it would be great if we get notified if something changes on production. And then I said, I think I can pull that together. Yeah, a few days after that I build a kind of proof of concept.

It kind of worked out of the box, and then we started to the, the bells and whistles for slack and these kind of things. My stress level and happiness improve a lot. So that's kind of the, the backstory of it.

Nic: I, I have to say, I, I love this. I, I immediately, I've already sent this to a client where we don't actually change config all that often in a production.

The only people that can do it are developers, but we would only really do it in kind of a debugging or an emergency situation, but still having kind of a record. That's something they have a lot of audits and security. So having a record of what was changed when can help, like a couple of months, actually about a month ago we were dealing with an issue where we were getting DDoS by Google.

We were getting a hundred thousand requests a minute or no an hour. And we had to scramble to kind of resolve some things. And that involved a lot of config changes, both in Drupal and outside of Drupal. And a lot of the process was just tracking what changed. And if we had some sort of system like this that kind of tracked those changes automatically or helped make sure we didn't miss something as part of our post.

Resolution clean up is, is really valuable. I would love an integration with GitHub too, that could just like open up blocking pull request to be like, Hey, there's, there's config on production that's different than what you're pushing up here. Do you, do you wanna resolve that before you push that?

Would, that would be great.

Fran: Actually, there is a module for that. I think it's called Config PR or something like that. I would need to Google to Google it, but I think I've seen a module similar to that.

Nic: Oh

Fran: yeah.

Nic: I just found that we can put that in the show notes too. That is, yeah. For me,

Fran: I am a big fan of the config read only module with Jeff Pro Mansion in another show.

And whenever I can, I try to install that and that this allows anybody from making changes in production. But that's just not always possible. Sometimes yeah, clients request it and say, okay, at least I, I wanna know about it. And that's what config notify is about. That

Nic: might, that might be interesting too to that client, especially since I assume you can lock down specific specific configuration or is it kind of global, it just locks down everything that might be mm-hmm.

That might be worth looking into. Absolutely.

All right. Thank you Martin. As always. You came up with a, a great module of the week and I foresee diving in pretty deep in the future with one of my clients 'cause, or several of my clients, 'cause I think this will be, this will be pretty useful. So finding it. If listeners wanted to suggest a module of the week or just chat about one that we've talked about recently, what's the best way for them to do that?

Martin: We are always happy to talk about modules of the week, either, you know, current past or potentially future in the talking Drupal channel of Drupal Slack. Or folks can reach out to me directly as mandclu on all of the Drupal and social channels. Perfect. Thank you.

Nic: This episode of Talking Drupal is sponsored by amazee.ai.

Are you worried about sacrificing data privacy for the convenience of using ai? The team at amazee.ai believes you shouldn't have to. That's why they've built an enterprise grade private Drupal AI provider that doesn't compromise security or data sovereignty. amazee.ai is 100% privacy focused, letting you choose the region where your data is stored and processed.

They don't store your prompts, they don't use your data to train models, and everything is fully open source so you can verify it yourself. You can even run the AI in your own servers or cloud accounts with their purpose-built Drupal AI provider. It's simple. To get started, just install the dral AI module and pick amazee.ai as your provider.

With advanced AI tools, you can generate or simplify your site's content, generate alt text and supercharge search, all while keeping your data and your users' data completely private. amazee.ai even offers a 30 day free trial with no token limits, so you can experience how AI can make it Drupal site smarter and faster without the privacy trade-offs.

Visit am amazee.ai today to get started.

Tim: I know we don't usually discuss the ad reads, but I wanna shout out Amaz a little bit because they're one of the Drupal AI makers for the Drupal AI initiative in the community at large, and participating in supporting the whole effort to do AI orchestration in Drupal.

And they're also partnering with us at the DA side so that that trial capability is something that we can offer through drupal.org as well. So hopefully that's something coming soon that'll and, you know, the solution has this provider agnostic LLM agnostic kind of capability, and I think that'll be helpful for folks.

So anyway, I'm gonna, I'm gonna shout out at the end of that, that ad read 'cause I think it's, I think it's useful.

Nic: All right, let's move on to our primary topic. So let's start with, I think one of the crown jewels of the Drupal ecosystem.

For people that may not be familiar with it. Tim, can you give a high level overview of what the contribution record system is?

Tim: Yeah, I'm really happy to do that. And I was recently putting together a little bit of a history of drupal.org engineering projects and things like that. And so I was looking back at the very beginning, but in 2015, DRIs published one of his discussions of the, the concept of, of makers and takers and open source.

This notion of understanding who builds the ecosystem of Drupal, who builds Dr. Open source ecosystems in general, and this idea of. Us being able to track not only like commits to particular projects in Drupal, but track much more detailed information about how Drupal is built, the individuals who are doing it, whether they're doing it as volunteers or sponsored, and if sponsored, whether that is by their employer or by like a client that they might be working for, or both, any combination of these above.

And so the, we have built this contribution system going all the way back 10 years ago now to help understand and track that information for the Drupal community and to sort of share what we are doing with the broader open source community and with initiatives like the the Chaos Metrics community and some others that are looking at the health of open source ecosystems at large.

So very more, more specifically, what this is, is a way to say for any contribution to Drupal, who is involved, who sponsored it. For the maintainers of those projects to say, Hey, these are the people who are helpful and who should receive some credit for that issue. And we take all of those attributions, use them to understand the ecosystem, and also use them to rank our marketplace of service providers based on the amount of sponsorship of contribution that they've done.

So really powerful. Used in a lot of different ways. And recently updated. So,

Martin: so friend, we're here today to talk about some recent changes to the contribution record system. Can you tell us what prompted those changes?

Fran: Yeah, so basically I'm pretty sure that they were since ICOM, Barcelona some of you have seen that there is a new site versus new version of the site, a landing page.

And we also have the all current site. One of the main things that issue credit as or contribution records as, as Tim mentioned before, it's heavily tied to the issue content type that we have on the old side. Our goal as part of the GitLab acceleration initiative has been to move whatever would make more and more sense to GitLab with move code, with move metric requests.

With move ci it only makes sense as well that we move issues and that's part of what we are still trying to do. And we are closer than ever. We want to migrate issues to GitLab. However, GitLab is able to track people but is not able to track companies. It's also not easy to customize to tell it that I'm volunteering my time or I'm working for this client or for this employer.

As, as thing was mentioning before. So that's something that we build and that we think is still very valuable. But moving into the new site, there is no content type for it. There is no content type issue anymore. So we needed to design a brand new system that could do the same as the old system, but that would be allowed to be connected to issues still.

So that's kind of what came how, how this solution came to be. So we created the contribution records content type literally on the new Drupal. And we are as of right now, connecting it to drupa org issues. But as we migrate those issues, we'll connect them to Git. Not only that allows us to migrate issues, but it also opens the.

Different types of contributions in the future. Think of translating strings localized. There is no, we usually don't create issues for that. There is a platform that tracks the translations, but that's just no credited. People are doing it willingly. There's no credit, there's no attribution. So this new system kind of opened the doors to as well connect other systems.

But obviously our main priority was GitLab. And thanks for the flexibility that we designed it with. For sometime, we're gonna have some projects on drupal.org issues, some projects on issues, and the contribution record system will be the same.

Nic: So Fran, can you, can you, you talk about old system in new system. Can you talk a little bit about what that migration was like? Because I imagine that there was a lot of data involved, and that could have been pretty complex. I, I'd like to, as somebody who's done very large migrations, I'm a little curious about what that looked like and how you tested that.

Fran: Yeah. I actually, it's funny. I mean, I, I've I've got COVID, I've got the, the version, the newer version of the Drupal Flu because this past weekend was Drupal Camp Spain, where I did a session, which was called Millions of Data or How Everyday Solutions Never Work. I was precisely about telling the story about the migration process for jupa org, and I actually put together some numbers.

I mean, if we're talking about users for example, we've got more than 2 million users. We're talking about issues. We've got around one and a half million issues, and then those issues have, I think it was approximately. 5 million contribution contribute contributor entries. That is people that have been collaborating in issues and giving attribution to their companies.

And then if we go even to comments, then we have more than 10 million comments within those issues. So yeah, doing this migration, it is being a constant challenge. I mean, we've needed to do some optimizations for some entities so that they would be migrated faster for some other entities. We kind of have background processes, which are constantly migrating, so we could do like 2, 3, 4 episodes of this just purely talking about the, the migration.

Hayden: Very cool. Yeah, that seems like a huge project. I have a question, like kind of around, it seems like the old way of. Kind of giving credit, felt like a little, like it was manual, you know, like type names. Easy to miss people, kind of easy to get it wrong. New system has more of an auto population. Is this, you know, you know, is this really gonna make it easier for maintainers to issue credit and maybe make sure people don't fall through the cracks as well, I guess.

Yeah.

Tim: There's a, there's a few points here. I'll speak to a little bit of this and let, let France speak to, to it as well. So there is, we'll admit one thing, there's one way in which it's a little bit more difficult because, and we'll mention this throughout, like people do have to go to a new page where all of the credit stuff is organized on the new content type that is separate from the drupal.org issues now and separate from the GitLab issues, but it's, it's one extra click.

But the advantage is, yes, we are the credit table is much more sort of well organized in terms of importing information of all the people who were there. You can still credit people who maybe didn't comment on an issue but participated in a Slack conversation, all of those sorts of things that you could do before.

And as Fran was referring to, this opens up the capability for us to start creating similar contribution records for a lot of other types of contributions, whether that's the local localization or others. But would, would you like to add to that, Fran?

Fran: No, I mean that, that pretty much covers it. I mean, we, we are trying to bring automatically all the participants of the issue so that from a maintainer point of view, at the end it's just checking the check boxes with the information that we give them.

We give them how many comments were made, even if they made that sums up on a me request or all the contextual information that we can give, it's provided to the maintainer so that all they need to do is just check the checkbox.

Tim: I forgot we added the emoji reactions to merge requests, reviews and stuff.

Yeah. So really any, any of that approval information? Yeah, I think it's really, I think it's really powerful. There's also an automatic notification to the issue when it gets marks fixed, which means anybody who's on the notification list for the issue gets prompted to check their attributions to check the credit, which I think is a nice improvement as well.

Nic: Well, there was also a big change recently, which I don't know if it was due to this new rec contribution record system or something else, but you get credit now for, you used to only get credit if an issue was marked as fixed. Now you get credit for pretty much any closed status as long as you've, you've been given, you've been marked as creditable.

Is that part of this migration too, or is that like a separate initiative that

Fran: happened around. A few months ago, so, oh yeah, it has been that long, hasn't it? It was prompted, it was prompted by this because for GitLab there is just open and close. That's, that's how there is. And we were actually discussing all this kind of, we have closed we have fixed, we have closed close works at design.

Close one, fix close, duplicate. Yeah. But sometimes we were also discussing that maybe there are some duplicates where there was very valuable work. Yeah. And then that duplicate, those duplicated credits needed to be transferred to the other issue, which was actually more work for the maintainers. Yeah, we eventually decided it's like, why not just credits or the issues that are closed make everything easier, which in turns makes the migration, the issue migration easier as well.

So it was not technically part of the new system, but it was prompted from conversations around the new system, if that makes sense.

Nic: It, it does. So, so go getting back to the new system itself again, are there changes with how the contributions are displayed for a given issue as well?

Fran: If we talk about displayed as in visual, yes. The changes should be zero. What's going under the hood is completely different. So right now we have our user profiles and our and company profiles. And those used to I mean those shows a listing of issues.

Nic: Mm-hmm.

Fran: Where before we would just run a database query.

Now we are making API calls to the new system and rendering that information exactly in the same format as before. The idea was. So, yeah, to display exactly what we had before, because technically it's the same. But what's going on under the hood is, is very different. Obviously, we want to migrate those pages to the new site at some point, but right now we have this kind of hybrid system that is reading.

If something is living in the new system, we're gonna try to read that information from the new system and render it in the old system. Okay.

Nic: I mean, to, to be honest, the biggest change that I've noticed for historical stuff is that you, like Tim said, it's, it's an extra claim from, from any direction, right?

Previously, if I got a notification on my dashboard that an issue was fixed, I click on it, I scroll down, see if I get well. I look at the issue and see if I thought I had done something that. I would expect credit or not. Because I follow a bunch of issues that I wanna know about, but I don't particularly contribute to.

And then I could just scroll down and see if I had gotten credit and if not, see if there was something I needed to change moving forward. Now you have to click. That also happens from the other side. If I go on my user account and see like, oh, I have this many credits from this project. When you click on that, it brings you to a contribu.

It brings you to the contribution record, not to the issue. Maybe a redirect can be put in place for something because I, I feel like if you're going from the direction of the user profile, you always want to get to the issue. Not,

Fran: but you are. That's hard. Yeah. Yeah. I totally understand what you mean.

But you are actually taking the credit, so that's what it takes you. And then from the contribution record page, then you can go to, I mean, everything is crosslink at the, I mean, if you, you can cross link. To the metro and the contribution record. And the other way around, if you're in the contribution record, one of the tabs is the, is the actual issue.

So we were actually thinking about that, but because what we are actually displaying is the credits for the company or the credits for the, for the person, it would make sense that it would go there. To put an example, you may have been credited on the new system and not appear in the actual issue.

Say that you have a Slack conversation about the issue. You didn't make a comment, but the person decided to, to credit you. So if you go to the issue, you will not see your name. Whereas if you go to the country of record, contribution record, you'll see it.

Nic: Yep, absolutely. Yeah. That ma, I guess that makes sense.

Martin: So I have a, a question about the actual process of assigning credit because one of the things that I really liked about sort of the, you know, the switch over to the merge request system when, when that whole transition happened, was that at the bottom there was that nice little section where you sort of would assign your credit and they had little dropdown where you could say, okay, go ahead and merge this in.

And then kind of in that one nice little spot, everything was done. You know, including sort of the, the merger quest, you know, formatted exactly the right way and all that. Whereas now it feels like, at least this morning when I was trying this out, it seemed like a bit of a three step process, right?

So at the bottom of the issue, there's a link to the, to the spot where you go to manage the, the attributions, and then from there it tells you to copy the commit message, and then you go to the merger quest and sort of paste that in. Now, I understand that th this still we're in kind of a transition phase because more things are gonna be moving over to GitLab.

Do you, do you foresee that sort of becoming a simpler process again as part of those transitions?

Fran: I do. I mean, I actually talk about that many times. I mean, every time I do a demo, whether it's internally on to somebody else, I always start that with, we, we have three systems right now, we have seven, we have 10, we have GitLab.

Just because we have those three systems, we're kind of jumping in and out of them, which can main, can make things confusing. But if you see what you used to do five years ago to what you do now, you are now spending way more time on GitLab ui. And that's part of the goal as well. Once we move issues, we will have the ban board.

So we'll have the issue queue, we'll have the actual issue, then you will be doing the MER request. You'll be doing so much on GitLab. And then eventually we'll go out topa org the new, the new drupa org. So yeah, we are in a transition period where things could be confusing, especially if you're new. But they are definitely going to get better and it's part of the plan first, decouple things, try to do things.

I mean, we're even thinking internally about how can we communicate GitLab with new org. But for that we need to actually have the, the issues living on GitLab. So yeah, it's part of the roadmap and we are always constantly thinking of how can we simplify, how can we make it a bit more streamlined? And we are aware that right now it's not, but it's needed.

Martin: That sounds good. So I guess then also on, on sort of, you know, that topic of attribution, are there certain kinds of contribution that the new system, you think are going to sort of better you know, reflect the, the contributions of people that maybe weren't necessarily being reflected before I.

Tim: I'll talk to this a little bit. I think, you know, we already mentioned the localized example, which I think is a really important one. So there's sort of two categories of non code contributions that I like to talk about when I speak to those. So one of them are non code contributions that are tied to drupal.org activities.

So for example, if you create a community event node to, to, to promote your meetup, if you sponsor one of those community events, if you translate strings on localize, if you, whatever it might be at activities that take place on drupal.org are all opportunities. For us to tie in automatic crediting in some way, whether in some cases that's generating a contribution record where you can do full attributions.

In other cases, it might be much more simple. We might, for example, we might say translations happen on individual screens. Strings, right? So you might do hundreds of them. You're not gonna wanna attribute every single one. So when we do that, we might say. You know, we might have a default attribution for your localization work.

That'll, that'll handle all of them. We might, we might do something like that. I think the other element of this is we, we technically have the possibility of having these contribution records linked to not just GitLab issues, but possibly other external systems. There are still some folks and some important projects hosted on GitHub.

We'd love for people to be able to move over now that they'll have all the tools that they expect. But that possibility will exist too. And if there's good reason for people to be maintaining an integration project offsite it opens up the possibility to do that as well. And then, yeah, that, that last category of contributions is activities that take place maybe in person or just not on Drupal org itself.

And for those you know, we can either, we can create new ways to create those contribution records under the new system. So, so.

Nic: So theoretically, what about something like, I don't know, a podcast that happens weekly with a group?

That's

Tim: nice. Yeah, I know. I mean, I know today that you all, you all create issues for them and, and use that to get to the crediting ui hypothetically.

This is the kind of thing that could be, could be simplified to be a, a record that doesn't need a separate issue created or something like that. We, we'll have to evaluate all those things. Our first priority is the issue migration itself, and then some of the known, like fundamental activities like localization work and things like that.

But I think it's totally on the list and I think it would be, I think it would be an amazing enhancement. One, one of the best things about the Drupal contribution system is that it does reflect contributions outside of just the code base and gives us a huge amount of visibility into. How the community supports marketing activities, evangelism for the community mentorship all of these other things that a lot of other communities and the open source ecosystem as a whole know, are important, but really just have the vaguest understanding of why that's the case.

So definitely continues to be an area to, to invest in.

Hayden: What about issuing credit? Like, so I think it's really cool that underserved kind of. You know, it takes a village to do open source software, but has the, has the philosophy around, you know, giving credit remain the same or has it widened with the new stand, with the new system? Like, you know, that's, is is this is it?

Yeah. Sorry. Yeah, I'll, I'll stop my question there.

Tim: No, no, no. That's a really good, that's a really good question, Hayden. So, mixed answer. So the tools themselves are fundamentally work in the same way, in that ultimately the discretion for granting credit is given to maintainers of projects or is given to, you know, the, the author of the community event node to say who the sponsors are or all these different sorts of things.

But you know, there, there is a, there's a whole separate set of, of conversations continually going on about what should the standards be that projects can share for granting credit. Right? And this is a, this is while not directly tied to the new system, this is part of the ongoing maintenance of the contribution system as a whole, right?

We need to look at are there new behaviors that seem like they might be gaming behaviors? Are there are there. Changes in standards that we need to look at because AI is used more frequently in contribution. And what's the difference between an AI slop contribution and an AI assisted contribution and which ones should get credit, right?

So there's various sorts of discussions for things like these. The fundamental criteria is basically the same though in terms of the credit is granted to who the maintainer deems credit worthy, and that's, those standards are documented. Like there's an official Drupal core maintainer policy that is, that is the suggested standards for crediting that can be followed by a lot of contribution maintainers.

But that's something that'll be continuously evolving just as we evolve the system. So,

Nic: I was just gonna answer the question from the perspective of somebody who grants credit and receives credit as well. Yeah, because I, I think it's an interesting, it's a, it's a great question actually.

I could, and I think the short answer is what Tim just said, right? The standards haven't changed. We're just changing how they get applied. But the truth is there's a very, very wide disparity in how credit is applied. Core. Core is, I mean, there's differences between different maintainers, slight differences, but in general, core is very consistent and very strict, which is why I think one of the reasons that I think those credits are weighted a little bit more in the marketplace.

Contribute ranges everywhere from, or, or like contributed modules and stuff, ranges everywhere from they just give credit to anybody who has comment on the issue to, they never give credit anywhere, ever. And think that credit shouldn't be a thing on Drupal org in the first place. Honestly, Mo is in between, right?

Like I, like I personally am much less strict about renting credit in contr modules. I maintain then core. Because I think the barrier for contribute is lower. And so the expectations for the and it's not weighted as much, right? I wanna encourage people, I'm trying to encourage people to help me out on projects that I maintain.

So, you know, granting credit is one way, but, but like Tim said, I'm sure, I don't know if you knew how much of your time will be spent trying to stop gaming the system when you first put this out 10 years ago? Yeah. But I'm sure a fair amount of time is spent I'm not sure. I know for a fact a fair amount of time is spent, prevent trying to prevent people from gaming the system.

But yeah, the actual criteria hasn't changed. I think. Yeah,

Tim: it's, I'll, I'll add to that a little bit. Which is that one of the interesting things is managing gaming stuff is a noisy part of it, but it is not. Like if we should, if we were talking about by sheer volume of contribution activity happened, it's still very fractional.

Like the, the while, while that requires the most manual intervention, perhaps there's so many, you know, the vast majority of contribution doesn't require manual intervention from an administrative perspective from us at the da. Right. It's a process that works between those maintainers and contributors and like, I suspect that the credits we're responding to in terms of reports of potential gaming and stuff, is probably between five and 15% at most of the total attempts of attributions.

And I suspect it's on that lower side. So while it, while it is sort of noisy, I wanna be careful about drawing the line between what takes time and what impact it has on the total volume of the system. Yeah. I think that. That's important. And then I do also wanna say, I agree with you that the standards are different in different projects, especially in the space.

And I think that's a fine thing. I think there's not potentially we could do more to say like maybe we could provide some inline text to the maintainer when they're on the record that's like, here's some suggested standards or whatever. But like, overall, as you say, Nick, it's, it's largely to encourage people to participate more in the community, to encourage their employers to see the value in them participating as contributors.

And so that can be freely given and in contribute. Usually the volume is less, and because the credit waiting is less, you know, you can be less strict because you have the time to manually evaluate. So yeah.

Nic: Yeah. I, I, I think it also depends a lot on how many projects that maintain or maintained, right?

So for example, I just recently got a, an issue open by somebody doing the whole. Convert from t to this T with the string translation trait in, in issues. I, I only maintain a dozen or so modules, so it's not particularly noisy for me, but I know that particular type of issue is something that a lot of maintainers are hesitant to give credit on because every single project they have is getting these issues open.

Multiple issues opened on this. Anyway, Mo moving back to the, the show notes. I think I have a quick Yes no question. Does the new system rely on get commit messages more or less than the previous version?

Tim: So both of the old version and the new version, the get commit messages do not impact the credit.

So contribution credit has always been independent of get commit messages. There's always been some confusion on that point though, because. The get commit messages, try to include the same people who are part of the contribution just so that they are in the GET history. But the reason those two aren't intertwined is because that is a very code centric thing.

All sorts of things we wanna credit have nothing to do with code and therefore wouldn't have get commits. So we do try and make sure that the get commit has information about who worked on those issues, but they're not tied to the credit system.

Martin: Yeah, I'll say that as a maintainer myself, I think the other reason why they, they feel intertwined is that a lot of people, myself included, rely on sort of automated tools to generate the release notes.

And those are a hundred percent, well, when they're done automatically, the ones that I've used have always been based on the, the get commit messages. So to get the right release notes, you need to make sure that, that the commit messages are actually right. And so that that's fair. Yeah, and I mean, I guess on that note, given the fact that the, the newer sort of updated system seems to be using a slightly different structure to the get com get commit messages that it generates, has there been any dialogue with people that maintain, you know, popular maintainer tools like, you know, Matt glam with MRN to make sure that those tools will be compatible with a new sort of commit message format?

Tim: Yeah, so couple points on that one. One is the commit message format. Like the standard for what that is, is is owned by core. So they're the ones who ultimately determine what the commit message format, the standard commit message format that we generate automatically should be with us chiming in on what the constraints are for what's possible, basically.

And so. There, there was a change with that, that basically aligned with this change to the contribution records. It was sort of semi coincidental. They had been working on a suggested update to that format for some time and we were collaborating there and we were like, well, we're changing some other things.

We'll tear off the bandaid and include that change as well. To my understanding, Matt Glam is following that issue for the MRN stuff, but, and I think most of the right folks are, but I'll be totally honest, I don't necessarily know all of the third party tools that are out there that people might be using related to the commit management stuff.

So certainly if any of those folks are listening, I'd encourage you to, to reach out to me and I can point you to the issue where that work is happening. You can certainly, I think, find it on your own if you search commit message format in in the core issue queue. But

Fran: yeah. In every single contribution record page, the desu is linking there because we actually have the old Oh, that's right.

Commit. The old commit message and the new suggested commit message. And yeah, the old one is supposed to be temporary. And there is an agreement on what Tim mentioned on that issue where a lot of people are, are just yeah, giving their opinion and try to agree on, on a format so you can find the link on every single contribution record.

Hayden: So I'm gonna butt in real quick and just ask about this. 'Cause this, Phil, I mean, it's clear that this is like the catalyst here was the GitLab, you know, kind of migration, right? You had to decouple credit from hundred percent your own issue system. So is the process right now stable or is it in a transitional state like.

How does the new system kind of really fit in with the GitLab migration? And when can contributors or maintainers expect should they expect another shift in the crediting process in the future? Like, you know, the questions kinda wrapped up into one.

Fran: Yeah. I'll answer that on, on the very, very short answer is no.

The contribution record crediting process should remain completely identical when the issue is migrated to GitLab. And it was actually designed with that premise in mind. Actually, when we, I mean, we've, we've now created contribution records for every single issue. Once we migrate the issue, all we need to do in the new system is to update the link that it points to.

But the information, the ui, the absolutely everything, it's identical and it will not change even when we are with using Gira.

Tim: The issues themselves will change naturally. You'll be seeing the GitLab issue interface instead of the drupal.org issue interface. Those issues will be gone. But, and, but you'll see this, this is what will reduce us.

We spoke earlier about being on three systems. We'll be consolidating down to two, right? So you'll be, you'll be in the single place where you're managing your GitLab issue, the ME request, all of that on the GitLab side. And again, we'll have the integration that posts the link to the con contribution record in a similar way to how we're doing on the old old issues.

And using that just for when you need to use the, the contribution management or get the, the pre generated commit format. So, yeah, it should, what you'll see is a simplification of the number of different places you need to. Look, but the, the actual record itself and attribution process will all be the same as what we've just changed to, which is important because I know there's been a little bit of a learning curve and people have had to reset their default attributions.

We are also tracking feedback on the UI and on the, like the instructional materials. So we might make some tweaks that are just designed to make it a little bit more intuitive, but it, but yeah, nothing fundamental. Yeah.

Nic: So I, I guess my main question there is once we do move to GitLab, have you guys explored like, including this as like an I frame or a widget or something on the page is, is there a way to customize GitLab issues so that it can just be in the page somehow so that you can not have to go to another page?

Or is that just not

Tim: possible? Un unfortunately, GitLab is not an extensible system in the same way that Drupal is, and almost any type of change is effectively hacking core, which has real severe implications for how we manage security updates, regular updates of GitLab itself. So we, there isn't really a way to do a directly embedded version of this contribution record.

Maybe one day that will change and in, in the way they do this. But what, what we can do is system-based messages that get posted back to the issue and we can create a couple of custom. I forget what they're called in GitLab, they're sort of slash commands that you can type an issue. Yeah, yeah, yeah.

So maybe you can speak to those a little bit, but

Fran: Yeah, I mean the, the, the option of, of INCE is, is just non, non-existent on, on GitLab. But yeah, we are actually considering talking like planning possible ways of integrating. I mean, the same way that we have Drupal talking to GitLab, we can also get GitLab talking to Drupal via web hooks.

So we are considering the possibility of creating custom commands where we can say, create a fork or attribute it in these people or things like that. Obviously we are trying to do one big step at a time. First we are focusing over our energy and having the GitLab. They issues roll out to GitLab.

Once they're in, we, we try to facilitate the communication between the two interfaces.

Nic: Is is there an upstream GitLab issue like requesting this feature? Or

Tim: So there have been a few upstream GitLab issues for other necessities that we have needed and they've fulfilled some feature requests. That, that, speaking of the overall timeline of this, there, there, there's been a few of those over the past.

For this specifically there is a, there is a broad issue about, there might have to dig it up. So this might be something we follow up with afterwards, but there's a broad issue for the ability to add some kind of plugin or extension thing. But it's a big, big architectural thing that for the most part they haven't they haven't expressed interest in adding to their overall roadmap.

They use a sort of 80% rule. Would 80% of our customers need this feature? So I'm not anticipating it in, in any kind of near term capability and that that's been open for like five years because we predicted maybe we might one day need it. Yeah. So, and, and one thing I will say, actually just this is a good case study for some of the trade-offs with the whole notion of doing this GitLab migration, right?

When we originally did a developer tools evaluation for drupal.org and said we wanted to modernize, we knew that the trade off of, of using an existing off the shelf system would be, we would lose some customization functionalities, and we had to make the choices of what we were willing to lose and what we're not.

Right? We're not willing to lose contribution records. And so we, you know, Fran put together this whole capability, but we are will, we are losing the ability to edit the UI and the elements that appear in that UI on the issues themselves, the lab. So.

Nic: Speaking of timelines, I know the new contribution record system is live and being used. What, how does this impact kind of, and can you talk about the timeline for the full migration to GitLab issues, or, or is that something that you have to still kind of keep in the nebulous feature

Tim: when I ing? Sure, I'll, I'll answer the big question the million dollar question and then Fran, I'll let you speak a little bit to, to what's involved.

So. Alright. First caveat, I try and be very careful about promising timelines and milestones in all of our communication because open source is hard and DA engineering team is five people serving thousands and thousands of developers. And and one of those people is me and I'm not even getting to do engineering these days.

CC levels just go to meetings, right? So, yeah. But, this audience of people. And having been a guest on this podcast a lot of times, I'm willing to say that we do have some things that we're very hopeful for. We are going to try to have a minimum of one project opted in as a test example case of the issue migration when we arrive in Vienna in just a couple weeks.

Nic: Oh, wow.

Tim: And, and that will represent the beginning of being able to do an opt-in process. To nominate the first projects and there will be, there will be an element of, of iteration to this where there'll be some criteria for who we're willing to opt in. You know, there won't be a rollback offered, so it's gotta be people who are willing to take that disruption.

We wanna start with projects that have less than a certain number of issues at first. Again, just to avoid the issues of dis potential disruption. We'll likely start with some Drupal Association projects because we are responsible for them. So the only, only people we can hurt are ourselves, all that kind of stuff.

But we will open an issue where people can nominate and say, Hey, I'd like to be an early adopter, and things like that. And then we will use those first folks to gather a little bit of feedback afterwards and be like, Hey, was our translation of the metadata to labels working for you? Are you, is the new workflow working properly?

Is there anything we missed? And once we've got that feedback, we will start doing waves of additional migration. So that is, that is the approximate plan with a very, a very hopeful timeline of being able to show the, the very first of it basically in Vienna.

Nic: Wow, so three weeks. Oh yeah. That's exciting.

That's a lot of pressure. Yeah. D don't worry, I, I'm a developer too, so I take those, I take, I I understand that timeline. I will take it with a grain of salt. I understand that A lot of stuff can change in the meantime, so don't Yeah, I won't, I won't hold you to it. You understand? Don't worry. I'm

Tim: trying to protect my team members like Fran and Yeah.

Lenny and everyone on, on, on their, their level of stress and commitment here. But yeah,

Nic: I will, I will. But we will not, the talking, I'm speaking for the talking Dral community. We'll not hold you to the timeline. I, I do, I do have some projects though that might be eligible for that testing too, and I'd be willing to, to help out with that if you want.

So lemme know when you get that opt-in issue and I'll, I'll so friend. Anything to add to that? You know, what do you, what, what kind of testing have you been doing? I, I can't imagine testing this level of migration. Never, nevermind. Issue credits, which are kind of like a separate like. The, the form itself is not ultra visible.

I can't imagine the migration process or issues.

Fran: Yeah. I mean, so we, we do have speaking to how I've been doing the testing, we have developed members since of seven. We have developed members of, and we have developed members since of the new stack. And yeah, I've been literally connecting those together and running the scripts is just yeah, setting tokens in, in a few places and running a few commands.

Yeah, I've been able to run successfully both small bigger projects. I mean, the smaller project, the, the project that I normally try it on funnily enough is config notify, just because I am familiar with it. The biggest project that I've been trying is being webform. Yeah. Both of them have run successfully from beginning to end.

And you didn't start with

Nic: core with 120,000 issues or, or so,

Fran: yeah, I mean, our development machines are a bit slower than the production system, so yeah. I, I didn't want to have have it running all, all through the weekend.

Nic: Sorry to diverge like again, but will this solve the issue that core issues have where once you hit like depending 400 comments or so, they just die?

Like

Tim: it's, it's really 200 comments actually. I think it's, they start slowing things down a lot. Solve is an interesting question. We are going to be exercising how well GitLab does with really big issues. Okay. Yeah. Obviously it'll be a totally, it'll be totally based on GitLab's performance rather than our own system performance.

So, and we think they scale pretty well, but we're gonna see.

Nic: Okay. And, and one, one final question down this rabbit hole. Have you talked to Nod or Theodore Theodore about his bot migrating to the new system as well? Because I imagine he'll need some updates.

Tim: So we haven't yet. We will need to do that.

We're gonna, because, so, because we're gonna start with that kind of opt-in period, that's what's gonna give people a concrete like target to develop against for things like bots and things like that. So like right now, we, we could have some precursor conversations about that, but like, it would be in the abstract.

So, we're, we're gonna, we're gonna do that as we're like, alongside the period of those, those initial kind of test projects.

Nic: Okay.

Martin: Very cool. So now that the new contribution system is live and people are actively using it, what kind of reaction and sort of community feedback have you gotten so far?

Tim: So, Fran can speak to this a little too.

I'll, I'll be brief, but this is a, this is a good microcosm of, of, of Drupal community participation and feedback in general, which is, I would say the majority of people are really happy to see this, largely because it represents a milestone on the way to issues. And everyone is very, very excited about that.

Very. We have had a number of, of, of items of feedback, again, about the, oh, it's an extra click now, like we've talked about here. We've discussed most of them, the ones that, that, that, that have made sense, right? So the extra click, the commit message format had some feedback, the just, just little pieces here and there.

There was also just a little bit of, of troubleshooting after the initial release. But at the DA you eventually learn to, to tell the difference between, between the feedback that comes in because people ha have this commitment to the thing because they fundamentally care about the thing and feedback that comes in as just sort of critical noise, right?

And we, I think if you're a contrib maintainer, you've seen that, you've seen like the, the meaningful feedback and the noise feedback. If you're core maintainer, you've certainly seen that. And we see that a lot for, for things we roll out in the da. And I'm, I'm really happy to say that's been like 98% that that kind of critical feedback from people who are committed and really care and friends been, you know, ace about responding to those quickly.

So

Nic: yeah, I mean there, there's been a couple. I, I will say if I were you guys, I would've been very nervous about this rollout for, for two big reasons. One, it's so much data to migrate and rollback in that situation is very difficult. I mean, that would've been. I mean, I've done these types of migrations.

It's very stressful. I, I sympathize with you, I empathize with you. The other side of it is like you, there is, there is a user experience regression, you know about it. The extra click is regression. It's necessary. The, the, the ends is worth the means. I, I understand it, it's a non-negotiable, something that you had to do.

But anytime you're, you're regressing something like that, it, it's pretty painful. And I'm, I'm glad overall the feedback has been mostly constructive. I honestly, I think the only two pieces that I've seen that are like things that could be worked on, which I think you have, is and, and I know it still, it still happens to me sometimes, which is the, sometimes I end up on contribution records.

And I'm not logged in. Yes. Right. There's no like clear indication that I'm not logged in. So like there, I did see at some point there was a message saying, Hey, log in. That I don't always get that. Still. Yes. So, but I know you, you guys are, I know you guys are working on that working hard, but that's the only like real regression that I, I I know that Jurgen had to reset his default attribution a few times too.

Yeah. For me, the,

Fran: the, the question of the regression is I mean, the way we see it, once you understand the context is that you need to give one step backwards to, to give three forward. And that's kind of where we are at. I we are aware of this kind of yeah. Oppression there. Yeah. It's, it's a necessary, it's a necessary step.

Then Yeah. In terms of feedback, yes. So those are the small changes that we've been rolling out. I, we, at the beginning, we had no differentiation on the new site where whether you were locked in or out. Then we added, I mean, you, you, if you have a picture, you will see the picture. If you don't have the picture, you will see your initial on the top right.

And not everybody looks to the top, right. So then we started, we put a message with with the messenger service for anonymous versus non-anonymous, but sometimes it wouldn't, it wasn't showing. So we actually decided to repair that. And now it's JS based. It's Java is JavaScript driven. So if you actually click any checkbox, it will tell you you are not, not, oh, you need to interact.

Yeah, okay. Exactly. I didn't interact with

Nic: it.

Fran: Yeah. If you are not making any changes, then you are just viewing it. But the second that you do anything, then it will tell you whether you are locked in or not, whether you are maintainer or not, and all this all this kind of things. And even like that we are taking some very valid feedback from people where maybe we can add some more verbose text in some areas or maybe create a help page and we add a link to it.

So yeah, those are small changes that we've been adding in this last couple of weeks.

Tim: I just got a request this morning to create a video that shows how to change the default attribution. So we're probably gonna record one of those and link to it in, in some place. But yeah, you know, this is this is change management and, and education stuff, which happens with a lot of major initiatives.

The Drupal core team has to handle this stuff as well all the time, run out. There's a new major API and things like that. And, and for us, like this is one of those things, right? And we'll have another round of this when those issues go live and people begin, begin working with those. So,

Nic: yeah, I, I, I can't wait.

I'm, I'm excited to kind of work closely integrate there and, and see how that works. But yeah, no, great, great work.

Hayden: I, I have to, so I have to just say from a, someone who's not a maintainer of a, of a Drupal contributor module or a core or a contributor, I think it's pretty cool. From the Drupal sense, right?

Yeah. It's kind of this rebrand of recognition. It's broadening kind of the scope and definition of what contribution is. And it feels, not to discredit any of the work that's been done, but it feels like this great first step on making formalizing credit, making it transparent from the outside. I'm wondering like, well, where does it go from here?

Because like, I can imagine like, cool dashboards, maybe gamification. I know we talked about gaming the system, but, you know, and even like, you know, we haven't really even talked about how, you know, this could affect companies. It's like companies getting credit. It's like, I could see reports being pumped out that's like, Hey, company a Macy you know, dot io contributed a thousand hours of ai.

Yep. You know, testing. That's, that's cool. 'cause I feel like that's not just recognition, it's like kind of like storytelling fuel for companies and for the Drupal Association. So looking ahead. What do y'all think is next for the contribution record system? Are there any ideals on the roadmap or is this, are we just keeping it to record keeping for the time being?

Tim: No, I think there's a lot coming up that follows this. The issue migration itself, as we've been talking about, some of the other examples we've mentioned, like localize and some of the, the non code activities that happen on Drupal drupal org, like event organizing and things like that might get some enhancements.

But yeah, I think one of the areas we do wanna look at reflects something that you just said, which is the, the way that contribution. Affects the business ecosystem and that just the overall ecosystem management of sponsorship of contributors and all of those kinds of things. So I don't have a specific feature list to highlight, but I think we wanna keep looking at how we are incentivizing companies to give their staff time to contribute.

We want to launch a more formal program for how we want to credit people who might sponsor a core maintainer. We're already in the background doing some private vetting of some of those concepts and a few things like that. So, so I think there's, there's always more to build on here. I also it just popped into my mind, but another thing that was really cool to see is.

Sometime in the last year, the GitLab team implemented a, not the same as our system, but an inspired by our system way of tracking contribution to their, to GitLab core. So they actually have a dashboard that has a similar sort of thing of code contributions, docs contributions, some non code staff.

And I happened to know that several Drupal staff went over to manage that team. And so, and they, and they brought some of those ideas there Drupal community folks. And so that's really cool to see because in the very long term, what I'd like to see is something like our system adopted as a standard in a lot of other tools and in a lot of other communities.

And that might even let us, that might go to, Hey, we have a system in GitLab we can use to make it not an extra click. Eventually. Who knows? That's the pie in the sky, five to 10 year stuff. But I'd love to see it because I'd love to be able to compare apples to apples, the contribution health of Drupal in other communities.

So.

Nic: I mean, one, one of the, one of the big things they see that there are a couple of detractors of the credit system that I think that you, you see fairly often say like, Hey, people contribute to other open source software without the credit system. And, and they've announced plans of once, once everything moves to GitLab on their projects, they won't provide credit anymore.

But the, I, like I said at the beginning of the show, I think it's one of the crown jewels of the Drupal community. And just because other systems don't use it doesn't mean that they wouldn't benefit from it or wanna to do that. Like a lot of like just thinking of home assistant, right, which is a very active with a huge community, open source home automation system.

Like they don't, they don't do a lot of the non code contribution stuff, but. Every month they have release, and the release notes are second to none. And the people that maintain it put out a list of everybody that contributed. I don't know if it's everybody, but almost every issue. And people that worked on those issues and maybe they'd be interested in this kind of thing.

I think it would be, I think it would be really valuable for a lot of open source projects and not just like CMS level projects. It's just open source. Yeah. I'd love to see how other communities would be able to adopt it. You know, maybe I'll, maybe I'll just send this over to the home assisted people and see what they think.

But

Tim: the, the thing is, yeah, I hundred percent agree and I think what, what a lot of people don't realize is the potential it has for. Further fostering that contribution stuff. Just as one anecdote, when we announced the Drupal CMS when d announced Drupal CMS as a, as an initiative for the Drupal community, and I mean the, the Drupal CMS edition, not obviously Drupal as a CMS, but the, but the special recipe based, easier to use edition.

For the very first time we saw the ability to use credit as an incentive to recruit. Organizations as track leads within that in a way that we've tried before but never been successful with before on like a fundamental, strategic, strategic way. And it's just amazing how much this kind of recognition at an institutional level unlocks that ability to, to, to, to sponsor contribution time for people.

And I just, yeah, I, I think, I think the case for the value of it is, is maybe not something people have in mind in, in some other open source projects, but I think it's, it's pretty clear when you spend some time thinking about it. So anyway.

Nic: Okay. We're, we're getting close to wrapping up. Kind of a follow on to what Hayden just asked, by the way. Is there sorry. Actually friend, you were gonna add something, weren't you? I saw, I

Fran: think yeah, I mean, I was gonna say before, I think Hayden mentioned the, the possibility, the possibility of breeding dashboards and all that, and one of the hidden gems that is there.

Is new endpoints to query data where you can just put the username or you can put the, that was gonna be my question. And those are actually the endpoints that we are using from seven to query the data from 10. And they are very powerful and they can give you very, very cool information. They are somehow documented in the README file, in the contribution records module.

I am, I'm populating the links on the, in the notes of the show, so yeah, you can, you can find them there.

Nic: Perfect. Yeah. I, that, that exactly is gonna be my question. Is there a public, API, 'cause one of the things I'd like to start doing, like I can go to my dashboard or my account and see like, oh, I have x number of credits for this or X total.

But one of the things I'd like to see in general is like over, if I could see over time how that's built up or like there's the there's the GitHub project that show that lets you pull down. The number of contributors based on commit message, which goes back to an earlier question from Martin, and it's interesting to see per major version, top contributors, that kind of stuff.

But I'd love to do a similar kind of analysis in the last 10 years of, of, you know, the credit system. You know, who's, you know, who's, I think Dre used to do annual like company and person personal contribution records and things.

Tim: Yes, yes. That's actually, that's a report that I work on with him and run, pull a bunch of the data for and process.

It was fun because you don't often see Dres writing PHP data processing scripts, but he, he did with with the raw data and it was, it was cool and I'm sure he enjoyed the chance to work on some code, but

Martin: Yep. Yep. I, I know of, there's a project, it's somebody in the Drupal community, I think he used to work at Accelerant.

I'm not sure if he still does, had actually created kind of a little, hP system that, that could query the, the drupal.org API and pull down contributor information. So the idea being that if, like, they used it internally, sort of for their team to just see like who are the top contributors within a specific team.

But I always thought it would be really cool, like if you're at a big company where you have maybe multiple Drupal teams, you could almost gamify it a little bit to see like which teams are contributing the most or some of those kinds of things. So, you know, having those, those richer APIs, I think, you know, potentially unlocks a lot of, you know, interesting ways that, that information could, could hopefully help to drive even more contribution.

Tim: Yeah, yeah. Speaking, speaking to that, oh, go ahead Fran.

Fran: I'd say that these new endpoints are way more powerful because it gives you the information that you need. Whereas the other tools that yeah, you mentioned and other users have, they are just based on scraping data. And they need to go through a lot, then process it, whereas these new endpoints process it and then give you the data.

So yeah.

Tim: Yeah, it's a big improvement. And I've worked with some folks who've been, who've done some things like that, Martin. So like the local gov ecosystem of local gov related modules. I've, I've sort of privately worked with them to help gather the data on that ecosystem and which areas were receiving contribution and things like that.

There's, there's been a few others as well, individual companies who have. We'd love to run an incentive program for our, for our contributors. And you know, I've gone in there and done like even a training session with 'em and I've talked with their leadership to say, okay, well here's what you should do and here's what you shouldn't do.

Right? You should not, you should not tie contribution credit to compensation, to, to performance reviews, right? That would be, that would be the anti-pattern and the bad habits to get into. But doing it as a rally around like, making people feel engaged and committed to, to the open source project they work with every day is good for job satisfaction.

It's good for the project, it's good for developing expertise. So yeah, I think there's tons of opportunities.

Hayden: Awesome. I think I think I, one, one thing to add on, because this is, once again, someone that's coming from, who's only been in the Drupal ecosystem for two years now, is I think. The gamification of contribution would help immensely as you try to get newer developers coming outta college to, to try Drupal, right?

It's like, you know, like that kind of thought process in my head would make me want to say like, oh, cool, I can, I can contribute and see an instant result on the backend of like, of my basically, you know, gamifying my progress or career ladder or like, you know, my community involvement. That's cool. Yes.

Yeah. It doesn't make someone feel established, makes someone feel like they're part of it and they can point to their little dashboard potentially one day and say, look, I've, I've done, I've done stuff in this space. That's really cool. A hundred percent. A hundred percent a resume builder.

Tim: Yes.

Absolutely. Yeah.

Nic: Yeah. I mean, that, that's very accurate. I mean, a lot of development companies, people ask for your GitHub and they might still do that in Drupal, but really in Drupal, they ask for your Dral org account and, I mean, it just shows it right there. Right on the Tim. Well, Tim and Fran, it's always a pleasure to have you guys on.

Thank you for joining us to talk about the new contribution record system.

Tim: Thank you so much for having us. It was super fun. Yeah, thank you very much.

Nic: Do you have questions or feedback? You can reach out to talking Drupal on the socials with the handle Talking Drupal or by email with [email protected].

You can act. You can connect with our host and other listeners on Drupal Slack in the Talking Drupal channel.

Martin: Want to be a guest host on Talking Drupal or our new show TD Cafe? Click the guest request button at the sidebar at Talking Drupal.

Nic: You can promote your Drupal community event on Talking Drupal.

Learn [email protected] slash td promo.

Martin: Get the Talking Drupal newsletter to learn more about our guest hosts. Show news, upcoming shows, and much more. Sign up for the [email protected] slash newsletter.

Nic: Thank you patrons for supporting talking Drupal. Your support is greatly appreciated.

You can learn more about becoming a [email protected] and choose to become a patron button. All right, Tim, if our listeners wanna get in touch with you, what's the best way for them to do that?

Tim: Awesome. Yeah, you can find me as hest all over the net, including on drupal.org. From there, you can find contact information, email, whatever.

I'd be happy for anybody to reach out to me. I'd like to give anyone that time if they need it. Please consider joining the Drupal Association membership program called Ripple Makers. Like I said, we are a nonprofit. We try and do a lot with very, very limited resources, and we also do a lot of work too.

Amplify every dollar. So, for every dollar we spend, we have secured 40% of it. As in-kind trade, we've gotten 30% of it from sponsorship, all sorts of places. So we, we try and make the most of every dollar that you contribute. It's really very helpful. I hope you'll also consider joining us at DrupalCon.

There is still time to join us in DrupalCon Vienna in just a couple of weeks, especially if you're a European listener. It should be hopefully relatively easy to get there. Early bird registration for DrupalCon Chicago has just opened up. If you didn't see that announcement and a DrupalCon NARA is coming up in Japan in November, which should be really, really cool as well.

So hope you'll join us.

Nic: Awesome, Fran, how about you?

Fran: Yeah, I'm not in many social networks, but I am very active on the community slack. So you can just look for FJ gardening or Fran Garcia. Yeah, I'd be more than happy to help you.

Nic: Perfect. And Hayden, how about you?

Hayden: Exactly opposite of Fran. I'm just kidding.

You, I am on the socials, but you could just connect with me on LinkedIn, Hayden ba I believe I'm one of the only Hayden Baillios out there. Or I am on the Drupal Slack at Hayden Dalio. So yeah, reach out.

Nic: Perfect. How about you Martin?

Martin: Folks can find me as man clue on all of the Drupal and social channels.

Or if they want to keep track of what I'm up to, they can go to man clue.com.

Nic: And you can find me pretty much everywhere at Nicks band, N-I-C-X-V-A-N

Martin: And if you've enjoyed listening, we've enjoyed talking. Thanks guys.

Nic: See you week.

Tim: Alright, thanks everybody.