 I need a mic check. Can you guys hear who's saying okay? Yeah, it's okay. Thank you Okay Hey, welcome our talk is how do we encourage repeat contributions to Drupal core? So for some of you who are around in the previous session that Kalpana over there just did it's a similar topic But we've a slightly different focus. So they were talking more about People who already contribute and how to get them to sustain their contributions What we want to talk about are the people that Have started to contribute but might have only done one or two things How do we remove some of their barriers and help them to do more and get past sort of the one to commit credit area? Into the 510 and above I'm David Hernandez. I work for Rutgers University. David Hernandez all one word is my username I've been involved in the Drupal community for about seven years now doing a lot of different things With a lot of different projects. I help organize a local user groups in New Jersey I've organized sprints and triple camps and come to a lot of different conferences I've been involved in the mentoring program done some coding been involved with Drupal 8 so I've Met a lot of people who are in this area that have that one to commit or just beginners And I've seen a lot of their frustrations. I've experienced those frustrations so Quite familiar with a lot that's going on and some of the things I think that we can do to solve those problems So today is a core conversation So we have a presentation we're going to go through that will not take the full hour And what we're going to do is hopefully get a lot of questions from all of you and a lot of good ideas from all of you We're going to be pretty casual So we'll go back and forth But feel free if you think you have something really important to say in the middle of what we're doing I don't mind at all if you interrupt us and give us some good feedback Hello, I'm Hussain and I on d.co I usually go with the Hussain web and actually pretty much everywhere on the internet Twitter wherever you can find me and I have been involved in Drupal community since about two years and in that apart from Co-contributions mainly to Drupal 8 I have been also working with my local community back in Bangalore and Nearby communities Mumbai, Delhi various communities in India and Well, it's really exciting to be here. It's my first Drupal Khan and really excited to speak here. So let's get started so So why is it important to have repeat contributions One of the biggest reasons is obviously we need sustainability in core and in the community We have a very large user base as far as the people who have actually gotten commit credits and worked on Drupal 8 Almost 3,000 people now in fact have gotten a commit credit. So we're one of if not the largest print source communities But we actually have a very small number of people who are doing the majority of the work Probably less than a hundred people that are doing probably 75 to 80 percent of the actual work And that's not sustainable. This is what leads to burnout It leads to frustration There's a lack of diversity in that group in a lot of different ways We're not just talking about national diversity or racial or anything else, but even just diversity in like job functions So if we have a larger group, we get more ideas from different people who have different backgrounds And we can allow those people to rest when needed and have other people take up the mantle and continue progressing Drupal That of course leads to community growth because when you have more people involved you have a stronger user base And you have people that will Continue working with Drupal core and Drupal projects learning about Drupal and they are far more likely to stick around we're worried about Some of the percentages of people who might Work on one issue or one problem and then if they have a bad experience They're far more likely to come back and it's very possible that they don't even stick around the community because they're just getting involved with the project I think maybe Drupal is not right for me. I'll work with something else find where my place is and they work with a different project And that affects adoption as well if you have good developers who stay in the community They will use Drupal and they will prefer to use Drupal and all their projects. They will push their organizations to use Drupal and Working on core and different projects and contributing is a great way for you to actually learn so it affects your developers education I can say that I know a decent amount about Drupal 8 right now But it's not because I use it on any projects very few of us have ever used it but when it gets released, I'll know a fair amount about how it works and That's really great for my job. It's great for me personally But I don't know any of that without actually working in contributing so Having understood this having understood why we need repeat contributions So let's understand a bit more about what really motivates people to contribute and It's a bit of both Here we let's let's see, you know what motivates a person to contribute for the first time and Keep his contributions going This is the focus of our talk, right? So in my experience I have found people primarily start contributing to learn and and by that learning become a part of this community and Well back in Bangalore, it's it's really exciting not just in Bangalore, but in overall, you know all the camps have been to in India It's it's a really exciting thing. There are a lot of people who come up and ask Ask mainly about droop-a-late. That's the focus of the moment, right? And how do you learn it's such a major shift and the easiest answer for this is to start working in the issue queues right and Of course the the word here is start most of those people have not started yet and They do start and that is the reason we see about three thousand or contributors right now on the project and Sustaining it is of course the problem here so to sustain Education still plays a role in sustaining these contributions. You don't You don't have people just coming one page and oh, yeah, I've learned to play it now. It's it's fine. It doesn't happen that way, right? So they keep they keep at it and those who do They satisfy their They decide, you know that they have learned the system and they are ahead of everyone else. So that's one thing There is of course respect and of course we handle that with the commit mentions and so there is this layer of commit mentions and many people are attracted to that and that's not a bad thing of course and With that it makes it easier for a person to say, okay I'm contributing I've made just one patch, but okay I'm there in the vlog and if I make the next one You'll see the long tail of the graph right now and you'll jump you'll suddenly jump, you know Way to the left of the graph right and make a couple of more patches and you're actually approaching the curve So this is again very important for some people and this keeps them going, you know, you know because it's the benefits are so So drastic in the initial first steps, you know Writing another patch getting it submitted getting it committed is not that hard but your name jumps like from maybe 2000 something 2000 something and commit five more patches and your name is right within hundreds, I guess right, so this is again another motivation to most people and My experience karma and altruism is not that powerful of a motivator it is still important and many people still feel that You know when we contribute for the sake of the project for the sake of the community For the sake of contribution itself But it's not as powerful motivator as these commit mentions and education has been and Yeah, so what are some of the current problems that we see that interfere with people contributing? One of the biggest ones we hear from developers is obviously the complexity of our systems and the workflow that you have to go through in order to Contribute a patch and the entire patch system itself, right? So you've set up development environments You might have to make sure you have get installed and that you know how to use it And then you're doing you make simple little code edits and then you have to generate a patch And you might generate an inner diff and know how to apply patches from other people and then upload them And make sure they go to the test bot and all that other sort of stuff and that can be pretty Overbearing and intimidating for a lot of new people and especially for non developers which people forget about a lot If you want to help with documentation or do some of the front-end work and then you tell someone sure great We have lots of things where you can do by the way, you have to do all this exact same stuff The developers have to do that's why they just walk out the door and never come back Finding and organizing issues if you spent a lot of time in the issue queues You know that the the issue queue is a great bug tracker. It is absolutely horrible project management tool It's not a project management tool. We have none We rely on a small set of fields. We can't properly prioritize. We end up using issue tags for every single thing Comments get too long If you've worked on an issue that has two or three pages of comments and you want to try to figure out What's going on? It gets pretty impossible And then if you want to organize all that work for a larger initiative and you start using metas and child issues and before you know It's completely lost So anyone actually wants to get involved with something really significant. It's impossible to keep track of things This plays into lack of confidence we we have a prominent community where We have a system of knowing which means a lot of work It's done by the people who just know what to do and I'm not talking about the code I'm talking about how to navigate everything who just know where those issues are and what that project is and what Groups that you put a org group was used and who are the right people to talk to and what IRC channel and where the Instructions are and which instructions were wrong and which ones were right and which ones worked which ones didn't And it just becomes an intrinsic part of the stuff that you do and for a completely new person That's impossible and they see all of this amazing work being done by people and when they get involved It's not something that they can do so you you assume that you're not going to be capable But it's really just a problem of the way we organize things Then lack of incentive for some people which is a very real thing I don't There are a lot of people that do want to contribute and they want to keep contributing But it's not always realistic to expect people to do all this work on their own time On weekends and at night. Oh, we see that obviously happens a lot and that's that's really what we get from those people That are at the top of that chart That they're doing a significant amount of work on their own We need to find ways to incentivize organizations to allow people to do work on work time because I Honestly gotten to the point where when I talk to people and they say I can't do it during work hours I'm not going to do it and I say that's fine. Like I'm not going to tell you you should be doing that I think that's completely it's it's wrong for us to tell people that that you should work on something on the weekend or take Holidays and come to a sprint or do something, you know, that should be your personal time And we do sometimes have problems with decision-making Which can be pretty demoralizing we have a oftentimes in areas. We have a very loose structure for how things get done and what's decided and It's not clear especially for newer people who has to talk to whom Who's gonna make that decision what solutions are gonna be used what isn't and If you've ever seen or had to experience where you work on an issue and you spent a lot of time on it And then eventually when it finally gets to the right person they go well, no, we're not gonna do this and they shut it down I'm sorry. You spent 20 hours working on that but you know a well It's not as clear For especially new people how to handle that situation the experienced people will know if I'm gonna work on this I'm gonna talk to this person But when you're new when you're trying to do things on your own, that's an impossible expectation Let me see that all the time, right? When I mentored in this various friends people are generally very very afraid to update an issue you know, it's Should I should I add this tag? What do I do about this tag? You know, what is this tag about or you know, what what should I said this said the status? you know, what what about this priority and Comments can be overwhelming. You know the way it has been done so far and Regional differences do play into this a bit for example When you're reading through an issue You know, we generally find people from North America and Europe doing the most of the talking When a person from India or I guess surrounding regions as well comes in and sees the sees the kind of Discussion happening. They immediately feel intimidated. It's First of all the code base is very new most of these people are familiar with Drupal 7 Drupal 6 environments and the overall Style of programming you have now, you know the modern PHP programming the Drupal 8 and everything and on top of this That style of discussion it gets a bit overwhelming and of course, you know, you can't do much about the the coding style That's here to stay of course, and that's a good thing No complaints there The the solution is to find ways around this find Well, of course, you know, we have we have to make sure we have enough mentors at the sprint We have to make sure we the mentors make people comfortable and We are seeing some progress there, especially in India recent sprints So Well with all this problems in mind, let's let's look at some data. We have collected from Drupal dot oig Ryan as I hope I'm pronouncing his name, right? he built this queries for us to go through this data and I'm guessing this pie chart is of course, you know, I'm assuming most of you are familiar with this pie chart it basically says It breaks down the number of commit messages your name mentions in all the commit messages in Drupal 8 So the the whole half of the pie chart you see on the left the blue one. That's people with just one comment so three thousand odd people and Half of that are just people with one commit and the other Well other two-thirds of it around 40% That's people with just two to ten commits the next step And people who have actually Become comfortable with this repeat with contributions and they're repeating them repeating contributions now That's just 13% you've seen yellow. So I just just for the sake of curiosity Which pie chart would you place yourself in blue red or yellow blue anyone in blue here? blue red Red, okay, and yellow Okay, so well, of course the discussion the talk is this but I mean if you fare if I Yellow talk over let's go home Exactly. I solved all the problems Yeah, so do this over the entire attendance at Drupal con and well, of course, you know We'll start seeing this exact pattern play out One thing to notice over here is just the size, you know, this is just a pie chart It shows percentages But the number itself three thousand it's actually more than the attendance at this Drupal con and We'll not go we'll not delve too deep into the mechanics of you know What that what that number means and what it means to the attendance at Drupal con But it's just something to think about we have a lot of contributors And even if we think that Drupal con has a large attendance. It's not nearly as large enough as our prospective contributor base Yeah, so this is the the long tail graph that people have probably seen before Jerry's has had it several times in his Keynotes before We stole this directly from XJM and her blog post If you were here the the talk before this you've seen this exact same chart I know you have because I stole it directly out of cup on his Presentation because I have access to Google But this is you know kind of a representation of the the chart essentially we were looking at before where We see that only a handful of people have the most commit mentions and there's a very very very fast drop off Where it levels out near one and two So what we want to do is work on Bringing that curve up and the previous talk they were talking about sort of that middle area and in our talk today We're talking about the tail right so how do we elevate that tails from having so many people just being one or two commit mentions and Have a more gradual slope so that we can progress people from this first stage to the second stage of how they contribute Okay, so with that in mind we started delving deep into the data and Of course, there are so many dimensions to consider here So one dimension in particular which we considered was That we get the person to start participating in the issue queues and they probably make a comment, right? How much time does it take? for that person to go ahead and submit a patch and We found on average it takes about 112 days This is this is based out of all the 3000 contributors. We have its average on that. Yeah, it's actually it's more than that It's actually all active accounts on dribble org So from the first time you commented ever on An issue to the first time you ever made a patch The average was 112 days. Yeah, and so we were thinking if this actually plays into the you know if this actually factors into the The repeat contribution so the idea is you know if we improve this number if it make it easier for the for a person to Get get started with his first patch. Does it encourage him to contribute repeatedly and our answer was not really From what you see in the chart, it's actually logarithmic charge chart if I normalize it It will look very much like that long tail chart. We have been seen but this actually Distributes the data for us to consider and you can see that most of the patches You know actually the path the patches the red dots you see on the y-axis on you know when the time between first commit and first patch is 0 And these are the patches which are probably done during sprints mentored to sprints and all that They they have a good enough chance to start repeating contributions So we have you know like you see we have one dot nearing 100 Right, but everybody else is kind of evenly distributed from two to nine That's like two two figures like about hundred seconds to few days and Will this chart kind of makes it a little bit more clear I hope But it's the size of the circles are basically the number of comments that the data point represents and Again, it's evenly distributed. There's no conclusion here Which actually the conclusion here is that there is no relevance so this is one one area where we can say that okay, we don't really have to focus here and We want another dimension and it's this David so this was actually we analyzed the time from when someone uploaded a patch to the time when Another active account basically left a comment So it's what we're using to sort of estimate how long it takes to get some kind of review on that patch And what we found is for and this is the data points here are for individuals So what we found is it matches that long tail So if you Are someone that has a lot of patches and you contribute the most your wait time to get a review is Lower than anyone else and all the people who have just one or two patches their wait times are extremely long And it like as we said it matches almost perfectly that long tail So this is probably the key point that we really want to work on I think we all knew that this is one of the problems waiting for reviews and I think they just sort of confirms that Especially for newer contributors. This is an extremely significant problem Yeah, Peter There is a microphone in the middle So I just want to make a comment about cause and effect here because I remember Being early well when I first started contributing I had this experience also that like you post a patch and basically it would never get a response and Having a eureka moment of like going on RSE or getting connected people and being able to directly You know at least have a conversation with people or ask for a review was when things got really quickly so You know, I think it probably reflects the interconnectedness of those contributors as opposed to that people are Looking at their issues specifically even. Oh, definitely. Yeah, I don't think we're trying to draw that conclusion I think it's exactly that it's more of an issue where if you were an experienced contributor You know who to talk to you're probably working on active issues You know exactly what are the right issues to work on you're probably doing it at sprints and different events You can go on IRC and say hey look at my issue or you're working directly with someone Whereas if you're a new contributor and you might be someone completely random That's just doing things on their own You don't know any of these things and that's that problem that problem of knowing that I discussed earlier And you also don't know that you should just go and harass people and get them to look at your issues or whatever I So I'm Kathy So I thought exactly the same thing as Peter when I saw this graph I'm like wow we need to be really careful about cause and effect here But then I really liked the comment that David said Which was this is a problem. Yes, so whether or not it's the cause or an effect It is a problem that our First-time contributors are having to wait this long So it's really nice to actually see this data. Thank you. Yeah, it's demoralizing for people and This is one things that we're worried about a lot of these people are probably the ones that May leave and not come back because we tell them hey come work with us To be a part of the community work on issues and they work on something and they don't hear back from anyone or get any Reviews or weeks or months and they just leave and they don't do it again It's actually pretty astounding the the topmost dot on the y-axis you see that's that works out to months You know the patch was posted and was committed months later So it's it's something it's definitely a problem area and something we need to work on Yeah, there's there are some data points where someone is a new contributor They uploaded a patch and it's been years and no one has ever looked at that issue so What is the likelihood that that person is going to do it again? Hi, I'm John shortest and something that I noticed as a sprint mentor last year is is exactly this the the demoral is a demoralizing effect of I mean not necessarily not having instant gratification, but even sitting there in the room and It being hard for a new contributor to get a review but something that I just thought of we've now got that new user tag and Yeah, just that could be something or other equivalent metadata on the user. Yeah, that's actually something that I That I it was an idea that I got from Ryan Azulet when we were we're going through some of this data Because we have the new user tag and so he was suggesting like hey Maybe we can do something like add a tag when someone uploads their patch and said this was the first patch This person uploaded or you know cool things like that in the issue queue and then people will notice it And they're more likely because we usually are very good about doing those things when we are notified about it Exactly when the community role stuff came out everyone was like hey This is great community role and like they'll go and click the button and help people and they'll see that someone's a new user And they'll be nice to them and all that kind of stuff I think they were more triggers for those kinds of things it would improve things, but we'd have to say But yeah, those are great ideas Yeah, and also for example You mentioned mentoring at sprints right and another problem. I have seen Is to explain to people that okay? You're coming here You're working on an issue updating issue summaries or making a patch But your patch is not going to get committed today You're working on the patch today, but it's going to go into review and that might take days It might take months and it's difficult to explain to the user that no do this today and Read the benefits weeks later and this This is a little tricky to deal with Personally, I would say that Mentor outreach program where mentor knows for example, it's it's all a knowledge problem here And the people don't know way to who to talk to and so if mentors if there is a channel where mentors Can get in get in touch with the car the maintainers of the of the project It actually helps make a difference and I know there is such a channel. It's always they but I Find very few people use it and again It's not just the contributors who are new it's the mentors as well who are new over here And that's another problem. That's entirely another problem that we need to deal with yeah That's a really wise thing like you were saying That you have the mentors at sprints explained to the new contributors What will happen next and then it could be a long time to wait to get in a review and that helps? Mitigate some of their frustration by making sure their expectations are in line with reality. Yes, so that's a good idea I don't know that we've ever done that so maybe we can we can learn from that and do that here this When you are talking about, you know, maybe adding a tag we don't have to add a tag for these Issues so if not, I mean so wait, so we know we had we know which users are new because they're new Right and there's already an issue in the issue queue to change Drupal.org so that our advanced search We can restrict to like the Date of the last patch that was uploaded so if we can get our advanced search table of issues to Say only show me the issues from new contributors and Sort by the date of the last patch That's our mentor issue queue and yes and mentors don't have to maintain their own List of issues they want to return to they were like oh, I know this new contributor Did some work on this I need to check back on this later And then they have to figure out how they're gonna maintain this list of thing right and nobody knows what it is But if we can do this query With like a database or something like and maybe you know some kind of interface to the data Then we have like people will be like, you know, I want to mentor new people Well, this is how you do it you go to this thing and it's just like here They here are the patches from the new people Review them like it would be so yeah, that would be great We do also have to be mindful though that it wouldn't wouldn't be the same query just for new people because we have to check That's their patch count. It's not the age of their account Because someone can have an a user account. That's five years old and this is the first time they've uploaded a patch Yeah, I think somebody needs to make an issue for this so we can we'll talk to Ryan But there's definitely I think a way to automate this. Oh, yeah And just to take out something that Kathy just said I think setting up I think these Drupal con sprints can be setting up false expectations because I Talked to someone who yeah, she had her first patch committed live on stage at Drupal con a few years ago Second patch waited for months. So I think just a better job of mentors, but in general Sprints are not the way things usually happen. I think that's just an education issue Yeah, I'm very big on Managing expectations and I tell people that if you know when we go to sprints if you want to be successful and have a good sprint Make sure that everybody accomplishes something But be realistic about what that something is so for some people it might just be commenting It might be uploading a patch, but that's it like that's the end or getting their dev environment set up and make sure They at least do something and they know what that something is no Yeah, I don't like when people show up and they think okay I'm gonna help out and I'm gonna solve a bunch of problems And they're all gonna get fixed and committed right now and when I leave everything's gonna be way better than it was When I came like that doesn't happen and that again leads to some of that demoralization Where people have these lofty expectations. They don't get met so they don't feel good about the experience You know just apart from managing expectations. I would like to add that We could definitely work on finding a way to incentivize this. You know commit mention is of course the Definite incentive when everything is done and ready, you know the patches the issue is closed But even before that if we find If you find a way to incentivize just the act of uploading a patch or act of reviewing and I think of course that's in works For example the data we have collected the number of patches you see is not the number of commit mentions on the on the x-axis so It goes up to 3000 I would say I think the largest that the topmost contributor right now has about 1300 commit mentions, but the number of patches are about 3000 and so we have that data and if we can use this data to Incentivize this you know like for example, you know top of my head. I can think of like a badge, you know 3000 plus patches It's something which is immediate, you know a person won't have to wait until the end of End of the entire issue cycle to see the Benefits out of his contribution And by the way the number of patches that Drace has uploaded is one So we need to find a way to incentivize him to upload We need to urgent control I'm sorry, I can't hear you Yes, we do We haven't gotten to some of our solutions Yeah, yeah, yeah, we should Okay, so we have already spoken Well, okay So let's start with discussing what we already good at right so recruitment is one area I was Prince are doing a great job and They're really good at getting more people in and that's that explains the long tail, right? You know the people with just one or two commits Commit mentions It explains that so we are good there and interest and that's building up Back home back in India. There are a lot of organizations taking an active interest in supporting contributions For example, I can use my own example here because excellent organization. I work for Pays me to contribute. I do this contributions on working time and I know of many other organizations small and large who do the exact same thing I as a local Organizer I've been approached by many organizations and when we organize camps The most common question is how do we get started with contributions? So there is definite interest Ability is there ability as in, you know, the technical skills, you know, you can write PHP code You can understand you can debug you can build a system so that ability is there that's not a problem and motivation again motivation in the sense of a Person wanting to contribute the desire again ties into the interest so all this are there, you know, we don't have to work on these But we have to improve the workflow and Yeah, so some of the things that we're trying to do Which improved the tools that are used for contributing especially to developers one thing that's hopefully coming this year that Ryan Aslet is working on mentioning his name again makes a logic is bringing this concept of issue workspaces to triple.org and this involves get namespacing and It brings essentially a pull request like system to Drupal.org so we can kind of get away from this patch workflow that we have now If you've been to any of his presentations that he's given about that already It's like standing ovation type stuff where it's like, yes, it's gonna be the most awesome thing ever Yeah, and that's why I put that link up there. Unfortunately his he's actually giving that talk right now so Do you check that out later? It's all recorded. I'm sure who'd be giving that talk again at some point And all of his information will be online He has some nice really good charts and workflows and awesomeness and You will hopefully after a Drupal con Los Angeles start seeing some of those issues pop up on the Drupal.org project Q where he's gonna begin doing the work and What I'm really excited about probably even more so than the pull request stuff is that along with this Become we're gonna get in browser editing and That is I think the most enormous part for getting people like front-end developers and documentation people and people who just want to fix really small things and One line changes and even reviewers because there's a lot of times when you review a patch and you see something really small You're like, oh you you have to just fix this comment Or there's a typo here or something and then you leave the comment and tell them to fix it because you don't feel like downloading the patch Spinning up your development environment applying it making this one line change making another patch and interdiff Uploading it doing all that work. If you have the in browser editor, we just do it straight away and go done Another thing that we've talked about doing That I've been privy to and I'm not sure if I'm supposed to actually talk about it Are the is this initiative concept that the DA staff has been talking about adding to Drupal.org which is it I don't think they've Fleshed out the software yet, but it may essentially be bringing organic groups on the Drupal.org and then using it as An actual project management tool so that you can build a group You can add issues to that group people who are responsible for them can sort the issues any way they want collect whatever issues they want Set up meetings post documentation do all sort of stuff and just keep it in one generalized issue era and Subscribe to the group so that when the group has updates You get notified so that you don't have to magically know that somebody made an issue about something somewhere Again reducing that knowingness that you have to do If that gets added I think that will that will have a lot especially for the initiatives and we can Possibly start ditching like these meta issues and all this other stuff that gets done And then the governance changes or not so much changes, but the refinement that happened recently So if you go to this node 2 4 5 7 8 7 5 it's where the core committers recently did a lot of work to sort of flesh out their structure and decision-making and their roles and doing something like adding a bunch of tags that are necessary to get like committer feedback and specific committer feedback so If you're not familiar the committers themselves actually have specific roles So there's a release manager. You're the Jesse the release manager You and catch this is the product manager the framework managers The benevolent dictator all that sort of stuff But we can start using a tag where we say hey We need feedback from this person because we're about to do something and it needs sign-off Right so we can start avoiding those issues where someone spends a lot of time working on something and then They didn't know the right person or they didn't get feedback. We can tag it and say hey I need your feedback on this as soon as possible Yes, so with this with the initiatives what David just described With with that in place we can actually start solving the final problem Over here final as we see it right now of matching people with their interests It's it's of course it's right now It's a little difficult to find issues that you might want to work on I personally like to work on issues related to base system and Either I would have to go to that filter go to the advanced search and filter on that component every day or Some if I just have to follow this initiative and I would be notified of anything happening over there and make sure that okay You know, there's a new version of symphony out. Should I should I work on that? That that you we solve these problems and again with this we start categorizing our issues better not just the the single layer of tags, but You know the the groups which is basically what we're calling as initiatives and with that we know, okay I know I'll be I'll be involved in the base system group base system initiative and If there is any issue that comes up like I just said, you know, I would know about it I would be able to stay abreast with it and This this can definitely help make it easier for People to continue contribute continue contributing even on the longer cycle, you know Once they have gone past that 10 commits or 50 commit stage It makes it easier Yeah, anytime we Step number one in mentoring when people show up. What do you always do you ask them? Well, what are you interested in and I don't think anyone has ever said PHP? No, they say well, I'm you know, I'm interested in this doing finance stuff or I'm interested in like this You know this you know UX or something like that and it's well, okay Choose this particular subsystem or component hit Hit save yeah Oh your front-end developer choose theme system and then go through the 500 PHP problems that are involved in that Subsystem and see if we could find a few that might involve CSS or something maybe possibly I don't know good luck I'll see in four hours and maybe you found something but if we can keep people if people can get more directly get to their interest groups and Get in touch with the people who are also interested in those areas And they can see things like these are the particular Issues in the queue that are related to this subject matter And these are the people that are working on it and there are meetings and there's documentation and everything It's I would hate to say this though It's sort of like reversed web thing that Dries talks about but like if you want to go an area and actually have it Pushed to you instead of you having to search for it, right that would actually help things Yes, yeah jazz hands I'm waiting for a drone to show up and give me issues Okay And you know, we've been talking about this the whole time but greater recognition for people and the work that they do we're getting So pretty good at getting developers recognition Commit credits and things like that, but we're always talking about commit credits which Are not always important to people People who do reviews should get credit and that's not necessarily each a commit credit people who are doing It can but we I want something more granular than that I don't want to just say this developer got ten commit credits and then you did reviews and got ten commit credits I want to know who's doing the reviews I want to know who's a top ten reviewer or who's the the top three reviewers in this subsystem Or who's doing the most UX work in this particular area or design work or whatever it is. We don't we don't do that now and I'm giving public recognition for people So this is something we talked about with like badges for organizations or the top ten organization We should you know find ways to Get people that credit as well We you'll see a lot of things now where people like tweet congratulations for your first commit credit stuff like that You know that kind of thing is really great and we need like more sustained efforts like that That gives people karma it gives them good feelings about the experience and it It incentivizes them to continue and feel a belonged just as an example here When we hit the two for two thousand five hundredth commit milestone Web chick tweeted about that. I don't remember the name of the commuter the contributor here Oh, it was you it was XJM Okay, I'm going to be in trouble for that but okay her name was Tati char and she was she's a student contributor And that was my Alright, so yeah, I got the names mixed up. Sorry about that But yeah now I see more and more contributions more and more patches uploaded by that user and This could be a coincidence, but I think not that initial encouragement actually Actually made sure that you know that person she she stuck on to the she stuck on to her contributions And I think well a tweet for everyone. I don't know if that sounds practical. We can think about it, but I Think it might be possible if we knew whether it was their first commit or not Right if then then that type something Yeah, I'm sure we could do it. Yeah Yeah, but I mean definitely my emphasis on this is things besides code, right? There is a lot of work that goes on the Drupal community. I mean like you do project reviews Right how much recognition do you get for that? Do we know how much how you know what your account is of reviews and how many hours you've put in a way and It's just you know and nobody talks about it, right? It would be nice if we had all that data compiled and would actually display it on user pages and give people credit for it So that there's you know, there's an equal playing field for people who are doing things besides just getting commit credits for a core If this actually opens up a whole new Whole new category of contributors were not comfortable with code, but who can go and update issue queues And that's very much needed Right. Yeah, I want to know who are the top ten writers Not just editing documentation. We're like blog posts So then we can contact those people and tell them the right more things Who are the top ten typo fixers? Push the push that information to me Okay, so one one thing that I would this is Lucas heading HEDDN on Drupal org I Think that as we I Think critical to all this is being able to and it's a constant thing So I do IRC mentoring on on Wednesdays Let's get some of these other introductory remarks out there So I do IRC what mentoring on Wednesdays and what what's our constant sort of internal feedback every three months is Hey, you know what? We should probably get more of these folks that are coming on a regular basis to be able to find their own stuff and Then two months go by and then you know We should really get folks that have been coming here regularly to find their own stuff Why is it so hard? I feel like I'm a matchmaker, right? I'm matching up Jane with John right we're finding issues for folks. Why is it so hard to find stuff? I think part of it is our growth Suggestion here. I want to find easy stuff that folks can get a Success on even if they don't get a commit mention at least they got a patch uploaded in their 45 to hour and a half stretched long lunch break or Maybe they did it before the kids or after the kids went to bed, right? That means I need to know what novice tag novice tagged things are But I can't just look for novice tagged things I need to look for and and this is my soapbox. We need to know patches that and and the dates for when patches have been Uploaded because if I don't know that and I need to know it's a dot patch file not a dot jpeg I Need to know this information so I can do a reverse search and look for something that's three years old or In that search around and I can play with the data now I've got the information exposed to me so that I can look for something that's been tagged as novice and that's in that sweet spot of Five weeks old so it's not so terribly complicated to To look at and try to figure out what's going on and re-roll the patch And they want to pick up a JavaScript patch that's three years old and try to apply it ain't gonna work You need something. That's about five weeks old. Okay, soapbox. We need this information We need to make it easier for folks to get into the issue queue and and find stuff for themselves and in and jump in there on their own and Get successful Without having to be Yeah, I mean we have a big problem and it's in a way a good problem is that we've we've grown a lot We've grown a huge amount, but it's just that our tools have not grown with us I guess I have a little bit of a question here in the sense that I know everybody's really focused on Wait before you go for a question next slide I know everybody's really focused on cutting down the time between patch review and commit But you know one of the things that I struggle with every day just like in my everyday job is is understanding when something's Actionable right so sometimes a patch sets for a really long time Because it's not a really important patch But it was something that somebody had time to do and it was little and it was unimportant right so that's not Necessarily by itself a sign of a problem I mean sometimes the whole world worry about agile programming is that you're supposed to be developing issues so that you can Figure out from the lay of the land how you might do something as you go and the low priority chunk of something you want to scoop in and do it when the Time is right and so I guess one of the core questions that I have is to I mean for me It's like right now I'm scratching my own itch about something that I think is really important for the for the for the future of Drupal and stuff like That but the last thing that I want to be doing is Taking all these people who are already the barriers and roadblocks to to Drupal 8 being released and Jam them full of issues that need to be triaged or patches that they need to decide and review their commit Somebody's little personal itch that isn't really inside the the the core kind of release blocker thing Right from that perspective So it's like I want people to be folk to increase the contribution of the stuff that matters And so looking at fringe stuff and a product this big and this old it kind of worries me about well You know are we really focusing on the right thing? It's like to what extent are we focusing on on? The important stuff that needs more resources and connecting that with the people who have resources to give Versus just saying you know what we just want to reward people Because we want to increase the volume of contributors because growth is not necessarily a measure of success, right? So to this I would say that there are really two things here. So first thing is of course The problem is that we need new contributors. We need them and the the time problem over here is that The the problem of incentivization Okay, now right now the way incentivizing a contribution works is ultimately when everything is said and done and when the issue is committed and you get your name in the commit message and This is what discourages people So if you find a middle ground say that you know not the number of commit mentions, but the number of patches you have uploaded Okay, hold on a second. So You mentioned that earlier and we need to not do that That's really really dangerous to incentivize the number of patches and in fact We're already doing that by incentivizing the number of commit mentions and one thing we do not need is people who are like I'm going to like make 50 patches on 50 issues. It will kill us all And there's already I see I see sprints that happen and then the sprints are like Celebrating their successes, right? So they write a blog post they make tweets and they're like we had the most successful sprint ever We had 50 patches put up on the issue queue and I'm like, oh my god No, please you needed to have four patches put up on the issue queues and 20 reviews done So if we're gonna do I like your idea of incremental Recognition that we shouldn't have to wait for commit mentions. I'm with you on that But the way that we do it is on reviews not on patches. We ignore the number of patches that people make We don't have to I incentivize anybody to make more patches. We have plenty of them What we don't have is reviews Contributions in general. Yeah, and we need to figure out so use. Yeah, so well views or fixes I know fixes is a longer term reviews the end I Share your concern old issues that haven't been touched in a while probably aren't worth touching again So we shouldn't devote a bunch of resources to getting them reviews if we can We can do this in two different ways But if we can do like David was talking about these groups these initiatives and the initiatives can prioritize issues Then when new contributors are coming They are working on the issues that the initiative leaders have identified as currently important at this time They'll never work on these issues that we okay not never They'll be less likely to work on these issues. We don't care about so that will help solve that problem also Yeah, we started for for the front-end stuff and at our last twig meeting We made a Google doc of all the stuff that we're gonna start working on while we're here in Los Angeles Because I'm tired of going through issue queues looking for things. So when someone comes to me I'm looking at that Google doc and saying here you work on this. Yeah, I also think Like in terms of identifying more in metrics and recognizing people I think it would be amazing if we could figure out a technical solution to make a leaderboard of the number of project Application reviews that are done, but that's the same thing. It's a leaderboard of reviews not of how many applications you have Right. We don't need more projects The other thing I want to mention is node Two three nine six eight six five it's a meta for finding issues to work on is difficult Um, it's related to another meta that is finding issues is difficult That's slightly different, but on one of the child issues of this is Is issue two two one nine four nine three add a search for issues with patches that touch certain file types Like JavaScript or CSS So we if we can improve our search tools Then we can do a better job of matching up people with things to work on and Any I know we're out of time We are two minutes past And I hate to keep you all over from coffee By the way, go to the sprints On Friday, we need to find out who these two people are in this picture because we keep using this picture So we should find out who they are and ask them that it's okay We keep using the picture because we because it's a really good It's like a perfect picture for like the mentoring and the sprinting and stuff and just like make sure it's okay That they don't feel weird that way we start using it everywhere So so with regard to the sprints tomorrow and finding issues that are important and Relevant to all of the things I said this in the last session too But we're trying to do a triage of the major issues that are in that are outstanding in core There are like almost 900 of them if you're someone who has some experience contributing to core before previously But you're looking for a way to get more involved and help with this issue discovery problem of having Lots of old stale irrelevant hard to search stuff as noise in the queue Come like when you come to Sprint Day because you're all coming to Sprint Day, obviously When you come to Sprint Day look for the major triage table that Kalpana is going to be leading and I'll probably be nearby Chris Cellefin here also is leading the sprint and the goal is to go through the major issues in the queue So by by virtue of being major priority. They're already to your point about finding things that actually matter They already someone thought that they were more important than you know two-thirds of the stuff out there So that's a good way to know that something at least at one point mattered I encourage people to come help help out with that tomorrow Fry oh Friday is it night? It's Wednesday. Yes Friday. You can come out tomorrow too, but Um how out of time are we? Okay, thanks Kathy um so and Hussein you said that you you like to work on the base system queue so the base system is very Scary and I was going to like not even included in the triage It's the it's the component with the most major technical dead-out standing But if you are already working there It would be fantastic if you wanted to like lead a team to do that at the major sprint if you don't have another goal for Friday already That would be really awesome But this is the point that that kalpana I talked about is that you are gonna get? Credit for in the issue when the issue is if the issue is eventually committed and like some certainly a proportion of them Will be you're going to get credit like we don't we can't surface it immediately on triple dollar yet But you will get commit mention in the commit message for doing like posting a substantive comment That summarizes the issue whether or not it's still relevant finds related stuff like if you act you're doing this this triage exercise Isn't just clicking buttons it involves research and thoughtful thinking about specific problems And that's that's a part that's work that deserves commit mention And so so I've been committing patches to triple it for about a month now And I credit reviewers on every single thing I commit there's I mean it's like substantive reviews like when someone and not just not Just code review like someone does design work They deserve to be credited in the patch for that issue if someone does usability review They deserve to be credited in that issue And and we're going to do that for the tree estimate as well So you if if that recognition is one of the motivations for you Please come to that I was going to address more of the point about Not crediting patches specifically, but I don't want to battle since everyone probably wants to go have coffee And thank you this session is awesome Thank you, and then of course do the whole go to the page and Allow the There's been a couple mentions about project application. I want to put a little advertisement out for David's session at five today He's going to talk from now Project application process if you're interested in that and seeing improvements there. It's yet another area that needs improvement Thank you I