 Hello, is it started? Ah, OK. Hi. Hi, Enrico. It looks like one of those evening programs where people discuss politics standing on four chairs on a stage. I don't think you want to get me started on politics. Yeah. But an end process, a new member. Hi, I'm Enrico, and I'm one of the deputy health managers. Jonathan is another one. And the third one is Ganef, your good Jasper, who is in here. And we are responsible for accounts in Debian. So if the wrong kind of person becomes a Debian developer, it's our fault. We think about what to do about it for a very long time. Yes. And we are very sorry. And if the wrong kind of person being a Debian developer, it's also our fault and their fault. And then we are not alone. There's Front Desk, as a group of people that help doing that job. And Jonathan McDowell is part of Front Desk, as well as to be as frost. There's more who are not at Debian. And managing the day-to-day, looking after the website and the people coming in and reading advocacy messages to see if people said, this person is good, or if people said, test, test, test, can you read me? Or something. And then there's another group of application managers who among you are application managers. Thanks for the work you do. Application managers are those that have a chat with people who want to become Debian members to figure out whether they got a good feeling about it or whether there seems to be something wrong about the person. Like maybe it's too early and they don't have a clear idea of how Debian works yet. And maybe it's best to try again after a while. And then there's advocates who among you have advocated people. Advocates are Debian developers who recommend someone to become a Debian developer. And then there's applicants who among you, applicants are those who are becoming Debian developers. Who among you is in the process of becoming Debian developer? Yay, welcome. How many of you should be applicants but have been resisting your advocates please to get into the process? Right, so there's a whole ecosystem. So I don't know if it's the right word of getting into Debian. It's kind of tricky. It's how do you make yourself an idea about a person? You can if you are the advocate because you worked with these people. But when I am responsible for who becomes Debian developer, I wish I could instantly telepathically assess whether a person is a good match for Debian but I don't have that power. So there's a way of getting to know each other. But then I can't get to know everyone who enters Debian or very few people would enter Debian because I'm also not very, I'm kind of introverted. So I'm busy. So that's where application managers come in. They have that conversation for us and for us Debian account managers. And we can read through and all the social things somebody has done it. And I can just read and say, OK, that looks good. Can I just jump in? Enrico used the word conversation there. And I think that's very important when I try and explain to people about the things I do for Debian. They sort of go, you interview people and it's not an interview. The intention is that everyone who applies for the new maintainer process should get through it. It's a conversation to sort of just get a feel for the applicant and make sure they're all on the right page rather than a test. And don't ever be put off because you think you would fail. It should be a conversation. I learn something every time I am someone and I hopefully teach my AMs or my new maintainers something as well. Yeah, it's the kind of, if you want to think about it as an interview, it's an interview with unlimited time at your disposal and unlimited internet at your disposal. So you can't quite be a job interview. I mean, it really is a conversation. I also think it's important that we farm that conversation out to lots of application managers who have a very different view on things rather than just the same three people looking at every application because we would probably start to take shortcuts quite quickly in guessing what people are like if we had to do every single thing. So having an application manager's view on an applicant is really important for us to make sure we're in the right place. And there's peer review. So an advocate says this person should be a Debian developer. Okay, and I kind of trust them, but maybe there's some bias and there's an application manager can kind of peer review what the advocate says and then try to get the second opinion. And yeah, so that's more or less how it works explained from a very confused point of thing. There is a website that coordinates all of this which is nm.debian.org, new member, Debian.org, which where people can request a new status, be assigned an application manager, submit signed statements of intent where they sign in blood and crypto that really they want to become Debian members because it's consensual. And it kind of tracks the progress and see where people get stuck and so on. So if you're curious about what's going on in the new member process, you go to nm.debian.org and click all the buttons in the site and see what comes out. Also the missing in action team is part of more or less the same umbrella and to be as works on it, don't know if you want to introduce it. Yeah, so at least partly we are utilizing nm.debian.org when basically when we found out in the MAA team that some developer is not active anymore. We, let's say that this is kind of the final phase then when we issue the so-called WAT ping, so we are the upings where we ask then I think private, if someone knows about the whereabout of a person and this is kind of then if that fails or if that times out then that leads them to the removal of that person from the project which is a third thing, but well it happens. On the other side, if someone wants to voluntarily retire from the project because yeah, life changed or something like that and we implemented a nice feature on that one on nm.debian.org which we call the one click emeritus. So it's much easier now for DDs who wants no longer to be DD to officially retire we are by logging in to the interface and requesting the status emeritus. So I think that helps a lot because in the past we had people who lost simply lost their keys or PGP keys or were not sure about the procedures and therefore did not resign properly. Okay, so I guess that's I can end of introduction. So this is a bit free discussion. I would take questions and answer. I would maybe, and if it's also a good moment of communicating things that I would always I wanted to say to all application managers but I never got around to fix the bit of the website that generates the alias that writes to all of them. So nm is perceived as a bit lengthy and bureaucratic. Historically it took way too much. People spent a year or more getting an account but that was many years ago and now it's much swifter. Now people who spend years, it's because either they become unresponsive and maybe each mail that takes them months to answer or because their application manager becomes unresponsive and they don't send an email to front desk saying, hey, somebody is forgetting about me over here, help. So public service announcement, if you are an application manager and your applicant becomes unresponsive, give the applicant up. Public service announcement, if you are an applicant and your application manager becomes unresponsive, contact front desk, things should not get stuck. We have way to deal with that. We have in the past had sort of a problem with the limited number of AMs but the call went out recently and we've had thankfully a huge number of AMs come forward. So thankfully that's not causing us a bottleneck at the moment. And then another thing that is not optimal at the moment and I cannot fix it in software is that application managers tend to ask too many questions. There's a thing that I think as inflation of bureaucracy. So when just to be on the safe side, I will ask one more question is a valid strategy. The number of questions that gets asked inflates over time until I go to a talk in a depth conference and say, you really don't need to ask that many questions and then there's a drop and then it starts going up slowly again. But so the general idea is when you go like, yeah, sure, you know what you're doing, approve. Right away. You don't need to, yeah, sure, I know what you're doing. I'll ask you one more question to be sure. I'll ask one more question because maybe dam is not convinced. No, when you think, yeah, I would work with that person. Yeah, I would install a package uploaded with that person by that person, then approve. So is the records of dialogues between AMs and NMs available to all other application managers because when Jonathan was my aim, he asked really good questions focused on, well, when it was clear that I understood something well, he just skipped whole sections, which was really great and spent things up greatly. And I think that's a really good example of what a good aim should be. So if other aims could see that record of that dialogue as well, then I think that could serve as a real good example. I don't recall what the permissions say about being able to see the, but your point that skipping out a chunk where the applicant clearly knows what they're doing is absolutely the right strategy. The templates are meant to be a menu of questions you can pick and choose from as appropriate. And I like to see an application manager who's asked a question from the template and then maybe asks one little detail out of it just to prove that you didn't copy and paste from Wikipedia, just to explore it. But a number of application mailboxes come back to us at the end where clearly that the AM has just sent the question templates and said, oh yes, you've answered all of those, let's go. That can be a frustrating process for the applicant. Well, on the other side, if some applicant knows how to research the information and just points me to the section where this information is written, this is fine, this is enough. So it needs not to be a 20-cent answer or just to go, okay, that is written up, deaf, deaf, paragraph, something like that and that's fine usually. For AMs, there's a really useful tool, MindChangeLogs, that's actually linked from the applicants page on end.debi.org and it will go through and find the applicant's name in all the change logs within Debian. So like, for example, there's a question about, hey, have you ever fixed a bug and it's very simple to go, yeah, they've uploaded a change log with a closes line and I do not need to ask that question. So things like that, you can strip it out. And all it takes is sort of a couple of minutes, actually go and work your way through that. And equally, sometimes you go and you look at the MindChange logs and it's like pages and pages of information. You go, this person probably knows what they're doing. I'll ask a couple of questions, maybe just to make sure that, but I'll cut basically everything out. Yeah, the most, the things that, it's really unlikely that don't need to be asked is that the first question is like, do you know how Debian works? Do you know what Debian is about? Just to make sure we're all on the same page. And then maybe you're asking someone who's been editing policy for five years for some reason they are not Debian developers yet, or maybe you can even skip those, I don't know. But yeah, like I wouldn't ask when somebody who's been the major developer of apt finally applied to become a Debian developer, I wouldn't have asked any technical question. For example, but you don't need to be at that level. When somebody who's been uploading packages for three years, doing, and in the change log, you don't only have like fixed standard, updated standard version or changes needed, but actually stuff got done. Why ask technical questions yet? I see technical questions asked to people who've been uploading packages for 10 years. And like, okay, but no, I mean, yeah. Maybe if somebody's been uploading packages for 10 years, the question is like, why didn't you apply earlier? There's probably a nice story in there, I would like to know. Yeah, I think we should also encourage people to come forward as of the applications because that's not so certain that you've come especially at Debian for some people who is a name in the project and then you find out he's not developer or she's not developer. So that's surprisingly often happening. Yeah, with the person that was the author of apt, it was asked a bit too often to the point of almost being harassing. So like, take care. And when I'm reviewing applications, I think you're looking at the same kind of thing. We're looking for, is this somebody who knows their own limitations and then knows to go and get help with them and not just upload to the archive and hope. So that is a useful indicator that this is gonna be a responsible person as opposed to this is gonna be someone who's going to cause lots of grief by uploading things without thinking about them carefully. My question to the panel is, I have a general idea of what my answer is but I'm looking for alternate opinions or answers. So I come from India and we yet to hit a two double digit count for Debian developers in India and when I see some countries like Germany or which has hundreds of developers, what things could we do or should be done to get more DDs from India and more Debian contributors from India? Not just India from other countries where the number of DDs have been less. It's not that the number of activity is less. The activity has been growing around but not many people are applying. I think it's discussed, what other things we could do? I wonder, I mean, I would like, I wonder if there's something going on that like for example, if somebody's working 10 hours a day for their day job, they probably don't have enough time to be Debian developers. So I don't know the situation in India but there's this idea that people in India work way more than people in Germany in terms of hours per week. Or, I don't know if that is relevant. I don't know if that is relevant. I don't know if there are issues that are like differences in the societies or if it's purely a social question like Debian is not seen as interesting because there's other interesting things in India or language translation. I wouldn't know how to answer that but you had ideas. Yeah, so I will put first a big qualifier. Take this as an entirely unqualified opinion and feel free to dismiss it if you think it's dumb. But I think it would be extremely valuable to have more deb-confs, not just, you know, and mini-deb-confs and events where we actually get, you know, people who are already Debian developers talking with people who are not yet Debian developers or with people who are not yet Debian contributors because you said the activity is happening so we need to, you know, actually tell people, yes, commit us of, you know, well, I will use us anyway even though I'm not a Debian developer. Commit us and, you know, realize that we are just regular people and that we just want to work together and that there is no, I don't know, that there is, you don't need to be some packaging superhero or something to actually, you know, become a DD. I think that's a very valid point. I think that the events like DebConf help bring people together who may not be Debian developers but are part of the Debian community and that's a good way of getting doing it. I suspect that in, and I'm guessing, but there are areas where populations are spread out. You need to get a critical mass for things like just even the interest-sakin' Debian to sort of like go, right, we'll hack on Debian and I've got some of the talk to you about Debian. There's definitely a key ring bootstrapping problem. We've had problems with people who are, you know, in remote areas. It's hundreds of miles for them to get to anyone else who might be able to sign their key. I don't have a good answer to that one. I think things like DebConf help or mini-conf or general technical conferences. I mean, it's great that DebConf moves around every world, moves around the world every year. And I hope that it being here in Asia will help with that. I know that India is sort of pitching for 2020 and if it doesn't get that, then maybe at some point down the line. So I do think there's a little bit about we should move around as a project and bring a critical mass of Debian developers' places and see what happens there. I'd be really interested to know whether that's happened in places that we previously been that didn't have a huge number of Debian developers and whether anyone here has been brought into Debian because DebConf ended up in their country. I have an, I guess, from experience and from what I observe with friends and other Brazilians applicants and they are now developers and those who never applied, even though they are still involved in the project for many, many years. And I think language barrier is a thing that even though people can, sometimes they can communicate to a level that they can contribute. Answering those questions, it's intimidating if you're not, if English is not the first language for many people. And I think, I was also thinking about that because I speak Portuguese and now as an AM, I'll be able to help that to improve the process, at least for Portuguese-speaking people and for sure it will be, then I would ask, it was a question to them and from Desk about how would that happen? Actually, it would probably put a bit of overhead in AMs that want to facilitate the process for non-native English speakers because then we would probably have to translate a big chunk of that to the dam report. So I have certainly assigned AMs to developers where I think that they probably have compatible non-English language ability. Even if the conversation still happens in English, I assume that there will be the ability to sort out misunderstandings much easier whenever two people share a language. Maybe we need to formalize that and have maybe an AM flag for these languages I am prepared to engage technically in and then we can have a flag for applicants. If that's a barrier, then I can't speak for dam about what they want to see but I think as a front desk member, I would happily assign people to the right language if that helped. Unfortunately, to contribute to that, you need at the moment to be able to have conversations in English. So in a way that something that I feel like I have to discriminate to, although I hate it, but I don't know how to fix it because still when there's elections in Debian, the calls are in English, the platforms are in English. So even though I could say that people doing Italian localization need to speak Italian way and barely understand English, that would be good. But when it's time to vote for a GR or vote for a DPL, that is important. Unless we start to destructure Debian in a way that there can be local Debian where English is not spoken. But I wouldn't know. No, I agree, it's important. But I also think there's not speaking or non-speaking English. There's a spectrum of, and the level, the spectrum. And it's a level, there are some people that really have contributions for many years, but just elaborating on those questions, more deep questions, it's hard for them. Yeah, I'm gonna have to disagree with Enrico for once. I think that if we can help, I agree that you need to speak English in order to be able to interact with the project. And I'm not sure that's easily changed, but I do think that if it's a barrier to people feeling that they can go through the process of becoming a full member, that they're interacting with the project and they're quite happily doing stuff and they're quite happily aware of what's going on, they understand everything that's going through, but they go, I really don't wanna sit down and have to explain all of these quite complicated at times points with someone who may not, or it's gonna take a lot of my time to do this and therefore it's just not worth it. It's just not worth me spending the extra effort whereas the likes of a GR, it's like, well, that is worth it because I can engage with that. So I think that if we can make it easier during the application process for people who still don't speak English as their first language, I think we should do some work towards that. Right, as an application manager and as them, if I saw an applicant replying, I am sorry, my English is not enough to have this kind of conversation, I would go like, yes, come, approved, because, and then engage in, and then the applicant and the application manager engage in some negotiation on how to be able to have that conversation, so maybe find another application manager or call from desk, how do we do this? Because that means that when that person becomes a Debian developer, if there's something that I think is important and they cannot access it because of language, they prove to me that they are able to look for help. And that to me is something that gives me trust on how well that person interacts with the project, way more than trying to wing it and say, yeah, I don't understand, but maybe it's that I'll type something and then it's actually not. And so the application manager goes back and say, maybe you didn't understand the question and then it drags on two people not understanding each other, but not admitting that there is a problem. Although I say it here, but how do I put it into documentation? I have no idea. So like a kind of mediation between the languages, I think English is important for a Debian project, but well, many of us are a non-native speaker and our English is not good. It just needs to be well enough to somehow understand on that one. And this is maybe always an appeal on the native English speaker here is that if I use a word or we use a word which is weird in English, keep that in mind that we probably meant that differently because we didn't know better. So coming back to education, I think it could help if we assign AMs which understands the native language because they could then maybe clarify more better the questions or the thoughts we want to avoid that I'm asking A and you understood B and you're not getting the question. Yeah, that's what you mentioned. We do, there is a human step in all the assignments at the moment at least. So it is not that there is some script running that goes, oh, you're an applicant and you're a free AM, we'll pair you up. So we do try and match people who are gonna suit each other a little bit, but a big part of the point of the process is that we don't know one of these people yet. So it doesn't always, it's not always perfect. And it's not usually along the lines of language, but along the lines of culture is sometimes quite helpful or the programming languages that someone is working in, there's no point assigning someone who only writes in C to somebody who is only doing Python packaging work because it's gonna be a jarring conversation all day long. We would try our best to get matches together. I don't have any objection to native language phrases being used if a phrase is particularly expressive in Portuguese, then I don't object to somebody using that in the application, but what we do need is some kind of explanation of why they have chosen those words to describe what they're describing. It's unfortunate that of Dan, I think we are, we've got English, Italian and German as natives, haven't we? And in key ring, Spanish and English. And so our own spread of what we can understand if you use phrases like that is kind of limited. We do need a little bit of help along the way. First of all, thanks for the concern that we have. We are thinking about understanding the language barriers. It is actually a concern if you consider it for the Asian level, a lot of Asian speakers find it hard to converse in English. It's not that hard with India. A lot of people do actually speak English and speak it very well. So that's not an issue particularly in India, but a lot of maybe not Asian countries have this issue and I have found hard to converse with them. So yeah, so any ways if the process could be made better for languages, it would be great. Thank you. And thank you. And when I assign an application manager to an applicant, there's only so much I want to guess because my understanding of other cultures is limited. So I don't want to go and say they're from that part of Asia. I'll put them together with a person that's from that completely other part of Asia because they're Asians. That's kind of almost racist. So I mean, there's a line until which this is constructive and past that line, it kind of becomes bad. So I would like if somebody feels like they struggle with something, I would like to see a request for help because I don't want to assume. Or if I have to assume, I will make bad calls and probably it gets a bit annoying. So there's 10 minutes left and two comments on RSC. Voters says interacting with Debian is a great way to improve your English skills and becoming a DD is a great way to interact with Debian more. So I think doesn't speak English perfectly, shouldn't be a barrier. And then Pub says there's a parallel discussion about English on planet and the next weekly news and he provides some links to that that I won't read out loud but you can get that in RSC. I think I second that because your English will get it better naturally and don't be afraid if you think you're not good at it because some of the time your English is better than you think. So that should not be a barrier for an applicant to apply for status. I wonder sometimes too whether written English and spoken English in any language really being quite different is sometimes more intimidating or makes people more nervous. So one of the things I'd quite like to do when there's an opportunity like this is to actually pair people up at DebConf or introduce people who I know already the application manager for someone and say sit down and have a chat, get a little bit of a hang of each other because in conversation that's much easier than in relay mail all the time. On the flip side, we need some documentation so that when Dan comes to read the conversation it doesn't just say, oh I sat down and had a chat and he seems like an okay kind of guy. Because your interaction with the project will largely be by email and so if you struggle with that side of things then you're gonna have trouble later on in the process anyway. So instead of wondering what the applicant can do differently if they are not close to anyone in Debian, I'm wondering about questions that what can Debian do to make those that hand-holding gesture, that hand-shaking gesture easier for someone who does not know people already or doesn't have a body of people from their own country here. You know, so that's the reason I'm thinking of a question like not formal mentorship necessarily like outreachy or summer of code but informal mentorship to what degree could an app manager continue this kind of a greeting and social integration that happens with new people to keep them interested, keep them involved and keep them more encouraged about their ability to get through an application process. I've certainly seen some reports of success with BSPs sort of people in areas who put together a BSP with maybe a couple of people who are already active in Debian who therefore can guide things and get people along and go, hey. Bug squashing parties. So it's a bug, sorry, bug squashing parties, yeah. And that does mean that it's technical contributions but it's hey, come along, maybe pick a bug that is annoying you and we'll try and work on and even if it's not solved then there's a bit of explanation about here's how you interact with the bug tracking system and then hopefully some continuation of involvement afterwards. So that's maybe something each and every one of us can do and certainly I'm from Northern Ireland and to my embarrassment I'm the only Debian developer in Northern Ireland and I've actually had some people in my log request that I do a BSP so I'm gonna go back and try and sort one of those out. I'm kind of, I don't think however that this kind of mentorship belongs in the new member process. The hand holding happens before when somebody starts contributing, when somebody contributes but when a person comes to the door of the new member process the idea is that they already have everything they need to be a Debian maintainer or a Debian developer according to what they are requesting. So I am interested as far as how can the NM process not be in the way of something but all the sort of come in, I'll teach you, I'll show you that happens before that happens, the advocate may have done it, the mentors Debian or may have done it, the local teams may have done it, the other teams but ideally the NM process, I mean ideally the NM process could just be somebody advocates saying that person's good and I go okay, did you, right? But that would only work if it's the advocate that has responsibility for membership of that person which could be an interesting change in Debian. That will save me a lot of time. But so there's that double checking that exists because somebody has to take responsibility for something. So they're advocates, they're local teams, would you like to add to that list? Advocates, local teams, would you like to add to that list? To the list of people who do outreach at the early stage. I mean advocates probably has a side effect, it's not, I mean when you advocate you're already convinced that a person is good for what they ask for. But whatever happened before that point probably the advocate was involved in some way because it's somebody who knows that person. So asking the advocate maybe how did that person get into Debian could be a way to collect a success story. So your question is more like, how to get someone addicted to Debian? It's more about how to keep people when they express a small amount of interest. What are the factors that encourage them to come back and keep trying? Because you can get easily discouraged and some people, some types of people will be more easily discouraged than others. So how to keep the door open. I think one good thing is that people are interested in meeting other people like local BSPs or other events or maybe other events on free software. But the other thing which also quite worked well for me is if you're for example interested in packaging that you use mentors to get a name or to get some visibility to get an order to then when you found someone who is frequently sponsoring, you ask your sponsor some questions or work with them closely because then you will always likely have already an advocate later. We have little time, I would try to stick to what is the member process. Yeah, I was going precisely on that direction. I am very happy that over the years the project has become more interested in attracting and keeping people and being more open. But there's a very long distance between starting to get interested and reaching NM. What we usually look for is well, is the person ready to take the commitment of becoming a project member? So yeah, I think there's a huge chance in between what you're saying and the panel. Actually, one of my first contributions as a front desk member was to start rejecting advocacies. Even Enrico's first steps also in that position was to tell me to stop advocating people so early. And that really helps the new member process because the application manager doesn't sign up to be a sponsor, doesn't sign up to be a mentor. And so there's a lot of mismatch when a person comes who they're not ready is really hard socially to tell them you are not ready. And there were advocacies that were clearly that person stated my house last night and looks like a nice person for Debian. And I was like, no, work with them first. There are other tools for getting somebody partly on board as well like Debian Maintainer, which we always intend is a stepping stone status towards being a full DD. So there is no assessment of who you are or what you're like only an advocacy from someone. And that's really a rubber stamping exercise. Ideally the whole NM process should be a rubber stamping exercise too. Somebody should be coming to us in position to join the project, not to be getting started on things. I have several times before now paired people up and they have come back within a week or so and said, yeah, they're ready to let them in because they've been in that position. They've been ready to just demonstrate that they know what they're talking about. They signed the paperwork and we put them in. That can happen. When an application grinds into the sand a bit then sometimes that's an indication that this is someone who's not quite ready to be here yet. So I still have a comment on the pairing people and like with like. I kind of agree with Enrico too and I'm also concerned about, sorry. I agree with Enrico and I think it's also dangerous to, let's say, I don't want to be the AM for all Brazilians now because then it just, it's a disservice for the Brazilian community too because I think it would prevent them to reach the Debian community as a whole which is much richer than my Brazilian perspective. So I think it's only for cases where we see a clear need and I think maybe we could ask, is language a very, I'm not sure where, but do you think it would be overhead in the process to ask because I understand Enrico, the person should be ready to ask for help but in the reality it's not always the case that people feel comfortable to say, well, I'm not that okay with English and I, so if there was somehow that we could say there is this possibility and if you think it would make yourself more comfortable, you have access to Portuguese speaking AM. I agree with everything you say and all I would add is that this matching up is nowhere near that scientific. It's very touchy-feely to try and sometimes we'd have any choice anyway because we've got one applicant and one AM. Yeah, it's very much a piece in the, who do you assign to who? If there's one applicant and one AM available then that's the way it goes and that's always the way it'll be. It's never held off, it's just if there happens to be a handful of both available then maybe you'll do some puristics to try and match them up. So I'll make a note not to assign you all the Brazilians. I don't know how to tell a person they can ask for help. Depending on the character of the other person they can feel insulted, they can feel entitled to get all the help that they ask. They can come from a culture where they'll say, yes, yes, yes, I'll ask for help just because I said they can but then they never will because it's a culture. Well, you can never ask for help. You can never say you need help. You can never say no. So I'm really stuck on that side. So kind of a different tangent. You made the point that you basically have enough application managers right now. Right now is the keyword. Does that mean that you are not accepting more or not interested in more for now? Application managers have a number of slots and so if you set your slots to three we will give you three applicants and when one of your slots is empty we'll put another one in there. The typical pattern is that we do a drive for application managers and we get this money and then the number of slots, as people get busy we encourage them to reduce their slots so they don't get an AM, they don't get an applicant and then leave them hanging. So the number of slots available sort of does this and then when people get free again they don't really put their slots back up so we get all the way down here and we have 150 application managers with zero slots. So we are always interested in either increasing your slots because you have more time or being a new AM. When you start as an AM you start out with one slot till you've completed it just to make sure that everything goes well. So we're not immediately gonna throw 10 people at you. Thank you.