Subject: [Codematch-develop] Codematch Call Wed 13 May

From: Christian O'Flaherty <[email-masked]>
Date: Wed, 13 May 2015 14:02:08 -0300

Hi Lisandro, find below the changes to the data model we discussed today:

Add to Codematch table: Creation_date

Add Projects table: Reputation

Change the table name from Specification to Document

Remove Area from Codematch table

The relationship between Projects and Codematch should be many to many

Christian O'Flaherty - [email-masked] <mailto:[email-masked]>
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:  christian.oflaherty 
Phone: +598 98769636

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Fri, 15 May 2015 02:18:34 -0400

Hello Christian

> Add to Codematch table: Creation_date

There’s no Codematch table. I believe you meant Project Container

> Add Projects table: Reputation

Done.

> Change the table name from Specification to Document

Done.

> Remove Area from Codematch table

Done, from the Project Container as above.

> The relationship between Projects and Codematch should be many to many

I didn’t do it yet because I wanted to double-check. To do so, let me “tell” the story of this version.

- A “Code Project” describes a project owned/run by a single user. Each user, however, can be the coder of many project.

- A “Project Container” is a collection of Code Projects. Each container hosts several projects, but each project is linked to a single container. I believe this is where you asked for a many to many relationship, but I think 1 to many is more correct, I guess. 

- A “Project Container” is linked to zero or more documents. Each Document is linked to zero or one container

- A “CodeRequest” is an extended container, adding estimated LoE information. 

Best regards,

Lisandro

---

From: Christian O'Flaherty <[email-masked]>
Date: Fri, 15 May 2015 13:09:08 -0300

Hi Lisandro, 

> There’s no Codematch table. I believe you meant Project Container

On our previous call we decided to change the name to the table that was called “Match”
I thought the name you suggested for that table was Codematch 

Is it “Project_Container” the new name for that main table in the middle of the data model?

> Done, from the Project Container as above.

I assume we’re talking about the same table

> - A “Code Project” describes a project owned/run by a single user. Each user, however, can be the coder of many project.

ok

> - A “Project Container” is a collection of Code Projects. Each container hosts several projects, but each project is linked to a single container. I believe this is where you asked for a many to ma…

I think there are cases where a single project (code) has to use definitions described in more than one document. For example, if you would like to implement and test the current proposals for BGPSEC you will “use" for your code several drafts.

> - A “Project Container” is linked to zero or more documents. Each Document is linked to zero or one container

In the current implementation, the relationship is: A “Project Container” is linked to one document.

I think we should always have at least one document linked.

I’m not sure if we need more than one document linked from the container. I thought the best way to capture the fact that an implementation needed more than one document was on the “Code Project” table referring to several “Project Containers". But I can easily change that if needed.  

Christian

---

From: Christian O'Flaherty <[email-masked]>
Date: Sun, 17 May 2015 17:54:53 -0300

> I’m not sure if we need more than one document linked from the container. I thought the best way to capture the fact that an implementation needed more than one document was on the “Code Project” t…

Lisandro, you’re right: 
“ProjectContainer” is linked to one or more documents because the “creator” for a project container is the author or chair who knows what other documents are related (it may not be only one)

And we will also need a mapping from a single project to several containers because the “coder” is probably implementing several documents (containers) and the creator for that entry is the programmer.

So ProjectContainer to CodingProject is many to many, ProjectContainer to Document is one to many.

Christian

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Sun, 17 May 2015 18:19:50 -0300

Hi Christian

Comments below...

> Em 17/05/2015, à(s) 17:54, Christian O'Flaherty <[email-masked]> escreveu:
> 

Sorry, I missed your other message, but this one I’m replying now.

> So ProjectContainer to CodingProject is many to many, ProjectContainer to Document is one to many.

I understand your point. However, I believe it’s a matter of, let’s say, how the “workflow” of a documento>Request>Implementation is understood. My reading, from all our discussions, is the following:

1) There are several documents (I-Ds, RFCs, etc.) available;

2) Someone (e.g., group chair) needs the development of some code for one or more documents related to one another. The group chair then creates a CodeRequest in the system, linking that request to the document(s) he/she wants someone else to code. A mentor is assigned to this CodeRequest as well. In the current data model, a CodeRequest is materialized by creating a new ProjectContainer as well as a new CodeRequest linked to that container;

3) Developers interested in coding for a specific, advertised CodeRequest associate their projects to that CodeRequest by creating a CodeProject in the data model. Notice however that the set of documents that the new projects will code is inherited from the original CodeRequest (linked in the data model to the code request’s Project Container entry). It means that the set of document is something handled at the Project Container, instead of at the CodeProject.

My understanding is that allowing a single CodeProject to be linked to several ProjectContainers will create confusion. We wanted “comparable” CodeProjects that could related to the same sets of documents. That is achieved by linking these projects to the same ProjectContainer. That’s why I still believe the relationship here is still a many (Code Projects) to 1 (ProjectContainer).

Best regards,

Lisandro

---

From: Christian O'Flaherty <[email-masked]>
Date: Sun, 17 May 2015 19:14:31 -0300

Hi Lisandro,

> 2) Someone (e.g., group chair) needs the development of some code for one or more documents related to one another. The group chair then creates a CodeRequest in the system, linking that request to…

Agree 100%

> 3) Developers interested in coding for a specific, advertised CodeRequest associate their projects to that CodeRequest by creating a CodeProject in the data model. Notice however that the set of do…

This is correct, but the same program can implement something else (not related by the same code request). The table CodeProject will be populated by programers and we don’t want to “limit” their efforts to a single code request and we want to “capture” as much as possible on our database. 

> 
> My understanding is that allowing a single CodeProject to be linked to several ProjectContainers will create confusion.
> We wanted “comparable” CodeProjects that could related to the same sets of documents. That is achieved by linking these projects to the same ProjectContainer. That’s why I still believe the relationship here is still a many (Code Projects) to 1 (ProjectContainer).

We will be able to compare them exactly the same way because that relationship from one CodeProject to several documents is kept. 

I agree that it is confusing (that’s why I suggested to have one to one initially) , but I think those relationships are capturing different information.

Christian

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Sun, 17 May 2015 20:44:25 -0300

Hi Christian

> This is correct, but the same program can implement something else (not related by the same code request). The table CodeProject will be populated by programers and we don’t want to “limit” their e…

If a developer is interested in coding for additional documents, he/she would create new projects and assign those project to appropriate CodeRequests. I understand what you mean by a single project implementing several documents at one, but if those documents are that related, we would expect a CodeRequest to capture that. Still, for example, if I’m a developer having a more generic effort called “Management Stack”, I could still slice it in different projects (e.g., “Management Stack - SNMP”, “Management Stack - IPFIX”, etc.”) to have each of them associated with CodeRequests (in this example, “SNMP”, “IPFIX”, etc.). My point is that we don’t lose information by restricting one CodeProject being associated to a single ProjectContainer; instead, I believe we make it more organized and easier to assist.

Let me propose something. Because I believe that, in any case, the case of having a single project being related to multiple ProjectContainers will be more rare, I suggest keeping this 1 to many relationship for the moment; if, in the future, we see the need for that, we can change the data model based on the feedback we collect from the developers creating their project.

Best regards,

Lisandro

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

---

From: Christian O'Flaherty <[email-masked]>
Date: Mon, 18 May 2015 04:45:09 +0000

Ok. 
Will keep that relationship as it is. 

Sent From Mobile Device
Skype/Yahoo/Google: 
christian.oflaherty
Internet Society 
eMail: [email-masked]
Mobile:  +598 9876 9636

> On 17/5/2015, at 18:44, Lisandro Zambenedetti Granville <[email-masked]> wrote:
> 
> Hi Christian
>