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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPswKRVdg=mwkc0ezgtafb-s2e_mu++voijws5a1pc...@mail.gmail.com
