Subject: [Codematch-develop] CodeMatch preliminary data model

From: Lisandro Zambenedetti Granville <[email-masked]>
Date: Thu, 13 Nov 2014 13:58:29 -1000

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). One CodingRequest may have one or more WG chair. Each WG chair can use zero or more CodingRequests.
- 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.
- Each CodeMatch is developed by a single Coder (User) [we are reducing team of developers to a single Coder for the moment]. Each Coder can developed zero or more CodeMatches.
- Each CodeMatch has a single Shepherd (User), possible the Default shepherd from the original CodingRequest. Each Shepherd can shepherd zero or more CodeMatches.

Thinking ahead about integration with data tracker, we believe that User and Specification will existe outside the CodeMatch site, living in the data tracker. If we have APIs to these entities, 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.

Best regards,

Lisandro

---

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Nov 2014 15:49:18 -0600

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:
> 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).
> 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)?
> Each WG chair can use zero or more CodingRequests.

> - 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.
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"?
> 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 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?
>
> 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.
>
> Best regards,
>
> Lisandro
>