How to Land an EPIC Contribution in Drupal (Without Losing Your Mind)

This talk explores the intersection of people skills and technical contributions within the Drupal community. The speakers, Matt Lman and Mike Hershel, emphasize the importance of communication and collaboration when contributing to Drupal, highlighting practical strategies for identifying issues, forming teams, and navigating the complexities of project contributions. They share personal experiences, including the development of responsive grid displays in views and enhancements to the development settings form, showcasing how addressing minor annoyances can lead to impactful changes. Attendees are encouraged to engage with the Drupal community, leverage available resources, and be proactive in their contributions, reinforcing the idea that even small fixes can greatly improve the user experience.

going to How to land an epic contribution in Drupal without losing your mind by myself, Matt Lman, and Mike Hershel. >> The alternate uh the alternate title of this is the people skills of getting done because it is about people skills more so than even technical skills. >> So, as you see, I've already lost my mind and now we get to talk about it. So, hopefully you

don't either. Um, again, my name is Matt Lman. I'm a principal software engineer at Aquia and a lead working on Aqua Source. Uh my name is Mike Hershel. Um I've been involved with Drupal for almost 18 years, which is like a little ridiculous for me. I uh I'm responsible for uh I'm the primary dev behind Drupal's default theme called Aloe Vera. I work a lot on the

front end side of things and I help bring single directory components into core. Uh, I have a company which is the best company ever called Dripyard that makes uh premium themes and site templates that are amazing, accessible, and beautiful. And yeah, I think that's All right. So, behind every great feature is a stubborn person who refused to let it stay broken. It's kind of the main theme

here behind all the contributions. >> So, what does it mean to be epic? those things that make will make everyone's life easier on a daily basis or paper cuts. Crap that annoys the heck out of people, right? So, um Oops, I'm going a little forward here, Matt. There we go. Stuff that annoys the heck out of people. Um, an example of this, uh, at least for me

right now is, uh, like when you create a link field, it truncates the the link text, like not the hyperlink, but actual text by default to 80 characters. And and that's just like one of those little things. It's so easy to fix, but if you add those up, it adds up to like kind of a death by a thousand paper cuts. Everybody hear that term? And and

Drupal has it share of paper cuts, but we can we can work on those. >> Yeah. So, here's what we'll cover so that way you can land your own epic stuff. Um, such as identifying the bugs or features that you want to tackle, pitching the idea, assembling your team, um, doing the actual work, handling the complexities of communication, and then getting across the finish line because you

did all the work, and if it doesn't get committed and released, it's not actually there for you to use. Who here loves Drupal? Who here hates Drupal? Yeah. Anyway, uh we have some uh some usea we have some case studies uh just to kind of talk about some examples of the stuff that Matt and I have done. Um we're just going to yeah, we're going to talk

about this and then we're going to show you how to kind of do your own. One of the things I'm most really that I'm most proud of of getting into Drupal core is is the views responsive grid display. So prior to Drupal 10 when you uh you can go into views and you can set uh you can set your view to output into a grid but prior

to Drupal 10 that grid was not responsive. And this is like something like 2019 or something like that. And you're thinking like what the heck is up with Drupal? It's like living in the past you know. Um, and it wasn't easy to make it responsive because, uh, you couldn't just CSS it because there was a wrapper around every single row. I ended up kind of coming up

with a cool CSS technique. Um, I found I assembled my team. The the backend dev that I that I ended up grabbing was Martin Anderson Clutz, who's also an Aquanian. And we ended up putting the we ended up doing the work. He did the work I think over Christmas day or something and we ended up getting it committed pretty quickly and it was just it was just

like a kind of a fun little story but it's just one of those things that um you know we made Drupal a little bit better from there and then this is one of my favorite ones. So who's used the development settings form inside Drupal? All right cool it's catching up. So, Drupalcon Portland 2022. I don't know if anybody you remember the Dre note from there, but Dre

talk about the ambitious site builder and I was like, "Oh, well, how about trying to disable render cache and turn on twig debugging? What a pain." Um, so I wrote like a blog post about like if we're talking about or I open a drupal.org issue, like if we're talking about ambitious site builders, they need to be able to actually do development. Um, so I opened the issue

and then it sat because I was like, I had this idea, I didn't have time to work on it. Didn't really want to work on it. I was just like blocked here. Mike saw it and he's like, "Hey Matt, you know that thing you did?" It was at Midcamp. He's like, "We're going to sit down and work on it." So at Midcamp 2023, we sat down in

