 Hello everyone. We are going to talk about pain points of contribution in the Drupal community. Very excited to be here and very excited to be speaking. We have bit.ly links. First one is for the notes. It's bit.ly slash pain hyphen points, hyphen notes. We encourage you to take notes because more notes is better after this session. Val and I will be preparing synthesis based on the discussion here. We have also posted the slides online which is bit.ly slash pain hyphen points, hyphen slides. So you can follow along and you can see our speaker notes what we will be talking here. My name is Kalpana Goyal. I am from Washington, D.C. I work for ForumOne as a developer and ForumOne is a full-service digital agency. We do a lot of non-profit organization work and government agencies in Drupal. My name is Valerio Luria. I run a small Drupal agency which is a distributed team. We work in Europe mostly. I maintain several country models on Drupal.org and I am hireable both as individual and as an agency. So we are talking about pain points of contribution, but what is contribution? Contribution is organizing sprints, camps, meetups, writing documentation, whether it's documentation patch or writing documentation on Drupal.org, doing manual testing, design review, UX review, but in this talk mainly we are going to talk about code contribution and reviews. I presented similar session at Drupal Con LA with another co-presenter and it was surprising that multiple people and quite few people said that their biggest pain point for contributing in Drupal community is using IRC. I was really surprised because personally I like IRC really. But IRC is because how many people in the audience use IRC? About 40%. So you know that Drupal lives on IRC. We do interact our day-to-day interaction in IRC related to issue in the issue queues. But how about if a new contributor decides to contribute to Drupal and have no idea that there is such thing exist or any newcomer to Drupal community? As for example, when I started working in Drupal, I didn't know that IRC really existed. And one of my co-workers just told me one day why you are not IRC and I said what is IRC and why you are asking me to be on IRC. Why I have to be on IRC? And he said because Drupal lives on IRC, if you want to work in Drupal, you have to be on IRC. So how people can learn about IRC? How do I connect to IRC? What channel should I be in IRC? There is no information about list of channels or any information about IRC on Drupal.org home page. So you can go to Drupal.org slash IRC, which lists all the channels of the IRC which you can log in and connect to. Or you can go to Google and search for Start Contributing and then go to Drupal core mentoring page and that has a list for the IRC page. So some people said that it is very difficult to keep up on IRC. For example, if three or four people having a conversation on IRC and if people, like somebody is typing my nick or IRC handle then I know that person is talking to me. But if nobody uses my IRC handle, I don't know who is talking to who. So for example, other chat apps like Slack and HipChat, it shows like who is typing. So you kind of get an indication, okay, this person is talking to me and is typing. So I should wait for it to get an answer. So for some people, it's really, really hard to keep up on IRC. And someone also mentioned I was at PHP World last year and I happened to organize a Drupal core hackathon and somebody from the PHP community said that why you are on IRC? Because IRC is so 1990s and I had no answer to that. And I just said because we just talk on IRC, so we are on IRC. Another pain point of using IRC is that there is no scroll back or history. I am logged in on IRC. But for example, I'm not on my machine or computer for two hours. After I come back, after two hours and I want to scroll back and read what happened in two hours. There was interesting discussion and I was interested to know more about that and I want to read about it. But there is only so much my IRC client, which is Line Chat I use, that can show to me. So there is that, that history is all lost. I don't know what happened. I really wanted to know, but there is no way to knowing that. So to mitigate that problem, you can set up Bouncer. And so the question is what is a Bouncer? How many people here in the audience use Bouncer? Two. So Bouncer is a piece of software, like running on remote server. So you can, the advantage of setting Bouncer is that you are always connected to IRC. But setting up Bouncer is not easy. It requires technical steps and it costs money. So in the beginning, there are some steps that you need to set it up, but it becomes easier in the future if you want to use it. But it does take time and money. There is an issue on Drupal.org. The issue number is 2490332. So in this issue, I actually created this issue after DrupalCon LA session. So in this, we are talking or community is discussing about an exploring and better option or alternative in place of IRC. So some of the options being discussed is Water, which is open source software application, or Slack or HipChat. We know that the Slack and HipChat, you can use it for certain limit for free. But like if you want to store, like show the history and if you want to display the old messages, I think then you need to go to the premium account. But this, nothing has been finalized yet. It's still in the discussion. So if any of you are interested and have any feedback, please do participate in the discussion because it will help the community. It was also noted during previous discussion that IRC is definitely not the only channel to communicate, that is used to communicate through within the Drupal community. First of all, there is a powerful tool of issue notifications via email. And if you go to any page of any project, including Drupal Core, of course, which is www.drupal.org slash project slash Drupal, there is quite a few links in the right block, including subscribe via email. And there are several options to choose when exactly to get identifications via email. Some things have changed also since LA and we have more or less regular core updates. That resides in groups.drupal.org slash core slash updates. They go from weekly to monthly, this week in Drupal Core or this month in Drupal Core. And in addition to being a web page, it is also an email subscription. There is ongoing discussion on Node 2230579 about how we can recognize contribution which is different from writing code. And we are focusing on writing code and contribution by writing code in this session, but still we have other types of contribution like research, like providing screenshots, writing issue summary, and things like that. So if you want to participate in that discussion, you're very welcome to visit that node. So my co-presenter Val just talked about how do we recognize contribution, because this is also a problem. We do recognize contribution for somebody writes a patch. Now we made an improvement that now we recognize contribution for the reviewers, because reviewers spend a lot of time. They read each line of your code or documentation, and they spend time reading each line of the code, making sure that it does what it's supposed to do. So we have made huge improvement and we do recognize that contribution. But what about documentation review? Because when you are reading documentation, you just say that, okay, I read each line of doc, and it does what it's supposed to do. Do you get credit? Come with credit for that? Does anyone have experience about that? No one? I will share my story here. So recently I had an opportunity to participate in the code sprint at MWDS, and we were working really hard on safe markup issues. So someone asked me, can you review my patch? It's a documentation patch, and for the safe markup, and I said, sure, I will do that. So I spent two hours because that patch was so long, and I kept reading each line of the code. And the person who worked on the patch, he was also there. So I had some suggestion, and I went and talked to him. He made those changes. I was talking with Alex Pott on IRC, and in the meantime, he also provided better language for the documentation I was not happy with. And so everything is good. I said later in the night, I said, I read the patch, it looks good. I will mark RTBC. But guess, did I get commit credit for that? Any guesses? No. So that was disappointing because we all want commit credits because we all volunteer our time. We are not getting paid. This is volunteer stuff. So of course, I want to get commit credit because this is something I am really proud of. This is what I have invested myself into. But I will tell you why I didn't get commit credit for that issue. Because when I RTBC that patch, I said, I read this patch, and everything looks good. And it was not enough. It was not enough. When you do code review, you read each line of the code, and you just provide thorough feedback and say, yes, I read each line of the code, this function is doing this, this variable is doing this, this method is returning this, or this looks good. But what about documentation review? Documentation has the same thing. When you do doc review, you say like, I read this documentation, and this is doing what this function is supposed to do. And that's what I liked. So if you want commit credits, please do follow those steps and provide thorough feedback or review on even on the documentation patch if you do want to get commit credits, which I don't know if you want to spend two hours and not care about commit credits. Not me. Another improvement has been a huge improvement has been made to user profile pages on Drupal.org. So that new improvement now it shows the commit mentioned on number of the issues that has been marked fixed in three months, the last three months. But by the way, how many people here think that their user profile page on Drupal.org is really important, and they use it on their resume. Can you please raise your hand? About 40%. I think it's important because that is the place I tell my employer to go and look even though I have not contributed any module or team but I have now the core mentioned which I think it's important. And then people have listed me as mentor. That is also important because that shows that I am one of the mentor and I I don't work on my own issues, but I rather help other people to work on their issues. So I think these are huge improvements. As many of you know, there is thing called mentored core hours, which happens every week in IRC. Sorry for IRC, but still. And what I've heard from many mentors that visit that core mentoring hours almost every week, including myself, is that it gets kind of disappointing when people work on their own issues. And when they finish and they get some help from other people, who from their side can easily commit that trivial change in the text and get their own commit. So they help other people to get started with contributing with core to core. So mentors are very happy when other people list them as mentors, because it's also part of the new user profile on Drupal.org. So this is a screenshot of my user profile page on D.O. As you can see, I have listed a few people as my mentor because they help me work on issue. One of my mentor, he's sitting right here, Tobias. He's a shortcut module maintainer and he helped me work on shortcut module issues. So this is my token of appreciation to him that, you know, he instead of working on his own issue, he spent time with me and he explained me what's going on into the issue and how I should proceed forward. So kudos to him to spend time with me and help me work on that issue. We'll work on it on Friday. And this is like and some people have listed me as their mentor, because at some point I help them work on some issues. And also you can see that the in the previous slide, what I was talking about, it has the commit mentions. So I fixed I got commit mentions in 12 issues, which got fixed in last three months. So this is new. So after LA like LA was four months. So after LA like maybe from July, August, September. So this is this is I think this is a really huge improvement. Can I interrupt you for a moment? Yes. So this here is another pain point is that this is a number of issues that were really committed to core and a lot of people participate in issues that can long for months or years. And this number doesn't appear here, which is kind of sad. Another thing is that how can we encourage companies to contribute their developer time? So we don't do much to recognize those kind of contribution for the companies. We have new feature on triple dot org, like if you work on the issues, you can select like, like K Gwell at forum one. So my company get credit. And they recognize that forum one is contributing their developer time to work on core. But I think there is some, some idea or some kind of planning in the future that they will gather all these companies name and show somewhere on triple dot org, but it's not there right now. So I think the whole back for the companies is that, okay, we can sponsor triple con, triple camps and sprint because we get more recognition because more exposure during those events. But if I can't let our developers to work on core, then there is no such recognition. Yes, Mike, please. There we changed the marketplace to reorder by that yesterday. So there is today. Is there is that information somewhere on dribble dot org that we can go and check? It's the marketplace. Yeah, it was the keynote introduction. And Josh posted a blog post on the home page of triple dot work too. So yeah, it's yeah, it's really recent. It was just yesterday. But yeah, it's done. Would you mind posting that link into our Google doc, the link I posted? I don't have the link to the doc. Okay. Yeah, it's the most recent news post on the triple dot work home page. So that's a biggest step. So I guess the whole back for the companies is that because they don't get recognition and so they don't want to contribute their developer time to work on core. I want to give as an example. How long it took us to raise triple eight accelerate fund? Does any everyone know what the eight accelerate fund is? Does anyone not know what the eight accelerate fund is? What is that? Yes, so this is something new, which we did for triple eight. So triple eight accelerate fund is to raise money to help core developers work on critical issues to help move triple eight forward. And there is a related session, by the way, it's paid contribution past, present and future tomorrow at 1pm. I encourage you to all come and attend that session. And also, so this is a screenshot which I took from triple course dot com. It shows the list of the companies and agencies. So for example, card dot com. They have contributed five pet five developers and they have contributed 74 patches. So this is some kind of something nice. But this is this information is not on triple dot org. Somebody has to know that they can go to triple course dot com slash companies page and then find out this information. Mike Okay. And by the way, this is a core conversation. So this is a short presentation. And so there will be a plenty of time for discussion and question and answer. Kalpan was talking mainly about big companies and how we can interest them to pay people for contributing to the core. But there is the other side. People who work in small companies or work by themselves. And the problem for them, as well as big companies, of course, but the problem is different from that. It's their time and their money net. There is no one there is nobody that is able to pay for them. And of course, they all of us have families, we have bills to pay and full time jobs responsibilities. So it's kind of problem to find the proper balance. There is also a buff on increasing contribution in open source software tomorrow at 1145. Someone is doing it and asked us to add it in our presentation. So what other open source projects are doing things differently? So recently, a patchy tweeted this, that they pass 5000 committer, I think it's not committer but the contributor mark. And this is a graph I took it from their website. It shows like how you can see like it started in 1999, and it was pretty flat up to 2001. And then it started picking it up. And now by 2015, they have 5000 contributors. I don't think we have this problem in Drupal community, because currently we have 3150 contributor. But the problem is that we don't have many repeated contributors. And I will explain it. So this is a long tail graph. I took it from XGM's blog post. So you can see and this graph is few months old, because as I said that we have 3150 contributors. But you can see the line is flat, not like a patchy. A patchy is like moving up. But that is also from 1999 to 2015. But anyway, so we have lots of contributors who have contributed to core, but they have like patches up to like 5 or 10. But very few people, they have patches or contribution, like 20, 50, 100 and so on. So the problem is that we don't have many repeated contributors in core. Just to sum it up, we have talked about pain points from Los Angeles and something has been added since. And some of these pain points have we see suggestions that we can do. Definitely, we need more reviewers and we need to reward people who make contributions other than writing patches. We need not more documentation, but we need better structure documentations. We have tons of the commutations actually, which is written by people and generated from the source code. But in many cases, it's really hard to arrive to the piece of documentation that you need. There is a certain problem caused by unique workflow of Drupal that is different from other open source projects. And I know that we know that pull requests are coming to Drupal org. And this is great. But we're still not there. We need better communication, and probably something different from IRC channels. And you say about motivation. So this is not a suggestion. I have two pain points, which I have also it's not just my own pain points, but I have talked to many core contributors and my friends in Drupal community. And they all say motivation. How many people have that problem here? Or the pain point? Please raise your hand. Motivation. I really want to learn because Drupal 8 is great. We are using modern OOP. And it's great because if I learn this thing, maybe I can apply this knowledge to symphony level and other platform and do other projects. But the motivation to work on core, because it just drags some time. If I submitted a patch, if my made a comment, if I'm waiting for answer, it just takes a long time. And the problem is that we lack reviewers. There aren't many reviewers. But hopefully that will we will overcome that problem because we have started recognizing their contribution that reviewers are important to Drupal community. And another thing is time. We all have our personal life. We most of us have full time job. And I as I said, I want to work on Drupal core. But having full time job and working on core, it's not something not possible because I want to have a healthy life outside my Drupal life and work life. So it's it's very hard to balance everything together like my work, personal life, Drupal. So speaking of that, please come to the sprints on Friday, help us get release Drupal 8. And at this point, I will open the mic to audience, please share your pain points, suggestions with us. I would like to hear from you. Hi. So I'm not a Drupal developer at all. Can you say your Drupal.org name, please? El Smith 77. I do have that. Despite not being a Drupal developer. So one thing that that I noticed. So you mentioned pull requests are coming and you know, Drupal.org workflow. And I'm pretty sure that there are lots of benefits for doing it. So I'm not advocating like just dropping that. I do notice also that there's a GitHub.org mirror of Drupal. But it specifically says that no pull requests are accepted there. And I'm very active in the symphony community. And we have a similar situation in a way that we have a symphony GitHub repository, which is one monolithic repository where all the code lists, and then we have subtree splits for each of the different components. And for a long time, we didn't accept any contributions on the components because we work in the main repository and the components are just read only. And at some point we said, no, actually, we want contributions to be easy. So if somebody is just using the component, we now accept merge requests on the component and we do the work to bring it to the right process. And that basically means we pick up the people that want to contribute. We help them then move it to the proper process, rather than just telling them, no, this is not the place you have to go elsewhere. And the same way I would suggest that, for example, if you have that GitHub mirror, or even other places, that you welcome whatever contributions in whatever form, and then you do the work and bringing it into the right process, and thereby teaching the people how to do the proper process rather than just telling them, no, go elsewhere. And by telling we who pull things and proper people from other repositories to the main repository, you mean who exactly? Drupal community. So again, these would be volunteers from the Drupal world. But this is a great way of just bringing new people in into the community, rather than just telling them, whatever process you know up to now is wrong. You have to do this process. You basically tell them, do whatever you know, and then we will take you by the hand and bring you into the process. Does anybody want to answer that? I think Klausi at one point had a tool he was using for Larry, can you say your Drupal.org name? For those who don't know me for recording. Yeah. I think Klausi had, at one point, a tool he used to synchronize like, I think it was before going GitHub from his GitHub account to Drupal.org issues. And just kind of a stop gap until we figure out how to get the full pull request like behavior on Drupal.org. There's a lot of pushback on it. But I think tools like that might help with what Lukas is talking about, just some way that we can automate, hey, there's a pull request over here. Now, talk to that person or whatever. Another thing that is a barrier is if you want to do reviews on Drupal.org, everyone needs to use Redditor for Drupal.org. Really, Redditor is the tool you have to use, which means you need to know that you need to go download this browser plugin in order to review patches for Drupal, which is just ridiculously weird. Is there a reason that's not just part of Drupal.org yet? I mean, it's kept in sync. I mean, we've got a Drupal.org person here, maybe you can answer later, but that seems like something that should just be baked into the site and not be a browser add-on. That would just be one less step that new reviewers have to think about. Hi. Sorry. I think there was discussion about that, about adding their editor to Drupal.org, and the reason that it's not part of Drupal.org is that there are people who are Drupal.org users who are not contributors, so they don't need their editor. As far as I know. So, yeah, there's probably an issue. We could look up the issue number for it and find out. And we can also listen to what Neil has to say. Cathy can use it. Yeah, so my name is Cathy. I'm Yessi T. The idea of not telling people no on GitHub and allowing them to do it there like they normally would and then redirect them to a different process is quite interesting. I think in the least, we could probably have some kind of GitHub hook that runs, that responds to a pull request with instructions on how to do it on the Drupal.org issues. And that might be a soft introduction to doing it that might avoid some of the backlash that other people's automatic postings on comments and stuff have gotten in the past. So it might be like a little bit of a halfway. I'm Neil Drum. So I work on Drupal.org. So a couple of things I've heard on the Dreditor thing is the Dreditor maintainers, they've basically Dreditor is a hack. And they've said, as far as I remember, something along the lines of like they don't think it should go into Drupal.org as is. It's not good enough. And yeah, we do want to take a look at some of the other, there's lots of open source code review tools out there. And maybe there's a standard software package that can be integrated and work well. So yeah. And the other thing is time. You know, we need to to actually look at those alternatives and maybe look at them and say, oh, well, our hack works. That's possible outcome. But yeah, that's the least a few hours of work. Yeah, I would agree with Neil that there's just so much that the Drupal.org staff has to do that's uber critical to the project surviving that Dreditor hasn't made it up the list yet. I think PHP fabricator is the tool that I think was the last time we did an evaluation of what kind of review tools to add was the one that looked the best way to go at that point. Yeah. Hello, I'm Dassio. So I liked the idea of opening up more possibilities of contribution and I'd be interested in is the canonical resource for discussion and information still be kept in the main repository or in the case of Symphony, do you then also handle the complexity on the subsystems? Because that's what I would be concerned if, like if we if we start thinking in branches and features, do we also communicate in those isolated levels or do we communicate on on the main level? Else Smith. Use Mike, please. Can you both please use the mic? Hey Lucas, so my question is if you handle discussions in the subtrees or do you direct the communication on to the main level? No, so we try to then directly as quickly as possible get it to the main repository. But again the fundamental idea is really that we will never make it a barrier. So if the person will then reply there, I think that the I mean we technically don't prevent like I think in GitHub you can now close the discussion but I don't think we've ever done that. So if the person insists on replying there then that's just how it goes. Shifting gears slightly from the mechanics I think another one of the barriers that even I run into a lot is the knowing whether or not something will be accepted or would be accepted if it worked. You almost never know that in advance and the more work something is the more of a gamble it is. So that means pretty much unless you're sponsored and working on something that has been specifically called out by trees to you specifically, which is about five people, everything we do is spec work. And any designer knows spec work sucks. And so just having some better way of communicating these are the kind of things we want, these are the kind of things that if you do will get accepted if you if you do will probably not get accepted. Yes I'm talking roadmaps but you know some way of being able to communicate yes this thing is going to be worth your time or not before someone spends the time on it because you know the negative impact of putting in an hour of work on something to have it then either not be accepted or to sit idle or be outright rejected or whatever it take that's that compensates for 10 successful patches getting in just getting one you know nope with the work you spent on this is not going to be worth anything. So minimizing that with much clearer direction communication I think is another important pain point for just pre-approving issue concepts before people start working on code or whatever the mechanism is just to minimize the amount of spec work that people do because that is soul crushingly bad when it stuff doesn't get in that that way. Do you see any mechanism for that? I've actually tried a couple of times to push through things like that at one point there was an issue tag needs architectural review or needs committer feedback or we've had a lot of different mechanisms we've tried over the years not all of which have stuck at this point I think things with a novice tag are pretty well guaranteed to get in because they're so simple I don't think beyond that there's any real reliable mechanism to say yes this thing is okay other than well can you make an argument with a beta evaluation which is you know current phase of the cycle we have that. Other than much more proactive work from project leadership which who knows once we actually get Drupal 8 out maybe we'll have time to think about that. That's all I can think of just much better marketing and much better communication around you know these are the types of things we want to do this is the collection of issues we care about these are their priorities these are things we explicitly don't want that's a useful list as well that we've never really done anything with but that's a good thing to have as well of you know if you have a patch with those X Y or Z please don't waste your time because it won't get in for whatever X Y and Z are which means deciding what those are going to be but just some better method of knowing you know if I'm going to go spend a couple of hours writing this code is it going to go anywhere or it's going to go into blockhole is it going to get won't fixed it's going to just sit there and not get won't fix but to effectively be rejected anyway which is even worse just improving that process I think is helpful because even first you know longtime senior level people myself included that is soul crushing when you say that knowing something that if this is guaranteed this will make an end make it in before someone is starting work on an issue are you talking about this phase right now or has it been the issue always from the beginning of the development cycle just to be clear I'd say it that problem exists worse during beta or during our scene for obvious reasons but I think at any points I don't think even in the early stage early stages of the whiskey initiative you know there's no guarantee of anything or if there was it is so informal as to not count so everything ended up then being a fight to get through large and small changes because nothing ended up pre-approved until the patch was r2b seed and even then sometimes not so it's it's more of a problem during beta but it's not unique to beta it's just a natural part of the process I think and that's what we need to compensate for hi el smith 77 again yes this is a response to Larry I'm not sure if this is accurate but you're talking about things that go into core rather than that things could be that could be done in the module okay so maybe maybe the problem will solve itself and here's why with two blade you now have an object oriented architecture and you have interfaces and the great thing about that is that it becomes much more feasible to hack the core by extending it by you know overriding things in services and so on so forth so that you know it doesn't get into core in symphony in many cases when you know people are starting like bigger things where they are uncertain about that they just started as their own component and sometimes they just live at their own as their own components and sometimes to get actually then promoted to become official symphony components later on but either way like your work will not be for nothing right just because you didn't get into core it doesn't mean that your work will have to live as a core hack which probably doesn't make sense in the long run but it can it can live on and still be useful so obviously still you know if you have the ambition to bring something in cords can still be soul crushing if it doesn't get in but at least the work is not entirely lost so okay maybe the problem doesn't solve itself but at least the the pain will be reduced a little bit in the future so I think there's two different kinds of things to think about when you're when you're thinking about investing your time and doing something one is like investing your time in doing something relatively big and the other thing is investing your time on a very discreet small issue and so the way to solve those two things could possibly be different when when Larry said the problem is worse during the beta phase I actually think the solution that we put in place is better so we had then that we didn't have before guidelines that were written down and agreed upon by the core committers as to what was going to be allowed in the beta so it was more restrictive maybe what was going to be allowed to be commendable but our communication about it was much better and then once we got the secret tool that experienced contributors know dreaded her with the beta evaluation button it also became somewhat discoverable instead of some mysterious thing that nobody knew about so it may have been frustrating but also our communication was was much better and I think we're going to see that also improve as we move into the next phase of the release with an RC I think we'll get extremely good communication that we tell everybody about is in terms of what's a priority and depending upon which phase we're in and in fact we just opened an issue I think yesterday for a way to actually make that discoverable automatically by everybody who looks at a core issue instead of a secret dreaded her thing or you have to be on IRC when people are talking about the new doc so I think we're we're going to get much better at communicating what things are worth investing time in and in which things aren't it got a I want to add a caution Larry said that people can find issues that are pretty much guaranteed to get in by looking for the novice tag the novice tag is not triaged none of our issue queues are triaged right like if we actually had somebody who knew what they were doing triage the whole entire issue queue this wouldn't be a problem but we don't and anybody can add a tag so in fact what happened a couple months ago is that we noticed that many people would tag my normal tasks as novice because they were easy but in the beta normal tasks were not allowed to get in so yeah you still don't just assume because it's it's got a novice tag that it's it's committable you still have to evaluate depending upon which phase of the release we're in I think in some cases it's just not possible to know whether or not an issue or a feature can go in until the solution is there to look at like sometimes the idea can be something good but depending upon the implementation it will either break other things or it won't break other things and so you can say yes go ahead and work on this we're going to commit it until we see what the repercussions of the solution are so it would be nice to get some initial guidance and that might be helpful in some situations but I think even if we triage the issue queue before people started work and identified things that were a priority or won't I still think we're not going to get around having to have some kind of solution in place before we can really say whether or not it'll work anyone else I have a question for Larry so for a module or company and maintainer or subsystem company and maintainer do you find the process easier than compared to contributor like me when making decision when we are like I am working on issue and waiting for response and guideline and I have no clear direction and just relying on you and other component co-maintenors I mean that's that's also one of my pain point before are you talking before or after the new governance model when one of the reasons we brought that in is quite frankly before that no being a subsystem maintainer in practice didn't give you any special treatments in that regard at least certainly not that I ever felt as a subsystem maintainer since seven years now something like that you know in that time I never really felt there was you know subsystem maintainers got any special treatments in terms of determining roadmap or getting something in that someone else may disagree with there really wasn't any benefit from it since then I have you know there have been a couple of issues where we've been able to just pause an issue and say wait let let the subsystem maintainer speak let them get in on this let them give them a couple of extra days for review or whatever and that's been good we have not you know since it that was only introduced during beta it hasn't run for that long yet and at the same time we've also had more people who are now working full-time on core in you know the the more inner circle in a sense so that dynamic is still evolving I'm not quite sure where it's going to end up but as that's yeah it it didn't use to mean anything it kind of meets something now which is an improvement what it will mean in the future I'm not sure that's a social dynamic we need to continue to work out just in practice through using it but yeah as I as a subsystem maintainer I don't feel like I have a guarantee on changes I still have to convince whoever happens to be in the issue plus whoever's committing it that yes something's a good idea and haven't tried to push any large changes since we brought the new governance model in so I can't say on that front asking again in 10 months that does that answer your question yes okay no one else nobody has any pain point all right thank you for coming please don't forget to rate our session