 So the next talk is 50 Shades of MIA by Karam Ones. Thanks. Hi, we're going to present something about MIM, which is something we do at Debian to make Debian better. So we want to transmit to you. What MIA is, MIA means Mission in Action. You know, when we come to MIA, people usually come and make a lot of noise and want to do a lot of things and that's good. But sometimes life gets in the middle and people go and don't know anything about them. They live and they don't say a word. So we have to find them and try to ask them what to do with your life, what do you want to do with your Debian packages and so on. So is the mission of the MIA team. Why do we care about the staff? But because mainly all of this and in packages being rotten and being maintained. People's house to me is have some releases, bags get an answer, even RC bags, especially on release time on testing freeze. People even send fixes to the bags, but they don't get up yet, no new uploads are done. And of course this means the quality of the archive drops. As for things, I personally think it's also a kind of breaking the social context because it looks like we are not caring about the users of our packages. So it's kind of. So because there are people behind that packages and we care about what happens to the people and like people do disappear with a reason and to miss that people we already know. Why do you care? This is again where we care too, but I have to change the title. I'm on 10 package, not a good idea. There's no way to have packages rotten on the archive. It's much better also we think there are opinions to have the orphanage and the QA team to take care of them. This is no problem if you cannot maintain a package, just let it go. If you love it, let it go. Interesting packages will be adopted and the ones nobody wants will be missed or we don't be missed in fact. And this is the best work for the rest of us. Of course we don't have in a mountain and you don't like, it doesn't mean the packages are not on that business. Well this is a brief presentation of the team. Who are the MAI team? Well everybody is MAI team. We were reporters, everybody from the missing people and QA is everybody on the MAI. So everybody is MAI currently. Only René is practically doing work here on the first row. I myself am in vacation mode this year so I don't really know much things. So we need you. We need you to join. Well we are thinking about improving the process so if you want something you can join. If you want their equality you can join. If you like today well people, those people you might know or don't know, you can too, you are the one. Current tools are somewhat aged. It's a command line toolset. You can see some, well there is more commands than that and you can see some, the typical workflow is using me a query. And am I to do? To see what needs to be done and so on. It's just list what it's spending on the database. And the other tools also have to send the mails and to keep things more or less sane. It's somewhat tied to math but you can use other minors. More on current process. It uses a system of tags. Three levels. There's a little mix of what are, they are implemented all of our tags and there's somewhat difference between the status, level of approach. It's doing nice. It's sure he has been warned once, two is the last one we are sending. And also directional which helps to keep more or less the flow. It's not very nice but somewhat worse. You have to prepare manually the mails and remember to be busy, the address, prepare the address and so on. It's very prone to error and I think everybody in the team has forgot on some of the tags sometimes and you have to redo the things. So we want to change that a bit. We want to make it simpler and we want to make it better. Make a process more direct because right now there is a little confusion on what to do and someone else where depends on the answer and makes it very complicated. And we think it should be simpler. We have thought about two reminders just which is really more or less what you don't know but more explicit, having time on each reminder and if possible create a web app with implement a lot of features which are missing in the command line command. Web reporting, so we see people easily can tell somebody I think that's me on that package or whatever and automatically report the feedback which is other factor you have to do by hand now. Support for teams of people working in a package which is totally missing now. There is no, you have to ping individually everybody and so on and in fact when you do so the system gets a little confused because things there is kind of duplicates and it's a bit internal comments which is some of the several times to not to feed a next member of the team and these people has that problem which doesn't necessarily need to be public or send in the mail. And of course we're trying to keep backwards compatibility. This is not a strong feature because we understand to make it better it's probably we need to break something but at least it will be decided to the new system to keep updating the mail database and make it real for the command line tools at least. This is kind of the footer flow because it's very, even if it looks complicated it's not, it's more simple. You get to receive, this is the first part, it's okay you refuse somebody tells you somebody's mail. It's in the first reminder, third reminder, third reminder. And then finally is the what which is in the part of the mail process but it's not done by the mail thing or not directly by us. There's somebody else because you have to remove the account from the lab and so on. And checking is all the same as ever. You have to check time, you have time for them and you have to match your workload. You have interest, have you motivated to work in new packages and you have problems with people because sometimes there's internal affairs and things we make people go away and tell anything. I just need to remind what I wanted to mean by LOD. Ah, life outside Debian, problems in real life can be affecting your Debian experience. And of course our final is all from the packages if you have one or want to have less workload. Retire, if retiring is good you can retire and come back later when you have more time. So to summarize, the process helps Debian even if you don't think so. Less people is better, less people working less and we need help because we are getting started and need better tools. So, thanks for listening and join me I think. If you have some questions or whatever. Hello. Do you think we need to fix something in the Debian workflow itself so people get less MIA or do we need more non-mantana uploads, easier hydrax? Well. What are your ideas there? It can't help but it doesn't really help to get people less MIA because in them people can disappear. If you have a better QA process in the sense of using MIA and MNUs or you can improve packages but people who are first maintaining them it's still missing in action. So it's a kind of hiding a bit in the real start of the package. This package has non-mantana. You are, so it should be orphaned. Related to that last year there's been at Debian last year there's been a little workshop, a booth, whatever, about salvaging packages. That was the idea is when packages look and maintain and somebody starts an MU1, an MU2, an MU3 saying that it's actually acceptable at some point to upload like a 15 days delayed an MU whatever that changes the maintainer field. Yeah, I think it's a good idea because. And that kind of helps also. It's akin, a kind of express process and it's a good idea to implement. We have failed to make it reach like the developers reference or something like that but it would be nice to resume it and that also helps when a maintainer is still active but unresponsive on some packages because maybe they lost interest. Yeah, this is another problem with maintenance. We have forgot about some package but they are still active with others and don't want to ignore deliberately some package. And I still think that even if you managed to salvage the package itself, it's not a good idea to have accounts laying around without people answering so it's like. Completely. I just wanted to say I'm quite fine with the current jewels. The only thing I was missing when I was doing some mere work was the documentation. Yeah, that's another fault it should be covered with this. There is documentation but the main issue I remember is that it's scattered over several places and there's no place where you find all of it. So for example, the meaning and how to work with the tags is I think in the read me in the SVN while the procedure went to my little what is in the wiki. That's the kind of confusion I was talking about. There is something said but not all and it's like an arcana process you have to master somehow by learning my examples. So I'm glad to see a kind of workflow here and well I hope that there will be better documentation in the future. So maybe more people can help without needing to learn too much things from asking on IRC or so. Yeah, I think having a better tool is the way to go and because you can build something you can build in a right way. Having it documented with help or whatever. Hello, my question is rather asking a feedback from the audience not just a question to the missing inaction team. The process starts with sending an email to the missing inaction team saying that this developer went away a long time ago and we don't know anything about him or her. So my proposal to the Mia team a year back was sending a reminder automatically to every developer who hasn't been seen for a half year for example. Kind of reminder that hey, we remember you were there you did some work and thank you and you want to come back or not. And it could trigger the Mia process faster and he or she may not be as Mia as he or she would be after a year or so. I want to answer. Because that has been already discussed. Hi, the process doesn't start with the Mia team mailing the maintainer. The process starts with somebody mailing the maintainer directly and if this person doesn't get communication with the maintainer then mailing the Mia team. And the second thing is automatic ping is never going to work because we have plenty of people in Debian who are active in something as a maintainer packages. Plenty of them people are maybe maintaining two, three packages that don't change. So they have no reason for that in their packages. Do you understand it or not? You can have somebody who is an FTP master in Debian. This person she is maintaining three packages. Those packages don't change, don't need any update. So what's the point of sending an automatic email? Usually when you send this kind of automatic emails you need to handle the replace and you get plenty of angry replace. Which is a problem itself. In the missing in action teams infrastructure there is a tool for querying the activity of people. And it shows mailing activity as well. So if someone is active as an FTP master he would send out a lot of emails. So he wouldn't be seen as inactive. Yeah but there is other activities which doesn't leave trace on the current world. So you can be making teams or whatever without mailing list or mailing other lists which are not surveyed by the script. So you can be doing things without leaving all kind of traces. Okay that would mean. Maybe the FTP master was not the better example but it's an example of people which can do things without necessarily making packages. There's a lot of things more on Debian than packages. That would be two emails per year. That's a lot for some people. Who are not visible but it would mean months or. You mean to mention per package? No no no no by per people. Handling the replace. Please use the micro. Right. So just a question for me. Commit strict. Like if somebody commits something to get a subversion on subversion.inoc that's tracked for MIA or not. Oh well if you. Yeah. I think there is when you became maintainer you have to send a ping to a package. And people should be doing that I think if they have no other activity. Am I wrong or? And that might help. When we introduce Debian maintainer status somebody put something I don't know if he's seeing the official documentation or not about Debian maintainer having to do an annual ping opening a report. I have seen some people doing that but it's actually somebody looking at that. I have never ever ever seen a request for a key removal based on someone not sending an annual ping to the Debian maintainers. And as someone who gets those emails by being on the bug alias I do absolutely nothing with them and I don't think they serve any useful purpose. I think there's a potential for tying a bunch of information into nm.debian.org that ties with the Debian contributors which will tell you how recently someone's been active and potentially moving the maintainers thing as a button in there. But I don't think anyone's doing cleanup based on that ping or not and I don't think it serves any useful purpose at present. Just going back to his comments. I understand that no one is doing it but I also agree that if someone is not visible it's also a problem. Like there are even there are contributors that are not packages but we somehow can trace them like Wiki editors already show on contributors.debian.org or if someone receives this kind of message and he or she is active somehow and we don't know we just apologize and maybe we should be tracking this activity somehow. So we're mostly running out of time. Is there any urgent for the comments or questions? I guess with regards to the M the only thing that taken over the M can do is upload new packages. So there's not much point. I mean they're not having an inactive DM. So there could be the only difference between an active and an inactive DM is that new versions don't get packaged. But there could be an active DM that has an upstream that is not making any new releases and that it wouldn't be a problem. And it's not contributing to compute the quorum for elections for example where the count of developers is relevant. So I think that could just work by salvaging packages. Okay, so there's one for... Okay, now maybe it's best to continue the conversation afterwards outside. Yeah, yeah, yeah. Because we're running out of time. Thanks everybody. Thank you. The next talk...