the room, we worked on it. We had people that we had UX folks that were sitting there, some design folks, we had people testing it in the room because it was like a do or die moment to leave Midamp with this thing committed. Um, so we did like hallway reviews like, "Hey, hey, come here. Ping people on Slack like can you just come up with verbiage?" Um,

and it was just really neat because we gave this form which lets you do faster front-end development and we actually fixed a bug in core tests along the way due to how it was handling some in-memory cache. So, it's a neat win for everybody and also fixed the test some tests across the board. >> Uh, for that particular issue like Matt was like over at a table

and I was guarding him. I wouldn't let anyone talk to him until he was like I'm like no he's busy. >> I was paid well afterward. Um, so for who here's a front-end dev? Anyone here do front-end dev? Yeah, we're the best. Everyone else, you know, um, there was an issue early on with single directory components where the stylesheets was were where the component stylesheets for STC's

was kind of outputed before the theme stylesheets and that kind of broke the way that CSS cascades and it was really really annoying because you had to increase your CSS specificity. And so at the time I was building Dripyard themes like like as I as I said earlier, we make awesome themes and y'all should buy it. But uh it and it was making my code a little

unmaintainable. And so I created an issue. We uh like I had someone else kind of dive into it and we realized it was a little messier than we thought it was. But then I ended up kind of bribing him into into into fixing it and and we ended up uh I think we had a talk with Lori to see like hey this is this is a way

to move forward. He did the work. We wrote tests and this is something that if we were running in into it today it would it would be one of those Drupal WTFs. >> Yeah. So those are a few things we did and now we're going to walk through like how you can land some of your own act contributions as well in the Drupal core or other modules.

U one of the first things is like you got to identify things to fix. Um which is the hardest part of identifying what to fix. I think Mike's example is one of the best like he had a business case and was like work is hard because of this sounds like a good thing that and it has a cascading a cascading effect. H CSS cascading um where it

could improve other people's lives. So like kind of that approach most of my contributions have always been workrelated whether at Centuro with Drupal Commerce or at Aqua with well canvas or other things in that sort. >> So uh something that you have to consider is does the fix for this belong in core or contribute in as in a contrib module. And to be fair, that CSS loading

issue that I mentioned earlier, someone had made a contra a contrib module that fixed this. But the thing about contrib modules is not everybody knows they exist. You know, someone has to feel the pain and then they Google it and if they're lucky, they will find that contrib module. And that's a horrible user experience that can that's one of those things that contributes to people like not

enjoying Drupal development, you know. So you have to you have to think like is this something that most people that 80% of people are going to run into or that are going to use or this should be a module >> and I think the development setting form kind of ties into that as well because I'm pretty sure you'd use like the develop module or something of that

sort but then Drupal had a paradigm shift of its own and then it made a case like oh this should be part of core because it aligns with where core is going. So this kind of you have to just kind of see and you can ask around. Um so part of that is has anyone else found this issue or attempted to fix it. So in that regard

we found like the contrib module fixed it. How did they fix it? Okay, how can we get into core or there is like a core bug and there's an exist existing issue maybe you can join in on the effort. Now just because there's an existing issue or existing fix doesn't mean one it's right or that it's active. So don't see that and say oh I can't jump

in. No you can because it probably needs a revitalization if it's still open and sitting there. >> Yeah. So sometimes um sometimes an issue even an existing issue just needs a little bit of energy. So like one of the most important steps if you want to get stuff into either core or contrib you need to pitch it to the appropriate people. So how do you find those

people? So in Drupal core there's a file under the core directory called maintainers.ext. Drupal core is made up a with a of a number of subsystems you know like every single like little module or permissions or security. I am a subsystem maintainer for the olive theme and for the CS and for C for core CSS. You can find a list of these people and you can reach

out to them and in places like Drupal Slack and you can say what do you think about fixing this because it bothers the heck out of me and then if it's not in core contri maintainers so you can go to the project page the upper right you'll see a face maybe you see my face like I saw that guy's talk I'm going to ask him a question

about this um so it's always about like that's you can find us a project page and that's how you can find a list of people who have commit access and can get stuff merged in. Um, and if you don't know or you don't know where to go look, ask around. Um, I've been doing Drupal for 13 maybe 14 years and the reason why I stayed is the

