QA first: looking beyond the MIA process

--9o258LqskYm6s9c8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

I'd like to share a small change in how the MIA team has recently been
handling a specific class of reports, but more importantly, to encourage
a broader QA mindset.

The MIA process serves both security and QA purposes, like quality and
maintainability of the archive. It is an useful tool, but like any tool,
it is not the right one for every situation.

A recurring pattern we've seen is reports concerning Debian Contributors
who were active only for a relatively short period, contributed to only
a small number of packages, and have shown no Debian activity for many
years.

Before investing effort into finding a new maintainer - or establishing
whether the current one is MIA - it can be worth evaluating whether the
package still provides sufficient value to Debian. Removing a package
that no longer serves a useful purpose is just as much a QA improvement
as finding a new maintainer for one that does.

There is no single criterion that answers this question. However, a
combination of factors can indicate that proposing removal deserves
serious consideration. Examples include:

- very low package usage (e.g. popcon),
- no upstream activity for an extended period,
- software that has become obsolete or has been superseded,
- packages where the Debian maintainer was also effectively the upstream
  maintainer, and upstream has ceased for many years,
- being largely isolated within the archive (for example, no reverse
  dependencies beyond closely related companion packages),

None of these factors should be interpreted in isolation. Niche packages
may naturally have low popcon numbers, upstreams sometimes become stable
rather than inactive, and contributors do occasionally return after a
long absence.  These are indicators intended to help guide judgement.

If the situation already provides sufficient indication that action is
needed, for example based on several of the indicators mentioned above,
it may be more effective to first evaluate whether the affected packages
should remain in Debian. Removal can be a better QA outcome than finding
a new maintainer. If the packages should remain, then salvage or
orphaning are possible next actions. Where the appropriate course of
action is already reasonably clear, you may choose to act accordingly
without involving the MIA team, though it remains the appropriate point
of contact whenever the right course of action is less clear.

The above recommendation is intended for project members with sufficient
context to make such QA assessments; it is not intended as a general
recommendation to bypass or replace the MIA process. The approach
described here applies only to the narrow class of reasonably to be
assumed MIA Debian Contributors described above. Other cases should
continue to follow the existing MIA procedures. Rather, it is a reminder
that the MIA process is a means to improve QA, not an end in itself.

Accordingly, the MIA team may use a simplified process exclusively for
this narrow class of reports. For these reports, running a full MIA
procedure may not be the best use of the limited MIA team resources as
the additional investigation required can be significant, while an
incorrect assumption can usually be easily corrected. If the contributor
is still interested in maintaining the packages, they can simply reply
or close the bugs. Therefore instead of initiating the regular MIA
procedure, we may directly orphan the affected packages or file "Remove
=66rom Uploaders" bugs while informing the contributor of the actio taken.
This allows the MIA team to focus its effort on cases where the process
provides more value.=20

--=20
For the MIA team, with thanks to my fellow MIA team members Paul Gevers
and Nilesh Patra for their reviews and suggestions,

tobi

--9o258LqskYm6s9c8
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAmps5UcACgkQkWT6HRe9
XTYu3w//V3CL0WU0i0IQGskytBrW4EicsbCZQdQels7DW3qoKBXqhZN6PJ2DFrnC
ocpXPQ8Z4iMiWoqk+Cff5o5m670aP9z2bNkIDvI2fk3OIJaKQNAB6k7yrwSJbJOI
QjIgXi1EKvb8W0/l1LviZZ9HKMZv7snPvaEgi7G6HgcveChj+VP0jrs5NKtN4CLq
5LG+VS8kCIRgH4n5Dr301xY+vT2RsaKI0kzGoHTgxgpSNsBRrhOjdHyq1Bj5BaPk
BJrxFb2rUVe7dJSdQZG8lpiR88Q9N1JEz+U6enT1HAip1vBLEB5cYcdiYjq9bh7f
E51NyFES6T0r5D8wElczjDGhlhLEQSq88MAqvla9Zg5WgDordolhzd9uB+NTooiV
pXzjSAd+YJ6bjz6u2r1hNDV8Jh92jAvvlh4f1JW+vL2pZgmbSdeiLvF7srubrXBV
/b4qmozJquvHH/LBTe471+aHqWkmLjWGzJNV1PlsdyXQd+3/oSem7qf6HOAc867z
yHcywg9NMb7cdXT62tkCfunzoPLUBN6frtRutOzKk95HRtdj9uHuZ5jyesqE4trl
ktCItwWQ8Vvpib0EFlnTCaBF0Wn1wWeIpwc8ZN+iNONfGu8hI56ZE3ceqkb1nyyr
HSYDaW/Tm7Zs7C0kLAqFrAwRku0CnHm3ZgIp7++GinDpPLV4gG4=
=7tI0
-----END PGP SIGNATURE-----

--9o258LqskYm6s9c8--