On Mon, Jul 16, 2012 at 12:01:50PM -0400, Michael Gilbert wrote: > As an example, the wine package was in a very similar state to the > python package a few months back. Instead of complaining about the > maintainer (and likely leading to a flamewar), I did my best to get > work done while concurrently allowing the maintainer to reject that > work if he were really interested. This involved many 10-day delayed > liberal nmus of the package, culminating in bringing it up to date. I > also ensured that all of my messages were positive, and acknowledged > the fact that the maintainer could review and reject the nmus while > they were in delayed. Apparently, my uploads were sufficient and none > were rejected. Ultimately, I brought the package up to date, and was > accepted in to the team. > > This worked, I believe, because I maintained a positive stance > throughout the process.
Let's add a couple of data points to this example of yours. IIRC the
timeline, before your involved in it, I chimed in the relevant buglog
suggesting, if not encouraging, the NMU path. Later on you contacted me,
privately, asking for advice on the best way to proceed with the NMUs.
I've been happy to provide the advice, essentially encouraging your
NMU-based plan (my position towards NMUs is well known, so that should
come to no surprise to anyone). Then you proceeded, cautiously, doing
very proper NMUs that allowed, together with some help from the
maintainer later on (I'm thinking at alioth permissions here) to solve
the issue for Wheezy. Which is a great result.
But I still find interesting that in an example that you use to argue
for transparency, a private mail exchange has played a relevant role.
------------------------------------------------------------------------
Transparency is hard. But it is a worthwhile goal. Out of hypocrisy, I
suspect that today every non trivial (social) conflict solving will end
up having some private exchanges. Especially when mediations are needed.
The question we should ask ourselves, then, is how to *minimize* those
exchanges. Ideally trying to reduce them to 0 even if we know we're not
there yet.
This is why I'm worried about this specific GR: it seems to go in the
opposite direction. I think that the present situation, i.e. "thou shalt
not do that", is a moral check on the desire of discussing matters
privately with and within the tech-ctte. Those private discussions will
happen [1], but the fact that they are considered socially wrong will
limit them to cases that are considered "extreme", even for tech-ctte
issues (which are already extreme per se). I fear that legitimating
private discussions will remove this useful moral check.
I realize that my stance above is a hack, based on the assumption that
people will occasionally "break rules" even if they shouldn't. And I
understand that the draft GR is trying to attack the problem from the
opposite angle, i.e. defining when private tech-ctte discussions are
acceptable. But the propose solution seems flawed in at least two ways.
The first one is that once easy mechanisms for discussing privately are
in place (e.g. a debian-ctte-private list), it will come very naturally
to discuss privately also matters that could've been discussed publicly.
The second one is that nobody outside the tech-ctte will be able to
control what is actually being discussed on those fora.
The tech-ctte is a trusted body in Debian anyhow and, presently, I have
no reason to distrust any single member of the tech-ctte. But removing
both the moral check of discussing matters publicly and the ability to
review what is going on doesn't seem wise. It is after all the kind of
paranoia that comes handy when designing constitution-like documents.
(One might argue that a similar problem exists with the leader@d.o
mailbox, and I agree with that. But at least the DPL is subject to
periodic reelections, which is not the case for tech-ctte members.)
As some sort of more positive conclusion, I encourage the tech-ctte to
go ahead with this GR. It is a very important matter on which a vote
should have a final say. But if you want for it some chances of success,
I think you should be more clear on the desire of limiting private
discussions to the very minimum. For one thing, I think "[public]
discussion" in the title of the constitution paragraph should stay.
Similarly, I don't find the usage of "infeasible" and
"counterproductive" reassuring enough. Especially the latter is very
subjective (who decides it?) and might be used to legitimate all sorts
of private discussions.
With many thanks for all the work the tech-ctte is putting in fixing
Constitution "bugs" here in there, it's much appreciated.
Cheers.
[1] for full disclosure, I remind here that I've pleaded guilty for
having done so myself ~24 hours before submitting #658341, asking
for comments on my draft bug report
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
