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.
signature.asc
Description: This is a digitally signed message part.