community like sucked me in and I appreciated it. So, just leverage that tool. That is what makes Drupal great. So, ask around. Chances are it's like it's like the Midwest. Drupal is a Midwest. People will be nice to you and give you an answer, not just turn around and say, "I don't know." Um, so in Drupal Slack, there's like the contribute channel and the core development channel

as well. So an example of that like if I want to fix something like I said in the link module I can number one I would look into core maintainers um I would look into that maintainers.ext text. I would see if anyone is in a link if anyone is a maintainer of the link module. And if I don't see anything there, I would post in core development.

I'd be like, "Hey, this particular thing bugs the heck out of me. I don't know how you all feel about this, but who is who is responsible for this little section of code." Someone will probably get in there be like, "I don't know, but this person does." And tag them, and you'll get an answer pretty quick. >> Um, so the key is like how to pitch without

it being annoying. I'm sure we've all had those things where somebody's like, "I've got a great idea." >> So, I would like to say that like as an open- source maintainer, I love like angry emails and DMs. Like that's obviously a bad joke, but hey, this is a great meme. Um, so, um, to not be annoying, identify the problem. Say like this, you know, know why you're

fixing it. It's, you know, um, if it's an opinion, uh, have have some type of try to have some type of data behind your opinion or something >> Yeah. And you want to focus on the why. Be clear and concise. It's funny like I'm reading this book about docs for developers and it's literally just project management and user stories and scoping. So like when you work at

an contribution issue, like if you work at an agency and you like scope fixes your client needs and like the tickets, it's the same thing for doing contrib. It's not different. Just make sure you have a good scope, know what you're doing, and just be clear and communicate with everybody else because everybody's got a lot going on. So the better communication, the better the fix can be.

And tying into that, like come with a solution, not just a problem. I know this might sound a little bit loaded, but there's like an idea. I've had plenty of times like this is broken. It's like cool. What should it not be broken with? Like what what is the end goal? like it can be really hard to like make a fix if you don't explain well I

would like it if it did X or I think because this might be a little bit broken let's go there and that's just something that can grease the wheels a little bit and get things moving kind of like a snowball effect you know you start small and then it can go into a bigger bigger item you want to be respectful of people's times especially maintainers um there's

what like something like maybe 15 16 uh Drupal core maintainers in the world and these are the people that actually have the ability to push stuff into like the main branch in Drupal core. They're constantly busy. A lot of them do volunt are are volunteers. Some of them get paid. Some of them get paid part-time to do this. And so if you're reaching out to them constantly

and and things like that, it's they're going to get a little burnt out with it. And burnout is real like in Drupal. Um you want to you want to be a little bit gentle with it. And we're going to talk a little bit about First, I'm going to talk about making the actual pitch. You know, you've found a problem. You know who to pitch it to. Now,

you've got to pitch it. Um, so one thing you can try to do is save your fingers and talk it out if you can. Obviously, you may not be at a camp or a conference, but that's the one beautiful part about Drupal Cons and the regional camps, even meetups, is you get a chance to talk it out and just be like, "Hey, I've got this idea. Let's

workshop a bit before you go to typing everything down and coming up with a larger issue." Um, and it can also do like faster validation. So again, if you can collaborate with people upfront before you even start making the issue, that can be a huge timesaver. Um, and so if you do or if you let's say you have an idea and you're not sure if you should

make an issue because you're not sure how you should word it because it's like I've got this thing, but is it really a bug? I don't know. That's where you can go into Drupal Slack. I do this at work even all the time. I believe in public communication. I'll go into a channel like I've got this thing because if you put it out there, there will be

serendipity and somebody will have an idea. So like go into the contribute channel. Don't DM, especially when you're contributing. Um, I get a lot of unsolicited DMs. I usually leave them unread purely because I have my mind everywhere else and I don't know if I can answer it. And if you DM me, I can't then go into a channel and say, "Actually, I'm not great to answer

this, but Mike could answer it or somebody else could." Or, let's say we're both busy because we're presenting at Drupal Con. Somebody else could say, "I have an answer to this." So, it's always good for that public communication. And getting unsolicited DMs as a maintainer can also be like a little stressful because it kind of puts you on the hook, you know. I I tend to just

like set reminders, you know, because a lot of they might not quite know like what's proper in in the open source community. So, you know, I I I I tend to like give people a little bit of a little bit of grace and say like, listen, you know, I uh can you post this here? I don't know off the top of my head, but I would, you

