Subject: [Codematch-develop] CodeMatch data model v3

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Sat, 7 Feb 2015 16:24:27 +0800

Dear all

After one of our last meetings, a new data model (v3) for CodeMatch has been defined. Please, find below the new version of such a data model. We tried to incorporate the comments received in the list as well as the suggestions mentioned during the last meetings. Terms in this version are also aligned with the list of terms previously shared by Kathleen in the mailing list. Any feedback is welcomed.

Best regards,

Lisandro

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Feb 2015 10:17:24 -0500

Lisandro,

Thank you for your time and effort developing the data model with the
team!  This looks great from what we discussed.  From additional feedback
received from the IESG, the point was made that you may not always have a
shepherd.  If we want this to also advertise existing implementations (open
source or proprietary) of existing RFCs, there should be flexibility to
demonstrate links between a CodeRequest (in this case an RFC) and a project
without having a mentor.  You would still have a coder or the project owner
that creates the link and it would be possible for others to connect their
project to that same published IETF or IRTF document.

In that case, would the coder then also be connected to the CodeRequest so
there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so they
might only see ones that have a mentor and I'm sure they would want to be
able to restrict their view to the projects they have time to code (1 FTE
for x weeks or months, etc.).

Any other comments?

Thank you,
Kathleen

On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville <
[email-masked]> wrote:

> Dear all
>
> After one of our last meetings, a new data model (v3) for CodeMatch has
> been defined. Please, find below the new version of such a data model. We
> tried to incorporate the comments received in the list as well as the
> suggestions mentioned during the last meetings. Terms in this version are
> also aligned with the list of terms previously shared by Kathleen in the
> mailing list. Any feedback is welcomed.
>
> Best regards,
>
> Lisandro
>
>
> _______________________________________________
> Codematch-develop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codematch-develop
>
>

-- 

Best regards,
Kathleen

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Fri, 13 Feb 2015 12:37:00 +0800

Hello Kathleen

Thanks for the feedback! The absence of a mentor as mentioned by the IESG is interesting and reveal an aspect that in fact we didn’t put much effort on it yet: the life-cycle of a CodeRequest. 

To me, a CodeRequest is an explicit call for FUTURE developments. If someone is questing code, that’s because (additional?) code is required. To help in the development of new code throughout new projects, mentors seem to be mandatory. However, if you want to advertise projects that already finished, mentors make not sense indeed. But consider the following situation: there is a CodeRequest for an specific protocol. That CodeRequest already finds previously finished projects but still requires further code. In that case, the previous projects don’t need a mentor, of course, but the new projects do. But because mentors are associated with CodeRequest (and not with project), once we define a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old projects will always have a mentor once new projects are required.

The whole issue resides in the fact that mentors are associated with CodeRequest. Previously, mentors were associated with individual projects (at that point we were referring projects to as CodeMatches, before the last change in the model). Here, we have some options:

1) Assume that dummy mentors can be associated with CodeRequests that exist only to advertise already finished projects, but we need to live with the idea that once additional code is needed for those CodeRequests, a real mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicating that mentors are optional. However, we may be imposing an administrative burden here.

Another option is checking how we tell the story. The question may be solved if we say that “mentors exist to help in the development of new projects”, implying that already finished projects has now association with current mentors. Too simplistic?

Best regards,

Lisandro

> Em 11/02/2015, à(s) 23:17, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> escreveu:
> 
> Lisandro,
> 
> Thank you for your time and effort developing the data model with the team!  This looks great from what we discussed.  From additional feedback received from the IESG, the point was made that you may not always have a shepherd.  If we want this to also advertise existing implementations (open source or proprietary) of existing RFCs, there should be flexibility to demonstrate links between a CodeRequest (in this case an RFC) and a project without having a mentor.  You would still have a coder or the project owner that creates the link and it would be possible for others to connect their project to that same published IETF or IRTF document.
> 
> In that case, would the coder then also be connected to the CodeRequest so there are multiple ways to make the connections?
> 
> We would need search capabilities for coders looking for projects so they might only see ones that have a mentor and I'm sure they would want to be able to restrict their view to the projects they have time to code (1 FTE for x weeks or months, etc.).
> 
> Any other comments?
> 
> Thank you,
> Kathleen
> 
> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville <[email-masked] <mailto:[email-masked]>> wrote:
> Dear all
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/codematch-develop <https://www.ietf.org/mailman/listinfo/codematch-develop>
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Christian O'Flaherty <[email-masked]>
Date: Fri, 13 Feb 2015 14:12:32 -0200

