Subject: [Codematch-develop] Feedback CodeMatch preliminary data model

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 3 Dec 2014 23:43:43 +0000

Looking through the list archive I was reading:

http://www.ietf.org/mail-archive/web/codematch-develop/current/msg00082.html

>From a tracking perspective, it does make sense to associate a WG chair as the originator of the coding request, but WG chairs can change over time. Taking this into account, it might be better to also associate the coding request with the working group, allowing any current chairs to make updates. This would involve adding an additional entity and association to the model.

I like the idea of associating a codematch with a project and then (for now) a single user with that project. This allows for easy growing room to support more than one user that might want to collaborate on a single codematch without refactoring the data and code too much.

Thanks,
Dave

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 4 Dec 2014 00:02:26 +0000

Thanks for responding on this and bringing the referenced email back to our attention.  The IETF week was kind of busy for me :-)  some responses inline.

Sent from my iPhone

On Dec 3, 2014, at 6:44 PM, "Waltermire, David A." <[email-masked]<mailto:[email-masked]>> wrote:

>From a tracking perspective, it does make sense to associate a WG chair as the originator of the coding request, but WG chairs can change over time. Taking this into account, it might be better to a…

I see where you are coming from, but may have missed an important point Robert raised.  This should be a shepherd to avoid having the WG chairs & IESG as an escalation point.  In addition to that, we will also have individual drafts supported and that could include ones published in the ISE stream.

I'm not sure, but think there may be some confusion here.  The 'project' referenced in Robert's email, responding to Lisandro could be a github project.  I like the way Robert phrased it as we would really be associating a code repository project that implements a draft or standard and the link to the externally stored project could be run by a person or an open source community.  Additionally, it could also be a proprietary project that is a link to a description of that project rather than the open source code repository.  It will be important to allow multiple projects to be associated with the CodeRequest for the CodeMatch.

I think the above was just a matter of getting our new terms down.

Please do share any other thoughts on this or if something is not clear enough in our set of terms.

Thanks,
Kathleen

Thanks,
Dave

_______________________________________________
Codematch-develop mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/codematch-develop

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 4 Dec 2014 00:50:27 +0000

Comments inline below.

From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Wednesday, December 03, 2014 7:02 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [Codematch-develop] Feedback CodeMatch preliminary data model

Sent from my iPhone

>From a tracking perspective, it does make sense to associate a WG chair as the originator of the coding request, but WG chairs can change over time. Taking this into account, it might be better to a…

I see where you are coming from, but may have missed an important point Robert raised.  This should be a shepherd to avoid having the WG chairs & IESG as an escalation point.

[daw: As far as workflow, it looks like WG chairs are the ones issuing "CodingRequests" according the text accompanying the model diagram. Is this still the intent?]

[daw: Secondly, the model from the email I referenced defines two relations between the "CodingRequest" and "User". The first is "Default shepherd" which allows a single shepherd per "CodingRequest" which addresses the point you are making above. The second is "WG chair" which is why I raised my concern. It might be better to associate the "CodingRequest" to the working group. This would be a link to the Group in the datatracker model. Using the "WG Chair" Role in the datatracker, the current WG chairs could then be easily identified for display or access control purposes.]

In addition to that, we will also have individual drafts supported and that could include ones published in the ISE stream.