know, something like that. >> And to clarify, they're unread. Not because I didn't read them, but I read them. Like, I'm going to leave it unread so remember to go back to it. And then three years goes by. >> He's just an >> Um, and so there's also like creating the issue for the project. If you feel really confident, you know what you're you got the good

scope, you feel it's the right fix to the area, go ahead and create the issue. And also, I mean, like even if you don't, it's not going to hurt making the issue. Issue can be moved around. Um, it can be helpful having the issue to link to. So that way you're maybe not writing three paragraphs in Slack and like I wrote this issue you put into the

Slack like could I get eyeballs on this, you know, just wrote it there, share it out. Um, so like what's a good example of an issue? Let's go to the development settings form. Is it the most verbose? Probably not. But it was succinct and got to the point where I said seeing your changes is difficult. You've got to edit this file and this thing. Don't only partially

copy it because then it will drop values and then by the way copy this samples exetting this example settings form uncomment five lines. I just tried to show the paint in the simplest way possible and that was enough to make other people understand the issue at hand and hopefully set the scope to not be like the what about isms because that's the other thing you have to

battle with. So depending on the issue that you're that you're doing, you're going to want to assemble a team. And your team can look something like that or it can just kind of maybe be you and another person. it depends on the issue. Um like a a typical issue might require a backend dev to do backend type work. It might may or may not require a front-end

person. Um, and but you you likely will require tests. >> And then other ones need cat herders, aka maintainer ticklers, which is Mike Hershel's specialty. Um, >> I'm good at tickling maintainers. >> And it is something like I'm not very good at at all. Um, and you'll need like you might need a UX. And a lot of these apply for Drupal core when there's case like if

you touch an interface, it has to pass UX. Um, and of course docs and a change record writer. I am horrible at writing change records. They're great because they go into release notes and tell people what happened. I write blogs and books. Don't write change records very well. Like that hangs me up. >> I, on the other hand, love writing change records because it's like the final

step. It's like, holy crap, we're actually doing it and it's going to get into core and people are going to read this and someone out there is going to read this and they're going to be like, "Heck yeah, about time." You know, like like I love that feeling. >> Yeah. So that's where it's good to have a team because everybody has their strengths, everybody has their weaknesses,

everybody has their own amount of time. Um and the question is like when you assemble team like how do you know who to ask? >> Yeah. So uh once again like find people that share the pain. Uh post in Slack. Um, if you have people at your company like uh when I did the Aloe Vero uh theme, I was friends with people at my at the company

I worked with, Lullab which is a great group of folks and we assembled a team within there because we worked very well together and and I kind of knew people's strengths. You have to get it really helps to kind of get an idea of this guy doesn't like writing change record but he can write PHP somewhat decently. And this all comes with time. And again, like let's

say that you leave this session on you. I know you're going to leave this session like I want to find something to work on at the contrib. >> Just ask us like, "Hey, saw the thing, felt empowered, but I actually don't know who to ask and go for." Like I said, just ask and we will help point you in the right way because it is one. We've

been doing it for a long time, which means that we'veorked, we've met people, we have we know who to go to. So just ask around, too. And now you've assembled a team. You know what you're doing. you got to do the work. Um, which might be the easiest part is if you've seen there's all that prep work that has to go into it. So, I don't know

if anybody else is like me but absolutely loves to write tests. And I'm not saying that sarcastically like I do love writing tests. So, that's a big part. Um, when you do code, you need to make sure it works. So, like tests like just just have the tests in there because that will be like the first gate. The maintainer will be like, I don't want to set

this up manually and verify it works, but if I see it has passing tests, that's like a gate that gets checked. so they can trust the code a little bit more and handling communication. So this is the hard part right here. So writing the code is the easiest part. Handling communication is the hard part. People are going to people are going to have dis different disagreements. Um

communication of course depends on the style on like the size of of the issue that you're doing. I can tell you for the Aloe Vera theme, what I would have regular regularly scheduled meetings with uh with a core committer, which is generally Lori Timy, and we would we would meet every two weeks and I would go and I would have this list of issues that I set

to like reviewed and tested by the community. And I would watch him review it like over our Zoom meetings. And number one, watching it would like give me a whole bunch of insight on what he's looking for so I can better better prepare for next time. But we would but the but that feedback loop was very immediate when we were on a call. Um for smaller issues

