On Mon, Jul 16, 2012 at 12:50 PM, Russ Allbery wrote: > Michael Gilbert writes: > >> 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). > > There have been several other (significant) issues besides the Python > maintainership conflict where people have contacted the Technical > Committee in private. I think you're drawing somewhat unwarranted > conclusions.
The goal there is again to preempt potential flamewars, and your next paragraphs below affirms exactly that. So, I feel like I my conclusions are actually on the right track. >> Flamewars are a kind of social problem, and historically the tech >> committee has been very reserved about intervening in those >> situations. > > The goal here is not to intervene in a flamewar; the goal is to be able to > get involved *before* there's a flamewar and try to resolve the underlying > issue before it escalates into a personality conflict. > > Please don't confuse this with the separate question of whether the > tech-ctte should get more involved in social issues. This is an > independent question. The ability to raise an initial question in private > is valuable for technical conflicts with a social component, where the > person raising the technical conflict is concerned that just opening a bug > against tech-ctte will come across as immediate escalation. It can be > very useful to get a sanity check of one's reasoning before taking that > step, as well as assistance in how to word a proposal to be less > confrontational, and that's one of the places where I think this option > will be used. Sure, that's the easy road. Transparency and openness make things hard, but far more in my opinion is gained. From what I can tell, Debian has never been the type organization to lean toward the lowest path of resistance in the past. >> 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. > > If you're a Debian Developer (I forget off-hand if you are), you could > certainly propose that. For the record, I'm strongly opposed, for all the > reasons previously stated in this discussion. I am a DD. You may have missed the most important part of my last message about positively solving these problems via liberal nmus (a DD-only power). Please read that paragraph. It demonstrates an alternative solution already put to use in practice that can resolve maintainership problems without tech committee intervention. So, I would simply like to make a plea to allow us project members to try to solve these problems before hitting them with a big stick. An action item from package hijacking bof was to develop a salvaging procedure, and I would like to propose a solution for that. Since it seems that there is a lot of momentum to push this GR forward, I would like to make a simple request to slow it down a bit. Please initiate the discussion on -project before initiating the GR itself so this can get more visibility and you all can get a better gauge of a larger set of the project's opinion on the matter. Thanks, 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=MPzhK0b1EJ5Mdxi2DRmH0y+mrb6ZjTOfTCxd=+6dxq...@mail.gmail.com