[daw: I'm not sure how this is handled in the current model. For the "CodingRequest" would the "WG chair" association be to an AD with the individual being the "Default shepherd" in this case? How will this be addressed from a workflow perspective?]
I like the idea of associating a codematch with a project and then (for now) a single user with that project. This allows for easy growing room to support more than one user that might want to collaborate on a single codematch without refactoring the data and code too much.

I'm not sure, but think there may be some confusion here.  The 'project' referenced in Robert's email, responding to Lisandro could be a github project.  I like the way Robert phrased it as we would really be associating a code repository project that implements a draft or standard and the link to the externally stored project could be run by a person or an open source community.

[daw: I'll defer to Robert on this.]

Additionally, it could also be a proprietary project that is a link to a description of that project rather than the open source code repository. It will be important to allow multiple projects to be associated with the CodeRequest for the CodeMatch.

[daw: This is addressed in the current model by associating a "CodeMatch" with a "CodingRequest" as an "Implementation" and a "User" with the same "CodeMatch" as the "Coder". A link to a code repository would be handled as an optional property of the "CodeMatch" for open source projects. Such a link would not be possible for closed source. I would guess an additional optional link to a project website would be useful in either case as well.]

Thanks,
Kathleen

Thanks,
Dave

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 5 Dec 2014 16:40:39 -0500

On Wed, Dec 3, 2014 at 7:50 PM, Waltermire, David A.
<[email-masked]> wrote:
> Thanks for responding on this and bringing the referenced email back to our
> attention.  The IETF week was kind of busy for me :-)  some responses
> inline.
>
> Sent from my iPhone
>
>
> On Dec 3, 2014, at 6:44 PM, "Waltermire, David A."
> <[email-masked]> wrote:
>
> From a tracking perspective, it does make sense to associate a WG chair as
> the originator of the coding request, but WG chairs can change over time.
> Taking this into account, it might be better to also associate the coding
> request with the working group, allowing any current chairs to make updates.
> This would involve adding an additional entity and association to the model.
>
>
>
> I see where you are coming from, but may have missed an important point
> Robert raised.  This should be a shepherd to avoid having the WG chairs &
> IESG as an escalation point.
>
>
>
> [daw: As far as workflow, it looks like WG chairs are the ones issuing
> “CodingRequests” according the text accompanying the model diagram. Is this
> still the intent?]
>

No, this needs to be updated per our discussions.  The intent was to
enable any draft/RFC to have a CodeRequest associated with it, so it
can't be limited to a chair.  This should be a shepherd who may be a
WG chair, but doesn't have to be.  The change is important to support
the intended model (description document).
>
>
> [daw: Secondly, the model from the email I referenced defines two relations
> between the “CodingRequest” and “User”.

Right, from Hawaii, User will be updated to say project as you'll be
associating a coding project with the CodeRequest.  The user, someone
registered with an account in to datatracker will do the association.

The first is “Default shepherd”
> which allows a single shepherd per “CodingRequest” which addresses the point
> you are making above. The second is “WG chair” which is why I raised my
> concern. It might be better to associate the “CodingRequest” to the working
> group.

I'd rather see the coding request associated with the draft or RFCs as
that gives us more flexibility.  The draft and RFCs would be
associated in turn with a WG if the work was done in a WG.

This would be a link to the Group in the datatracker model. Using the
> “WG Chair” Role in the datatracker, the current WG chairs could then be
> easily identified for display or access control purposes.]

You can get to that through the draft.  The chairs may have no
responsibility in regard to CodeMatch, it could be a shepherd that is
not a chair or a shepherd of a non-WG document.

Good points, that data model shared to the list needs some updating.
It may just be that Lisandro didn't get around to it, so hopefully our
discussion is helpful.

>
>
>
> In addition to that, we will also have individual drafts supported and that
> could include ones published in the ISE stream.
>
>
>
> [daw: I’m not sure how this is handled in the current model. For the
> “CodingRequest” would the “WG chair” association be to an AD with the
> individual being the “Default shepherd” in this case? How will this be
> addressed from a workflow perspective?]

Yes, the model needs to be updated, thanks.
>
> I like the idea of associating a codematch with a project and then (for now)
> a single user with that project. This allows for easy growing room to
> support more than one user that might want to collaborate on a single
> codematch without refactoring the data and code too much.
>
>
>
> I'm not sure, but think there may be some confusion here.  The 'project'
> referenced in Robert's email, responding to Lisandro could be a github
> project.  I like the way Robert phrased it as we would really be associating
> a code repository project that implements a draft or standard and the link
> to the externally stored project could be run by a person or an open source
> community.
>
>
>
> [daw: I’ll defer to Robert on this.]
>
>
>
> Additionally, it could also be a proprietary project that is a link to a
> description of that project rather than the open source code repository. It
> will be important to allow multiple projects to be associated with the
> CodeRequest for the CodeMatch.
>
>
>
> [daw: This is addressed in the current model by associating a “CodeMatch”
> with a “CodingRequest” as an “Implementation” and a “User” with the same
> “CodeMatch” as the “Coder”. A link to a code repository would be handled as
> an optional property of the “CodeMatch” for open source projects. Such a
> link would not be possible for closed source. I would guess an additional
> optional link to a project website would be useful in either case as well.]
>

Good point.  Or we name the place the link is included a little
differently to encompass either.  I believe there is a short
description so information about open/closed source should be apparent
from the CodeMatch site before code consumers (or contributors) for
open source might know the difference before clicking through each
option on their site/code repository.

Thanks for the review and helpful feedback.  I think Lisandro wrapped
up his travel and should be catching back up soon.

Best regards,
Kathleen

> [email-masked]
> [email-masked]

-- 

Best regards,
Kathleen