On Thursday, January 12, 2017 02:26:59 PM Sean Whitton wrote:
> Hello,
>
> On Thu, Jan 12, 2017 at 03:11:46AM +0000, Scott Kitterman wrote:
> > 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.
>
> Thank you for your e-mail -- I now understand your objection.
>
> All the other wording in clause 3 is about bug reports against the
> Debian system. The examples that you give are about unresolved issues
> in the Debian project -- disputes between people, rather than problems
> in source and binary packages. I find the line between the Debian
> system and the Debian project to be fairly sharp. I'd be interested to
> hear if you disagree.
>
> The header of clause 3 ("We will not hide problems") admittedly could
> refer to your examples. Would it help if my GR text were amended to
> append "in the Debian system" to the header of the clause?
That then has the opposite problem. It clearly narrows the notion of not
hiding problems and I don't think that's good either.
I'm still at don't monkey with foundational documents to solve non-problems.
Scott K
P.S. I am subscribed. Please don't cc me.Attachment:
signature.asc
Description: This is a digitally signed message part.