that a regularly scheduled call might not be necessary. Sometimes like a group DM, we have done tons of group DMs. um communication and places like this. We're all like lucky and privileged to be able to be here in Chicago at a Drupalcon, but don't just go to sessions, talk to people, you know? I I see I see m Mike Gford with the red shirt over here. He's

an accessibility maintainer. Like there are some smart people here. Talk talk to people, network with each other, and just like it it Yeah. And before we go into the bike show, like one example is like the boss. If you aren't familiar with birds of a feather, it is one of the best things about Drupalcon. So this is your first hit sessions next time hallway track and boss.

I have a thing that I need in DDev to make get work trees better. And they have a bof about get work trees in about 3 hours. So I'm going to go there before I go make an issue about the one change I need. I just want to go talk it up because I have that ability now. Um, so go take advantage of that before I go

do a bunch of work and possibly have be told no, do a different way. Um, so the next step is like so you've done the work, you have the communication. Um, you need to mitigate bike shedding in the work. I don't know how familiar any of you are with the term bike shedding, but it's like just nitpicking and blowing the scope is how I like to put

it. Like we have the scope. Let's just do this. Like, but what about if it was red? It's like, well, does red actually change the value of the feature? >> so an an example I'm going to go back up to bike shedding. Um, an example of like a real world example of bike shedding while we were doing that development settings form was we were taking like that

form around in hallway track. This was at Mid Camp a couple years ago and we had a lot of people who were very vocal and persistent on the verbiage and the order of like the little check boxes within that within that forum. And Matt and I were like, who the hell cares? Let's just get this in core so people can use it. You know, it's not like

people read anyway. They just start checking, you know, and then we can change we can fix stuff. So the way that I Like I'm a big believer in like perfect is the enemy again. So um it helps once again to know people I reach. So so at this person we needed to temporarily and in this situation we needed to temporarily add a person to our team. So

once again at this point we're talking about UX. I reached out to a u UX maintainer and I said, "Hey, Christina, I don't care what the hell it says, but just put a stake in the sand and say, "This is it." And we can make changes as a follow-up issue. So follow-up issues are a secret weapon, right? We can say like, "This is good enough. This adds

value." And we can change it. It's it might not be perfect, but it's good enough to get in and we want to get it in. Anything else? Follow up. >> And then a lot of the development process is hurry up and wait. You hurry up. You get the code built and then you wait for the reviews and you wait for the committer to say, "Actually, I want

this change." And then as soon as that hits, you hurry up. It's like, "Okay, they looked at my issue. It's in their brain space." I'm sure we've all had that. We have to like upload context once they get in your brain. It's like strike while the iron's hot. Go for the review. All right. All right, once they reviewed, make some changes, and then you hope that you

caught them in that window. Otherwise, you just kind of wait for the next review and do that cycle until it's about ready. If you do it quick enough, you can even say like like if I'm if I have a if I have an issue and I get a review from someone like Alex Pot and I I will if or anyone I will immediate like if I'm lucky

enough to notice it right away, I will have that thing I will stop what I'm doing, fix it in 15 minutes, address the concerns, and if I do it quick enough, I will just say like I I will ping them in Slack and I'll say, "Hey, just FYI, no rush, but if you're in still in the same headsp space, I address your concern and maybe if I'm

lucky, he'll be able to jump back to it while he's while it's still on, you know, on their mind. >> All right. So, you got to work. Now, we got to get you hurry up and waited. Now, you got to get it committed. Um, which involves getting quality reviews from other contributors as we talk about. >> Yeah. So, uh, should we have AI review? >> Yeah. So,

this is one where I wouldn't say having your AI agent do the review and post its comments on the issue as a quality review. Um, mileage may vary. If you want to use that, use it as your own personal review or let the maintainer make that choice. But to then be like, I got this issue up and then I had anthropic review it and it's good to

go is probably people are going to be like, okay, I don't know what you prompted to do it. and like just so again it can be your tool but I wouldn't say there's a qualifying gate that maintainer is going to be like I trust the prompt you wrote and how it reviewed the code um so it can be part of that tool set but just it's your

tool set not necessarily the process that will make somebody say great I trust it and sign off >> so how how do you get like real life humans to review post in Slack you know ask people bug people buy people beers >> or get to RTBC what is it about the internet like post and answer that's wrong and then everybody will tell you the right answer because

