QA/MIA

Missing In Action, part of QA (quality assurance), a team to find maintainers (DDs as well as DMs or sponsored maintainers) who seem to be neglecting their duties or not making use of their membership. The idea is to improve Debian's quality, not to hunt developers.

Infrastructure

Interacting with the team

Usual roles

Due to the privacy of personal data possibly stored in the MIA database, all team members need to be Debian Developers. The complete interface is available on a DD-only machine: qa.debian.org. Requests can be directed to the contact address by everyone, though, which is appreciated.

Current Team Members

Task description

MIA means "Missing in Action" and is a group of people and scripts which help to deal with inactive Debian contributors. The MIA Team is responsible to orphan outdated packages if the maintainer is not responsive. It also helps to find solutions like finding a Co-Maintainer and so on. The team may request the removal of an inactive member's account.

According to this information a "MIA Person" is someone who has packages in Debian and maybe is even an official Debian developer but was quite inactive for a while and let his package get out of shape. Someone is considered a "MIA person" as soon as anyone reported this person and an entry in the DB has been created.

You know someone who seems MIA

Sometimes there are people you have been working with years ago and they are not active anymore but still listed as maintainer/uploader for several packages which now seem neglected. Or you're working on RC bugs or whatever package you like since noone did before. This is when you notice that something's off.

What can you do? Well, obviously, talk to people! Mail them, see if you can meet them on IRC, be creative. Simply ask them if they're still active. And if you don't want to do that or you're out of ideas or just too shy, leave it to us by mailing to mia@qa.debian.org which is our contact address. (You can even CC us from the beginning if you fear your contact will remain unanswered anyways.) Mailing public mailing lists is also possible but not always as effective as one might think. And please, pretty please, don't just start orphaning packages. Give us and the maintainer in question some time to figure things out.

You are MIA

If you really are MIA and still reading this text, think about it. :)

Well, measuring the level of activity in a project like Debian is quite difficult. There is of course the last upload, then the number of RC bugs a maintainer never responded to. But there are also many subversion and git repositories that one could check for commits... You get the point. If you ever get mailed by us even though you're active, please don't get angry. We make mistakes sometimes and it's not always clear if someone's MIA. Even nasty spam filters made contacts impossible in the past and led to unpleasant confusions.

When we think (for whatever reason) that you seem inactive, we try to contact you. And then we try again. And again. One day, after warning you about this, we will orphan your packages and request other maintainers to remove you from uploaders lists. How can you avoid this? Oh, that's simple: answer our mails.

We are -- despite what people think -- not hunting the bad guys, we don't have a black or red list of people that we would like to get rid of. We are a bunch of Debian Developers mainly who think that neglected packages aren't exactly good. So this is basically a QA effort. It is true that we, as a last step, inform the Debian Account Managers about DDs that seem to be completely MIA (usually after orphaning all their packages) and they will proceed with account removals as they see fit. But that's the very last step. So please understand, when you get mailed by us, we will not kick you, we just want your packages to have the attention they need. It's that simple.

Get involved

More stuff

Currently, there is qa.debian.org with sub pages and the aforementioned README file which are even partly contradicting. Also, none of these seem to reflect complete and correct information. Thus, if you want to join, please read the complete stuff and then get in touch with us about the current procedure.

{i} MIA should be embedded properly in the new QA workflow yet to create.

Titanpad from DebConf14 MIA BoF

* Possibility of reporting MIA via web interface contributors.d.o, including a mandatory field to specify why and how you relize the maintainer is MIA.

* Include a way to have feedback to the `reporter'.

* Add MIA tracking for teams.

* Allow mia-tracking via web (plugin to contributors.d.o)

* New workflow more clear that current one (nice, prod, last-warning, wat) and time based:

* What shouldn't change: