 We're here to discuss a little bit about the Missing in Action team. So first, the first idea is to give some information regarding how we are working now and then we will open the microphone and the discussion because we want to do some slight change on the process and the workflow, but we want to hear about it, we want to hear what other people think. Sorry, I don't have a proper PDF now. So I will move quickly. So right now we work with different tools. We have some sort of scripts that are writing in Python. We have a database, everything is on Quants. So the scripts do the tracking. We use the scripts to save status about the maintainers and to query. There is some service called Carnivore echelon that actually pulls out all the information from the mailing list to know when was the last activity from the maintainer. So we also use that to check. We have one privacy channel. The password and everything, the information is on the wiki. So if you want to join or report over there, it's good. And of course the alias, some people know. So tracking is done manually. That means nobody is actually looking actively for Missing in Action persons. We normally register the person who has been reported to us or if we bump with the people who looks not active, we manually add it to the database. Then we use several tools. When I say several tools, including social networks, I have been contacting people on Twitter and Facebook to see their words. So that's up to every team member how they decide to do the tracking. So now we have several status. This is the current situation. So we have all these status which represent what people is doing. Okay, it's the normal. Then we move to VC and then we start to move to different status, like in acting or responsible, retiring, until we get to Mia. And then we are from the package. Then we just move to Needswap with the Debian account manager. I need to take the decision and remove the account, et cetera. You can. So we have a way to reset the status normally. There is a full reset which is okay. And there is one temporary reset that we use that it's called WillFix. So sometimes we ask people, how are you doing? And people say, okay, I'm busy and I will come back in several months or we'll fix and put, like, we'll fix in three months. Then we manually check again if the people have actually improved the situation, package has been updated or whatever. And then we decide to move to Okay. And we have different prod levels. First, we start with Nice, which is a very nice email. How are you doing? Everything is okay. Can we help? Then we start to move a little bit more rude and ask, okay, you need probably more commentators. And then we issue a last warning telling, okay, if you don't do anything, we will orphan your package. And then we decide to orphan the package. Okay, this is how we update the status. We normally do it by email. It's on specific information on the headers. So we can put comments there. So the comments are somehow privately, because we include information regarding what's happening with the people. We use several ways to see, to inform the other team members to see, okay, this guy has foreign views or he has not been uploading for one year or whatever. And that's it. So I will hand the microphone to Anna. I was working also on this, on the new ideas and Moniz, who is the other team member who is remotely participating. And I will move to the Titan path. So anyone is welcome to edit. Okay. So what we want to do is first, the first idea came to start doing some reporting using web interface to make it life easy and to have some way of inform the people about what we are doing because sometimes you send an email to the alias and probably you will never get an answer. But some action is taken in the background. I know we need to improve that. But probably if the people who report the people who are missing in action have a way to check how is everything going, it can relieve some frustration. And then we want to change the workflow also and remove the current plenty of status and pro and do a full merge of everything and change, for example, define specific times like start with a first warning and give 16 weeks to react then move to a second warning and move to a final warning and then offer the package. So we want to reduce all these status like responsible or whatever and just use three or four to make things easy to us and to other people who want to contribute. So the new idea is just to have this set of reminders. Okay, first reminder, second reminder, third reminder and it will fix and then move to next what? And that's it. Another question that we were having is how much of the information can be available for everyone because some people ask, for example, what is going on? But as I said before, we normally put private comments because some people actually tell us, okay, I'm changing jobs or I'm doing this and we actually add that information to the database. So we know how to ask and be more human when we ask because it's a kind of awkward job to ask someone to do something on the project when they are not active. And this is our current situation as Agus first. We have several people who need to be contacted, several people who need to be contacted for the second time and some people that the package needs to be orphaned and the discussion that the key ring maintainers has lately about pinging the people who has weaker keys on the key ring and decide what to do with it. It will be nice to coordinate together so we can actually decide what to do with these people, probably included manually pinned from the MEA team. Also as part of our tools, we save the mailbox with all the conversation with the maintainer who are being tracked. So we have a collection of mailboxes for each maintainer who have been tracked. So everyone who joined the team, for example, and want to check what happened a year before the people was contacted can open the mailbox and follow the threats and even using that information to contact the people back again. It's open for discussion, so I will really love if someone decide to... Michael? Just us. There we go. So on the private versus public status, it might be very worthwhile to come up with some indicators of status that don't include all, obviously, the personal information so you could still be able to provide that overall status. It says we're working with the maintainer or we're working with the developer or basically something that would allow someone to see that is actively being worked or the situations in good shape or bad shape without exposing the personal information. Okay. So with the current set of timings, are we not being possibly too nice to people? Well... And sometimes we lack of time. Sometimes it happens like we do a pink and we wait for four weeks or whatever, because one month or two months. Sure. So when mails are sent out, so the system at the moment, I've looked into this, I've pinged a few people over the years and whatever, I've forgotten the details, I'm getting old and my memory fades. Do the existing tools actually keep track and automatically ping people to say, we haven't heard from this person, should they? It's a good idea. I mean, that's the kind of thing I'm thinking. We were talking about automating this but with manual handling. So you just prepare the mails and approve. It's probably the best approach here. Because the discussion there has been like sending automatic emails. It's a little bit impersonal and this task requires some social interaction. I mean, it's very sad to ask someone what you're doing and then it's better when you actually write the email and try to be a little bit worn. We talked with Anna a couple of days ago about merging database with contributors at Bien Orc because there's a lot of overlap and the contributors is already tracking people's activity very coarsely. It only tells you, I've seen activity on that date. Yeah, actually we even use, at least me, for example, use contributors to see information that I don't have on the other system. So I could reasonably easily add some MIA features to contributors. Things that we discussed were the ability for anyone that is logged in Debian contributors. So both DDs and people with Ali of Accounts to go to a person page and click report as MIA. We have a comment added by Ricardo with the other team member working on MIA that is the first here that we should include a mandatory field explaining why or giving some information when you do the reporting. Yeah, report as MIA with field, saying I wanted... We can even track the status there. For example, we can check at least has been reported or has been tracked, or like two or three visible status, not the full status we have in the database, that will be cool. So if you log in back, you can see how the contributor is doing if he's actually been tracked or not. So I could have for each person in Debian contributors a MIA report log wherever people reported as potentially MIA with a text field saying why. And then if someone is logged in as part of the MIA team, they can see all the logs and they could click a button to send a ping, again with a text field with things to put in the email. And that would also be logged. The email may even have like click here to reply that goes on the website and adds to the MIA log the message saying, well, I'm actually alive. What are you just discussing? It's above. So I said what could be, from a different team, I'm kind of saying what could I can offer. So that will have a sort of lightweight, well, not lightweight but simplified but a swift workflow because you essentially log there and see a log with all the reports and what the person said and make like a very qualitative judgment about what's going on. So yeah, those are reasonably easy to implement. To what extent does this have any kind of API? Because I want to do, I'm part of the DSA team and I want to basically close a lot of shell accounts because currently we have a zillion shell accounts and like you pointed out with about 500 people being in various states of missing in actions then that's kind of accounts I might want to close. So what I want to do is both restricts so people don't have accounts on systems by default but they have an easy way to do I need an account on this portal box now please and then that gets provisioned so by default you can't just log into a portal box you'll have to kind of run this command and the other thing I want to do is currently we don't expire people from teams so being able to track a little bit especially if there's a way for me to take the information from possibly from contributors or from some of the things you are tracking so I can figure out that oh yeah you actually haven't done anything to the website for the last period of time. The query information is visible for all DDs you just need to log in on once and you can check the read me there you can see your comments you can see what was going on with the people there's one call it MIA to do that is the one that pulled the information that is in the bottom the one that you see over there and actually gives you the login and everything details the key etc is that in a parsable format or is that completely free for? We use two files we use one mailbox and we use another database with another text file and some Python scripts that do everything to it. Okay yeah sounds good like MIA team usually you measure inactivity right? For me it kind of seems reverse because when I find something that's broken I want to fix it I realize the person is probably MIA for a really long time and then I need to kickstart the MIA process which on basic timings if person is MIA and not replying is like 28 weeks or plus which is like half a year. But still you have an MIA? True. I still have an MIA that's true and like yesterday we talked about setting the expiry date on the keys to self-expire people. Can we assume that everyone is MIA? Then measure activity and to see if there is any activity within last year you are okay and then and if there are no activity that we can automatically detect in the past year or for example two years or three years right then we kind of should ping those people MIA even all of their packages have zero bugs and they have no posts on mailing list, no logins to any shell accounts, no uploads no sponsorships, no nothing such that we could kind of proactively clean people and kind of have expiry on your activity by default instead of measuring inactivity. I understand your point. Instead of defaulting okay? Defaulting MIA? I think it can be quite complicated no. Maybe not taking action on it but at least measuring it. Okay, Erigo was also just a short point I think it was said before that automated mails are impersonal I want to balance the point that when you interact with a package maintainer that it doesn't answer for months it's even more impersonal and I think I would balance the impersonal mail just ping and do something about your package is better than interacting with MIA people. About the MIA by default there's a problem in Debian in that no it's essentially impossible to track all possible Debian activity. If somebody is a Debian contributor and what they do is taking care of Vietnamese translation they would get an email a year saying are you still alive? And it's not that nice. On the other hand it's nice that as long as everything is fine in my work I don't get pinged even if I don't do anything. So it makes sense that things are triggered when something is lacking and I'm all for shortening the time because if things are triggered when something is lacking say there's RC bugs that are unanswered then we shouldn't wait 6 months those bugs should have been answered in the first place. So if I go and see a package that has dead activity in the BTS for some time and RC bugs and I want to take it over I would believe that we could move to a situation where it's easier to take over things when they're not properly maintained. I have one question for now that I see an evil and some other people I remember when we implemented the deviantainer process it was required to do an annual ping that has been done? No They're supposed to send the ping every They're supposed to send the ping every They're supposed to send the ping every They're supposed to send the ping every They're supposed to send the ping every No it's carrying on from Dimitri and Riko It is difficult to reliably detect activity so a lot of our contributors may not necessarily contribute all that regularly or it might be very difficult to track them I think we all understand that If we get to the stage, if you're in MIA then that means you already a DD Is it unreasonable to expect that either we should see contributions somehow we can track and send the mail once every six months if we haven't seen anything in six months and by all means there will be some false positives to start with but if we send mail to people and say we don't think we've seen any contributions if you think you have can you please tell us where and help us to track those in future that will be a really good answer to that but we definitely we should be able to do this and send definitely and impersonally mail and say sorry this sounds impersonal but our automated systems don't think that they don't seem to be able to find anything. Apologies if they're wrong please help us fix them Actually we have in the current scenario the MPA which is non-package activity so you can theoretically mark someone like okay this guy is doing web and it's not trackable and leave it there but after that there was no way to track it there was some discussion with Anna early regarding that and the point was we were supposed to take care about the package more than tracking the people itself so I think we need to balance somehow I wonder if there's a way to possibly expedite transfer of packages from an MIA to a team so there's been a couple of packages which I've immune and I've sent there's been clearly no no activity by the maintainer and I'd be interested in adopting it but not as a sole maintainer but transferring the ownership of that package to a team it's always possible for that maintainer to wake up and say I still am interested in it that's the quality assurance who take care of the orphan package I know what you mean because I have done that it's a package so you see a package that is not maintained correctly so you start loading it but keep the person that could be maintaining your blood and after some time you remove it some people do that in plenty of cases I think it's a good option but still reporting this person to MIA is good because this person might need what we actually depends on the scenario but sometimes we get reports people telling us like okay actually very interesting on this package and we skip all the process together and we say okay let's do this as a warning for the maintainer please take the package and leave the MIA process to continue in the background so but I get your point like you mean like a team to specifically maintain some package that I didn't be neglected yeah not like MIA maintainers team but sort of like well this package naturally would fit sorry thank you this package would naturally fit in this team and because they're the sole maintainer we have a process where we can adopt that package into the team and let the team maintain it but I like your idea of just keeping them there all the MIA process goes on and then if they do wake up then someone else was raising their hand over there do we separate which activity requires your GPG key to be in the uploader skeering and which activity does not and if all of your activity does not actually require your GPG key ring to be an uploader skeering for example you only upload and you only commit for example translations via SVN to alias then your GPG key you're uploading you don't actually make any uploads should it be in the uploader skeering but that will be something like moving existing developers or loading developers to the yeah well I'm just grabbing the microphone away from you because it's not the first time I hear this during DeepConf I do not think well I know it's not a hierarchical set of privileges but let's say several people have told me we should demote the accounts that do not show activity in some way the thing is it's quite involved if I have to move an account from one to the other key ring I also have to ask DSA change the account type and well maybe I am being responsible I'm not doing uploads for some packages but I for my packages I mean but I can still keep that ability so I mean yeah we want to require people to keep up to date not only with their activity but with the current practices well if their key is 1k that's so what I think is important here is for people that I don't think we should remove people from uploading a key ring because they don't upload what I think we should consider is things like if you never used your GPD key then maybe it's not a good idea for it to exist in the key ring at all because that means that potentially we have a cryptographic credential out there which is not under good control so it's not about uploading versus non-uploading if you vote for instance then you're actually using your GPD key and that's the same same approach I'm using for the accounts and groups is that if you're actively using a group or actively using an account on a portal box then I don't want to shut that down but if you have an account on a portal box and you've never logged in there for like in the five years that machine has existed then that account should not have been there in the first place I think we see a trend here in not having everything in one account not being a DD means being able to vote having an email address being able to upload etc and I think the current trend is dividing these things and having these virus things expire that doesn't mean that you lose your email address or the right to vote when someone orphans your packages because you're not doing work and I think it's quite important to not consider the MIA like we remove you from being a DD and that's the long process you know, our last step is orphan the package then everything moves to Debian account and it's their decision to do whatever they want to do with the person main point here is packages have not been maintained should be orphaned and then we decide after that was whether you're a DD or not it's not actually decided by whether you have a key in the key ring in Debian account and Debian systems Dam decides who is a DD and they ask key ring maintainers to add the keys of those people to the key ring and I don't think there's ever been a case where they haven't added that key but they are actually free to not do so and similar they will ask DSA to create an account and we're actually free not to do so and I don't believe that has ever happened but these are actually three separate concepts The inactive key reminded me that we do not currently have a system to audit key usage so when I log into my bank I get an email saying there's been a login into your account it would be nice to have a log of every time my GPG key has been used in Debian so I could see if there is some use that wasn't me and I detect replay attacks the same could be used if that actually works in a way that there's no way GPG key use that is not tracked with this it can also be used to see that that key hasn't been used for like three years and then move it to time out key ring of some kind also both studies Eklon actually tracks that so in LDAP there's a field which says when a key was last used and where so that's tracked on Debian lists and uploads we also query that information it's not used everywhere I don't think it tracks votes for instance it tracks a certain amount of GPG key usage even citing the dimension does it also track SSHK usage so I am going to change a bit the topic of the discussion I would like to talk about a phenomena we have been experiencing in the last two, three years that are the Fountain Maintainers so there are people you go to their developer page that maintains I don't know 15, 20 packages but actually they are doing no job in Debian at all they are used for maintenance several things for example the parallel thing is a very good example of this but they have no activity use at some moment they add themselves to maintenance so I would like to ask you all that if you have a co-maintainer who is doing no job at all in the packages to remove them because it may sometimes the MIA team work very difficult well remove it then notify us also ideally a maintenance contribution should be tracked by the change log instead of the maintainer field we currently have a problem with DCH not putting an email address in the square bracket when the co-maintenance is only used full name so try tracking Brian Elson and Luca Bruno if you can and I reported a couple of days ago back to DCH asking if there could be the email address at least added to that and I don't know how much that would break but at least that would make people's activity trackable via the change log which would be a step forward in this respect this is of course why we should have all packages and get that's what I was about to say it's probably easier to track email addresses from emails in the kids changes but not everyone use git how about you as sole maintainer yes sure but I mean if it is co-maintained it's most probably on alias so plugging in there it's probably be careful about tracking activity with git commit logs you import upstream sources upstream becomes the developing developer plus the change log is signed by the uploader at some point so that we can trust that information much more than we can trust git stuff because on co-maint I could commit anything in the name of anyone in any git repo actually at FOSDM me and Daniel Silverstone toyed with the idea of doing a white hat operation against co-maint which maybe they are not happy with but it would be fun to add to every git repo in co-maint build in Debin control saying x unchecked upload column true and see how many of those end up in the archive at some point I don't think DSA would have a problem with it the alias admins might be have a problem with it it's important to have enough sets of hats that we can distribute around everybody ok what I was saying is we probably should take notes so git tracking is not a good idea so far the only the only conclusion we reached is the use of contributors which Enrico also suggests and it's a cool idea having the way to get feedback keeps on data private improve the tracking regarding the tracking how hold on sorry we have another question there with the tracking what can we do with the with the teams sometimes we even find some teams that are being me and it's quite complicated because there's two, three people in the mailing list some actions need to be taken for example if there's a mailing in Alio it probably need to be closed or hand over to someone else yes exactly and then there's a few packages out there which well they appear to be maintained by a team actually it's just one person and they've got to get around being noticed so of course if they go away even worse if it's not an Alio list you've got no idea who's on that mailing list yeah a question for DSA do we have any way to track all the bonds in Alias I mean if I send an email to some developer if the email is bouncing we currently don't track that I think also it's not that there are two sides of that there's Listmaster which obviously does it for lists we don't currently do it for the normal Debian Alias we possibly should because last time when so about a year ago we did a fairly large whichever over how we do the email writing on Debian Og and during that process we discovered a few people whose email like they're Debian Og email in the forwarding completely didn't work there is a complicating factor there in that we don't necessarily actually have email addresses for all accounts but that's something which I think we should rather fix than say yeah that's a desirable property because we get sometimes reports and emails bouncing so it will be easy and it will be a very easy way to trigger action from me and from them and whatever at least tracking not so far as 400 less say 500 or something the problem doing just simple bounce tracking there is that some people will bounce their email based on it being spam yeah so people shouldn't do that but people still do it so I mean you would get a good bunch of false positives so I'm not sure like it might be an extra data source so you can use it to verify whether all their emails are bouncing I mean we can we can detect the percentage but actually we send an email and it bounces then obviously and then you also get around so you can figure out whether you know it says spam detected or it says like a user okay okay any more ideas yeah so if you want that then please file an rt ticket so we actually keep track of it rather than you know I standing here saying yes that's a good idea and then I forget because there's a good party tonight and nothing happens okay regarding the hijacking in orphanage I have one question for for people in the audience has anyone taking packages and not notifying me like hijacking one package and yeah I've kind of done that in the last couple of weeks and I haven't notified me yet okay sorry it should I don't know if the developers reference says that you should do so but if it doesn't then it should it actually say you should think he's in some section like beyond packaging or something like that I don't remember okay yeah I read the like when I became a DD 14 years ago and haven't really read it afterwards so so I will ask another question I mean how much manpower does the MIA or QA team have in general at the moment exactly it's to make a point obviously we're all talking about lots of things that it would be lovely to have here I'm assuming also lovely to have would be manpower to make these happen yeah I'm making a point of that for everybody in the audience yeah I was I was actually planning to give a call for for help we were discussing with Anna also that right now the situation is quite complicated with I mean it's confusing so if we want to change the way we work it will be better to have some people also to help because currently we are only actively Ricardo Anna and me so three people mostly Ricardo doing the job day-to-day job and me sporadically one week or whatever so bits of the MIA team are actually MIA and we also have an email asking on the MIA team if you are MIA inside the MIA team and it will not be the first time I remember before some people okay okay thank you we close a little bit early thank you