 I might want to get you to all know me, and I'm doing this talk about unit tennis stuff. Well, I'm in front of this get-to-moment and fairly active as application manager, so I have a little bit of experience in this area. And, well, I didn't want to hold this talk, so the first slide is about not holding it. Well, that was a hard one. I could slide about not holding talks, a short introduction to the human process, what people change, and this slide I just did a few hours ago because some things were missing and I wanted to just put some in and discuss a little bit. Okay, not holding talks. Very important. It's not a good idea to know people who have scandals, so just run away. I gave up after like five minutes, and that's why I'm standing here. And, as always, don't look like you know something. Now, the real talk. We need a new container process. There was a presentation at that conf which was quite good and described why we need this complex process and complex checks, and if anyone doesn't know about it, he should just fetch the video and everything is okay. Just a few main points. We need new people who want to help deep end because all people draw out and the distribution is growing all the time. On the other hand, it's not a good place. We can't give out accounts just because we want because it's a quick thing. Security problems on our machines, which isn't good. And we have quality assurance problems because not everybody who wants to help really knows what he's doing. It's not a problem, they can learn, but we can't give them up on permissions instantly. The last point is a bit complicated. I personally think it's important to keep the number of developers relatively low. So we have at least, well, we should know everybody who is working on this project. Not personally, but we should have an idea who this person is, who he's doing and probably should have already talked with the PRC only. It's my personal idea of the project, but that's probably not what most people think. Security process, it's fairly easy. We have interested persons, they need already existing developers, they advocate them and after like four months at the moment, they get an application manager. That's not planned actually. It should be possible to get an application manager very fast. Well, I shouldn't do that all the time. We aim to ensure that people have the same philosophical background as we have. So there's a part of the process which just checks knowledge about free software and whatever it's related to that. And the other part is checking that they are actually able to have the project. That's not so important in one aspect because it's just needed to give a reasoning to give someone a count, but why should you give a count for people who don't have it? After the application manager has finished the checks, the report is created. Frontest checks it, which is not very useful at the moment. The account manager checks it a few months later and creates an account after that. Well, I can't finish it at the moment because it's not able to create accounts. The actual checks are not very good in my opinion. We have a lot of questions. Most of them are used to do, like, what would you do if, which is not very interesting, doesn't help very much and just shows that people are able to read the documentation. No, it shows that they are not, but... Yeah. There are obviously enough people who are not able to read the documentation. So, it has its advantages. There are a few tasks added in the last 18 months or so. The documentation thing is fairly old. I added the fix in RCBAC and do some work and prepare an improvement and stuff like that to see that people are actually able to perform the duties as developer. The last thing is something most applicants don't know about application managers are supposed to look at other work, not only at the packages that are submitted to the application manager, but also to see what they are doing in the BTS and how they are interacting with other developers, past users and back submitters and stuff like that. It's not included in the wrapper at the moment, which is not very good, I think, but I'm planning to change it in the next time. There will be quite a complicated change in the next month, nobody knows about it, and even GANF is looking a bit irritated at the moment, but I'm far less aware of what I want. Yeah, we can go to the next slide. Yeah, if you want. Yeah, we have the new GANF... Yeah, we have... We have... Yeah, we have dark instance, deep-end archive script instance on one of GANF's machines, but it's not mandatory to use it and only a few application managers actually use it, and not sure how many, and most of them aren't active anyway, so I just see the reports after they were submitted and only eight or nine people have submitted reports in the last six months, which is not very good. Mike? Yeah? Mike, one of you is seeing what's built on that from the archive, there's about one or two packages a week, which is... Yeah, but... It corresponds to the fact that half of the applicants in the process at the moment are processed by three application managers, which are Joach, me, and Craig Small, who's doing less work than earlier, but still does quite a lot. Not very good, but it does a lot of work. So, the advantages of the Q-introses. We have problems that many people are interested in being associated with deep-end because it's cool and everybody should have cool things alive and cool email addresses and stuff like that, and the very long process filters these people. They just drop out after like eight weeks or so and get rejected after some time. The questions at the moment lead to reading documentation, reading documentation, reading documentation. At the same time, people are weird, but take some time and they understand what we want to hear from them and we hope that they actually apply the procedure themselves. Okay. Yeah, we have also a long time to educate people in the skills part before they get after commissions, which means we can ask them to do sponsoring tasks, like checking other people's packages, and the moves are very important because daily quality assurance needs the moves a lot and I want that new and maintainers invest time in helping to assure the quality of the quality solution. Okay, next slide. What are the problems of the healing process? It sucks up a lot of time and it's lost. We have a lot of answers which get in the red format and are lost after that and we will not see them again. This is obviously not very good because a lot of times they're still writing them and checking them and discussing about them and it's not very good. It's people who are very experienced and are application managers at home, so we need that time and people who are very motivated and want a giant project and we also need those people. So it's not really good to waste their time. Consequence is change checks to be based on actual tasks. That means doing stuff that helps devian instantly, not after playing out the account but in families. So what can we do to use such task-based check? I have started this with two applicants. One of them is not very active. I hope that will change and the other one is Russ Orberry. Some of you should know him. He's quite active on devian release at the moment with one of the tasks I gave him. He's up to maintain a new server and Kerberos and stuff like that. He's very active in open source. Any way an applicant who would join instantly would be out. Well, I can't use him. So what can applicants do? They can help maintain us to clean up the bug tracking system. Most packages, larger packages, have a lot of unchecked bugs. All bugs should be classified as reflected in the changes in the BTS recently. The new overview which shows bugs are not in categories like patch or patch provided won't fix a confirmed unreproducible and unclassified. And that's where new maintainers can help without getting further permissions. They can look at bug reports, check if they fly, see if they can reproduce them and perhaps find a solution to patch whatever. Next point, WMPP bugs. We have a lot of them, mostly useless. We have request for packages that are two years old or more for packages that are long dead upstream. They're not dead a lot anymore and actually not needed anymore. So it could be an idea to ask new maintainers to go check 15 of the old bugs and close and attack them while retighting them. And well, I'm keeping this fairly short because I have a lot of slides about it. They can do sponsored QA uploads and an boost. We also need that all the time because it gives us a fairly buggy. What we're doing at the moment is transition support and management. He's asking maintainers to coordinate and is filing bugs to document what the situation is. And this is actually something that release team is doing most of the time but they always need help. So we could use active new maintainers for that too. So what can they do to, yeah, I don't know if it is at one resources site, but just skip it. So the purpose of this task is more that they can show to use the control bug that they can communicate with maintainers, with bugs submitters, with other developers and stuff like that. Cleaning up WMPP shows the same skills and knowledge about QA versus because it's important to understand that you can't just close intent to adopt or so because they actually need maintainers and sounds fairly dumb that I'm saying it, but I have seen people who have done that. So that's not really good. Okay, short social skills, especially that because there are many intent packages for people who have no time or not enough they don't know enough about DVM to provide proper packages, don't find sponsors, and you need people to communicate this problem and help them either to learn enough to provide the packages or draw to the front page of the next slide. Yeah, we need people who go for packages and find packages that need help, which means often packages which have a lot of RC bugs, a lot of important older bugs, and find a way to solve that problem. That's either uploading a new version as an app or QA app out or we move it there, or asking for new maintainer. There are pretty few people that refuse or are against the idea of non-maintainers. I know, I'm not one. Who are any of you? I'm a lot of one. Well, we have talked about it anyway tomorrow about QA app and moves by non-maintainers and external contributions, but I believe we can use every help we can get and it's not always enough to just provide packages in the BTS but sometimes you just need someone who's caring about a package and preparing a new upload, because sometimes no developer is interested in a package but some non-maintainers are. I think the main, the important part is that the sponsor is aware that if something goes wrong with the new, he's also responsible for fixing it, because he has uploaded it. Of course, if the uploader says, no, I only sponsor that, that's fine. I think the important part is that the sponsor is aware that he's also responsible for the new. I have some questions that some people in the project have written about that he has sponsored before. It's not, I just check a package, upload it and that's it. They are responsible for this upload. Every bike they introduce with this upload is their responsibility. They can forward it to the applicant or a new maintainer or an interested person who is doing the packaging, but if that person isn't answering, they have to fix it. It's their work. And some people who are going over independent mentors who are just uploading stuff without actually checking it or caring about the package enough to be able to check it. Okay. Kim, you guys? No, I post one. Kindly post five. I have four minutes of action. I think it's more than this. Okay. It's like nothing is impossible. Yeah, I've heard about the offers that they just like re-signed the package and showed it to people. Yeah, some people just take it well. It was because of the few problems of finding packages that contain exploits or whatever. So, like recently, you have said I've automated an upload queue for this one post. No. I've asked him about it. He said he's doing only uploads to his own post and checking the bindings there. So it's actually just remote people. Nothing more. What do you mean? I have to look into my regular archive for that moment. I keep my memory with the iPad. Okay. Yeah, I think we're done with this slide. Just part of tasks is mainly used to demonstrate that people have the needed skills to join the game. And while some parts for NMU's interactions with other developers are needed and knowledge about MIA and procedures needed and stuff like that. Um, transition management. It's probably some of complex tasks and I wouldn't ask any human trainer to do it, but some who are able to do it and should do it because... Yeah. Um... Please call me Ms. Simon. It was 15 minutes. Okay. But I'm done in a few minutes. No problem. Um, transition management is quite complex because it requires to have deep insight into tech problems. You have to understand, at the moment, for example, if libraries are exporting C++ binary interface or just a C binary interface, if a release manager doesn't get it right every time. Not you. Okay. You're not a release manager. I don't care. Um, it needs a fairly good knowledge of the internal procedures we have about contacting maintainers and caring about it, actually, and communications with a release team. People who do this and then maintain application are probably a good example for people who will join the release team in a few months. I'm probably very sure that we will be able to do it in the next year. Okay. Yeah. Disadvantage. What's this idea? We can't use it for documentation. You maintain us because all tasks are listed, are very concentrated on them. Now, well, there are other possibilities like translation and coordination of translations that are also known as color puzzles. Um, most application managers need to learn more about product assurance. It's the sad fact that most more application managers are not very informed about human internal processes. I see a lot of really bad application reports and some application managers just don't know what's, what has changed since they've learned about TVN. That's a big problem anyway with the normal system of task-based checks because, well, even the questions show the problems that they can't help to educate new maintainers. Um, we need something, we need to do something about it, but we have no alternatives as application managers and so we just have to do with them wait until we have enough resources to replace them or ask them to, um, well, read about demonetized policies and, um, come back later. It's a problem. Uh, it needs a lot more time for application managers. Um, the future, uh, questions are very easy. You go to a list of questions, see the answers, okay, okay, okay, fix me, fix me, fix me. It's very easy. You can, like, do a complete application in four hours or so and, uh, are done with it. Um, with such task-based check system, we need to invest a lot of time. We need to find tasks, we need to, um, check what the applicant is doing and help them. We can't, uh, believe that they just know how to work with it. It's, uh, just an educational program. Um, yeah, it does. And the last part is application, uh, no, uh, reports are becoming less comparable because we have individual tasks and can't say he couldn't answer this question and this one, this one is performing a lot worse than another applicant. It creates a higher load on application managers and the front desk and the account manager. Okay, um, yeah, that's why I don't have that much time. Um, I see an other disadvantage of your, the procedure you're expecting. Uh, I have um, I haven't asked you, sorry. I see, another disadvantage just, just tell it. Uh, disadvantage is when you find a sponsor package from the upstream and when the upstream want to be involved in the beyond. Mm-hmm. And that's not necessarily want to know anything about QA, is it focused, is it focusing on the aspect? Well, it doesn't need an account then. It could just use sponsor after us. Uh, I'm not forgiving account starts to everyone. It's definitely a problem we have that there are too many developers at the moment. People who would just need like five thoughts a year and everything would be okay. And, uh, there are plans to remove, uh, the developers as far as we know. That's the application of the account manager's so he should come up with that. Okay, um, we could discuss this later. I think I would want to go through all my slides and then come back. Okay, um, advantages of, uh, check based, um, and end chat. Because it's a lot more interesting, you don't have to go through a list of questions and, uh, uh, then just quote from the policy or standard of reference. Um, um, it attracts other kinds of applicants. Um, at the moment we have, okay, at the moment we have, um, a lot of applicants who are just, um, interested in, um, um, yeah, uh, yeah, getting an account and you don't have to need a technical skills but know how to answer questions. And, on the other hand, we have people who are interested in having Givian but are not able to concentrate on, I don't know, thought questions for DMP and, uh, 2005 for T&S at the moment. So, um, we should change that a bit to attract another kind of person. Um, real tasks help to educate people. We don't need, um, a whole educational program but it helps to just give them some advice on how to address the tasks and how to help inactive maintainers or stuff like that. It's better to do it with real tasks and what if, what if, uh, something will help you, what would you do just better. Um, and the best bit is everything that's needed. If you do a Q&A approach, it helps people. It's no problem. That's just a wonderful thing about it. Okay, um, that's almost my last slide. Um, consequences for the Q&A team. Um, we need, we, as a Q&A team, um, need to accept help from outside us. This means we need, uh, to document some tasks better. We need, um, to allow people to just go in the tab and, uh, change a lot of things to just make them accessible for other people. Um, that means for example, we need to give read access to some tools, like, uh, medicine or my own history or stuff like that to allow maintainers. It's a moment that I've kept on, uh, project machines and, uh, only accessible to shared access and not maintainers don't have that. So we should I don't know, um, for, um, creating, uh, web interface for all these tools, it's, uh, fairly easily just to the CGI with an input field and, um, give all the options and stuff like that. Um, I'm a colleague with a medicine CGI at the moment. You have that? Yeah, but it's not, uh, it's not good. Yeah, but it's not, uh, it's not good. And I developed this week of web frontend for medicine. Uh, web frontend for medicine. I think when you develop a new frontend, you should ask the question if that information is, uh, is supposed to be open to the whole world or just to people in the new development queue. If you want to, uh, if you want to have a new development queue, if you want just available for new developers, you maybe think about creating, uh, an alias project or something like that and adding new maintenance to that project. No, but I actually want to, if we read access to almost all tools we have. Okay, that's an R-tool. It's a bit difficult because of personal data. It's not personal data. I don't understand why it's personal data if you give read access to, uh, I don't know, 900 developers. Yeah, at the moment 900 people can just go in there and limit it to 500 people and have a few minutes to have it done. Yes, but I don't see a difference. I see a difference. Because we are all part of the project, so we have access to the approach data. Has anyone actually looked at the stuff in MIA? Yes. And, uh, six people or so. Um, it's mostly, uh, not very personal. Mostly, but yeah. There's a problem of doing it, um, without, um, asking for permissions. We shouldn't over-archize, but we should try to do, uh, if we've right made something huge that's asking if we can publish it. It helps. But the next thing Yeah, I'm not sure information is there. Mark, I think there's a lot of tools that we really could try to open. And I would say medicine, for example, is something we definitely could open to the world. Because, uh, the information is public, it's just medicine is something that's the nicest tool to access to. Uh, I think we really need to be very careful about, I think something like MIA history is more problematic. And I think what's important is we should start with the easy ones. And I don't have any issues to say, oh, I'm your application manager. If you need some output from this tool, we'll tell you and I'll just send it back to you. Well, for example, at the moment we have like four months of time before you get an application manager, even after you've tried. We need to come with us. But I think that something is in there at large. The back is not so... Yeah, sure. Okay, I'll just close it and come to the end. Yeah, okay. Here's an example here. Yesterday I saw at the end a few lines about the maintainer because he was wondering what he was doing inside the MIA. And I gave him the answer because he asked him. Yeah. So, we can do it on IOS. But if you give the information out anyway, why don't we create web tools? Not because it's difficult, but we should... We might proceed and... Yeah. So, the last thing is actually the QA team should provide a list of tasks that can be done in the application process. Things that can be checked like we know the package needs help and we have a list of packages that need help. And we have transitions that are pending. We have people who need to be asked if they're really MIA or just not active at the moment, but will come back in too much or so. And we should make this more organized. It's a great, complicated moment to get information. But all the QA pages you have to look there and there and there. It shouldn't change. So, let's not do this. I'm done. Okay. Well, that's one of the main problems I have at the moment. I want to away from questions but I have no idea how to do this for translation or documentation people. I need to know them. They have just other tasks. Okay. But I have 10 days for the documentation tasks. I think it's easier in a way because people applying for documentation and new mentorship will almost always be active already and they will always already have a track record in that area. So you can just take what they have already done as the task really which is what happened in my case. Yes. We have a problem. Once the key is inside the key ring you can upload a package even if you have no knowledge. This is no problem. It's a problem. I don't know anything about package upload. But the project trust that he won't be uploading things that he doesn't know about. That's why I think the current TNS and PMP part is very important for people going that route because at least they will have the policy and procedures in their head and they will know where to go with questions if they do decide. They want to start with you have to trust people in the project to be sensible about using the right they have. Although on the other hand I have said before that I wouldn't mind personally if there would be a split in what the right speed is. If we move to a more task-based situation where we are asking people to learn about uploading if they want to then we get all the people that want to do documentation by just checking the documentation translations that they have done. What do we do with those two types of people when they get to the end part? Do we separate a new key ring for people just doing documentation uploads or we don't allow uploads at all and we just put those people able to access the machine to get information about Madison or to get information or what? The basic question is first what is the development part? The question is is the development part of our community and then they have some tasks that can do for example upload packages or the development part is a person who can upload packages. So when I personally would come and say a developer is somebody who is part of our community who has voting rights who can access all machines. And of course as part of the community being a developer a good citizen of our community if you say that some of them have additional privilege that I would say or additional tasks. Some of them for example have the right to move packages other have the right to upload packages so some of them have access to boxes other people have total access for example to Murphy I don't have access to Murphy but the other thing you should say is that there will be a hearing which is a people with trust some of them of course have the right to upload packages but if somebody says he is doing the communication he won't be able to upload a package he goes to some additional let's say package tasks after it can upload. What I have said just now about not having any skills is nonsense of course but in the context of having installed I know what I'm doing I would never start a new package especially not a library but I mean that for example if a person doesn't go to the philosophy and procedures and then it becomes a DDM then the documentation maintainer so is it a person of the project that has voting rights that has access it's a co-op part of the project but even if it needs to go to PNP there's no way around it there's only a way around it yeah of course but then he becomes a DDM or whatever we call it and why is he a DDM developer with voting rights where it's just a documentation maintainer that has access to machines that's another question that has to be answered too as an applicant in Nigeria has a problem with a French translator he did this translation in the past he was thinking that he had to write to a DDM address email address he goes to join he feels he feels a philosophy and a procedure at least then I took the application and I said no he was an completely inactive for more than one year and the only rational reason to project him was that no I can't I said to your team because you have the possibility to upload that's a wrong reason that is a wrong reason but he had worked a lot in the past if he was inactive for a year that's a good reason to reject him but rejecting him because yes but he was pretending that you know he was threatening me in fact sorry that's true we have a huge flatware to use in the program oh may I it's not a lie it's a privilege five minutes for the discussion I don't think we should talk too much about documentation people uploading pregnancy lab because the other way round documentation developed by years so it's not worth discussing it at the moment and I've already asked if he would do application management for the next post but he was interested in doing it he would say he would think about it but he said launched but we should complete things and I don't know anything about it I think we should turn it back to the rest of the seminar state I think the real reason why I got in fairly easily is because I showed a broader interest than just documentation I think that was a life part of the decision you really want to have people in the project who are interested in deviant and working on deviant and getting deviant further you don't want to keep them out because they don't know see or whatever most people record it no I know that but they have probably better background than I do I think one general goal of the NF process is to check whether people are generally interested and if they are able to show that they're interested in packaging, documentation or whatever you can trust them that they do reasonable things and we don't have to discuss too much about whether they will refuse things we should enable people to do stuff I think one of the problems when you sort of use the labor of new maintainers to propel the deviant forward is that you sort of you run the danger of exhausting them yeah but in some moment we ask them to answer stupid questions I understand I'm using them in another way so I guess you should use them in a way which helps us some of the ground is probably appropriate but you should always bear in mind that when you ask people to do a lot of things and then you reward them with an official deviant membership and then they might become inactive we have the same problem at the moment I believe that you have tracked most of your applicants how many are missing nowadays 20% 25% I think that is a real problem yeah but the real thing is that the task that he described exhausts you you are not right for them if you are exhausted by doing a bit of work I don't want people to work like 10 hours a week for 6 weeks I want them to do a few things to show that they are able to do it so Elamaten looks like I should say the two final sentences but you say something that I really want to keep and you say I should make a list of possible tasks that could give applicants I think that is a very very big deal because there is very often that there is a lot of small things that should be done but for whatever reason I don't have time or whatever to do it and you should just keep those things so that we can start a climb yeah and now this is a problem when I had such a task for us he needed something to do but I didn't know what I should ask him to do so I went around and asked Abba and Steve and release management people were saying I haven't asked you I would make this my free documentation for you this is not for us but it's good they like to make fun but we need to concentrate on the list of tasks discussion later at BBQ in about four minutes we proceed with South Park George how do you do it? how do you do it? how do you do it? how do you do it? how do you do it?