 So, what I want to do is first go through how many of you have read the blog series that I've been kind of working on about, okay? I'm going to go through some of that material because I think it's a good starting place. And then we're going to get to what the issues are right now in the Drupal community and just kind of walk through those and your input is very welcome. And then I'd like to do a little brainstorming about what you think we should do and I'd like to come out with some concrete ideas of how we can build going forward. In other words, what I'd like to have be the outcome of this today is not, we're not going to design Drupal's new governance today. That's not, I'd like to come out with a concrete plan though that would put into place something that would help us to build more structure into our governance that is in line with our culture. So, I would like to come out with a concrete plan and I think we can do that in this time that we have. A plan to build a plan kind of thing, right? So, what's that? Planning to plan. Planning to plan, yeah. We can bike shed about this today but no smoking craters, that's right. So, the actual presentation is hidden by this little slide thing here but it's lb.cm slash governance and that is writable right now by everybody. So, if you see, especially as we get to the end, if you see something that we need to add to that you're welcome to but you probably don't have to because Melissa agreed to scribe. So, she'll be adding to that as necessary especially those later slides where we try to write down what we're thinking as a group. Okay, so I have always avoided kitten slides but now I am one, right? They were just too good. So, I just want to say that no matter what problems we might have the idea that open source communities are able to create incredible things through voluntary collaboration of people all over the world is absolutely astonishing and it has to be one of the greatest things to happen in this world in the last 30 years. I mean, do you read about that in the newspaper? Does that go up there with Iran and nuclear threats and stuff like that? I mean, it is as important as Iran and nuclear threats on the opposite side and you're involved in that and that is absolutely fantastic. I don't think that anybody should take for granted the idea that we are already collaborating and doing beautiful things. I want us to do it better but we're already doing beautiful things and all those other communities are also doing great things. So, if you don't know what governance is, it's just a fancy word for how we make decisions, how we organize ourselves, how we plan together, how we make a decision when we make a plan and of course how we resolve conflicts. And if you know anything about government in the country type sense, you know that governance as an institution only works as well as the culture behind it works. And in your own country you have probably seen some issues with that. In the United States we have these culture wars that have brought our government to a halt. It's a very disturbing kind of thing but culture and the formal structures of governance have to go together. And so, as we think through these things, we always have to keep the culture in mind because the governance is just an afterthought if the culture isn't working. So, I know that we all value our culture and that we'll all be thinking that way but that is a critical, critical idea. So, culture plus process. Governance lets us have some consistency, some idea of what's going to happen when and why it might happen that way. It lets us accomplish shared objectives, it lets us resolve conflicts and do things more efficiently. I think that we can just keep going forward. So, I put down a list as I was studying various open source communities of some of the distinctives that they have and how they work. Each one has its own culture and of course we all know how we value ours. Some of them have a membership concept so we don't have that but Debian and Ubuntu have a very, very specific membership step where you become a member. Debian has a developer step beyond that which is the commit privilege kind of step which is very interesting. A lot of cultures have a founder who has kept the dictator role. If you laugh when I say benevolent dictator for life, which many people do when they first hear that, it's actually just kind of a standard statement. It's like it's already, it's something that's used widely in the open source world. Some of these have a sponsoring commercial entity which we don't or at least we claim we don't. And some of them have really defined structure and leadership and some of them have nearly nothing. So, we'll just take a quick look at some of them. Debian is absolutely amazing because if you read their many governance documents, the first thing they say is like, nobody can make you do anything so there. That's like the first line of the Constitution. It basically says nobody can make you do anything. If you don't want to do anything, you don't have to do anything. But don't be in anybody else's way is what it basically says. It's like, wow, okay, and so then they go on and they have this enormously structured governance that goes into great depth and it seems to work pretty well. They have a social contract. They have a philosophy of open software. They have a constitution. They have positions and they have elected leaders. You probably can't see this very well, but it gives you some idea of the hierarchy and who makes whom. They have a project leader who is elected who's not there forever. It gets elected every, I don't know how often. They have teams and secretaries and just, it's just fascinating. It's very, very impressive. KDE, which is smallish, has nada. They're like us kind of except that we have trees, but they basically have just do it. They have a rule. We have some rules like we call ourselves a duocracy. They probably call themselves that too. They have a rule that says that if you're doing the work, you get to make the decisions. They're a smaller community and they do occasionally have deadlock like we occasionally have, but they have no way out of it. They have one committee whose job is if somebody gets really mad, there's an attempt at conflict resolution. That's about it. If you go looking for governance on the KDE site, you'll find about as much as if you're looking for governance on the Drupal site. You just won't. I probably mentioned that I searched the internet for Drupal governance. All I found was this thing at DrupalMyths.com that denied that Drupal had little governance. That does have something to do with the word governance, not being necessarily the word that's used in all cases where we're talking about governance, but it's still pretty funny. It's like the only thing you can find is something that denies that you don't have an issue with that kind of thing. Wikipedia, which you can think of easily as an open source community. It's just that the source is content. It hasn't been ever dictated for life, but interestingly enough, even though he's like this super funder, founder guy, his prerogatives have been limited over the years. Of course, they have quite an amazingly large community, and his role in it has been occasionally controversial. He or they or something have actually rolled back with specifics what he has the power to do. It still has an impressive set of roles, but it's very interesting to see that. They have a constitution, but their big thing is solving conflicts at the page level. Have you guys ever seen one of those big conflicts on Wikipedia where the George Bush page or something like that, where everybody has a different opinion and they have to sort it out? They've got that particular issue of governance sorted out to where they have the technology to do it on the talk page next to it, and they have the procedures to do it. I just think it's very impressive that they've worked that out at that level. Ubuntu has a very, very impressive level of governance. Of course, we and KDE and everybody else you can think of have snarfed their well thought out code of conduct. The Ubuntu code of conduct with minor changes becomes the Drupal code of conduct, except that we don't have any of the structures that they use to resolve conflicts and that sort of thing. We punt on that part. They have a benevolent dictator. They have a commercial sponsor like a lot of the communities. A lot of people will say about WordPress or about Ubuntu. Oh, it's all about canonical or it's all about automatic. It's absolutely not true as far as I can tell in either case. Both of them are very established, very functional, and I would imagine also dysfunctional open source communities. But they both seem from a casual glance from the outside to be very, very functional, well thought out, and real open source communities, not puppets for some sponsoring commercial organization. I think I've heard that many times said about WordPress.org, but as I read about them and watch their videos and stuff, I don't think it's true. I think that they are a very established open source community. Ubuntu has the membership concept. It has community manager, Jono Bacon, who's one of the very widely well thought of thinkers in the governance and community and community organizing view that whole world there. He has a book, by the way, and there's the reference to the book. It's a free book. The reference is on the blog post. His book is well worth reading, and there's a full chapter on governance and a full chapter on conflict resolution that are very well informed, very well thought out. Ubuntu has specific conflict resolution because they have a way to do it. They have a technical committee that can make technical decisions, and they have some kind of a community committee that can make community decisions and solve those kind of things. WordPress has a sponsoring commercial entity, has a real community, and has a very specific org chart with lieutenants and that sort of thing. If you've been around Drupal for very long, you know that Dries has a very, very light touch, and that's one of the characteristics of our community. I think it's a defining thing that is a part of why our community is what it is. I think it's a beautiful thing. Matt Mullenweg is very explicit about directing. He's very directive. He says, this is what we're doing. Get to it. Basically, they say to new contributors, hey, you know, like, if you don't like what Matt wants to do, you might want to go to some other community, which is a perfectly reasonable thing to say, but a very different style than Drupal. And of course, the Linux kernel is the most famous of all open source communities, but it's kind of a narrow kind of thing. Like, I don't think that I could get a patch into Linux kernel without working on it for a few years. You know, get yourself into there. Has anybody done any work on the kernel? How did it work? So just to get a fix in that's obvious was that it was clear how to do it, but it's like patches in a mailing list, stuff like that. You know, it's very different from our huge community with lots and lots of people. I get the impression it's more vertical, most of the work, you know, especially features. Okay, so then there's us and we're a lot like some of the others. We have the benevolent dictator. We have a tradition of gentle leadership or cat herding only leadership sometimes, where we have leadership a lot of times it's only rather than leading its grouping or trying to get people to do things or that kind of thing. We have the new initiative lead experiment, which is a great new step in core development where we have some lieutenants. What, five? Five lieutenants? We have some lieutenants who have some kind of leadership invested in them and we don't exactly know what at this point, but there is some kind of leadership invested in them. We have words that we use like consensus and like duocracy that are very important, but can mean a whole bunch of different things. Consensus can mean that anybody can block any issue. It can also mean that you can do something if nobody's looking. Duocracy can mean the very, very empowering sense of if something needs to be done, I can go do it, which is very powerful. It's a wonderful thing. It's a suckered me into quite a number of problems. I look like this one. Yeah, because I can propose a core conversation and poke at our governance structure and I think it's important here I am. We have the Drupal Code of Conduct, which says a lot about our culture, but has no teeth because we don't have much governance structure. It was a trial balloon and it stayed up and it's there at Drupal.org slash DCOC and it's the same as Ubuntu except that we don't have really any way to institutionalize what it says. We don't have any conflict resolution model at all. There are a few people who try to solve problems. Our most famous one is in the front row on my left. Acquia explicitly names itself as not a sponsoring commercial organization and that's probably a matter of, you know, it should be conversed, but I don't know whether, I don't think it probably has to do with this conversation today, but it obviously drees with his agenda as project lead and drees with money at his disposal in the office of the CTO probably has a specific power that nobody else has and that doesn't need to be viewed badly. The Drupal Association, a lot of people think that the Drupal Association is Drupal's constitution or governance or whatever, but it's just not true. The Drupal Association does have governance itself, but it is in charge of money and it's in charge of events. That's it, right? Well, that's money, right? Money because of only infrastructure as it has to do with money. So the Drupal Association can affect the Drupal community by where it puts money. That's very similar to Acquia because Acquia gets to choose where it puts money. It can have an impact on the community, but the Drupal Association is not Drupal. It is not the community. It is not the development community. None of that. So that's a little hard to sort out. It was only like last year that I realized that. So yeah, yeah, Joseph. So the question is, does the DA control like our actual Drupal.org or the association, that I'm only in so much as they fund the servers and they put some funding into the care for the servers and they put some funding into new initiatives. So yes, they could turn it off by not paying for it, but essentially know if they got weird, we would just figure out a way and it'd be gone. It'd be out of their world. So if the DA got dysfunctional and started saying, hey, Drupal, you better do this and such. Well, the community can just change. It's not likely to happen. But I'm speaking true, right? Yeah. You want to say something? You say it. Just on the topic of the Drupal association, because I'm on the board of the Drupal association. So the Drupal association explicitly in its constitution, whatever you call it, does not control the project, does not control the community, does not do any of that stuff. We try and just basically handle the things that have to be handled by an infrastructure or an organization with money. DrupalCon is really hard to get a bunch of scrappy developers together and like, let's just pool our money together and get like $800,000 and throw this huge event. Sorry? I'm sorry, yes. So we basically try and limit the powers of the DA around only the things that the community can't rally around and do themselves. And in terms of Drupal.org, I have a talk tomorrow about that. And we're edging our way into helping Drupal.org more because this is what we're hearing from the community and we want more support, but definitely not a we control the project kind of thing at all. We pay for the servers, but there is a huge infrastructure team of like 30 plus volunteers that maintains that stuff. And we fund certain initiatives like the Git migration, the Drupal.org redesign, again, things that can't be sort of done through a grassroots mechanism. Thank you very much. Okay, so before we look at some of the oopsies about Drupal's governance situation right now, we need to acknowledge what is absolutely fantastic. And I mean, we're all here because it's absolutely fantastic. We have, you know, like I was saying, it's a duocracy. You have this preemptive power vested in you that if you can just figure out how things work, you can just do it. As we said before, it's worked a long time. We have a great community. And we have this effigency I pointed out in the comments on one of the blog posts that we have this culture of peer review that we should never lose. Whether or not we add structure to the peer review is great power. And of course, multiple minds working on something it can mean designed by committee, but it can also be fantastic in resolving things in a wonderful way by people collaborating, really actually truly collaborating. So now I do have a list of problems as you might have guessed that I would. As with any place where everybody can do their own thing, we can often have a lack of... And by the way, you're welcome to add to this list and we'll just add to it. There can be a real lack of strategic focus as the kind of person who gets suckered into just working on what he sees is a problem. I used to do that in core a lot. Every time I'd come to a bug or a thing that I didn't like how it worked, I would take that on and I would open an issue and I'd try to make a patch and all that kind of thing. Well, is that strategic? No. Can it be useful? Yeah, it can be useful, but it is no way strategic. And everybody working on what they think is the thing is not strategic. The lack of predictability for contributors, just thinking in the same context, this isn't just true of core development, but okay, so I would take on those core issues and hack at them and it could take a year to get a single stupid thing in because you've got to get somebody to pay attention to it, you've got to get it reviewed, nobody else might care. You just have all these... People often work on projects, especially in core development, for a really long time and then either they finally get it in and they're exhausted or it still sits there. So I have plenty of issues that are just sitting out there that just finally got ignored. And that's a terrible thing for us to waste. So another critical problem is the problem that we have when what we call consensus doesn't happen. We have a very poorly defined idea of consensus and it includes anybody who shows up can block progress and that isn't a very productive model. So we have a list of bad things that happen when consensus doesn't come around. We can have nothing happen at all, we can just stop, we have feelings hurt and contributors leaving the field. That happens fairly regularly. We have people wasting their energy and then we have the absolute ultimate web chick name, Smoking Crater Syndrome, where the feelings just get too high in the issue and nobody wants to stay. And therefore again, nothing gets done, which I think one of the critical things that we absolutely have to do is when we have a problem in our community that needs to be solved, we need to solve it and not abandon the field because our model of dealing with it isn't adequate. We need to actually solve those things. Of course we don't have a conflict resolution methodology which is the same thing I already said, wasted energy and the loss of important people because of the heat. So just to say a little bit about my own personal experience, which I already have, I got here kind of by accident, it's a duocracy. I was talking about burnout at the last Drupalcon and thinking about the causes of burnout and what causes us to just burn through contributors. I think it's our perception that Drupal is worse about that than some other situations we've been around. It may or may not be, but the comments that came out of that session at London included the fact that people spend too much time, governance-related things, that we can't solve problems, that we can't enable people adequately, that people end up too scattered and that people who are willing to give end up being asked to give too much. Those are all governance as well as culture issues. And so that started pushing me toward thinking about governance as it relates to our burnout syndrome or culture. The second thing that happened was this fall that I got involved in a couple of conflict resolution mediator type situations. And those are always satisfying on the one hand because if you're successful, then people aren't mad anymore and some of us are very sensitive to people being mad and we really would like them not to be. But there are probably things that could have been resolved by simple governance structures that would already have worked in our culture and not need an intervention from a mediator type of thing. Plus the mediator in that concept like that has no way, there is no governance structure, there is no conflict resolution methodology. So if you fail, you fail. And there's no place to go from there. Yeah, feel free to use the mic because it's that way people will be able to hear it. Hi, I'm Forrest Monster on Drupal.org. Randy, when you say that we need to solve problems when they arise, does that mean not abandoning them? Because I guess sometimes with some problems you just let them go and they go away. Can you tell me more about... I don't know, maybe you can comment on that. We need to solve all the problems. Yeah, so that's a great question. Is it totally legitimate to just let a problem exist? Yeah, the thing that I'm concerned about is that we have a culture that can walk away from problems that must be solved. Not all problems must be solved. I'm worried about the ones that must be solved and we have lots of them. And a lot of times we don't get them solved because of this whole thing. Yeah, you betcha. Okay, so we don't have much support infrastructure in the Drupal world. We started out with forums because Drupal itself has forums and we have a few people who carefully maintain the forums. But essentially people who come new to the Drupal world have a really difficult time finding an organized level of support. There are a number of solutions to that, probably. But due to the level of conversation and stuff, it's been a very long time and we haven't been able to even punt and like say, okay, well StackExchange is doing a good job, let them do it, kind of thing. So that's an example. Another example would be the full project application process. We want to have new developers in our community. We want to make it easy for them to get in and we want to instruct them on the way in. But the only structure that we've ever come up with is unsustainable. And we haven't been able to make a decision that would make that sustainable because we're just basically like this. And so we haven't gotten it, even though we talk and talk and talk. At every DrupalCon we have a talk about it and we try to solve it, but we haven't actually solved it. We have 400 in the queue again or something like that. So those are a couple of examples. Yeah. So right now, number two points that Jeremy just made, Jake Thorson, who is like the man who is trying for a technical solution to this problem and has been. And it's how he got sucked into many, many wonderful things. Yay! The two things that Jeremy said was that notice that there's no plan stated publicly to talk about that at this DrupalCon. Oh dear. Okay. Which is another one of those... We're not dealing with it because we couldn't. Which basically means we're telling everybody we don't want you implicitly. So those are some examples. So those are good enough examples. So yeah, yeah. Okay. All right. So we do have risks of change and we have to take the change seriously. We have to work this through and be aware because our culture is of value to us and governance doesn't get better just because you wanted to. It's got to work with your culture. So we could offend people with increased formalization. We could have full bike shits about formalization. I'm sure we could. Formalization or increased process, however you would want to say it, I actually am not thinking that we need that much in the way of formality. I just think we need a little structure that we can do a lot with that. Some people might become passive. They will take care of it kind of problem. So we have a duocracy and right now if people get involved in the community and they start to realize that they can just take over space, they do. I'm actually not sure that we have to do anything about that either. I think we might be able to just leave that. Our problem is where people try to take something over and they can't. For example, if we had probably had we not blocked the full project application and if we said to Jeremy, look, we're failing, just solve it, then we would probably have a solution. His solution is a technical solution that got blocked on some things but if you said to me, just solve it, I would. I would just say, okay, for now, we're letting everybody in. And I'd probably put a little bit of social structure on that but I would just say until we have a technical solution we will increase our training level and we'll let everybody in but I can't do it the way we're set up. So in other words, I don't think we need to get rid of the duocracy. I think our problem is when we block the duocracy which I had never really stated that very clearly before. Our problem I think is when we block the duocracy. So in the two examples that I just said, there are at least two reasonable proposals that would deal with the support issue perhaps and they would work in a duocracy. The problem is they don't work where we block them. So we don't want too much process. We don't want, oh, effigency is about to speak. We bow down. So I just wanted to give, I think those were great examples where, you know, formalization. Come a little closer into the mic. I think those were great examples where formalization and empowering people to make decisions would empower duocracy rather than blocking duocracy. One counter example is I think, you know, the initiative lead structure that we, you know, it's an experiment, right? But the initiative lead structure, one of the unintended negative side effects from it has been that a lot of people have felt like, oh, there's an initiative lead in charge of that. I don't have to get involved. So, and we're trying to figure out how to deal with that now. Okay. So, so Alex is saying that when we have added lieutenants, we're kind of letting the lieutenants do the work, which is a, which is essentially, that's the whole thing of they will take care of it. So, yeah, Angie. In addition to that, well, you said you don't think they will take care of it as that bigger problem, but you noticed also that the conflict resoluter for our community was sitting on your left. I don't actually want that responsibility. And I don't actually want to be involved in the center of every conflict and everything, trying to make people hug. I mean, I have many other things. You got conflicts of your own. I know, I do. And sometimes I'm in the middle of the conflicts and that makes me really in a really bad position. So, you know, I'm not against formalization, because, you know, about that, I think it would be great if we had, I think our number one thing is you nailed it. It's we don't have a conflict resolution. Our conflict resolution is literally to do, write this later, pretty much. The second thing, though, another negative consequence of the formalization of initial Bs that we know has happened is in Drupal 7, it was 1,000 people that all had direct access to Dries and I. I mean, you know, give or take. There were definitely some more equal than others based on their level of contribution, but essentially, you know, I could probably name four or 500 of those thousand that I, you know, oh yeah, that's the person. You know, formalizing initiative leads, which was kind of our first experiment with, you know, putting some structure around Core Development beyond, like, just identifying maintainers and maintainers out of text was, you know, really a scaling Dries problem. It was like, Dries wants these things to happen. He's going to appoint some people to, like, go figure it out and I trust you, and then, you know, kind of, that was the theory, right? But the negative consequence of that is a lot of the Core Developers who are not good at cat herding and are not really somebody that you want in charge of, like, helping other people who are on board and stuff like that, because they're much better just, like, crank out code. They felt really disempowered by that and they felt really threatened by that and they felt really, like, that there's been, I mean, we had to hold a big fireside chat in December to, like, break that myth. It's like, no, you don't have to be working on an initiative to make a difference in Core. Work on your stuff, you know, like, anything you want to work on is still great. We still have the duocracy model. It's just that these things are strategically important and Dries wants to make sure they happen and there are people on it to focus on it and try and communicate out to the community better what's happening in Core. So it's my nervousness around increased formalization is that every time we've tried to do that, we've, like, it's been really hard and it's had actually really negative consequences on some other things. Now, I think on the whole, this was a good thing, but I think there has to be some amount of buy-in from people that this is what we want to do because the negatives, I think, are a little bit not well explained here. They're very serious and we really have to, you know, be concerned about them. So, Greg, in his talk yesterday on what the learning about bike shedding, which was excellent, talked about ways of improving process without adding layers of responsibility. And so, in a sense, you're saying that there's huge consequences of adding layers of responsibility because people feel disempowered and stuff like that, but that's not the only thing that we're talking about here. So he mentioned time-boxing an issue, okay? So time-boxing an issue saying, this issue is important. We are not going to let it die. It must have a resolution by a certain time frame is not adding a layer of, so there's all kinds of finesse that we can do in our structure that is not just adding lieutenants and sergeants and all that kind of thing. It's more committing to deal with the things that we ought to deal with and making sure that they don't get blocked by our own culture. So, you know, time-boxing perhaps enabling somebody to make a call or creating a way. So in the issue queue, for example, you've got an issue and the degree is a community how a deadlock in an issue is to be handled then we have a way to handle it. Sure, we can empower somebody to call it. That's one way, but there might be other ways as well. Kroll. So on this same topic, whether it's formal or informal or whatever, a large part of our problem is, as you said, is responsible for something either as an initiative lead, as a subsystem maintainer, as documentation lead. Whatever their role is, however formal or informal it is, we don't have a cultural sense with that area of responsibility comes the authority to do it. And I know people hate the word authority, but if the documentation lead says we've looked at it and we need to do X for documentation, we need to be able to say documentation lead has said we need to do X, I'm going to trust their judgment on this or I may disagree, but they are the person in charge of this, I'm going to let them do their job. This is one of the biggest problems with D7 UX, that we hired professional designers and UX people to say look at Drupal and come up with a UX revision and they ran into a wall of knives from people who didn't trust them to do what their expertise was and what they were hired to do. And a cultural gauntlet I'll throw down is figure out what area it is where you will defer to someone else who has more expertise. If you do not have such areas, you are doing it wrong. Whatever they are, you'll defer on code issues to these people because you're a themeer, you don't deal with deep code, maybe it's the other way around. I don't know markup. As a module developer, if you're a front-end person tell me what markup you want and I will do it and I will trust you. We don't have that attitude of there's people with expertise and therefore they are more important than me, their opinion is more important in certain areas than others and that's different for different subjects but that is something we don't really have that trust of other people in certain areas. I agree that we should acknowledge leadership, we should allow for leadership and we should accept it. I think we should embrace it. How we do that, how we avoid too much authoritarianism or whatever is another thing but I think we should allow for leadership. We sometimes talk about ourselves like a meritocracy and sometimes we've tended more toward the duocracy word in recent years but there's a reason to let somebody who is respected I mean essentially we let Angie do anything she wants because she deserves it right? Anything she wants to do she can do, she deserves it. Well, she shouldn't be the only one and she shouldn't because of that have to be the only conflict resolver and she shouldn't all these things that have accrued to her are actually an over example of what should be happening throughout the community where the kind of cred that WebChick has should be spread throughout the community explicitly and deliberately that be my opinion. Chicks, go ahead. Just as you were talking about time boxing and issue cues it reminded me a proposal that Robert Douglas made six years ago or something that one way to deal with issue cue abandonment is to make it a cue right now it's just a dumping ground but if you make it a cue where things go first things go in, first things go out so if you want your patch to anything to happen with it you need to look at you need to have those that are in front of it just reminding people that there was a if you're making plans of plans then changing our culture about how we deal with code and the issue cue is an interesting thing we still have 12 minutes right I'm not confused we're okay no because I really want the key thing is I want to write down some paths forward I don't want to minimize the fact that needing more governance is a good thing that means that we've succeeded okay we've done really well and I don't want to I was very much touched by what Eflgencia said about the conversation and conflict in the issue cue is not it can be very very positive so how do you like that kitten picture huh so I'd like to make a list let me flip back to where let me flip back to where we are here and let's see what if Melissa has added to things so that we've got so that we're together on this yeah okay the I wanted to take a look at this slide and see if we have things to add to it way too often and this is actually one of Dree's problems when he thinks about when he thinks about governance is all he thinks about is core development governance that's it so you're shaking your head no so I must be wrong what's that okay it's totally not true so forget it cancel it I'm wrong she knows him a lot better than I do but every time I hear come so just forget that strike that what I want my point is let's say what are the areas the Drupal community is a lot bigger than just core development what are the areas where we need to have a little have something more than nothing so core development is one place contrib development is a place infrastructure security has a bit of governance which is interesting there's a bunch of implicit governance in how we do security and that's well thought out but it might not be stated explicitly enough yeah so the most important role in the security team is a decider of deadlocked and you formally have that so Greg is it so you've invested Greg so they have much more sophisticated governance structure okay yeah so I've noticed that security has a relatively has a relatively well thought out model that you could call governance yeah Angie okay good look she says it and it appears that's amazing security site function and content you know I would love for Drupal.org to have a leader who was actually had a plan for what it ought to be in a year there's probably more than one way to do that but one reason that Drupal.org is a morass is that it isn't really owned it isn't really owned by a group that has a plan for it and of course it's not just Drupal.org there's a bunch of others now you could say that Drupal.org does have a leader in a plan and so some of the smaller areas do yeah one of the things Dries mentioned in his keynote yesterday around content authoring was a three step process for I think discovery design and implementation of improvements to content authoring I think we could add when an issue can be blocked to a place to improve governance I know that's also come in whiskey should an issue be blocked in the design phase be it visual content authoring design changes or architectural whiskey style design changes should an issue be blocked then or can someone wait six months later until there's a completed patch can it be blocked after all that work has been yeah I agree completely in fact I think I've got another slide with some some ideas of the way that we could improve our rules about how we deal with issues and I don't know whether there I think Dries has been thinking about that and stuff let's see there when I put community issues I issue is a bad word there but there there is actually stuff right in the community that is I mean we're big and complex organization that has community issues as well as these ones that can be categorized in other places support project application what other broad subsets of what we call Drupal need to be on this list that we should be thinking about you can you can mention them later or Adam a little later if you'd like so I just was doing some speculative thoughts about the core development process a lot of you here been involved in it and I was only doing it because it was a way to think about something that everybody's thought about and so the initiative or lieutenant concept is obviously something that we have learned something about in the last year leadership is something that I'd mentioned but I think what you were saying is like can we make the design and the commitability decisions earlier in the earlier in the issue so right now in a in a core issue the you there's nothing certain until it goes in and it might even be rolled back after that I don't think we're going to I don't think we're going to solve that problem because that's that's just a normal risk of software development so that's not but the risk that you take to spend a year working on an important issue and it could be blocked by a bike shed at the end is a huge risk so can we make the commitability is a you know can we say this design approved after adequate design bike shed you know commit approved when it's rtbc in other words the the maintainer has signed off on it or whoever's responsible for it has signed off on it I think that just finding an explicit way to say this is how a bike shed ends would be a great thing for our community I'm not sure exactly what we can do but I don't think it's very hard between the time boxing idea yeah Angie one thing we this came up at the whiskey sprint that we had is you know this this thing where there's people tearing each other to shreds over like directory structures you know there was blood on the floor over directory structures literally so the process in air quotes that we came up with is if something and ideally this would happen way before there's blood on the floor but if something is heading in that direction where it's like there are two or more very smart people who are very opposing views on things the process that we came up with was assign it to trees and anybody who's in maintainers that text for core can assign things to trees I think we can I don't know the whole permission scheme but we could figure that out and then the goal would be that we would then say either this is what we're doing or he would say I trust Randy Faye to figure out what we're doing here and then he or the person assigned could also put a time box on the decision so say I trust Randy to make this decision let's try to have this wrapped up in two weeks or whatever it is that's the process we're gonna have to see how this works it did work with the PSR zero issue you know it was assigned to trees he was traveling or whatever but within a week he said that's what we're doing and the issue got marked fixed and I haven't been online a lot lately but it seemed like it stayed fixed maybe maybe but you know we have a BDFL let's use him basically well that works see that still has the problem that trees is limited and and so I would like to see that exact thing expanded and so that there were 20 or 30 trusted people in the community who would be close to the problem and who could be more responsive than he can let's face it can't I mean he can't be responsive on a hundred issues that might need response so let me just let me just go to this the one thing that I want to come out with okay so just at the end here there's a reference to where the resources are because there were some great thinking you know like Jono Bacon's book and stuff like that and I want to you know say that you should go and write up the session and stuff like that and the blog posts are listed here so that's good but what I what I really want to do is to take just a couple of minutes and come out of here with a plan of how we could within our current Drupal world how we could go forward to build a little bit more structure and implement some of the things we found out that work a planning commission for improved governance how can we do that and then we'll just run over the time with what you guys have to say is that alright yeah I just have a small point I think we should have a technical definition of what deadlock is and what a bike shed is then we can declare that this issue is bike-shedded by then that's a good idea have a description of when it becomes a bike shed only if 53% of the people agree that it's a bike shed so exactly so are there people in this room who would be willing to work on proposing to the community thinking through and proposing to the community a more extensive governance strategy yep yep what we should do is we should we should make an issue for it and have people kind of sign on or we'll figure out something like that how would we do it we would just say that we came up with this idea and we have self-appointed ourselves and if you want to join in you can should we have a governance group on groups oh you're just so polite okay you looked like you had to say it that second on the topic of should we have a governance group I would suggest we make a core issue and assign it to Dries and he would then approve or deny the governance group just to model what the conflict resolution system Angie suggested Dries could decide should we have a governance committee or not and will their proposals have a chance of being adopted on the idea of scaling the assign it to Dries technique I could see us using an appeal process where if we had a larger number of people with decision making authority it could be the initiative leads it could be maintainers listed in core currently it could be the design issues to those people they could make a decision and if someone still wants to bike shed there could be an appeal process that's basically what I'm saying is let's not start with Dries as the solver let's end with Dries as the solver yeah to be clear that's what I meant I didn't mean if you're bickering over like a little thing like assign it to you I meant these big ones the smoldering creators the ones that you pointed out like they must be solved like Greg said during his talk in terms of strategies was come in with a proposal don't open with you need to figure out governance like the four or five people who want to work on that get together ask some people do that kind of thing and then come to the community with a proposal because then it becomes a what do you think of this and then we can say well I don't like that aspect or I don't like this aspect of it but it doesn't become a well I think we should do this I'm trying to cat hurt all of that a related thing and this is related this might be exactly what you were saying about what Greg said is that too often in the issue queue when you have an opinion made person they will just say you can't do that and we should probably build into our system into our into our culture that you generally work from a what you should do what we can do rather than just blocking with you can't so but yeah go ahead I found that the biggest issue about proposing process to a group of people is how you convey that information to the group of people because it's so incredibly difficult for people to consume this much information and it's also very difficult for people to both understand like the grand scheme and the details of it so for like a governance proposal group you know their job is like the information architecture of the document of the processes and the details of them so that they're really easy to consume and then to bring them to the community and in small consumable parts for review so that it's easier for people to consume them and give feedback and I can't see us getting very far with like a document although that maybe that's where we're going to go but we're basically out of time and I want you to go ahead and talk anyway so we'll just keep talking anyway but what I propose is this I think that the issue approach might work for us and if there's not a governance project I would propose creating a governance project and talking there does that sound crazy? does that sound that's alright? we can all find it so if it doesn't already exist then we'll go out and make Drupal.org slash project slash governance and people can make proposals there and sign up to work there and we can experiment a little bit there and see if we can create some bike shits so yeah go ahead just to play devil's advocate a little bit we already have a code of conduct that no one ever points to that says hey you're not stepping down considerably but then we're talking about also establishing this governance document kind of thing that again maybe not be people may not be like oh you're violating rule like 1.2 of the governance code of conduct I agree that something needs to be done to change that but we already have this awesome code of conduct well the code of conduct right now only deals with culture and it punts on governance and that's kind of the problem is that I mean people do point to it quite often and I think we probably should more but it's only for culture and I think it has no conflict resolution in it it has no what to do when you have a problem in the issue queue it has no how do we resolve a bike shits well some of the onus is on the people who have accepted that code of conduct so sure we're in a bike shed argument about like what directory structure we're calling it but some of it's alright I understand that we're in a rut here and we need to step back considerably like that's the thing that's already in the books and you know I don't know we have our own government like the United States government you know you have 20,000 rules on the same thing and we're just adding more rules and more rules to kind of I was just playing double side to get here I agree that something does need to be done but thank you Krell I just also want to highlight that different problems and different types of bike sheds need different kinds of solutions I mean there's the issue that is deadlocked or checks and son can't agree or son and Damien can't agree which is a completely different problem space then there's someone in this issue who is outnumbering everyone else in terms of posts 2 to 1 and still it doesn't know what they're talking about they may be well meaning but they're an issue cube empire both problems exist I have been involved in both of them some would argue I'm on both sides of those but that's another story but those are different problems and we need to come up with ways of addressing both of those and those are going to be different for those are I don't know but those are different problems see we still have a duocracy because anybody could have put a picture on the screen while we're looking at it so you know how we resolve you know the bike shed is different than the issue cube empire problem and I've seen issues destroyed by both of those yeah chicks one thing that kind of works universally in the world regardless of countries as I don't remember the English word for it is this arbiter arbitration binding arbitration we could have issues going to binding arbitration yes I like it one thing we could do is to have I like it like community leaders so if you have a that log issue then we could have community leaders who name arbiters I like it what they are doing and then they decide like three or five people and then what they decide is the decision I like it I like it and that's very simple and it fits right within our model it just gives us a way to break it I like it yes sir come right up to it you hear me I think there is some working model of this multiple level of returnance and things I can make decisions and this working model allows to not have the problem of they are responsible I think a lot of sites and communities use this karma slash so basically the more you contribute to the community to projects the more rights you have I think that's relatively simple so the recognition of the structure of our community is another whole thing which I have opinions about but I think it's not exactly the same thing maybe it is the same thing but we definitely I think we need to expose the structure of our community and I'm not sure it's the same issue but it might be Krill just to push back a little on the finding arbitration concept well I like it in theory it runs into the problem that one of the things Chek said that arbiters should be someone who knows what they are doing in most cases odds are the person who knows what they are doing is one of the people involved if there is some question about some deadlock in the internationalization system Gaba is the one who should be resolving that odds are Gaba is also one of the people in that debate because he's the internationalization guy so he's probably in the debate already and I don't know what to do with that it's not necessarily true you could take effulgency and throw him at any one of those and he'd be a fair arbiter I mean there aren't that many people like him but you could take him you promoted man you've been promoted let's take a bow but no so I'm saying it's not necessarily true but I can understand your point the impartial expert is I think a lot harder to find than we give it credit for because most of the people who would be domain experts are not impartial by the time it gets to that point I think that we are large enough that we actually have the kind of experts who could move in we have actually seen this already happening without the formal structure usually what happens is when an issue gets deadlocked David Rawson gets involved and then things move on I have seen that many times actually but what I wanted to say is that badges are extremely controversial on Drupal.org because we don't want what you have said you know that they are doing this I think very easily could lead to that you know that somebody with this list of badges says something and then the new contributor who actually might know more about it, he's just not much into Drupal might be intimidated into not doing what is actually the right thing so I am very much against doing that this is also the reason even an IRC free node encourages the ops not to be opt all the time not to intimidate everybody why doesn't everybody come up here and talk that way and use this mic it doesn't make any sense for you to be looking at me you should get to talk to everybody else ok so one of the points raised was that not having a lot of governance actually empowers people and that by adding new layers and new lieutenants you are actually making it so that certain people and many people don't feel empowered enough but what I would like to argue is that those people are only empowered to solve trivial things and that without having a certain level of governance and without having initiatives it wouldn't actually be able to solve big things and to rework large parts of Drupal and I think that having initiatives has allowed us to rework a lot more than we could have been able before and I think that it will die as an individual really scared when thinking for example of reworking comment module or everything else because if I try to suggest large changes I know that it will be bike shattered to death and it will die and I really don't have the energy to just talk so much and not do so much so that's my point thank you one mechanism which hasn't been used by the PHP group and PHP projects in general which is the karma mechanism we have something about karma in the channels but it isn't used for anything currently as far as I know and on PHP projects the level of karma can give you some rights for recognition on the project and using such a mechanism might be useful for us for people to obtain the actual recognition beyond their name not sure I'm clear about that when people accrue karma points by doing some things for the community solving issues or getting in massive patches some people will know because they follow these bouncing too much oh yes should I restart no karma as I said karma is currently not really used on Drupal except for fun on the channel but if you look at how it works with PHP projects gaining karma points will gain you recognition and actual rights at some points in the system and currently when people do important work on core like sudden closing not date for instance some people will know because they follow the issue but many won't and solving huge issues will give you a recognition which could help provide recognition levels for some people who have some expertise or actual level of involvement in the project I thoroughly agree and I hadn't had that thought that the exposure of our community structure through expressing what people have done in it was part of the governance discussion but maybe it is I think we should probably bail because we're running out of juice I found the governance project doesn't exist I'm going to create it please create issues there and we'll sign you up and Angie you can have the last word I said something really quick which was a suggestion to the you know committee ad hoc committee that sort of works on this is rather than trying to come up with a big overarching plan for everything I mean it seems like we have some really good low-hanging fruit like let's fill out that to do in the conflict resolution policy it's my opinion that because our community is so valuable to us and works very well in many many ways that we should be experimenting with little changes and not making big I don't want to write a Drupal Constitution I think that would be a big mistake I think we should get community agreement for small changes that will unblock some of our key things and that may take us somewhere down the line in five years when we're even bigger but I think we should be doing looking for low-hanging fruit addressing it and finding ways to solve our problems without a huge structural change but let's do call it and please do check in I'll just create that project in a minute or two check in there and thank you very much for your care for Drupal thank you for caring oh yeah don't forget the evaluation I already said that but it's there thanks a bunch