Hi Kathleen, 

> To me, a CodeRequest is an explicit call for FUTURE developments. If someone is questing code, that’s because (additional?) code is required. To help in the development of new code throughout new projects, mentors seem to be mandatory.

I agree with Lisandro's reasoning. If there's a code-match, it's because someone did a code request. Someone needed that code and he will get the appropriate "coding" help if the student has some support to do that work.

We can have a different instance for those cases were there is no request, thereby no need to provide a shepherd. They could be just "code opportunity" and there's no commitment from anyone for those code-matches.

> However, if you want to advertise projects that already finished, mentors make not sense indeed. But consider the following situation: there is a CodeRequest for an specific protocol. That CodeRequest already finds previously finished projects but still requires further code. In that case, the previous projects don’t need a mentor, of course, but the new projects do. But because mentors are associated with CodeRequest (and not with project), once we define a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old projects will always have a mentor once new projects are required.
> 

A third option could be to have active "code-requests" with mentors and "code-opportunities" (or a better name) for finished projects, other  RFCs, etc. with no mentor. 

Christian

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Sat, 14 Feb 2015 08:22:12 -0200

Dear all

I’m sending this message to let you know about a new version of the prototype pages for CodeMatch. The new version is available at:

http://codematch.inf.ufrgs.br <http://codematch.inf.ufrgs.br/> 

Prototype pages complement the mockups that we have been discussing by incorporating more visual elements that mockups don’t capture. Mockups is still our primary material for discussions, but prototype pages help us to check the visual aspects. That also complements Kristin’s work!

Don’t be too worry if these prototype pages are not 100% synchronized with the mockups (it’s easy to change a mockup than a page), that’s natural. Still, you can provide your feedback for the visual aspects already.

These prototype pages have been voluntarily created by Wanderson Paim de Jesus (cc’ed in this message). I wanted to explicitly acknowledge that and thank Wanderson for his help.

Best regards,

Lisandro

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Sat, 14 Feb 2015 16:52:37 +0000

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kathleen,

Good point.

In looking at the data model again, how about having the CodeMatch either be a fulfilled CodeRequest mapping a project to a specification or simply the connection between a project and specification.  This let's us keep the terms and model simple which may be easier for users as they will have less to understand in terms of our terminology.  Also keeping the data model simpler should help reduce coding efforts.

However, if you want to advertise projects that already finished, mentors make not sense indeed. But consider the following situation: there is a CodeRequest for an specific protocol. That CodeRequest already finds previously finished projects but still requires further code. In that case, the previous projects don’t need a mentor, of course, but the new projects do. But because mentors are associated with CodeRequest (and not with project), once we define a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old projects will always have a mentor once new projects are required.
If the link is to the same draft, but I suspect this will happen more with draft revisions or drafts that extend base specifications.

Yes, you are correct and I think my updated suggestion fixes this, but let me know if I missed anything.

A third option could be to have active "code-requests" with mentors and "code-opportunities" (or a better name) for finished projects, other  RFCs, etc. with no mentor.
Or just to have two options for CodeMatches - with or without a CodeRequest.

Thanks!
Kathleen

Christian

Best regards,

Lisandro

Em 11/02/2015, à(s) 23:17, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> escreveu:

Lisandro,

Any other comments?

Thank you,
Kathleen

On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville <[email-masked]<mailto:[email-masked]>> wrote:
Dear all

Best regards,

Lisandro

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

--

Best regards,
Kathleen

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

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

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Tue, 17 Feb 2015 10:05:05 -0200

Hello Kathleen

I’m not an expert on data models, so I may be wrong. Today, CodeMatch is a relationship between Project and CodeRequest. I believe it is not possible to have another relationship between Project and Specification named CodeMatch too. But let me ask you if you agree with the suggestion of “fixing” this issue by saying that “a Mentor is the person responsible for helping in the development of active projects”, implying that mentors have no role in already finished projects? In that way, we don’t need to change the data model. Not that we could not change it, but I believe keeping it simple is important.

Best regards,

Lisandro

