Re: Draft Charter "Completed"

Quoting from the CLA, " “Contribution” means any original work of
authorship, including any modifications or additions to an existing work,
that I intentionally submit for inclusion in the Specification, and which
Contribution is actually included in the Specification".  To me this
implies that it is not a "contribution" unless it is incorporated in the
specification.  Which to me is along the lines that I was thinking that if
a member submits something that the group does not use, that it is not a
"contribution" and that it need not be published.  Also, it implies to me
that one doesn't know if it is a "contribution" until the deliverable
actually exists.

As I read what you say below, you seem to be agreeing with me that if a
member submits something and then it is substantially modified in the
deliverable that it is not necessary to release the original version to the
public.  I can, of course, understand the need to be able to track things
down internally -- I'm concerned about the publication issue.  And, I
guess, timing.

And -- yes, I guess I think that some things would never become public --
but I suspect that the kinds of things that I am thinking of are not things
that you would expect to be public in the first place.  For example,
suppose a group member demonstrated an application that does certain things
and describes in some technical detail how some of the code works.  Those
descriptions would, assuming that the POC becomes part of a deliverable, in
my view become public.  But it could very easily be that the actual code
could NOT because it runs in a proprietary environment.  There might well
be legal reasons why it could not, since such code would very likely
interact with vendor systems using API's that cannot be made public without
violating contractual requirements.  That's just what comes to the top of
my head -- I'm sure that there are other examples.

The issue here that I am trying to grapple with is that if the group is
working with business processes that use the technology as opposed to the
technology itself, there are very likely to be aspects of the business
processes that are either considered sensitive or on which there are legal
restrictions.

Another rich area of things that cannot be revealed is security.  Suppose
we get involved in issues involving how the technologies work in an actual
corporate secured environment?  We might be able to report publicly aspects
of the technology that cause problems and why, or best practices for
integrating the technology -- but details of how corporate environments are
secured are considered extremely sensitive because the security folks do
not want potential attackers to know what our defenses are.

I just have a pretty strong feeling that anything that actually deals with
business processes is going to have components that might be dealt with on
a confidential basis but cannot be published.

On Wed, Dec 7, 2011 at 5:22 PM, Ian Jacobs <ij@w3.org> wrote:

