Re: [Codematch-develop] [TOOLS-DEVELOPMENT] CodeMatch

[Kathleen Moriarty <[e-mail]>]

Robert,

Thank you for the valuable feedback!  I have updated the working draft that
will just be used by the team as reference materials to help develop the
mock up and design.  Please keep in mind that the language will change for
any materials like pamphlets and the actual text on the web site with the
teams input.

I'll try to respond in line or have already addressed some of the comments
in the working draft.



On Mon, Aug 11, 2014 at 3:23 PM, Moriarty, Kathleen <
[e-mail]> wrote:

> Robert,
>
> Thank you for sending this, I had not received your comments.  I'll go
> through them carefully and respond via my gmail account.  I'll update the
> working draft as well.
>
> We set up a mailing list (CodeMatch-develop) and will begin working on
> both a design plan and one for a functional spec over the next week.
>
> Thank you,
> Kathleen
>
> Sent from my iPhone
>
> On Aug 5, 2014, at 12:47 PM, "Robert Sparks" <[e-mail]> wrote:
>
> Kathleen -
>
> I was asked to review an earlier version of the codematch document back in
> May.
> I had several questions, and I don't know if they were ever forwarded to
> you.
> I'm sending a copy of that older review here.
>
> I've scanned the current document (pointed to on the recently announced
> list),
> and I think most of these questions are still open.
>
> RjS
>
>
> -------- Original Message --------  Subject: Re: [TOOLS-DEVELOPMENT]
> CodeMatch  Date: Thu, 08 May 2014 14:48:12 -0500  From: Robert Sparks
> <[e-mail]> <[e-mail]>  To:
> [e-mail]
>
> 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.
>
> Pete mentioned this and contact information was added to the top during
the IETF in Toronto.  Thank you.

>
> 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 tried rewording the introduction and adding a section at the end with a
bulleted list of goals.  These may get expanded by the team (copied on this
message).

> 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.
>
> Good point.  I went through the document and tried to use terms like
"linked" instead of match code where possible and to rephrase some text.

>
> 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?
>
> Open Source is listed as a separate group.  I reviewed the text with this
comment in mind and expanded the section to include a bulleted list of
benefits.  Additionally, I added a section to show that you could link
proprietary implementations as well, including benefits.  I also started an
FAQ as we've heard this comment before and would like to make sure it is
clear.  Does this clear up the concern or am I missing something?

>
> * The document seems to state that a Working Group Chair will have
>   the authority to make matches.
>   - What about non-WG documents?
>
> It also says authors, so I added editors as well and made a few additions
to show that it can be used with individual drafts or RFCs.

>   - How can a chair decide what's ok and what's not ok to point to?
>
> The chair just says what they want code for, they don't decide what gets
linked in terms of license agreements since proprietary efforts can be
linked.  Obviously, there won't be a linked code repository, but they will
get notifications on errata and may participate in plug fests.  You raise a
very good point that we will need a lever that could be by the requestor
for code (WG chair, author, editor, CodeMatch shepherd) to remove matches
that don't make sense (equivalent of spam or someone needs help using the
interface).  We'll have to consider this point in the access control
model/policy work that will start soon (following the mock up work).

>     * Are projects that provide their source with an open source license
>       but don't take contributions from anyone ok?
>
> Yes.

>     * Are there any restrictions on the licenses of the projects that
>       the chairs point to?
>
> No, there are benefits to the IETF and vendors for mentioning proprietary
implementations as well, they just won't include code.

>     * A couple of edge cases to consider when answering this:
>       - <http://www.asterisk.org/> <http://www.asterisk.org/>
>       - <http://www.openh264.org/> <http://www.openh264.org/>
>
> Thank you!

>
>   - What recourse do the proponents for a project have if a chair
>     decides they aren't worthy of a link?
>
> Great point, we'll have to figure this one out.  Suggestions are welcome
or maybe the team has ideas?

>
> * 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.
>
> If code is provided via a link to GitHub, you can get some sense of the
adoption pretty quickly.  This is a good point for what is listed on our
interface linking efforts.  Having a date of last edit could be helpful and
also to ensure protocol versions and RFCs implemented are part of the
match.  If an RFC changes state, it would be good to be able to reflect
that and possibly have links between old and new.

>
> * 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?
>
> No endorsement is intended.  We'll have to make sure language on the site
clearly states that point.  However, if an interoperability test is run,
then we would be interested to demonstrate success for those that achieved
it.

>
> * 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/>
> <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.
>
> Ah, yes, I agree.  Another set of reviewers were not familiar with tools
like GitHub and only SVN.  The section was added to better explain how
developers work today.  Any code repository would be fine.  I added a note
at the end of the GitHub section to make that more clear.

>
> * 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).
>
> Good catch, thank you!  I rephrased this to better explain how this works
and that code is just linked and not contributed to the IETF.

> * 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.
>
> Thank you, that will be very helpful!  This came as a recommendation to
add to the draft in terms of useful ways to leverage the established
collaboration set up between groups.  I didn't see this point before I
edited the draft, so the only change made was to show that this is a
benefit to some of the participating communities (they would be notified).
 Guidance on how to do something to improve the plugfest efforts would be
very much appreciated.  It would be good to make it possible for one group
to learn from past experience of another and improve process
recommendations over time.

Here is a link to the updated draft.
https://docs.google.com/document/d/12kbFDwzhecC1DLtVEo3ruLuFZMCtiSwd5US0I44v96Q

>
>
> Hope this helps,
>
> Very much so, thank you!
Kathleen

> RjS
>
> On 5/5/14, 3:28 PM, Russ Housley wrote:
>
> Thoughts are welcome.
>
> Begin forwarded message:
>
>
>  From: Kathleen Moriarty <[e-mail]> <[e-mail]>
> Date: May 1, 2014 8:54:59 AM EDT
> To: "[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>
> 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
>
>
>
>
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing [e-mail]://www.ietf.org/mailman/listinfo/tools-development
>
>
>
>
>


-- 

Best regards,
Kathleen