 I have to say, before that I registered a lot of talks and I was most afraid before this talk because I have no real proofs that I'm competent to talk. So I just had some ideas and think it is good to talk about ideas and I hope we can improve this in this both to something more than I can present here on the slides. Well, I just thought about what to lead. If I'm speaking about leading a free software project, then I thought about who to lead and lastly, but not least, how to lead. So what to lead? What is in general the motivation to work in free software? I think the first motivation is getting something to work for yourself. So normally, you'll see I want to do a certain task. There is no ready solution. I just want to have a solution for myself, but just start coding. And people who are entering the different comments have probably understand if you release your codes, free software, you get some code because there are, at least chances are good that there are people out there who have the same or similar task. And if they know about your project, they think, hey, perhaps I can join this effort and you can split the amount of work between those people. So releasing the code is free software is a clever thing. And finally, it's something to get working for your own task. And perhaps releasing code is also something to get friends, even if people are not able to do some coding and so on. Just using your third project, they will probably just love your tutorials. OK, so example, and why I was motivated to do this talk is that I was more or less the leader of Debian Reads. I do not really like the term leader. I just would call myself initiator of the project. But if you issue an announcement of a project, this is probably the first mistake if you want to avoid becoming a leader. Because those people who are thinking, well, this is a nice idea, often tend to regard those, the person who just made the first announcement as somebody who is competent and has thought, known about it, which is not really wrong, but sometimes it is more than just an announcement. If you, after this careful introduction to the first structure, some, like, weird subject pages or ask for mailing lists on the Debian web server, you most probably make the next mistake if you want to avoid becoming a leader. Or at least people respect you as such a leader because you are the man who did some work for a common project. And I learned that those people just asked me for some advice and positioned where I was not able to give any advice. And so I said, well, we just try this. And if we are lucky, it works. And so finally, if you try to do some reasonable stuff that brings the project forward, people tend to bore you in your leading position. So what if you are in this position? You can either accept it or think, well, I'm not really fit. But I think if there is nobody else who does it, you have to accept it. And this is kind of, well, doocracy. So if there is somebody who does something who becomes the person who is giving the direction of the project forward, and the thing is that you should try to make it more or less in a way that people won't accept you as a leader. And so you make sure that other people will join this effort. If you try to do some things other people will not accept or will not like, then you will lose your basis for your work. And so you have to just continuously check whether things go well. Whether people are happy with this project and to come back with the big and big stuff. I started this in 2001. And I was basically alone and started a mailing list. And this mailing list, the members of the mailing list, a number of the mailing numbers has grown. And I just learned that I can more or less ignore certain parts of the project because people are keen on working alone on this. And this is the best thing you can do if our people working on a goal you more or less defined and you can leave them alone. There's no need for any intervention. And so I can put my concentration on different things. So now I want to say something about who to lead. I think the first thing is if we speak about free software there where I was, that they are normally in individuals. So these people, I try to say, just behave different from normal. If we look at the user, computer user, I think we are not the usual computer users. We are something different because we want to dive deeper into the project. We want to get some more and do not accept what others present us. We just are thinking for different ways to do some things. If not, we would have this tiny, great, green grass background with a blue color of sky and white clouds, which is, by the way, a really bad image if you ask me, in a few points of the program. These people with the free software develops also in real life refuse to accept leadership if you look at the t-shirts of these people. And deep in us, you can learn that they just won't do something against it. Sometimes stronger, sometimes not so strong. When I was on Linux talks this year, I was a little bit impressed because the people had the face of the German Indian minister, Schäuble, on their t-shirt, and then wrote Stasi 2.0. And the Germans will understand it. I do not really like this sharp, it's a little bit harsh. But what I want to say is those people are not keen on being needed by anyone. They just accept leadership of somebody they can respect and they can agree with normal. Also, we are mostly technical-focused people and can be needed by good technical arguments. If you have no good technical background, you will not be accepted as a leader of this stuff. I think that's really sure. It has not been a strong background, but a technical leader of the free software. So a little bit of feeling is necessary. And finally, you have no handle to force those free software developers. If you try to force anybody, he will go away. I'm really sure because there is no other motivation than working on your own project. And if somebody is forced to do something he does not want to do, he will leave us. So we have some differentiation between an employee versus a free software developer. For instance, the employer-employee relation is they have a common interest. They want to make some profit. And both of them try to gain this goal and step back with personal feelings because they just want to gain money. They just want to gain money, both of them. And there are some rules they have to accept to get this working. And an employee can be fired. This is different between a free software project leader and a developer because they are just not interested in making money. They want to make their project running. It might be that at some point, anywhere, can somebody earn some money with this project. But this is not the main focus. And it's also interesting that sometimes something they are working on is different. And so they have to find some compromise and try to make things working to get some common interest. And that's the project is approaching in more or less the same direction. You can't fire a developer, but you can lose interest. And it is really hard for a project if a developer loses interest. And some projects will die if some poor developers go, or they will be forked, which is in most cases not a really good solution. But in some cases, it can work. But it has mostly something to do with differences in between developers and leaders. And some developer tries to lead his own project, which might be more successful, but this is not the one I'm talking about. So I'm going back to your previous slide, the one before that even, where you said. By the way, you can never entirely interrupt me. Please do so. That's where you cannot tell a developer what to do as a leader. The other way around is also true. I've had developers tell me, please test this now, because I would like to integrate it. And you cannot tell the lead to do that, because he's also spending his free time on it. So sometimes you will just have to wait until the leader or the release manager or whatever gets around to looking at your changes. And especially if they're invasive, keeping patience. And if you are looking as a leader, only one developer, he is a developer as anybody else. He's just in a different position, but he's also free software developer. You can't know if you're forced to do anything. This is absolutely correct. Actually, I think you can maybe not force people to do something, but maybe lead them into doing it or sometimes move them, I don't know. As long as you have something they don't have, then you can lead them. Just as you can have your employees do something they don't want to do, because you can give them money, you can get people in the project to do something, because you can give them, I don't know, add the feature they are wanting to add or say, I will apply your patch if you make it better or you add this feature or you make it more generic and documentation and so on. There are ways to do it. I don't think that will work. If you try to do a tick for cat sort of thingy, I integrate your patch if you develop it so it has to be related. So I don't think it will work one time. I think if you try to do that, people will start feeling coerced. They're not going to be, I'm writing this because I want to write it, but they're starting to feel like it's sort of, I'm writing this because I have to do it because otherwise, I don't know. This other thing doesn't happen. What you have to try to do is you have to try to make them want to do this. Which is not the trick, it's not that explicitly, but to do it kind of implicitly. I'm not talking about the training of features. No, it's not about giving this for granted, it's about making what they contribute, making it better. It's not the case by cat's basis anyway, because all the developers are different, but you can definitely say, I would implement your patch if you're not using, I don't know, a specific instruction from this library or something like that, maybe more generic and so on. People will eventually know to write better code. Yeah, but it's a different, it's sort of different. Sure, sure, different. You can never make someone do something that he doesn't want to do. If it has no relation with what he's actually doing. But sometimes you can just push a little bit and get big things done. The thing is, if you do listen to what a project leader or release manager has to say, and try to implement his wishes, then he will be much more inclined to look at your code in depth and to integrate it, because you have shown that you are willing to work with him. Well, if you just say, OK, here's the patch and please accept it. And I'm not willing to discuss problems or whatever he's going to say. I think as a free software leader, you have to be much more clever to get people in the direction you want them to go. Because you have no handle to force them. If you are really clever, you will find ways to be happy to do what you want. I don't think that you have no handle on developers. Excuse me? I don't think that you have no handle on developers. I think there's one handle that you have. And the handle is love for the code and love for the project. You can't overplay this. And you have to be very careful in how you do it. But I think this is the only handle that as a free software leader you really have. Yeah, but if it's difficult to have different opinions about the code, you... You have to convince him that... Yeah, you have to convince him that this is not a handle. This is some kind of... OK. It's not like an employer. Yeah, of course you can't force him from there. Yeah, which is the problem. The lines also get very blurred, because there are some people who are employees who are employed to work with free software projects. And so you might be a free software leader and you might have some volunteers. You know, you might also have some employees or some sponsored people or something like that who are working with somebody. So it's not one of them. But they're a report to you, though. They're a report to me else. Well, in some cases they may well report to the... Yeah, depending on what the arrangement is. In my opinion, for instance, one side effect is, by the way, that very often the documentation is not so good. Because writing this documentation is not real fun. So nobody can force a developer to write good documentation. So their approach was perfect for the documentation. But if you look inside... But it's a different set of skills to write code and to write documentation. Yeah, but you have to convince somebody to write this documentation. But not only that, some people try with all their hearts to write good documentation and it sucks. They may be great coders. You don't want to really force the programmers to force themselves to write documentation. You want to add new people who maybe want to become programmers so they will learn the code. And then, by the way, document it. Or if you don't need... Not all documentation is API. Some documentation is actually for users. Not everyone thinks it's obvious to click and cancel if you want to cancel. So documentation is a cold, different beast. It takes a different kind of people. I think 100 of you would cook with 100 of these programs. That's just the quality and what is good for the project. Saying, especially as a leader, this is good for the behind the scenes of this project. Might give you something which is not very sexy, but it's a short time of time. We have to fix this both, for instance. Yeah, but if you look at release management, it would be good if you all would fix your disk as regards. It would be really good. But, yeah, it's not good. It's like mission statements are a good thing. Someone else talked about that. If you set the general scope, there are no major disagreements about what needs to be done. Maybe you have people lagging and... Slamming off. You know, I don't want to do this right now, but they all know that it has to be done eventually. And then you can get into the time base, release the stuff there. But if you have a clean-emission statement, then at least everybody knows that it has to be done. So there's no essential conflict between, you know, I don't want to do it because it's stupid, and you can't affect your power as a leader, if slowly. Yeah. One handle that you can sometimes use is guilt. Yeah. Sometimes we'll make promises, like, okay, I will look into that, and then maybe you can say, have you had time yet to look into that? Really, really careful. But still, it's a reminder that, well, they're supposed to be involved in the project, and maybe they're spending time on other things. And so it's kind of a way to try to softly drag them in. And I found sometimes that guilt can be very effective. So, using some technical tools to generate that. Okay. So, well, the next topic is, the next slide is about being verbose. I think, by all means, communication channels, like email, I don't see even blogs, or even videos for certain things are very important. I think that also people are becoming informed, what you are wanted to do, and which is also an important thing, in case of trouble, use some other things like phone or real-life communication. I think if we would have some more real-life communication with hands-off of the keyboard, it could help in some cases. I'm really sure. And I'm sure that, you know. Yeah. So, for instance, to Francis here, in the case, I really like him, but he's a friendly person in real-life. But if I read all these emails, I'm so sad because it's really sad. And so, if we would meet more person, or we had more interpersonal communication, it might be better. I'm just, I can't be unsure about, I think this is a real important matter. I think the problem with Sven is that there is not enough communication. No, this is a wrong communication channel. Yeah, that's what he's saying. No, the problem is that the communication is bad, and both sides don't notice that they're miscommunicated. I don't think he can solve that with more communication. Yeah, but that's the exception. Different exceptions. Let's not reuse everything to solve that. No, I don't think that he's an exception. I think that he's just one of many cases of communication going wrong, and he's maybe a very spectacular case, but in the end, you have a lot of those cases all over the place, they're called different, and they pop up on different mailing lists, but the general leadership sense, you don't always have such problems as when we're escalating everything. Oh yeah, the little nuances help the project much more. If you can handle a little communication problems and rather than concentrating on how do I fix if somebody gets hit by a bus, or let's not go to extremes, keep it generic, you know. I mean, sometimes, if you learn people to know by email, and see them later on on the network, you start behaving different. You learn to know the face of the person, you know how it behaves, and so on. You just react different, and this is, well, it works to a certain point with this electronic communication, but above this point, we should use some, some other communication channels. Yeah, one more thing. In the slide, say, use communication channels and then, in case of trouble, I don't think you should really mean in case of trouble with communication, but in case of trouble with something else, because, you know, for example, I do mirror stuff in there, if, say, the Spanish mirror goes offline, as it has five or six times in the last few years. If someone's telling you a mess, a mess about it, that will automatically increase guilt, increase my interest in general, increase the feeling of somebody cares that you do, that you fix your stuff. You know, maybe this is an orthogonal example to software development, you know, if there's a security problem, communicate it more efficiently to someone and then they really realize that, you know, there's no room for, well, maybe it's not so important, maybe nobody really cares, why should I really bother? In some cases, generic methods to mailing lists will get lost while a personal reminder will get jumped up. On the other hand, too many personal reminders will definitely not work. Also, it's really important to pay all the reports. So people are working in their day-to-day life and they just like it if they know how we've made some progress, or even if there is not so much progress, you can say, well, we tried and had this and this problem also. So the period of the report depends on the project. But I think it is quite important to keep people informed. This is in several instances in England, not well done, and this is the main point of critics of mine. I would like to do this better. I have to admit, I'm doing it also not so regularly in the video main project, so I'm not bothered in this aspect, but I think it's an important point. So ask others about problems. If you have no response from others, well, you don't know if they are stick to some problem and just keep people informed and be informed about the problems, say, possibly, yeah. Just one more point. Service tracker, bug request tracker, the school for tracking things is a good thing for communication, you know, in the context of asking other about a lot of problems and everybody is saying that to you. Mail is not getting lost. Guilt to being distributed nicely and all that. Yeah, should be mentioned. Yeah, this is one of the reasons of veracity. I think I have to rework the video tape and make some more tour systems. Maybe. So a very, more important point is to be nice to your people. Yeah, it is, sometimes people are sitting in a high position, tend to become harsh to others. This absolutely has to be avoided. And I think one thing I'm doing very consequently if somebody has done a good job in the video main project, I just announce this on the mailing list and say, well, done job and keep on the good work and this, I think people like it and I had a very good response about this. If somebody, someone provided unexpected things, so things you do not really want or do not really think are good, try to elaborate whether we can change it for a better direction. It is a little bit, this interesting thing in free software is that it is not really predictable what happens. And so if something new is growing up, just observe it and try what will come out of it. More or more try to serve as an example for the people in your group. I see people's Einstein who said the best thing in education is what you can do. Be an example and if not possible, try at least a bad example. So I try to be a good example and try to follow these items but be open to your co-workers and just be nice to them. So we'll talk, not to talk, but these slides talk more about kind of reading more than a strong leadership because it just not works in free software. You have to try to move the project in certain boundaries but these boundaries should not be so strong that people will drift away. And finally in the point, be nice, try to avoid the kind of hard. Well, just in the talk before we heard the famous word, kawal, but it is hard to decide whether that is kawal or that is not kawal. People like to talk about the kawal but even if people start talking about the kawal then something is in the air what is not so nice as it should be. So while living at all, yeah, fun. I think there's almost always kawal. The question is if it's really a bad thing or not, it's a bad thing if the kawal is closed but in general that will just be people that are doing so much more work and are so much more involved in the heart of the project that by reason of doing the work they get to make the decisions. And to people that are outside that can look like kawal but basically it's just to make free soccer works. Yeah, I think that this is one of the kawal of course if there are people who are doing very much work and the people who are not providing so much work do not really understand what happens because they are not so deeply involved and they think those people are kawal. So if it is this way that people just could try to gather more information to get inside kawal, then it's okay, then it's not really kawal. It is about openness. It's more about decision making and power. So it's obvious that the people who do the most work get the more power and control but it's about the information that doesn't work. It's about process. You process the legal term but there should be a process for doing everything. There should be a process for not doing something. Make it possible for people to get rejected on their view. Legitimately rejected. We think this is a bad idea and you should go away. It's about being able to discuss decisions before they are made basically. Procedures that establish certain set of rules and then... Just to enter the kawal by just doing more work for the project. This is an easy way to move forward. If it is possible to grow up into the region of the kawal, then it's fine. It's my responsibility to get people to do things they don't want to do. Yeah, you're right. You have a very clever job. I would also add that a kawal is a... In the decision group, if the group is open, is defined, is official, it's not a kawal, it's a karmicine. So maybe it's better to have a karmicine then. This is what I meant with avoid the kawal. If people are just talking about the kawal because it's just fun to talk about the kawal, then it's okay. They talk about it if they don't have anything else to talk about. Yeah, that's the thing. Give them something to talk about, and then they'll talk, and then they'll stop. Eventually, you have to stop talking about something tangible, something, you know, if there's a feeling or something, then of course they will talk about it endlessly. If there's so much time, they can talk about endlessly. There will always be so much time. But you can also equate kawal a little bit with insiders. And that's something that will always happen together. You can reduce it. If a kawal uses a basically open IRC channel to do their discussions, you could say, okay, by definition, that's not a kawal. I'm not sure it happens that much at the technical level, but more at the political or legal decisions, like the license changes. We've seen for X11 Apache or... This was not really quite a kawal, but we have this general resolution about it. And then people feel their right to be involved in the decision processing, sometimes it's taken away from them. But you also see what happens in the case of XOR. There's a fork, and the people who proposed it were punished very badly, because basically they've become completely irrelevant. So there's a very large self-correcting mechanism in the Obusofero. Is this more about factionalism, or is this more about... Kawal, obviously, is pejorative. It has negative nuances. If you spell out a clear meritocracy, then you know what it takes to get to the inner circle, and it's very clear for everyone. But then I think what you're talking about here is more of a factionalism, which happens in all sorts of companies. You sort of back one set, another group backs another set, and this set wins, and these people are a lot of favor. I think those are different unless I'm misunderstanding. But I think as long as you... Once again, being open, being transparent, letting people know that if you do this, this set, you too can be part of the... You'd never use the word Kawal, but you can be part of the... Your influence grows as the amount of work and the quality of work that you turn in. It is just a coordinated project. You need some clear paths to go, and you have also to define certain tasks which are to do, to get this task done which you want to do. It is also necessary to mediate between the members if there are different opinions. So we have seen several escalations between members, but in most times it was fixable. I said it before, real-life communication is the best way to mediate, and sometimes you fail, but this is normal. But as a dealer you have to be clear that you have to do some work which you do not really want to work, or make some free software that you don't want to nurse other people to stay together, but it's kind of necessary. And finally, you are more or less a connection to the outer world. So... Since the E-mail project, for instance, has a website that says the address of the mailing list, and anywhere on this page, I think I removed my email address, that was my email address, and people want to talk to a person, not to list. This is incredibly stupid, because I'm reading the list and the rest is much more sane than me, but people try to talk to me, especially these kind of people, these medical people, need some character to speak to. So we have to be kind of a connection to the outer world. And if this connection is just forward, the problem to the mailing list is also fine. In most cases, this is fine, because people want to become informed, and you know who are the company and people who can perform those people answer questions, or you do it yourself. And another way is if you... This was one of the few people come to you and want to know something, and on the other hand, sometimes you have to make connections to similar projects, who might be targets for co-working or do something in common, so you are on the task, is to go to these people and talk to them about what can be enhanced? I'm missing one item there on that page, that is make decisions. It's not always relevant. In some projects it's more important than other projects, but in the end, when there is no clear consensus on a list or when certain individuals are trying to push something that for them privately is very important, but that, for example, would risk a release or the stability of a release. As a leader, you cannot be too afraid to make decisions about... And just say very firmly, okay, we are not going to do that, but we'll include it in the list. We'll look at it again then. If you do not make decisions as a leader, it will often kind of put the... The project has been in a certain state and will lead to stasis rather than progress. You can have two situations when that happens. There are no decisions being made in two kinds of project groups. One group has a clear set of procedures that has a documented setting for this and that, bug reports, main list archives, all members who fill in their own energy, and you have a group which doesn't have anything documented. And I mean documented in the widest possible sense. The poor man's documentation of just the proceedings, not like a mailing list archive or something. They don't have nothing documented, and in the first group, there will be a stagnation. But in the same group, there will be a kebab. The people will think nothing is going on because the kebab is obstructing us. That will happen. Just because of lack of transparency, lack of process. Establishing this process will help you when you can't make a decision. At least you can stall it. People will see why it's hard and they will see there will be a problem, but the problem won't be so escalating. And finally, does this idea scale? In the beginning I told you I was a little bit scared about working in the store but I think it was good that I started it and maybe collected some ideas. I forgot, obviously. I'm not sure whether all these ideas really scale for the area as a whole. I wish you good luck. Stay nice. All I said is probably valid for not elected leaders which are one of these two ocrusive principles. If you are an elected leader, people have some other expectations and perhaps you might have in mind that. I don't know. You have some policy and other means so it might be a little bit different. All this I said is more or less restricted to personal experience so we just talked about your experiences. If you have some more input, I hope you're really happy and make a motion to all of these slides. Come back down. Isn't replacement the handle against somebody? If you say you are maintaining your package not good enough, here Mr. X wanted to do it and you are being replaced. This is a decision by a leader. This is what I mean. What I said does not really scale for the area because you have an elected leader with delegation rights. This is a little bit stronger than what I presented here. This is possibly an option to... But it's only one handle. It's a very strong handle. You're not always going to use it. The problem is, if I would be in the shoes of a deviant leader and would go to some person and say I would like to replace you, would you be strong enough to say this to somebody? I think I wouldn't. This is a problem. This is a discussion of strong leadership and the same decision. It's different between strong leadership and a strong person and also if you are a strong person you most probably have not the courage to go to somebody and say go away and somehow make a decision. I think that even if you are an elected leader with such a decision, such an action, you would need really strong backing before you would be able to do that. That's actually the idea of the state. That's actually the idea of the social committee. My idea was if there would be a social committee, you have some people who are also responsible for such a decision and it's not that the person who is replaced says why you don't like the color of my hair and that's the reason but really people think there should be some change. This is different. Another advantage of having a social committee would be that the process of reaching that decision would become better documented because it would have been discussed over a longer period of time in the social committee and they would probably do some kind of investigation into mailing this history and interview people about what they think about the situation. I agree the social committee would be probably improve our handling of social issues. If we combine the issues of leadership and the social issue, the social committee is supposed to be just an advisory body. But the leadership stuff. In Evian we have this weird binary situation. Some of you mentioned it and I of course read it correct but we have one leader whose responsibility is everything executive in Evian and everyone else is beaten here We can just leave it to the leader to decide. That's a really silly approach. We need to layer it down. Like the responsibility for individual packages is rest on the person in the maintainer and the uploader's field there should be a layer down version of both decisions because that makes them documentable because there's overhead. But we can probably work on something acceptable. Sometimes I resented the leaders before Sam. You get frustrated. Many people did. I saw this in discussions. Why didn't people decide on this? Why wasn't there something done? Because you can't really expect one person to bear the burden of 1,000 desires 1,000 frustrations 1,000 everything. Basically that is the reason that DPL has the ability to call a GR basically just by himself while regular developers don't use that. Is that a problem of the system? Or is that a problem of DPL? I wouldn't be inclined to say it's a problem of the system. It was unrealistic to expect that DPL would really bother 1,000 people but he's elected by the majority. So he has the power in my opinion. When he's the majority he's elected by the majority. That's very important because you can have maybe one-fourth of the whole developer community who agrees with what the leader says and whether he won the election or not doesn't say anything about what GR would say. And the GR doesn't still winning the election. And the GR doesn't have to be connected maybe you voted for a platform but you voted for a person but a GR may be in your... Where does the leader take the legitimacy for all his decisions? What you're talking is basically representative democracy. You vote for a party, a platform and not every decision that in the end you get out of the system is the one that you voted for and that's the deal with representative democracy. In this case if you have a problematic decision to take you can get GR and all the people would say Just saying you can get the GR makes it sound so easy but we don't do it so easily. If you don't feel comfortable having... if you don't feel comfortable because you're just being a 50% or whatever you don't get people to decide. We don't have precedent for that kind of thinking. We don't have leaders we have 8 people at DPL they are all different. Some were strong some were weak some were mediocre some were good but none of them actually utilize these options that makes me one area of these options they're not really theoretically sound. For example if an issue was in the DPL and he's running into a block of some kind in that case I think calling GR on the issue saying well this issue was apparently important to people because it was one of the main points of my platform so I expected it's part of why I was elected but I'm running into this block I propose that the project shows its support for this issue so that I can move forward and I propose to do the following I think that would be an excellent use of a general resolution I have an example of that I think it's more important to think about big, hard issues like suppose we decided we're going to scrap all of the debt we decided they're going to scrap all of their very version control systems and switch to a mercury or something obviously that is a decision before a lot of people involved want to do a GR to get Debbie in as a whole stamp on it and then therefore cause everybody to go look I lost but we decided to focus for it so we're going to go for that anyway so I think GR is good for big data Yes, that's okay Maybe it was something you were pointing out yes nobody in so far nobody of the DPL so far used that I wasn't part of the project yet when the current governance model was decided when the constitution was drafted and all that but as far as I understand well this is a unique group that came up with a legal system basically out of nowhere so yes there's also something I have talked with some people we have some documents we consider where they should not be they should be amended every now and then and it's very hard to do it You need to know that the constitution was specifically drafted to prevent the project from going insane and having too many powers Those bears it didn't really come from now it was because at that time in Daniel there were issues with the project leader and they didn't want them to appear Yes, so this history is placing a burden on all of us you know, today because yes, we are all influenced by this thinking okay, it has to be a very free everyone has to remain free to be a volunteer that's the point I need to take on a leadership role and discuss and vote on a GR that will change something something substantial in the bubble procedure well So should we use GR more often? No, actually So we see the majority wants this and then we use it more often for problems The problem here is that you're asking the question you're not giving the answer We're talking about leadership I think it's supposed to see I mean, using GRs within Debian turns it in we're a very authoritarian leadership model which is a total amount of the way free software works free software doesn't like having general resolutions and well 52% said this is going to happen so this is what's going to happen So it's almost pulling it a little bit back on to your slide, Andreas about what the Debian project as a whole can do I think there are a whole bunch of things that the Debian project can do and probably let's get away from this GR authoritarian leadership because it's not going to work but I think the Debian project and you talk about communication and regular updates and things like that in one of your earlier slides and I think that's one of the great things that Debian can do we've got dozens of IRC channels and dozens of mailing lists and all that sort of stuff so to what extent we're totally swamped with communication but on the other extent it puts out on Debian announced or whatever a status or a sit-rep or something like that and if the project leader tied it into well these are release goals for Lenny and this is how we're tracking against it and this is what people can do to get Lenny in shape or this is what the QA team are doing or this is what the various projects are doing it's that communication and I think if Debian is a project and the DPL as a body uses the leadership in that way and say well this is what's happening if people wish to channel their efforts this is the way Debian as a whole the release team are driving this the QA team are driving this the FGP Masters are driving this then at least people are getting a regular update from the top from the lead saying well if you wish to be part of Debian this is how the project's going as a whole rather than saying well we're going to raise a GR and say that these are the release goals for Lenny it's the wrong tool whereas if the release team come up with some considered release goals for Lenny which is what they're doing and then the project leader then pumps that for the next 12 months and every month says well these are the release goals this is what you as an individual developer could be doing to forward your part of Debian towards the release goals I think that could be quite useful and quite a non-authoritarian quite a good free software leadership of the type forward I totally disagree that GRs are about being authoritarian I think GRs are about reaching consensus if you look at GR on the GRDL where basically the group of people most involved with the GRDL Debian legal were had a lot stricter standpoint than probably the majority of the developers the GR actually was a very good and effective way to break that discrepancy between kind of the most focal the standpoint of the most focal people and the general view point of Debian developers by just asking the Debian developers who are not involved in this discussion on Debian legal because it basically never goes anywhere whatever it should be noted that Debian both main English participants did a good job on that resolution the GR itself was just a consequence of having three options each of these three options was supported by like a dozen people and these dozens of people did a good job then a legal group at that point these guys stayed there and then we got a relatively easy vote and I agree that there have also been GRs where the options were very bad and really real alternatives to what was being handled but if that happens on Debian vote it's basically a joint responsibility of all developers and any developer who is not on Debian vote kind of sucks one other line point we don't actually have a procedure to raise good DPL the only procedure when we have people messaging 1,000 people we have a large main English like to develop Debian vote because I don't know how many 1,200 people but it's a bizarre but if you scream at it nobody actually hears you you can't scream at it but if you yell on Debian vote announce that's a completely different picture so we don't have a system of reading I don't know if I spelled it right pronounce it right we don't have this kind of leadership so I don't really expect the leaders these bits from the DPL idea was a good thing it was a major step ahead the other leaders didn't have this goal to just go out there and say something maybe what they said was not authoritative but when you send it to a list like that it sounds like it even if you mean it completely consensus-driven way it sounds like it has weight so there's a responsibility there but the problem is we don't have a system that produces people who can do that that's the problem I think I don't have a solution but at least it's a general idea it's somewhat self-select that's the problem itself you have to have self-loving people that's the problem yeah the problem is that problem right sir is this we call it? yes now I'm famous by the way there is one option to yell on TVNW just writes a welcome voodoo at the time everybody will notice increasingly people willing to worry I hope so but you are right it is really hard to get a focus on the people this general meeting general solutions also something people normally tend to they want to do some programming, some hacking and this organizing and so on I don't know I don't know I'm not we have about 400 not everybody but also maybe one-third of the development I know I know but but taking on what's being said also another thing I think is problematic but there's no way to consume around it is that GR yes it's a very dangerous tool if not used right I know we have some examples we can refer to but it's such a long process that it discourages people from introducing GRs also what I wanted to mention is that if you look how many people voted for the new year about do you really like to vote over and over taking into account that the people who you know the people who are here in DevConf are the developers that are most interested in the project many people are interested in making a linear solution better for their users and it happens to be that way we have this huge number of MIA I guess more than part more figures and metrics about how many MIA is really active in the project I think if you would correlate with that data about uploads and voting for DPL it will turn out quite strong yeah I'm not really convinced probably also those kind of developers who upload in regularity but do not care about anyone there's a fair few people who actually maintain one or two packages in a very specific field basically don't care about DevInner's project at all just care about as a vehicle to get the software and that's fine, that's absolutely fine I'd rather that those people do not vote because they probably are not informed yeah that's something we really spent yeah although it's taking all the stuff the issues that probably don't have to work I'm saying it's fine if they don't vote if they are not informed if they don't care about the project at that level please don't vote leave the decision to the people who have some kind of self control just a little bit of statistics David was kind of asking let me check we have 500 people on Debian Village 2000 on Debian Development and 5600 on Debian Development that's really like this so you don't know who of them are Debian Development well, only 3000 I'm scared, it's intimidating but Debian Development is replying a lot of users of Debian Development because basically the regular announcement list is dysfunctional yes if you're wondering anything about Debian and what's going on and what may affect your installation you're much better off reading Debian Development basically because it has on average very good and useful announcement and not trivial stuff pressing by so it's not time for burden for you there's 28,000 people on Debian Announce not getting any mail probably very happy about that well, it's a stable it means to me, what do you want the bounce handler on the list system, I know this much so I don't know this kind of thing the bounce handle goes wild there's a post on the announce because they keep piling up piling up and then the first post gets like 1000 bounces or 5000 bounces it's completely insane so how many people are there 600 which is quite large I'll take advantage of this period of silence we are out of time so thank you very much