 Welcome everyone, again, this is Ana Beatriz Guerrero-López, she is a Debian developer since 2005. She is also a Debian organizer and she works in the KDE package team. She's going to present this both about integrating new people in package teams. Please welcome her. Okay, good morning. Thank you to all those people who made sure I was waking up today early. Something very complicated to me. Actually, in some moment I have to put a title, and I still do this. This is a book, not a book, if we are in this room. So, I decided to put this title, but actually what I wanted to put was this one. Okay? When you are maintaining a lot of packages, in some moment what you want is somebody else helping you out. Doing your job, and if this person is doing your job exactly as you want, it's even better. So, I have a bunch of slides, 10 of them, because it was very early and I didn't know how much awake people was going to be. So, I am covering a bit some of the typical stuff that people do, it's better now. Some of the stuff that people usually do for when they have a team and one new people joining, but I am sure you have a lot of ideas there. So, if in any case you have something to say, please raise your hand, because the objective of here is getting new ideas. So, we have a lot of very, very big, I don't know how to say, a set of packages in the archive, for example, KDE, PHP, text, that are usually mined by a group of people. In the past, in some cases, where only one single people, it was a big problem sometimes. And all, I mean, absolutely all of these things need help. In some cases, the maintainers never will say, he or she needs help, but they always need help. What happens? When you get new people, you want to... You want these people to automatically be working and be helping you. That's impossible. You need to do something for these people helping because they are never going to know automatically how they can help you. You probably know that URL, that's in the last line. There is a bunch of things. Some of the things are infrastructure teams, that doesn't have nothing to do with this tool, but I am sure that you know what I mean. So, I have been working a lot of years in the KDE team, and it's very, very normal. We have people joining us, saying, you know, I want to help. Yeah, we usually never know what to do with them. We want them to help, but we don't know what to do with them. Also, some of the ideas here, tangentially it's not the objective here, can help your team working better. Because I mean, working in a team with new people is very, very hard. I think more than two people, it's already very difficult to coordinate sometimes. And it's also out of that, but if somebody has some idea about this, it would be very welcome. If you have some mailing list with users about the software you are using, you will realize that you have a lot of power users, users that are helping a lot to other users, but they never join the development team. It will be something very interesting to know how to get them into doing that. Well, this is not really interesting. I mean, I think everybody knows how to see a potential new contributor when they appear. I get a lot of emails saying, oh, I want to help you in KDE, what I should do. I don't know if it's the case. There's somebody else. I don't know, Juliane, did you get any email saying, oh, I want to help in X? Never? Never, never, never? So, I'm Julien Christo, I'm working on the X packages. So, mostly that happened after we sent some requests for help on DDA or on Planet or whatever, and we got two or three people saying, hey, I could help, and usually you will reply to that thing, okay, giving a few pointers and stop there. Yeah, something normal. So, basically the first brilliant idea you can have here is you say, okay, I will write some documentation, I put everything there. People will read that, and they will help me. That doesn't work. I mean, you have here the typical season ones. Well, how your thing is working changes a lot. So, what happened is you never write everything down. Reading it is very boring. You never maintain it to date. And it doesn't matter what you do, people don't read that. So, they ask you a very stupid question, that is exactly in the first page you have. So, in some moment, I realized that writing some stuff is a good idea, but it's not really a solution. Also, in the QD team, we organized some kind of book there for getting people into closing our bags. Sooner or later, we made one like maybe four or five months ago. We have maybe two or three people helping. They close a lot of bags, but after that day, people disappear. It was nice because we have some graph with the bags. So, one week later, you can see the graph going down. But people individually didn't feel like they helped a lot. Another idea, this is what mostly have worked for me, has been getting people into IRC. They ask questions, sometimes very stupid questions, but it's not something very public. They feel like asking and you answer. Still, it's not perfect. Sometimes you are in Europe and you are talking with somebody from Australia, so the time difference is very huge. You don't have so many time for thinking. So, sometimes when you say something in English, it doesn't make too much sense. Or what people tell you, you don't understand it. Still, there are some people who don't really get IRC. They enter to IRC, they say hello, sometimes after they say goodbye, but they never participate. Maybe they are waiting you to ask or something, I don't know. But when some people who really want to help and know more or less how the Vian works, join the IRC channel, it usually works very well. Another minor idea, I am sure a lot of you have done something like this in the past, having very easy packages. For example, you have a very easy X module. In our case, we have some of the small key dependencies. We say, oh, does somebody want to help with this? Sometimes people help. And after that, jump to the key decor packages. Sometimes they start updating it and they never finish. I do everything. I also have a lot of time asking for help. I have to say that maybe four or five posts saying, oh, we need help, we need help. In one of those posts, one person called and has been for like three or four months trying books, something that was very, very nice. I mean, maybe he has closed something like 200, 300 or something like that. I already have loaded the number. And also something that other people have been doing, has been like putting easy tasks, difficult tasks in some wiki page or in the backtracking system. And say, oh, look at the easy task and do one of them. And then with that, you get to join the team. I really have never seen that working for me in Debian. Maybe for other projects, it's on 3.0. Also, I try blogging with very specific tasks. I am that, sorry. It didn't really work for me very well. Most of the people say, okay, I'm going to help with this. How exactly I do? I am asking the people to try to figure that out. Maybe I didn't really know how to spread that very well. I mean, you have to do this yourself and it doesn't work. So I have a set of lists that, a set of things that is basically what I see is frustrating the most the people. First of all, when people want to help, it's really, really complicated to know in what they are able to help. It's really complicated. Sometimes they want to help in something that your team doesn't work. For example, I ensure more you have got somebody who wanted to help doing something like coding and you don't really code. You can make patches, but you don't code. Also, sometimes people are trying to help but they only want to fix their pet problem. They don't care about anything else. And they want to fix it in a way that is not exactly the best one. And this happened a lot in book report discussion. I also was saying before that I tried to assign very easy tasks to people to see with that the kind of say, oh, I know how to help. I am going to continue helping. In most of the cases, they have been taking, I don't know, one week to with. And after that, you need that task done. So you have to do it. And also everybody thinks that when everybody knows, a lot of people think that helping is only packaging. You don't do back report. You don't write any minimal documentation. You don't help users in mailing list. You don't coordinate with people. I don't know how many of you have something else to adhere that has frustrations in your head a lot. So the following slide I have is maybe what this is about is the more common frustration I have seen in people joining the team. Basically the first one is usually in the end, we are very, very, very, very slow. And it takes a lot of time until the people see in the archive what was the result of the job. They work on it. And they fix a bug. Or they help somebody else. This person never say thank you. So you don't really know if you help or not. It takes, I think, a lot of time realizing that when you are doing something in the end, nobody is going to say you thank you. From time to time, you get an email. That's something very strange. Now all the tasks are rewarding. If you are not doing that for fun, you are not going nowhere. It also takes a lot of time understanding time. Most of the people feel very insecure because in the end we have a very bad thing. So people think, oh, if I do something wrong, everybody is going to send an email to some list and they are going to say very bad things about me. I have a lot of people who were very smart asking me almost every step. Oh, should I do this? Should I do this? Should I do this? Should I do this? After two days, it becomes very, very annoying. Maybe the most important thing is that the people don't understand that they will never know absolutely everything. Some people think they know everything, but obviously they are wrong. They say, no, no, I will do that when I understand this and this and this and this completely. Sometimes you cannot get the global map of everything that your package is going to affect. Sure. So as a newcomer, I can maybe add some points to the list. First of all, quite often the maintainer doesn't exist. So you mail the maintainer, you file a bug report, you take the time to write a patch and you don't get an answer for months, sometimes years. So this is, I think, one of the most, for the people who took the time already to look how you properly contribute is the higher source of frustration. So seeing that the maintainer is not there. And one thing. The other thing is that... No, I commend you on this thing and then you tell me another thing. What you should do in this is writing the MIA team. Okay, you go to the QA pages, you can see the email. What happens? The MIA team, I have to say that sometimes it's asomia. Yeah, it happened a lot through the years. I mean, you have a lot of people reading the alias. It's something like, I don't know, they're 11 people. And usually nobody answers you. So I know it's even more frustrating. So in some cases you can be lucky and somebody answers you. There is some people who is very, very clearly MIA. But maybe somebody from the MIA team writes them or you write them and these people tell you, you know, I will take care of my packages in two weeks when I finish something. And two weeks is two months and two years and you keep waiting, waiting, waiting. And obviously you cannot go and hide at the packages. Some people do that, but you can't. So what I think is the best thing you can do in these cases is opening a bag and asking, hey, are you, I mean, after writing the person and so on, hey, are you still maintaining the package? I mean, like, I don't know, which list bags are in the package. Are you still interested in the package? I see you are not maintaining it. You also can do this asking for packaging new version when is the case. This person will tell you, oh, I will take care of that. Sometimes they close the bag. But after two months, if the person has not read, you can reopen the bag and be done again. I think that when there is like some kind of public track of, I don't know, six months, seven months, nine months, one year, and this person has no answer. You can ping strongly in the Debian QA mailing list or even asking in Debian Devil. And somebody, if you are not a Debian developer, might help you to, to kind of steal the package. But this time it's like, there is a public track record that you have been maintaining, having contacted this person. So I don't know if this is worth for you. Yeah. Well, I never did it, but I know there is a process that one can start. And the other thing is that when you want to document yourself, to find documentation, how you can actually help. And typically, after you get an answer, well, this is described in the wiki. Okay, which wiki? Where is it? What, where actually should I have to look? You know, it's, it's every package has a different way of documenting the workflow. Some packages don't have a documentation. Some have good documentation. Some have documentation. There's some blocks that, for the newcomer that doesn't know anything. You know, it's difficult to understand how you can help without asking. When you ask, you get replies that are typically from pissed off people that always have to say the same thing. So it is really kind of a, from one side, a social communication problem. From the other side is that the Debian website is in the state that we know. So it's difficult to find documentation. And when you find it, you get, well, this is described in the Debian policy. So how many pages is the Debian policy? So, just, I mean, I know that the problems don't have an easy solution. It's just that I wanted to had some points to this but at least because I don't think that most of the newcomer, I mean, it may be that most of the newcomers are excited about something and then disappear after a day. But if even only one percent of these people would then manage to get proper tutoring and help, they would stay afterwards. So it would be already enough, you know. Okay, so please, the people who want to speak raise your hand, and we will go down, who wants to talk. Okay, so Christian, the leader, Bruce, you? Yeah, Christian Perrier speaking. I think the latest comments seem to show that things just don't happen magically. People are not helped by magic or by documentation. We need to invest time in that. So everybody, I think this is more or less what you meant, Anna. If we don't invest time in our teams to mentor newcomers, to help them, to answer them, to guide them through the documents, then we will fail. Well, I have a successful experience over the years with the DI localization people. Most often, people who know nothing about Debian they just come and want to help, the exact example. And I had to invest a lot of time doing that. But if you invest this time, I think it becomes successful. It needs some documentation, maybe sometimes inaccurate documentation, just to have people ask questions and then interact again and again. The key is investing time. I don't see any other magic solution. Russ Albury. A couple of points. First on the MIA part, one of the things is that I think that people find starting the MIA process and going through that to feel very confrontational. They're telling somebody that they're not doing their job properly. And what that means is in particular I think that most newcomers to Debian are just not going to be willing to do that. They don't feel secure enough to go tell somebody that they're not doing their job or even start a process really that does that. So to me, I think that's one of the places where those of us who are Debian developers who have been around for a while who feel a bit more comfortable saying, hey, look, you're not maintaining your package. We really need to step in and help when it's an MIA situation. We need to be the ones who go do that process because the newcomers are just not going to be in a place where they can do that. The other thing was about the documentation parts. Debian slash readme.source. If you're part of the packaging team or you maintain a package and you want other people to help, each time somebody asks you a question about how you maintain that package that you don't know that it's already written down somewhere, put it in Debian slash readme.source. We've got a fairly standard location now to put that kind of stuff and then it's in the source package which means that anyone who's looking at the source package will see it. And so they, you know, even if it's just pointers to your wiki or whatever, that way there's something that's a standard location everywhere and they can look at it offline and it's in the actual package so it's in the one thing you know they have if they're working on the package. I just want to say something about the, about people joining the new maintainer process or Debian developer new maintainer process. I don't know how it's going to be calling in one year. Usually people who have been working in teams, you usually know two, three, these who are working with you. So getting advocates in some moments somebody gets very tired of sponsoring you and you can say, hey, you have been working with us for one, two, three years. And look, you are doing the same than us and I have to write your packages, please apply. I have a case of somebody who has been working, I don't know, four years or something like that and I have to say, he may be listening, Modestas, please apply. I mean, maybe you know him, Modestas Baenios and I was like, please apply already because I want to go, you are doing all the job and this time I only loading the packages so you are willing in any way, please apply. So in some cases you even have to beg people, I mean, please. It's just, when people get trust on their servers, it's easy. I don't really see, maybe people who is maintaining only two, one packages, they feel very insecure but I think that the team factor here works a lot. Okay. My name is Ben Armstrong. I'm speaking as a team leader to newcomers like you. I understand your frustration when you are directed to the Wiki or to policy but if there are shortcomings there you can help to fill that out. You will learn things as you ask more questions and you can then contribute to the Wiki and maybe aimed more at the newcomer because I have not paid attention so much and say at the WNEPC Wiki there's a night, the team's template says here are tasks that newcomers can do and when I initially filled that page, I put some things that I thought were things that newcomers could do but I find we're not consulting it, we're not updating it as new people come and say, hey, can I do something? And so that's one area that we can work together. The other thing is perhaps I don't notice you unless you show up on IRC I'm very generous with my time on IRC I know a lot of teams are like this that sitting down and writing the doc and the Wiki you need to discipline yourself to do that a little bit more. But I just mentioned that because you said this is something that works well for you. From a team leaders perspective though that's a very expensive use of your time to be individually covering the same ground over and over and over again where there's a lot of risk as well involved in most of these people aren't going to pan out as contributors. So just kind of encourage other team leaders to put more effort into that that team page where you say here are the tasks. Does anybody else have some comment about the frustrations you have when you're joining on frustration you have now? My name is Gregor Hermann I've been in Perl Group and I'd like to add a comment about documentation. I totally agree with you that it's useless to tell someone well go to the Wiki it's more or less saying back off. But I think it is useful and it helps if you point people to a specific page if you give them a URL or if you say go to this page and then read section something so I don't want to repeat everything again and again on the ISE if it is written down but I try to point it out very specifically. And this I also think because I know you said writing documentation is not so helpful from a team point of view I think it is helpful because it saves me from explaining the same stuff all over and over again. That's what I mean we write documentation for the things you usually ask but in some moment you cannot cover everything. Yeah sure. Okay does somebody have any question or any suggestion more because if not I have some questions for you. So this is a question but maybe from all the questions here I have maybe two that are the most important to me that if any of you are entering in Debian working inside a team directly instead of right now a lot of people is maintaining single packages but I have seen in the latest time a lot of people who don't start maintaining single packages in some moment they start helping in a team. So if there is somebody here who has started contributing to Debian doing that okay. Then a following question do you don't have to tell me this experience but of working in a team or working or looking how the team works and saying okay I won't work with them. Do you want to tell why? Without saying the team you don't have to. When I start working with the security team it was really hard. There is no even documentation. The documentation is in the head of the people. It was scary. Okay. So if any of you have some answer to one of these questions or want to share this experience in another moment if not I will move on. Related to if you started contributing in Debian what did help you? Personally for me starting in Debian science, Debian Med that there was sufficient amount of information available in non-IRC communication channels. So they had a mailing list and you could get a sense of how people communicate what is style what are the standards you need to get to be able to do substantial contributions. And maybe it's just me but IRC is too liquid. There is sometimes there is information there. Sometimes not depends on the time zone you are in and I know for people coming into it email is probably way more standard than IRC unless you first become a hacker and then go to Debian. That's a different story but I think you know there are more people that can contribute than are already hackers of some sort or quality. Yeah I have to agree that IRC can't be the only way. We still find it a very effective way but maybe we are not using it as effectively being sensitive to other people's schedules. Maybe we could focus more on scheduled meetings just a thought. Just a quick addition for me when I entered Debian I entered with dedicated sponsor for myself sponsor, mentor. So he was sponsoring my packages there were no notions of mentorship at that time I believe I was a dedicated person who gave me hints on where I was wrong and it just first of all made my contributions readily available soon within the system I want to contribute to. So I started working he was sponsoring packages and I saw the result right there quite soon. Now we have all the mechanisms for sponsorship and mentor mentoring but it's not just mentor or someone who wants to work with you. So maybe this advice actually it's present there it's just what helped me. Well traditionally maybe six, seven years old what was very typical is you start maintaining a package and we have some kind of mentoring one to one and it was mostly private emails people feel more like secure in the sense it was communication so you have somebody who was helping you you're wearing very stupid question and this person answered you the question so nowadays that is still working for some people but in some cases in the area you are helping you are not working only with one person on this person it's very overworked. So it's better if you can kind of join more people I mean having more than one mentor. So in this case what happens you could do the communication only via mailing and so on but we have more communication channels and in the case of IRC people is talking about the time difference that sometimes you don't have time to help but sometimes you more or less have time to help and somebody is doing something and this person wants the answer in that moment and helping that person in that moment can mean that this person is in that day gets encouraged and keeps doing stuff sometimes if you send an email and you get the answer like I don't know, two weeks after two weeks after you are no longer interested in doing that. In the case I have a question from all these people here and it's do we working in a team how many of you are usually using IRC for communicating okay most of you and how many of you do your deviant work using IRC at all I'm really surprised that there is deviant people who can do deviant work with IRC We could use IRC but we don't because we feel that it's superficial to somewhat or non-efficient for us And in addition to that getting into the deviant world one of the most precious advice that I got too late was that it's very difficult to leave a public trace because at some point somebody is going to ask you what did you do and if you can't come up with references and you're not working on one of the popular targets with 2000 buck reports open then it's very difficult first to find a mentor and then to get people to agree that you're doing something that is at least remotely valuable to the project and IRC doesn't give you that a lot of time there in which you probably can be very productive to do your work and email will give you public references that you can rely on later on and also in terms of my own opinion where this whole evaluation of people who will eventually become project members which I'm not should move more towards evaluation of public references than of a sidetrack of the exams that you take and assess your reputation and capabilities at the time of doing the examination and it should be more of an ongoing evaluation it's pretty much like a large scale missing in action process anybody can go missing in action at any point and they get out of touch with evolution of deviant standards if you became deviant developer 10 years ago in a package it's quite likely that you have no clue what the deviant policy says today I don't really think there needs to be this kind of perceived conflict between the IRC and non-IRC way of doing things any effective project leader understands that there are going to be some IRC members and some non-IRC members and we'll work happily with both for me personally as a hardcore IRC addict this is a way that I can take my energy and my enthusiasm and keep that level high because I thrive on the interactions the minute by minute interactions and if I didn't do that, I'd die I would no longer be useful to the deviant project but I also realize there's mailing lists and I also realize there's the wiki and I think I make very effective use so both of those in my project so I wouldn't, if you were approaching my project and the only way you were communicating was non-IRC great do you think that publishing IRC log publicly would help for the history in France? I want to answer something that you said about communication about mailing lists versus IRC but I want to make a comment about publishing IRC logs and I think that most of the deviant channel have the analog in policy in the sense that you can make log for yourself but you cannot publish the log usually in the IRC logs you tend to put some stuff that shouldn't be public so I don't know there is somebody here that thinks that for example making the logs of the deviant public will be useful not at all but there is somebody here that I don't know supposedly a deviant php channel do you think that the logs of that channel will be useful? not really okay people who are on IRC do check their backlogs and people who are not connected can't check their backlog basically I don't use IRC that much but I have screen plus IRC just running all the time to have access to the logs and that's a waste of resource for OFTC and free logs I also do what he does I don't really participate just because for example in the deviant level because when there is a problem there is a machine not working for you you go to the deviant level and probably somebody already has complained about that so you know what's the problem and why is this problem being there but I have found out that sometimes about publishing that information it's not really useful because maybe in 5 of July it makes sense if I am talking with somebody about coordinating the beta of some package that is coming out in August but in September that information is no longer useful so and about IRC this link is not only that you can get an immediate answer sometimes and even you can ask for more details and answer more properly it's also that for example who is sending questions to mailing list I was going to say silly question but maybe they are not silly it's just that sending sometimes a question to the deviant level that is going to be for I don't know so some to so some people saying for example I have this not working this machine is not working for me you are wasting the time of a lot of people when you can enter to IRC the deviant level topic so maybe you don't you don't lose your time but you make a lot more people losing time when we have an FTP master done for maybe one week it was sent an email to some of the announced mailing list I don't remember what one and several days after somebody was asking in the deviant level mailing list so maybe this is not the best example because you are supposed to be subscribed to the deviant mailing list but it's also that happens a lot in smaller things you are supposed to be subscribed to deviant what is announced or develop announce if you are a developer in the very moment you are maintaining a package you should be subscribed but we are talking about the people who should be maintaining a package that you want to get into the project and you assume a lot of knowledge about deviant internal things and it imposes an anticipation of culture in deviant which is not visible from outside personal experience given how deviant works I think that in the very moment you are interested in development you should be subscribed I am subscribed to a lot of mailing lists and I read them a lot that's why I know how it works but you want people to subscribe yeah I read them for years now and that gives a very clear impression but you want people to get to the point and usually what you learn is at the first site deviant develop has lots of things going on if you are interested in the social aspects of the project you will learn a lot and that makes it interesting if you have the time to do so Hi I'm Ashish, sorry to step out for a bit in the middle but as far as things that new contributors don't know is who else feels like they are in the beginning part of their deviant career and is not a DM or DD yet in this room so can we maybe talk afterwards about can we sit down and if you guys show me here's what I read, here's why it made no sense to me because that's a perspective that we experienced contributors don't have anymore and I think that will also begin to address some of the confusing aspects of team stuff too although only tentatively I don't really follow you so there's a concept called usability studies where you ask people to if I've made a system I'll have a user sit down and try a task and I'll say narrate to me what you're thinking as you try to achieve this task and I think that new people have a lot to show us about what is unusable on the deviant website for helping them find out what they should do and I think that if we can smooth out some of that stuff then it'll help people who are new to teams find the right answer to their problems and the right way to do things also I don't really I understand your ideas but I don't really see it very well so sorry no and then I am going to do as a question I have nothing to do with the both but you are not talking and I'm very curious okay 15 minutes do you think that there is some deviant working some deviant team that is totally, totally, totally failing to attract new contributors but they are trading it very hard I was talking about the packaging yeah and then my question is I have been working only about packaging teams but do you think there is something, I haven't talked about that there is something that is you have been working in some packaging and something that was not a packaging thing and you have some idea that might be applicable here after that I don't really have any more questions so thank you for coming that wants to say something this is somewhat of a different topic I was kind of wanting to mention towards the end so one project that might be really interesting to look at along lines of how do you include new people is DreamWidth so it is an implementation of live journal runs on free software and they are actively developing the live journal software suite it is interesting for a few different reasons the one that has gotten the most press recently is the fact that it is 60% of the contributors to DreamWidth are female and it is one of only two projects that people are generally aware of where the majority of contributors are female but more interestingly I think for this particular talk it is also has a huge number of contributors where they have never done any software development before ever and the project puts a lot of effort into trying to get what they call baby devs to come write Perl code and it is live journal it is not particularly great Perl code it is complicated and they managed to have a lot of success with that so the couple of points that I was going to make one of them is take a look they are really an interesting project and they have developed a whole pile of suggestions on how you do the sort of thing but the other thing I was going to mention is I think that the biggest thing that they do which has been helpful and is just that and it goes back to what Christiana was saying was that it takes a lot of time and they put a lot of time into it and the leaders of the DreamWidth project basically treated as as important or more important than writing code themselves is to teach other people how to do it and to mentor other people involved and it is a hard thing to say because I think all of us probably for the most part enjoy working on our own stuff more than we enjoy trying to mentor other people because it can be draining emotionally to mentor other people particularly if you are kind of introverted I am I think a lot of people who work on this kind of stuff are but I think that is one of the things that we can learn from them is that if you put a lot of effort into it it really does pay off and if you can create a really supportive environment they are when they train new developers they are really really strong on trying to keep the tone constructive and supportive and to try to really not jump on people and to try to let people make mistakes and spend a lot of time talking about that as a community because their experience is that a lot of people would like to help but a lot of people are scared and a lot of people are just really uncomfortable and it is way outside of their comfort zone and buildings are parachuting for the first time in an airplane and they need a lot of support and encouragement along the way but it pays off if you do it and you get a lot of new developers and they get developers like I know other projects I have ever seen one other thing that DreamWidth does is they have a bunch of VMs that they can provision for new developers to hack on the code so in order to modify a complex of having to set it up on their own machines they just get a virtual machine provisioned for them by the product leaders so I wonder one of the things that you talked about is this frustration where you label easy things to do and I've had this myself in my own projects label easy things to do nobody does them and you're like well actually I needed that and then you do it yourself so there's there's this process by which the easy things get dried up the VM is that you can just tell people to you can give people specific tasks inside their playground that doesn't affect the real package but teaches them the same skills and also setting up a P-Builder is scary although not actually hard and like a bunch of other things I'd like this to take a step back here different people have different levels of commitment to Debian and different amount of time to spend on Debian so trying to get people to become core developers isn't necessarily going to work so one of the ideas that I had for the Debian games team to get some people, more people involved is on wiki.debin.org slash games slash parties the first party that I was planning to do but I still need to write a bunch of code for is a screenshots party and the main point of these parties is to publicize the team get people to know that the team exists and that you can contribute by having just the skills to make a screenshot for example and then you can move on to more advanced things like bug squashing parties or bug filing parties or whatever else you can think of so this is just one idea I've had but haven't been able to implement yet please use it in other teams so you ask the question if you have been scared a way of starting to work in a team so I don't know now this is of general interest I can report my experience with the Python module team and I don't know how many of you are aware of the situation of Python in Debian so you are aware because there is something like two Python and half team you have Python module, Python application and then the half team is Python I'm talking about the Python module team and because I'm Python programmer, developer and user I was from very beginning I subscribed to the mailing list and lurked a little without contributing anything and then at some point there was a problem with the package I was using I found a bug I wrote a patch I sent a bug report and everything worked pretty well then I said well good this means I can do it more often and I tried to be more active but then all of a sudden you see that in the mailing list there are some quite heated discussion and their personal problems overlap a little bit with technical discussions and for me it was like I have to choose what helper Python, DH helper I use and then you immediately see that choosing one helper would mean putting you in one side of this battlefield and without me knowing anyone personally having no idea what are the practical implications of that I thought well unhelper would be something that would help me making the package then I ask there are two and nowadays we have three and a half helpers okay maybe four battlefields and different you know so this thing scares away a lot of people for me it was more like well okay I'm not doing any packaging I'm just maybe helping people fix bugs and write proper bug reports and maybe communicate personally with some of the guys but for the moment I have no time for this kind of stuff you know sorting out the personal problems and I don't know if Python is just maybe the worst example in Debian right now I have no idea if other teams have similar dynamics you know where is one example within too many I have my interpretation why this happens because there are people that consider their packages like their kits some kind of parental relation and so we hear often like I want to do this I want to do that my package is not your package if I understand Debian policy correctly every developer has the right to commit to any package upload any package right it's called NMU so just saying you know my package I want to see this for my package you can help me doesn't work I mean it scares people and it puts you know layer on top of the technical layer in this case you were talking first about the social problems sometimes in the teams I understand this but yes you also have the problem of the false team we have something that I want people they are saying oh you can join me but the truth is you can not join them I understand your frustration so there's only one meaning left more or less what I want to leave you with the point that Ruth talk is more what was my talk was about that maybe we are not getting so many new people in Debian because we are not trying to get more people into Debian we really need to invest more time in getting new people so thank you very much