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

Re: GR Proposal: Declassification of -private



On Thu, 24 Nov 2005 11:46:55 +1000, Anthony Towns <aj@azure.humbug.org.au> said: 

> On Wed, Nov 23, 2005 at 05:10:11PM -0600, Manoj Srivastava wrote:
>> b) I do not want to be associated with the post in question
>> In other words, if this showed up in google it may hurt my future
>> job prospects post ;-). In this case, the post can be published,
>> just every identifying bit about the author needs be redacted from
>> this post and the quotes.

> That's an interesting point, though it's mitigated by the problem
> that removing identifying information means you need to remove more
> than just the From: and gpg signature -- I mean a "Cheers,\n=="
> would nominally have identifying info redacted, but a pretty clear
> giveaway, and even without anything so obvious, there are fairly
> impressive ways of matching an author to a post just by analysing
> their writing styles these days.

        But these do not show up in a google search by a prospective
 future employer. I do not want to make the perfect an enemy of the
 good. In cases like these, perfect solutions are often intractable,
 but that should not preclude good solutions from being considered.

> Certainly the delegates should be allowed to do the above, and if
> there are posts that someone doesn't mind publishing with a few
> identifying remarks removed it's a good compromise, but I just think
> specifying it now is overthinking the problem, which we should do
> later when we've seen how it actually works in practice.

>> - - requests by the author of a post for that post not to be
>>       published
>> - will be honoured;
>> + - If the author makes a resonable case that some material is
>> + sensitive, then that material is redacted from that post and any
>> + other post where it has been quoted
>> +
>> + - If the author indicates he does not wish to be associated with
>>       a
>> + post, any identifying information is redacted from that post,
>> + and any quotes in subsequent posts, but the rest of the material
>> + is published.

> Removing the quoted material from follow on posts isn't a problem,
> as long as the "Foo said" stuff is anonymised. But if the text later
> says "Yeah, that's great, but you said the opposite in <link to
> message on
-devel> ", they're identified anyway.

>> I Think the proposal above still allows the opportunity for the
>> delegates to make good decisions, while providing them some firmer
>> guidelines in some of the common use cases.

> I think it's a good idea to think through these things now, and pass
> them on to the delegates as guidelines when they're appointed, but
> putting them in the mandate just seems like overkill. If we're
> trusting the authors of -private posts to make good decisions on
> what can and can't be public, can't we trust the future delegates to
> make good decisions on what processes to follow and special cases to
> allow? (And if it turns out we can't, we can definitely overrule
> them)

        Well. The reason I brought these up was that I considered my
 own misgivings about declassification While I do not have  specific
 posts in mind, I have posted a lot in the 8 years or so we have
 archives for, and these two use cases (sensitive meaterial, and not
 wanting to be (easily) identified as author)  are the two that stood
 head and shoulders above the rest.

        While I am not opposed to trusting the judgement of the
 delegates, I would prefer to know, in braod terms, if the common
 cases for wanting mateial not to be declassified would be handled
 correctly, this would greatly increasse my willinglness to support
 this GR unreservedly.

        manoj
 ps: also, given some of the recent shenanigans on -devel, I am not so
 sure I totally trust the judgement of my fellow developers all the
 time, even some delegates -- so a minimal guideline to the delegates
 would make me rest a lot easier.

 pps: Am working on putting the GR pages up on vote.d.o
-- 
When speculation has done its worst, two plus two still equals
four. Johnson
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: