Subject: [TOOLS-DEVELOPMENT] CodeMatch

From: Russ Housley <[email-masked]>
Date: Mon, 5 May 2014 16:28:46 -0400

Thoughts are welcome.

Begin forwarded message:

> From: Kathleen Moriarty <[email-masked]>
> Date: May 1, 2014 8:54:59 AM EDT
> To: "[email-masked]" <[email-masked]>
> Subject: CodeMatch updated doc
> 
> Hi,
> 
> I am attaching an updated version of the CodeMatch draft.  This adds
> in a description of GitHub rather than a simple mention for those not
> familiar and to better explain that the intent is (and was) to avoid
> replication of existing tools.  This effort is meant to create
> linkages between WGs and drafts/RFCs and implementations (any type,
> including open source) to improve/enable collaboration between various
> groups (standards, open source communities, researchers, students, and
> industry with proprietary implementations.  From some feedback
> received, those points were not clear enough, so the proposal has been
> revised.  Please let me know if you have any more comments.
> 
> Otherwise, next steps may be two-fold.
>  1. Get volunteers to help build the site
>   2. Solicit working group chairs to start compiling a list of what
> drafts would be helpful for them to track or solicit implementations
> 
> Thanks
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Robert Sparks <[email-masked]>
Date: Mon, 05 May 2014 15:56:18 -0500

Is a quick response needed?

I have thoughts, but unless there is time pressure (such as needing to 
talk about this at the retreats), I would like to assemble them carefully.

RjS

On 5/5/14, 3:28 PM, Russ Housley wrote:
>> _______________________________________________
>> TOOLS-DEVELOPMENT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 May 2014 18:30:42 -0400

It is not currently on the agenda, but it could be raised in the discussion.  Let's do the careful version.

Russ

On May 5, 2014, at 4:56 PM, Robert Sparks wrote:

> I have thoughts, but unless there is time pressure (such as needing to talk about this at the retreats), I would like to assemble them carefully.
> 
> RjS
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 06 May 2014 12:21:17 +0200

> Thoughts are welcome.

The document does not have an author.

Who are 'We'?  It is hard to get a proper understanding of a text if
the context is missing.

	Henrik

---

From: Robert Sparks <[email-masked]>
Date: Thu, 08 May 2014 14:48:12 -0500

Please feel free to forward:
----------------------

I have several comments and questions about this proposal.

First - it's not clear who's making the proposal and to whom
the proposal is being made. As a result, many of these questions
are based on assumptions, some of which may not be accurate.
I'll try to call those assumptions out as I go. But I think
making this far more clear is the first-order bit of feedback
that I can suggest.

It would help to try to be more explicit about goals.
Right now, the proposal tries to explain the goals using mechanism
in places, and it shows some thought drift (one part talks about
matching projects to drafts, another talks about matching implementors
to drafts). More carefully stating what you want to achieve, and why,
without resorting to potential solutions would help. That said, it's
not clear to me so far why a chair couldn't just use the wiki they
already have for each group to do what this document seems to be asking
for.

I would also encourage you to back away from branding this before
you more clearly define it. CodeMatch is a flashy name, but I think
you're running into places where you leaning on the name (and phrases
like "making a code match") as a definition or description - risking
Do What I Mean rather than Do What I Say.

Now for some detailed questions/comments:

* The prose focuses on students and academic projects. There are
   _many_ open source projects out there that are not fueled that way.
   Is the intent to attract and match against those as well, or is this
   really only focusing on student-like contributors?

* The document seems to state that a Working Group Chair will have
   the authority to make matches.
   - What about non-WG documents?
   - How can a chair decide what's ok and what's not ok to point to?
     * Are projects that provide their source with an open source license
       but don't take contributions from anyone ok?
     * Are there any restrictions on the licenses of the projects that
       the chairs point to?
     * A couple of edge cases to consider when answering this:
       - <http://www.asterisk.org/>
       - <http://www.openh264.org/>
   - What recourse do the proponents for a project have if a chair
     decides they aren't worthy of a link?

* How do you plan on keeping the code from becoming a process artifact?
   We struggled with OPUS in the Codec working group - much of the group
   at that time wanted the repository to be authoritative. While I think
   we have general agreement to not repeat making code normative in an
   RFC, this kind of formal linkage to code will put pressure back in
   that direction.

* How do you avoid this linkage appearing as an endorsement or some
   other blessing of status by the IETF to the linked-to projects?
   Or is that a goal?

* The document seems to assume we need to set up something at GitHub.
   It's not clear why. Individual projects could set themselves up there,
   or anywhere else. I don't see why the proposal should call GitHub out
   as something special. Or is the intent to _not_ point to projects like
   what's at <www.respirocate.org>,  or <http://www.kamailio.org/w/>?
   I think you want to be inclusive, and things like GitHub should just
   be mentioned as one of the outside places you might link to.

* The phrase "the contribution of open source code to CodeMatch"
   implies that CodeMatch is an entity that can accept contributions.
   Is that intentional? Are you expecting to hold a copyright, or have
   such things assigned to that entity? If so, please start describing
   what this entity would look like explicitly. However, I strongly
   discourage you from going down that path. (I could talk about
   relevant experiences with the SIPFoundry here if you really want
   to try to pursue it).

* The discussion of "guidelines for plugfests" seems totally unrelated
   from the rest of the document. Perhaps this will become clearer when
   the goals are more carefully stated, but I suggest you separate
   discussions of helping make interop events better from the rest of
   what you're trying to achieve. I'd like to participate in the interop
   event discussions when they happen - I have many things from SIPit to
   bring to the conversation.

Hope this helps,

RjS

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 May 2014 13:08:02 -0700

RjS,

Thanks for putting this together.  I was very helpful to me.

Bob