Re: draft alternative proposal: fix problem at the root
On Tue, Dec 02, 2014 at 11:34:14PM -0500, Scott Kitterman wrote:
> I think it would be better if ctte members did not bring disputes to the ctte
> and then vote on the resolution of that dispute. [...]
One thing I'd been pondering suggesting was that the ctte change how they
view "requests". ATM it seems like someone asks the ctte "Please decide
that A is the right way to do X" and the ctte looks into the issue,
maybe changes A to A' and says "ok" or "no".
Given that's only likely to be an issue when the maintainer of X has
decided to do B instead of A, I think that provides a pretty strong bias
towards the ctte only ever getting to consider questions of the form
"do we overrule Alice on this?"
I think that's generally a bad thing, so I wonder if it wouldn't be better
for the ctte to only accept questions more of the form "Please investigate
the way we do X (and/or how we should do it)" with possible outcomes:
- "sorry, more important things to worry about"
(decline the request entirely)
- "A, B, or C are plausible approaches that can be achieved by Debian
users using the following techniques: ..."
- "A, B, or C are plausible approaches for the maintainers to choose;
they involve the following tradeoffs: ... the maintainers of the
respective packages have decided B is the best approach."
(investigate and report only)
- "A, B, or C are plausible approaches, when X is the case, maintainers
should do A; when Y is the case, maintainers should do B; otherwise
maintainers should do C. the consequences of the different approaches
are ... Here's a patch to -policy summarising the above"
(decide on any matter of technical policy)
- "A, B, or C are plausible approaches; based on the tradeoffs involved,
we recommend B for this particular case"
(offer advice / make a maintainer's decision for them)
- "A, B, or C are plausible approaches. the tradeoffs involved are ...
the maintainers of foo believe A is the best approach; the maintainers
of bar believe B is the best approach. Unfortunately these approaches
conflict, and a decision has to be made, so we've decided ..."
(decide any technical matter where jurisidctions overlap)
- "A, B, or C are plausible approaches. The maintainer has taken
approach A, which has the following consequences: ... These
consequences are unacceptable because ... The maintainer disagrees
for the following reasons ... We overrule the maintainer, requiring
the packages involved use approach B or C instead."
(overrule a maintainer)
I think that'd have a couple of potential benefits:
- the "investigate and report" step is essentially common to all of
the outcomes above, and is something the ctte could hand-off to
"helpers" (ie, request comes in, ctte assigns it to a (neutral) helper
to gather as much info as possible, helper provides summary to ctte
at next irc meeting, ctte decides what to do next, summary is posted
to d-d-a as part of closing the request). that might also be a way
of letting people help the ctte without having to be involved in the
"political" parts
- anytime "investigate and report" is sufficient to achieve a consensus
("Oh, I didn't think of that, you're right, C is the way to do
things"), it avoids even having to consider the "who wins, who loses"
question
- if there's an actual report summarising the alternatives and tradeoffs,
rather than just an argumentative email thread, that might make it
easier to maintain/update policy on the topic
- the process would work just as well for a maintainer who wanted a
second opinion on a hard technical problem, even before any dispute
has developed (and that in turn might help prevent disputes in the
first place). having the ctte be something that's a useful resource
for maintainers to turn to would be a major win IMO.
Looking at the systemd stuff, I think the "investigate and report"
part of the initial upstart/systemd/openrc debate was the most valuable
(it introduced openrc to a bunch of people, helped resolve some bugs
in both systemd and upstart aiui, and helped people decide which system
they preferred), and personally my biggest problem with the more recent
GR is that (IMHO) the "investigate and report" stuff (in the form of
preparing specific technical documentation for maintainers and admins)
hadn't been done. Of course, the non-technical stuff took longer and got
the most press attention [0]. I think doing more and better technical
investigation/reporting/policy at this level would be a win and might
even make things more fun for the folks involved.
[0] http://lwn.net/Articles/572508/
http://lwn.net/Articles/578208/
http://lwn.net/Articles/581324/
http://lwn.net/Articles/584508/
http://lwn.net/Articles/617811/
http://lwn.net/Articles/620189/
I guess essentially I'm suggesting the ctte break down the work into a
technical component (list the feasible approaches and their consequences)
and a normative/social/political component (work out who gets to decide
which is the "best" approach), and make sure the technical step is
finished before the normative step is even considered.
I think that approach would mean it wouldn't matter much if a ctte
member brought a topic to the ctte -- the technical analysis is the
same whatever outcome you want (if we do A, X happens; if we do B, Y
happens), any disputes should be in the normative step (if X happens,
the world will end, we should do B; no, that's if Y happens, we should
do A). And as long as the technical analysis is complete and accurate,
I'm not sure I'm bothered if a ctte member was involved beforehand and
hasn't changed their mind. (YMMV, mine might too)
It might even be a *good* thing for the ctte to be able to occassionally
choose some area that's somewhat lacking in some way, review the
alternatives, and provide a good technical summary of options that the
wider project can could consider undertaking. Like, "review Debian's QA
activities" with conclusions such as "we should obtain more hardware
to run piuparts more frequently" or "lintian checks for these classes
of bugs would be hella useful"; or "is our content getting to users
efficiently?" or "is Debian well documented for users?" or "is Debian
an effective development environment?" or "how are the release goals
progressing?" Kind of a way to do a neutral review of "strategic" things
as a project. (Of course, whether domething is "strategic" is obviously
a normative judgement, not a technical one)
Cheers,
aj
Reply to: