[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: