Re: Draft Charter "Completed"

On 7 Dec 2011, at 5:41 PM, Roger Cutler wrote:

> 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.

That is correct. But the date it is contributed (even before showing up in a spec) is important in the CLA.

>  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.  

That is correct.

> Also, it implies to me that one doesn't know if it is a "contribution" until the deliverable actually exists.

It is a 'potential contributon'. The reason this matters is that there is a 150-day timeout from the _date of contribution_ after which one's obligations dissolve is the contribution is not yet in a specification.

> 
> 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.

Correct.


>  I can, of course, understand the need to be able to track things down internally

Yes.

> -- 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. 

Sounds understandable.

> 
> 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 also understand that point.

> 
> 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. 

I think we are converging on understanding and agreement.

Ian

> 
> 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
> 
> 

--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447

Received on Thursday, 8 December 2011 02:23:11 UTC