Differences between revisions 17 and 18
Revision 17 as of 2016-08-20 13:17:55
Size: 6861
Editor: XTaran
Comment: Mattia considers me a team member now, at least I receive these strange mails now. ;-) Also add a proper headline for the list of team members.
Revision 18 as of 2016-10-11 10:16:57
Size: 6888
Comment: Add myself to team member
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
 * [[MatteoFVescovi|mfv]]


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.


  • Documentation: qa.debian.org:/srv/qa.debian.org/mia/README

  • Unix group: qa

  • MIA is handled under the QA 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

  • {*} Please, pretty please, mail us if you think a maintainer is inactive. Your mail will be held private and we'll investigate the case.

  • {*}{*} Become a team member and help tracking MIA maintainers (DDs only here)

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:

  • Status: First warning -> wait 16 weeks.

  • Status: Second warning -> wait 8 weeks.

  • Status Final warning -> wait 4 weeks

  • Orphaning packages (maintainer of course, gets CCed in orphaning bugs)
  • Automatically is set to Status: needs-wat.
  • Possibility to override the warning status with a will-fix for X months.
  • Part of this information would be available to DD at contributors.d.o / qa.d.o CLI
  • New status:
    • ok (default for everybody) first reminder second reminder third reminder will-fix needs-wat (allows to go back to ok if person stays active but doesn't maintain packages) retired/removed
    • Automatic reset of the MIA status if maintainer gets active.
    • Add private comments for the team in the database

* What shouldn't change:

  • mailboxes db
  • CLI tools