 to give the stage to Hannah and, yeah, the NMQ. Three of these microphones work. Okay, great, cool. I'll just assume they're all going to work, and if they don't, you can tell me to start speaking. Okay, all right, well, I'm Hannah, otherwise known as Bubbles, apparently. And that's Murray, and that's Daph. And we're going to be talking about the Debbie and New Maintainer process. We're going to give a bit of an idea of the history of the process because in talking to Debbie and developers over the past six months, yeah, we've realized that many people actually don't know how the process came about and what exactly happened. So we thought it would be a good opportunity to tell you all exactly what happened and look at this and see whether the New Maintainer process is actually achieving the aims that we might have hoped it would be. So precisely what we're going to talk about is on the screen there. We're going to give a history of New Maintainer process. We're going to explain how the process works today, look at the aims, and also see how we could do better. So over to Murray. So when Debbie and started off, there were, unsurprisingly, wasn't much of a formal process. Basically, well, at this point, Ian Murdoch still controlled access to the archive. So if you wanted to get a file in there, then you could either sort of get friends with him and you get an FTP account, and then you could just upload things directly. But for a lot of other people, there was what we've called a staging area. So you could upload a file and then Ian would look over it and then, if it looked reasonably sane, it would get put into the archive. So that's obviously, you can see that has some analogies of what, well, if you know about the NM process, that will have some analogies to you about what happens today. But this is a pretty simple version. So it's very informal. And this is just a quote from BDEL. Should we read it out? Yeah. So, yes. He read Ian Murdoch's WM Manifesto, well, let's read it, resonated with it, and dove in. Within a couple of days, he was asking Bruce Parran's how to country it, how to package an email to Ian to us, tell him who he was and what he'd done. And he just got an email back from Ian, thanking him for the contribution and saying, welcome to the project. So quite different to the new maintainer process nowadays. Yeah. After a while, they stopped working. So as they've been and got bigger, more and more people joining the project, this process was too simple. It needed something which is a bit more sophisticated to deal with the amount of people who wanted to join in and contribute to the project. So they set up a new maintainer at devin.org email address. You send an email to this address, to ask for an account. This email would go to Bruce Parran's and he would read your request and create an account for you. Funny enough, they stopped working after a while. Yeah, one person doing all the work. That's something to do with Bruce resigning. Yeah, and that. I think this is actually, it's actually stopped working before then. This is... Right. Exactly. Yeah, this is 1996-97. Yeah, yeah. So in April 1997, Bruce delegated new maintainer approval to the security team. And applicants were supposed to say who they were and what they planned to do in Debian. And the security team would assess their applications, decide whether they were suitable and create an account for them. Seems fairly simple, seems like a good plan. Yeah. Yes, well done. So, a couple of months later, yeah, that was in April. In September, fortunately, who knows what would have happened otherwise, but fortunately, Elmo and Joey came to the rescue. So, yeah, they hatched a coming plan and decided how they could infiltrate the system and take over the new maintainer process. And as you can see, this is very complicated. You can see the conversation that took place right there. There we go. Yeah, so here's a quote from Elmo about this. We've instituted minimal procedures and we had to have a trust path to you. We didn't at this stage, this is comparing to the situation today. We didn't have this whole novella question and answer thing. You merely had to say what you were going to be working on and you didn't actually have to show that you could do this already. You just had to have an interest. But on the other hand, they did phone and talk to every applicant, which obviously gave them some idea of, well, does this person exist and does it sound a suitable kind of person to be in Debian? Yeah, after a while, this stopped working. So, people complained about the speed of applicants getting processed. Because there was only two people doing the work, it turned out that there was a big gap of people. Just too much work for people who are also active in doing other things in the project. Very busy people. Just couldn't keep up with the workload of doing NM. So this resulted in... Do you miss a slide? Okay, so there was lots of discussion. And after many emails, the result was a person who had four steps. Initial contact with the applicant, checking the identity of the applicant, checking that they are who they say they are. An internship period where they get involved with the projects and get through a sort of trial period. And then after that, they get reviewed by the NM committee and approved or rejected. Oh, maybe we did miss a slide. No, we didn't miss a slide. That's fine. Anyway, so as a result of this, Elmo decided that he was happy to remain on the NM team. The details of the new NM process were worked out by Dale Sheets. And as you can see, there's Elmo loving NM. Thank you, bubbles. Anytime. And the new maintainer process is pretty much the same today. So, yeah, just some of you probably have gone through this and will be all too familiar with it. But for those of you who are either in the process or thinking about going in, I'll just summarize the overall shape of what the process is today. So, well, first of all, we can say who are the people involved? Obviously, as someone trying to get into Dabian, you normally get referred to as an applicant. So therefore, the person who you really deal with as an applicant is called the application manager. So this is someone who'll send you a lot of annoying messages saying, can you answer all these questions? Can you fix your package? Yeah, I found like you've got some double spaces in your Dabian rules file or this kind of stuff. I'll ask you to remove the comment and then I'll put it back in the next day. Yeah. Yeah, so you speak to the application manager. There's also this sort of mysterious, shady figures lurking in the background somewhere of the Dabian account managers. And as the applicant, these are sort of somewhere bit distant from you. But you kind of know they exist and, in fact, they're really the people you're trying to impress because you've got to get past your application manager. But if the account managers aren't happy with you, then you won't get an account. And then there's these other people who kind of float around somewhere around the process where the front-deaf members and they're basically responsible for sort of running the day-to-day stuff of New Montana. So they do things like they assign incoming applicants to application managers and make sure that everything's ready before the information goes off to the Dabian account managers to actually create accounts. And there's a couple of other changes just to sort of finish off the history that have come in over the last period to kind of complete the NM process as it is today. But it's quite significant that kind of gradually came in but is now meant to be a definite requirement is that you should have made some contributions to Dabian before you apply. So you shouldn't... Nowadays, if you apply to NM without having done anything yet, then basically the idea is you just get turned away at the gate and so I'm told to come back a bit later. So, for example, for the majority of people who are trying to become package maintainers, it's meant to be a requirement that they should have a package already in the archive that they've been working on. Also, another requirement in that that's kind of related is that if you're a new applicant to the system, you've got to find... Well, it shouldn't be that hard for most of you, you've got to find one Dabian developer who's happy to write a short paragraph about you saying, yes, this person is suitable. So again, the idea there is basically that if you've been doing work in Dabian at all, there should be at least one person who thinks you've done something worthwhile. If no one knows who you are at all, then probably you haven't done enough yet that it's any point in you trying to enter the process. So, this might sound very complicated, but in reality, it's not actually that difficult to do NM. So for those of you who haven't done it yet, you've got to write a simple guide for how to go through the new maintainer process. So the first thing to do is start connecting to Dabian. This is fairly easy. I believe we have a question. I should congratulate you for staying within Enrico's range of 7 plus or minus 2. So once you've started contributing the project, then you find a developer to bribe. This doesn't have to be very much maybe... Yeah, money, all works well. Yeah, nothing too ostentatious. Yeah. Then you just have to wait for a while. Eventually you get an application manager assigned to you. You then use your lead skills to impress the application manager. Your impressed application manager will send a report to the virtual then impress the account managers. Now you need to hug Elmo. This might be a bit difficult. Given that she's... Yeah. Just in terms of... He lives in London. We've got his phone number. So if you need to know how to do it, just ask us afterwards. We can demonstrate if... I don't know if I'm so happy with that. Okay, that's good. Once you've hugged Elmo, he'll create an account for you. And then you can profit. Pretty simple all in all. I don't know. Why are you talking about brief bits about the new maintainer templates which were produced by Jurg a while back. And these are a set of template questions for applicants. They're designed to be used by application managers to kind of guide the entire process. And they cover things like philosophy and procedures. So you'll be asked to answer questions about the DFSG and tasks and skills. So you'll be asked to do stuff with the bug tracking system. That kind of thing. And many application managers follow these pretty much to the letter. Some people use them as a basic guideline, which is I believe how they were intended. And some application managers don't follow them at all. So I believe after producing those template questions Jurg was appointed as a new dam and he checks over the applications. You can see a very nice picture of some application checking there. And Elmo creates the accounts. Yeah, so you could say, well, has the NM process as it is today worked? And overall you could certainly say, well, we'll talk about some criticisms in a moment. But overall you can say it has worked because the NM process as it is came in. It was, well, there was this way to get into Debian in principle, but it was it become impossible that you could apply and nothing would happen. Whereas since the NM process has been in its current form, there have been, well, our latest figure was 715 people have come through this process in five years. Which is, well, it's about 45% of the applicants who have ever been, have ever been Debian developers. And well, it would be a bigger fraction of the people who are still Debian developers at the moment. Yeah, it's about 75% of the current number of active Debian developers. Right, so this is obviously a great thing. We've got new people in Debian. But I think we feel that it's worth looking at whether we can improve the process and do better. And the most frequent criticism is that new maintainers, this is the process. This often puts people off. They hear it's a long and arduous process and I think this is quite discouraging to people who are considering applying. People tend to get stuck when they're halfway through the process. They lose contact with application manager for some reason or another. It's not clear what happens, but they get stuck, they get put on hold, they eventually get rejected. I think there's a problem that people don't often understand what the application manager is expecting for them. They know that they have to communicate with the application manager, but they're not sure exactly what they have to demonstrate. One of the main problems is the wait for application manager assignment. This is largely because of the limited number of application managers. We have 904 roughly active dev-in developers in dev-in today, but of those only 34 are active application managers, which is few point eight percent. It actually turns out that there have been many, many, many application managers over the years, but for one reason or another people have stopped being application managers. It would be interesting to see how many people here have been an application manager? How many people are currently and they have an application to the moment? Yeah. All hands drop. I think that could be representative of dev-in as a whole. So lack of application managers is a problem. I think we're going to take questions for the most part at the end and just small comments and stuff now. So what should we be aiming for? Clearly the overall aim of the process is to have new people in dev-in suitable people. As long as we're doing that then we're basically doing okay. But and the key things for being suitable for being a dev-in developer are having an appropriate outlook, having a philosophy in favour of free software and having skills so that they can do useful things in dev-in be it packages or translations or whatever. It's interesting to consider a warning in a nightbook. In a nightbook you have like five seconds to react. Yeah. Okay, thank you. So it's interesting to look at the relationship between the application manager and sponsors of people. So sponsorship is an official developer that sponsors a package for somebody who is doing things for dev-in but it's not an official developer. So it's interesting to compare the role of application managers who act in an official capacity to bring people into the project and sponsors who work in an informal less efficient capacity to sponsor new people. So the difference between testing people and teaching people and there's obviously some overlap between those two roles. So some things that I've been, well we've all been thinking about lately one thing that I'm particularly interested in is theory versus practice. So because so many of the currently active application managers use the template questions this got me thinking about the extent to which the new maintainer process was actually contributing to the dev-in distribution. So if you ask people a bunch of theoretical questions and get them to write academic answers on them that's fine. They're very much demonstrating that they have an abstract knowledge of these concepts but answering questions doesn't directly benefit the project. Obviously it does mean that you can test whether people are appropriate for being dev-in developers but the actual product of the new maintainer process is then just a set of answers. Many application managers won't let these answers be put online. I know my application manager isn't too keen for that. This is because it makes the job of other application managers harder when they have to check whether somebody's just copied the answers to questions. But this means that the entire process certainly as I'm going through it at the moment has been at least so far a lot of answering theoretical questions and then sticking a text file in my home directory and that's it. I really feel doesn't contribute towards the distribution towards the project as a whole. So I'm really interested in whether we could go about actually testing skills in a much more active way. So for instance rather than asking questions about the bug tracking system let's fix some bugs. Rather than asking questions about documentation, translation, internationalization, QA, just anything where we could be doing tasks it's better to be doing the tasks and actually seeing whether people can do them than just seeing whether they abstractly know how they might go about doing the tasks. And I should say that although I have been answering many theoretical questions from my AM we are actually doing some more practical stuff for the later stages of the process. And another thing that I've also been thinking about is collaboration and communication. Debian is a large community. We've got 900 and something Debian developers. That's a lot of people and a lot of people who are intelligent and want to have their say on things. A lot of people who post a mailing lists and who feel really strongly about the project which isn't that surprising. Most tasks in Debian will require collaboration. This might be in the form of working with other developers or it might be in terms of dealing with users fixing bugs, asking users about the bugs that they're finding, that kind of thing. So one thing I've been wondering about is whether we should actually be making a more concerted effort to see how people respond in terms of communication and collaboration skills. It's great if you can package stuff. That's obviously very important but if you can't hold a coherent conversation with your users or if you can't collaborate productively with other developers how much are you contributing and it's not clear how we could test for these skills or even whether this is the right thing to do. We could look at mailing list threads just as we're asked to look at licenses and say whether a license complies with the DFSG, points out ways in which it doesn't. We could ask applicants to look at a mailing list thread and say how they would respond to certain posts. There are many ways we could look at this kind of thing. So I think that's something that we should at least think about. There's some more general discussion which as I suspect some of you have have things to say. I'll just ask how we should actually think about the NM process. The conventional way to think about it is people normally see it as just this big test that you have to get through and really it's seen as a barrier to getting into Debian that people think well I want to do stuff for Debian but if I want to get a real membership of Debian I'm going to have to go through this silly process of kind of preventative measure. Maybe people think that's a good thing in some cases because it's keeping out bad inappropriate people but it's still generally seen in a pretty negative light. But I think it's worth remembering that we can see the NM process in a much more positive way that you can say well Debian is this community and just as in the real world if you move to a country you don't immediately get citizenship. You have to show that you want to actually be the same for Debian and it's not just then a question of trying to exclude people but it's a question of how can we actually bring people in and make sure that they do become full members of Debian and in many ways you can then say actually well having this formal process makes us a lot more open than many other projects. There are a lot of free software projects where there's this very small group of people who are the core members of a project and it can be very full member of the project like that. If you weren't in there at the start often those people really want to keep a very tight control over it and not hand anything on. Whereas for Debian by the time as you go through this process you're being brought in and by the end of it you're a full member just as if you well with the same rights as if you had been in Debian from the start including for example obviously the voting rights as well as upload rights. We can positively see the end process not just as some kind of big negative test but as something that should actually be bringing in people and meaning that by the time you've gone through this process and become a member of Debian you should have a feeling well we should have people who have a feeling of responsibility and commitment not just to their own package that they want to get in their new ISE client or whatever but they should actually have a feel this towards the whole project that and also of course to the more general free software community. So that's basically it at this point we'll be happy to take questions and kind of open things up to more discussion we have just under 15 minutes left and we do have to get out of here pretty promptly at the end so keep your questions short we will cut you off if you go on for too long yeah. Microphone. See I have the microphone. No I just wanted to make a quick observation on what Hannah was saying about collaboration during Andreas is small groups in Debian talk I even suggested maybe making us part of the new maintainer process serving a kind of apprenticeship in one of the teams that we have in Debian already because that way you know we can see how well people are working with others and that kind of thing. So next question it's quite a challenge to keep that one short but I'll do my very best so we have about 900 developers and in my last statistics that was about 180 actually active which makes about 700 developers that are more or less active or are completely inactive and all of those which enables them to write to the archive I think this is a huge security problem now I appreciate the work that you've done you've done a great presentation of the NM process and I think that also all the people who have worked on improving the NM process in the past couple of months have done a great job but I want to raise the question whether it is actually what we want do we want to streamline this process to get more and more people into Debian and maybe this is what we want if that is what we want do we also want to make sure that we can get people out of Debian again because I don't think that we are going to be able to scale just in terms of number of developers we see it now we're not scaling well and it's just not going to get better yeah I I think that's a really great point I think we definitely do need a procedure for getting rid of developers well we do to some extent already I mean there are the missing there are people working of course on the missing in action checks trying to pick up when people stop working on their packages and well and then either sort of politely or less politely if to sort of encourage them to give up those packages and lose upload rights basically if they're not going to do anything else I mean there is some procedure that already I mean obviously yeah it's unclear exactly how we're going also I mean another well a related question is when you have people who are if well if you've got someone who's uploading a very rarely changing package then it's an open question of should that person have full upload rights I mean I think it's dangerous to say they don't need them therefore they shouldn't have them because as I was saying at the end is good if we can have people who genuinely feel that they are a full part of Debian and it's dangerous to start saying that you don't sort of this package you're doing doesn't really count we won't let you in and I think something related to this is also the fact that you don't have to be a package maintainer to apply to be a Debian developer you could be somebody working on translation or documentation writing yet everybody who passes through that new maintainer process gets upload access so this kind of I feel we're in this kind of conflict situation at the moment where on the one hand everybody should know how to deal with packages because they're all going to have upload rights but by the same token that means that people who don't actually want to maintain packages are being forced to go through and develop knowledge that isn't necessarily appropriate to them so perhaps we need to look at how developers do or which developers do different tasks and maybe look at restricting upload access depending on whether people are actually package maintainers and whether people are actually writing documentation and doing other tasks I will follow up on that just quickly it's not just upload access it's actually shell access and that can be very important particularly if you're doing website stuff but to follow up on your question about security surely you're more concerned that there's people who are going through the NM process who won't get in who've been explicitly rejected but have packages in Debian anyway I mean in person every package in Debian should be there by a Debian maintainer and the process should be short enough that realistically maybe the first upload isn't but every subsequent one should be I just have a mic here I just want to come back to my question from the release team that on the one slide there was a 7 plus 1 item list and there was a single person named on it and so if somebody wants to go to Huck Elmo in a restaurant and they both two get some food with Salmonella and they go to the hospital for few weeks what will be with our new maintainer process maybe we find some other person who is nice to Huck perhaps a nice woman to get some more people in but what you're saying is we need to clone Elmo just find some okay at one point in time during the last year I did actually raise the point of separating more the actual features you get with Debian developership and I see them as being the ability to vote your Debian.org email address, shell access and upload rights and upload rights should only be there for those people packages to maintain I know so many translators contributors bug fixers, user support people, PR people that don't even bother to go through the process because they don't need to and I think we should learn from that a quick follow up on the security question I think in order for a non maintainer to get a package into Debian they have to go through a sponsor and I know a couple of sponsors that will just simply take the package recompile and upload it and not look at it and I've seen it a lot of times before I think it's okay to do that when you've worked with a guy for a girl, sorry for a couple of months for a couple of packages and you know that that person is generally reliable you have no reason to believe otherwise but it's definitely not okay for new mentees and I think we definitely need to do something here too we need to probably institutionalize the monitoring in some ways well again the sponsorship system works a lot better when it is as you suggest someone who you actually work with a particular sponsor and try and learn from them but that's not actually enforced in the current system and it's perfectly possible just to go on to ISE and say I've got this cool new ISE client who wants to sponsor it and wait for someone to come along who will say yes and there's nothing to enforce that the next time when you have another upload it adds a root access hole or something that is actually even the same person who looks at it I have a comment to make the current process does have a requirement to fix some RC bugs and the packages check is at the end maybe it should be a bit sooner so the AM can get the impression of your packaging skills and not only after you answered all the questions yeah I mean another thing worth noting is that if the AM is doing well if the AM is doing their job basically they should also be looking at what you're doing in Debian outside their direct communications with you so they should be looking at what you've done on mailing lists what other bugs and packages are working and not just the packages that you've sort of explicitly maintaining yourself so I think often people applicants often don't notice how much the application manager is doing it's the only really cause to note if the application manager asks directly about it a couple of notes one about the length of the AM process often we complain about the length of it but I've been following some applicants which are not my applicants and more than complaining about the length of the process we're complaining about having to do these things they totally wouldn't care about and I mean they have other things to do in the project they would like maybe to maintain another package but they hold back in like studying maybe a sub policy that they don't care about or writing a main page for a software they don't use and so having to figure out also how this software works so that's one like focusing more on people needs for example when I've been on AM I've been looking at the packages people would maintain and ask questions about that specific area because I remember that I've never been asked questions about like the Python policy but then well no that's the wrong example because I have a bug saying I don't want to look into the Python policy I want a co-maintainer so not the Python policy but I've never read the per policy but then when I had to maintain a per package I looked at the per policy and I did it so that was one can I comment on that? I think that's a really good point and I think it's important to make sure that we do check all of the skills and areas of knowledge that any given person working within Debian will actually touch upon during their time as a Debian developer but the way we're doing that at the moment is to have this kind of one size fits all procedure and test everybody on everything and that's perhaps not such a good idea as you're saying but then we get into the situation of how we structure the procedure if we don't do that kind of thing because then you're putting a lot of well you're basically asking application managers to put a lot of effort into working out what's appropriate for each person and I think that might reduce the number of people who are willing to be application managers but I think it might be worth doing so I guess the question would be how best to do that Well okay that was one and the other thing is at this point about having different levels of upload access like I've been an applicant who was maintaining like localization packages I had an applicant who was maintaining Python packages and that was like and they knew such a huge deal about localization and Python policies and everything so I was really happy about let them go but then I have no idea if one day they will maintain a shared library what is going to happen and I was not wanting to bug them about shared libraries at that point but then why not like that would be a huge infrastructural change so I guess people will tell me like if you want to upload a shared library then maybe there's a little bit of an M to go through just to make sure that you know what's involved because what's happening now is that people don't know about shared libraries they happen to have to maintain one and they have no idea there's a library packaging guide they have no idea of the things involved and you get all sort of havoc I also have a few comments on the things that were said earlier I do know that you can't manage to check more than just what direct communication with the applicant and so if they do look at what you've done in mailing lists and so on they also already have a few of social skills and whatever so that is being tested implicitly on some level maybe it should be more obvious in the evaluation form that the account manager fills out because not all account managers do look at what's happening on mailing lists even feel they could possibly bring that kind of thing into their final report for the account managers so yeah, I would agree that it's perhaps not A second point is that I think it's good to allow account managers a little bit of freedom in judging people I know my account manager did I never went through the tasks and skills part based on what I'd already done within the Debian installer team the internship which was fairly intensive and so it already does work in that way that in some cases if there's a really good reason that it's a bit more flexible than the process that's been and I think that's a great thing I just worry that we're heading in the direction of just very standardized testing and I'm not a big fan of standardized testing a very last remark I agree that it's not really useful I don't think it's very useful to assign people tasks like fix an RC bug because you need to have an RC bug that is suitable to that person and it will often take a lot more effort to find a RC bug that is suitable to their skills than doing more general tasks and having standardized testing that's the downside of what you were proposing absolutely firstly I agree with everything you're saying about the new maintainer process I think you're exactly right and I think that the people who are worried about the question of allowing people upload access when they might not need it or shall access when they might not need it is very that's a really important question but I think there's another effect of the fact that most people going through the new maintainer process are going to be maintaining packages which we're overlooking which is that one of the consequences of being a developer is that you get to vote in Debian elections and at the moment we are effectively denying people who might be doing masses large amounts of work for Debian who might be heavily involved in other kinds of work Debian's lawyer can't vote we're not allowing them to have any say in the direction Debian heads in and I think this is terribly one sided and I think it's it's really doing these people in Debian and injustice I think it's a problem we should fix I think it's that's because the YNM process has at the moment it has technical permissions for doing uploads intermixed with the more social aspect of voting these things are tightly bound together so perhaps if we can separate out your ability to upload versus your ability to vote that perhaps address that problem okay well I'm afraid you're out of time but once again I invite everyone who's still have questions to ask to continue discussing the topic but just outside I also have an announcement I think just a small announcement for those who volunteered to help doing the formal the diners this evening we will meet at 5 p.m. at the Cantina who volunteered please be there so thanks