Re: Draft Charter "Completed"

Yes, I agree that we're understanding each other, more or less, and in fact
pretty much on the same page.  But at the moment I don't know how that
translates into prose.

I'll sleep on it.

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

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