I have a proposal. In writing the below, I realized that we may have reached the point of diminishing returns, and perhaps we should be done with this discussion. CONSENSUS IS NOT A REQUIREMENT HERE. In general, if someone wants to maintain something in Debian, and the ftp team does not object, and the TC does not assign a different maintainer, they get to do it.
We clearly aren't going to reach a consensus here,
and at least for myself, all this is doing is causing me to ask whether
I still want to spend any time on Debian at all.
If Branden actually makes an upload, great.
If he realizes he's never going to get around to it, he hopefully closes
his ITA bug.
If someone else has time they contact Branden, or if he's unresponsive
tries to salvage the package.
(or simply maintaines it through debian-qa).
If someone does maintain the package, people use normal Debian
procedures if they don't like it.
>>>>> "G" == G Branden Robinson <g.branden.robin...@gmail.com> writes:
G> 3. The reporter is either satisfied or not. If not, I reckon
G> the forum of appeal is the CoC committee.
By charter the community team has very little de jure power, and
definitely has no de jure power with regard to the contents of Debian.
The TC is the only body that has the constitutional power to override a
maintainer WRT the contents of a package in Debian (or to replace a
maintainer), although of course they may choose to consult any other
body they like.
I think the community team is a bad choice for content decisions,
exactly because the CoC is not tuned for evaluating content, and the
community team by its nature is going to focus on the CoC.
As I've said in the previous thread (with some rationale), I think that
the rules for creative content ought to be more permissive than the
rules for project discourse.
signature.asc
Description: PGP signature
