 Hello. Good morning. Gregor is going to talk about how to integrate new contributors in teams. He has experience from Pearl Group, which is pretty large, as you know. So here it is. Thank you for the introduction. Welcome, everybody. As Franklin said, my name is Gregor Hermann. You may also pronounce it Gregor depending on your accent of English. I hope you will cope with my Austrian accent of English, but I will try to give my best. I'm a Debian developer now, since a bit more than a year. I'm involved in the Debian Pearl Group for some three and a half years, I think, now. And well, and I'm interested in social aspects of teams and Debian itself, not only in the code and in the technical details. Some of you might remember that there were two buffs last year in Matelblatter about packaging teams. We tried to find out, well, what works, what doesn't work, what can we learn from each other. And one issue that came up is that no team had a, well, a systematic approach or some guidelines or whatever for finding new members, integrating new members of a, well, dealing with people in general. So I thought it might be interesting to look at this aspect this year. And I hope we can do it together. This is not the talk I have to warn you. I will say something in the beginning, but then, well, I invite you that we do it together, although this setting with the cinema chairs is not ideal for a buff, but I hope we can manage. Okay. So, yes, I will start with two slides, giving a short overview about my thoughts for the next hour. And then I will invite you to join me in a little exercise, experiment, however you call it. You can stay seated. It's not dangerous or anything. I think that should take about 10 or 15 minutes together. So then we have time for discussion and sharing. And I have just put up a few topics we might discuss about so that we don't get lost completely and have a bit of a structure. Well, in the end, let's try to find a summary together. Maybe there are some ideas we have, what could be improved. And, yeah, I'm sure we'll get reminded by someone if we are running out of time, so that should be fine. Okay, so the title of this buff was Finding and Integrating New Members. The bigger picture, in my opinion, is if you look at people and teams, that you have something like a life cycle, something like a general model, be it a circle or if you draw it in a swirl, that consists of three stages or three phases. The first one is the start or beginning or introductory stage, which means from the point of view of a potential new member, that they have to find out about a team and have to actually make the decision to join it and to, well, then integrate into the team, find out how it works. And from the point of view of the team or of the other members, you could say that this stage is about finding and integrating new members. The stage two is then the regular working phase where you just are a member to your regular work. From the point of view of the team, the task or the challenge in this stage is to, well, on one hand, to support each other and also maybe to keep members, to help them from getting burned out or bored or overwhelmed or whatever. And then there's also a third phase, which I just labeled the end here, which means there might come a point in time where a member decides to leave the group, be it actively or be it just by going MIA or just becoming inactive. And the challenge for the team as a whole or for the other team members at that stage is to, well, to get to a reasonable end to maybe say goodbye, say thanks or whatever, or to remove them from the project on earlier, to find some defined end instead of just letting go. So that's the framework in my view. And now in this buff I want to look at the first stage and the other ones might be interesting if we have come up with something in the first stage. We might also look at the other ones maybe in another buff in the next step, so this is a long-term project maybe if there's interest. Okay, now what are we going to do now or what do I expect that we come up with? I think it's important to start with personal experiences. If we remember how it was for us as team members, it's easier to think about what it is like for new contributors. So we should think about that and exchange our experiences. Well, and then it would be of course great to collect some stories from different teams what works, what doesn't work. And I'm sure we will find some ideas for improvement out of that collection. Okay, now I'd like to invite you to a short exercise, completely non-technical. It's an imaginary journey if this is the right word in English. It's very easy. I would ask you to close your eyes when I say start in a minute. You can leave your laptop open, you don't have to move, you don't have to do anything. And then just to listen to my, well, instructions, proposals on what to think about and try to go back in time and travel back in your memory. Okay, are you fine with that? Well, so let's start. Please close your eyes if that's okay for you. And let's start the journey. Well, I assume that you are a member of a team that you are here for that reason. Please now decide which team you want to think about. If you are a member of several teams, please choose the one you're most involved with or most attached to. Try now to go back in time to the point where you joined the team or where you first came in contact with the team. It's not important that you find the exact date in your memory but the situation and the feeling at the time. You have arrived in the past. Think about how did you learn about the team? Did you find it on the wiki? Did you read about it on some mailing list? So what was the first contact? After this first contact at some point you thought about joining the team and you finally did. Try to remember what made you join the team, what triggered this decision, what motivations for applying to become a member were just pulled in by somebody. Did you see advantages like getting free sponsors getting help for your work from others for your reviews? What motivated you? So when you joined the team you got commit rights or whatever permissions, access to something. What was helpful in this very beginning? Who was helpful? On the other hand were there some things that made it difficult, some roadblocks, some obstacles. Was there anything you had to fight before being able to fully contribute to the team? When you joined and took your first steps in the usual work of the group, of the team, did you know what was expected from you? Did you know what being a member of this team comprises which tasks are usually done? Did you know what you could expect from the others? Were there some offers for guiding or mentoring? And when you made your first steps, which support did you get and also which support would you have needed in retrospect if you think back? What did you miss during this first few months? Okay, so in this journey back to the introductory phase of you being a member of the group, we have now reached a point where you are a regular member and I now invite you to come back to that confine, to cathars, which means if you like you can slowly open your eyes again, maybe shake your head or hands or whatever to wake up again and return to this upper talk room. Okay, I hope it has worked a bit to remember how it was for you. And I would like some people to just tell a bit what came up in their memories, how it was like back then. Yeah, well, however that works. It works? Yeah. I will tell you about my involvement in the Perl group. I can't remember the date but it was some, well, four or five years ago when I needed some Perl module for my stuff at work. It wasn't packaged so I wanted to make a package from that and I can't exactly remember how I heard about the group. It's maybe when reporting books to some other modules that I used and when the replies come from the members of the group and something like this I don't remember. And first contact, what was Gunnar Wolf? I don't see him here. Anyway, he might not remember. And I have recently found these third messages and I realized that that first contact was very helpful because Gunnar was very friendly. I was making some stupid mistakes that are obvious for every experienced packageer but he didn't point fingers and be rude to me, he was gently corrected and put me on track and finally even said thank you for your work and I was very enthusiastic about this. A year later I was a very active member of this friendly group already trying to organize some stuff, change radically, whatever I had some successes and failures. So in the beginning the important thing was that you were welcomed by a friendly support and a thank you. I was very much welcomed by all my questions no matter how stupid they are or how many documentation there is on the matter, somewhere was asked but friendly, it was just great. So thanks Gunnar, you're not here but you're possibly watching the video some day later. Okay, thanks Dan. Someone else who wants to share what came up in the memory? I'm Ode, my name is Ode. You have to put it closer. And I'm involved, for me it was really easy to recall I started with Debbie and Edu some nine or ten months ago and the reason I got into it was that I wanted to find a solution for schools with diskless workstations to make maintenance here and I got to see LTSP, from LTSP there were pointers to some other projects and I chose Debian because I was using Debian. Okay, so in finding the group it was helpful that there were some links on related pages that showed you the way. Actually what got me to LTSP was that someone has removed the diskless how-to from the Linux documentation. So I went the other way to the server side. I think Debian and Edu is probably a little unique in Debian because it's not about packaging, it's about integrating other packages into a ready system. So it has a lot of structure, it manipulates the installer, it does a lot of system administration in a box. So what I felt was my initial idea was to start something very basic, very primitive and let it grow and therefore I would have had knowledge of all the components and by going the other way and adopting Debian and Edu I faced other problems of understanding what was already implemented which is pretty mature and quite complex. I started by looking at the way Debian and Edu manipulates the Debian installer and some stages I could have used some help about how things are working on that level and it wasn't readily available. But also in Debian and Edu I felt pretty comfortable, pretty welcome and it was quite easy to start making contributions and get some codes into the system. What made it easy for you? Holger. Holger, okay. So which year? Holger? Okay, so it's again about the people, about welcoming. It's a lot about the people. What I feel though that is probably lacking is structure. Structure and what topic? For learning the system, to see what, to learn about how the system works and how to get some sort of a path for learning and also for getting in some kind of... So something like an introductory documentation for new contributors? Something like that might be helpful. Yeah, and there's a lot of it but it's not always understood. There's also a lot of different, I don't really know how to explain it because there's different kind of projects. Okay, so it was a bit complicated in the beginning to find your way around the whole project. Yeah, and the other thing is culture of free software and free people who they don't really want to tell others what to do but sometimes a person wants just directions, not instructions, just direction and if for example on the mailing list you may ask a question that people will not answer because either because they don't know so they will not write, I don't know, because it's not helpful but some people get the impression that they don't get a response, they don't know what it means. Okay, so maybe a bit of guidance, mentoring in the first time would have helped you. Okay, thank you. We've had two teams now, maybe a short third statement from a different team. My name is Peter Reynoldsen and I would like to share with you some of my initial experience with joining the Debian installer team. This was a long time ago, shortly after Joey has abandoned the project and decided to spend time elsewhere, we in the Debian Edu project discovered that the old installation system didn't do what we wanted so we had to come up with a different mechanism and decided to go with the Debian installer project. Basically I was not a Debian developer then and I started just looking at the source poking around the CVS tree and hanging around on the RC channel and discussing with well, whoever was left there, I think it was Tollef again that was mostly active at the time and we started to work together on improving the installers to get the appointment to actually install Debian and I always felt that the Debian installer project or the Debian installer team was very welcoming to people that wanted to do work. They were giving access to the CVS tree without when a lot of administration or bureaucracy they would give us the opportunity to help. That was the really important thing to get things working and to actually become part of the team is to be able to contribute easily without having to spend a lot of time proving yourself worthy of the whatever cause of the project. So this little threshold for entering made it easy for you to get going. Yeah and the Debian installer team was I think the first team in Debian where we would allow anyone to contribute to the CVS and they had a few people able to actually upload packages so once a month or so the two uploaders would wrap up all the Debian installer packages like 30, 40 packages and upload it into Debian and see if it worked. Of course we had some testing, automatic testing going on and a lot of work to make sure that the changes done was actually improving the packages but still it wasn't very hard to do changes and you were expected to take risks and it wasn't a big deal if you broke the installation it was a normal way of improving things, try and see if it works if it doesn't go back and start over or fix the problems and move forward. I think that attitude in the team is very important to be able to accept new members because new members of course are new, they don't know all the horrid details of the project and they are not expected to either well eventually Debian installer is so complex that nobody knows them. All the details of that project but still it kept the low level of threshold to enter the project I think. Debian installer it's still possible today to move in and work on one specific topic to fix whatever itch you have in the installer and get that patch accepted very quickly. So the implicit message was it's fine if you make errors that's just normal and work what we do with it, it's no problem, just go ahead. I think that's very important to make it easy for new developers to not be afraid of contributing. Okay, thanks Peter. So now okay, screen saver has turned the screen off completely now so we've heard some of your experiences now and in the next stage I would like to try to collect them and also the other thoughts not only when we were new members but also from our experience now in a bit more structured way. As you see I have not been taking notes now because that would be too much besides speaking and running around. I have set up this more or less empty page on whiteboard.debian.net and I'd appreciate it if some of you could just take some notes while we are going further. Okay, well this could be topics we can discuss and I'd like to invite all of you to just share your thoughts also your experiences that you now have with new members. As a first issue that's the question about how do you get to a team where can the information be found, does it work or is there some need for improvement? In this first round now we've heard that well replies to bug reports can be a way to get to know about a team that links on related pages can be a way to find a team. Does anyone have an idea what other ways to advertise your team exists and which of them actually are useful in work? Yeah, it was quit. This is working. I have two now so you will hear it. We hear you in stereo. Okay, if you allow. This one is work. Okay, well I'm Kurt Grammli from Germany. I said it before in the talk before. I'm doing the project leading in Germany for Debian Edu. So there are some experience and let's say our tricks how to win people. Cool, that's what we're looking after. So somebody says be aware when you speak with Kurt perhaps after that you are a member of Debian Edu and I found the different groups and teams in my time in free software but also I'm politically involved in climate change and other things. Very important thing. So what I want to say, what have you done? I got involved in Debian Edu because we tried in Germany and I'm responsible for some schools and I'm working in adult education. So I had to use in the evening computers with adult person where people and students have played in the morning and the adult person they paid money for. So you see the problem and it's called Volkshochschule. So this was my point to come in and then I saw this free software possibility to connect to internet for schools. This is more than 10 years ago now and I started with SUSE or the normal German way until you hate to reinstall everything from scratch. Well, it was clear. I started to build a Linux user group as it were in these times everywhere creating user groups and this user group helped to build up a big event with more than 60 talks in one day and then we saw the installation of a German school server and there were some Debian people besides this installation and then it was clear we need to have a Debian school server. So we start to design it and then while designing there was a mail coming on the Debian list that there are Norwegian guys won a prize. Then we started to test the system but it was in Norwegian. Nobody knows Norwegian so it was the first install system in Norwegian language. But I saw the packet list that it must be the same system we... Well, then I joined the conference in Oslo and then so what have we done now for this purpose what we are discussing now? We built up a wiki and if everybody asks a question on the mailing list or somewhere we ask him, oh, could you please take an account on the wiki and it would be nice if you as first build your home page and says what are your interests in education and what you are doing, what you are knowing. So these are pages about people? About people, about the person. A short profile. So we started with about 400 pages on the wiki. We have now 4,500 and we have now 400 subscribers. They could write in the wiki and we have more than 200 home pages. So now if you join this, it's all in German, sorry, so mostly in German. So if you join and you build up your home page, it's less than a day. Somebody will ask you, oh, I have the same problem. I've done this blah, blah, blah, blah. And then we organized, we had our test center, we built up a test center where we can test software and learning and teaching together and then we have about once in a month or once, two months. We had a meeting and we invite actively new persons to come and to see us how we work. And normally every time in this meeting we learn something, we never thought that we learn this. There was always some prize and a lot of fun in there. Well, it's no time to sleep while this meeting and so, but it's similar like here. So the point of the wiki page is that you don't join an anonymous group but you know who you're dealing with. And so you see a list from the person who is active because you see the name always in the wiki and you see the recent changes and this is, then we have some pages you will find, if you give in Google, if you give Lern software, the German name for teaching education software, you will, the third or fourth hit is our wiki because we collected a lot of free software or still unfree software we like to change. So I think recognition is the most important point to be aware if somebody is new and then to contact him and to help him in the first steps. This is somebody who has to do this job. So this is mainly what I'm doing. I'm not a devian developer, I'm not a package maintainer, I'm doing something like community management to watch this and there's also some, there should not be a question on a mailing list not answered let's say three, four days. There should be a response, any response and if, well, if it's not so good public, private response, you are welcome or something or perhaps join these people or look at these people there you could find answers or such things. So this is important and let me finish. We also sought to build up a way how to become member and we look at the new member process from devian and thought, okay, well, this is heavy stuff. We should reduce the barrier. We should look, then we build up something we call new member new member process and it was German. So it was so complicated and so bureaucratic that it doesn't work because the people who has to do the work to help the new members they were overloaded to check all, does he have a mail address, does he have this, does he get the t-shirt, does he have it being at the meeting and all, we reduce this. And now you can just apply for to be new member then you wait half an year and look, have you done something, have you been at a meeting but it's very low and then we say, okay, you can have an email address, scrollinux.de or something like this, some recognition you will find it in the German wiki, scrollinux.de. Okay, let's stop here. Okay, so maybe one question. So after the people apply it's your job to mentor them, to support them, to give them some initial guidance. Have I understood this correctly? Okay, I think I will talk to you in detail afterwards. Thanks. Okay, any other experiences with promoting the team? Like we've heard it now? No, okay. Yeah, reasons for joining means advantages, motivations. My thought behind it was which advantages, which benefits can we offer to potential new members and how can we communicate those benefits? Does maybe some group have on a wiki or wherever on the project page something like, this is what we can offer you, this is what you get for free when you join. Are there some experiences in this area? Okay, Tim. Okay, so I found it really interesting when I was just getting into contributing to Debian, there's the whole, even before the new maintenance process, you have to adopt some packages and so on. And the way a lot of new contributors seem to try and go about it is following ITPs for new software and trying to get new packages on their own and then go through the mentors, Debian Mentors List and so on. And that's actually a really quite a difficult process. But when I started getting involved with teams, one of the big benefits was the sponsorship that it's actually a lot easier to get a sponsor when you're working with particular people with new people. That's something we should probably advertise through the documentation for new contributors to Debian more that actually getting into teams like, well, whatever they're interested in is a huge benefit of joining a team. Where could we advertise this more? I'm trying to think where people go to look for how to get involved in Debian. There is a web page on Debian's site, but I don't think anyone ever finds that. Yeah, that's something, how to help Debian or something like that. Yeah, but no one finds that. Somewhere in the mentors, Debian.net documentation, because that's where people end up and really emphasizing there that go find a team, because it's great. Yeah, we've heard it also yesterday in Datu's talk, I think. As far as I understood the Spanish, it would last it a lot, yeah. Okay, and grabbing people on Debian mentors list is probably also a viable way. Okay, any other ideas on communicating benefits? Yes, I think that we generally really search at saying that we need help. For example, I was observing Debian for years before I started getting involved in Debian development. I think that we need to try to send a message that we are looking for new contributors. For example, on the planet, often people talk about what they do, but not where people could help. It's something that we could use more, because people who are Debian users and might get involved in Debian development usually read planet Debian. And probably listing very concrete, detailed, small, simple tasks would make it easier than to say, well, just join, just help. Okay. Anything else? Yeah, just a small aspect of reasons for joining a team is that I think that a team should always make very clear what is the advances for the package maintainer to join and what's the advances for Debian as a whole or for the team itself to join. So that the new member gets motivated to join. For instance, the Debian Perl group is, in my opinion, very open, very accessible. It's very easy to join. On the other hand, Perl packages are very small and very easy to maintain. So there's no real reason to maintain one particular package with multiple maintainers. So it might not be clear to everyone the existence for the Perl group. Why is it? And I think the Perl group should also do more selling from what is the real advantage, the reason of existence of the Perl group. It's not just a collection, but there are some synergies that can help to maintain a large number of packages, et cetera, et cetera. Okay. So you think if it's clearer what the purpose of a group is, then this could motivate people to join. That it's not just some random version control system where everything ends in. Okay. Thank you. Good. Well, yes. We have about 11 minutes and three more topics so maybe we can just combine them a bit. Stepping stones and obstacles. We've had about, we've heard a few of them which what helps, what makes it difficult. We've had this mentoring for new members. We've had the idea of maybe some introductory documentation to find your way around in the group. The obstacle being that at first look it's a bit, might be a bit complex, all the stuff. Yeah, that's also the last one integration ways of support. Does anyone have any other ideas or experiences? What is helpful in the first weeks, months, or what would be needed because it was not helpful? I just like to stress the point that was brought up here that I feel, I didn't say it and I feel it's the most important, is the confidence of the newcomer to actually write either it's on a wiki or code to actually add his stuff in, make him confident to do that because make him feel like he's being watched and there are people to fix if he's doing something wrong. Okay, so that's what Bette has said before, that it's okay to make mistakes and that there will be a helping hand around. Yeah, I just wanted to make it clear. I think it's probably the most important aspect. Okay, does anybody accept, could have any experiences with some mentoring in groups? Doing this, that new group members? Okay, that anyone is assigned a mentor, that there are inter-facial people who grab the newcomers and try to help them. Is there something we could learn? Okay, then I will try to talk to Kurt afterwards and we will try to summarize these experiences. Yeah, mutual expectations, that's about the question, do new contributors know what will happen to them when they join a group? Should they know? Does any group have something like requirements? I mean, one thing I remember is FTP masters asked for new FTP assistants that they said, okay, you should have 5-10 hours time per week and it would be good if you knew DACA, whatever, code and language and you should be familiar with licenses and stuff like that. Are there some other experiences with such descriptions or list of requirements? Is it useful or is it maybe not helpful in the context of free software? Well, we have a description in our wiki and we looked around what exists and we found this Ubuntu declaration for not to beat each other, not to bite each other and these things, we reduce this a little bit or we reduce it to little things because we also experience on flameless, on mailing lists and so on, we try to reduce this so that it be kindly handled. The special thing in Debian Editor is we are handling teachers. Nobody else in the world has more fear to make mistakes than teachers. So it's a special way to learn that free software to make mistakes is a good thing because it's a thing to learn and this is for teachers, very difficult. So often a lot of traffic is firstly going in private emails and then they need some help to allow and to use his name publicly on a mailing list who is public saved. So every student or pupil will find in Google the teacher's name. So it's a special thing so we had to be aware of this. So I think to help somebody to get the first step and also to find out what is his real interest. There are so different interests to join a group, a cognition to spend his life in, I don't know, the English word, a more meaningful way of life. To find out what is his purpose, what he wants to do and to give him some examples what he can really do, some small shops so that he could be involved into the community. This is often needed, as I see. So it's not that you have requirements like you have to spend so and so much time and you have to have this and that technically experience but it's more like offerings what they can do and what they can gain out of it. And also this practice to make it as transparent what you are planning, what you are doing. So you find in the weekend under my name, you find goals. I have listened publicly my goals what I want to reach in 2000, 2000, 2003, 2004. And there you see, didn't reach, didn't solve, still not, still on work. So it's a kind of professional work as I do it in my company. I have goals, I try to reach them and try to... Well, and a special thing for mentoring what I'm doing, a special thing is I don't know the English word. I have given a talk about open management at the Linux talk in Chemnitz. Perhaps somebody, there is the sound also. I use this thing called in German Wieder Vorlage. I don't know what is it in English. So I have a very small system, a grown job who gives me a reminder that I should contact these people if there are nothing has happened meanwhile. So if there is something I suspicious, then I do a Wieder Vorlage and four weeks later it reminds me. Then I contact these people, what's going on with you? Why you didn't answer, what's happening with you? So a lot of family stuff and all these things. So what's coming to this all this deviant developer they're getting father, getting children like better and others and that will change a lot of life. So that gives them the feeling that you care about them? Right, yeah, this is important. But the big problem is if somebody is not able to handle with me that's the problem also. So I look for some advisors who are carefully look that I'm not only the good dictator, not so that they control me or I ask them not to but there's also bad or hard experience emotionally what you have to be aware when you do such a job. You will lose a lot, you invest in people a lot of love and you, well they go away and you had to be aware that they go away without saying thanks or something but you could go your way. So that's... Okay, thank you. I think we have one minute or something like that. Four minutes. So my clock is late. Okay, so yeah, do we have a conclusion except that I hope everybody has taken notes of every good ideas in this whiteboard and I will sum them up in a mail on Wikipedia or slash team slash something. Is there something, some final thoughts about this step should be taken, this step should be done, some next action item on this topic? Okay. If there are no more ideas I'd like to thank everybody for coming and also for contributing during a session like that that relies on input from the audience is always a bit of a risk because everybody might just hang around on ISE but you were really active and I enjoyed it. As I said I will try to wrap it up and maybe work a bit further on this issue. So thanks everybody and see you later.