Subject: Re: [Codematch-develop] Codematch-develop Digest, Vol 8, Issue 23

From: Kristin Burgh <[email-masked]>
Date: Mon, 2 Mar 2015 04:07:56 +0000 (UTC)

All - 
I believe our updated Card Sort is ready to go out.
Please let me know if you have any questions regarding the attached - I would like to formally launch this tomorrow (Monday - March 2), so please have any comments, suggestions or updates in to me ASAP.
https://conceptcodify.com/studies/AJDvCQAeNrm9nOO9rwNjsQDc/via/MlU1pQ4sRNefS1iIfsYi4l3a/

In terms of distribution, I believe we had discussed using our respective social networks (e.g. - LinkedIn, Facebook, etc.) to capture survey results.
I'd like to close this survey on Tuesday, March 10 and report the results during the weekly meeting the following day.  I hope that a week and a half will be enough time to allow the developers to make any necessary changes prior to Dallas.
Kind Regards,  Kristin  

      From: "[email-masked]" <[email-masked]>
 To: [email-masked] 
 Sent: Wednesday, February 25, 2015 11:06 AM
 Subject: Codematch-develop Digest, Vol 8, Issue 23
   
----- Forwarded Message -----

Send Codematch-develop mailing list submissions to
    [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/codematch-develop
or, via email, send a message with subject or body 'help' to
    [email-masked]

You can reach the person managing the list at
    [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Codematch-develop digest..."

Today's Topics:

  1. Re: CodeMatch data model v3 (Kathleen Moriarty)
  2. Re: Codematch-develop Digest, Vol 8, Issue 22 (Kristin Burgh)
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:

Hi Lisandro,

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

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

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

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

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

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. 
Or just to have two options for CodeMatches - with or without a CodeRequest.
Thanks!Kathleen 

Christian

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

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

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

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

-- 

Best regards,Kathleen

-- 

Best regards,Kathleen
Good Morning/Afternoon/Evening Everyone - 
I just wanted to let everyone know that I'll be sending out an updated version of the card-sort survey over this coming weekend.  The aim is to be able to have as much feedback from a variety of different users as we can get to help create the best possible prototypes in time for Dallas.
If you have any questions, please feel free to contact me either via this email thread or directly via "[email-masked]".
Also - my apologies to you all - but I'll be about 30 minutes late to today's call/webex due to a scheduling conflict.
Kind Regards, 
Kristin 

      From: "[email-masked]" <[email-masked]>
 To: [email-masked] 
 Sent: Wednesday, February 25, 2015 9:30 AM
 Subject: Codematch-develop Digest, Vol 8, Issue 22
   
----- Forwarded Message -----

Send Codematch-develop mailing list submissions to
    [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/codematch-develop
or, via email, send a message with subject or body 'help' to
    [email-masked]

You can reach the person managing the list at
    [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Codematch-develop digest..."

Today's Topics:

  1. Re: CodeMatch data model v3 (Kathleen Moriarty)
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:

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

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 

Best regards,
Lisandro

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

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.

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

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

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

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. 
Or just to have two options for CodeMatches - with or without a CodeRequest.
Thanks!Kathleen 

Christian

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

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

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

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

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

-- 

Best regards,Kathleen

-- 

Best regards,Kathleen

-- 
Wanderson

-- 

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 2 Mar 2015 10:09:46 -0500

Hi Kristin,

Thanks for your work on the card sort!

I moved around the boxes and wasn't sure what I should put in for all
visitors vs. overview information.  I view them similarly, so it was hard
for me to tell what was meant by each heading.

Also, I didn't have much in the coder bucket as there was no box that said
"My Code Matches".  The mentor owns the code requests, so that wasn't
appropriate for that category.  I also think the mailing list option will
be tough, but maybe we will learn something from that. The tricky part will
be that responses may depend on a persons knowledge of the IETF Trust and
IPR policies as opposed to functionality.  I would have put that one in a
few categories, but for IPR reasons, selected the one that I did.

Thanks,
Kathleen

On Mon, Mar 2, 2015 at 9:54 AM, Moriarty, Kathleen <
[email-masked]> wrote:

>
>
> Sent from my iPhone
>
> Begin forwarded message:
>
>  *From:* Kristin Burgh <[email-masked]>
> *Date:* March 1, 2015 at 11:07:56 PM EST
> *To:* "[email-masked]" <[email-masked]>
> *Subject:* *Re: [Codematch-develop] Codematch-develop Digest, Vol 8,
> Issue 23*
> *Reply-To:* Kristin Burgh <[email-masked]>
>
>     All -
>
>  Please let me know if you have any questions regarding the attached - I
> would like to formally launch this tomorrow (Monday - March 2), so please
> have any comments, suggestions or updates in to me ASAP.
>
>
>  In terms of distribution, I believe we had discussed using our
> respective social networks (e.g. - LinkedIn, Facebook, etc.) to capture
> survey results.
>
>  I'd like to close this survey on Tuesday, March 10 and report the
> results during the weekly meeting the following day.  I hope that a week
> and a half will be enough time to allow the developers to make any
> necessary changes prior to Dallas.
>
>  Kind Regards,
>
>  *Kristin  *
>
>   ------------------------------
> *From:* "[email-masked]" <
> [email-masked]>
> *To:* [email-masked]
> *Sent:* Wednesday, February 25, 2015 11:06 AM
> *Subject:* Codematch-develop Digest, Vol 8, Issue 23
>
>  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).
>
>    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
>
>  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
>
>    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.
>
>  Thanks!
> Kathleen
>  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,
>
>  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
>
>
> Kathleen
> Kathleen
> Kathleen
>  I just wanted to let everyone know that I'll be sending out an updated
> version of the card-sort survey over this coming weekend.  The aim is to be
> able to have as much feedback from a variety of different users as we can
> get to help create the best possible prototypes in time for Dallas.
>
>  If you have any questions, please feel free to contact me either via
> this email thread or directly via "[email-masked]".
>
>  Also - my apologies to you all - but I'll be about 30 minutes late to
> today's call/webex due to a scheduling conflict.
>
>  Kind Regards,
>
>  Kristin
>
>
>
>   ------------------------------
> *From:* "[email-masked]" <
> [email-masked]>
> *To:* [email-masked]
> *Sent:* Wednesday, February 25, 2015 9:30 AM
> *Subject:* Codematch-develop Digest, Vol 8, Issue 22
>
>  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.
>
>  If it is possible, after the Code Sprint such other collaborators could
> send me the tools and manuals about the Codetracker.
>
>  Best regards,
>
> ------------------------------
>  *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
>
>  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
>
>
>
>
>  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.
>
>
> 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.
>
>
>  Thank you,
> Kathleen
>  Thank you,
> 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
>
>    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.
>
>  Thanks!
> Kathleen
>  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,
>
>  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
>
>
> Kathleen
> Kathleen
> Kathleen
> Kathleen

-- 

Best regards,
Kathleen