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

[Christian O'Flaherty <[e-mail]>]

Ok. 
Will keep that relationship as it is. 

Sent From Mobile Device
Skype/Yahoo/Google: 
christian.oflaherty
Internet Society 
eMail: [e-mail]
Mobile:  [phone]


> On 17/5/2015, at 18:44, Lisandro Zambenedetti Granville <[e-mail]> wrote:
> 
> Hi Christian
> 
>>> 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.
>> 
>> 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.
> 
> 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
> 
> 
>> 
>>> 
>>> 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 
>> 
>>> 
>>> Best regards,
>>> 
>>> Lisandro
>>> 
>>>>> 
>>>>>> - A “CodeRequest” is an extended container, adding estimated LoE information. 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> <codematchv5.png>
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Lisandro
>> 
>> _______________________________________________
>> Codematch-develop mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/codematch-develop
>