 So, hi everyone. This is the core conversation room, and this is learning to let go, contrib burnout. I'm Dave, and, yeah, this is going to be an interesting session for me, so if you want to tweet me, there's my tweet handle, or Twitter handle, just Dave Reed, mondriple.org is Dave Reed, and yeah, this is quite a little bit different for me. I do want this to be more of a conversation than a presentation, because I want to work through some ideas, because really, like, I've been telling people about this session, like, I want to picture this session as, like, you're all my therapists, I'm going to sit up here in the couch, like, I'm going to lie down, and we're going to work through some problems. We may not solve any problems, and, like, I think I put in the session description, like, I don't have answers for some of this stuff, so maybe we can figure them out together. So, yeah, I'm Dave, I write modules. Just a little back story on me, I've been in the Drupal community for about 10 years, which seems like a lot, like, I'm probably the old guard now, which is really weird, and I work at Lullabot, which is also celebrating its 10th anniversary, that's kind of fun, and this is also my 10th Drupal con, so if you like numbers, that's a fun coincidence. I'm excited to be here and, like, see everyone, and I had a really great day yesterday, and, oh my God, I love the food here, that's like, I'm excited about that. And one of the reasons that I enjoyed coming to work to Lullabot, among a lot of other things, some really great co-workers, is their core values. They have them defined on the website, and this one in particular, like, really resonates with me right now, and especially throughout the last couple of years, and it's be human, and if you can't read that, it's, we love our red robot, though we may do technical digital work, we know that it's the human connections that bring our work to life. We value our humanity, we talk in simple terms like humans, conduct our business like humans, and accept the humanness of those around us. We celebrate failure as an opportunity for growth, we admit mistakes and learn from them, and we strive to be honest, humane, friendly, caring, and humble, trust emotion, trust intuition. And like, I think that's a good, like, that kind of value is pretty strongly throughout the Drupal community too, and I have been trying to live by this more, and specifically, like, failure, like, I think the last couple of years of my life have been kind of a failure, and that's okay, but I want to explain why, because I write modules, and then I hoard them, which is really what happens. I mean, they just stick with me, they stick around forever, I don't really know how to get rid of them, and sometimes they don't really want to get rid of them. It's a personal issue I'm facing. And just like cats, because I have to include a slide of cats, because I hoard those, but I only have three. So with the newest one, the calico on the cat on the left, which I wish I could also get rid of, because, like, the most kitten destructive behavior that we've ever seen, and the other two cats look like awesome cats in comparison. Yeah, I wish I could give them away, but they're family. But does anyone have a guess to the number of modules I currently maintain? 175, anyone else? What in the back? 500, any other guesses? 50, 200, 19, 90? It is 134. So you want a module. You were close. And I even wrote the module to keep track of the number of modules that I wrote. If you get a module to that, I have a stack here. I can just throw them out. And I even put like a little counter, like, you know, the factory, like, it's been two days since our last accident. It's like, yeah, it's been two months since Dave wrote a module. And I have to admit something. I wrote a new module this morning, technically. So it's now 135. And you win another module for being close too. So yeah, 135. That's quite a lot. That is quite a lot. And so I've been trying to, as a part of preparing for this session, like, go back and understand why I'm doing this, why it's gotten to this point. Like, why do you, why am I hoarding this? Why is this a problem? And I mean, there's some obvious reasons, like, writing modules. Like, it's the first way I got involved in Drupal.org. My first module was the feed burner module. I wrote it. No one had written the feed burner, like, how to integrate feed burner with Drupal. And I wrote it back in 2009. And it feels good to contribute back. I really, really, really get a lot of enjoyment from contributing back. And like, I don't know, it's just, it's a part of everything of how I solve problems now. Like, every client problem I encounter, or every like, you know, user story or epic that I'm working on, I'm always like, how could I solve this with a module? And then maybe like a little client glue around it? Like, how can I get this, like, how can I make this reusable for people? And I think that's a good thing. But then it's like, when I'm always doing that, and then they build up, build up, it's like, it's a lot. And I mean, it also, I mean, I have to admit, like, it's a little bit vain of me to say, but like, there's the prestige and there's the respect. Like, if you were a module maintainer of Path Auto, like, everyone uses it. Everyone wants to thank you for it. And it happens all the time. And like, I don't know, I feel good about that too. Like, it's, it's not a bad feeling until I realize how bad the situation has got. So yeah. And it results in obviously me being spread too thin. So I mean, in addition to all the modules, like, I maintain two core subsystems right now. I work on the token API and the telephone module. And I should really say work, because I don't really do it anymore. Because I don't have time to dedicate to it. I'm a member of the Drupal security team. And I invest time in that. I'm a member of, I'm supposed to be a member who can approve product applications. And Jeremy, you're going to laugh at that? Yeah. Because I have like not approved a project application in like a year. Like, I don't think I've been active in that issue queue. And I probably should just resign that position. Like, I need to give it up. I'm a big part of like the media initiative. Dries talked about in his keynote, you know, he wants to make a media initiative. But we already have kind of a team that's already been working on this for like five years. And we've been doing all the D8 work and trying to figure out the solutions forward for that. And, you know, that's a big part too. Like, I mean, it's like, I just got sucked back in yesterday when he did his keynote, he announces the media initiative. I was like, ah, like, everyone around me was like, knew that my reaction was like, damn it. Because I knew like, I've been involved in this for so long, I either need to like, cut it told cold Turkey, or I need to figure out a way to offload my knowledge to someone. Or I just need to make it a last hurrah and keep going through it. And like, to me, the option to quit is not an option for me. It's just not one that I realize. I'm also a local group organizer, like I organize our meetups. And I have work to that's 40 hours a week. And I have a family, I have a wife, and I have two kids that are really small. And like, I want to, like, am I sacrificing being a dad, and being a husband for this? In addition to all the modules. And it ends up feeling like I'm just backed up in a corner, like all the time. And I will get very, very stressed out. And I hide it really well from people. It's paralyzing at sometimes. And I have to face it. And I have to deal with it. So that's kind of my back story. If I haven't like, completely, you're like, oh, yeah, I'll take this case. If you're the psychologist, because you're like, this is going to be some great billing hours. So I wanted to go through like some pain points for like, as a module maintainer, like, how do I feel pain? When I'm when I'm working on modules or working on triple dot org. And I would love if you, you know, had also a pain point that you encountered to step up to the mic and help me out. I kind of listen to things like GitHub is becoming more and more popular with Drupal modules. And I really find as someone who works primarily on Drupal.org, it fractures a lot of discussions. And like, if it doesn't exist on Drupal.org, it like, I don't feel like it should exist. And I have a tough time with that, like, we're using GitHub for all the Drupal media stuff in D8. And it gets really confusing at times, because like, I want to adhere to making sure I'm attributing all the commits properly. And it's really easy to do that with Drupal.org. But it takes a little bit more work on GitHub. And like, and then if I'm not attributing things correctly to the right people, or that kind of stuff, like, I feel bad that I'm not doing that properly. You know, issue queues. They're a pain point. If modules didn't have bugs, and we didn't have users, it would be a lot easier. But that's not the reality. You know, support requests and like, the issues that come in every week. This module doesn't work. Or this thing doesn't work. And like, no more details about it. And like, you know, we don't have good issue templates for new, for people that are newer to Drupal.org filing bugs. Like, the information that it would be nice to have from them, or try and extract from them, we're not getting. I mean, I've had this issue, like, I would love to give people co-maintainership access to modules. And I'm trying to loosen that up, obviously, with this session. Like, someone will come by in the path auto issue queue and be like, I want to help maintain. But like, I will search, because you can search by a user and see how many issues they have touched, or like, replied to or posted on in the issue queue. And I'll search for their username, and it'll be like, the one issue where they asked to be a co-maintainer was the one issue they were involved. And I nice, I try very hard to like, you know, encourage that person to be a contributor. Like, hey, I would love your help. You know, this always needs help. You know, please get involved in the issue queue. I've got these patches that need review. You know, there's these issues that could use someone to write help write tests. You know, I could just help someone that, you know, goes through the issue queue and helps triage stuff. Like, that's all helpful. And then like, when someone is helping quite a lot, I will be like, you know what, you've been a super big help. I'm going to add you to the module. Like, I have no problem doing that. On the other hand, is it, am I being too restrictive to those people? Like, should I just be giving access away willy-nilly? Or, like, but I don't feel like I should do that with some of the other modules. Like, I shouldn't do that with Path Auto, because, you know, a lot of people rely on that module, and it has to have some standards with it. It's like, where's that balance for me? And, like, I don't know. Like, I used to think that, you know, longer ago, the places that new modules fit in, like, you could write a module for stuff, because it didn't exist yet. And I think that it's slowly, slowly lowering. It's like, we need to get people involved more in current modules. And this kind of ties into project applications. Like, I know that a lot of them end up like, hey, could you help this module instead somehow? And, like, getting people involved in that, like, is that a way that we can help reduce this load somehow or this pain? And, frankly, I find it a lot easier to remove yourself as a core maintainer of stuff than a contrib maintainer, because I feel very strongly that core, like, if I were to go say, like, I can't be the token maintainer in core anymore, because I have literally done this. I've said I can't maintain the path module anymore. And I filed an issue with a patch to remove myself from maintainers.txt. And a couple of people are like, we're sorry to see you go. And I was, I was honest. I was like, I don't have time for this. And it was just easy and done. And I know that two months down the road, someone is going to pick that up in core, because it's core. It's so very important that someone, there's a maintainer for every section of core that's active and responsible. And I feel like that's not the same in contrib, like, if I were to just drop off on some modules, which I have done, like, is someone going to pick up this work? Is it just going to fade? Is that okay? Or not? I, I struggle with that a lot. And I, I like highlighting this. If you've ever seen this on Drupal.org project pages, we, we added these nice stats, you know, for our end users. But this is super stressful as a maintainer, because it's like, your response rate to issues is 21 hours. Like, that does not give off a very good impression. And it's like requiring my effort to constantly be in the issue queue to make this stat look good. And like, it's, that's a pressure on me there. And like, 33% response rate. That's pretty crappy. But like, those are all, that's, there's a lot of factors in there. I think this is the media module too, by the way. I think. And one of my biggest fears is like, self identity. What if I'm not the module guy anymore? Because like, I've self identified and identified in the community with that. Like, that's I feel like that's a part of me. And what happens when I, when I lose that part? I, I very much struggle with that. You know, well, if I'm no longer the module guy and active in all these modules, will I want to work on Drupal anymore? I don't know. And scary, because it's like all I know right now. Like, I'm fully invested in Drupal. And I don't feel like I can leave. Like, I don't, I want to be working with Drupal. That's what I love doing. But it's scary to imagine that not being a part of my life. And this isn't really a self-enforced identity. Like, there was even Greg Kananasen made this website that you could make wagers on things. And this was back in 2012. Greg Dunlap, one of my now co-workers, made it, made a question, how many modules will Dave Reed have by the end of the year? It's like, this is, I mean, this is not self-enforced, too. But it's part of who I am. How do I, how do I lose it? So did anyone have any other, like, module maintainer pain points that they have? Yeah. Same pain points at 40 and 50. Yeah. Yeah. Ignoring the issue queue. That's one thing I do. I don't, yeah, I know. It's like, it's a solution. It's a solution that comes to the detriment of the end users. Yeah, I would empathize with that one, that it's hard to, like, document why the things are the way they are at times. Like, I, I struggle with that. Like, how do I document that for all these modules? And like, if I could do that, I feel like I could let someone have the keys to all this stuff and take over the larger stuff. And it's something that I have very much experienced, actually, like, in this porting process from Drupal 7 to Drupal 8, there have been some modules that, like, kind of went off the rail in this one feature. And, like, I, I'm trying to not be involved and then I see, like, it happened and I'm like, hey, you did realize this is intentionally this way because of this. And, like, they didn't know that at all. It's, it's hard to document that in code and, like, I probably need to document that, like, on the handbook pages somehow. But, like, that takes a lot of effort and time. Yeah. Um, so I, yes. Yeah, so the patch-based workflow, ironically, I love because I'm just used to it. But for, like, people that want to be involved and help contribute to modules, that's probably a pain point for them. Like, that's a reason why they're, we're lacking a lot of help with modules, too. Yeah, that's fair. Yes. Got it. So for the recording, to kind of help relay, your issue is kind of the reverse. Like, it'd be easier if people helped provide pull requests for stuff rather than patches. And that's completely valid, I think. It's just, you know, the converse. Um, you had, yes. Yeah, having the separate project page, readme.txt or markdown, all separate, like, that works really nice on GitHub. Yeah. I like how that works. And I know that there's an issue to actually have that happen on triple.org. It just needs an infrastructure champion to have that, have that done. Yeah. That would, that would be nice. And I think, like, if I'm thinking about it, too, it'd be nice if we, like, have an architecture.markdown or something like that. Like, if I started doing that with modules, like, just trying to put down architecture documentation in a file in the project that might help with some stuff. Yes. Yeah. So the views issue squad, that worked out really well for them because, like, it was tightly focused. They had an active group and multiple people in the group. And it was, you know, the most important module. Like, it was, it was heavily visible. Like, we've, we've tried to replicate the same thing with, like, the media module. We used to have a media module issues queue squad that would have had the same goals of, like, helping, helping incoming bug reports and helping maybe help solve those before it needed to be brought to, like, my or someone of the other maintainers, you know, attention. And the problem was that just it fell off. People didn't, it, I mean, I can't blame people for this because it's, like, life takes them in another direction or they lose interest or, like, it just falls off. And, like, it just, it didn't last very long. And, like, if I tried to do that for all the modules, it'd be a lot of work to organize that all. Like, you know, maybe Drupal.org could have, like, something where someone could sign up to be an issue queue maintainer rather than it being something the maintainer grants to you, which is the current process. So maybe that's something that, like, hey, I want to subscribe to issues and, like, every support request and bug report gets sent to you and not the other stuff or something like. Yeah. And there actually is, you know, there are people that are helping do that. One of them is in the room, is Wampie in the front. He's one of my co-workers and he's been awesome helping triage a lot of the D8 porting issues. Like, yeah. And it does happen. So thank you, Wampie. Yes. Yes. Would you like a module? Would that help? Yeah. How do I find time for contrib? That is an excellent question. Moving on. I can kind of cover, you know, how I'm kind of handling things now, which kind of fits into with that. I compartmentalize things a lot now with modules. So kind of like what was said earlier with like, ignoring issue queues, I will basically, like, say, okay, this week I'm going to look at path auto and I ignore everything else. And that kind of works, but it's not really sustainable. Like, because if I use a spend a week on a module, I'm going to be spending, you know, I'm not going to get back to path auto for, you know, three years. Yeah. That's not very sustainable at all. Yeah. I mean, I try and focus more of the compartmentalization on the major modules. So like, I'll do media one week, path auto one week, redirect one week, and cycle through those a bit. And the smaller modules, it's like, if an issue queue pops up that piques my interest, or it's like someone provides a patch that I can easily review, like, I'll maybe go check that out. But I kind of tend to ignore it. And that's like, I think I only spend less than an hour, like maybe 30 minutes to an hour a day, then if at all. Because sometimes it's just not any time in the day that I spend on it. I'm actually trying therapy this year, like to help some of the personal issues. And I would recommend it. It's tough, but like talking about it, like this is a form of therapy for me, like talking about these issues allowed in front of peers and strangers and triple con people that can then tweet me afterwards. It's kind of scary. But I'm trying it. And I think it's helping a little bit. It's helping me at least accept things, accept the problems, and brainstorm a little bit on how I can try and let things go. I've been focusing a lot more on time away from the computer. I mean, this doesn't, this directly conflicts with contrib time. But like those other pressures, like I have really been enjoying taking walks with my family. And, you know, related also exercising a little bit more like, that's been a goal of mine for this year, to do more of that. And something I've also been doing is like a lot more very, very strictly tracking to do's in a to do list system. So I use G cues, it's tied in with Google. And I can divide things into different cues and reorder them. And it's kind of nice. But like literally everything that comes in, I will add it to do. And I think it's probably like close to the getting things done method, probably. And like I'll take a look in the morning and like, what are my work to do's, what are my personal to do's that I want to get done. And I if I can check two things off for personal and three things off for work today, I feel good. And I'm not feeling like I'm spinning everywhere and trying to get everything done. And that's gotten me a lot more satisfaction in my own personal like, at the end of the day, I can like, okay, I feel like I'm done at five. And I know I've literally see the things I've checked off and like, I don't know, this may be simple for everyone, but it was like a revelation for me to like, really stick with this. Yeah. Any other ideas for like, things things that you found in your like, experience like, how to de stress or how do you handle balancing these things? Ben, away from keyword time. Yeah. Yeah, I really enjoyed it. Yes. That's that's how it has been for years. But like, I never found an issue with the module myself. But once in a while, I go there, oh, a lot more. Yeah, that's it. So the community there helps and they maintain the module. I just do the final check and get the thing in. But I don't work on the module. Yeah, so I've got a similar model that's been in 1800 years. So I think I emphasize with that a lot. Like, I definitely have had situations where like, if I can rely on people, other people to get issues to reviewed and tested, that is awesome. Like that's my ideal. Like if I could have that happen in everything, that would be great. But it doesn't happen a lot for me, surprisingly. It does happen more in the popular ones. But like, I don't know, it doesn't happen as often as I think it does. So or how much maybe how much I wish it does. I don't know. But yeah, if that happened more often, and I think you're talking about XML sitemap too. So yeah, we'll commit those. So you asked how not been on time to work in about two and a half years, but I have been twice as productive as a result of not showing up stressed. Taking more of a South American approach to time. Okay, the South American approach to time. Context there, I lived in your way for five months. And if there was a meeting at nine o'clock, and someone sort of stole in at 11 o'clock that was still accepted and acceptable. Interesting. Yeah, I like that. If I didn't have scrums in the morning. Yeah. Yeah. Yeah, that road rage in Omaha when I'm driving to my own house. Yeah, I work from home. Yeah, that that may clarify. But I can also I feel a little bit of stress just getting the family ready to go in the morning. Like I feel like I experienced the same thing. And it's like the mornings where like, I feel very pressured that I have to get to work on time. And I'm like, the kids are screaming. And I know that Jenny is trying to help get the kids out of the house. Like, Oh, my God, that just starts my day off horrible. Yes. Yeah, I definitely found for my own personal experience that we moved into our house like two years, two or three years ago. And I had thought, Oh, this this room on the main floor, it's nice and centrally located, it's where the router will go. So naturally, that's where I should put the office. And I found with having small kids, having the room on the main floor does not work as well. Because they respect boundaries a lot less. And so I eventually moved the office downstairs into a room. And I was able of it helped a lot on the focus level for that. So I can definitely definitely recommend that. Yes. Yeah, making sure that you leave the house, I do the grocery shopping in our house, because it's like, that's my opportunity to go drive somewhere and do something and like, feel productive for my family, like, and I enjoy that strangely. So yeah, yeah, trying to keep a regular schedule. I found is very challenging, because my kids don't wake up at the same time every day. And I tend to sleep until they're awake. Yeah, can you teach them to wake up at the same time? Yeah, I know. I feel like it's a phase thing with small kids. Like I'm in that kind of rough period as a parent too. And like, I just kind of need to accept that that it's rough right now, and that it hopefully will get better. Everyone tells me it gets better. Yeah, there's some thumbs up. Okay, all right. Yeah, I mean, that adds to that stress. Small kids, they're fun. So, you know, what are areas that Drupal.org, I kind of touched the personal aspect, where areas that Drupal.org could help reduce that stress and pain for maintainers. So some ideas I had, like, I feel like core has a good mentoring structure, but like, I would love to have can like contrib mentoring be something. But again, it takes time to do that. Like, how can we, how can we better mentor contrib? Oh, there are. Oh, Tim Blunkett. Okay, I'll talk to Tim about that then. Okay. All right. Yes. So it's more, at least in my experience, in core, to start in concrete. And then later, when you understand how it works, when you understand a little bit more the idea, then if you want to go, but I can't see people who go to events, and they, they see off more, and they think that that's the thing about computing. And they say now, this is not for me. And, and we need to contribute it. Answer this. And this issue is not of the rising. The issue with the mentoring is that why core mentoring is so successful? Does you go through the problem? And there are a lot of people, including the maintenance of, say, of four, four systems. We have the same with the concrete. You need to, you need someone that will be able to help you to have some issues with the concrete. And where you need someone who will be able to commit your projects on place. And please, this is something that is much harder to organize than to have work in the, in the process of doing that. That's the top part of the data. Yeah. Yeah, I'm not exactly sure I would want to put a new person in front of media's issue queue at all. Like, that's a scary place right now. Yeah, if it was, like, prearranged, like, if we had, like, module maintainers sign up, like, hey, I want to have a table that just sprints on this module and I'm willing to accept new people, like, I would probably like to do that. Like, I would like to get into more of that. Because I think it would help offload and kind of, I like mentoring through example a bit more. And having it on a sprint day would be ideal. Yeah. Yes. Unless I can clone myself. Yeah. Yeah. Yeah, I know, I know for myself, like, I wanted to do more of that. Like, I'm not going to be even at the sprint day this week because I'm flying home for my family. But, like, if I was to spend the sprint day, like, I've in the past been hesitant to, like, try and help new contributors. Just because, like, we've been thick in the weeds, like, with media stuff and it's, like, we need people up to speed. But I think I've been realizing over the last couple of months, like if I actually use the sprint days to help, like, hey, let's get some new people working on this module and if I can maybe spend the first hour or so figuring out issues that might be on boarded in the process to help. But I think, usually, once they hit the afternoon session, they're ready to help wherever possible so that it could be contrib or core. Yeah. All right, so back to Drupal.org. I would love it if we, there actually is an issue and it's been presented before at other Drupal cons and improved get workflow on Drupal.org, so kind of getting away from the patch-based workflow and actually using branches that people can contribute to and kind of making patches work for people that want to work with patches but also supporting branches. So if you want to check that out, that would be, I would love that. I'm not certain on that answer. You'd have to probably check the issue. Does Jeremy have an answer if anyone's working on it? Yeah. Composer is pain. And I would like to thank Jeremy, you and the Drupal CI team because that has removed pain as a maintainer, so thank you. Um, what else on Drupal.org? There is this random handbook page for co-maintainer best practices, but it's, like, really long and really detailed. But, like, I would love if we could clean up that page a little bit more, make it a little bit more modern expectations, like, and have that kind of point too easily for, like, hey, you want to make it a little bit more standard for getting involved with a module. Yeah. Better issue cue tools question mark? I don't know. I don't know what those are, though, so. All right. And I think we did solve the problem with me. We're going to clone myself. Wait for human cloning. Because I promised a module giveaway, and I had been giving them away. But you should take a moment and look under your seats. Right now, I'm serious. Look under your seats. And if you found an envelope taped underneath your seat, you just won a new module. It's a happy thing, people. It's a happy thing. So, on the sheet is a little slip of tape that if you post it in the issue cue, I guess I have the little contest rules. Winters must have a Drupal.org account that assigns the agreement to redeem. To claim your prize entry, file an issue in the project issue cue. By redeeming the prize, you agree to the co-maintainer best practices. So, post in the issue cue, if you want the module itself, you may have it. So, this is like my I have more. I had 48 modules that I was like, I can give these away. So, if you want them, you are more than welcome to them. You can trade them. You can barter them at Drupal.com like buttons. You can trade them for favors with your coworkers. And, you know, maybe you can sell them on eBay too. I don't know. Yeah, so, I mean, I'm hoping that, like, I mean, it's silly to do the giveaway, but like, if I can give away 48 modules to people that's in one to a person, not 48 to one person, like, can help spread the load a little bit for everyone else and, you know, take a little load off me. But, yeah. And I wanted to thank these people. You know, there's Wampie and Bridger has been helping a lot with the D8 ports at MD Systems. And he's, like, done a lot of the porting for major modules for me. And that's, like, once I've finally had a chance to evaluate those ports and, like, move them back to Drupal.org, it's been a huge relief, like, helping with that. If you can evaluate the session, let me know feedback on Twitter. Come find me at the Lullabot booth afterwards. If you have more ideas or thoughts on how to handle things and balance things. So thanks, yeah.