On January 11, 2017 4:47:30 PM EST, Sean Whitton <spwhit...@spwhitton.name> 
wrote:
>Hello Scott,
>
>On Tue, Jan 10, 2017 at 07:04:02PM -0500, Scott Kitterman wrote:
>> Yes, but all your proposed GR does is move the problem one definition
>> to the right.
>
>I don't follow this objection.  The SC is not meant to contain
>exhaustive details of policies.  At present, though, I think it goes
>too
>far the other way.  This GR is intended to nudge it closer to the right
>level of detail.
I think there is always risk of unintended consequences.  

I don't think the proposed GR solves any problems (at most it substitutes an 
argument about security issues being embargoed at all for an argument about 
what's reasonable - we can be reasonable without a GR).

Here's an example of possible unintended consequences:

Currently we enumerate no specifics about exceptions to when things should be 
public.  Once we have a foundational list of acceptable reasons to not be 
public (security would be the only one), then it's easy to infer that's the 
complete list.

Would this GR prohibit the tech ctte practice of private deliberations about 
recommendations for new members?  I think it might.

I've worked in private with other DDs to resolve disputes within the project.  
Often a quiet conversation out of the public glare can make solutions possible 
that wouldn't happen if all discussion was public.  Does this GR prohibit that? 
 Maybe.

If we need this, do we need this or another GR  to authorize debian-private?

It's a can of worms we don't need to open.

>> Are you aware of any newcomers that have been negatively affected
>this
>> way?
>
>I'm not.  I could imagine it happening to a younger version of myself,
>though.

I think we're better of spending project time and effort on real things that 
need doing and not on imaginary problems.

Scott K

Reply via email to