they'll want to correct you. That's like not what's going to happen with RTBC. But it's like a gate. When it's RTBC, somebody said, "Hey, we reviewed this. We think it's good enough." That means if it's Drupal core, the core maintainer comes in and gives it that final look because remember they have a lot to look over. So they are really reviewing things that are all ready to

go unless they're like particularly involved. So get it to RGBC is like next gate of like great we'll do the next review which as an issue I'm following gets slapped back to needs work and then you hurry up to do the fix and then send it back to RTBC and you go through that process and like a lot of times you don't necessarily even need to look

at the code you just need to verify that the new functionality works right when you do that post some screenshots and if you post screenshots the maintainers who are looking at this they'll have confidence that you actually did the work and that you're not actually, you know, just making stuff up. >> And make sure they're valuable screenshots, too. But sometimes, like I'll see it's like the status

message and it's like sometimes it's a harder issue, but make sure you get something that proves that the fix is there. Um, and then how to reach out to core committers. Again, this is kind of like when assembling your team. Let's say an issues at RTBC for like a week and you're like, well, this has been kind of bit. just like do the gentle nudge and like

slack like hey this has been sitting here just wondering like when it might be on your plate for a review because I want to make sure I have time to adjust feedback. So always like make it like the two-way street. That's what I like to try to do is like look I know that you need time to do it but once you review it I just want

to make sure I have my time set aside so I can take action on your review so it's not like an elongated process. >> Yeah. Like I have literally pinged people um and you do it in an open channel. You do not DM people like this unless you have a specific reason to. But you say like I I say gentle nudge on XYZ, you know, this is

ready whenever you're ready, you know, and then if they don't respond in a week or so, I will do, hey, uh just I know you're busy just bumping this to the top of your list when you get time. you know, you be very gentle about it because a lot of these people once again they're they're bouncing around between so many different things and a lot of them

are doing it for free. Again, as we said, say it again, hurry up, wait, hurry up. Um, oh, and this is really crucial for contrib. So Drupal core has a release cycle because it's Drupal core has a lot of people maintain it but the contrib is one person maybe there's two if it's a bigger one and something get could get committed and then there's not a release

for a while. Um the Drupal community is getting better at contrib more releases more often but there was a time where I was like hey I'm running the dev branch and I got patches all over the place because there hasn't been a release. Um, so that is one thing like after it's been released like maybe comment like do you know when you might do a release and

just check the release history too. Maybe it is a module that has like the maintainer does a release after merging a few things or maybe it seems like monthly but don't be afraid to ask like just do you know when this will get released so that way you're not like running a patch forever. Um, so make sure you ask for a release. Drupal is made of people.

Like people wrote all of this, you know. Um be mindful of that when you're asking for help. Um like don't go and you know crap on someone else's work and say that this is crap. Be like, "Hey, this could be a lot better." Um but also keep in mind like people there are there are tons of UX issues as we know in Drupal. There are tons of

bugs still in Drupal despite it being probably the most stable content management system out there. Everybody knows this. There's there's so much work to do and people want to get this work. You know, I want I want everybody in this room to be racking their head like what bugs the heck out of me because if you you know it you figure out what you want and at

that point there is a path to get this fixed. And when you get this fix and when you get that fix and you're writing that change record and you're like no one else is going to have to deal with this crap ever again, you know, it it feels powerful. >> So we'll talk about some take we'll summarize some takeaways. Um so step zero is have the bestest

of the communication skills. >> Um because like contributing to open source is communicating with a large group of people, large diverse group of >> Opinionated >> and opinionated. Um, so it is good to have the bestest of the best >> Get your group of people together, you know, like have people that are passionate, you know, about this, who are willing to put in some time, that are

willing to hurry up and wait, you know, people that you know how to work with. That helps. And and and and get a champion. Get someone who can do who can tickle those maintainers without pissing them off, you know? >> Yeah. And like I have the attention of a puppy with a tennis ball when I'm like just kind of all over the place like you know a

dog that's got two of them and they're bouncing around. So I need somebody like Mike that keeps me on task that at a mid camp it's like don't you touch him he's working on this. Um just because also it's like a project manager right we need somebody that helps us close all those that gaps. Um and then again leverage the inerson events for easier collaboration. We're here.