>
> On 7 Dec 2011, at 5:15 PM, Roger Cutler wrote:
>
> > Contributions:
> >
> > My expectation is that deliverables are public, not contributions per se
> -- because I see the contribution as part of the work process which is not
> public.  For example, if there is a contribution that the group does not
> want to follow up on, I think it can just die. Or if there is a
> contribution that is modified because of the work process, I don't think
> that the original one is relevant.  A more interesting example, as noted in
> my draft, it is possible that a contribution could be something that cannot
> be fully reported without violating proprietary restrictions.
>
> How would it become public at any time then?
>
> >  This could particularly happen if it involved a POC.  I have a
> particular example in mind from Chevron of a POC that could be described
> (should Chevron decide to release it) and demonstrated, but I don't think
> that the code could be released because it operates in a proprietary
> context.
> >
> > However, looking at the CLA again I'm not entirely sure that these
> expectations are compatible with it.  I think that there is a problem here
> that I am thinking of "contributions" in the context of business processes
> or applications whereas the CLA seems to be thinking in terms of
> specifications.
>
> That is correct.
>
> >  However, the issue appears, to my uneducated eye, to be essentially one
> of recognizing IPR.
>
> Yes.
>
> >  I don't know.  Maybe I'm on the wrong track here.  But the mindset I've
> got is that what goes into the work process, which to me includes both
> opinions and more substantive stuff, doesn't need to be made public -- only
> the results.
>
> For IPR reasons we need to know who contributed the stuff that ends up in
> the specification (under the CLA or FSA). If that's recorded somewhere (in
> the mailing lists), then we're fine. The contributions don't have to be
> public prior to appear in the specifications.
>
> >
> > OK, if the BG doesn't have a "Team Contact" what does it have?  It's
> supposed to have staff support, isn't it?  Shouldn't that be explicit?
>
> There are various ways the staff could help support the group:
>
>  * Helping it get started (like I'm doing)
>  * Being invited to a meeting on a technical topic
>  * Being consulted on a process issue
>
> All that's fine and expected (and possibly more). But that's not "ongoing
> staff participation in the work." So I would just drop the line in the
> table.
>
> >
> > Again, you are talking about publishing "specifications".  I think that
> BG's are vanishingly unlikely to publish specs.  Descriptions of processes
> and applications, and possibly technical details, are much more likely.
>  And, I suppose, ontologies, which I suppose is sort of like a spec -- but
> not exactly, I think.
>
> You are probably right. I think we'll have a better understanding when we
> see the deliverables.
>
> Ian
>
> >
> > On Wed, Dec 7, 2011 at 4:38 PM, Ian Jacobs <ij@w3.org> wrote:
> >
> > On 7 Dec 2011, at 10:05 AM, Roger Cutler wrote:
> >
> > > I have roughed out a more-or-less complete draft charter for the Oil,
> Gas and Chemicals Business Group.  Comments and suggestions are most
> welcome, and in fact you can get into the Wiki page and edit it yourself.
>  As previously stated, however, if you do edit the charter it would be
> friendly to send me (and this discussion group) an email indicating in a
> general way "what" was done and if relevant "why".  There is no intention
> at this time to limit your editing -- I just want to be able to keep track
> of what's going on without digging through the change logs.  I say "at this
> time" because I think that the group could decide to define an "editor"
> function that has more control over certain documents, and in fact if we
> start developing deliverable documents I personally think that this might
> turn out to be desirable simply from a logistic point of view.  That's
> pretty much consistent with the way I think most WG's and IG's do things in
> the W3C, and probably with processes in most other collaboration
> environments.  [Ian:  Should this discussion go into the charter?]
> > >
> > > Note that the list of potential topics in the Scope section is pretty
> rough.  Help is particularly requested in this area, which one might
> actually consider the "meatiest" section of the charter.
> > >
> > > The most significant lack is probably in the "Dependencies and
> Liaisons" section.  It seems to me that it might be a good idea to make a
> separate page in the Wiki for this, particularly to document the various
> industry consortia and what kind of connection they have with Semantic Web
> technology.  At the moment, however, I'm tired of typing.
> > >
> > > Note that there is a separate Why Work in This Venue wiki page which
> is linked from the mission section of the charter.
> > >
> > > Ian:  You probably should read this draft fairly carefully.  I have
> included some statements that I think are consistent with W3C process, but
> I'm not positive.  Note particularly the discussion of "Contributions" in
> the Communications section.  I think that this is consistent with the
> spirit of the definition of BG's and CG's, but I was unable to find any
> statements on this that were completely clear to me.  If this section is
> not OK I think we need to work this issue.  I hope it's clear to you what
> my concerns here are.  Note also that I am using the words "contributions"
> and "submissions" pretty much interchangeably, and I'm not sure whether
> that's OK either.
> >
> > Hi Roger,
> >
> > First, thanks for putting this together. Charters are not required by BG
> or CG process, but I think they will be useful. It also helps me to see
> which bits need further explanation, etc.
> >
> > Some notes
> >
> > 1) "Policy with respect to patents and other intellectual property are
> covered by the Contributor License Agreement (CLA).". Please note that
> there are two agreements; the FSA is voluntary but the CLA sets
> expectations about its use.
> >
> > 2) "Here is a rough summary of primary similarities and differences
> between the W3C Patent Policy and the Community Group IPR policies.". I
> don't think that's so useful here. I'm not sure that the audience will be
> existing W3C Members who therefore need help understanding the differences
> from the policy they know.
> >
> > 3) I would therefore propose to just link to the cla, the fsa (final
> spec agreement), faq, and be done with it.
> >
> > 4) I am working on the process for publishing CG/BG specifications. I'm
> happy to tell you about it later; it's not complicated.  There will be UI
> to register a specification; we will display the specification information
> (and link to it wherever it is) on the group's home. And when the group
> publishes a final spec, there will be a form for making final spec
> commitments.
> >
> > 5) The only bit that concerned me is that "contributions" might not be
> public. At some point you will need to make public the group's
> specification (drafts, final version) and they would be public at that
> point. I want to see if you share this expectation:
> >   a) The "date of a contribution" will be the date when it is
> contributed to the group (whether public or not).
> >   b) The "date of inclusion" is when a contribution is actually included
> in a specification (at which point it will be public).
> >
> >  I call out these 2 dates since they are relevant within the CLA.
> >
> > 6) Remove "Team Contact" from the table at the top; BGs don't have Team
> Contacts.
> >
> > Thanks!
> >
> > Ian
> >
> >
> >
> >
> > --
> > Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
> > Tel:                                      +1 718 260 9447
> >
> >
>
> --
> Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
> Tel:                                      +1 718 260 9447
>
>