 Good morning. I'm from the first session from Jerun. Something like that. About conducting something, it was far too long for you to remember as an early hour. So please welcome. Welcome all. I am surprised to see so many of you over here at Saturday morning. I'm actually also a little bit surprised that I'm here myself. Some of you might have not expected this, but well, if you have goals, you need to go. Today, in this three quarters of an hour, I would like to have a small discussion about co-operating in Debian, and especially how to get work done better with complete work. Debian is a great operating system. And I believe this greatness is in the mid-parts thanks to the lots of the huge amount of developers that are working together to integrate Debian into one universal operating system. Debian does not consist of a lot of different source of packages. Well, actually it does, but they work very well together. This wouldn't be possible if developers wouldn't communicate with each other or wouldn't make rules so that the packages actually are nicely integrated and would work immediately once installed. In order to remain this Debian to be the biggest operating system around, it is very essential to be able to remain co-operating between packages to have this. The Debian policy is an important part of this work. The Debian policy, however, is not so very easy to change. The problem is that you cannot actually simply use the Debian policy to enforce changes on Debian itself. It would make way too many packages immediately buggy if you would change the policy into something that isn't yet reality. Also, the policy editors and I think rightfully do not consider the policy the place to actually enforce large scale changes in Debian. But there needs to be a way to actually improve Debian altogether and to make new policy. For this to happen, developers need to come together to discuss what would actually be useful things to modify in Debian. In recent years, at least the years that I have been involved in Debian, which is not terribly long, I realize, I noticed that whenever something a bit controversial is being discussed on a large mailing list like Debian Devil, Debian Votes, or Debian Flame, this will actually not really often result in very constructive conclusions. There will certainly be a lot of constructive replies, but you turn the nature of email and the tendency of people to always reply to the latest email in a thread. This will not so often lead to really good conclusions, consensus. Also, people have a bit sometimes difficulty actually in a later moment in the thread admitting that they have been convinced by others and changed their stance on certain issues. As a sort of work around what happens often, and I think too often now, is that only in small groups, either in real life on ISC or on a smaller mailing list, issues, controversial issues are being discussed, because that makes it possible to discuss without having immediately a big flame. But there are big disadvantages to that. A very good example of this is what happened in Vancouver. It was seen in general that the release of Debian was not really progressing very fast, and it took us very long to release. But on a big mailing list like Debian Devil or whatever, there was not the trust that it would help to discuss this then. There would be a huge threat. There have been several in the past, and in order to look constructively into what could be improved, some people came together to actually meet in real life and talk about it. The disadvantage here is quite obvious. Not everyone who is interested is being involved, which can easily lead to, you can call it PR issues, but actually it is simply an issue that there is conclusions being reached that are not necessarily understood or agreed upon by the Debian developers as a whole. The conclusions that everyone agrees on is not possible at all anyway, but at least a broad consensus should be possible. This is a birds of feathers session, so it's actually not a talk, and I would like to invite you all to discuss a bit about what possible means we could implement to improve the Debian mailing lists, for example, to be able to actually get technical and controversial issues resolved in a doable matter. Good. First, I would like to know whether other specific people here that have very strong ideas already on one of those issues. Could you raise your hand too early, I guess, for that? Never mind. Good. There are several ways to... Apparently, on mailing lists, it is very hard for people in general to moderate themselves. There are other communication forms where that is not really a problem. In real life, you have a necessary issue that only one person can speak. At the same time, you can give non-verbal signals, and in this way, you prevent very long and heated threads because there's simply limited bandwidth available. On ISC, that bandwidth is a little bit more available. There are also no non-verbal signals on ISC, so in that way, it is very much more similar than mailing lists. It also can involve basically everyone with internet connection, although, admittedly, not everyone who has access to email has also access to ISC, but it's still reasonably similar. The only difference with ISC is that on ISC, it is accepted to actually moderate discussions. Every channel has usually an operator, and this operator can actually tell people that are not being constructive to lower the voice or lower the frequency of saying something. You were talking about the threats on development earlier, and you said that no real conclusion is reached, and it goes for other mailing lists as well, I guess. What I think you would hope will happen is, even if there's no public conclusion on the list, that the person who started the threat will get a sense of the balance and the ideas within Debian by reading through the threats and taking that into account into the final decision. What may be missing is something like a summary mail from the persons who initiated the threat to say, okay, I've read this and this and this, and my conclusion is this and this and this, and I'm going to do that with my packages or whatever, and I think that that could work. It could result, of course, in a new flame war if there are very strong opinions about the end result, but that would be an indication that it really has not been resolved. So that could be maybe one way to do this, maybe by formalizing such a summary mail in a kind of netiquette or listiquette, so I'd like to get some feedback on that. I think you make a very good point. You addressed at least one issue that there's not a definite conclusion. There are other issues with email discussions that are still, they're not really solved like the volume of a threat can still be very large because of what not everyone who might be interested is actually motivated enough to read all of the messages, and there's also a mailing list, a little representative problem because typically, or typically, it happens a lot that the most vocal posters on the mailing list are not necessarily the persons that are most active in the project, which in theory shouldn't matter as long as simple arguments are posted, but in practice I think this does matter. But the conclusion mail is a good way. It's a little bit difficult to see when a threat has really ended. Someone else thoughts about this? Okay. One idea that's been suggested is to, if you find someone who's just going off on tangent or someone a threat or who isn't being constructive, to just send them a private mail wanting them to know that you feel they're being that way and hopefully if enough people do it, they'll get the message. Yes. This is actually, as far as I can tell, I do it myself also sometimes, not too often, being done. It does not always have effect. And there are, I mean, in some cases like, for example, the incidents on the Debian women lists of late with some troll about death to women's right or something, it's a very clear-cut case that someone is not interested in constructive discussion at all. And then the step for listmasters to take to actually ban someone from the list is an easy one to take. And in this case has also been taken. There are a lot of much more borderline cases that this is not really doable or feasible, especially if people who are otherwise generally contributing might end up being a little bit overheated and they strongly disagree with a certain email or whatever. Some technique that has in the past been implemented by the listmasters, which is quite an interesting way to go about this, is imposing delays on the mailing list of a few hours of specific persons of specific threats. This keeps, this gets the tempo out of a mailing of a threat because, and actually, it mainly forces people in a way to think a bit more before they send an email. One step further would be to actually really moderate people, which is traditionally not really something that people like. Free speech has been uttered often in this context. I see a volume, yes. That comes together with how you, with, yeah, it's a borderline case if someone does not have something really constructive to contribute and still sends a mail like me too or repeats previously said arguments that, for example, the person which that is a reply to did not understand or read. Yeah, sheer volume is one of the big issues. Delays help. Are there other techniques or motivation maybe telling people about their not always even very constructive emails? Good. You can also compare the way mailing lists are going about in Debian, which is said to be quite unfriendly, something to say. I think another way to reach decisions maybe on major issues is to create semi-formal or formal sub-projects because you see that if you define a sub-project, people that are interested in the subject will get involved and then you might try to reach consensus within the sub-project, create a mailing list for it. People can subscribe to that, follow the discussions done within the sub-project and when a conclusion has been reached, it can be implemented within the rest of the project. Yes, this is actually simply creating mailing lists with a lower number of subscribers because it's actually working around for big mailing lists and you note that on smaller mailing lists there is a much less problem of discussions getting out of hand and if you would have smaller groups of people, a special mailing list for a specific discussion, you would actually work around the problem by simply not discussing them on a big list. The problem is how to discover in time that a certain discussion is going to be big there's no way actually really to move a discussion from one list to the other. It generally feels horribly, even though headers like mail follow-up too exist. So the idea is good, it has been suggested before, but I have no really idea how you would best go to really implement this if you're not foreseeing something that is going to be a big discussion. I feel it should not only be creating a mailing list and trying to move the thread there, it should be defining a sub-project and creating a mailing list for that project. So effectively you hold discussion on the subject, create the project, find people from the thread that would like to get involved, publish information about the sub-project, try to get others through other channels that were not in the initial discussion but may be interested in the subject to also subscribe to the project and then start the discussion new. It would not work for minor technical issues but I think it would work and it would make major changes in the project a lot easier to do. It would maybe cost a little time but if you see that the current method is not reaching any conclusion and you just see that the same subject is started over again about a year later or half a year later and you get the same big flame war that was already done a year before, I think in the end it may get better results and it would avoid the thing you said at the beginning that you will get very small groups that are going to try to decide things in private. Yes, I think it's indeed a good idea to split up maybe certain parts of decision-making in smaller groups. Do you have something to say now? I've actually seen some of these small groups being created as a result of some frictions and also as a result of certain needs and in very many cases the productivity has been very low of these small groups because I take some credit for some of them for the non-functioning and I would like to know maybe especially from France and maybe Joey as well because I know you two have been in this Debian installer group which has basically been addressing a major problem in Debian and you have, from what I can tell put together a very productive group maybe you have some tips that made this group be so productive something that would help other groups reach that same productivity because just creating saying guys let's work on this here's a new mailing list I'm going to work on this to join, please go on that's just not going to do it at least not in my experience Same happens with me with DevTags we had the same idea split it in a different sub-project but then we are like five or six of them very small I thought like make it short there's like five or six of them very small and there's conversation that could be interesting to other Debian developers who don't subscribe to yet another mailing list because like there's too many and so I come to DevConf, give a talk and I get really nice feedback from people who've always been around but not in the DevTags mailing list so maybe one of the idea that's been proposed is first creating a sub-project with a subject tag in DebianDevel so that the discussion is still like with people and when it gets major you move it away but then other ints are very much appreciated in this because bootstrapping a sub-project is not that easy in my view Yes, DebianDevel and BigMain is have because of the nature a very big audience and for a lot of smaller projects smaller issues in Debian it is very worthwhile I think to have the general opinion of people generally interested in Debian that is why those lists exist to discuss general development related issues of project related issues for everyone interested in such general discussions to be able to participate the disadvantage is the volume but the advantage is exactly very related to that that you get a lot of different opinions and because of the large group you get sometimes also very valuable contributions it still doesn't really solve the problem of course some people you can wonder whether this is very person related the way people behave on mailing lists and there is sometimes we noted that when a discussion a big discussion is running out of hand one or two always at least two or three people very very interested or very very specific ideas about a certain subject want to continue to get the point across and convince others by mostly repeating arguments drag a discussion to a place that is not really productive anymore and now we lost my why if I could break in one thing that I found works pretty well if you're still in the process it's still in the point in the process where you're on a large mailing list you're trying to get something going is to first of all you really have to take somebody has to take some kind of a leadership role and try to point people in a constructive direction and then you need to find a way to recognize people out of the thread who are actually doing something for example when I started the secure testing stuff it was all done on I believe Debin release and Debin security mailing lists I don't have volume but still I found people who were posters of the thread and then who I managed to convince to go on and do other things and that's a good way to build up a team while you're on those lists yes for careful readers of big threads you can face out the interesting people, the people that have valuable contributions and then select them to go further in a smaller project and more constructive and sometimes it will be a very big thread and then it will for also very interested people not be possible to actually read everything I myself for example still didn't read and probably never will read most of the threads that happened after the Vancouver thing he was posted because it was simply way too much and it quite quickly became the signal to noise ratio was too low for me to actually find the interesting post in it so while you can still find the valuable contributions if you have time enough the disadvantage of at the high level of noise you won't solve that way yes I believe it works I believe Martin asked specifically about project SCUD and I wanted to talk about that a little bit I'm very pleased to hear that you find it to be successful I think those of us within it pretty much can only see our frustrations because we have such high ambitions we've been thinking we'd be able to get together for periodic real time meetings and given the time zone spread that we have and the extremely busy schedules of some of us that's turned out to be difficult so what our working pattern has fallen into is we rely upon a few resources we rely upon a subversion repository a mail alias it's not a mailing list and an IRC and what IRC is useful for is just for us to brainstorm with each other just drop a note just uploading ideas or just finding out the status of something that's going on it's the kind of thing that people do all the time with queries privately with each other and IRC we just have a channel for it and we use it for that I personally think there's a lot of benefit in SCUD which is probably applicable to small teams in that the sense of accountability you get to a small team is different but people don't feel accountable to a large project I certainly feel pretty accountable to the entire body of Debian developers but it's difficult mentally maybe this has something to do with Enrico 7 plus or minus 2 rule and I'm not joking it's difficult to conceive of a one-on-one accountability relationship to a thousand Debian developers it's very easy to think of myself as accountable to the other members of project SCUD so if I'm dragging on something if I'm not being responsive it's very easy since I know these guys in person now everybody except Steve Langasek who I've known on IRC for years so it's almost as good it's very easy to feel a sense of personal connection and responsibility to them and so in a way they serve by proxy to represent the project to me that certainly doesn't mean I do without communications with the rest of the project I try very hard to do that and maintain a personal relationship with as many people in the project as I can but again you can only keep so many items in your head and it does me some good to know that there are these six people you know basically keeping a close eye on me does that help? Does that give you a little more insight into how things work? Is that to me? Yeah It kind of does, I mean It's rather difficult to respond to that because my the kind of teams I was talking about is more like project related some sort of small packaging area or something like that I mean maybe I haven't made myself perfectly clear and then you kind of answer with project SCUD which is sort of on top of something else but I kind of understand what you're getting at you are from what I understand project SCUD pushes for openness or tries to push for openness I think I'm at a different level I'm even before getting to that stage where openness is even important I think it's more about a motivation thing it's more about a coordination and I can't really formulate it properly it's more about a I think it's motivation more how to keep people together and actually make them realize and work on something I guess I was talking if I say earlier today I don't actually know what day I'm referring to but if I say earlier today I was talking to someone so that was yesterday and basically it's all about the like if you don't like what's currently going on go and do something about it don't complain or don't talk about it and that's kind of what I'm getting at is the the kind of person that goes ahead and creates a mailing list and creates a nice project name and goes ahead and does and pretends to do something and then actually doesn't do something whereas on the other hand those that actually get to achieve are those that actually do something even if it's underground like it's not visible there's no mailing list at the beginning it's completely unorganized but those I guess that is kind of like how a lot of the most successful projects in Debian got started and actually carried through until then at one point in time somebody said now it's about time we can actually create one of those mailing lists but it's this initial stage that of how to get people together how to actually make people believe that in fact it's not important let me back up for just a second one of the important, there's a book called the understanding open source development by Fitzgerald and Joseph Heller and one of the main points they harp on is the main reason we are all sitting here in this room is because we are being recognized for what we do that seems to be sort of one of the main motivations of open source development and if you actually sit down to do something without a lot of visibility without a lot of publicity then you're not getting that recognition and yet a lot of people are actually managing to do this to pull other people together I completely understand that the idea of whether I'm actually going to bitch about a problem or talk about how a problem could be solved is completely different from whether I actually managed to sit down and fix a problem that is an entirely different issue for me but I'm trying to get at is how do you get other people to work on that same problem how do you make other people how do you motivate them and that is the reason why I don't really see an answer in your explanation of Project Scud Personally Project Scud more as it's not entirely the same but it is in some ways very similar to developers simply discussing issues over beer in formal ad hoc groups it's a bit of a meta discussion trying to see where problems are and which people are maybe good to put together to actually work on an issue I think that is a more important function for project-wide I mean next to the function of giving a way of Brandon Robson to reflect ideas then actually discussing and solving the issues as Project Scud itself you had something to say at the risk of making this the Martin Kraft and Brandon show then let me try to since you've right exactly it's your show so since you've clarified what you're talking about a little more let me offer my thoughts I think part of the problem comes from a couple of good-natured instincts which is that in this project of a lot of openness we want to bring things out onto the table and sometimes it's difficult to identify a problem area without being perceived as complaining no matter how you couch it no matter how diplomatic your language and yet that is exactly the kind of thing you have to do if you aren't already strongly socially networked and you don't know who to turn to the community around your problem you're wondering how do we get a small team off the ground to tackle a problem well if you don't already know who cares about it the only way you can find out is to go ask so I think you look like you're looking at me like I'm speaking utter bullshit so well I think that's a good oh okay he's wondering whether that actually works in Debian and I'm trying to think of a case where I've done that personally and I'm not thinking of one but I'm not coming up with one but I mean what's the alternative to stay quiet or to labor alone in a silo hit some brick wall and then not be able to get anything done because you've reached the limits of your personal knowledge as we've scaled up in the project as we've gotten so large the number of people who are able to editorialize on something has grown faster than the number of people that can reasonably work together on something you know because the optimal size for a small team as Andreas is fond of pointing out it's in the low single single digit integers probably maybe as many as nine people again we have Enrico's principle this is the everything principle it explains everything seven plus or minus two anyway so in the early days of the Debian project that was a significant slab of people working on anything but now you might be able to have nine people working on something but 999 just being able to do armchair commentary and one of the things that makes it difficult is not all of that commentary can be thrown away a lot of it is insightful and useful and I think a lot of people get paralyzed from taking action because they do know that they know they've got to put together they've got to get together with their peers to solve a problem and they don't want to exclude those who have meaningful feedback but if you you know if you spend time grappling with every single point of critique that comes up you will never get anything done and I don't have a magic bullet for dealing with that apart from just you know advocating a bit of egotism on the part of the person trying to get something done to just bowl forward and try to achieve something positive at the same time you've got to have the intellectual maturity to realize when you've failed and to try to help other people learn from your mistake I remember the NM talk the other day where we had various approaches to the NM process until it stopped working so it's not easy but I think if we can articulate the challenges involved in getting these kinds of things done it might lower the level of acrimony just a little bit I'm hopeful that way anyway so anyway I've talked long enough about the 7 plus minus 2 thing it's indeed difficult for to get short to the point friends but if you look at other projects it actually seems to not always be impossible to do so I have not really read a lot of Ubuntu lists but rumor has it that it has a certain amount less flames and can actually reach a lot easier consensus on it and I'm not entirely sure of why that is I have a few ideas I'm wondering whether someone has a real maybe a more funded idea of why it in Ubuntu might work better than in Dabin at the moment Ubuntu is of course quite new in Riko it would be interesting to have Miko in the crowd but I guess he's not awake yet so I can try to repeat like the two or three arguments I've heard in the past and quite, repeat them quite blindly because I've only been involved in a very minor mailing list in the Ubuntu community which was a bit special and point number one was that when Ubuntu has begun it began on top of the Ubuntu community guideline and the Ubuntu name itself has a strong community related meaning Ubuntu means being kind towards others and understanding that you are nothing as yourself and you only have a meaning in the context of a community kind of like losing the boundary weakening the boundaries that separate the individual with the community that's like the meaning of Ubuntu you can also so they're the board man board ah the board kind of so with the guideline has shaped the community a bit and when a threat gets flamish someone tends to invoke the guideline and bring it back on track and another one like in the development side that's been said is that they have a strong leadership as in I don't pay you anymore if you're an asshole which helps to deal with the craziest cases and one other issue is what is also involved there is and the smaller community they are smaller they are smaller Ubuntu is very new while Debian is already 12 years old and Debian discussions on Debian I don't think they always used to be Debian used to be small of course so then discussions could be productiver and you also notice it in the involvement of a number of key Debian contributors who contribute a lot for like often around 10 years how much do you see for example BDL post on a Debian devil mailing list not really often and I have the feeling this used to be more if you look back at the archives maybe Ubuntu will end up the same way as Debian would be it's hard to say future will tell but what Ubuntu started out from the beginning and that is of course in a big part thanks to the hints sides that Ubuntu community creators have because they have Debian to look at and see what is actually not running so optimally in Debian is the immediate creation of a code of conduct and applying it quite strongly and one could wonder whether it would be a good idea to have the same in Debian if you have such guidelines of what is acceptable we do have this policy but it's actually quite not enforced at all on spam policy thing that is quite obviously completely unenforceable so it's a little bit a joke and the real community guidelines would be a good way to actually also stop the minor contributions of people that do not have very misconstructive things to say so I myself would be quite in favor for such to introduce a sort of code of conduct on the mailing list that is more or less being voluntarily enforced by simply telling people about violations may I have a small quick vote by hand raising we would think initially like yes such a code of conduct for Debian would be a good idea we would think that a code of conduct in Debian for mailing list would be a good idea to have to introduce okay we'll do some I mean a real one yeah really yeah I yeah but the current one is not really adequate and if you compare it with the text of for example the Ubuntu code of car lines it doesn't cover the social aspects or in refrain from posting when you not have anything really valuable to contribute etc other people who think that would be a bad idea to have a code of conduct on the mailing list none sorry you think the current situation is basically okay no I don't but that doesn't mean that any conceivable social code of contact we post is going to fix it or make Debian a better place it's really difficult to regulate speech in this fashion and I think people would be uncomfortable with the idea of having a team of commissars who subjectively evaluate things like well you have nothing useful to add or you know you're just excessively bad we're going to kick you out I mean the way in Ubuntu the code of conduct actually enforced is not by having some set of moderators or whatever that actually apply this code of conduct to the mailing list members but actually by simple people on the mailing list informing the poster of their violation of the code of conduct and because it simply stated as facts that it will be enforced in whatever way people will tend to listen to that well we try to do the same thing with the social contract and the Debian free software guidelines and that doesn't impress some people either they say it's just a mantra that we're reciting and they keep on blathering so I mean I don't want to I don't want to be too negative about it but those social contracts and DFHG but especially social contract is not specific to communication in Debian no but they're sometimes used on Debian legal as an attempt to stop a thread and sometimes they do but often they don't because someone just wants to keep going I'm very sorry we lost the time for the first time we totally forgot about the time maybe because we all had in the discussion thank you sorry we are over time