Re: Draft Charter "Completed"

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

Received on Wednesday, 7 December 2011 23:22:37 UTC