 We can get started. Sure. Hey, so this is Wouter. Hi, Wouter. Wouter. Wouter. Thank you. Sure. Sorry. Ryan's with Wouter. And not with Scooter. Not with Scooter. And we're going to be talking about Debian code of conduct. And it's a bit of a feather session. I expect that we'll be running some microphones around. You all will raise your hands and we'll get to you as quickly as we can. Yes, please. Right. Just a few introductory words. First, where is this coming from? I actually started a discussion on the Debian project mailing list a while back to update the code of conduct that we already have. Just a show of hands. Which one of you knows that we have a code of conduct? OK. Which one of you thinks it's a good code of conduct? Well, nobody's very confident. Just to show you, I mean, this is our current code of conduct. There are some things in there that I think are fairly silly, things like do not send spam, send the advertising, to look at the advertising policy. We have an advertising policy to deal with spammers. We don't actually ever use it. I don't think that's useful. There's something in here which I think is totally irrelevant about swearing is illegal on package radio. So you should not swear on our mailing list. I don't know what that has to do with anything. I think it requires a citation needed as well because who received the package radio? I don't know. Anyway, so I think this is totally, completely, utterly useless as we have it right now. And I think we should throw it out or we should update it. And that's where this is coming from. Originally, I wrote some proposals on the Debian project mailing list. We had two drafts there. And then it was pointed out that maybe rather than updating the mailing list code of conduct, we should migrate more towards a generic code of conduct. That idea held some merit, but it required more time than I had at the time. So I did it during that camp. And the idea now is to go over the proposal that I wrote. I'll close this so we can actually see. And that we can discuss it, maybe update it. After that, we'll have to post it to some wider audience so other people can come in on it as well before we can, of course, put it to a vote. So just to keep things a bit structured here. It is in Gobi. Everyone can eat it. But I would like to ask that we don't just go ahead and change things, but that we actually discuss things for it before we update it. Should be fine, right? Other than that, I'll just go over what I wrote, and then we can discuss things. First of all, I wrote a little bit of my goals. I think a code of conduct exists primarily to improve collaboration and to give people tools to work against people who are not really helping our community forward. I think, therefore, it should be a short list, not a very long list, because if it's 70 pages, nobody's going to read that, then we might as well not have anything. So because of that, you can't possibly enumerate everything, so you should be somewhat fake. If you actually read other codes of conduct, I think they are similarly somewhat fake. And I think it's actually a good thing. I don't actually explicitly say so, but in the code of conduct itself. But assuming common sense, good sense from people who read it is probably a good thing to do. Those who don't, we can deal with it in other matters. We shouldn't try to fix that before the fact, because we're not going to do that anyway. As I said, I read several community codes of conduct. Stefano Zacchiroli actually made a list on the Wiki, and I went through each of them, read them. I used some of the concepts from them. They're not much of a language. We'll see. So let's go a bit down. The first item in my list is people should be respectful towards one another. That's actually something that comes up quite often in the other codes of conduct. So basically, the titles are meant to be normative, and the rest is meant to be an explanation. So the explanation here is saying, in a project the size of Debian, inevitably there will be people with whom you may disagree or find it difficult to cooperate. I think this is true for any community at a particular size. And we say accept that, but even if that is the fact, even if you find someone difficult to cooperate with, remain respectful. Disagreement is no excuse for poor behavior or personal attacks. And a community in which people feel threatened is not a healthy community. It's okay to disagree with someone. It's not okay to let this agreement turn into a problem for the community as well. Any comments on this, if people... Do we think this is a good thing to... Yes, go ahead. I don't like the last phrase. It's not okay to let this agreement turn into a problem for the community as a whole, because I think it's a two-sided thing of two... Well, of two sides who communicate and... It may be a bit harsh is what you're saying. It may be a bit harsh is what you're saying, or do I get your wrong? Well, if I disagree with somebody and I'm called names and I don't react to that, people may... I see a point, yeah. May call me for turning it a problem for the community. So... She's correct. It sounds like you think there's a bug in this because if somebody's not being respectful to you... I mean, as far as I understand it, the situation you've described, the person who is not being respectful to you about calling your names is already violating this, and it would be helpful for everyone if everyone saw that calling your names was a problem for the community as a whole and you reported that. So I don't understand what's wrong with this statement then. It seems like you like it. Sven, in the back. Somebody give me a mic. I think that saying that it shouldn't turn into a problem for the community as a whole is giving it too big scope so that relatively small things might turn into a problem for some people, not others. So is this a problem to the community as a whole? No, I see a point. In the end it is, but this phrase just makes it open for too much interpretation, I think. Maybe that's true, right, right, right. So we should probably adopt that phrase then. The point is, I wanted to final, finish a statement that it's okay to disagree with someone but keep it reasonable somehow. Maybe this phrase is indeed a bit too strong and we need to drop it. Ian, go ahead. I don't think the problem with it is that it's too strong. I think that it's too vague. Or that, okay. What you need to do is you need to say what kind of disagreement is good and how we should, I'm not sure I have a good form of words, but we should have something like, it is okay to disagree with someone, this should be done in a positive way or in a constructive way or something like that. Happy constructive way, right. Lucas? Yeah, my point is similar, actually. I think that this will be used as a way to point people, we pointed to it showing that the behavior was not respecting the code of conduct. So you need to give some examples and some people need to draw a line and what is acceptable, what isn't. And with that paragraph, it's very hard to change. If you don't give any behavior, it's acceptable or not. The only comment that I have with that is if you start animating things that are bad, then you will inevitably forget something and people will do something that is bad and it's not in the list, so it's fine. So I'd rather not go down that path. But I understand your point. Yes, go ahead. I think it's also a bit, in the current wording, it's the problem that it speaks about the disagreement. In some form, every disagreement is, if it takes a longer time, a problem for the community, but even a disagreement in total respect, if it's about something important and we cannot resolve it, it's a problem and it has nothing to do about being respectful. Yeah, so maybe we should, anybody else, go ahead. Yeah, perhaps it should just mention what kind of disagreement is a good disagreement. I mean, when you are offering technical aspects that you think are valid points opposing your discussion partner points, then that's okay. If you turn it into a personal attack which is already listed in that explanation, it's just getting into the wrong path. And maybe this whole last phase should just be removed. And the hope, yeah, it's okay to have a disagreement, but keep it on a factual level instead of a personal. Would anyone want to update that on? I think indeed, going down that road is Ashish, go ahead. I was just gonna propose removing either the it's not okay dot, dot, dot clause or removing the entire sentence. I think that that doesn't add anything, luckily. Okay, so let's remove that part at least. If we're going to remove this though, I would certainly add some qualifier, but maybe this qualifier, that's the point. What's meant to be a qualifier, if that's not a good qualifier, I can buy the document, but then we need something else instead. If you remove the whole sentence, I think the paragraph stands on its own anyway. Just remove it, okay, remove it from here then, right. This is actually turning it into a title now, it's not a comment, it is marked down, so that's not a good idea. Right, so, any, yeah, remove that too, right, thank you. Any more comments on this paragraph or are we good? Does that satisfy everyone's objections? Okay, let's move on to the next one then. So, this one is assume good faith. This is actually something I think I came up with myself and I'm totally sure. So, what I've observed in many discussions is that people will sometimes react to a point on the assumption that people are out to get them. I'm putting it very, well, I'm exaggerating here a bit, but I think you understand what I'm trying to say. And the point here is to get people in the mindset that if somebody is doing something that you think is wrong, assume they mean well, because we're all basically trying to get Debian forward. We may have differences in agreements in what the best way to do that is, but that doesn't mean our end goal is different. And for that reason I think it should be, yeah, that should be clear. So, I'll just read the paragraph first. So, what we say here is, a project the size of Debian has many people working towards a common goal of a free operating system with a link to what we mean by free. Sometimes the ways in which we try to reach a goal may differ from one person to another and sometimes one person's immediate actions may be contrary to another person's, but please do not assume that people are purposely working against your goals. They may just have different goals that you don't understand, if in doubt, ask. Remember that it's more likely that people are unaware of their bad behavior than that they intentionally try to degrade the quality of the discussion. Any comments on this? I think you had one, Ian, go ahead. Right, so I'm pretty happy with what you're trying to do here in this first paragraph. Right. But I think the wording could be improved. Firstly, by making it more personal, so by saying sometimes someone else's immediate actions may be contrary to yours. Right, yeah, I think that works. Because that makes it seem more personal to the reader. Right, that works, yeah. Also, it would be better to say that somebody else's actions may seem contrary to yours, and that is indeed failing to make the very assumption that we're telling people not to make. Right, yeah, right. Yeah, it may seem to be, yeah, you're right. Okay, I think that's fairly non-controversial until someone disagrees. Can we make a change? I just want to mention something about the style in the previous paragraph. You mentioned a project of the size of Debian. Here, a project of the size of Debian. And the next time Debian is large and complex projects. Maybe it's reiterative. Maybe that's redundant, yeah, good points. I hadn't noticed that, yeah, thanks. Erika, go ahead. I believe that description contradicts the title of the description. The moment you assume good faith, then you do not, in my opinion, you should not say that, make go into details about people not assuming good faith. I mean, when you say do not assume other people are purposely working against your own goal, if I'm a new contributor and I read that, I expect to see a community with problems and where the majority of people think that everybody is else to get them. I believe the code of conduct should give the good example and assume good faith on the people. And then you can say, if in doubt, assume good faith without going into details saying, don't do this, don't do that. Because it's a bit of the same problem with the first point. And it's probably a structural problem of it all, which is the non-smoker problem. When you see a non-smoking sign, you feel like smoking. Because that puts smoking into your mind. Right, right. I'll go out on a limp and assume you don't have any better suggestion to this paragraph. It would take me a while to think. Yeah, yeah, that's what I thought. I see a point, but yeah, Ian? One here first. Oh, sorry, go ahead, sorry, excuse me. No, I forgot it. I think what about keep in mind that we all have similar goals and that other people might have only other means to get there? Basically, yeah, I like that. It's more of formulating in a positive sense rather than this somewhat negative sense. I like that, that's good. Right, exactly. That's more or less what I was going to say, which is I think in general, it would be a good idea to phrase everything in terms of do this, assume that, rather than here we have do not. Yeah, right, right, right. Good idea, good idea. So the question is only how do we do that in this particular case? Anyone willing to suggest a, or Ashish, would you do the same thing? Yeah, go ahead, sorry. So I'm gonna read the paragraph but change it as I read it. Right. The project the size of Debian has many people working towards our common goal of a free operating system. I'm just skipping that, sorry. Well, that part was just reading out loud. So it was just there, okay, go ahead. So this part you would not change, go ahead. The contributors of Debian have lots of ways of reaching that goal, reaching those goals which may differ from your ways. That sounds good, I think. Well, lots of sounds a bit informal though. We can patch that up. We can patch it later, nevermind. It's helpful to assume that other people are working towards these goals. Semi-colon, when you, wait. We can fix it up later. Oh, yeah. Just keep on reading, I'll type it off on the video if we don't get it. Okay, yeah. So for the next sentence, it's helpful to assume other people are working towards these shared goals, semi-colon, if in doubt, comma ask. Period. And I'm not sure about it's helpful too, we can strike that. I have a patch for what you just said, when you say the contributors of Debian have, I would change it with Debian contributors have. Okay, so I get my laptop, but then soon I assume there's a microphone around. Wait, capitals, obviously, yes. I think we are mostly in agreement that if we phrase this as a positive rather than a negative explanation, we should be fine, or just, yeah, Sven, go ahead. Yeah, I'm just thinking one of your goals is to keep this short. Right. So I think that the first sentence just doesn't really belong there. We all know we are talking about Debian, we all know it has a common goal. Good point, good point. So it doesn't really add to this explanation, we can start off by saying we have a common goal. Yeah. Period, and then. Or just the Debian contributors have a common goal. And many ways to achieve that. Yeah, and stating that level of obvious does risk-sounding patronizing a bit. Fair enough, yeah. Okay, so we'll, yeah, I think that's fair. So we need to reduce that and turn it into the positive. Is there someone in the back who wants to make a statement? Oh, there you go, go ahead. I wanted to point out, if we want to put it in a positive way, we may, I don't have the words, but I have the idea we should, or we could say that everyone has different goals and different ways, and that's a good thing. And that helps us. Yeah, the fact that you have different ways does necessarily mean it's bad. Yeah, that's a good point. Okay. Somebody's making very good. While that happens, I'll. May I ask my question? I'm sorry, you had a point, excuse me. Yeah, my point was we discussed about disagreement before, and I think, I mean, that's quite an important point because actually this whole document is about disagreement, or disagreement situation. So maybe we should have an introductory point that actually mentions that we're happy about disagreement because it helps improve. And there could go all this discussion about debbie on its large operating system. We have many people we expect to have disagreement. Very good point. And we're actually happy about that. Very good point. Here is how we want to handle this because it helps us to produce a better product. Let me go up and see. Right, so that probably would go. I think that appreciating that we have disagreements is actually for the next section that's possible. What was the title again? Be collaborative. Be collaborative. Maybe we should make this the first section then. Maybe, we'll see, I guess. Right, so this part actually comes from the KDE and some, oh great. When I first read the headline for this Assume Good Faith, I think there should also be mentioned sort of language barrier. People tend to not be native speakers in such a big project. And there's also room for misinterpretation because people understand certain words in a different way. I did consider that when. This should be put somewhere. I did consider that when writing the original draft of this, but decided against it because it became too long if you start enumerating all possible ways in which people could be misinterpreted as not being of good faith. So it's a point, but unless you strongly disagree with it, I don't think it really belongs in there. Sven? Yeah, I was just demanding that it's not only that many people are not native speakers, but we come from a lot of different cultures. Exactly. And that often means that even the same word, if understood correctly, can mean widely different things. So that's exactly the reason why I didn't want to enumerate because there's too many ways in which it could be misinterpreted. Right, go ahead. I just think we should keep that in mind. Maybe we might add a small section about this to just be aware of differences in language and culture. Right, we'll see. All right, so any more comments on this section? No? Okay, we'll move on to the next one then. Yeah, you do that, do you have still the? That's your patch. That'd be interesting. Anyone have, I think this looks really well in my opinion. Anyone feel opposed to this? To replace my proposal with a Jesus version here? Yeah, go ahead. Two mics, use a bit too much, I think. It sounds, it has a little bit of danger that we get the new standard insult that people will ask on the mailing list, are you doing this in good faith? Which could be the new form of asking, are you twirling? That's a good point. Sorry if I miss it, but ask who and ask where, is that specified somewhere? No, it's not specified, yeah. Because otherwise maybe just drop it or, I don't know, because right, people will just ask. Well, if you're in doubt, then you're not assuming it anyway, so maybe you should just drop it. If in doubt, assume good faith. Right, that's what the entire section is saying, so the if in doubts part should maybe just leave. But even if I do agree that the ask thing shouldn't be there, it should be somewhere too, because it clarifies a lot of stuff, whenever you, you're talking with people. Maybe you can add this to the section that Sven was talking about, about introduction, yeah. Enrico? I'd like to point out that most of what I see there is completely redundant with the Debian diversity statement. Some of it is, you told this at the bar to me earlier. Yeah. I disagree, because the diversity- Well, especially that green thing is a longer and, well, less beautiful- Basically what the- The phrasing of- Basically what the diversity statement says is, we welcome you if you're constructive, something like that, right? No, no, no. In that case, it's no matter how you describe yourself. Oh, this one, yeah, this part, yeah, that's true, that's true, that's true, yeah. We accept your contribution and, well, it's- I think this should add to the diversity statement, otherwise, or it should complement the diversity statement, not try to replace it. No, I see a point, I see a point. Sven, go ahead. Yeah, I don't think that repetition here is really bad, because many people might be aware of the diversity statement, but many people won't and won't actually read it, even if they get all into it. While many people actually look actively for code of conduct. The code of conduct can link to the statement. That would be a good idea. And the statement is three lines, so it can be at the beginning of the code of conduct. That's also not a bad idea. Yeah. Right, anything else? All right, I'm sorry, I don't know your name. I've been just pointing towards you there, anywhere? I can't read from here. Vanhub. Oh, right, okay, go ahead. I think the diversity statement might be a bit of a distraction here, because it's a little bit different. Diversity statement is that we accept people coming from different things. Here it's more about the indifferent language we speak, including culture and language. Okay. I would like to move on now, because we are about halfway in my talk, in a lot of time, and we're not halfway through the material yet, not even remotely. So we can discuss this at length on the mailing list. I think it's clear that we need to do that. We, at least the worst parts have been removed from that. So let's just move on to the big collaborative. This I actually got from KDE mostly, and some other projects that have a similar clause in there. Again, the is large. We should probably remove that, as Baby said. It is impossible for any person to understand. Do not be afraid to ask for help when you need it. There is no shame in accepting that one cannot do a particular job on their own. Similarly, an offer for help should not be seen as a personal attack. When you made something for the benefit of a project, be prepared to explain to others how it works so that they can build on your work to make it even better. And Nico, go ahead. There is no shame in blah, is patronizing possibly anytime it happens. I think this document should be an enabling document. So I would be happy to see lots of phrases starting with it is okay to rather than there is no shame in. So it is okay to ask for help. Right. It is okay to- I see. Yeah. Yes, yes. So just for the record, I said that it is actually good to accept that you can't do everything on your own. Right. And especially. Anyone want to change it in that manner? You want it? Okay, thank you. What happened there? All right, good. This is so near to very interesting. Anything else that we want to modify on this section? Or is it good, I'll just scroll down with she's doing a lot of weird things here. Not that much. I have to admit that- Who's talking? I don't see you. Be prepared to explain- Oh, right, yeah, go ahead. Yeah, go ahead, go ahead. Be prepared to explain part sounds a bit threatening for me. It sounds like, yeah, you can do it, but be prepared. Yeah, this part, this is because I want to make collaborative, you can only collaborate if it comes from both sides. And I wanted to point that out too. But yeah, given the, I mean, I've only written this by myself, and maybe go ahead. No, the mic is off, I think. Do we have a? It's not working. Is it open? I don't know. Oh, go ahead. I like that paragraph. Maybe the wording could be changed. But I guess what we would like to say here is that whenever you propose something, try something, do something, some people are going to ask you about that. And because it's a collaborative thing. So don't be prepared to explain. I like that fact, maybe with other words. But I like that because it means like you're not working alone and people are going to ask you about it. That's indeed my philosophy behind it. But I understand that it could sound somewhat threatening. So the main question is how we take that out of it. But that was indeed my philosophy in writing it. So we'll link with three else, interesting. Any other comments? Sheesh, go ahead. Sorry, microphone. Does it work? What do you think of my patch? Do you want to merge it for the first? It's minus, minus, minus, minus, plus, plus, plus, plus, plus, plus, plus, plus, plus. I could run WDiff if you wanted. No, it looks, it looks, I think it looks okay. But I don't know about other people. Any comments on the Sheesh's version? Yeah, go ahead. Didn't we have an, it's good to ask? It's okay to ask you, it's good to ask you. I think we said it's good to ask you. Anything else? No, let's move on to the next section. Try to be concise. This is both to avoid long emails and to avoid long threads. Both are problem. If people send you an email with 70,000 pages, then nobody's gonna read it or you need to postpone it and that's not really helpful. If people send the same message to a thread over and over and over and over and over and over and over again, like some people tend to do, then you have an issue there as well. So that's what this is trying to be, to discourage it. I actually found that in one of the other codes of conduct as well. I think this was in the GNOME one. Making a conversation larger makes it more difficult to follow. Writing a long email means people may have to invest large amounts of time to understand it. When a long explanation is necessary, consider whether a summary is appropriate. Try to avoid repeating arguments that have already been brought forward. This rarely serves any useful purpose. Try to stay on topic, especially in discussions that are already fairly large. Any comments on this section? Andiko, go ahead. I would just keep the title and the honor, the point you're trying to make by giving an example. Try to be coincide, no text, skip to the following one. That would be interesting, but... It's far too verbose for something that's trying to tell me to be coincide. I see a point. Ashish, go ahead. By contrast, the idea about adding a summary is kind of novel. I mean, so there is some content here. Yeah, that's what I was hoping for. It's already a failure if you have to add a summary. I don't think so. It's not a summary for the long email. Well, some things just can't be explained in 10 words and do need a long explanation. I mean, I've been there myself for instance when we went to Keel for an MCCRK meeting. We, no, sorry, it was something else. I gave a very long technical explanation of why something was necessary. And then I just explained, but this is what we really suggest. Sometimes you can't go around it and it makes sense in some cases to do that, I think. Go ahead. Maybe if we would like to make a point here, in addition to suggesting using a summary, we could also suggest structuring the text for the long email like in articles. So you have a short summary in the beginning and the structured email because you can follow a long structured email where you can't really follow an unstructured one easily. I think we're good. Honestly, I don't think we should really come up with new ideas to structure emails in this code of conduct, at least not in the first version. I mean, this should be also about the current practice which is positive and not trying to, I mean, this is an experiment. And you say, everybody should start a summary. Maybe it goes nowhere and it's really bad and people start complaining, where's your summary? And so, yeah, this is the code of conduct. So I mean, I think the idea is good. I mean, we should explore it but maybe not in the code of conduct but first outside of it and then if it goes well, we just put it in in the second version. I did try to make it clear that, I mean, I said consider adding a summary. I didn't say add a summary. IETF. Well, yeah, the point here was really to say, maybe, okay, sometimes this may be helpful but it's something you need to decide. There you go. What I need was talking about the IETF must-shall definitions and so on. I think it nailed something that I was asking myself. So far, I appreciate that this is a dump or, well, it's a formulation of concerns that are shared by many Debian developers. That's the goal. Right, but how, so it's, it could be like we are concerned about these and I respect those concerns and I share many of them myself. Right. But how is this code of conduct going to help? Is it a tool for them to kick people out? Is it guidelines to teach new developers? That's coming down. We're not there yet. We're not at that part yet. But any further comments on this section? Anyway, I cannot give comments until I know what's the point of this. Right. In the back. Yeah, we'll come there soon, I hope. I just agree. It's useful to know what this is all about. I'll skip through that one. There's actually only one part here which tries to encourage open communication as opposed to private communication with Debian in, yeah, in referring to the social contract paragraph three which says we don't have problems. I'm not sure if this is really necessary out of there. I think it was a good idea, but maybe it's not. Basically what I was referring to is the in case of problems as follows now. We'll come back to the open if we have time or be open if you have time and otherwise we'll just look at this. The idea here is to say, so it says literally, well, this code of conduct should be adhered to by participants. We recognize that sometimes you may have a bad day or be unaware of some of the rules in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct. In particular, it should not be abusive or disrespectful. Assume good faith. It is more likely that participants are unaware of their bad behavior than that they intentionally try to degrade the quality of the discussion. Repeated offenders may be temporarily or permanently banned from communicating through Debian systems at the medium's administrative prerogative. That's what it says. So basically, yeah, 10 minutes left. So basically the idea here is to try to have people enforced by themselves. Most people if told in private that they are doing things that they think are not helpful will change the way, stupid flies, will change the way they are acting. And some will not, but List Masters today already will temporarily ban those people from our lists. IRC operators will temporarily already ban those from people from IRC. And I think that kind of way works well. Go ahead. Did you have anything to say, I think? Or are you just holding the mic? I'm just holding the mic. Anyone have any comments on that? Yeah, go ahead. What does medium's administrators prerogative mean? Originally this set, because originally this, as I read it, I fell over the sentence and I don't like it myself anywhere either. It originally set at the List Masters prerogative. So the idea was that it is their judgment call whether or not. So are these List Masters Debian, well, leaders delegate? Or I think they are, Lukas? No, nothing else, okay. No, because then I think that's a bad description. The idea here basically is that people should at first comment when they think somebody is misbehaving. And if that doesn't happen, we should talk to ideally somebody who is indeed a delegate. I thought List Masters were, if they're not, then we need to maybe need to revisit that. There you go. When you suggest that the Code of Conduct should be pointed out to people. Right. I see, so that means that the Code of Conduct becomes something that peoples might in my face every time I'm having a bad day. It's a recipe for disaster. There's no way people get to like it. Well, it's a strategy that means that people will increasingly get to hate it because it will be used by patronizing self writers, people that decide that they're better than everybody else that they send it to everyone. But if it's something you point people when they don't behave in an optimal way, then it's a guideline. If it's something that brings people to be banned, then it's a normative thing. The two things not necessarily fit in the same document. If it's something that you are banned from, then it's like, don't do this, don't do that. If it's something that is a guideline, then it's like doing this is better, doing that is better. The idea is that, I mean, repeated offenders, the idea is that people who are, yeah, Ashish wanted to say something too. The idea really is that people who really cross the line by a very large extent would be banned because we don't really want them. Whereas if you do this occasionally, it's not really a big deal. Ashish? I think it's an interesting theoretical problem. I don't know of any, oh. I think it's an interesting theoretical problem in RICO. I don't think that it's been a practical problem for any of the dozens of communities that have had codes of conduct, and I think that's interesting by itself. Even those communities that have codes of conduct, ah, maybe it's a counter example, that contain lines like this. I also want to mention that to make a long story very short and make it recorded on Debacont video forever, I kind of academically trolled the UDUDS key signing party a year and a half ago, not realizing that I was being a jerk, and the person who was organizing it emailed me and said, hey, I don't think you were, and pointed to whatever line means be respectful, being respectful to me as the organizer. And I was like, oh wow, I feel awful, and then I had to have a conversation with him, and then we all came to a happy conclusion. That's exactly the kind of behavior that I was expecting myself to, and that I would like to see encouraged by people. Indeed, if people start pointing out because people are having a bad day, then they're not really being respectful either, and they're not following the code of conduct themselves either. So Ian, you wanted to say something? Right, so one of the main reasons for having a code of conduct is because precisely the people, the forum administrators, like Listmasters, need really to have a clear mandate from the rest of the project about what it is that we are expecting them to do for us with respect to the policing of behavior on the lists. And therefore, and that is one of the main purposes of something like a code of conduct. Now, the problem of being slapped down in public over alleged violations, I think that should be dealt with in the code itself. You should say, you know, don't do that. That's a short five minutes. I just wanted to respond to Ashisha's comment that it's never a problem. In fact, people use the current Debian List code of conduct in at least an irritating way. I don't know if it's actually destructive, but it doesn't seem constructive to me, in many cases, to tell people that they shouldn't CC. I totally agree. I mean, and so on, and you could argue that that's just because the list code of conduct is maybe not as constructive as it could be, but it's not. No, I agree. And I mean, it's actually, you may have noticed there's a section here. We'll probably won't have the time to go over this one. It contains some media specific codes meant to be clear. One is for email. There's one for ISC and there's one for Polana Debian, I think. This is actually based on the draft that I sent to that project originally. So I have not changed this much. And you may notice that the CC stuff in there is just totally out of that, because I completely disagree with that kind of thing, apparently we're out of time. But yeah, go ahead. One thing is, if people point out that someone is misbehaving and it feels like you're being slapped in the face, then usually the people that are pointing it out to you are the people that are not following the code of contact. And that's something you can't really address in that way. People will always be disrespectful when I'm pointing it out. Yeah, one more there and I will stop and I'll have a... Maybe it would be useful to have some kind of tips to help things not to escalate. Like having something that is out of the code of conduct but something you could have a look to help you cool down and not react. I actually put a further reading section at the end with a link to Enrico's excellent document, the Debian Community Guidelines. And maybe some links that could be added there. I'm awfully sorry, but I'll just close that. Yeah, I know, we are out of time. I intend to take this and put it on the mailing list, Debian Project, with annotations, what we managed to discuss during this both and what we didn't manage to discuss, so that will be clear. And I hope the discussion will go on there and then we'll see what happens. Thank you and see you later.