[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Replace the TC power to depose maintainers



On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote:
> There is a recent case where:
>  * The maintainer has done nothing to the package for many years,
>    other than infrequent (and usually short) emails to NAK
>    contributions from others;
>  * The package is years out of date compared to upstream, afflicted by
>    bitrot, and many users are asking for the new version;
>  * Several times, proposed updates have been prepared by contributors
>    but blocked by the maintainer;
>  * There are new maintainers ready and waiting, with a new package
>    ready for upload to sid for stretch;
>  * Now that the TC is involved the maintainer has written many emails
>    explaining their decisions to NAK uploads, but TC members are
>    clearly unconvinced on a technical level that those decisions were
>    right.
> Even in this extreme situation the TC has not seen fit to wrest the
> package away from the mainainer's deathgrip.

We have a very similar case within the MIA team (the willing contributor
contacted us instead of the TC).  The only difference is probably that
the maintainer sent his NAK to me on IRC instead of in a email, and now
he is not doing that either).  The difference is that on paper we don't
have the authority to "wrest the package away"; but I can't even mediate
given that this person is not replying....
(this is this case reported in d-d:
https://lists.debian.org/debian-devel/2016/11/msg00320.html )

> 1. Recognise that Debian will never depose a maintainer, no matter
>    what.  Maintainers are, within their packages, dictators (subject
>    only to the possibility of TC overrule on individual issues, which
>    is itself very very rare).  The only way to get rid of a bad
>    maintainer is to wear them down unti they eventually go away.

This is silly.  We have a issue that really needs resolving.

> 2. Provide a new process for deposing a maintainer, or appointing
>    co-maintainers.

Agree.

> 3. Abolish maintainership entirely.

This would be a mess, as you acknowledged.

> The key question for such a new process is: who will decide ?
> 
> It is very tempting to model such a thing on our existing
> constitutional structures.  For example, we could create a team like
> DAM, whose job was to take (private) requests for
> mediation/intervention, and who would eventually make some kind of
> decision.
> 
> But I would like to make a more radical suggestion.  We should make
> these decision by juries, rather than committee.
> 
> For each such dispute, we should pick a panel of randomly chosen DDs,
> and have them decide (with a time limit).

No randomness please.  Probably all bodies in Debian are either elected
or appointed (by previously elected bodies).  We all know that there are
DD with a known bad track at mediations which would be totally unfit for
such a role.

> In more detail:
> 
> An aggrieved contributor, the complainant, would first contact a
> mediation team, privately.  There would be some overlap with MIA, I
> guess.  Hopefully things can be resolved through mediation.

In some part this already happens within the MIA team; but so often
mediation just fail simply due to lack of communication by one part
(i.e. we can't even mediate!)

> If the mediation does not result in satisfaction, a DD complainant
> would send an email to a robot, giving the names and addresses of
> co-complainants.
> 
> The robot would select a random panel of (say) 10 DD.  (There would
> probably have to be a ping back phase to make sure the chosen weren't
> MIA.)  There robot would set up two mailing lists: the panel; and the
> complaints and existing maintainers together (for the maintainers,
> personal addresses, from, Uploaders, for a "team" maintained package).
> 
> The complainants would send an initial summary to both lists; the
> maintainers would prepare an initial reply, to both lists.  Messages
> to the panel list but not the two-sides list, other than from panel
> members, would be rejected.  If a panel member feels that private
> input is required from one side, they can ask for it and forward it
> themselves.
> 
> The panel would discuss matters for a period of two weeks.
> 
> The complainants and maintainers would be CC'd on the initial mails.
> At the end of two weeks they would vote.
> 
> By a simple majority, the panel either reaffirms the maintainership of
> the existing maintainers/uploaders, or transfers formal maintainership
> to people nominated[2] by the complainants.

This sounds a nicely cut idea to me, except for the randomness above.

> [2] Nomination of the new maintainers should be done at this stage.
>     Thus a a frustrated contributor who, if the petition fails, needs
>     goodwill of the curent maintainer, can ask others to front the
>     complaint and argue the case.  This helps minimise the justified
>     fear of retaliation.

Fear of retaliation in such a place is IMHO everything but justified.
Or at least it shouldn't be...

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Attachment: signature.asc
Description: PGP signature


Reply to: