Re: QA first: looking beyond the MIA process

Hi Tobias,

thank you for this proposal.

I believe I have found a package that appears to fit the criteria you
describe. To make sure I have understood the intended procedure
correctly, I have done a QA upload of laptop-detect to DELAYED/15 and
filed the corresponding orphaning bug (#1143551).

Using DELAYED/15 should leave sufficient time for anyone to point out if
I have misunderstood or misinterpreted the announcement before the
upload is accepted.

I think it would make sense to also announce the text below on
debian-devel-announce and document it in the Developer's Reference.

I also wonder whether you might consider opening a bug to update the
list of uploaders of the package molly-guard as task for any DD or
remains the task of the MIA team.

Kind regards
    Andreas.


Am Fri, Jul 31, 2026 at 08:11:24PM +0200 schrieb Tobias Frost:
> 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
> from 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. 
> 
> -- 
> For the MIA team, with thanks to my fellow MIA team members Paul Gevers
> and Nilesh Patra for their reviews and suggestions,
> 
> tobi