 Right. Good afternoon Tower. This is in Rico's talk on the Debian Community Guidelines all how to be able to achieve total world domination through discussion on Debian Devel. Without much further ado, Emily for the cheerful presentation. Hi everyone, I'm Mariko Vini, someone knows me from Stoff. I've been working in the past probably here and a half on putting this together and I'm not very far into it but it got something kind of usable so it's pretty much time to present it publicly. So here's my recent work, the Debian Community Guidelines which are, well, Debian Community Guidelines started actually with a conversation with Martin Mikkelmeyer when he was DPL and there was complaining of a couple of, well, a few bad answers I was getting from people on IRC or lists when I was asking for things and since my ego is too big and it couldn't have been my fault I started wondering what could have been wrong and so I reported things to the DPL that we could have communication problems and Martin told me something like, where does it see what is good and so on and so I had the idea of starting collecting, well, a list of things that could be, like, good to assert in Debian but that would have been, that sounded too much like the teletabi thing Be Nice Guide, which I soon realized it was a stupid idea so eventually I came up with a slightly different idea for what could be a document that could improve communication a bit in Debian and the idea is to have a collection of what people normally do that works well it is actually very hard to do because the thing you notice in lists is what people normally do that works really bad and so it's been a long work especially because you need to spot things that work well and you need to train yourself to be able to spot that and these things are put down as a list of suggestions for people to work online more efficiently The Debian Community Guidelines are not a policy Many people, especially during the DPL election have been talking about making some social policy that would make it outlaw for people not to be nice in Debian and that's exactly not my approach especially because the more law you put into social behavior the more you bias and screw up social behavior basically so I want suggestions but I don't want them to be mandatory I like to think that I'm not the person that knows social things the best and someone can always have better ideas than me so I don't want to mandate anything and they're not a way to point fingers at people that would just make things worse if we start pointing at each other like you don't respect 0.7.ae of the Debian Community Guidelines that would make things easier in Debian and they're not perfect, they're a continuous work in progress and they're not, hopefully, inquisition stuff so in this talk, why am I giving this talk? I'm giving this talk because I would like to have the guidelines become something a bit more mainstream so I want you to know what is in the guidelines and so since you're not going to read them here I will go step by step through it with you I would like you to tell people about the guidelines when you think it would be useful but not as a finger pointing and I would like you to watch out for potential additions to the guideline because, as I said, it's not trivial to spot useful suggestions for the guidelines and that's something that is better done with different sets of eyes and so in this talk I will go through what is in the guidelines tell you my plans for the guidelines and ask you for ideas of further steps to take with them so before I start, there's some free editorial dogmas that I forced myself to follow because I think it could be useful and so the DCG, W Community Guidelines should be a collection of suggestions and not a collection of blames so you will never see in the community guidelines something like you are really bad if you do that you will never see bad people do these sort of things or at least you're not supposed to see that if you do it's a bug this suggestion must be something useful for all the parties involved in the communication that is the only way for such suggestions to have a chance of being used it makes no sense to suggest something to someone that would just make things worse for this person obviously this person would never follow this suggestion and of course people who's been listening to my usability talk in previous depth conf know brain doesn't hold more than 7 plus minus 2 items so every section cannot have more than 6 or 7 points after the dogmas we go into the beginning and main part of the guideline we go into the index of the guideline I didn't have this slide in my brain the guideline is split in 3 parts the main guidelines which is the most important part is 4 points which ideally should be general suggestions that are general enough to summarize the entire work with the idea that no one is going to read a long document and if someone is in a hurry you want to bring something useful to them as well and then there's a list of more detailed suggestions or guidelines that are communication specific and a list for things that are babian specific so that's the content and we go into the main guidelines it's these 4 you can just listen to these slides and if you're bored of the talk you can just leave after this slide it's the most important one it's 4 points one is strive for quality try to work for quality what quality means is up to every one of us I like the word quality because it can be relocated to whatever is everyone's set of values but the idea is that you want to do your best in everything you do also because everything you post will contribute to the knowledge usefulness and look of babian but it will also be publicly archived and found by others in out of context and out of the time frame that you were intending for that message so you really want to write a good future for yourself so this is a point that helps both people reading your message and both you as of your image you want to work with others otherwise you could just be lonely upstream and have a developing developer take care of you and then work with others means trying to improve the quality of the community as a whole help to improve everyone's packages which could mean co-maintain but you not necessarily have to co-maintain so that's a high to manosh and just help to improve other people's packages by providing nicer tools for them nicer guidelines nicer suggestions how to use tips testing tools whatever that improves the quality of everything as a whole you can share your ideas and plans allow people to help and contribute thank people these sort of things then this is something that kind of helps everyone because you help others and you get help right? and then principle do not change and the rest changes with work so this gives the idea that we have something in Debian that we all agree with which is not much social contract and Debian for software guideline and then all the rest we can change it with our work we don't go very far with just talking but as soon as we start working we can change a lot and the last one is my favorite one well they're all actually very important but the last one is if there is a conflict of some kind especially you see someone that is being arrogant or unreasonable in a conversation it's best to support the one who's being reasonable rather than attack the one who's being arrogant attacking the person who's being arrogant doesn't solve any problem and just makes the atmosphere worse but supporting the one who's being reasonable actually reduces the gravity and the annoyance of the attack so that is kind of something that it's a suggestion that is aimed at having going into a more sustainable kind of discussion even when things go wrong make some sort of fault tolerance tolerate faults in communication so this is the main guidelines now I'll go through the ones that are more specific and people can fall asleep and digest burps are tolerated so I said there's main guideline communication specific guideline and Debian specific guidelines these are the communication guidelines which are in turn split in three one is improving the content one the presentation sustainability of the communication so this is about the content so the idea is that if you want to write messages that have good quality in the content and are useful to people you want to ensure that you are adding information to the discussion you don't it opposed doesn't have quality if it doesn't add something to a body of knowledge well RTFM read the manual is a good example of something that doesn't add much content to the discussion besides saying that the answer that someone was looking for is written somewhere and of course if someone already knew where to read the fine manual they wouldn't bother to ask so try not to repeat your points some big problem we have in Debian is people repeating themselves over and over again that just doesn't help and it works fine to let your point be heard once and not insist unless you can come up with code specification a technical explanation to back it up it's also less frustrating for people who write a message to you if you actually add something else and people will read your message not just keep you you will actually enforce your point but if you just repeat your old point then it's frustrating because no one will end up listening to it and share the help you receive so when solving a problem creates knowledge and knowledge is good to be shared so you can turn an IRC conversation or an email conversation into a blog entry or a wiki page a short tutorial on how to you can encourage people to share the help so I will help you if you then write the results of your problem fixing into a wiki page when you receive help you have to take notes and share them sometimes Bdale was pointing to me that sometimes you give a suggestion to someone on how to solve a problem but you wouldn't actually be able to solve the problem you just put this person in the right direction and this person actually gets beyond what you would have done so it's nice if this person at the end can post what it's done and you could figure out oh damn it could go that far so share the help you receive do some research before posting that makes a very good quality of the content of the message and as well makes you look smart I found out that I look unbelievably smart to the eyes of most of my friends because every time they ask me a question I just paste the question on Google and tell them what I get back and yeah so some friends use me actually as a kind of Google which kind of annoys me but if you do a little bit of research before answering people you really end up looking smart and people will like what you write and know what you want and make sure people know what they want that is a hard one so this point actually expands into four questions that are called Flanagan Critical Incident Technique that could be useful for debugging social problems like if you can't understand what went wrong you can ask yourself or the other person what led up to the situation what did you do that was specifically effective or ineffective what was the outcome or result of this action and why was this action effective or what more effective action might have been expected that if I read it like this doesn't make any sense but I only wanted to tell you that the four magic questions are in here and I've been told that they kind of help so that's about improving the content and the presentation of the message is important as well unfortunately but in a small group say the DevTags mailing list there's like five active people it doesn't really matter about the presentation of the content of a message because then it's a little traffic and you can actually spend a bit more time trying to figure out what's the point of a mail but on a big high traffic mailing list people tend to skim through messages they need to bring out the message as efficiently as possible so you want to have the shortest mail which most completely gets the point and that is kind of hard so suggestions for that are put the main point at the beginning and the long details later actually Mako told me a nice tip which is you start writing the mail and usually you start with your reasoning to the main point and at the end you actually clear up your mind while writing and you get to the main point to write in a very coincide form so you just copy it and paste it to the top of the mail so that people can see right away what you are aiming for and what is your point and Mako then added and then you delete all the rest which actually makes sense because yeah one error that we often make is to actually put our cognitive process in the mail and you start the mail with some intention but not with clear ideas and you have the clear ideas at the end but then you feel like you don't want to throw away all that effort you had in writing the mail but at least you can just turn the mail upside down and put the main point at the beginning and leave the rest as like more rational about things that people could or could not skip and that's point one point two is talk with coder patches well that's especially on technical mailing list of course like you don't want to talk with coder patches in Debian project probably but that just make things more clear you can like test them right away that's probably the most efficient form of communication we have in our world when it's actually applicable so and sometimes it's hard to say something in English so and it's easier to say like in C, Ruby, chicken whatever language you know best I like chicken a lot I have never seen it but I can generate bindings of my libraries in chicken so I got attached to it I like the idea that I could contribute to chicken development yeah so you can like make examples on your language of choice and it will generally be understandable by readers unless you like to program in brainfuck but well and then point to existing resources this is actually a nice big one sometimes if a problem has been solved or a point has already been made you can condense your message by just collapsing it into a link and if there's no existing resource which is good enough you can actually create it and like in a wiki or you can improve it if it's found on a wiki so you can actually like externalize the body of knowledge and contribute to make like a wider amount of wider body of knowledge grow up I mean someone could just paste from your mail and contribute to a wiki page but while you are writing and if you have to write a lengthy and detailed mail that could just go in a wiki page and be easily linkable and improvable by everyone interested and use a plain and simple style that is probably one of the most difficult points because I'm Italian I've been studying Latin in high school and when they put that in your mind you don't write simple phrases anymore and I know that the Germans have the same problem even when they don't study Latin and so really I mean languages have different ways of building phrases so that needs a bit of effort but it really pays off I found out that people were not understanding my mails even if they had simple content because they were absolutely twisted so I really made some effort and I don't know if that improved but I like to think that it did right and especially an under nice important point inside use a plain and simple style is try to skip rhetorical writing rhetorical questions and all that sort of things people may not understand them as you've intended to write them and you end up picking up a fight without noticing why if I ask a rhetorical question people may understand that I actually meant to ask that question because I couldn't hear what was my tone of voice when I read the mail and then they could just not answer in the way I would expect them to answer and that mail degenerates so the clearest the better and I wouldn't like this to sound like sterilizing the language of Debian because it's actually really nice to enjoy in advanced use of the language and luckily we have good places to do that like Debian Curiosa and Planet Debian so in a technical mailing list it's good to be simple third and last part of the communication specific guidelines is the sustainability thing you want the conversation to be sustainable you not only want to have good conversation today but you'd like it to have like a good enjoyable and actually productive conversation now and in the future we want to have a community which keeps being good even if it grows up so that's actually a bit more detailed there's more points and it's five I go near the limit of six or seven and I think I cheat because the first point opens in four points more so needs improving so first point is read messages smartly which almost means nothing unless I expand it in exercise your will which is it's up to you to decide if a message is important or not a message is not important if it's the last on a thread especially if the thread is very long a message well a message is important if it meets your needs and motivation mainly it's not important if someone important writes it or anything so that is most important like to read messages according to what I really need what I really want try to interact with human beings instead of single messages like behind every message is a person and a person who is usually nice may get really upset one day but that doesn't mean that the person suddenly became evil or if you have the feeling that the person suddenly became evil then you can send them an email asking what happened in the end like nice things after the deb-comps is that we generally like get to know each other in person and when we see that someone of us is having a bad time on mailing this we kind of figure out that the person hasn't become like an asshole right away but may just be having a hard time or something and try to be forgiving this is like the optimist suggestion which is when you are unsure about the intentions of a message assume good intentions which kind of helps avoid to raise a big noise by mistake and be tolerant of personal differences especially yeah especially since we are people who are very different from each other inside the project nationalities, habits, religion whatever but even if like some of us would probably kill each other when meeting in real life happily doesn't happen often actually happily doesn't happen often so we wouldn't work together as like roommates maybe but we can work together online in like Debian itself and it would be a waste to lose good technical work good technical cooperation just because we have a different set of beliefs outside of the scope of Debian so that's about reading messages smartly try not to become victims of preconceptions, bad mood whatever could be wrong in one day then I have be positive before being negative this is absolutely difficult and I tell you because I tried to do it during the whole writing of the guidelines and try to put positive phrases before negative phrases the result is more rewarding and pleasant to read if I say if I translate this into don't put negative phrases before positive phrases it doesn't sound as good it sounds already as finger pointing it's a kind of a style thing that actually can make like a bug report much more pleasant to read the point is we are used at working with bug reports and the bug report starts with this thing it doesn't work so we are using at starting our conversation with this is broken this sucks we take like a very good proposal that we like a lot and we see there's a small flow in it so we reply to the message we delete all the quote except for the broken part and we say this is broken and all the rest is lost and it goes into the war knock dilemma of deleted because it was good or has then been deleted because it was unimportant or rubbish so we are used that the technical instruments that we use kind of leads us in the direction of just remarking what is wrong and we do it in order to improve but that kind of conditions the way we discuss in a way that goes towards being a little bit unpleasant and if we want to get our message through being able to report a flow in someone's reasoning or work without making it feel like an insult trying to be positive before being negative putting positive phrases before the negative phrases is a very good way of doing it and then give credit where credit is due not much to say about it I think many of us actually put acknowledgments as needed that is also I found out that putting acknowledgments is also useful if you then like need to change the license or need to find out who wrote the line of code and so you still have the name around and be respectful and polite this is just if you write in an unpleasant manner people won't feel motivated to work with you so it's kind of like trivial but and help the public knowledge evolve so you want to have like work to be sustainable by not being wasted so it's good to reply to the list if you have a problem actually Lars was telling me that there was a community in which he was involved in which they would have all the replies to questions being private and then people would post back a summary of the problem solution but he said that he knows of only two people who are able to do that efficiently in the whole world so reply to the list when providing suggestions he's actually a good trade-off and one could take from list messages and make wiki pages and build FAQs and whatever but that's still quite trivial encourage people to share the help they receive I think this is repeated from another part of the guideline so that needs fixing and oh this is a big one sustaining a discussion towards solving a problem is sometimes more important than solving a problem it doesn't sound very clear probably needs rewarding but I'm not native so I don't usually get the best of what English can do so suppose you get like a bug report or you want to improve something and you can kind of see how to do it and you feel that you could actually do it well but you don't have time today so that's something that happens to us and we tend to procrastinate and say okay I won't answer this message I'll flag it important and answer it tomorrow and then after six months you still have that message flagged important and I think we should all remove from mud all the options of marking messages unread, flagging them important and all those damn things I use to forget about the things I should remember so the thing is instead of trying to solve a problem that when we may not have enough time it's good enough to bring the discussion forward so replying by saying I don't have time to fix this now but I would look in that direction try to improve in that point that may allow someone to bring it on and it actually happened to me I tried to do it once and actually people when I woke up the next morning people were almost reaching the solution by themselves and because they could actually build on the good direction I gave so yeah instead of it's best not to try to solve a problem but instead to bring people forward as much as one can according to the limited time of the moment and this is the end of the communication guidelines there's two more parts that mean how to like how to bring long threads to conclusion or how to cope with flamers but I skip them especially because one is almost empty I could use more suggestions but one suggestion I've already followed if you receive an email that makes you angry the first thing I do is I turn off the computer and walk a couple of miles and get back to that email a week later right yeah that's another important one as an alternative solution I generally write the angry email and get it out of my system and then don't send it and then if I'm still angry about it the next day I edit all the anger out and say the reasons why I was angry yeah so coping with emails that make us angry could be like either have a walk go to the fridge or something or write a very angry reply and throw it away without sending it what oh you keep it okay so I write the angry reply and keep it there and bring it back later and so maybe you would cut away most of the angry part or you're not angry anymore so you don't go into that vicious circle in which you answer with an angry reply and the person answer while you're still angry and you beat each other within half an hour yeah so this is BDL the two suggestions I throw out to the people about this all the time are number one if you read something that gets your blood pressure up then absolutely immediately sit there and type out a reply and don't send it this does two things one it allows you to get all of the stuff that you're frustrated about out of your system and down into a file somewhere and if you don't send it immediately but instead go off and do something completely different when you come back and look at it you're not going to help and in the meantime six other people have already called them whatever and you don't have to the second piece is that if there's a particular thing in the middle of somebody's post that you want to reply to that you think is wrong or you need to correct or you want to add some valuable information to or whatever your definition of the reply is focus on that one of the things I've discovered is that sometimes when discussions go the most wrong and they get the most bile built up and they get into these huge long threads it's because people are putting too much stuff in each message and it makes it hard for people to figure out how to either just sort of take or not take that thing you know if you put 20 points in a message and one of those irritates the other person they're likely to respond to all 20 points and it'd be a whole lot simpler if you know we all figured out how to respond to the thing that we really need to respond to Thanks B-Dale Did everyone pick them up? Do I need to repeat it? Right, so from there we go into the W-Specific guideline and I hurry up a bit because I'd like to have a little bit of Q&A and I think I have like 5 minutes so yeah so it's about package management, there's a couple of well it could be added to the developer reference there's a few suggestions on how to work with others and where to publish bizarre dark trees and that sort of thing and how to handle bug reports and simple stuff I skip over I guess they need improvement unfortunately the more you go through towards the end of the guideline the more the quality of the guideline decreases a bit because I always start reviewing them from the beginning and my brain is bored when I'm halfway through so what to do on the future with the guideline is well my first idea is to add it to the new maintainer process documentation I wouldn't ask questions about them because it's like but I would just like to suggest people who have a read and that may make their interaction with Debian more efficient and get into the core of the work more I mean faster and then I could package the guideline in Debian and respond to bug reports that could be like issue tracker to add suggestions to it publish on the Debian website that would get translations as well and then have it linked from the beginning and that could be useful like I was thinking the Debian mailing list pages but not as a policy please that are just intended to be suggestions and then see because there's overlap with the developers reference and maybe I should sit down later on with ABBA and if there's other maintenance of the developer reference and actually work together if we should merge what keep a watchful eye for things that could be added because it is I mean every time I talk with someone about it there's new ideas coming up so now I want to know what's in the guidelines I try to illustrate as much as possible during this time I would like you to tell people about the guideline possibly again not as finger pointing but if you think that there could be a useful piece of knowledge for them and then what's out for potential additions to the guideline and let me know and that's the website I mean the address where you can find the guideline and you can just pull them with bazaar look at commits I do and that's just published over there so this is the introduction and I have a few minutes for questions I'd like to have more but well we can do our best in this time you have a part sorry I'm Roland you have a section of your guidelines about online communication I would suggest adding just one more guideline is take it offline if you can I mean come to DebKonf if you happen to be able to meet the person in real life that diffuses any possible frameworks you can have with that person later flames there's actually another addition that came to my mind recently which is use your friends actually I had this coming in bits and pieces from different people but DD is that you should not be alone against the whole Debian project and we have a few people who are in this unfortunate position it really doesn't bother your friends if you actually talk with them and discuss an idea before bringing it to the wide public that helps the idea to improve that you get supportive people turn down your idea it really helps and I've been talking with someone who was really frustrated because every time they made like a suggestion into a list it would get like good critiques and bad critiques and they wouldn't know what was the most important and I suggested well discuss them with friends oh I don't have friends make friends you are at linux there's Debian developers go out and know people and try to remember their names and that is like something I'd like to add to the guideline but I still have to figure out a good wording for it somebody mentioned coming to events like this there's another thing that I don't think gets used often enough and that's the just pick up the telephone option I'm intrigued at how many people seem to you know get all worked up about somebody hasn't been responding to emails hasn't answered my mail I asked them an important question you know why can't they be bothered to answer and when someone me or someone else finally gets around to picking up the phone and calling them you discover that they've had a death in the family or their company fell apart or something like that happened and it's part of this taking it offline going out of van thing but I think sometimes we forget the simple stuff like this yes you know an international phone call is not free but it's darn cheap compared to sitting around being unhappy for the rest of your life and there's VoIP there's VoIP now so but we can hi my name is Mark Allen I would like to second that comment telephone if you are at work and you're in the same building with a person and they don't respond to your email and they don't respond to your telephone walk over and visit them in their queue or find them in the cafeteria I send email if I don't hear it back in one day I'll try a telephone message if I don't get a response on my telephone message in a day and I don't get a vacation indicator I will walk over to their queue with their area and try to find them and see what's happening okay time's up so feel free to bump on me later and I don't know what that means in English actually feel free to step on me and is that correct I don't know like feel free to talk with me and propose additions patches are the most appreciated so you make the effort of adding things using the dogmas that I came up with and see how difficult it is well too slow of a laptop to get to the dogmas so you make an effort to actually follow that and it's fairly difficult but it really helps you to get your radius clear and thanks a lot for being here and well see you next week on