On Mon, Sep 14, 2015 at 09:37:28AM -0400, Sam Hartman wrote:
> What I'm hearing is that there seems to be general support for TC
> members calling for quick votes in cases like this. If I were doing it
> I'd probably give 24 hours to comment on an interim ballot and then do a
> CFV.
It seems to me that the only way you'd get a ballot like that out quickly
is if there's a template you could easily fill out, that's "good enough"
for, say, 80% of issues. If you're coming up with something within a
day of an issue being filed, I don't think it's reasonable to try to
have a detailed background of the issue in the ballot, for instance.
A) agree with the bug:
A.1) Under 6.1.2 of the constitution, the committee resolves the dispute
between developers [...] (as maintainer of [...]) and [...] (as
maintainer of [...]) by determining that:
* [the priority of package ___ should be ___]
* [/usr/bin/___ should be owned by package ___]
* [bug ____ should be fixed in package ___]
* [package ___ should be maintained by ___]
* [...]
A.2) Under 6.1.3 of the constitution, the committee accepts the
delegation by developer [...] of the right to decide [...], and
determines [...].
A.3) Under 6.1.4 of the constitution, the committee overrules the
developers involved, and requests the following technical course
of action be undertaken:
* [package ___ should be reuploaded with the following patch
applied, or equivalent functionality: ...]
* [package ___ should be reuploaded with the following patch
reverted: ...]
* [...]
A.4) Under 6.1.5 of the constitution, the committee offers the following
recommendation for dealing with the issue raised, but at this point
leaves the final decision in the hands of the developers involved:
* [the priority of package ___ should be ___]
* [/usr/bin/___ should be owned by package ___]
* [bug ____ should be fixed in package ___]
* [package ___ should be maintained by ___]
* [package ___ should be reuploaded with the following patch
applied, or equivalent functionality: ...]
* [package ___ should be reuploaded with the following patch
reverted: ...]
* [...]
B) decline the bug:
B.1) The committee think the issue raised requires further discussion,
but that the project would be best served if this took place via
[the bug log | debian-policy | the ____ mailing list | ____]
rather than involving the committee directly at this point in time.
B.2) The committee endorse the actions of [...] as the responsible
maintainer and as such decline to overrule their decision.
B.3) While not endorsing the decisions of [...] regarding this issue, the
committee accepts that they were not unreasonable, and bearing in mind
that, in general, individual developers have the right to "make any
technical or non-technical decision with regard to their own work",
declines to overrule the decision in this case.
For bug escalations where users think a developer's done something
wrong, A.3, A.4, B.1, B.2 and B.3 would be reasonable.
For conflicts between developers with overlapping jurisdictions, A.1, A.4,
B.1, B.2 and B.3 seem reasonable (and I don't think A.3 is necessary).
For the rare case where a DD delegates a decision to the ctte, A.2 or
B.1 would be the only reasonable options I think? If FD won initially,
and discussion resulted in consensus that the DD went ahead with, B.2
could become an option I guess.
If someone asks the ctte for advice on a topic before there's an
entrenched disagreement (!) I think FD and B.1 would be sufficient
alternatives for an initial vote?
(Hmm, having templates like this might make it easier for people to
understand how the ctte can actually help, maybe...?)
> I understand there are community members who want to go further than
> that and have automatic votes, etc.
FWIW, to me "automatic" means "quick", "easy", and "likely to actually
happen"; while "manual" means "slow", "painful", and "likely to be
forgotten pretty frequently". If you end up with a process that turns
out quick, easy and likely to actually happen, but requires people to
do manual steps, I'm likely to call it "automatic" anyway. ;)
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature