Re: Draft GR for permitting private discussion
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
Reply to: