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
signature.asc
Description: Digital signature