We all get this nice moment that we can actually be around people and chat and figure out the next steps. >> You can't just throw up code. If you throw up code and you're just like hoping that it's going to, you know, get chances are you're going to you're going to get disappointed pretty quickly. You know, you there's people skills that that are involved. you know, you

need to reach out to people, bribe them to do a review, get them to post screenshots, you know, before you even write your code um like reach out to someone who might have the final say and says, "Does this even make sense to you?" And then be tenacious but not aggressive or annoying obviously based on your relationship with people. Like Mike can talk trash to me all

day and it's like that's our long loving relationship. >> Um but just you know just you got to find that balance because you don't want to overdo it you know because you don't know somebody's mindset like as maintainer I remember when >> like with PHP stand Drupal not a contrib module but there's all these bug reports and I got like overloaded just got to remember there's somebody

else in that line that it may seem like they're paid to do the open source work but maybe that's not what they're paid to do. So, you just got to find that balance in >> and remember that perfect is the enemy of good and that follow-up issues are are a fact of life. They are your secret weapon. There are still follow-up issues in Olive like everybody like

when I did the default fame like everybody had thoughts on this, you know, everybody I don't like how this button operates. I'm like, "All right, but I get what you're saying, but right now it works and we have a little bit of, you know, this already has maintainer side sign off. Follow up another issue and then we'll check on that." And the thing is maybe we will,

but unless people are like actively pinging me, it's probably not. It's probably going to sit there, but that's okay because it it got that first issue, you know, committed. And the way I've been framing this lately is like just provide the value, get the feedback. Like is like adjusting the one word going to deny value getting in people's hands so they can see how like if it

works or not. So just take that in mind like when you make the review if you're reviewing somebody else's change like am I blocking getting that value in people's hands so we can actually use it and see what happens. Um and then build trust with the maintainers. This is this takes time but you know as you contribute it'll happen. >> Yeah. tonight if anyone's going to the

gala or anything like that like talk to people like if you see a maintainer just like go up and be like hey thanks for working on this you know and and and stuff like that and and like get into issue queue and kind of help out you know a lot of times like if you have a random person going into an issue and says that this is

a problem the issue maintainers like they're they might not give it the same amount of effort as someone that they know, someone that has put in the put in some work into this. If they know this person and they have this trust with person w with a person, they're willing to give a little bit more effort on that. >> Yeah. And like I remember my start, I

was on a Drupal Commerce build and we had bugs with shipping and I had no idea how to get it fixed and to get Andy to merge a patch. I triaged 35 issues on a shipping module. I was like, I don't know this person, but maybe this will get the bug fixed because I don't know what I'm doing. Um, and that's just, you know, you do a

little bit of work that they're maybe backed up on and then they help you out too. Um, and of course asking Slack, Slack is a communication tool. There's a contribute channel, there's a support channel. So, if it's more like I don't know where this should go or if you know it's like a core issue, there is like the core >> If you're not in Drupal Slack, you

really should be in Drupal Slack. A lot of our a lot of the community is there. you can you can find like if you're stuck on something and and you can't be helped out, you can post and you can get answers and it's just it's just a great place but also to help do a contrib. >> Yeah, I would say like maybe this might be out of

date. So like if you're here and you're listening about canvas and the Drupal canvas, there is like a Drupal canvas slack. If you're doing commerce work, there is a commerce channel. So there's like all these other channels for these microcosms in the community for if you want to contribute or get assistance. so I do want to give a shout out for the best camp called Mid Camp,

the Midwest Drupal Camp that will be here in two months. So if you're from here and you haven't been, you should come. If you're not from here and you're like, Chicago is great, but this whole like spring, winter, spring weather, come in May where it might still be winter. I I I came to I came to my first ever mid camp two two years ago and we

ended up getting a group of 30 odd people and we went to to see the Cubs play and this video right here evidently the Cubs have this tradition of like stacking a whole bunch of cups of like beer cups and carrying them around the stands. So I'm like we're going to do this and this is a picture of us doing that. >> Yes. >> All right. Uh

any questions? Although actually room monitor, is there like a mic we can hand people or how should we should we just relay the question? >> Do we have a room? >> Let's just relay the question. >> Okay, we'll relay. >> You mentioned having to stop and start frequently. >> Yeah. So like frequently the question. >> Oh yeah. Thank you. Um, so the so the questions about stopping

and starting like like how do you restart the issue after you've received feedback and did I did I understand the question right? >> Yeah. So it it like it all depends on the state of the feedback. Like inevitably you're going to receive some what nits which are basically nitpicks and those are usually like really straightforward. You know maybe change you know even like as changing something as

as quick as syntax. You do that as soon as possible. Like it's very important to make these to do the hurry up part after after you get that feedback. Um, a lot of times you will maybe receive feedback that you don't quite understand. And at that point, I like to jump to things like Slack and say like, "Hey, Alex, I I saw that you gave some feedback

at this issue right here. I I wanted to kind of short circuit the I wanted to short circuit our communication and just kind of ask some follow-up questions right here." And so I can, you know, hopefully they will respond fairly quickly. At that point, what I will do is I will copy that link in Slack. I'll post that into the issue and I'll post that conversation in

the issue so everyone else can see what happened. And at that point, you know, you have you have two choices. You can either follow directions or you can push back against the maintainer, which in some cases is totally valid. And like I think one addendum to that is like it's okay to DNF like did not finish. Like maybe that feedback comes back and you're just like well

these are a lot of changes. I don't have it in me. I just want to make it clear like we talk about the team and landing these things but it's not always a happy story and that is okay too if you're like well I'm going to let it sit here for the next team that wants to push it over the edge. Like the development settings form was

me putting a feature into the void and seeing who would pick it up. I just happen to come back and do it. So like that is okay too. Like just to make sure everybody knows. >> Yeah. But don't give up. Don't give up. But like it's okay to just like now's not a good time. Yeah. Go ahead. >> I was just wondering any tips or tricks on

reviving really old. >> Yeah. So, uh the question is uh tips and tricks on reviving old stale issues. So the first step is verifying that there's still a problem, you know. So you can even just as far as going into an issue and saying, "Hey, I just verified that this is still an issue on 11.3 and it's still annoying as all hell, you know, like like that

goes a lot." Update the issue summaries is a big deal. Like uh if if you go into an issue and it has 50 odd comments, it's very overwhelming. Go in there, update the issues. Sometimes uh AI can actually help out a lot with that, you know. Um and um at that point assuming that the problem still present assuming that you updated the issues f like find out

like what feedback needs to be addressed where is this and if there's something you're not quite sure how to do switch over to Slack and and find out you know who the maintainer is responsible for this who's been kind of kicking it back to to needs work and stuff like that and say like hey so and so I really want to work on this and push it

over it's a big deal for me I know you're busy but what do you think about XYZ and I would add this is the one nice part now that we use GitLab merge requests instead of patches because you'd have like the legacy issues and it's like well there's this one patch and I need to redo it and now somebody has to review what the old patch did

the new work like so if you are picking up an old issue I would make a new issue Q branch and a new merge request. So that way you could be like at this point in time decisions were made and this is where we ended up and we're going to work on the new version that's here. So they can also do like that delta and compare. I

think for like the whole bre don't just like start building on that existing MR and like rebase and all that. Start from scr if it seems like it's easier to start from scratch. I think it's there and then there can be two merge requests and it kind of like tells the story as well of like where the issue went. >> Any other questions? Does anybody Does anyone

have anything in their head that like bugs the heck out of them that they might want to start working on? Come on. There has to be some. All right. I I got a half of a handshake in the back, which honestly I'm like really disappointed. I know it's morning. Come on. Come on. So, as you're using Drupal, as as you're going through and something annoys you, make

a mental note of that. And at that point, that's that's often the hardest part. And if you get stuck, reach out to Matt Glamman, reach out to Mike Hershel. We will point you in the right way and say, and again, not everybody like has a blog and writes anymore, but if you do have one, it's and you got ideas, it's also like just spread the ideas, too,

because you're going to make somebody else like, "Oh, you know what? There's that. There is a value in that." Like if you have something that you think is kind of quirky, like I don't know if it's really a bug. We're here and you're chatting it over. You're going to be talking to people at the gala just like about building sites. Kind of talk about those pains also.

You get to vent about work a little bit. You get to vent about things you're building with other people that relate. Do that and next thing you know like whoa I don't like that either. I mean that bugs me too. No, it would be so much better if and you get that serendipity rolling. And that's kind of you know that's the magic of these inerson events and

that's where you can make something happen. Or like if you don't think you can land it, somebody's like I got it. I'll run with it. >> Yep. >> Thanks everybody. >> Yeah. Thanks for coming.