Differences between revisions 1 and 18 (spanning 17 versions)
Revision 1 as of 2010-06-14 07:19:49
Size: 2420
Editor: JanHaukeRahm
Comment:
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 2: Line 2:

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.
Line 5: Line 7:
 * '''Documentation''': qa.debian.org:/org/qa.debian.org/mia/README  * '''Documentation''': qa.debian.org:/srv/qa.debian.org/mia/README
Line 12: Line 14:
 * '''Public IRC channel''': #debian-qa on irc.debian.org (OFTC)
 * For urgent private discussions please use #debian-private on OFTC since #debian-qa is a public channel. Though mail is still preferred.
 * '''Public IRC channel''': [[irc://irc.debian.org/debian-qa|#debian-qa]] on irc.debian.org (OFTC)
 * For urgent private discussions please use [[irc://irc.debian.org/debian-private|#debian-private]] on OFTC since [[irc://irc.debian.org/debian-qa|#debian-qa]] is a public channel. Though mail is still preferred.
 * '''Debian MIA IRC Channel''': [[irc:irc.debian.org/debian-mia]] This is private channel, password available on qa.debian.org:/srv/qa.debian.org/mia/irc-password.
Line 17: Line 20:
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 (merkel at the moment). Requests can be directed to the contact address by everyone, though, which is appreciated. 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.
Line 19: Line 22:
 * [[JanHaukeRahm|jhr]] is handling the everyday job
 * [[ChristophBerg|Myon]] is sort of the interface between MIA and DAM
== Current Team Members ==

 * [[RicardoMones|mones]]
 * [[ReneMayorga|rmayorga]]
 * [[MattiaRizzolo|mattia]]
 * [[TobiasFrost|tobi]]
 * [[XTaran|abe]]
 * [[MatteoFVescovi|mfv]]
Line 24: Line 33:
MIA means "Missing in Action" and is a group of people and scripts which help to track inactive people in Debian. The MIA Team is responsible to orphan outdated packages if the maintainer is not responsive. We also help the people to find solutions like finding a Co-Maintainer and so on. 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. 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.
Line 29: Line 88:
 * <<Icon(star_on.png)>><<Icon(star_on.png)>> Reorganize documentation, see below (DDs only)
 * <<Icon(star_on.png)>>
<<Icon(star_on.png)>><<Icon(star_on.png)>> Become a team member and help tracking MIA maintainers (DDs only here)
 * <<Icon(star_on.png)>><<Icon(star_on.png)>> Become a team member and help tracking MIA maintainers (DDs only here)
Line 34: Line 92:
Currently, there is [[qa.debian.org]] with sub pages and the aforementioned README file on merkel 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. 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.
Line 37: Line 95:

== 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

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

  • 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