> Em 14/02/2015, à(s) 14:52, Moriarty, Kathleen <[email-masked]> escreveu:
> 
> Hi,
> 
> Sent from my iPhone
> 
> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Kathleen, 
>>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 17 Feb 2015 12:31:13 +0000

Hi Lisandro,

That accomplishes the same goals and sounds good to me.  What does the updated data model look like?

I have a planning call with the IESG at the same time as our call tomorrow, so I'll have to miss it.  Should we find another time that works this week?

Thank you,
Kathleen

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <[email-masked]<mailto:[email-masked]>> wrote:

Hello Kathleen

Best regards,

Lisandro

Em 14/02/2015, à(s) 14:52, Moriarty, Kathleen <[email-masked]<mailto:[email-masked]>> escreveu:

Hi,

Sent from my iPhone

Hi Kathleen,

Good point.

Thanks!
Kathleen

Christian

Best regards,

Lisandro

Lisandro,

Any other comments?

Thank you,
Kathleen

Best regards,

Lisandro

--

Best regards,
Kathleen

---

From: Christian O'Flaherty <[email-masked]>
Date: Tue, 17 Feb 2015 12:54:15 +0000

That accomplishes the same goals and sounds good to me.

+1

What does the updated data model look like?

Or We can skip this week's call. We're making progress by email.

Christian

Thank you,
Kathleen

Sent from my iPhone

Hello Kathleen

Best regards,

Lisandro

Hi,

Sent from my iPhone

Hi Kathleen,

Good point.

Thanks!
Kathleen

Christian

Best regards,

Lisandro

Lisandro,

Any other comments?

Thank you,
Kathleen

Best regards,

Lisandro

--

Best regards,
Kathleen

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 17 Feb 2015 15:16:56 +0000

Sent from my iPhone

On Feb 17, 2015, at 7:54 AM, "Christian O'Flaherty" <[email-masked]<mailto:[email-masked]>> wrote:

+1

That's fine with me.

This week we need to work on Kristin's results to see when we start getting volunteers to do the online card sort, data model reviews, and start prepping for Dallas.

I have a couple more volunteers for coding as well lined up.  There may be more decisions to be made for that and prep for developers to get familiar with the datatracker and how it will be accessed.

Thank you,
Kathleen

Christian

Thank you,
Kathleen

Sent from my iPhone

Hello Kathleen

Best regards,

Lisandro

Hi,

Sent from my iPhone

Hi Kathleen,

Good point.

Thanks!
Kathleen

Christian

Best regards,

Lisandro

Lisandro,

Any other comments?

Thank you,
Kathleen

Best regards,

Lisandro

--

Best regards,
Kathleen

---

From: Christian O'Flaherty <[email-masked]>
Date: Tue, 17 Feb 2015 17:19:15 +0000

Although I never used datatracker as a coder I would like to be among the initial volunteers for coding.

Christian

Thank you,
Kathleen

Christian

Thank you,
Kathleen

Sent from my iPhone

Hello Kathleen

Best regards,

Lisandro

Hi,

Sent from my iPhone

Hi Kathleen,

Good point.

Thanks!
Kathleen

Christian

Best regards,

Lisandro

Lisandro,

Any other comments?

Thank you,
Kathleen

Best regards,

Lisandro

--

Best regards,
Kathleen

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 17 Feb 2015 18:01:04 +0000

Sent from my iPhone

On Feb 17, 2015, at 12:19 PM, "Christian O'Flaherty" <[email-masked]<mailto:[email-masked]>> wrote:

That's great, thank you Christian!

Christian

Thank you,
Kathleen

Christian

Thank you,
Kathleen

Sent from my iPhone

Hello Kathleen

Best regards,

Lisandro

Hi,

Sent from my iPhone

Hi Kathleen,

Good point.

Thanks!
Kathleen

Christian

Best regards,

Lisandro

Lisandro,

Any other comments?

Thank you,
Kathleen

Best regards,

Lisandro

--

Best regards,
Kathleen

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Fri, 20 Feb 2015 09:18:16 -0200

Hello Kathleen

> That accomplishes the same goals and sounds good to me.  What does the updated data model look like?

In this case, the data model remains the same, since the “solution” resides on the semantics of mentor, i.e., the person responsible for helping in current and new projects. Do you want me to send the data model again?

Regards,

Lisandro

ps.: It took me a while to reply given the recent carnaval break in Brazil

> Sent from my iPhone
> 
> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hello Kathleen
>> 
>>> Em 14/02/2015, à(s) 14:52, Moriarty, Kathleen <[email-masked] <mailto:[email-masked]>> escreveu:
>>> 
>>> Hi,
>>> 
>>> Sent from my iPhone
>>>

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Fri, 20 Feb 2015 09:23:20 -0200

Dear all

Wanderson Paim (cc’ed in this message), who develop the prototype available at http://codematch.inf.ufrgs.br <http://codematch.inf.ufrgs.br/> is also a volunteer to code the CodeMatch backend.

Best regards,

Lisandro

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 10:23:51 -0500

On Fri, Feb 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville <
[email-masked]> wrote:

> Dear all
>
> Wanderson Paim (cc’ed in this message), who develop the prototype
> available at http://codematch.inf.ufrgs.br is also a volunteer to code
> the CodeMatch backend.
>

Excellent, it's great to have you on the team Wanderson!  Thank you for
volunteering!

Best regards,
Kathleen

>  I have a couple more volunteers for coding as well lined up.  There may
> be more decisions to be made for that and prep for developers to get
> familiar with the datatracker and how it will be accessed.
>
>
> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <
>  I’m not an expert on data models, so I may be wrong. Today, CodeMatch is
> a relationship between Project and CodeRequest. I believe it is not
> possible to have another relationship between Project and Specification
> named CodeMatch too. But let me ask you if you agree with the suggestion of
> “fixing” this issue by saying that “a Mentor is the person responsible for
> helping in the development of active projects”, implying that mentors have
> no role in already finished projects? In that way, we don’t need to change
> the data model. Not that we could not change it, but I believe keeping it
> simple is important.
>
>  Best regards,
>
>  Lisandro
>
> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <[email-masked]>
> wrote:
>
>  Hi Kathleen,
>
>    To me, a CodeRequest is an explicit call for FUTURE developments. If
> someone is questing code, that’s because (additional?) code is required. To
> help in the development of new code throughout new projects, mentors seem
> to be mandatory.
>
>
>  I agree with Lisandro's reasoning. If there's a code-match, it's because
> someone did a code request. Someone needed that code and he will get the
> appropriate "coding" help if the student has some support to do that work.
>
>
>  Good point.
>
>
>  We can have a different instance for those cases were there is no
> request, thereby no need to provide a shepherd. They could be just "code
> opportunity" and there's no commitment from anyone for those code-matches.
>
>
>  In looking at the data model again, how about having the CodeMatch either
> be a fulfilled CodeRequest mapping a project to a specification or simply
> the connection between a project and specification.  This let's us keep the
> terms and model simple which may be easier for users as they will have less
> to understand in terms of our terminology.  Also keeping the data model
> simpler should help reduce coding efforts.
>
>
>
>
>   However, if you want to advertise projects that already finished,
> mentors make not sense indeed. But consider the following situation: there
> is a CodeRequest for an specific protocol. That CodeRequest already finds
> previously finished projects but still requires further code. In that case,
> the previous projects don’t need a mentor, of course, but the new projects
> do. But because mentors are associated with CodeRequest (and not with
> project), once we define a mentor to help in the new projects that mentor
> will be also linked with the old projects too. In summary, old projects
> will always have a mentor once new projects are required.
>
>   If the link is to the same draft, but I suspect this will happen more
> with draft revisions or drafts that extend base specifications.
>
>
>  The whole issue resides in the fact that mentors are associated with
> CodeRequest. Previously, mentors were associated with individual projects
> (at that point we were referring projects to as CodeMatches, before the
> last change in the model). Here, we have some options:
>
>
>  1) Assume that dummy mentors can be associated with CodeRequests that
> exist only to advertise already finished projects, but we need to live with
> the idea that once additional code is needed for those CodeRequests, a real
> mentor will be assigned, and the finished project will inherit that new
> real mentor.
>
>  2) Rollback the model back to associate mentors with projects,
> indicating that mentors are optional. However, we may be imposing an
> administrative burden here.
>
>
>  A third option could be to have active "code-requests" with mentors and
> "code-opportunities" (or a better name) for finished projects, other  RFCs,
> etc. with no mentor.
>
>  Another option is checking how we tell the story. The question may be
> solved if we say that “mentors exist to help in the development of new
> projects”, implying that already finished projects has now association with
> current mentors. Too simplistic?
>
>  Best regards,
>
>  Lisandro
>
>  Em 11/02/2015, à(s) 23:17, Kathleen Moriarty <
> [email-masked]> escreveu:
>
>  Lisandro,
>
>  In that case, would the coder then also be connected to the CodeRequest
> so there are multiple ways to make the connections?
>
>  We would need search capabilities for coders looking for projects so
> they might only see ones that have a mentor and I'm sure they would want to
> be able to restrict their view to the projects they have time to code (1
> FTE for x weeks or months, etc.).
>
>  Any other comments?
>
>  Thank you,
> Kathleen
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 10:26:02 -0500

Hi Lisandro.

On Fri, Feb 20, 2015 at 6:18 AM, Lisandro Zambenedetti Granville <
[email-masked]> wrote:

> In this case, the data model remains the same, since the “solution”
> resides on the semantics of mentor, i.e., the person responsible for
> helping in current and new projects. Do you want me to send the data model
> again?
>

That sounds good if that is the case as simpler is better.  When I look at
the data model, it appears that the Project requires a CodeRequest that
connects it to the specification, but maybe I'm reading it incorrectly.  So
if you can explain how we can have these two possibilities in the current
data model, that would help me before we go forward.

Thank you!

-- 

Best regards,
Kathleen

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Sun, 22 Feb 2015 18:54:10 +0000

Hello Kathleen

> That sounds good if that is the case as simpler is better.  When I look at the data model, it appears that the Project requires a CodeRequest that connects it to the specification, but maybe I'm reading it incorrectly.  So if you can explain how we can have these two possibilities in the current data model, that would help me before we go forward.

A CodeRequest is a container for projects that both (a) are developing new code now and (b) have developed code in the past. For (a), mentors are important; for (b), mentors make not difference. If you have one or more projects from the past ( as in (b) ) to connect to the same specification, you’ll need a CodeRequest to link those project to that specification. 

You asked how we can have the two possibilities in the current data model. The data model itself has no specific structures for both possibilities, but that’s why I mentioned that it resides in the semantics we assign to mentors, since CodeRequest would be there anyway, to link either new or old projects to specifications.

If thinks are still not clear, I can try to provide examples.

Regards,

Lisandro

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 22 Feb 2015 15:30:51 -0500

Sent from my iPhone

> On Feb 22, 2015, at 1:54 PM, Lisandro Zambenedetti Granville <[email-masked]> wrote:
> 
> Hello Kathleen
> 
I think an explanation along with the data model will be necessary if no line is included to show the code request isn't needed to link a project to a specification.  That and examples will help developers as we proceed.

Thanks,
Kathleen

>>>> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <[email-masked]> wrote:
>>>> 
>>>>> Hello Kathleen
>>>>> 
>>>>>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <[email-masked]> wrote:
>>>>>> 
>>>>>>> Hi Kathleen, 
>>>>>>> 
>>>>>>>>> Em 11/02/2015, à(s) 23:17, Kathleen Moriarty <[email-masked]> escreveu:
>>>>>>>>> 
>>>>>>>>> Lisandro,
>>>>>>>>> 
>>>>>>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville <[email-masked]> wrote:
>>>>>>>>>> Dear all
>>>>>>>>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 23 Feb 2015 09:46:59 -0500

Wanderson,

We are glad to have your assistance!

Dave Waltermire has also volunteered to help code and we may have 1-2 other
volunteers soon.  If anyone is attending the IETF in Dallas and will be
able to help us code, it may be a good idea to go to the Code Sprint
Saturday before the meeting as you'll get the tools to install and learn
more about the datatracker.  Please let me know if you need more
information on the Code Sprint.

Thank you,
Kathleen

On Mon, Feb 23, 2015 at 7:14 AM, Wanderson Paim de Jesus <
[email-masked]> wrote:

> Hi Kathleen,
>
> I find Codematch a good idea and hope being able to contribute with its
> success.
>
> Christian seems to be interest in coding too. Given that I'm not familiar
> with datatracker, his support would be honestly welcome.
>
> Best regards,
>
> Wanderson
>
> ------------------------------
> *De: *"Kathleen Moriarty" <[email-masked]>
> *Para: *"Lisandro Zambenedetti Granville" <[email-masked]>
> *Cc: *"Christian O'Flaherty" <[email-masked]>, "Kathleen Moriarty" <
> [email-masked]>, [email-masked], "Wanderson Paim
> de Jesus" <[email-masked]>
> *Enviadas: *Sexta-feira, 20 de fevereiro de 2015 13:23:51
> *Assunto: *Re: [Codematch-develop] CodeMatch data model v3
>
>
>
>
>>  I’m not an expert on data models, so I may be wrong. Today, CodeMatch
>> is a relationship between Project and CodeRequest. I believe it is not
>>  I agree with Lisandro's reasoning. If there's a code-match, it's
>> because someone did a code request. Someone needed that code and he will
>> get the appropriate "coding" help if the student has some support to do
>> that work.
>>
>>
>>  Good point.
>>
>>
>>  In looking at the data model again, how about having the CodeMatch
>> either be a fulfilled CodeRequest mapping a project to a specification or
>> simply the connection between a project and specification.  This let's us
>> keep the terms and model simple which may be easier for users as they will
>> have less to understand in terms of our terminology.  Also keeping the data
>> model simpler should help reduce coding efforts.
>>
>>
>>
>>
>>>  After one of our last meetings, a new data model (v3) for CodeMatch
>>> has been defined. Please, find below the new version of such a data model.
>>> We tried to incorporate the comments received in the list as well as the

-- 

Best regards,
Kathleen

---

From: Wanderson Paim de Jesus <[email-masked]>
Date: Mon, 23 Feb 2015 09:14:42 -0300 (BRT)

Hi Kathleen, 

I find Codematch a good idea and hope being able to contribute with its success. 

Christian seems to be interest in coding too. Given that I'm not familiar with datatracker, his support would be honestly welcome. 

Best regards, 

Wanderson 

----- Mensagem original -----

De: "Kathleen Moriarty" <[email-masked]> 
Para: "Lisandro Zambenedetti Granville" <[email-masked]> 
Cc: "Christian O'Flaherty" <[email-masked]>, "Kathleen Moriarty" <[email-masked]>, [email-masked], "Wanderson Paim de Jesus" <[email-masked]> 
Enviadas: Sexta-feira, 20 de fevereiro de 2015 13:23:51 
Assunto: Re: [Codematch-develop] CodeMatch data model v3 

On Fri, Feb 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville < [email-masked] > wrote: 

Dear all 

Wanderson Paim (cc’ed in this message), who develop the prototype available at http://codematch.inf.ufrgs.br is also a volunteer to code the CodeMatch backend. 

Excellent, it's great to have you on the team Wanderson! Thank you for volunteering! 

Best regards, 
Kathleen 
<blockquote>

Best regards, 

Lisandro 

<blockquote>

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

<blockquote>

</blockquote>

Christian 

<blockquote>

Thank you, 
Kathleen 

<blockquote>

Christian 

<blockquote>

Thank you, 
Kathleen 

Sent from my iPhone 

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" < [email-masked] > wrote: 

<blockquote>

Hello Kathleen 

Best regards, 

Lisandro 

<blockquote>

Em 14/02/2015, à(s) 14:52, Moriarty, Kathleen < [email-masked] > escreveu: 

Hi, 

Sent from my iPhone 

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" < [email-masked] > wrote: 

<blockquote>

Hi Kathleen, 

<blockquote>

</blockquote>

</blockquote>

Good point. 
<blockquote>

</blockquote>

<blockquote>

<blockquote>

</blockquote>

</blockquote>

<blockquote>

<blockquote>

</blockquote>

</blockquote>

<blockquote>

<blockquote>

</blockquote>

</blockquote>

Thanks! 
Kathleen 

<blockquote>

Christian 

<blockquote>

Best regards, 

Lisandro 

<blockquote>

Em 11/02/2015, à(s) 23:17, Kathleen Moriarty < [email-masked] > escreveu: 

Lisandro, 

Any other comments? 

Thank you, 
Kathleen 

On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville < [email-masked] > wrote: 

<blockquote>

Dear all 

Best regards, 

Lisandro 

</blockquote>

-- 

Best regards, 
Kathleen 
</blockquote>

</blockquote>

</blockquote>

<blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

<blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

-- 

Best regards, 
Kathleen

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Tue, 24 Feb 2015 10:41:28 +0000

Hello Kathleen

Just to clarify: a CodeRequest is still needed to link projects to a specification. The data model is not missing a link between projects and specifications; projects are are linked to specifications only through a CodeRequest. What we have discussed so far is that the mentor field in the CodeRequest is only meaningful for active projects, since already finished projects don’t need a mentor anymore.

Best regards,

Lisandro

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 24 Feb 2015 21:15:29 +0000

Hi Lisandro,

Sent from my iPhone

On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" <[email-masked]<mailto:[email-masked]>> wrote:

Hello Kathleen

Let's chat about this tomorrow as I still don't see why a direct connection between a project and specification can't be made.  Maybe it's to have a grouping, but I'd like to talk through this a bit.  If you have an example for tomorrow, that may help.

Thank you,
Kathleen

Best regards,

Lisandro

Sent from my iPhone

Hello Kathleen

Best regards,

Lisandro

Hi,

Sent from my iPhone

Hi Kathleen,

Good point.

Thanks!
Kathleen

Christian

Best regards,

Lisandro

Lisandro,

Any other comments?

Thank you,
Kathleen

Best regards,

Lisandro

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Wed, 25 Feb 2015 12:18:48 +0000

Hi Kathleen

Thanks, that’s perfect. But just confirming. The meeting will be tomorrow or today? I thought it was today, but I may be wrong.

Best regards,

Lisandro

> Em 24/02/2015, à(s) 21:15, Moriarty, Kathleen <[email-masked]> escreveu:
> 
> Hi Lisandro,
> 
> Sent from my iPhone
> 
> On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Feb 2015 07:36:49 -0500

Hi Lisandro,

The meeting is today, I sent my message on Tuesday.

Thank you,
Kathleen 

Sent from my iPhone

> On Feb 25, 2015, at 7:18 AM, Lisandro Zambenedetti Granville <[email-masked]> wrote:
> 
> Hi Kathleen
> 
>> On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" <[email-masked]> wrote:
>>

---

From: Wanderson Paim de Jesus <[email-masked]>
Date: Tue, 24 Feb 2015 21:11:19 -0300 (BRT)

Dear Kathleen, 

I'm afraid saying, but I had not planned attending the IETF in Dallas and I'm not aware about Code Sprint. 

If it is possible, after the Code Sprint such other collaborators could send me the tools and manuals about the Codetracker. 

Best regards, 

----- Mensagem original -----

De: "Kathleen Moriarty" <[email-masked]> 
Para: "Wanderson Paim de Jesus" <[email-masked]> 
Cc: "Christian O'Flaherty" <[email-masked]>, "Kathleen Moriarty" <[email-masked]>, [email-masked], "Lisandro Zambenedetti Granville" <[email-masked]> 
Enviadas: Segunda-feira, 23 de fevereiro de 2015 11:46:59 
Assunto: Re: [Codematch-develop] CodeMatch data model v3 

Wanderson, 

Dave Waltermire has also volunteered to help code and we may have 1-2 other volunteers soon. If anyone is attending the IETF in Dallas and will be able to help us code, it may be a good idea to go to the Code Sprint Saturday before the meeting as you'll get the tools to install and learn more about the datatracker. Please let me know if you need more information on the Code Sprint. 

Thank you, 
Kathleen 

On Mon, Feb 23, 2015 at 7:14 AM, Wanderson Paim de Jesus < [email-masked] > wrote: 

Hi Kathleen, 

Best regards, 

Wanderson 

De: "Kathleen Moriarty" < [email-masked] > 
Para: "Lisandro Zambenedetti Granville" < [email-masked] > 
Cc: "Christian O'Flaherty" < [email-masked] >, "Kathleen Moriarty" < [email-masked] >, [email-masked] , "Wanderson Paim de Jesus" < [email-masked] > 
Enviadas: Sexta-feira, 20 de fevereiro de 2015 13:23:51 
Assunto: Re: [Codematch-develop] CodeMatch data model v3 

<blockquote>

Dear all 

Best regards, 
Kathleen 
<blockquote>

Best regards, 

Lisandro 

<blockquote>

<blockquote>

Christian 

<blockquote>

Thank you, 
Kathleen 

