 Hi there. Hello and welcome to improving the Drupal contributor experience. This is kind of the Drupal community working group session. I'm George Domet. We have Mike Inelow, Emma Cariannis, who are also from the community working group. Adam Hill is our other member. And he unfortunately can't be at Drupal Cotton Dublin. He's back at home with his wife expecting a baby like any day now. So the community working group is a volunteer group. We are chartered and appointed by Drees. And we promote and uphold the Drupal Code of Conduct in order to maintain a friendly and welcoming environment for the Drupal project. Ways that we do this, we field incident reports. When somebody has an issue or observes or experiences a code of conduct, violation is just something that's just wrong. They file that report on a web form on Drupal.org. So we try to help diffuse tense situations that can sometimes involve mediating and or arbitrating, and particularly seemingly intractable disputes. We also help develop tools and resources to promote community health. And we work to try to recognize leadership in the community one way. We do this through the Aaron Windborn Award, which we give out every year at the North American Drupal Cotton. So as members of the community working group, we often find ourselves in a position where we hear a lot about contributor frustrations and complaints. And when you've been doing this for long enough, you start to see some patterns emerge. And we feel that these patterns are really symptoms of some larger structural and cultural issues in our community. Some of the things that we see include technical disagreements that turn into personal attacks, often involving people lashing out at each other in issue queues or on IRC. The big thing we've been dealing with a lot recently is frustration with the amount of time that it takes to review patches and project applications. If we don't address these issues, some of the potential consequences for the Drupal Project and community would include decline in contributor morale, decline in productivity, people leaving the project. We've seen this happen. And people choosing just not to join the Drupal Project. But in order to really understand and address these issues, we need some data. And fortunately, we do have some. So back earlier this year, Drees held a state of Drupal Survey, which 2,900 people responded to. One of the questions he asked was about the challenges, frustrations, and problems that people had with Drupal Contribution. And I know this is very, very hard to read. But the two biggest challenges cited at those two bars at the top are the complex issue queue and slow consensus building, and that bugs and patches don't get reviewed quickly enough. So that's followed by a variety of other issues going down. People not knowing how to contribute, complexity of the architecture, project application review process. And interestingly, if you go all the way down to other, one of the, a lot of the people who answered other cited lack of time as an issue, which was not one of the options in the survey. So if we summarize the complaints that we've heard, along with the results of Drees' survey, kind of the big picture issue is this, right? Contributing to Drupal can be slow, complex, and time consuming. And many people don't have the time or the patience to do it. And I think most folks who have been around Drupal would agree that this is true. And I want to be really clear, like having something be complex and difficult and challenging, that's one thing. If there are artificial barriers that are making it needlessly slow and complex and time consuming, that's where you're talking about trying to solve problems. And at the end of the day, like if you're facing artificial barriers, you want your sense of achievement to be that you've accomplished something, not that you've, oh my god, finally gotten through this horrible process, right? So we've also known for some time that contribution gets more challenging the higher up the ladder you go. So this is a graph from the research that we did back in 2014. This was the Drupal Association and the other CWG I was a member of at the time, the Content Working Group. We did persona development for Drupal.org. So representing interviews with dozens of current and former members of the Drupal community, as well as people who evaluated Drupal and ultimately chose not to adopt it or to become part of our community. And so this model is based on the Dreyfus model of skill acquisition. And what we found is that while we're actually pretty good at onboarding people at the entry level of contribution, we lose more and more people as we move up the ladder, particularly once you can get past that learner. And you're going into the skilled expert and master. The number of people at those levels is dramatically less. So Dreyfus did some research earlier this year, along with Matthew Tift, into the sponsorship of Drupal Development. And so they found that despite the large number of individual contributors, it's a very, very small number that do the majority of the work. So 51% of the contributors involved got just one credit, while the top 30 contributors, which represents the top 1 half of 1% of all contributors accounted for over 21% of the total credits. So what we really should be doing is helping more people move up the contribution ladder in order to spread the burden across more shoulders. This also helps create more engaged community members, which also has the impact of increasing Drupal adoption. Megan, in her plenary session this morning, talked about the adoption and contribution journeys. And if you saw that graph that she showed, it's a circle. They all feed into each other. They're intertwined issues. We know that one of the historical hurdles to Drupal adoption has been the shortage in talent. And the long-term sustainability of our project depends on our ability to resolve that problem. So how do we get more insight into the root causes of these common issues that are experienced by contributors? And fundamentally, how can we find an answer to the question of what can we as a community do to help improve the experience of contributing to Drupal for everyone? Right now, I want to be really clear. We're not talking about technical solutions here, but things that we can do as people to help make Drupal contribution more accessible. So yeah, we launched yet another contributor survey at Drupal Con New Orleans, soliciting feedback from people who had been involved in contributing to Drupal, and particularly during the Drupal aid development cycle. We publicized a survey on Drupal.org. We broadcast it as widely as possible via social media. But it wasn't all we did. We also reached out to and held follow-up interviews with a lot of the people who had responded to the survey and said it was OK to reach out. We talked to those people both virtually. We also talked to a bunch of people in person at various Drupal events that we were attending this summer. So very quickly, let's take a look at the demographics of the survey. So we had 109 respondents. The gender breakdown was 86% male, 10% female, and 4% chose not to share. That may sound very skewed, but it's actually fairly consistent with Drupal.org analytics, which are about 84% male and 16% female. It's also fairly consistent if you take an average of North American and European Drupal cons and the gender breakdowns between them. It's pretty consistent. So there were 33 countries represented in our survey. 39% of respondents were from the United States. That's probably a little bit high. Drupal.org analytics are closer to about 21%. 6% of the respondents in our survey were from India, while about 12% of Drupal.org traffic is from India. And other countries that were less represented in our survey would include France, Russia, and Ukraine, which also have a fair number of Drupal.org visitors. Over half the people who responded to our survey have been contributing to Drupal for more than five years. And nearly three quarters have been contributing for at least three years. So if this is representative of the contributor community as a whole, then the lack of fresh contributor talent is a concern, particularly given there was another contributor survey done back in 2011, which indicated that only half of respondents have been contributing for more than three years. So this may indicate that our contributor pool is aging and narrowing. More than half of our respondents spend less than four hours a week contributing to Drupal, with the other 28.5% spending five to 10 hours a week. So for this one, how did you contribute to Drupal 8? We let folks provide more than one response. So the highest percentage helped write code for a Drupal-contributed modular theme. The second was help write code for Drupal Core, help provide Drupal community support, which in this case includes things like project management, sprint organization, and other events, training, mentoring, et cetera, helped write Drupal documentation, helped work on the design, UX, those sorts of things, didn't contribute to Drupal in any way, and another. About 40% of respondents said they experienced burnout during the development of Drupal 8. So we asked those people what they felt were the leading factors that contributed to their burnout. And these were some of the things that we heard. Slow progress, bike shedding, feeling over my head, lots to do before deadline, contributing on top of a full workday. I suspect this sounds very familiar to a lot of folks. Development cycle was way too long. There's always more to do and no defined end point. So obviously, this is something that's mitigated somewhat now by semantic versioning and scheduled releases. So hopefully, we're making progress there. Lack of clear goals, very complex code base, uncertain, flexible deadlines, e.g. feature freeze. Difficult to move large patches forward, very hard to find qualified reviewers and collaborators. Again, this is something that we heard quite a bit. Very difficult to get patches reviewed, inconsistent messages about deadlines and policies and inconsistent application of policies. It feels like whatever the rules are, they only apply to some people or some patches. So 60% of our folks said that they had experienced or observed conflict during the D8 development cycle. When we asked what they did about it, most folks said they ignored it. Some said they intervened and or reported the issue to the CWG. Others said they either left the issue or stopped contributing altogether. Nearly three quarters of our respondents said that they were able to receive non-technical support from others, overwhelmingly from other contributors in the issue queues, IRC, and at in-person events. Smaller numbers cited work colleagues, followed by family and friends. Our respondents were almost evenly split over whether or not there were non-technical barriers to communication in the contributor community. We asked those who answered yes what some of those barriers were. These were some of the things that we heard. Feels like there are superstars and then everyone else and it's hard to feel encouraged to help out with the bigger initiatives and development. Again, similar theme, mostly perception. The perception that people working on core are better or more important or are to be treated differently from other contributors. Number of folks talked about both issue queues and IRC as being a barrier to communication specifically, but this is kind of the general feedback. Most of our communication is text-based and not real-time and for many contributors that is in their non-native language and this leads to a lot of possibility for misunderstanding. Documentation is hard to discover. Again, I know this is something that hopefully has changed recently with the new documentation on Drupal.org. So almost two-thirds of our respondents said that they felt the experience of contributing to Drupal could be improved by some kind of organizational change. We asked then those folks what kinds of organizational change would help improve the contributor experience. More leadership from the top, not necessarily a dictator, but ideas vetted early at the top and then worked out by the community as a whole. Empowerment of initiative leads to make decisions in order to move forward. We heard this come up several times. We need more transparency and it's really grown well beyond this idea of a benevolent leader making the hard calls. I'm not sure how to change that, but it has to include more open democracy and some new blood. So kind of a common theme that we were hearing was a more structured and more transparent decision-making process. Mentors should have a more important presence in the community. We heard this from a lot of people that we not only needed more mentors but more one-on-one mentoring. The process to approve Sandbox project is full projects needs to be much cleaner. It's too difficult to have a project approved with a lot of people complaining about the project application review process. So we spent most of this presentation so far talking about the frustrations and problems that people have contributing to Drupal, but there is a silver lining. Over three-quarters of the people that we talked to indicated that they were very likely or extremely likely to continue to contribute to future versions of Drupal based on their experience contributing to Drupal 8. So we have a very loyal community and what our challenge is is to make sure we continue to earn that loyalty. So this is our final question. What is the number one non-technical change that you feel should be made to improve the Drupal contributor experience? I don't have a pretty graph here because we just let people type in whatever they wanted. So here's what some of them said. Again, this is a fairly representative sample of the responses that we received. Lower entry barriers by making it easier to contribute modules. Fix the application, project application review process. Like I said, we heard this a lot. Greater acknowledgement of non-code contributions. We need to improve our tools for contrib to at least GitHub level. So this is not actually a non-technical change. This is a technical change, but enough people mentioned it that I thought it was good to include here. More detailed roadmaps. So potential contributors can see where they can jump in outside of just combing an issue queue. And finally, feminist new world order, which I personally agree would solve everything, but is sadly outside the scope of our authority as the community working group to implement. So moving on to the second part of the presentation, we've been talking a lot as a group for the last year about different ways to improve the Drupal contributor experience, right? So what follows are a series of recommendations, and these recommendations are based, not just on the results of their surveys, but the follow-up interviews and conversations that we've had, as well as our own experiences as members of the Drupal community. So we've divided these up into two buckets. One bucket of things that are within the scope of the CWG's charter to kind of influence and lead, and another bucket where things that we are, where we're looking for the community to take leadership. And to be clear, neither bucket is deplorable. So, yes, you get the election joke, thank you. So first, let's talk about some of the things that we wanna see the community focus on. Streamline the review process, okay? So literally, everyone is on board with this, right? I think we all agree that this is like a immediate problem that needs to be addressed. And I know that people are already working on this. So we're not gonna tell those people what to do, but these are some of the things that we think any reforms to the review process should include, right? Empowering and enable more people to be able to conduct reviews, making the process more transparent to avoid an appearance of favoritism, making it easier for reviewers to find unreviewed projects, making it easier for reviewers to actually indicate definitively that they have approved something in an issue queue or a project or a patch. And the community really needs to provide encouragement and support to the people who are already working on this. And really, I know that there are a lot of different, sometimes conflicting interests at play, but I really think that we can find a balance. Number two, improve communication. Don't rely so heavily on IRC, especially for new contributors. This is something that we've heard that, I think IRC was very, very important in the first decade or so of Drupal's life, but IRC is something that not as many people are using these days. There are other channels, other ways that people can communicate. So to that end, we think it's really important to mix both asynchronous and real-time channels, Skype, Hangouts, Slack, et cetera, as appropriate. You don't have to be all one or all the other. And understanding and appreciating that English is not everyone's first language, right? So one kind of little anecdote I have here is a friend in the Drupal community last year got really, really upset because someone wrote in a comment or a queue that they had written this thing and the person wrote about how I demand you provide me more information or more context about this thing. And this friend was really, really upset by this. It's like, what right does this person have to demand things of me? And then someone else pointed out, was this a native French speaker? And they're like, oh yes. And it's like, well actually, the literal translation from French, when you say demand, it's actually more like a polite request. And so they were being respectful, but it didn't come across that way in English. And so we've seen this come up in many, many issues, several issues that have been escalated to us where things can sound less polite or blunter if English is not your first language. And so I think that people, that's something that people really need to understand and appreciate. And then making it easier for newcomers to know where to go to connect with other contributors so they don't feel so much kind of on their own. You come to DrupalCon or a big Drupal event, you get the rah rah community like mentorship experience and then where do you go from here? So roadmap communication. So first, creating easy to find summaries of active initiatives on drupal.org, making it easier for contributors to get involved with initiatives that interest them. And a lot of the suggestions here, the recommendations here are really designed right now if an initiative is already in progress, it's not so easy to jump into it. So really what we wanna make sure is that even folks who are not there at the beginning can still very easily find and jump into something that's going on at the appropriate level and don't have to spend all this time getting caught up to speed on what we're trying to do here. Clarifying the role of initiative leads. This is again something that we've heard quite a bit. And then improving documentation and providing architectural overviews for future contributors. Again, this is something that happens very often at the beginning of an initiative but making sure we're keeping that information up to date not only lets folks come in if it's an in progress initiative but if it's something that gets revisited later on down the road we don't have to reinvent the wheel. So now moving on to that second bucket of things that we as a community working group really want to focus on. So mentorship is a big one. We want to move the focus beyond onboarding newcomers and core mentorship hours. This is not just about onboarding people but making sure that we're moving them up that engagement ladder so that mentorship continues. Mentorship is not just for people at the bottom of the ladder. Mentorship needs to be present in some capacity at every level. One of the things we heard quite a bit was pairing mentors with high potential contributors for long-term one-on-one mentorship like almost kind of like a buddy system, right? And the reality is that this does happen right now but in an informal way, right? So we talked with some core contributors who were like I wouldn't be here if so-and-so and so-and-so and so-and-so hadn't generously worked with me one-on-one to help me get where I am today. And what I'm suggesting we need to do is, what we're suggesting we need to do is formalize that and make that something that's more structured so that people have that ladder. Providing more non-code mentoring opportunities. So one big one that came up in particular is camp organizing. So very frequently if you have a camp there's one person or a small group of people who really take the leadership and spend a lot of time and effort and energy putting a camp together and if that knowledge is not transferred then the next year everything, the wheel gets reinvented all over again. So if there's an opportunity for people who are like this is something I'm interested in to receive mentorship from those people to help out and then they can be better positioned to step into those leadership roles moving forward. Providing more support and training to mentors. We have a number of really fantastic mentors in our community who do a tremendous amount of work but we need to be able to provide not our existing mentors with support as well as additional training so we can build up a really strong mentorship community. And then finally, promoting mentorship success stories. We need to talk more about those stories where people who got mentorship were able to become like really wonderful members of our community. So recognize and appreciate that. So second, leadership training. And I want to be really clear that what we're talking about here is not just for initiative leads. This is not code focused. This is leadership across kind of all the different areas of the Drupal community whether that's events, mentorship, et cetera, right? So right now, a lot of people find themselves put in informal leadership positions within our community and they don't have any preparation or training in basic leadership skills, right? Some people are able to develop those skills on the fly or may possess them innately but others require a more structured approach. So we need to go beyond just the innate skills that people have and so what we're suggesting is a structured program for current and emerging leaders in our community. This would be, you have a curriculum, people would actually meet in some capacity and think of it like a class, right? And this would extend probably over months in order to get there. The focus would be on developing skills like create a problem solving conflict resolution, effective advocacy and visioning. And it would broaden an understanding of the Drupal community, right? Its assets and its challenges, right? So we have a lot of folks who are leaders in the community and they're leaders in their particular niche, right? But they don't necessarily have the full understanding of the breadth of like how all the different parts of our community fit together. So the model I'm thinking of here is something that I've been through in my own local community. Adam has also been through it. There's a model for this that exists of the community leadership program where you go around and you might have one meeting where you learn, hey, here's how the school system works in our community, right? Here are the issues and the challenges that we're facing with our school system. Here are the opportunities that we have and we might hear from representative of the teachers of the administration of the parents to really understand how things work. And then in the next class you would learn about some other aspect of your community, right? So that's the idea here. And the goal is really to create a network of leaders within the Drupal community that can really share knowledge and work together to create the sort of, and transfer that knowledge to others, right? So I really think that if done well, this is something that would have ongoing benefits for everyone in our community. So conflict resolution. So we've got creating easy to find resources that people can use to resolve issues without having to escalate them, whether that's to us or to someone else. Providing more conflict resolution sessions and trainings at Drupal events. So we have this being human track here at Drupal Con Dublin. That's a really good first step. And on these items as well, we get a lot of help here already, especially from the work that comes out of the community summits, right? This is a great opportunity for people to contribute to either don't know how or uncomfortable contributing code. And in the end what we're trying to do is create a culture of empathy. And it's funny, Dries talked about this earlier, Drew Gorton talked about this, really seems to be kind of a theme maybe of this conference. The answer here we think really lies in this, come for the software stay for the community slogan, right? Our greatest asset is in our code, it's our people and all of our efforts at every level need to reflect that, right? So for those who may have been at Drupal Con Barcelona or watched the session online, David Rosa did a session where he went into some of the academic research that he had done on Drupal community and contribution. And one of his findings was that we as a community tend to give less attention and thus less value to non-code contributions. But really strongly made the point that it is those kinds of contributions that play a key role in the ongoing sustainability of our project. So again, I wanna be really clear, this is more than just about making sure that people know how to take care of themselves, right? It's something that needs to be reinforced at all levels. We need to stop glorifying over work, you know? When people feel like they have to burn themselves out in order to be successful, that's not an individual issue. That is a sign of a larger structural problem that needs to be addressed. So, suggestions we've offered today are, you know, a starting point, we want to, they're designed to both address some of our immediate problems, as well as helping to build out a structure to hopefully help support a healthy and sustainable contributor community in the long term. So, that's enough of me talking. We'd like to spend the rest of the time here. We have a really, I think, good group of people for this, talking about some of the ideas and getting feedback. So, if you are watching a recording of this session or if you aren't comfortable speaking up today, that's okay. You can reach out to us after the fact. We put up our names and Twitter handles here and we're very proud to announce that as of this morning, we do have a new Twitter handle for the community working group at Drupal Community. So, you can now follow us on Twitter to get updates on the work that we're doing. Please don't use this handle to file complaints or issues. Please continue to do that through our email form. We don't want folks reporting stuff to us on Twitter, but we would like to keep the community updated on both this work that we're doing and other things that are going on in the community. So, now I'm gonna turn it over to Mike and Emma and you guys are gonna leave the Q and A portion of the session. Thank you. Thank you. Thank you. All right, fantastic. George answered all of your questions. Yeah, absolutely, we knew it. The community is fixed. All right, Gabor. I have some things. So, one of the things that we had a heated discussion about at the DrupalCon Slack channel, I think, is the Drupal Heroes Twitter account, which celebrates Drupal Heroes. And I was trying to argue that it's bad because you should not. I mean, it makes it a bad impression that you need to be a hero in Drupal. And I don't think we need heroes. We need people to make things happen and there don't need to be heroes. We don't need to have like these, like that's what you said in the survey that there's these superheroes who make everything work and then the rest of the people. And that makes the rest of the, that makes the making things happen much harder to achieve if you think you need to achieve superhero status to be able to do things. And I think the way we celebrate our biggest achievers may not be the right way. And they were like multiple opinions there and some people said, but we need to do those celebrations. And it makes me empowered. Somebody said that it makes them empowered when Drupal heroes tweets about them or retweets their tweets. And I was like, yeah, maybe, I don't know. Well, I think the key there is how it's promoted, right? So you can, I mean, I think by now, there's not a whole lot of fans of people using the term rock star or hero. But I think the key is if you can promote a success story and that success story can speak to other people who started from a similar place and find common ground saying, oh, well that person, they're a middle-aged white guy from Florida and he did it. So, I'm a middle-aged. If a middle-aged white guy from Florida can do it, anyone can. Yeah, we're pretty low bar. So. But I mean, I agree with you where the superlator that we use is probably not the best idea, but I like the idea of success stories that other people in the community can relate to and say, well, if they can do it, I can do it. Right, I mean, I think it's right. I mean, it also has to do with how you think of what a hero is, right? So there's, you know, there are your comic book superheroes who are able to achieve what they achieve because they have amazing powers or abilities or if you're a Batman, just wads of money, right? And, you know, and that's not the image we want to promote. That is not at all what we want to promote, but I think this idea that like everyone, anyone can be a hero, this idea of the everyday hero, right? You know, so, you know, we often, at least in America, talk about like, you know, people like policemen and firefighters and other people who do kinds of public service, right? As sort of everyday heroes. And, you know, and I think I, personally, I like that kind of idea, but, you know, I'm not familiar with the feed, so I haven't, you know, I don't know exactly how it's being used right now. Hello, it's Paul Johnson here. I just want to echo what you just said, really. I helped to run the Drupal social media. And one thing I've consciously done over the last two years is to pinpoint somebody who is not a hero, somebody who is from a country where perhaps Drupal isn't very big or they've had a small achievement and by shining a huge spotlight on that, make them feel amazing and hopefully inspire us to follow suit. So I've kind of flipped it on its head. I can see a place for both things, but I'm quite uncomfortable with the idea of heroes as well. Yeah. So I think what I'm hearing you say is that it would be effective if you focused on the process as well as the outcome. It's not just outcome driven, but one of the things I'm really interested in, everyone in this room's thoughts on is you reiterated several times in the presentation that we need to value non-code contributions as well. And to me, I see contribution in three different areas. I see contribution in code, contribution financially, and contribution in volunteer time, whether it's with events or other committee, community working group takes a lot of time just in case anybody didn't know. It's a lot of time investment. And for those watching the recording, this is Tiffany Veras, who I also happen to be married to. Yeah, so it takes a lot of time there. Wearing my wife hat, wearing my board hat, I have a different question which is, how would we go about finding ways to create a rubric of contribution if we were to recognize it? How do we create a way to quantify those contributions? Right now, we have a way to recognize code contributions in core based on commits. And we know that that's been a big step forward for us, but it certainly is limited in its scope right now because their commit's too core and they're based on each commit. So if it's a really big commit or a really small commit, it's still one commit, right? So what I'm interested in are thoughts around how do we quantify so that we can recognize those kinds of contributions? I was gonna tweet that question out to the whole world. I didn't get that false enough. You're the one that's supposed to answer it. I know. No, no, the whole room. Well, let me take one out of that rubric of three kinds of contributions. Let me just take one out, all right, which is financial contribution because that's pretty easy. Yeah, yeah, that's whatever, sponsorship, advertising. So people who have money usually do not have difficulty getting attention, right? So really, I think, and we, like you said, we know how to focus on talk about code, not in a perfect way, but so I think really the key is are the non-code community time, the organizing, the events, all of that sort of thing. How do we make sure that those kinds of contributions are understood and recognized to be valuable? So the first thing I'll stop my head, the thought, is because we mentioned the mentorship and the body system and things. And the first step we can do is just someone who is aware of what you're doing, recognizing it directly to you as well. So you have the body who's like, hey, you did that really good thing. And also if they're comfortable that promoting that, like just sharing that for the world, I would think having a system of everyone looking, not looking after, but like being aware of everyone and keeping an eye on things and supporting and encouraging and empowering is super important for our community because we come to these events and people will say to me like, oh, I really like what you did like six months ago and stuff. And I was like, oh, thank you. Like this event gives you so much encouragement and like feel good feels. But like every day kind of, yeah, if it was more of an everyday thing, that would be really good. Something that I heard was the easiest way to make non-court contribution recognized as if we can get that into the issue queue, have people to review it and then commit as soon as you have a certain number of reviews. So the easiest thing for them to implement possibly is something that could just map to what they're already doing and get some kind of... Right, because really the big core question here that we haven't focused on is the, how do we quantify it, right? So, if I spend, or someone spends two months organizing a Drupal camp, how does that contribution get quantified and understood? So I'm uncomfortable with that question because I think what we should ask is why we want to quantify it? Like what we wanna get out of the quantities that we measured, do we wanna put them against each other? It's like you contributed four hours and that person contributed two months and they are like 20 times better than you or whatever. I don't know. I think we wanted to recognize them and I don't know if we need to quantify them so precisely to recognize them. So if we don't need to quantify them so precisely then we can use different tools to recognize them compared to if we really wanna know how many hours they put in. Well, I think there's two benefits to being able to quantify at some level. Number one, there's a benefit to the community to just have that data, just to know. So that's, there's a value there. The second item is, I often talk to my students about using contributions to market themselves. And so that's, so there's a value to the community and there's a value to the individual and being able to quantify it. But it's an extremely difficult problem as far as how do you actually, is it a number we're talking about or is it a, do we start saying, well, if you organize an event that's five times as important as organizing a meetup. Which will never happen, but we'll never come to any agreement on that and nor should we. Hi, Damien McKenna. So two points. One is that we're not the only open source community dealing with this. The WordPress community have put a lot of effort into documenting some of the things they do, including running events and running meetups and whatnot. So there's a lot of content out there worth looking into. There's also a presentation right after this one from Jenny Wong, who is heavily involved in the WordPress community, but also somewhat in Drupal as well, on various aspects of the WordPress community and what they do. So I'd recommend everybody, well, people who have the time go to that. The other point is that I, from my own point at, or experiences at work, one of the problems I constantly see is a barrier for entry for making their first contribution, people making the first contribution and a, almost a slight, I don't know, it's fear or reluctance to get involved. And so we're trying to come up with an internal mentoring program to break down that barrier to make it easier for people. Because from personal experience, I found you become a, you can work with your tools better if this barrier is not in your way. If you feel that you shouldn't contribute because well, it's only just me. Every contribution is valuable in some way. So if we can get people over that initial learning curve. Right, and that's the idea behind the one-on-one or small group mentorship, right? And one of the things that kind of came up in the interviews that we did is that, so we very often have these big things on Sprint Day where we'll have a large audience of fresh, new, awesome people. And we'll walk them through that whole process. Here's how you do it and everything. And then, but that's exhausting. That is a lot of work. And at the end of the day, there's a small number of people in that room who will be so excited and so energized and really want to move forward. But there's no capacity to keep, working on them because it's like, the mentor's like, I'm exhausted, I'm done, I've done this. And so it's getting not just that first step, right? But moving along that path. I mean, I was struck this morning when Megan was up there and she's like, going through the story of her first commit and it's like, okay, this is the executive director of the Drupal Association. And she got direct access to Angie and Peter Willanen immediately came in and reviewed her patch and like, that's not the experience that most people have, right? But how can we make sure that folks who are going to be good contributors have get something close to that level of attention, right? To your first point about other communities? Yes, we know. We are absolutely looking at things of what other communities are doing. I had a great conversation yesterday with Christophe Entome who was talking about a lot of the work that the Django community is doing. They're a different community than us in many ways but they've really focused on a lot of these questions at a very deep weight. They've even stolen our slogan and I said that was okay because we stole their conflict resolution policy. So that's fair. But yeah, Gabor? So yeah, so I'm excited about the next step after the first contribution sprints because that's sort of highly related to my day job, which is good. So my day job is I'm an initiative coordinator coordinator. So my job is to try to spread some of the good things that we figured out through Drupalite's development and initiatives to other initiatives. And one of the things that we figured out is to kind of in the initiative, so let me start from a bit back. So I think the problem with Drupalite is that it's huge and scary and you have a hard time figuring out where to connect. And initiatives are small and nice because there's a small group of people who have a shared interest. They regularly meet. They are like many people. They want to solve the same problems that you are the itch that you are wanting to scratch. So you have a lot of shared background right there. And if we can make the initiatives, the supporting groups that support the people coming in because they know that the people coming in, they're going to share their problems and they want to solve the same issues that they are working on. And they will mentor those people forward from there and encourage them and help them be successful. And that's a model that we managed to very successfully. We start the UX initiative with. So UX initiative was kind of non-existent half a year ago. And we started it again from scratch and we have this model now. We have twice weekly meetings and we have a lot of new contributors coming in of several different experience levels who like came in and redesigned the status page randomly. It's like, yeah, cool. And then we have other random people coming in and implementing it. And that's also cool. And we can mentor them through this, through these tabs. And I think if we can do the same for other topics like media or migrate or a lot of other things, then those can be like these small comforting groups where you find your place and it's not that scary. And then you can know the people there that can support you. I agree. Absolutely, you know, and I think along with that making sure that in some way that even after that work and that initiative is done, that there continues to be a relationship with the mentor so that they can continue to receive support, because this is the thing. Okay, so that gets you a little more up the ladder, right? But it gets harder the higher you get and the more you need the support, right? Continuing with the initiative, I think the mobile initiative, that was something that I was involved in and really agree and chime in that these initiatives give a very easy way to get people who had similar interests together. And at that time, I'm not still very closely following the initiatives, but at that time, we had project managers who were actually mentors helping people to connect and just recognize the work that was happening. And I think this was really helpful for us. And I, though I was not a code contributor and I didn't understand code, I could take away time that was very precious from some of the core contributors of the initiative and help them figure out who should be brought in next, give encouragement to the newbies, find them where they were closest to. So I think there is in the mentoring space a lot that we can leverage by bringing people who are not necessarily coders and programmers, who are more in the leadership role, who have seen and understand the Drupal community and see how you can leverage the understanding of the Drupal community and the way it works to build these better teams. And train those skills too. Right, yeah. So we've got like one or two more minutes, so Mike, Edwin, do you guys, either of you have anything you wanna like say or ask or? No, I think a lot of ideas are coming just out of this little discussion. Yeah. This is, this is great. Yeah, thank you. Yeah. Thank you, everyone. All right. Thank you.