 Welcome everyone. We are presenting our session on pain points of learning and contributing in Drupal community. We have a link here, bit.ly slash contribution-notes. Would be very much appreciated if you can take the notes as we follow along. My name is Kalpana Goyal. I am K Goyal on Drupal.org and IRC. Kalpana Goyal on Twitter. I am developer at Forum One. We are full-service digital company. We do a lot of non-profit organization work and government agency work. I am Frédéric Maran. I have FGM on Drupal.org and IRC, Ozynet too. Ozynet is a consulting company in France. They're mostly working on performance issues for larger sites like Media Ones. So pain points to core contributing. I want to get started by asking how many of you have experienced pain contributing to core? Please raise your hand. You are not alone. We are in this together. So I want to start with a little bit, with a story about myself, how I got involved into the core. With an awesome core mentoring team. Mentors were on IRC, always helpful. I asked for issue which I can start working on. Everything went fine. And I thought, hmm, so since I have some experience, now I can start contributing on my own and I can go to Drupal.org, look for issues myself, but boy. You can tell I had some difficulty, not some difficulty. There were some subsystems in Drupal 8. I wanted to really contribute to. There was whiskey routing, other subsystems. But the challenging part was find a right issue to work on where I could just jump into that issue and start contributing. I have talked to some of the contributors in the Drupal community and what they have expressed is that the biggest concern is they feel like they don't know much and if you don't know much, how would you contribute to core? And I agree with that because when I started, I felt like I know nothing. And if I don't know nothing, then how can I jump into the issue queue and work on the issue? Also, I have experienced that I had trouble finding right mentor. I wanted to have some mentor working with me and that I can turn to mentor and ask questions where I was feeling or experiencing difficulties while working on the issue. Talking with a few contributors in our community and some have expressed that lack of code reviews. You work on the issue, but you don't get code reviews in time, so that kind of like a demotivational for them and it just holds you back from contributing to core. Yesterday, I went to Alimec and SCT session about Drupal.R changes to support first-time contributors and mentors and they discussed about automating coding standard part of the patch reviews on issue which will make coding review easier and possibility of getting good code reviews in time. Also would like to share one of my story here. Recently, I was at Drupal Dev Days and I was working on one of the major issue. FGM was also working with me. I actually, I was at that point, I was the only one working on that issue and I asked FGM, hey, could you do code review for me since you are sitting right next to me and then we can collaborate with each other, we can talk to each other, we don't have to be on RC. So he wasn't nice enough and he did code review on that issue and he found some nitpicks and he fixed that and submitted a new patch. Great, and testbot came as a read. So I said, okay, I'll take it from here and I worked on that issue. I submitted a new patch and I turned towards him again and I said, can you RTBC my patch? He said, hmm, no, I can't RTBC your patch because I worked on it, it's too bad even though he just worked on fixing some nitpicks but he could not RTBC my patch. So it was just sitting there, but anyway. Another pain point is adding beta evaluation. How many of you know what beta evaluation is? Okay, I'll explain. So since triple eight is in beta release cycle, so beta 10 I guess, okay, doesn't matter. So we add like a beta evaluation form on each issue. Just so when core computer is coming and looking at that issue, they look at the beta evaluation and see okay, this is not breaking API changes, there is not major changes and it's not breaking any backward compatibility. So it's okay to commit this patch. But for the first time contributor, it takes one and a half hour to add a beta evaluation. Think all the time you're spending, coding or documenting or testing UX and then on top of that, you have to add a beta evaluation on the issue. But it gets easier as you keep on contributing on core from one and a half hour to maybe one hour, half an hour or eventually 20 minute. So we talked about some of the pain points, but there are some barriers to core contributing. Going back to the same story, working on the major issue during dev days, I felt I had the pressure that I need to provide a working solution for that patch sooner. If I was working on the minor or normal patch issue, I didn't feel like I had the pressure to finish that issue as soon as I could. Speaking on behalf of other contributors I spoke to, they said, I'm so scared to comment on the issue, even though I have a valid reason, valid concern, but I feel like I don't know much. I don't know enough. How could I go and comment on the issue? The third thing is time and money. Do you think your company or yourself recognize the value and importance of contribution as an asset? As a woman, I have a full daytime job. That's a paid job, lovely. It pays my bill. But I have a household responsibilities as well. And contributing to core, it's a third unpaid job. I don't have time. I don't have enough money that I can quit my daytime job I would like to and work on core 100%, right? Who would not love it? These are organizational problems we have in Drupal and on Drupal.org itself and process issues. There are also problems for contributors regarding Drupal itself. Drupal 8 has become much more complex than previous versions. You know the entity API has been evolving since its humble beginnings as FlexiNode and CCK, then the entity API in seven, then the country entity API in seven, to the large system we have now in Drupal 8 for entity and field API which is now combined. Also we have the new plugins system in Drupal 8 which has at least at last mostly unified discovery of extensions and we have a configuration management. All of this is very new in comparison with other things which made much noise in Drupal like the new symphony components. Routing is a well-known system mechanism. Templating is something which is well-known. But discovery, configuration staging, these are unknowns and Drupal is basically the first open source solution to address this issues head on, to provide a very high level model abstraction like the entity and field system to address discovery with flexible means like we do with the plugin system and to address the staging of configuration. So this is intrinsically complex and this makes it all the more difficult for new contributors to come in because if the issues were on the well-known parts like the symphony bits or the twig, it would be easier because it's a known unknown when you start working on the thing but these new subsystems are essentially unknown unknowns. They're completely new. So where do you go when something is too complex? Well, typically you go to documentation and here we have another problem again on you. If you look at the symphony documentation, the API pages are not very good to say the least. There's almost no PHP doc in symphony but they have world-class narratives introducing each concept. They have a guide and they have tutorials for every major subsystem in symphony. When you compare this with Drupal, we have tons of documentation and the doc team has been doing a great work organizing the documentation. However, the documentation is poorly structured still and many times it's completely inconsistent. If you look, for instance, at some doc pages like the way you need to create an entity type on Drupal 8, there's not a single thing on the page which is correct at this time. It describes the procedure as it was two years ago and everything has been changed since. To take another example, Kalpana mentioned the module handler to me. This is something which is very central in Drupal 8 programming and yet the documentation about it was very hard to find for her and many people don't understand what the purpose of this handler is and we could go on and list other problems but the point is not here. The point is that we have not started documenting with an overarching view of the subsystems which would maybe possibly be guided by the subsystem maintainers but the documentation has been growing organically and that doesn't provide a good structure to the documentation so we are weak on the narrative. Okay, but then what about the API docs? We are much better than most other projects when it comes to API docs because our docs are mostly complete because patches don't get committed without a good PHP doc. But there we have another problem. These docs are correct. They correctly describe what is available without the parameters and sometimes even what the function is supposed to do but they do so in mystifying terms because it's basically you are trying to understand what foo is and it explains it in terms of bar and baz which you don't know either and you run circles around the documentation before you start to form a mental model of what's going on. This is not easy. We would probably need a better organized documentation starting with a narrative and for the tutorial part. So how can it improve maybe by contributing continuously? Katana? So I would like to talk about what is continuous contribution. So continuous contribution in my opinion is that you work on Drupal every day or every week, little bit. So basically in other terms I can say that you don't have a life because you work on Drupal 100% of your time because we would like to and we love to and that's what we do. But what are the benefits of continuous contribution? Why do we want to have continuous contributor in the community? There are like so many benefits. When I started or anybody, anyone I talked to called contributor they said we didn't know much like what was going on into the core. When we started contributing we have like a deeper and broader knowledge what's going into the core. What are the most of the activities taking place in core? So once you have some experience once you start contributing you get to be the part of decision making. You can provide insights and share your ideas. You get to work on different subsystems and issues to gain broader knowledge. This is well and good but some people just cannot afford to contribute continuously and they will contribute sporadically and that's basically what I'm doing these years although I used to be a continuous contributor 10 years ago. But what does it mean? That means coming to code sprints going to conferences like this one and staying the whole week to go to the extended sprints and they're working on deep issues on the critical and the major topics addressing the things which have been blocked and which have been preventing group 8 from advancing. And in these setups you meet a few people targeted on a topic to unblock something and ideas go very fast from one person to the other because you're in the same room, you're exchanging, you're drawing on whiteboards and things like that and you gain the feeling of diving into a subject and unblocking things. This is good. However, there are problems with this. Because these sprints are typically one week long at most and because they are spread over the year and the issues you are addressing here are difficult. You don't typically get to close these issues. You can get to closure. You work on something, you unblock it and then time has to pass by so that others can continue on what you unblocked and bring it to fruition and finally commit it. This is frustrating because you spend the time, you dig into something very hard. You try to do a lot of attempts, measurements and in the end someone else closes the issue that you have been working on. There's an upside to it, however. Working only like this one week sometimes avoids burnout, which is a problem with continuous contributors because essentially these code sprints are your holidays. That's maybe not everyone's idea of a holiday but for me it is and that means that contributing becomes a high point in your daily life because that's, oh yes. At last I'm leaving the business work, I'm leaving the legal work and I can spend one week coding and carrying just about tech because that's just what I love. That's the positive side. There's something else to, if continuous contributors are aware of everything that's going on and the drop is always moving as we say, when you are contributing sporadically you don't get that much insight. You tend to always discover things after the fact. Oh yes, someone has been doing this. Oh this has been abandoned and it's been left on the side and I didn't know it. This is frustrating again. So I want to talk about myself a little bit. I started working in Drupal 2010 and I started contributing to code just before Drupal portland which is almost like two years before. Using an example which I worked on during Drupal Dev Days, it took like 98 comments to RTBC that issue and 114 comments to commit that issue. And one of my friend provided data from Drupal.org and he said, he came to me yesterday or the day before yesterday and he said, the average time for you to get reviews on your issues is seven days. Woohoo, that's awesome because it's faster than the average code reviews. So win-win situation. And now contrast with this sporadic contributor like me here, I started Drupal in 2005 and things were so much easier at the time. I remember my first call patch was submitted in 2005, a few months after I started on Drupal and the first comment on it was chicks setting the patch to RTBC and the second comment was Dries committing it the next day. These things don't happen any longer. It's sad but it cannot happen this day. So it was very motivational at the time to get such immediate feedback and from people in a position to decide what was going on in the project. It gives a feeling of empowerment, of changing things, of changing the world. And this is a spirit we had, for instance, in 2009 when at DrupalCon Paris, we did these D-shirts. We were changing the world, hooking, hook world alter. Let's work to change the world and you have that feeling of being able to change things for the future and for the better, of course. And now, times have passed, Drupal is more complex. We have in some ways changed the world by moving larger organizations to open source and to agile practices and things like that. But look, the response time for much by patches for my reviews is 32 days instead of one week like for Kalpana. And if you consider the duration of a sprint which is around seven days, you can see there's no way this can get committed during the time I'm working on an issue in depth. How does this affect the contribution? So we talked about some pain points, we talked about the high barriers, we talked about what is continuous contribution, sporadic contribution, we talked about us a little bit. And at this point, I would like to talk about things. Like, how does this affect contribution? Like, we are talking about several different things, but how does it relate with each other? How to break the trend? So we get more than 20% new contributors with more than five commits. So as you can see, I have some data here. In 2012 and 2013, we kept the trend and we had 18 new contributors per month with more than five commits mentioned. So 2013, it was steady, but 2014 and 2015, we started losing momentum. Not to mention, like, as per today, we have 2,862 contributors in Triple 8 core. So please give a round of applause for them. We do need those contributors, but we do want to have more contributors with more than five commit mentions. And there are benefits because FGM is going to talk in that next slide, but I just want to mention it that we have so many new contributors with one, two, three, four, five, six, seven, eight, nine, 10 commits, but the number goes slowly, slowly, just limited to more than 50 commit mentions or 100 mentions or 150 FGM is going to talk. Yes, look at the consequence of having done so much work. We have done great work bringing in new contributors to do the first commit. This is the very long tail you see on the green curve. XJM, who is, I think I saw her over there. Thanks to XJM, drew this plot some months ago of commit mentions and the number of contributors. You see it's very flat, there's a very long tail and a small number on the far left who are doing most of the actual commit mentions. This is good because we have lots of people involved and who get a feeling of belonging to Drupal because they have contributed in some way, which is recorded in the system, but this is not so good because that involvement doesn't get them very far. What we would like to get is more people involved with more contributions, something like the red curve. We want to smoothen this and instead of having it stay glued to the axis. Because there's what you could call a bus factor. For some subsystems in Drupal, though you have only one or two people just completely understanding it. Think of the entity API, for instance. If this one get burnt out or get run over by a bus, you have a problem. That's the bus factor. But on the other hand, if you have many people who have contributed many patches on a subsystem, the organization and the project itself are much more resilient. And also these people will feel more empowered instead of just belonging to the project. This gives us a more better perspective for the future. So why do we need more contributors to work on this one? You can say there's this program, the Drupal 8 Accelerate program, that has been set up by the association and supported by various partners, giving money to help finish Drupal 8. This is all well and good. It will help Drupal 8 be released earlier, maybe even at Barcelona, who knows, maybe. But this only helps us reach a goal which is very limited in time, which is scoped to finish Drupal 8.0. It does nothing to help us build momentum for the future releases to bring up new contributors who will make Drupal with it, will have to be in future releases in Drupal 8.1, 8.2. The semi-major releases we will be putting out every six months, starting with Drupal 8.0. Continuous contribution has its merits, as we saw, but it needs motivation because it takes a huge tax on your life, as Capana mentioned. You don't get a life if you spend your nights working on a car instead of carrying for your household and taking some leisure. When you work on closed source projects, basically the motivation is salary. You get paid to work in free and libre open source software. It can be to some degree. Most of us here are probably paid to work on Drupal, but we are not paid most of the time to work on Drupal Core, except in cases like the Drupal 8.0 program. So most of the time that motivation has to be something else than money. What can it be? And here, we are a bit short on ideas and that's why it's a core conversation. We'll be opening the mic soon. Do you think, for instance, that community should start doing one-to-one mentoring to help the contributors work on these major issues instead of staying stuck by the pain points Capana mentioned? And what would the motivation be for mentors? Because if they are mentoring, they are not themselves working on the issues. It's maybe not so motivating. Can we find a way to incentivize the two-person programming method per programming, like the XP method? Maybe we could do things like screen sharing from mentor and mentee. Can we broaden the scope of the core office hours? At this point, we have to discuss and here you are at ease about this. Are we ready for conversation questions? Yeah, please start with your name and Drupal.org username and Alina is taking notes. Hi, this is Lucas Heading. My Drupal.org username is H-E-D-D-N Heading. I do IRC mentoring on Wednesdays, come out Wednesdays. If you're what, Pacific Time? It would be like noon to two. That aside, so two comments. First, how do we incentivize and then the second one is, I'll get to it. So how do we incentivize? I'm biased here. I think we need to get. How do we incentivize contribution? How do we incentivize contribution? I think we need to get Drupal 8 out so that I can start billing clients for making it better. Until that happens, I can't pass that cost along to anyone. I think we're a lot closer than, I'm not going to say that criticals are not criticals because I've looked at all 28 of those recently, like Monday, they're all criticals. But I also think that we were a lot ready or perhaps than we think. Second, so how do we, how do we, how do we, so I think another thing is we need to recognize that contributions don't have to be a patch on an issue. So what are my contributions to Drupal Core right now? I work full time. So what I do, I spend two hours a week and I do IRC mentoring. My contributions is findings people and helping them become someone who's, maybe doesn't have a life and maybe that's okay for them. And then they become, you know, someone who does a lot to the community or maybe they're just an infrequent committer and that's okay for me. So I think we need to recognize what can each one of us in the room do to make the project move forward. There's a great deal of manual testing that needs to be done. Project managers can do this. I could probably brainstorm a lot of activities and tasks but I think all of us could maybe do some of our own introspecting and think how can I help myself? Even if I don't know the whole entity API which is so complex, what can I do to help? There's a major core sprint, a major sprint this week. Maybe we can just do some triaging and read one ticket that has 100 comments on it and figure out what's actually being said in this thing and make it easier for the next person who maybe has the time, maybe is a frequent committer to figure out what needs to be done to fix this thing. Next. What just Lucas said makes sense but we just don't need the patches in the core but we need reviewers, we need testers, documentation. We need all the help we could get to help Drupal aid out of the door. And we do as a community need to recognize what mentors do every week. They have core office hour on IRC two hour and they do a lot to help new contributors get up to speed, understand, make them understand the workflow, how core works. I don't have the solution for your first question but anybody has any ideas or thoughts please do come to the mic and share. And also I would like to know if you have any pain points or if you have experienced any high barriers for the core contribution, please come to the mic. Hello, Chris Weber. Also known as Cosmic Dreams on triple.org. Also known as the guy with the weird Google Glassman's face. I, on your point, Capana, of where are the pain points? You know, I've been following the issue queue pretty religiously for a number of years. Been trying to find ways to fit in. Trying to find ways to help and I haven't really been able to find too many. Kathy, you do a great job of mentoring me and mentoring others to get people ramped up and I feel I'll call mentoring day. I can be enthusiastic. I can help people when it comes time for me to actually get down into the code and work on issues myself. I always feel lost. I always feel like I spend most of my time trying to understand the issue and then after that, all the time is spent and I have to get back to my day job. So for me, what would save me a lot of time is just having the explanations of where I can help, what is the issue about, which is typically done to a good degree on issues but sometimes when we're moving fast that's just too much for barrier. I almost think that text is not enough. I almost think that the project descriptions is not enough and if perhaps after Drupal 8 launches I know there's probably gonna be an effort to make the big definitive book again but I almost think that's not enough. I almost think that in order to really understand these systems, well, we need videos. We need audio. We need people walking through other people through the problems and I'm trying to find ways to either create that or find that. Thank you and congratulations for taking time to mentor others anyway. I'm Adele Frank on Twitter and Drupal.org and I refuse to get on IRC. I just wanna put that out there because I can't be alone in this. I- I'm gonna do it by the way. Huh? I'm gonna do it by the way. Community, it's complicated and confusing and more importantly, people communicate with me in like 70 different ways and I don't have time to figure out a new one or keep up with it so it's a little bit challenging because I gather if you get on IRC like all these, maybe not secret but like tons of stuff happens there but I'm not gonna do it and I love y'all. It would be better but this is kind of an easier way to like, I don't know, communicate. This isn't hard to sign up for it doesn't require me to have more information overload and I'm sorry if I'm complaining because I do love Drupal but IRC, there's gotta be a better way. So you think that basically IRC which has been a historical channel for communication and live is a part of the problem really? I do, I really do. Well I must say you're not alone. I've always had trouble when trying to introduce the nine to five hours during Drupal to use IRC. Yes. And one of the surprises I had a few years ago when starting to do enterprise work on Drupal was to discover that there was an incredible number of nine to five hours working on Drupal which we never saw, which we'd never consider contributing because it was not deemed important by them and they were not motivated by it and also because they're doing things like IRC was blocked on enterprise firewalls for instance and it's not easy, there's no history. It has been an ongoing discussion to use things like Slack or other alternatives but they have other problems really. Well recently I was at PHP Word and I was mentoring few people who has never contributed to Drupal before and I asked them to get on IRC and they mocked and laughed at me and say, do you still use IRC? Are you telling me in 2014 that was last year to go back to 99 but I said that's how we do Drupal. We cannot live without IRC, IRC is our life. But I love IRC by the way, sorry. I'm glad somebody asked. Mike, yes. So it gets recorded. I'm with her, I'm one of the nine to fivers and I went ahead and reinstalled IRC and I hadn't used it probably since the 90s when I probably used it for the secret thing she's talking about that we're not supposed to do. And so Drupal would be the only thing I would use it for and so I tried to get on to the mentoring thing and by the time I had figured out getting into the chat room, met with somebody, tried to go through whatever to get into an issue, I had expended the time that I had told my boss, oh I really should be contributing back to the Drupal community. Let me spend four hours a week doing it and by the time I spent that four hours I didn't accomplish anything and part of it is is this very confusing way to get into talking to these mentors and trying to start up and that's IRC because I don't use it anymore and it's not really used anymore widely that I can tell but maybe I'm alone. And same thing, like learning the Drupal.org way of patching and committing is like not GitHub, not the GitHub is perfect but I'm not gonna use it ever anywhere else whereas if it were GitHub or something more like, that's just an example, like it's really hard to find the time and make the time to learn something that is so specific that I cannot use elsewhere. I want to ask you a question. Do you contribute to any other open source software and do you use any other tools which we could use or adopt in Drupal? I mean I do use Slack although I'm working on, it's proprietary, sorry I didn't know. So maybe I'm not a good example then. No, I don't. Yeah, so I was actually, with regard to the IRC thing I was gonna ask the same question that Kalpana just did which is to my knowledge a lot of others. Could you please introduce yourself maybe note that everyone knows you. My name is Jess, I'm XJ, I'm on Drupal.org. I kinda started the core mentoring program and now I'm a Drupalic Committer. So I do think that a lot of other open source projects still do use, have free node channels that are very active to my knowledge. So it might not be in the normal domain of people's day to day work but I think in terms of, there is a precedent and it's not just the Drupal community. I think that there's, but that doesn't mean that there's not a better communication medium. One thing that I wanted to suggest is a point that I think that Kathy might also have considered raising which is that one of the most important things that we can do to make sure that, because I recognize that IRC is a barrier for some people. It was for me until 2009, from 2005 to 2009. I wasn't an IRC and I wasn't engaged in the community for that reason. We need to make sure that all communications that happen in IRC end up summarized in the relevant issues on Drupal.org because if we, having two bad channels that are not clearly documented is definitely worse than having one. So we need to make sure that there's at least canonical information in the issue queue. I will say that with regard to core mentoring, when we first started it, there was a concern raised that IRC is a barrier to people, that some not even can get on. The noise stream is just, there's accessibility limitations with it and so forth. And we, it was suggested that we use Twitter to initialize mentoring contacts. And I made my Twitter account for that reason. That's the entire reason I have a Twitter account. I use it for other things now, but it never really panned out. So if anyone has, I know that people have suggested Google Hangouts. I think there's a cap on the number of participants and Hangouts. So for everything that we've sort of proposed, there's been some limitation to it, but I'd love to hear more ideas about it. But the main thing that I wanted to ask about is, or to the point about how we motivate people to be involved who aren't paid to work on core. I'm full disclosure, I'm paid to work on core full time. I have been for two years. Before that I was paid in, at a contract rate to work on views and core and before that I was a volunteer contributor in way too many evenings and weekends. But there are, other than financial motivation, there's been all kinds of research that's been done on what motivates volunteers to participate, what the benefits that volunteers, not just in open source projects, not just in, but in every area of life, what is the value that they derive from volunteering? And so I put a couple of links in the notes document to a couple of research articles that I've referenced a couple times before. I'm gonna put this back in the stand because what the hell am I holding it? I can hold my laptop. And the notes she's talking about, the link is right there. The contribution dash notes. Yes. The second link, bit.ly.bit.ly.ly slash contribution hyphen notes. Thank you. So we can't see the slide. So there's these articles list a number of, so that some motivations that they suggest are things like some volunteers are motivated by achievement. Some motivations are motivated by power having authority and control over things. Some are motivated by affiliation or by the social aspect of it where they become the member of a group and they derive, they have social interactions that are a part of it. Some are motivated by the recognition they get for the volunteer contributions they make. And some are motivated by pure altruism, just this notion that I'm doing a good thing, I'm making the world a better place. And each one of those motivations I think we can appeal to in a different way. So for example, for volunteers for whom being recognized for their work is that brings them joy in and of itself, making sure that we do recognize all forms of contribution is hugely helpful. And so I think that it would be useful for us as a community, and I keep saying this and not doing it, but it'll be useful to go through the different things that motivate volunteers and then think, well, what's one thing that we can do that will appeal to people for whom that's an important thing? So the links are there in the article if you want to look at them. And I'm gonna stop talking now because I keep taking up too much right now. Thank you for all these insights. There's one thing which we didn't mention that which can be helpful for many, at least we found it in the French association of which I'm a founder and member, it's to organize regular meetups offline. Sometimes, although we are developers, getting offline can really help and to create a feeling of belonging in a community and helping people be motivated to try and get to become contributors. We have a lot of national channels in most countries or by per-language channels, also on IRC, but these do not complement the fact of meeting in real life, talking to someone over a glass of something. That's good too. Cathy? Oh. I'm just evaluating if I should prioritize. So in the beginning... Your name and... Oh, I'm sorry. I'm Cathy. I'm Yestiti. Jess mentored me and I help organize mentoring now. So in the beginning, we were talking about one of the barriers is the complexity of the code and how many things are different in Triple 8, like the whole entire entity, API, that we have this new thing, these plugins. That it is a barrier to learn the new ways but the advantage in Triple 8 is once you learn the new ways, the pattern is repeated everywhere in core. So if you learn how to do something in one small slice of core and then you want to work on another part, you'll see the same patterns. So there is some barrier, but also some payoff. We mentioned this earlier, Alina and my core conversation the other day. Alina, was it four, three, nine? So it's node four, three, nine on the event website and things like having to learn the patch workflow and we want to have Git. Having a hard time using IRC for a communication channel and wanting other ways of talking to other people. Thanks, but so I think we need to solve those things and they are actionable and definitely, a lot of those things can get a lot better. As an alternative to IRC that we can use right now, we have core updates that are posted on groups.drupal.org. So instead of having to check in on IRC and see what people happen to be talking about recently and you want to know, hey, what's new in the last little ways, you can see a summary on the core updates and you can subscribe to them and get them in your email. When people do the right thing, which is communicate in IRC and then post back on the issue, what you can do is you can subscribe to issue notifications in your email. So if you're following issues, you can go into your profile and say, please send me email notifications of new comments that are posted on issues that I follow and if you're a new contributor, that's reasonable to do because the amount of issues is small. And then you can have a conversation with people via the issue queue. And there are many contributors to Drupal 8, top contributors to Drupal 8 that do not use the issue, that do not use IRC is their main form of communication and if you want to talk to them, you better post on an issue. So there are people that have gotten around the IRC thing and you would not be alone to just refuse to use it. Another option that we could think about is instead of having to install it and use it locally, get it all configured and figure out how to join the channels as we could have a web interface right on Drupal.org and you just use it there. Yes, but it's not integrated in Drupal.org. It's even worse than the normal. Yes, it's not integrated. Anyway, we could do a little, that's something we can look at. Our text-based information for disseminating how Drupal.org, Drupal Core works, has some problems in terms of the narratives, we're lacking in narratives and the suggestion was made that perhaps we should look at using other forms of communication like videos and audio and we have some of those but they are not free all the time. So we have in the Drupal community ecosystem, four or five, at least, several large companies that make their living by making video tutorials and we also have a lot of podcasts around and those video tutorials give you a high return on your investment but they are not free and it is not financially viable for the Drupal Association to produce those things. Maintaining videos on software that is not released yet is incredibly expensive and intense but it's really cool to watch so if you want to get the benefit from that you need to also invest in it by subscribing to those services. We'll get back in line. And I also think that as we get closer to Drupal 8 release because things are changing and moving so fast we might see some block post or some free videos, someone will post. So hey, I'm Dave Metzler, MetzlerD on Drupal.org. First of all, I'd like to say that it's really easy to stand back and express frustration about the challenges that are going on but also that there's a lot of great work that's being done and we ought to acknowledge that while we're complaining. In particular, I've heard a lot of people like I sat in Pacific Northwest Drupal Summit and heard Angie and a guy whose name I cannot remember talk intensely for a long time about trying to figure out how to change the patch workflow and stuff like that. So know that there's a lot of bright people out there who are working on those problems. They're just insanely technically hard to accomplish when we talk about the packaging systems that we have and things like that and they're going to take a really long time to change from that perspective and I just kind of would like people to honor that a little bit because these guys are working really hard on that problem. The other thing that I'd say is that from my perspective, one of the ways that you can help get your respective employers to understand the value of contributing to Drupal is to focus in particular on the custom modules that you develop or maintain. So how many people have written a Drupal 7 module at all, right? Okay, so that's pretty much everybody, right? So the best way to get your, understand how to port your modules right is just from my perspective anyway, is to start by understanding the API documentation, make sure that it's right and accurate and then start connecting with people about fixing the things that are important to you and this, my boss at least gets very much is a core part of making sure that the code technical debt that we have gets ported in the same way and that you future protect your code for what's coming in Drupal 8 and Drupal 9 and stuff like that and so that's a huge incentive that people often don't get and talk about. What I would say then is in terms of the biggest change that we could make as being one of those five or so committed kind of peoples is that understanding how, focusing on how we can develop communities that understand sections of modules that aren't core committers because these guys are taxed beyond all possible understanding, right? So that means that the relationships that you form at code sprints need to continue beyond the code sprints and so it's not so much about you maintaining a relationship with a core committer that you figure out but maintaining relationships with people who are sitting next to each other viewing each other's patches like you guys were talking about and having those communications channels open. Now if you do that and you do that, you can choose Skype or whatever the heck you want for communication conversations on that and you can keep those relationships going and develop clusters of people who are interested in common things that then are group core committers focused on a project. Now the biggest thing that I feel like anybody can do to help us do that is to make sure we understand like where there is need not in terms of we need reviewers, we need blah, blah, blah because that's all great but what I really need to understand is which section of the product do I need to bone up on in order to be productive around those particular issues and that's the piece that's really hard for me to find out in terms of managing the issue queue is like okay, do I need to focus on services or should I work on the forms API and where's gonna be the most bang for the buck in terms of low hanging fruit that needs to be tackled so that we don't have to ramp up on every single system one at a time because we're working this issue than that issue than the other issue. Thank you. Okay, just to be sure I understand you well because I think this is something important. We tend to focus on, well not to focus exactly but to worry about getting more contributors overall and in fact you are saying that we should focus on getting clusters of people to focus on one topic instead of trying to get more committers for Drupal or more contributors for Drupal, we should focus on getting more contributors for one specific topic which will be a group and that group being smaller will be more closely neat maybe and communicate more, is that correct? That is correct, yes. Oh, that's a nice idea. Thank you. Hi, I'm John Shortus. My Drupal.org username is just my first name and last name and like so many other people whose primary work with Drupal is during their day job and our time window to work on Core is very limited. I share a lot of the same pain points that I've heard today but first I wanna talk about two things that have made things easier. First is the Core updates this week in Drupal Core that's been great for me to keep up with what's going on. So thank you to the people who are doing this. The other thing that I have really liked to see is the employer sponsorship mentions in commit mentions that I think is going to go a long way in our organization for making it easier for me to work on Drupal Core and even on Contrib. But some ideas that I've got and I don't know how these are gonna work just where we are in the release cycle. Like so many other people, I've got a limited amount of time to work on Core and by the time I read through the comments on an issue my time is up. So I think come a long way with Core mentoring but that seems to be aimed for people who are brand new to Core. It may be kind of a mentoring level too where for people who know how the issue queue works, we know how the patch system works but we don't have time to keep up with all of the critical issues and what all of the implications are and is there grunt work that can be passed down? It's like, okay, take this design pattern and make it look like this design pattern and there is probably an army of people who are those occasional contributors who don't have a lot of time but if you give us grunt work, we'll happily do it. I think it's just easier to answer to that. So thank you to both of the last people, I missed your names for also highlighting the things that are working. I think that we do need to celebrate our successes more. It's kind of exhausting as one of a handful of people who do work under a blade full-time. I feel like I've spent the past four years of my life trying to help solve this problem and it's all the same problems continue despite the solution. So it's good to know what things are actually working that we're doing, like the core updates for example. I would say that I definitely agree that the next problem is figuring out how to help people dive in more and I think that's focusing on a specific technical area is one good strategy for that. I'm not sure if everyone's seen, you may not have seen but recently, Drew's proposed a new core governance structure that sort of solidifies the role of the subsystem maintainer in Drupal Core. So the idea that we are empowering and this has always been informally the case but we're empowering individual people to be responsible for a specific technical subsystem in core to sign off in decisions in it and maintain the issue cues for that component. That's one way to zero in your focus and the way that you become recognized in that role is by just starting to do it and a way that you could start to do it if you're here and you're looking for a way to get involved. The 26 critical issues that remain are hard, technically complicated. I don't even understand half of them but Kalpana and Chris are going to also be leading a sprint to triage major issues on Friday. The idea isn't that you will go in and patch and fix these issues. The idea is that you will look at them and look at the set of the issues in one particular component and then team with maybe one or two other people and try to decide whether they're still relevant. They just take the time to understand what the issue is and if they're relevant, make the updates necessary on the issue to communicate that to the next person so that the next person doesn't have to read 50 comments. They can just read an issue summary. They know whether or not it's a relevant issue to work on. So I'd encourage you to come to the Friday Sprints and look for the table that will have Kalpana and probably me somewhere near it. That's one way to get involved. It's something that we're trying for the first time, I think, at this event as an organized thing. I don't know if it'll work or not but I would love your help and experiment to see because if it is a good solution or even if it isn't, maybe we'll learn something from it. Thank you. I think we're running out of time. We do have five minutes. Five minutes. Oh boy. I'll try and be brief then. My name is Eddie. My username on Drupal.org is EddieN120. Very brief. And just to know that I'm winging because I love. Drupal is very useful to me. It's helped me in my professional career so anytime I try and use it, if I have any complaints, it's because this thing is supposed to be so fantastic. I want to keep it that way. Briefly, someone talked about how IRC is a historical thing and therefore we should keep on using it. There are plenty of things that are historical that we don't use anymore. We could and should try and look for alternatives because that is a very major pain point for people. A lot of people think the IRC sucks and they're not interested in getting into it and they don't want to use any client for it. So an alternative that works for me personally is Twitter with StoryFi or Twitter with Twitterfall or something like that so you can keep all the tweets in one place with an appropriate hashtag that works. Motivation for mentors. I think one of the greatest motivation for mentors is the whole concept of teaching a man to fish. If you keep on saying we need people to help do this thing and we can't find people to do it, go out and look for someone and teach them. And as you teach that person, you're teaching yourself. So you help yourself and you help the community as a whole. My own personal motivation is I try not to work for companies that don't allow me to contribute back to Drupal. If they are not willing to help me help the community of which I'm a part, I don't really want to work with them. No amount of, well, I want to no amount of money because money is great. But if we all try and insist, I know it is very difficult. We all have full-time jobs. So to find that time within the working day to give back to Drupal somehow, I think it's so important, very vital. So the more employers that get that in their head that yes, this might be a free open source thing but it has a cost. And part of that cost is giving back to the community. If we don't do that, we're in trouble. And another one of my personal motivations is I'm trying to make sure that Drupal and I apologize if you're a Wikipedia and I apologize if you're a Stack Overflow but one of my strong motivations to make sure that Drupal.org is not like Stack Overflow and it's not like Wikipedia because Wikipedia is like that little girl with the curl on her forehead. When she's good, she's really, really good but when she's bad, she's horrid. When you encounter one of these self-entitled Wikipedia's who have their little fiefdom and work against newbies, that is so bad. And I'm my level best trying to make sure that Drupal never gets to that stage. We have to be and continue to be inclusive and inviting to all. We have to reduce the barriers to entry as much as we possibly can. And speaking of inclusion and diversity, we have to walk that walk and talk that talk. And that's part of helping newbies into the fold. We have to reduce those pain points. You have to reduce those barriers. FB, Facebook has their slogan, they say move fast and break stuff but the newbie fear of breaking stuff or retrievably is so great that anything that we can do as a community is to reduce that because the more people that have eyes on these issues, the quicker they'll be solved and the quicker they'll be pushed out and help all of us as a whole. Thank you. Thank you for such comments. Thank you for your feedback. All right, so I think we have a minute and a half left. Yes. Okay, so we're talking about that it takes a lot of time to understand an issue if you only have four hours. By the time you understand it, you can't do anything. You're having trouble convincing your businesses to give you time to contribute, especially on a regular basis, more than four hours every so often. I have a blog on the Black Mesh blog about how to get strategic business contributions and how to business-constructure it. So it's really in depth. It has a lot of links and I recommend you read it because I wrote it and it's awesome. One of the main points is that we used to think many years ago that any employee who wanted to contribute should have some small amount of time regularly to do it. And since then, I don't think that anymore. I think you add up the amount of time over your employees that you can afford to contribute and concentrate them in a fewer number for a limited amount of time. So for two months, you make it 15 hours a week and you only give that to one person at your company. And after those two months, they get a break and you give that same amount of time to somebody else. Because four hours sporadically, you can't get anything done. When you're looking to get involved in a particular topic, we have initiatives and topical areas that we organize with tags. But I highly recommend it. If it hadn't been for getting involved in multilingual, I wouldn't have been able to just help with core. It's just too broad. In terms of, we're really good at getting people involved to teach them their first contribution, but we need an intermediate thing. We have core critical office hours a couple of times on Friday. And the criteria for participating in them is that you have participated in core before. So you know the patch workflow, you know that things need review, just the regular things we don't want to keep telling people. So you may think you can't help with criticals, but if you have ever helped with core, then that's where you should go. You should go to the critical office hours. If we want to broaden the scope of mentoring, aside from just teaching people, like convincing them to get in IRC or teaching them how to make a patch, and we want to actually do mentoring, then we need to solve these simple problems on triple.org itself, and then we can release these mentors to actually be doing mentoring. Okay, thank you for the comprehensive. Yeah, thank you all for coming. Please leave your feedback, please, please, please. It's vid.ly slash node 999. Also, if you would like to stay in this room, David Hernandez here. He is giving next session, How Do We Encourage Repeat Contributions to Drupal Core? I'm going to stay here. And if you want to talk to me, we will be here. You can find us here or on Twitter. Thank you. Thank you. Thank you. Thank you. I'm very new to Drupal. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.