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

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 9 Dec 2014 10:39:14 -0500

Hello,

Thanks Lisandro for putting together a proposed data model and Robert for
your guidance.  Some comments/questions are inline.

On Mon, Nov 17, 2014 at 4:49 PM, Robert Sparks <[email-masked]> wrote:

>  Thanks Lisandro.
>
> What you have here is mostly the relationships between objects - lets
> capture here what should live _in_ those objects as well.
>
> Several questions inline.
>
> On 11/13/14 5:58 PM, Lisandro Zambenedetti Granville wrote:
>
> Dear Robert, dear Henrik (cc CodeMatch mailing list)
>
>  As promised, please find attached a preliminary data model that we’ve
> scratched considering the current observation of the planned CodeMatch
> site. This preliminary version compiled the work developed so far and
> feedbacks we’ve collected along this week here in IETF 91. It’s a very
> initial model but I believe it’s also an important starting point. Let me
> try to explain it linking with the system’s functionalities.
>
>
>  - CodingRequests are issued WG chairs (User).
>
> So what's in this? Is it a text description written by the chair?
> The mockups also suggest there are some "Resources" that are stored here
> (from our conversations, these are probably name:value pairs where the
> value often looks like a URL?) You probably want to keep when it was
> issued. Is there any other data (any deadlines, any other state) that
> should be kept?
>
> By assuming chairs, you are limiting the use of this to WG activities (I
> understand you are using WG as a short hand for IETF or IRTF groups for the
> moment). Specifically, you won't be able to issue a codematch against an
> individual submission document, such as rfc6032 (either now, or when it was
> just an I-D).
>

As mentioned in the overview materials and my later response to Dave, this
role can be any individual so that we are not limited to chairs as the only
ones to issue CodeRequests.  Authors of individual standards require this
as well.  I think the best approach is to have this be the responsibility
of the shepherd.  This also abstracts this away from the WG.  Since the
draft(s)/RFC will be part of the request, there will be a path through the
datatracker back to the WG anyway.

>  One CodingRequest may have one or more WG chair.
>
> Why allow more than one?
> This is probably something like draft-shepherds. What would go wrong if
> you could only assign one (at any given point in time)?
>
+1 - this should be one shepherd.

>
>  Each WG chair can use zero or more CodingRequests.
>
> I think we get rid of the WG chair completely within this data model and
leave it to links through the datatracker if a draft/RFC is the work of a
WG.

>
>  - Each CodingRequest has one Default shepherd (User) who possibly assist
> future developments of that CodingRequest. Each Default shepherd my by that
> default for zero or more CodingRequests.
>
>  - Each CodingRequest link to a set of one or more Specifications (RFCs
> or I-Ds) that are logically co-related. Each Specification is associated to
> zero or one CodingRequest.
> - A CodeMatch exists once a Coder (User) wants to develop the offer of a
> CodingRequest. Each CodingRequest can have zero o more CodeMatches. Each
> CodeMatch implements a single CodingRequest.
>
>
How about the following wording per our agreement at IETF91 (Robert
mentions a bit further down) to associate a project instead of a user to a
CodeRequest.  The wording is important as the project could be open source
through GitHub or proprietary and may just be a link describing code or a
project that implements that code.

- A CodeMatch exists once a 'project' developing the drafts or standards
 has been associated with the CodingRequest. Each CodingRequest can have
zero or more CodeMatches. Each CodeMatch implements a single CodingRequest.

 This is the 'my project is related' relationship we talked about at IETF
> 91;
>
>  - Each CodeMatch is developed by a single Coder (User) [we are reducing
> team of developers to a single Coder for the moment].
>
> Have you considered replacing "Coder" with "Project"?
>

I think my above suggestion should cover replacement text for this bullet
as well as the previous one.  We decided to change not only the word
project, but that the project would be 'associated' with the CodeMatch.
This language is cleaner and encompasses more than just open source and
student coding efforts.  I think it will be easier to start from a more
generalized approach than to try to work in the various options later.

>  Each Coder can developed zero or more CodeMatches.
>
> Again, I think you really mean project.
> But the zero in "zero or more" throws a flag for me.
> Do you really want to start collecting data on people (or projects) that
> are not associated with an offer?
>

I think this bullet goes away as well with the notion of associating a
project as opposed to a coder with a CodeMatch.  The notion of a user in
this sense would now be the person who is creating the associations on
behalf of projects.  The projects would likely be different ones for
different standards. although some overlap is possible when a project
implements multiple standards (and that happens).

How about the following to replace, "Each Coder can develop zero or more
CodeMatches":

    - A 'project' may be associated with multiple CodeRequests.
    - A User who creates the association between a Project and a
CodeRequest (a codeMatch), may have more than one CodeMatches with distinct
Projects.

That's just meant to call out that a project may be associated with more
than one CodeRequest when you have cases where multiple standards are
implemented.  Then you may also have cases where a vendor or open source
community with multiple efforts going on could have distinct projects that
get associated with the respective CodeRequest.

> I suspect this was inspired by early thinking to be able to show a report
> of all the offers a particular coder has provided code for, and that
> _doesn't_ align well with talking in terms of projects.
>
>  - Each CodeMatch has a single Shepherd (User), possible the Default
> shepherd from the original CodingRequest. Each Shepherd can shepherd zero
> or more CodeMatches.
>
> And, similar to CodingRequest, what lives in a CodeMatch? A paragraph
> description, provided by the random person who says "my project is
> related", and a URL pointing to the project? What else?
>

The CodeMatch just includes the CodeRequest and a link to the project (open
source code repository or description of proprietary code/a product).

The shepherd and set of drafts are part of the CodeRequest along with some
other elements discussed in the background materials I put together with
help from the team.  It is important that the CodeRequest include estimated
level of effort for the development.  This will help students or even
Capstone projects assess which of the CodeRequests are feasible for them to
consider given any constraints on length of the semester and size of their
team.  It may also help others in the community assessing their project
plans.

Longer term, it would be helpful to identify sponsored opportunities as
well for CodeMatches.  We won't get involved in the sponsorship
discussions, but may enable a way for industry and universities to connect
on specific CodeRequests.  There is some interest in this already from my
discussions with a few companies and multiple universities.

To Robert's question, the CodeRequest has more information int he
relationships that need to be included.  The CodeMatch is simpler, agreed.

>
>  Thinking ahead about integration with data tracker, we believe that User
> and Specification will existe outside the CodeMatch site, living in the
> data tracker.
>
> Right.
> Specifically, you'll be doing read-only queries of the datatracker's
> Person and Document objects.
> You will probably also use several other datatracker models the same way
> (such as Group and Role (which is how you find WG chairs)).
> We can dive into the details of those later.
>
> If we have APIs to these entities,
>
> If this goes as we've talked so far, the access will be through django
> itself.
>
>  the CodeMatch site, in one possible option, would need to implement
> CodingRequest, CodeMatch, their relationships, as well as the links with
> the external (from data tracker) User and Specification. Just an initial
> though to advance the discussion.
>
>
Thanks for all your work and input on this discussion.  Is there anything
else?  More reviews are welcome!

Thanks,
Kathleen

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

-- 

Best regards,
Kathleen