<blockquote>

Christian 

<blockquote>

Thank you, 
Kathleen 

Sent from my iPhone 

<blockquote>

Hello Kathleen 

Best regards, 

Lisandro 

<blockquote>

Hi, 

Sent from my iPhone 

<blockquote>

Hi Kathleen, 

<blockquote>

Good point. 
<blockquote>

<blockquote>

<blockquote>

</blockquote>

<blockquote>

<blockquote>

</blockquote>

<blockquote>

<blockquote>

Thanks! 
Kathleen 

<blockquote>

Christian 

<blockquote>

Best regards, 

Lisandro 

<blockquote>

Lisandro, 

Any other comments? 

Thank you, 
Kathleen 

<blockquote>

Dear all 

Best regards, 

Lisandro 

</blockquote>

-- 

Best regards, 
Kathleen 
</blockquote>

</blockquote>

</blockquote>

<blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

<blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

</blockquote>

-- 

Best regards, 
Kathleen 

</blockquote>

-- 

Best regards, 
Kathleen 

-- 

Wanderson

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Feb 2015 09:29:52 -0500

Dear Wanderson,

Yes, I am sure we will be able to help you and other volunteer developers
figure out how to get started and to work as a team without having to
attend Dallas.

Thank you.

On Tue, Feb 24, 2015 at 7:11 PM, Wanderson Paim de Jesus <
[email-masked]> wrote:

> If it is possible, after the Code Sprint such other collaborators could
> send me the tools and manuals about the Codetracker.
>
> Best regards,
>
> *Para: *"Wanderson Paim de Jesus" <[email-masked]>
> [email-masked]>, [email-masked], "Lisandro
> Zambenedetti Granville" <[email-masked]>
> *Enviadas: *Segunda-feira, 23 de fevereiro de 2015 11:46:59
>
> Dave Waltermire has also volunteered to help code and we may have 1-2
> other volunteers soon.  If anyone is attending the IETF in Dallas and will
> be able to help us code, it may be a good idea to go to the Code Sprint
>>>  I have a couple more volunteers for coding as well lined up.  There
>>> may be more decisions to be made for that and prep for developers to get
>>>  A third option could be to have active "code-requests" with mentors
>>> and "code-opportunities" (or a better name) for finished projects, other
>>>  RFCs, etc. with no mentor.
>>>
>>>  In that case, would the coder then also be connected to the
>>> CodeRequest so there are multiple ways to make the connections?
>>>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Feb 2015 10:18:51 -0500

Hi Lisandro,

I reached out to Pete Resnick, one of the Apps directors to see what he
thought.

He does agree that something is missing.

I think we can handle this in a few ways.  We need to be able to
differentiate when code is requested from when a link is being made as the
information on each will be different.

The data model would need a few elements to be optional, like mentor,
resources (estimated level of effort for coding).  You usually see this
when there is accompanying UML.

Pete suggested a different name for CodeRequest, maybe MatchRequest with an
element for CodeRequest?  If we keep it at CodeRequest, I think minimally
an attribute to designate if code is actually requested would be necessary
- or we change this to MatchRequest with an attribute called CodeRequest as
a boolean (yes/no - for our team members that are not data model savvy).

Just some thoughts so the data model would be clear...

On Tue, Feb 24, 2015 at 4:15 PM, Moriarty, Kathleen <
[email-masked]> wrote:

>    I think an explanation along with the data model will be necessary if
> no line is included to show the code request isn't needed to link a project
> to a specification.  That and examples will help developers as we proceed.
>
>
>  Hello Kathleen
>
>  Just to clarify: a CodeRequest is still needed to link projects to a
> specification. The data model is not missing a link between projects and
> specifications; projects are are linked to specifications only through a
> CodeRequest. What we have discussed so far is that the mentor field in the
> CodeRequest is only meaningful for active projects, since already finished
> projects don’t need a mentor anymore.
>
>   Let's chat about this tomorrow as I still don't see why a direct
> connection between a project and specification can't be made.  Maybe it's
> to have a grouping, but I'd like to talk through this a bit.  If you have
> an example for tomorrow, that may help.
>
>  Thank you,
> Kathleen
>
>   Best regards,
>
>  Lisandro
>
>            Sent from my iPhone
>>

-- 

Best regards,
Kathleen