Re: Draft GR for permitting private discussion
On Mon, Jul 9, 2012 at 6:57 PM, Ian Jackson wrote:
> I think the key difference between us is this: you seem to be arguing
> that the wording discouraging or limiting the TC's private
> conversations should be normative - that is, that the text should
> somehow say that under some vaguely specified situations, the TC would
> be actually forbidden from having the conversation in private.
>
> Whereas I think that this text should be in <cite> - ie it should be
> rationale and explanation, but not grounds for anyone to assert that
> the TC had somehow violated the constitution and therefore that a
> decision was invalid, or something.
Hi all,
I just finished watching the package hijacking bof video, which helped
cement my understanding of the catalyst driving these changes.
So, I had though these changes originated from the recent python
maintainership conflict, and that was basically confirmed by the bof
discussion. The primary motivation for private discussion stated
there was to be able to preempt potential flamewars (like the python
discussion).
Flamewars are a kind of social problem, and historically the tech
committee has been very reserved about intervening in those
situations. The fact that a constitutional ajustment is under
consideration to rectify said untested issue gives me pause. Its
strikes me as using a hammer to drive a screw, which can work but
causes unintended consequences like irreversible damage to the
underlying structure. And importantly, the finesse of a screwdriver
would have been far more appropriate.
So, anyway, my opinion is that there are ways to positively resolve
such issues without imposing on the tech committee, and without
touching the constitution. 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. Even given all of this, it seems that the
external viewpoint on what was happening was less than positive, as
can be seen by various late complaints to debian-devel about the state
of wine, even though we were in the final stages at that point. So, I
guess what I'm saying is that this approach will seem slow to
outsiders.
So, anyway, after all of that, I would actually rather see this GR go
in the opposite direction and instead uphold the ideal of full
transparency in all works of the tech committee. I am not naive
enough to believe in this cabal idea, but enforcement of transparency
eliminates the ability for project members to even start jumping at
the perception that there is one.
Then, the question is what to do about those pursuing maintainer
changes in a negative manner? I think a kind message from the tech
committee stating that is not appreciated and not appropriate would be
sufficient to reduce said counter-productive messages.
Anyway, I think it would be quite disappointing to alter our ideals
simply due to a very small minority of developers exhibiting
counter-productive behavior.
Best wishes,
Mike
Reply to: