Re: Proposed GR: State exception for security bugs in Social Contract clause 3
On January 11, 2017 4:47:30 PM EST, Sean Whitton <spwhitton@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 to: