 All right. So the purpose of what we're doing today is to talk about leadership for Drupal.org. There's been some really good conversation on the proposal over time. I think it's been a little bit quiet, and I suspect that until we actually start really doing things and making decisions that it will remain quiet, it's a difficult part of the conversation, I think, for people to get their heads wrapped around in a lot of ways, trying to figure out, like, what is process, and how does that work, and how is it going to be really different than it's been in the past. So what I hoped that we would accomplish today, and we should have plenty of time to talk about things, is actually review the current proposal, discuss any concerns that are in that, and then look at the to-do items. And the to-do items are largely about the details of process. So what we'll do is hop down to the comments and talk about suggestions that people have made. I think they've been really good ones. And then just generally talk about a timeline. So that'll be the last item, and it'll make more sense in the context of the proposal. So I'm opening that up so that it's on the screen right now. And just to have the background since this is being recorded, I think all of us know that the governance process that was kicked off almost a year ago, eight months ago, to help facilitate decision-making around Drupal.org, and Drupal as well, in different committees, convened a software working group, which is Tatiana, Neil Drum, Angie Byron, Kim Pepper, and myself. And one of our mandates is to appoint leadership for Drupal.org. And so it's in that context that we're looking to define the roles and how people are appointed and removed is the language of the charter, excuse me. So we're starting, rather than trying to define all of the Drupal.org properties and all of the things that have to do with Drupal.org, really talking about what has become the developer tools. And so I'm looking at the scope here. And so the proposal is to appoint roles and leadership for these areas of the site, that is projects, the issue queue, packaging scripts, releases, and release nodes, version controls, so to get repository, to get integration with the website, the repository viewer, and the continuous integration dusting for TESPOD. And I feel like that has generally been agreed to, that's a good idea, that that's the right scope for a team. And I pause here and just see if anyone has anything to add to that. It feels like it's fairly well decided that that's a good idea. And you can still hear me, right? Okay. So probably more debatable on certain levels, but there's some fairly good feedback on here. What are the skillsets or roles that are needed in order to cover this area? And it's been broken into the idea of a product owner, a project manager, a QA lead, a UX lead, and lead architects for project version control and TESPOD. And the reasoning behind the lead architects is that those on an infrastructure level, especially version control and TESPOD, but project as well, have both an infrastructure component, as well as user experience component, and that there's a lot of specialized knowledge for those. So the lead architects are about taking care of the code and the infrastructure levels and informing some of the user experience, but then largely working with the product owner, project manager, QA, UX, and all of those pieces. So the product owner is an interesting role because it's me when I look at the proposal. I'm like, I don't know who this is. I don't know what sort of person is going to be able to do it. And the description that we have is that they know the functionality of the site front to back. They can prioritize the features. They're gifted at both asking for and listening to feedback from the community, parse out the good points of a large heated discussion, not take it too personally. They're trusted to take feedback and make a decision that people can live with. And they use metrics and data to drive decisions, and they're extremely available. So we've got that. A project manager who handles the communications issue, queue wrangling, the lead architects, what I already covered, a UX lead. So the UX lead is someone who's going to take requirements set by the product owner to an implemented design that discovers the needs of different audiences. And then a QA lead. So someone who's going to be able to make sure that as changes go out, they're going out and have been properly tested and whatnot. So those roles, we've talked a little bit in the process about those roles being kind of a combination of skills that maybe one person could fill different parts of it. And it's really skill sets that we need. And I feel like it'll be most helpful, especially for the software working group. When we start talking about how do we appoint people for these, I think we'll get a feeling that we may need to change some of it or adjust some things, depending on the skills of the people who are actually interested in making Drupal.org decisions. Just to add one quick thing in the background of those roles, if I could. Yes, please. That draft is based around some of the lessons learned that we've found from the Drupal Core initiative. So like in the Drupal Core initiatives, we started out by appointing a person to be in charge of each area. And that's somewhat analogous to Drupal.org in the way it works now, except we don't always have people for areas. But what we found is that actually leading an initiative that, if it's working well, has community involvement and is able to make decisions in a timely manner and all this kind of thing and get features out that don't hurt other people's work and blah, blah, blah, blah, you really do need a team or initiative versus a single person. And so these roles are sort of teased out from what we've seen has worked well in some of the initiatives like the views in core initiative, for example, that is sort of more balanced approach than trying to put all this on one person's shoulders. Yeah, and that totally makes sense to me, too. Any other feedback on that section? Again, like I said, I think there might be some adjustment depending on, you know, who's available and how all of the details of that actually come together. But the basic idea seems to be fairly well agreed. So then we get to the responsibilities section, which is the big to do. And I'm the one who wrote the section that's still in there. We all agree that we need excellent process, but we haven't really talked about what that process is. And I've suggested that we consider nailing a bunch of the responsibilities down with the people who first fill the roles so that we softly put out some suggestions, so that there's some kind of guideline, like if somebody says, I am interested in being the product owner for the developer tools on Drupal.org. What does that mean? How much time does that take in a week? Is it a compensated role? How long do I serve? You know, what are all those expectations? I think there's a couple of recent proposals that look pretty good in terms of beginning details. And that those we can start with those and like work together to define them with the people who will actually first fill these roles so that when we get to that point, we all say yes, this this works. And hand in hand with that is the authority section. And that actually seems to be kind of kind of okay, I think in terms of feedback that we've gotten so far. So they set priorities in the area, the team and clothe can actually say that a feature isn't going to be deployed, which is important feedback for people to understand like we don't want the community or anyone working really hard to try to move something that actually isn't going to go forward. And it's not like that needs that that's necessarily a big bunch of features. But often, there will be people who get really excited about something and don't necessarily take into account the larger picture. And so it can't really be implemented without negatively impacting other groups of stakeholders. And it's that kind of feature that a clear decision like this isn't going to happen can actually be really beneficial. And hopefully in the processing, well, what needs are you trying to meet and can they be met in some other way? But that feedback is important. And then approving work for development and deployment saying, Yeah, this is a great idea. And we should go forward with it. As well as working with the software working group to get budget and staff support for the features that they feel are that the team feels are important. And the escalation chain came up and I'm going to switch screens in a minute to the discussion. But Cameron Wiggins points it out that, you know, knowing how the community can give feedback if things are not going well. I mean, that's my paraphrase of that is important. And I believe that it goes from the community. I mean, that that's covered actually here from the community to the leadership team, from the leadership team escalating to the software working group, from the software working group to the CTO, which is not currently a filled position and from the CTO then to the Drupal Association Executive Director is that chain. And if that adequately covers it, possibly talking in more detail and again, developing that alongside the people who are going to fill the position if we need more detail seems feasible. So what I want to do now is switch to some of the comments and the responsibilities on the to do list and look at those. Because they came quite a bit after we consolidate the proposals and we certainly can still change the proposal and like I'm suggesting, we'll do that in conjunction with the people who stole the roles. So the main issue queue leadership discussion. There were a couple of comments that I thought were really worth taking into account. So the logistics of having people in these roles is really threefold. One is what are the expectations and how much time is that going to take to how do we handle transitions in leadership and three, how do we remove people if things aren't working right. And I for one feel like it's really important to establish what that process is like up front. So people know because typically by the time a situation like that arises and has to be dealt with, it's too late to be making things up as you go along. And I think that had the excellent feedback on both of these. So this thoughts on transition is the most concrete proposal for how to get the commute like communicate to the right people that we have this opportunity to shape Drupal dot org. And so there's some discussion about whether commitments should be one year or two years. And that's something that I'd like to open up for discussion. Once we've gone through this, a two year commitment in the general feeling on two years is that a year isn't really long enough to get to figure out what's going on and actually get things done. There have been suggestions that we just had a yearly review. And I will admit I'm partial to a two year commitment, but yearly reviews so that there are easy exit points because it's a lot of responsibility. And we don't actually know what the financial model is going to be for this. So yearly reviews just make sure that there's a routine way for people to exit and it makes planning easy. But I don't feel strongly enough that I would argue against a two year commitment for the initial thing either. So specifically the year renewal and you can commit to like upping for another year. So you start with a two year commitment she suggested and then review yearly after that and try to have three months in terms of finding replacements. Holly brings up later that it's a good idea to bring people in in a staggered fashion so you don't have an entire team routinely turning over at once and that makes a lot of sense to me. So she broke down here that in the three month transition period that there's a month to find a replacement and communicate information. And I think this is really important because this is what I feel like the software working group needs to act on next and that is communicating information that there's a search for people to fill these roles. Figuring out who we want to reach and about what. So we have that pretty clearly defined now I think. Making it clear why people care. And then the communication plan and one of the things that happens a lot as we try to get organized with the community and the community tries to self organize is that we don't always know how to get people's attention in the right way and if we if they've known to pay attention they care a lot but they don't know when something's really going to happen. So I think this plan makes a lot of sense which is an issue for people to follow. GDO post getting the Twitter accounts and maybe being more specific about which Twitter accounts communicate with whom where. Getting it out in the DA newsletter doing some PR for it. The DA blog or any blog as she points out and then I'm really interested in exploring the possibility of using the tools to get people's attention. So if we were interested in people helping with the developer tools the possibility of like a banner on the issue edit page that's an interesting idea and a little out of the box and I've mentally expanded that into potentially also including a footer on the GDO mail say for jupel.org improvements and I realized like on the footer part of it that there are a lot of people who actually follow GDO by email only they don't actually go to the website from going to the Boston user group and talking to people also the Portland user group that it might be a viable option but making sure that we have a clear plan to let people know that we want them to be involved and then she had some transition time and that brings up an interesting question I think which is ask the outgoing person to spend 50 percent of the time being available to the new person and it's the thing that's unclear to me is 50 percent of what like how many hours. So the plans of if the people's needs aren't being met I think these are all super positive ways of interacting and I think it would be initially that and I'm not sure about this the responsibility the software working group to hear the feedback that something's not happening to know that things are happening and if they're not finding out and investigating how to be supportive and then if someone's struggling but would be better doing some other role finding that and making the adjustments that are necessary and then finding a new person potentially to share that so there at least some concrete steps that can be taken in the event that things are difficult for people. There's the discussion that I alluded to about one to two years and how long it is and I think Tatiana had some great feedback here on the responsibilities. This is the part that I really wanted to pay attention to so specific responsibilities for the whole team being something like reviewing change requests that are opened for the area of the site on a weekly basis giving initial feedback to new ideas within a week participating in idea discussion and helping flesh out the implementation plan and then the product owner as the person who gives final approval to an idea and implementation plan and gives a green light for the development to start providing guidance and reviews during development that would be tech leads on a weekly basis no reviews waiting longer than a week final review of the development implementation and is it ready to move forward and that would be the product owner and is it ready to stage and is it ready for production and that ultimately being the call of the product owner potentially QA as well if there's a strong QA person and Angie's commenting here yeah that the week review time what I like a lot and I'm done going through like this is basically the summary so I'm going to turn it over and open it to discussion now I just wanted to make sure that we'd all kind of seen that the information that we were about to talk about what I like about this is that there are specific like signs that people are engaged or not engaged in their roles you know the week turnaround I like that a lot as well so Angie and everyone like at this point what I'd like to do is just open it up to a general conversation about about what's in here concerns ideas all of those things and then return to the agenda in in 10 or 15 minutes and talk a little bit about timelines and some good things okay great I was saying stuff in chat so I can say it out loud instead but like I'm not sure how go-to-meeting records things so but I think you know I think that well you know I'm a little bit biased because I helped co-author the current draft that's up there but but it seems like there was general agreement I'm pretty much all of it I agree the responsibilities is the is the biggest question and actually like coming at it from Tatiana's description more where it's like here's what you're going to do day to day rather than trying to like come up with you know we do need to answer some of the broader questions to like whether or not this is a funded position and whether or not some these other things but I think by explaining what you're actually going to do in this role it's a good way to weed people in or out based on their interest level and availability and things like that so I think that within a week time frame for all of this to happen is is is pretty reasonable as long as we can stick with it you know I think as a volunteer you know when you submit an issue somewhere it's not like you expect immediate turn around or anything like that but on the other hand it starts sitting for two three weeks a month whatever I've completely like you completely miss the level of interest I had in that thing and now I've moved on to other shinier things so I think as long as that expectation is met I think that's a really great improvement over what we have right now I also really liked a lot of Kathy's suggestions to so in general yeah I'm just I'm really excited about this I think I agree with you Melissa I think we're just going to have to do our best on this to an extent like we don't know what's going to happen we don't know who's going to fill these roles so like we do our best to lay out a framework and then kind of adjust it based on the people who are actually in it and letting them decide you know what works for them so similar to how we did the you know sort of Drupal governance charters it's like lay out the stakes you know that we need like make sure there's in the charter of these people there's like they have to have community involvement you know blah blah blah whatever but then on the as far as the day-to-day and how they working goes kind of let the team you know sort of define that I think once once we sort of lay out the framework so general plus one what key yes is that you pronounce your first name by the way Joachim Joachim okay thank you sorry about that I really like the green light idea because I'm speaking someone's occasionally dabbled on with with doodle customization someone like that I posted you post an issue and you know I've got this idea to improve things and you can reluctant to really get stuck in and do the work until you know whoever's the maintainer for that particular component Eva tells you sorry this is complete crack it's never going to fly or you know yeah maybe and yeah that kind of thing I think would help and like Webchick says you know if it we if it's weeks and weeks before you get any kind of feedback you lose kind of whatever drive and enthusiasm you add so I think that's a really good idea yeah I really like communicating and being able to communicate to people that if you haven't heard back from a week within a week that's too long and you should ask again so that they know and don't have to walk the line that that insecure line of is anybody paying attention to this or you know when my nagging what's what am I supposed to do so like that a lot as well any any concerns about what we're seeing here I think like I can't you said we might find that once we've actually got a team doing this there's there's a gap between you know what we'd ideally like and what's feasible but all we could do is put down what we have now and see how it actually works out in practice and adjust it if we have to I think there were two main concerns that I found in the comments anyway one is well one is something you said Melissa which is you know we've laid out some pretty lofty roles here you know that would be wonderful if this were like a commercially funded operation you know or whatever but it may be really difficult to find people in all of those areas UX QA blah blah blah that can actually commit to something like this so I think you know if you look at Tatiana's list here it sounds like the minimum that we're gonna need is a product owner and a tech lead for each of these sections then maybe we can flesh out the others as either people come along who just are awesome at what they do and it's a matter of saying you're awesome you're the QA or whatever or whether it's a concrete effort to fill these positions but I think you know I kind of you know and to Holly's point about rolling you know not not putting everyone on at the same time it might make more sense to say fill the product owner and tech lead role first and move on try to find UX and QA and and so on this sort of like stagger things a little bit the other concern that came up aside from can we actually fill all these roles is something Cameron eating said which was you know there's there's going to be a transition point the community is not used to being told no on anything right but they're used to being told nothing which is not a no it could be yes could be maybe you don't know or they're used to being told yes so that's going to be the whole fact that under the authority section like close won't fix is is one of the things that a product owner can do I think there is going to be some adjustment to that I think you know and and we just have to be really you know what I said in response to that concern is like if the person in that product owner role is just won't fixing things left and right without any kind of rationale they're not going to be effective in their role and effectively they're going to be removed because people are going to handle that but on the other hand I think a product owner that close won't fix is something with with a very thoughtful reason behind it which is you know here the other things that we have on our on the go if we did this it would make these things 10 times harder so instead of doing this let's do this instead or or you know or I've talked to various people in various different roles and you know this is actually a better fit for what they need or whatever it is I think that that's actually really great because you know to joke his points like you're not sitting there like on a bed of nails wondering if your idea is any good and in this kind of thing so but I do raise that as a red flag is I think there's going to be some cultural adjustment we're gonna have to get used to there you know in core we we have had you know benevolent dictator for life in core committers and stuff like that to come and lay the hammer down occasionally when it needs to be laid down but jupyledorg generally speaking hasn't had that I think that there's some underlying uncertainty about a couple of things that Cameron brings up and I think that they're worth acknowledging one of which is a I believe that there's some historical distrust of how projects have been managed or worked out in the past and I for one feel like this year we've seen lots of positive change and that it takes a while to really be able to explore the DA as a supportive a community supportive organization and the whole like push to have process that's clear to people I think it's a great move and I feel like Neil and Tatiana as the two people who are employees are working super hard to to make that more of a reality than it's felt like sometimes in the past so I'm excited about that but I think there's like some remaining the DA is outside of the community rather than a part of the community and I just want to acknowledge that I believe that that's going to change with time now and that the opportunity to have a less adversarial conversation is totally present so I'm excited about that and I think that one of those things is the governance and having the working group when we get down to where he clarifies that if there's a process for the community to remove someone who's not being responsive whether it's a product owner you know any of those roles really we can clarify that a little more clearly but there is a governance group that the community should be able to approach to express their concerns and so I think that that's going to be a positive thing in terms of building that partnership more clearly related to that and the reason I bring up any of that historical and easiness at all is that there's a plan to hire a lot of staff at the DA and it's very unclear to me how how that would fit into these goals and I'm not sure that I fully understand the intention of the governance document and the mandate to to appoint and remove people whether that means that that's to appoint and remove staff or folks working on a contract basis or what that's a question that I think we really do need to contend with you know for me I would say that's probably the ability to add or remove people from these roles within the leadership teams but I don't think we could like fire someone from the DA like that would be cool but if somebody is is not behaving in a way that's congruent with you know community harmony or whatever I think it's completely valid to not give them a leadership role in the project. Right there were suggestions I guess what I'm responding to and I think that they're fine ideas Tiana had pointed out that some of the roles maybe should be folks who are on staff who are paid. I also believe that is probably the case too like I would love the UX person to be financially compensated whether there's staff or contractor or whatever. Yeah and I am not in any way opposed to that I'm just saying that I feel like it's it's and there's some uneasiness there about how that works if you identify that as a staff role then that means and it's just about what that means does that mean it's okay for the software working group to say well you may be DA staff but you're not doing a good job as the UX lead so yeah sorry about that. I mean it changes it makes things less clear I think. Yeah clear enough that's that's definitely a dicey potentially dicey situation for sure. I think in that case what we would do probably is escalated I guess to the board or something you know like the ultimate escalation chain I guess if it gets like I really think in that situation we use our escalation chain so you know like we would say like this this this person's got to go escalate to Holly who you know holds the you know keys to their employment or whatever and then she can make the call and then if we feel like the call wasn't made properly we can always escalate to the board as well but yeah it's definitely uncomfortable for sure that's why talking about the the what am I trying to say the the terms or whatever that's a good reason to have yearly reviews or however we want to structure it but the nice thing about yearly reviews is they you know give us an opportunity to nicely say oh so and so has decided to move on to other things you know what I mean like without like actually like booting someone out of the community in a really public messy way and a chance to confirm that people are doing a great job for whatever that's worth yes let's let's let's land on the positive side of that yes you might have somebody that's such a great job that they're a lifer and that would be great so one of the things I don't know for the software working group moving forward is how the the discussion of compensation for various positions happens and whether people who are on the call today have ideas about how compensation for filling these roles will impact the the things that happen how that how it should you know one of the things that I suggested is if we're looking at being experimental then filling it with a full-time staff position maybe isn't like the right way to go about it and we can consider things like stipends I question the like financial viability of the site gets divided into even eight major areas how that how that works together in terms of being able to adequately compensate people for their time and whether we want it to be volunteer what that even looks like well if we decide to compensate it money has to come from somewhere so that be I guess software working groups budget so yeah we have a budget set aside we can use it but it's not what the board approved since we didn't think of this before the budget got approved so it becomes a software working group recommendation seriously no we could take money out of our what we would have a future future developments and yeah I think we probably have to go to the board for approval say hey we spend this money on something that we didn't say we would spend it on or you know we can go to the board and say can we have more money so it's a whole process so I would carry that forward as a conversation the software working group can continue having which is how does compensation fit into the mandate that we have to appoint these roles and that's certainly something we can have that discussion I'm in the interest of like agility I would love to get this rolling and try and find people who either through like you know 5% time from their employer or just due to lack of sleeping or whatever can try and do this without us tackling that question because I think tackling that question is going to be it's going to open a big can of worms and we're going to want to be really thoughtful about it but on the other hand we need these people in these leadership positions like now so I'd prefer to defer that to a later time if possible it might not be possible it might be that we can't find someone who can say I'm going to be on so on top of this I can get back to people in a week without the DA's money but if it is possible to find someone who could who could say that we think would be good in that role I really think we should we should try to do that because you know then it's then it's merely in air quotes you know figuring out all of the other things we need to figure out you know in terms of responsibilities and day-to-day work and that kind of thing without also tacking on politics of who's getting paid and who isn't and those kinds of things yeah understood I also feel a pressure to move these things forward because we have lots of questions and things you know coming up in the in the year ahead of us that does lead me to the the other thing that I wanted to be sure that we discuss and that is how long do we need to let the community know that we are looking for people for these roles and for them to indicate their interest what's a reasonable communication time and I'm actually I know that the Angie you and I have talked about it but I'm curious from the other folks on the call how long is reasonable for getting this started because of course it introduces a lot of latency into the process if it takes two months to to have that call open so and I'm thinking about it in the cotton and plan that Kathy put forward so if we communicate through those channels how long before it's reasonable to to appoint people can you hear me now Angie I can hear cut out a little bit for Oh Jeremy's here yay and who else has joined Jay I haven't had the list open welcome so my guess is if I if I made a proposal that said one week is long enough that that would be a bad idea and it's not really long enough but I don't know how long is I feel like I hate to say it but I feel like a month is probably what we would want and let me just clarify why that is because ideally we could include well for one thing Christmas is coming up in the last two weeks of December kind of a write-off for getting anyone's attention but the second reason is ideally we could like you know leverage the local user groups as the communication vehicle for this but that's only a happen if we get the word out in a way that they can process so a tweet of front page post a Drupal planet post a Drupal Association newsletter thing like you said and then specifically ask local user group meeting people to do that and then basically from now until a month from now would give enough time for all of those people to have a meeting um I would rather not push it that long so maybe in them you know given the urgency of the situation we do a two week cycles but you know basically if we do a two-week cycle we're into the last two weeks of December so I think we're out a month regardless of what we do and so it might be nice to we talked during previous discussions about our ideation process wanting to also use the local user groups as a communication channel for that we could experiment with that you know for this thing and see how it goes um and then you know as we have the next position and the next position in the next position hopefully you know get that chain working really well so that the next time we do do a huge community driven ideation process around Drupal.org we have the kinks worked out of that process yeah and realistically in order to ensure user group involvement based on the on those that meet monthly we have to tell them in December so that they have all of January to execute since some people meet the first week of the month etc right and so they don't find out in time then they won't be able to act on it but I think that that may not not be completely necessary for the very first time that we try it if that's what you're saying Angie that we say open things up now and try to today's the 10th of December so if we try to have at least a product owner and tech leads is what you'd suggest it identified by the 10th of January yeah I think that kind of a month announcement out today then I think yeah that would be a good goal and realistically the announcement probably won't go out before Friday why don't we make the date then January 15th which is Drupal's birthday but I guess that there's there's a couple of things right so one is we need to put the announcement out that we're looking for people secondly we're going to get hopefully more than one or more than zero I'd go for more than zero hopefully we'll get more than zero people saying hey I would like to do that here is my qualifications and yada yada and then we're also going to have to allow a process for the software working group to kind of meet and decide who of the cat you know of the candidates if any of them we want to fill these roles so so I don't even know that we can do that by January 15th feels like that's realistic to have a list of names to talk about but it doesn't feel like it's realistic to make the decision the end of January probably feels more realistic to make the decision and cringing as I say this because I know we need it now but I'm just trying to be I don't know I feel like we we need to be thoughtful about it's great if we do it before the end of January but I think the end of January is probably the soonest that that would happen does anyone agree or disagree with that I guess the things that I think when I think about that is how things move forward in the interim and as long as things are moving forward and we're not frozen on our ability to act on things that need to be done which I don't think we are like I don't think Drupal.org is the we I'm talking about is going to be stagnant on all fronts because this hasn't been done yet and so my feeling yeah my feeling is the next month is going to be nothing but bug fixes anyway realistically maybe a minor feature that the community pushes through so our real need for this role happens after we've sort of worked through the follow from Drupal 7 upgrade which to me doesn't feel realistic to do much before January 1st anyway I don't know if I'm wrong about that but we still have a couple of pretty severe critical bugs in the D7 QA. Anyway those are my thoughts someone else's please have thoughts. Yes yeah yeah that's true. Sorry I was I wanted to say something like this upgrade of D7 is something like a short don't think that I don't think we should try to fix you know the team or people that we are thinking to appoint the team it's something like there should be a you know might be that that might be a step one but we should have a step zero which is writing down the vision of the project you know like it's kind of thing we're gonna run and this is something I spoke with the web chick in Prague as well you know kind of you know rather than just looking at community what they want exactly we have a lot of this you know like a triple that are kind of tools like a GitHub and all these you know stuffs like that I mean it rather than the public opinion like if we know by a product out there which are successful if you can come up with a plan and if you can write down the vision of it and then if you find the people to satisfy the vision that would be great and then we just look for people and appoint people and whether we're paying or not anyway they're going to spend time on it and then they will find the vision if that makes sense I don't know yeah that something we've talked about doing in the software working group and I think it's on our schedule to talk about more but I don't know if we have a specific plan for that and I know the content working group is also doing a whole I study on like what is true about work without the more work I think and users rather than developers yeah and I think what you said makes a lot of sense and the first thing I try to do is figure out what are the concrete steps in achieving the definition of a vision yeah I mean the one thing is what I mean what I'm hearing what I'm reading is we are trying to kind of cover all the suggestions are kind of make the community the people using the trooper.org day-by-day feel comfortable and you know feel more like you know like feel like a home but but if you have a you know bigger vision that covers more like industrialized tool then I think that all this community you know like all of you know it covers all other expectations as well so I don't know how to put this one I mean I I never know github like you know that last year and I started using like one year and I feel like more come more you know like a more comfortable so it's more like a building like building the proper tool that definitely solve all the problems but I'm not saying that we shouldn't take any suggestion from the community and we just go by our theory definitely we have additional community suggestions but we should go with something to ask for suggestion. So Vijay can I can I try and paraphrase what I think you said because I'm not sure I totally got it but I just want to see so I think what I heard is like the the governance structure that's being set up here is all well and good in that it's going to bolster the current tools and it's going to you know allow the community to feel like they have a voice in the direction of those tools and so on but it it may not be the right vehicle for actually deciding whether or not Drupal.org is the best vehicle for our development process in the first place and that we're not likely to make bold tools decisions with an organization structure like this that we're probably going to stick with the status quo and that that might ultimately hurt Drupal in the future is that what you're saying? Yeah I mean kind of I'm just trying to say I mean you know but like I think you people know better than me because most of the time I feel like sometimes I I may suggest something which might I know it's wrong but for some for the sake of discussion and for the sake of I was in a wrong set I want to prove it right and this happened you know by history that happened quite a lot of places and I'm just simply trying to put like yes some some you know like some things these things need to be discussed and it needs to come from the overall discussion but it's not like the whole you know like it shouldn't be like you know like we shouldn't move as a whole for all this for this discussion because I may be involved active for a month and I may say you know like a put and I may I may put my points forward and I find try to find people you know like to support my opinion and after sometime it might not be valid anymore and I may not exist in the community but the people coming after me just need to bear what I suggested which may not be that appropriate. So I think what we're trying to do here is establish a decision-making structure so that when people like you have suggestions and they have merit that there is someone to hear them and someone to like basically organize those thoughts in a way that's like more accessible to people than finding random comments on the internet in various places so the intent of this is that once we appoint this product owner role that they would be the point person to basically with you say I really think that Drupal.org should do this or I think that our dev tools should do that and here's proof of concept I did or here's not a proof of concept they did but here's how Juma is doing it or whatever that kind of thing. Right now there's no one to really hear that and make a decision about it right now it's just so what happens a lot of people exchange really heated opinions with one another about how things should be and then the whole thing just kind of dies in sort of a crater of smoke right because there's like nobody to take that and say okay so based on this you know conversation that happened here's what I think our next steps are you know and jubilee south working with trying to do this a little bit but it's not really within our charter really it should be the people who own the development tools who do this and us sort of guiding the process. So what I think we're going for here is a way is a way to better get those kinds of suggestions and actually act on them or not act on them like some suggestions I don't think we'll ever act on like the idea to force all people to go through a rigorous code review process in order to share a module at any time I don't think we would ever do that personally unless there was tremendous research that showed that was the best thing we could possibly do but right now there's no one to say yes or no and so these things these ideas just sit out there and they sometimes some of them make people angry some of them like you know make people feel like there's huge unresolved tension these kinds of things so the goal is to get people into these positions who can actually cycle through all those over time and say yes that's in no that's not and here's why so that I think what can help then is getting everybody on the same page but where we're going and you know also giving an opportunity for when someone does have a crazy idea about like all this could be so awesome if you did this there's someone to look at that say oh that is an awesome idea yeah let's totally do that you know or encourage people to kind of do it themselves so that's sort of the framework we're trying to set up here I do hear the concerns that we're probably going to tend towards the status quo a lot more than like sort of radical ideas and I did I share that concern I think you know I don't I don't actually know how to get around that myself but other than just being very conscientious about monitoring what other projects and stuff like that are doing and making sure that if our time does come when it is you know the right time to say yeah we should cut our losses and go that there be someone in that position who can make that choice so we're right at 903 I'm perfectly content to have further discussion but I want to make sure that we're respectful of people's time who planned on this not lasting more than an hour and I would sum up right now that we've basically said that the suggestions that were put out including the comments that Kathy had specifically about process are something that are good enough as a draft to talk with the people who will fill the roles about and make more concrete before anybody makes a commitment we've discussed that the timeline for saying we're looking for people would be getting an announcement out by this Friday leaving it open until January 15th and making a decision about people by January 30th and that we will prioritize looking for product owner and technical leads potentially and if other people come up great but we don't feel like we have to fill all of the developer tool roles at the same time helping to stagger the commitment we have also discussed sidelining compensation issues because there are so many things to be discussed that one that will probably come up and we will learn more as we look for people and it will need to take that into specific consideration but that we probably can't solve it in time to actually get people into these roles does that sound like an accurate summary of where we are I think so the only other thing I may be out of that is we should probably do one more draft that incorporates the the more specific responsibilities and stuff suggestions just to you know just so we have sort of like a document to point people at who actually want to go for some of these roles that sort of been yeah I actually assumed that need to be done by January 15th or by December 15th so that when we said we were looking for people that we would need to do that so yeah thanks for making that explicit but yes I agree well I do have to hop off but thank you so much everybody for joining and for the discussion and all the feedback and the issue in the earth sorry the group discussion as well it was really great to see folks you know sort of trying to hack on process for a while and and you know set us up to be in a good place so we can you know make jubilator awesome so yeah and thank you Melissa for for spearheading all this and leading it and organizing the call today and everything else it's that's really really awesome yeah thanks to to everybody who joined us and if you have feedback along the way I don't think that it's too late to incorporate things or be thoughtful ever so I hope that we can keep and improve the lines of communication between the folks who are using triple dot org and and the software working group in what it's trying to do and then you're moving things forward so certainly you can reach out to me and to the working group because we will be able to figure out at least where to route things now so don't hesitate to find me at least I can speak for myself and IRC or my contact form you know or in the issues if you have new ideas things that occur to you okay awesome thanks everyone