 Yeah, ring Jordana online. There we go. Hello, Jordana. Hello, I'm here. You are here. You're present and accounted for in the room on the screen. We can hear you and see you. Thank you for being here today. Thank you for having me digitally. For all of the AP folks. Thank you, AP folks. Cool, so hi there. Welcome to our session. I think the print program is different. So if you are not here for relief pressure within open source communities with reusable systems templates and succession management, I'm not sure where your session is supposed to be. But this is what's in here. There was another one about JSON, I think, that got moved. And I'm not sure where that went, unfortunately. Yeah. Thank you for stopping by, though. OK, so anywho, today we're presenting this session. I know nothing about JSON, or I would attempt to do that. Anywho, hi, I'm Ellie. I'm occasionally like this. So that's a little tiny me. My name's Ellie Lidvigson. I've been on Drupal.org for 10 years, as of three days ago. I'm EKL1773, pretty much everywhere on the internet. And that is absolutely no reference to the American Revolution. It's my name on a calculator. Other than that, Drupal stuff, I've been on the mentoring initiative for my entire time in Drupal. And we'll get to that at the end. There's contribution events all day on Wednesday. And I've also done a lot of work with the Drupal Diversity and Inclusion leadership team, who are just all over the place. I am, by day, a product marketing manager. I'm actually looking for my next position at this point in time. And yeah, that's plenty about me, I think. I did want to say one other thing, which is that we come to you today from the historical lands of the Shawnee, Monongahila, and Osage tribes. There's currently a group called the Council of Three Rivers American Indian Center that organizes events for indigenous people in the area today. And they are active and doing cool stuff. So check them out if you're interested. And with that, let's go back to Jordana. Hey, y'all. I'm happy to be presenting. Less happy that I'm not there with y'all in person. But I have the privilege of being here in part thanks to having amazing mentors and friends, like Ellie, who are part of my amazing support system because of Drupal and its wonderful community. I am the current mayor of the community working group who are tasked with fostering an inclusive and welcoming environment within Drupal. Both the community health teams and the conference resolution team, which I'm a part of, within the community working group are always looking for help. So if you're interested in volunteering, please reach out. This session is especially relevant to me as well because I've also struggled with burnout, struggled to say no because I want to do all the things, and struggled with asking for help sometimes because I don't want to burn another. You can go to the next slide. The slides, there's a link at the top right corner. But the links to slides work. We also created a Drupal.org issue about this session with resources around succession planning and management, where we would love for y'all to collaborate with us. So if you have any resources, questions, comments, please feel free to go in there. We added all of the links there as well. We were planning on creating with some open source to make a playbook based on one of the playbooks you'll see a little bit later. We haven't gotten to that because of light gets in the way sometimes. So that is something we are planning to do. So if you are interested in helping out with that, please feel free to reach out there as well. So what's the problem? So I believe one of the biggest issues within open source is succession planning. And there are other closely related challenges, which include converting users into contributors, contributor retention, and contributor burnout. So what have we been seeing in open source? So unfortunately, those of us who talk and lecture a lot about burnout are often always no one feeling good. And we are generally less likely to eat our own advice because we are leaders and we're trying to protect others from kind of landing in the same spot we are. And we spoke with so many people who have stopped in their roles because no one is stepping up. And they feel like if they don't continue on in these roles, the project will fail. These contributors often feel overburdened and tired. They're juggling multiple projects and they don't feel like they have enough time or energy or even willingness to continue. But I feel they have to. And then they often suffer from burnout. This can turn out the effect that some of these amazing folks will end up leaving our communities and projects. And thus open source suspicious cycle churns another overworked tired person who often feels underappreciated. And unfortunately, often will be less willing to take on these types of roles again. The flip side to this is that other willing contributors, see these tired folks that feel stuck and in turn will be less likely to take on these roles if they're scared of getting stuck as well. So you wanna give a gentle reminder that self-care is not selfish. You can't run an empty battery. And unfortunately, once the battery is empty, it takes longer to recharge and get back to a healthy state. So we just wanna let you know that we set this whole and if that's not a burnout, that means you might be scared about new and potential contributors and leaders to your project. And if this is you, we wanna reiterate and we wanna let you know, please please know you are not alone. And it's not just you being hurt by the situation. And it's important for us all to be honest about how the workload and the situations are affecting us, to ask and accept help and to create an environment where this is not an or. And once we do this, we can try to start to break the unsustainable cycle of feeling stuck, obligated and frustrated. So Ellie will be going over some of all of this a little bit more. Great. Ellie will now go over this. So what we're actually talking about today is kind of the solution side of things. To help alleviate everything Jordana just mentioned, there's a lot that needs to happen on various levels. I never wanna put pressure on just individuals to do all the work because it really needs to be systemic change. So while there are a lot of things you can do personally at the same time, advocating for that bigger change is really important too. Equally difficult. So a few core skills and systems that we can think about. First of them is delegation. Sounds simple, it's not. In order to hand off the tasks or pass on responsibility, people really need to know what to do, what a role is, preferably without like too much hand holding, there's a balance, right? You want people to be able to self serve and figure things out on their own, but you also wanna be present when they do need mentoring and coaching. So our goal is to have thorough documentation that can be supported and supplemented with actual human conversations. And that's where this talk comes in and behind a couple in the bullet points. We wanna make it easy for today and for the future. So you're enabling not just your team and everybody who's going to come in the future, but yourself and your team tomorrow. Just make the work easier every day. So there's a few things you can do. And I have a habit of making to-do lists for myself that are epic and very nicely laid out and then they sit there for a year. So this is very me. We need checklists, we need guides, we need templates, we need task breakdowns, we need timelines and hand off processes and permissions and tools. And that all starts to feel kind of like, oh my gosh, so many things. So at this point, I'm just gonna pause for a sec and do a quick definition of what succession management and succession planning is. Succession management or succession planning is a process and materials for regular handoff of responsibilities to other team members or leads. It's pretty closely related to handing off your job when you quit or if you go on long-term leave and also onboarding. So what can you do? Where do you start? First thing, I like to keep in mind, I may have said the first thing already. So maybe this is the second thing. I didn't actually number the important points. You cannot pour from an empty cup. If you are drained, you don't have anything left to give. This is also a concept that was spoken about by Jeff Eaton way back in Drupalcon, Nashville, with a talk called You Matter More Than The Cause. It's linked in the slide, which is available. Great talk, it's been quoted a lot. So I always wanna be thinking about our commitments. You can't do more than we have capacity for. We will guilt ourselves to death for not having enough time or energy when we haven't scratched off all those things on the to-do list. And I myself always wanna say yes to things. I'm like, oh, I really wanna help you. Sure, I'll fit that in somehow. I won't, I can't, I'm out of water in my glass so I can't give anymore. And that's how overload starts. Best of intentions, but it doesn't end very well. And all those expectations weigh on you. You don't feel like there's a way out and then you're stuck in that burnout mode. So even the stuff that we enjoy takes so much energy and we have a limited amount. So you're just always making a choice about what you're saying yes to, which means you have to say no to something else. So in summary, continuously evaluate where your energy is being spent. Sort of a personal energy audit, I guess. This brings me to a little metaphor where I'm talking about if somebody needs to step away from the project, maybe it's a sudden thing and nobody sees it coming. So if you don't have all the support and preparation in place, it can leave your team hanging. And this is often referred to as the bus factor. And I was thinking about that and I'm like, that's super violent, I don't wanna use that. So instead I thought, okay, so what if you were suddenly beamed up by some aliens? You're gone. And you personally may be having the time of your life cruising the galaxy on a spaceship with your new best friends, but your team back home is like, oh my God, we don't know where anything is, we don't have access to anything. What do we do? So that's my metaphor for the day. So our goal is to prepare for extraterrestrial beam out. Which brings us to how to hand everything off. And this is something Jordana brought up the other day in terms of an exit strategy, which has often four phases, starting with an exploratory phase, where you may be looking at what things you need to capture and document and understanding how processes and tasks happen today. So observing things. Then there might be a strategic phase, letting folks know about the exit plans, start looking for interested folks who can help craft and test those plans and who may want to take over in any role. And then there's an execution phase, actually creating the templates, the documentation and resources, starting to delegate and empowering people to test all of those assets. I think the testing wound up in two phases there now that I noticed that. The transition phase is when you delegate more heavily and hand off responsibilities while you're still there, so you can also spend the time to mentor and guide folks as they're getting started. You really want to ensure that the excellent visions and goals and values of your team and your project have a chance to survive in the longer term. You probably also want to think about when it's time for a change, like do you have terms? Is it one year? Are there staggered terms? Like it's a four person team. Do you switch out one person every year? So there's always some people with more seniority and younger folks and lots of things to consider there. All of that comes together and then we can say, once we're in this more healthy place in terms of bandwidth, it starts to show. We can make setting boundaries and delegating part of the group culture so everyone feels comfortable and safe, engaging and gives leaders more space to mentor and support each other. And then you can rededicate all the time that you used to spend doing everything yourself to helping each other more. Every time I start talking about this stuff and thinking about it for myself and the projects I work on, I come up with these excuses which include, oh, I don't have the time. And I personally kind of hate this phrase, you have to make the time. Because I'm stubborn and I fight back against it but sometimes it's true, you have to carve it out from somewhere and that goes back to needing to say no to something in order to say yes to something else. I will also tell myself it's too complicated. I don't know all the things. I need to have the perfect process. I need to know everything before I can start but then I'll never start. So it's important to just start with what you have, start small and build on it later. There's also the argument that everything is going to change anyway, so why bother? But that's a good thing, right? We want change. And then there's the inevitable blank document which is very intimidating. And in this case, this is something we'll get to a little bit later in the presentation. You can start from something another community built, open source that is and definitely check in with them and like have a conversation about it, ask what worked for them. And these days you can also just grab a rough draft from good old chat GPT and start from there. So with that, I'm gonna hand it back to Jordana to go into a few more details and some how-tos. So what are the steps to the benefits? So first off, we need to make tasks easy to repeat. So start now, document everything, document the steps, create playbooks and templates and snippets. If you see certain things you or your team use often or you feel can be reusable, grab it and save it. It doesn't need to be perfect, you can tweak it later and even if you don't use it exactly the same way you have a starting point and some guidelines in place. Enabling more helpers by breaking down tasks for clarity so folks know what is expected from them. When larger projects and larger tasks are broken down into more manageable, smaller, bite-sized tasks, people are less likely to feel overwhelmed and other folks are more likely to pick up these tasks so they know the expectations of time and effort to get them done. Create a participation-friendly environment. When a project has clear tasks with time and time to do that offline, it creates a sense of safety for folks that may not want to bite off more than they can chew or where folks feel like they would get stuck with larger scopes if they can feel burdened. Help creativity and reinforce the habit of participation. Sometimes there's nothing more daunting than a blind page as Ellie just said. To me, it can feel like I'm staring into an empty void with feelings of overwhelm and anxiety. I'm not sure if y'all have that too. But having templates and starting points helps when you're feeling overwhelmed as well. If templates and standards are also helpful for those of us who are newer than us, tired, stressed, or just plain busy, by helping increase focus and facilitating professional, empathetic, clear, and task-based language so that we can just start taking action and getting things done. And we kind of want to stay prepared instead of just planning, test your new documentation as you go, continually check, run drill, because plans fall apart and that we're preparation and help us. Circumstances can arise or suddenly people need to leave your project or need to step down and others need to take over from them. This is why it's more important. This is why it's so important for us to ask for help sooner and continue to collaborate, refine, and reiterate. Because as we know, some people are good at some things and have a harder time doing the other thing. And when a role is just thrown at you, sometimes you're gonna have to do something you don't like or have a harder time doing which costs a lot more energy. But if you have these clear guides, pass them out line, it helps assess where you are in the planning, what it's done, what still needs to be done, and it makes it easier for folks to hand off tasks that they have less bandwidth for or are unable to complete. Preparation needs you have backups to delegate to, folks that can step in and use their strength, and then they know what is expected from them and where things are left off, so they can pick things up much easier. Another important thing to focus on is onboarding and mentoring. We should always be looking for new volunteers and new contributors, but one of the bottlenecks is training and mentoring new contributors, and by having these templates and playbooks, you drastically reduce the hands-on nature of onboarding new folks. Of knowledge and recognized contributors and their contributions, no matter how small they may think it is, giving thanks goes a long way. In terms of volunteering, contributing to your project, a lot of people are limited by their time, means, their ability, their position, some people might be looking for work, like, like us, or they're trying to advance their career, for example. So encourage both publicly and privately, and even outside of your project, thank you the momentum or social media, for example, and encourage them to have their volunteer work to their CVs or read them names. Otherwise, other ways to incentivize volunteers is by sponsoring their tickets to camps and conferences, and payment and sponsorship of their time and effort is a great way for enabling folks who may not otherwise be able to help. So it's not about just doing things for recognition, it's about valuing people's time and time and effort, and about empowering them to grow and succeed. And, of course, you're decreasing the UFO abduction issue, which, especially for smaller projects, even though it can be hard to start. So we're an open source, but we should work openly. We should focus on transparency and collaboration, which means starting where you are. You may not have the resources or skills you have within your project to create a comprehensive plan, but when you start with what you do have and document what you still need, your to-dos, your wish list, it can and will grow as you continue doing the work, because by doing this, you're attracting new contributors with those skills you need, because you're actually asking them, you're telling them what you need, and you're reaching out. We are an open source, so work openly, and remember, perfect at the end, we have done. Ask for help, project managers can be an amazing resource to help you create these templates, playbooks, and succession plans. Reach out, introduce them to the community, and give them contribution credits. That way, you're helping advance your careers and giving them experience, and kind of bringing them into open source, which is all we're talking about. Also, actively encourage your users to use and contribute to these resources. Link to them all the time, make them easy to find, give your resource documentation clear names, and use them as part of onboarding, and keep referencing them while you're working. And then make introductions to stakeholders, like other contributors, sponsors, any relevant members of the community, and encourage that back and forth of reaching out and for guidance and support. So succession plans are like code of conduct. They increase safety, participation, and community when they are used and enforced correctly. And of course, encourage feedback, and solicit help during the entire process. Detectives things are clear and helpful while you can find any gaps or things you may have missed, and continually refine and reiterate, because remember, we are always a working product. So now we will go on some examples of an open source. There are a lot of open source communities doing lots of stuff, and we're gonna take a look at a few of them. And remember, it's open source, so you can go over there, contribute, collaborate, and open source some of their ideas, documents, and work on them as well. So CNCS does a great job of encouraging contributors to grow and they can grow by using what they call the contribution. Contributor ladder, so just like rungs of a ladder, folks can step up to new roles, and they also highlight the benefits of stepping up to these contributors. They do a great job of that as well. Another project CNCS does well is they have clear documentation on how to use and contribute to their template, and list them all together to make a mean divine. And this is the part we're talking about refining, because there they have these clear documentation. It's easier to add new templates and contribute to the ones that are already there. So if your community keeps growing in the templates and your resources keep growing that way as well. Does an amazing job of highlighting different teams who contribute to what their goals are and defining the tasks that personas they're looking for within those teams. But at night, it's easier for your contributors to jump in and be like, okay, I can help here. And type of three is a great example of clear and easy to use community of expectations. They supplement their code of conduct with a little tlvr in the beginning, as you can see there, alongside breaking things down into general advising rules. And those rules have a fact that go along with each role to kind of explain community questions and frequently ask questions, of course. And they make this document incredibly accessible by having it translated into multiple languages. WordPress. WordPress facilitates collaboration between their different teams by having team reps. So every team has their own team page which relates to what they do, how to find them, how to contribute. And then they also do a great job of explaining the needs and process in detail along with the expectations of the role and the tasks and responsibilities associated. WordPress is contributor, it is also great in this facilitated collaboration. No, they encourage contribution. Sorry, by having plenty of courses for you to take and by offering lesson plans for you to train others, which I love because that way you're helping to help others. And they make these courses accessible by having overviews of what these courses are, what's covered in them, and estimates of how long it took others to do them. And now on to Drupal. Drupal has many resources of community and communication expectations and guidelines. They offer templates, suggestions, and do's and don'ts, which you can all collaborate on as well. Then Drupal contributor guide is written as they offer personas, references, and great ways of finding projects to contribute. For example, by listing the community initiatives, which by the way, if you're interested in, there's a keynote happening on Wednesday for the community initiatives. Another way Drupal encourages healthy communication is by using nudges, either a little template that anyone in the community can use and collaborate to and add to, with just to kind of help move conversations into an effective and helpful way. And then we have the Drupal event organizers playbook. This was done in collaboration with the amazing folks of the event organizers working group. We'll have a box here as well, and the documentation team. This basically has, it's a playbook with guide through documentation on everything you need for event planning. You could use these playbook, for example, for what we wanted to do and create things into your tooling, like in your Canada boards, or your to-do list. And they also have the event accessibility playbook, make your event more accessible, both online and in person. And with that, I'm gonna end it over to Ali for a few more minutes. Yeah, just a couple more examples from Drupal. There's, as I mentioned at the beginning, the new contributor mentoring initiative, which overlaps with a lot of different projects. I think Dries even mentioned meeting to bring more folks in as contributors more easily. So this is really still in alignment with everything that's going on. And I am super happy that Amy June got part of the Pitchburg money this morning to update some of the mentoring materials as well. So mentoring leads are recognized in the Drupal core maintainers.txt file, which is just in core, and it lists everybody who maintains various components. And in theory, every year, the mentoring leads go through. We review the file, we see who's listed as a mentoring lead, and ask if anybody wants to step down this year, and if we'd like to nominate anybody to take up the mantle. To be honest, this is still a work in progress. We have not reliably done it every year, but we are evolving the process and making sure that it's fair and balanced and documented to go back to my first points. It's important to remember that being a mentor is also a form of contribution to the Drupal project or any project. And there are definitely still some tasks that are not documented. And it's just the same folks showing up year after year for all of these events, Drupal cons and camps. And it's just stored in their heads and we need to put that onto paper. So this session has also been a great way to encourage myself to help get some of that done. And there's also Drupal diversity and inclusion, which has gone through a few leadership changes since formation in 2016 or so, yeah. So I think Nikki Stevens started this, started all the documentation especially, and then Fatima really enhanced things. And I was looking through some of the leadership files the other day and there's just nicely organized folders, there's onboarding documents, there's spreadsheets, there's lists of things that you're gonna need access to when you join the leadership team, very nicely done. Everything's templatized and the process for adopting and onboarding new team members is streamlined. So there's no guesswork and there's no additional back and forth. But we learn something every time too because there's always gonna be a new question. And then we can add to all of those materials. So on the right here is just a sample of the internal leadership team onboarding document you can see at the top, little changelog, which is very simple and links back to a previous version of the document. So it's really evolved quite a bunch. And I also wanted to say that the DDI team is looking for more folks who wanna get involved. Last few years have been a tad rough and a lot of people are sort of taking a wee bit of a breath right now. So if you or anybody you know wants to hop on board, that would be super awesome. Feel free to reach out to me or just in the diversity and inclusion channel. Yeah. And I think then we go back to Jordana again. Okay. So turning your motivation into action, just a few practical tips and a quick rundown of everything. So create documentation and tasks. Write down everything. Relative due dates. So some of the dates to hop are relative due dates, estimated time to complete and instruction and assets to accompany tasks to increase focus. Because if you have all of the information you need to start and complete a task, your most people are gonna be more likely to pick it up and you won't have a lot of that back and forth. That's sometimes necessary. And then assign and remind, which we'll talk about a little bit later with some, we're automation and health as well. Posting guidelines. So guidelines on expectations of contributors, expectations of the community. Examples are code of, how we're having code of conduct, the issue queue etiquette, and templates for comments and emails. Again, try not having people start and scratch. Same with projects and public health templates. If things are much more likely to succeed when you have templates and when people are aware of what is expected from them for creating projects and adding comments to figure out what's helpful and what is it. You also have templates and creating nudges like we saw with the little snippets that you keep using. Keep communication open and be honest about availability. If you're having a rough time, if things aren't going well, if you need to start stepping down, be open and honest about things, it's always gonna help you much better in the long run than suddenly having to disappear because things are getting overwhelming. And use have and work visibly. It gives a great big picture view of where your tasks are, what's the lead to be done, what's completed, what's unassigned, what is assigned. And of course, mentor and encouragement to write. You can do that by shadowing, by onboarding the contributors, by creating documentation and what we also spoke about is if you want to help speakers and new speakers, you can do what we lovingly call being a speaker buddy. So if you have somebody that is interested in a topic you wanna talk about, invite them to do the talk with you or just be there as a mentor for support, running their talk through being just like somebody that can give feedback and helpful guidance and tips. And try to automate as much as possible and this is possible with things like flat workflows, get out of actions. Yeah, I'm having like those things to grab some of your templates and just being able to be sent. The reminder tools and nudges are also great examples of things that go with well with automation. Back to me. And one thing I wanted to add to that was that while specific tools have all kinds of benefits and cool features, the best tool is the one that you'll actually use. So with like post-it notes. If that works, that works. It's totally cool. All right, so now we've got this nice summary slide of some key points. If you take nothing else away, some highlights, just things to keep in mind. They're somewhat alliterative because they can't help myself. So first up, delegation, focus on enabling others or future you to do the work. Preparation, continuously update documentation, be ready for unplanned trips to outer space or whatever, you know, parental leave or sick leave or just companies have layoffs. It happens. Documentation, process of succession, access and materials, just try to have as much of that as possible written down where other people can access it. Automation, simplify with bots like a Slack bot, a chat bot. I think there are clever little things you can do in Mac OS too. And other recurring items, calendar items, that's the simplest automation, right? Iteration, start where you are and be open to change. And finally, recognition. Always include thank yous and credits and other forms of good karma for everybody involved. The smallest thank you can really make somebody's day so much better. So never hesitate to be kind. Back to Jordana. Yeah. I also wanted to give a quick shout out to the tools we use as well. You're absolutely right. If you might have the most amazing tool, if it doesn't work for you, it doesn't work for you. But I may have just forgotten my point, I'm so sorry. But trying to simplify the tools used, document all of the tools you're using and the credentials are added off as well. We've mentioned that a little bit, but a super important thing we've seen, we've had issues with in the past where we forgot about certain credentials, getting on the off certain credentials. And then yes, we want to give a dance warm either for us. So let's remember to give ourselves and other grace and others grace as we are all doing our best and our best differs from day to day. I wanna thank you and everybody here for contributing and being part of the Drupal community and making things wonderful. Yay. And then we have a slide with some volunteer opportunities and things, stuff that's going on. We have the, we've mentioned the community initiatives that's happening online, so we're just not on the slide, but we have some birds of a feather or box that are happening as well, which are very interesting for very interesting initiatives that are going on, so you can learn more about them there. And then of course, we have the community summit on Thursday for your, you'll hear from a lot of these same groups, the community urban group, the event organized working group as well and have our own table. And the community summit is free unlike some of the other summits. So definitely show up if you want to. And then of course, join us for contribution opportunity. Yay, yeah. All day on Wednesday is contribution time that's going on the rest of the week too, but this will involve the first time contributors workshop. The first round of that will be at 10.30 and there's another round at one o'clock. And you don't have to do both. It's one or the other. You can hang out for both. That's fine too, but they are the same content. So if you're a new contributor, hit that first and then head to mentor contribution and otherwise go to general contribution and find a group that you're interested in working with and see how you can help. And even if you contributed before, the new contributor workshops might be interesting, learning a thing or two. And if you've contributed before and you're not sure if you can be a mentor, you can. Nobody expects anybody to know all of the things. So you can definitely be helpful. And so joining one of, I think one of the boss happened already. It happened right now. Yeah. And then another one I think tomorrow morning that Adrian is running. Yeah. So even if you're just thinking about it, feel free to join, figure out how things work and see if you want to or not. And then don't forget, okay, then don't forget to kind of check out our HQ, leave comments, reach out to us. We love your help. We love your thoughts and give us feedback on what you have for a lot of the presentation. Yep. And grab the slides so you can see them slightly bigger. That's it. Instead of my humongous day. No, but your face is beautiful. Okay. Awesome. That's it. That is the presentation. Are there any questions? Otherwise we might have some questions for you. New questions. Okay. If anybody feels up to it and wants to speak up or raise a hand, have you ever joined an open source project and just found the documentation totally lacking? You don't need to say if it was this one. Do you feel comfortable volunteering what was missing or what was provided? If there was one thing that would have really helped just get started. That's cool. Feel free to like draft some thoughts and leave them in a comment on that. Handy issue queue. The one on the right. Cool. Thank you so much for coming. Good to see you all. Have a great DrupalCon. Thank you, Allie. Thank you, Jordana. I miss all of your faces. I wish I was there. I know. I feel bad you can't see the room. You just get me. I'm curious. Why aren't you at DrupalCon for a long time? Oh. Can you share why you're not at DrupalCon? Yeah, sure. For the first time, my visa was denied to the US. So that was very surprising and upsetting in many different ways. Yeah. Really bites. I did take the opportunity to come to the Netherlands to be in Drupal Jam though. So I'm trying to mitigate my formal of missing out there. Not working very well. Well, it's OK. I've got FOMO about missing out on the Netherlands. So maybe it balances out a little. I'm going to unplug.