On Sat, Sep 19, 2009 at 8:48 AM, Alan Burlison <Alan.Burlison at sun.com> wrote:
> A lot of the cases had been published when they shouldn't have been. That's
> not a sufficient justification for continuing to do so.
When I set this all up, I went to a TAC (aka TeamCTO) meeting and
asked GregP (Sun's CTO, and the "boss" of the ARCs) for direction and
advice pertaining to the case archives, ARC review materials and
committee meetings. His immediate verbal answer was (paraphrased)
Just put it all out there. Make it all Googleable.
It is all good engineering discipline that we
should intentionally disclose. There isn't anything
we own in those archives that we really need to
keep secret, especially since we are open-sourcing
much of the software it talks about. For the rest,
well, uhm, we could just let the lawyers duke it out.
No, not really, we need to hold back on things that
are properly marked as confidential or proprietary,
especially in cases where we are discussing other
people's IP or when our documents mention
customer specifics, financial projections or other
sensitive business (not technical) information.
In the following discussion, Greg indicated that the key was
identifying properly protected material without falling into the
semantic analysis trap that AlanB has climbed into - rather than
playing "read the writer's mind" or "be draconian and pessimistic", he
advised that we simply look at what the Sun IP Protection policy
requirements were for labeling and redact any document so labeled.
In addition, he suggested that we remove the sections in our ARC
templates where we asked for information that probably would be
confidential (costs, business justification, revenue forecasts,
release/GA time lines...) - it didn't belong in the ARC materials and
wouldn't be missed. We did, and it wasn't.
> In addition, most of the problems need fixing upstream of the external
> publishing step - for example if a mail to a case log looks like it contains
> confidential information it should be rejected and not be added to the case
> log in the first place.
I assume such filters are already in place on ALL the other existing
os.o aliases that your group maintains, right? Oh, no, can it really
be that these are simply special rules you thought up to apply to the
ARC community that nobody else has to follow?
> Similarly the ARC management tools should do the
> checking an classification processing needed to distinguish between closed
> and open cases.
The ARC tools do that. Each case's IAM file contains an Exposure: tag
that tells the tools and users what state this case is in.
Use of that tag is simple:
If Exposure = "closed" (or is missing), expose the meta-data about the
case, but don't mirror any case material.
if Exposure = "manual", use the special case heuristics documented
elsewhere to figure out what to show. Be pessimistic and assume that
most things may contain proprietary material.
If Exposure = "open", *ANYTHING* submitted to a case and *EVERYTHING*
in the case materials should be published. People that submit bad
stuff should fix it and deal with the consequences, just as if they
were sending email to an external alias or submitting a slide deck to
a conference.
In all these states, except for a simple global safety net (redacting
files or messages that contain exact matches of the required Sun IP
protection notices), the tools should never attempt to read the
submitter's mind or distill the submitters intent via a semantic
analysis of the content.
> Trying to intuit the status of a case based purely on
> processing the case materials after the fact is *always* going to be less
> than satisfactory.
Then don't do that.
I know you disagree and that you have no incentive or motivation to
change your mind. Unfortunately, your attitude is slowly driving away
the external development community here on OS.o.
-John
