From kmburgh@yahoo.com Mon Feb 2 14:14:53 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1C71A0196 for ; Mon, 2 Feb 2015 14:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.691 X-Spam-Level: X-Spam-Status: No, score=0.691 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCg6HZm1syot for ; Mon, 2 Feb 2015 14:14:52 -0800 (PST) Received: from nm39-vm3.bullet.mail.bf1.yahoo.com (nm39-vm3.bullet.mail.bf1.yahoo.com [72.30.239.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4211A00FF for ; Mon, 2 Feb 2015 14:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422915290; bh=ZCSU68x7y1tvzMksxTHKaGQTXzfaAT0xTkFhiV07nx0=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=qqce3UM79SKsEDP5m65BcDnQlUxchimnVIZ6uU6vkoF+SbKe4fK3mSS5GiKoTtfkVnn2hcqUO6ZIt7gAvceIyp0FsuE/P5ZB1akz04rvuwqlxDFXRNbxLe1IHyB67sbUFOBi/Uljugvm9Duy6Erw84TBMpdLwpEPiQPuxxPqHl2xTiOxtOEuNx5riggYrAbMgsgOJKWZWslvI5wcubnX0MDrwCa9iTCnGGTD9ollIp+b+sW8ALPCBp0fG6/gskn9cDst3cLtu98Ao4JXPUMUuzDzAuchlDpwAsA7sKgVfWKVXH+V7iiYKBvHdk59Pm8xs3QhGbo3ZKoT8JwzgVSzvQ== Received: from [66.196.81.171] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 02 Feb 2015 22:14:50 -0000 Received: from [98.139.212.251] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 02 Feb 2015 22:14:50 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 02 Feb 2015 22:14:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 923380.31201.bm@omp1060.mail.bf1.yahoo.com X-YMail-OSG: 6smUKqIVM1nlhtjkV4aVfg7Yr1ZCeVicD5tfqxOlXGvlhNrIs7lKzXaokGSIL4u Na88eKQeubWZmDGLGsNAR_bt6OcsJ1TLFEDjRvEhktd2qxKilmp0vXZ1Zx7eLcD4od2asIo0b1KQ celYIPwJPgrBRJ85JSMdYDDKsoq6vPTa3VgVD0epzMSt1H6Ki1s7jj9Gb7te3Vsv2B9mb8WB1UO2 iU.0E80Fg46_mvTOciWHy_sF7WZvFU3xkdWRydbKKauUd2w_KqLRW7clgjI5sLSOTf64sviBwWcP mW4tnzFcCmtEP1KfhzDbNZnQnUHljxoID.p.w498mfflmj03VEEObjRfa55wBtvlUH43SXiLbm6S SuxEsr6xqaSrqM9l3tYodbl.wyTCYXNQ.o5pRmgCjt2oXSD9ac6FASXNSkGSuVY2Uy32hEDKeRm9 MecOlUnznHGxxo0C0QACprmA56_osOVMP5vZXgLEYmj1F38RN8scD7aZLtx0i5QINiodDBvxIqW_ SImxWzG3zWmRcm9w5xj1qc_iPCygXFqKbsc41OH4fy_shbeQzZTHhgHN8vhZ_V1C4Z4Y5grzUZH9 4o92QAAP4bcvtJz2431PRb4upxS.UTsa1EJVmo3y90ug7n_f.pBa5C9H0m3XTubBOcb3Z4N93Vw-- Received: by 66.196.80.122; Mon, 02 Feb 2015 22:14:50 +0000 Date: Mon, 2 Feb 2015 22:14:47 +0000 (UTC) From: Kristin Burgh To: "codematch-develop@ietf.org\"" Message-ID: <539499825.1176234.1422915287955.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <117930795.1084101.1422905229476.JavaMail.yahoo@mail.yahoo.com> References: <117930795.1084101.1422905229476.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1176233_829253445.1422915287948" Archived-At: Subject: [Codematch-develop] Fw: PowerPoint Card Sort on Google Drive X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kristin Burgh List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 22:16:09 -0000 ------=_Part_1176233_829253445.1422915287948 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0 Sent: Monday, February 2, 2015 2:27 PM Subject: PowerPoint Card Sort on Google Drive =20 Hello Everyone -=C2=A0 I thought I'd try to make our card-sorting exercise a little easier for eve= ryone. =C2=A0As such, I've posted a short PowerPoint presentation to the Go= ogle Drive, which I'd like you to use in lieu of the Card-sorting link. https://drive.google.com/?usp=3Dslides_home&authuser=3D0#folders/0B-dir4eV4= Ih1V2tQSDdNRndrdGc =E2=80=A2Viewslide 3 in this PowerPoint deck=E2=80=A2Movethe =E2=80=9Cgreen= boxes=E2=80=9D underneath the corresponding purple boxes=E2=80=93Dowhat ma= kes sense to you =E2=80=93 there are no wrong answers!=E2=80=93Feelfree to = fill in the =E2=80=9Cblank=E2=80=9D boxes with terms that you think are rel= evant=E2=80=A2Savethis file to the Google Drive as =E2=80=9CCodeMatch_CardS= ort_[YourName] Please let me know if you have any questions or concerns.Thank you and Kind= Regards,=C2=A0Kristin ------=_Part_1176233_829253445.1422915287948 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
 
Sent: Monday, February 2, 2015 2:27 PM Subject: PowerPoint = Card Sort on Google Drive

<= span id=3D"yui_3_16_0_1_1422916020828_3172">Hello Everyone - 
<= span>
I thought I'd try to make our card-sorting exercise a litt= le easier for everyone.  As such, I've posted a short PowerPoint prese= ntation to the Google Drive, which I'd like you to use in lieu of the Card-= sorting link.


=E2=80=A2View slide 3 in this PowerPoint deck
=E2=80=A2Move the =E2=80=9Cgreen boxes=E2=80=9D underneath the corresponding purple boxes=
=E2=80=93Do what makes sense to you =E2=80=93 there are no wrong answers!=
=E2=80=93Feel free to fill in the =E2=80=9Cblank=E2=80=9D boxes with terms that you think= are relevant
=E2=80=A2Save this file to the Google Drive as =E2=80=9CCodeMatch_CardSort_[Your Name]

Please let= me know if you have any questions or concerns.
Thank you and Kind Regards, 
<= div style=3D"margin-top:7.68pt;margin-bottom:0pt;margin-left:.38in;text-ali= gn:left;direction:ltr;unicode-bidi:embed;" class=3D"yiv8527012350" id=3D"yi= v8527012350yui_3_16_0_1_1422904238455_11239" dir=3D"ltr"><= span style=3D"font-family:Calibri;color:black;" class=3D"yiv8527012350">Kri= stin



=
------=_Part_1176233_829253445.1422915287948-- From nobody Wed Feb 4 08:29:56 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752B01A00F3 for ; Wed, 4 Feb 2015 08:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11Lh0sT8mbQN for ; Wed, 4 Feb 2015 08:29:54 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87611A079D for ; Wed, 4 Feb 2015 08:29:53 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id gf13so2526666lab.8 for ; Wed, 04 Feb 2015 08:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XCxAtykvBZbYnKDxBWFJaaENziC4+M0l7SVH+QLlLFI=; b=JPDwoau4dJQYajgWTCGvAzYsMlBy1t3Fb89sAnOvCJ+oCLZg3ppZKR5mMSA8b6ePzQ XHs2lKKwBBLo2ObSTFE+7RcNGCWlXa1DPeLGKSjKJo5Tsn2qjx6mwPD7goHTFbQoMPMn vH3EPyv2uyb8gA39Avic4hVlW6qHUKtYl2Fhl/XIq0UuqIW+7ookRvm1QYsrCwMvvAlA E0T7dj/fu5jK+YBPDwZeVCwscOyndEYZX4Tx1lZokUHU+jtXxsEDqbTiXverQ27irgYT rr/qKp4xoGsqKqCDjRj95T4YZ5rDcsoPSPq9vBUjuePcu0aiOGLX5TJ0mkVleyS1EuCF ne7w== MIME-Version: 1.0 X-Received: by 10.112.63.134 with SMTP id g6mr27686789lbs.52.1423067392377; Wed, 04 Feb 2015 08:29:52 -0800 (PST) Received: by 10.112.167.134 with HTTP; Wed, 4 Feb 2015 08:29:52 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Feb 2015 11:29:52 -0500 Message-ID: From: Kathleen Moriarty To: "codematch-develop@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Codematch-develop] New call time: Wed 12PM EST X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 16:29:55 -0000 Please take a look at the PT Kristin posted in the Google drive prior to our call in 30 minutes. Call info is included below in case anyone missed the new information. http://www.ietf.org/mail-archive/web/codematch-develop/current/msg00117.html Thank you! On Tue, Jan 13, 2015 at 3:58 PM, Kathleen Moriarty wrote: > Hello, > > From the poll, we have a new call time, 12PM EST on Wednesdays. We'll > need a new webex (to be provided soon, by ISOC). Here is a > placeholder invite for tomorrow's call. > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Fri Feb 6 08:07:56 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12801A6F15 for ; Fri, 6 Feb 2015 08:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmHOp38FCYT9 for ; Fri, 6 Feb 2015 08:07:48 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57F01A6EF3 for ; Fri, 6 Feb 2015 08:07:47 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so18846584lbv.4 for ; Fri, 06 Feb 2015 08:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KibdSrSTrq2UdOnb+VwuiJY2dfYsgrMWeFDCozikjfE=; b=TU7u7IybUQf1+FbGnZncOIBcjKE1s8p7kw+z4fs2OdM2gEXRmen9fwVMWXZN6kK/al jKwmRDaraLOUI7wHaSCCmAPz87K4h16A+eZWbftpxFli4cB1rZsR6x41pNfFOTKxtuMH i3lZ8IrwCZHbFkLF6mB3XlcEojEphw0AYkAC8qQtjGMTDPMqhPvEt06ZnWKQ7EejjAjn SsJKO3RvBPxINMdMKsk8CJevQAsVfQ6sBig+xo/pFSFhCFqHSWHPK/nShpkbUWsTraVS B9YjHfcdvsGQmUG8V2hKzQLvE1hmunBKZQuefDkD4l5PF/LtwuLJkyUvQO1JLPA6a9rC iWgw== MIME-Version: 1.0 X-Received: by 10.112.118.144 with SMTP id km16mr3486778lbb.75.1423238866142; Fri, 06 Feb 2015 08:07:46 -0800 (PST) Received: by 10.112.167.134 with HTTP; Fri, 6 Feb 2015 08:07:46 -0800 (PST) Date: Fri, 6 Feb 2015 11:07:46 -0500 Message-ID: From: Kathleen Moriarty To: "codematch-develop@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfd07e60c0b73050e6d9fad Archived-At: Subject: [Codematch-develop] Short exercise - requested by Tuesday X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:07:51 -0000 --047d7bfd07e60c0b73050e6d9fad Content-Type: text/plain; charset=UTF-8 Hello, Kristin, who is helping us with our UI is designing an exercise, called card sorting. She needs our help to fill in what terms we think belong with each type of user. She's posted a PPT in the google drive and would like as many of us as possible to download it, add our initials to the file name, and edit it to include the names of terms we each think fits in the categories. Some are there for you and others are left blank. Please use as many or as few as you think are needed. This will be used as a tool to test out our terms with out potential user base so that we have some sense if the interface is confusing or not. Here is a link to Kristin's message & the PPT: http://www.ietf.org/mail-archive/web/codematch-develop/current/msg00117.html -- Best regards, Kathleen --047d7bfd07e60c0b73050e6d9fad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Kristin, who is helping us with = our UI is designing an exercise, called card sorting.=C2=A0 She needs our h= elp to fill in what terms we think belong with each type of user.=C2=A0 She= 's posted a PPT in the google drive and would like as many of us as pos= sible to download it, add our initials to the file name, and edit it to inc= lude the names of terms we each think fits in the categories.=C2=A0 Some ar= e there for you and others are left blank.=C2=A0 Please use as many or as f= ew as you think are needed.

This will be used as a= tool to test out our terms with out potential user base so that we have so= me sense if the interface is confusing or not.

Her= e is a link to Kristin's message & the PPT:
--047d7bfd07e60c0b73050e6d9fad-- From nobody Sat Feb 7 00:24:46 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453711A88E4 for ; Sat, 7 Feb 2015 00:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.055 X-Spam-Level: ** X-Spam-Status: No, score=2.055 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_12=2.059, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gL3530LXqCm for ; Sat, 7 Feb 2015 00:24:39 -0800 (PST) Received: from delivery3.ufrgs.br (delivery3.ufrgs.br [143.54.2.213]) by ietfa.amsl.com (Postfix) with ESMTP id E3DD31A1A4F for ; Sat, 7 Feb 2015 00:24:37 -0800 (PST) Received: from delivery3.ufrgs.br (localhost [127.0.0.1]) by delivery3.ufrgs.br (Postfix) with ESMTP id 962E4300253 for ; Sat, 7 Feb 2015 06:24:34 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery3.ufrgs.br (Postfix) with ESMTP id 9D26B165 for ; Sat, 7 Feb 2015 06:24:34 -0200 (BRST) From: Lisandro Zambenedetti Granville Content-Type: multipart/alternative; boundary="Apple-Mail=_FF3539F6-2F6F-4C76-852D-FBF300CE49C9" Message-Id: <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Sat, 7 Feb 2015 16:24:27 +0800 References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> To: "codematch-develop@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Subject: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 08:24:41 -0000 --Apple-Mail=_FF3539F6-2F6F-4C76-852D-FBF300CE49C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 --Apple-Mail=_FF3539F6-2F6F-4C76-852D-FBF300CE49C9 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_D1D4BB17-996B-4270-B8AB-9443411980B3" --Apple-Mail=_D1D4BB17-996B-4270-B8AB-9443411980B3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 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

--Apple-Mail=_D1D4BB17-996B-4270-B8AB-9443411980B3 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=codematchv3-3.png Content-Type: image/png; x-unix-mode=0644; name="codematchv3-3.png" Content-Id: <3791F40E-73E1-499C-8999-2245631C0893@icannmeeting.org> iVBORw0KGgoAAAANSUhEUgAAAZAAAAF8CAYAAADhOe01AAAAAXNSR0IArs4c6QAAQABJREFUeAHs vQ9AXNWZ9/9NCwoKqcQmm5coMY1NiXWoBnWTapIBal+jLTTdZm0LrEm1mGhNSLXml1ijEjUlrRqo OjHVBVfI1pKf2+C+Jb/dHUqIdWx1aDsTC7XEODSgBR2aQJ0xM/2d9zn3zgzDMHeAyQzcGZ6jw9w5 9/x5zuec3Oeef8+ZJciBHRNgAkyACTCBSRL42CTDc3AmwASYABNgAgoBViDcEJgAE2ACTCAqAqxA osLGkZgAE2ACTIAVCLcBJsAEmAATiIoAK5CosHEkJsAEmAATYAXCbYAJMAEmwASiIsAKJCpsHIkJ MAEmwARYgXAbYAJMgAkwgagIsAKJChtHYgJMgAkwAVYg3AaYABNgAkwgKgKsQKLCxpGYABNgAkyA FQi3ASbABJgAE4iKACuQqLBxJCbABJgAE2AFwm2ACTABJsAEoiLACiQqbByJCTABJsAEWIFwG2AC TIAJMIGoCLACiQobR2ICTIAJMAFWINwGmAATYAJMICoCrECiwsaRmAATYAJMgBUItwEmwASYABOI igArkKiwcSQmwASYABNgBcJtgAkwASbABKIiwAokKmwciQkwASbABFiBcBtgAkyACTCBqAiwAokK G0diAkyACTABViDcBpgAE2ACTCAqAqxAosLGkZgAE2ACTIAVCLcBJsAEmAATiIoAK5CosHEkJsAE mAATYAXCbYAJMAEmwASiIsAKJCpsHIkJMAEmwARYgXAbYAJMgAkwgagIsAKJChtHYgJMgAkwAVYg 3AaYABNgAkwgKgKsQKLCxpGYABNgAkyAFQi3ASbABJgAE4iKACuQqLBxJCbABJgAE2AFwm2ACTAB JsAEoiLACiQqbByJCTABJsAEWIFwG2ACTIAJMIGoCLACiQobR2ICTIAJMAFWINwGmAATYAJMICoC rECiwsaRmAATYAJMgBUItwEmwASYABOIigArkKiwcSQmwASYABNgBcJtgAkwASbABKIiwAokKmwc iQkwASbABFiBcBtgAkyACTCBqAiwAokKG0diAkyACTABViDcBpgAE2ACTCAqAqxAosLGkZgAE2AC TIAVCLcBJsAEmAATiIoAK5CosHEkJsAEmAATYAXCbYAJMAEmwASiIsAKJCpsHIkJMAEmwARYgXAb YAJMgAkwgagIsAKJChtHYgJMgAkwAVYg3AaYABNgAkwgKgKsQKLCxpGYABNgAkyAFQi3ASbABJgA E4iKACuQqLBxJCbABJgAE2AFwm2ACTABJsAEoiLACiQqbByJCTABJsAEWIFwG2ACTIAJMIGoCLAC iQobR2ICTIAJMAFWINwGmAATYAJMICoCrECiwsaRmAATYAJMgBUItwEmwASYABOIigArkKiwcSQm wASYABNgBcJtgAkwASbABKIikBJVLI6kSWDWrFma9/gGEwhHQAgRzpv9mIDuCbACiUMV8QMhDlCT NEl+4UjSip0hxeIhrBlS0VxMJsAEmECsCbACiTVRTo8JMAEmMEMIsAKZIRUdVTHdHSinOR05zDLy ycOO+qNwTyLB4Y49FH8PBicRZ3TQYRw9UI+u4dG+/IsJMIHpJcBzINPLX/e5n4QBjZaf4R8vADwk 7cCxZqxatwqu+Q48cUPOhORPW1SMFrMHmRMKHSaQ9y2sKn0cVtf6MDfZiwkwgekiwD2Q6SKfMPle iNwrcrE4Nxe59Fn5te+izgiYbX1wdx1ESUE5tpYXUA+jAM09bvS07kOJr8eSV74HHQNeeJ3H0Pjy HwO9lr7XDowKYw/qmhyX8fPUHk8BxbcPDuPAhnyiZUd++u3o4F5IwrQcFjT5CbACSf46PusS/s3l BbykCOjT1/EzPN4GfCkvB17P+2hua8De89bAVHMLLun/KRYWbcJ8kxnd3RasO7kN+fN248+n+tCw t0+Rw9tzEAtWlCphHA4bbju9DXmr92CA7rqPH8SlMv4dLUr8FQ10b/NhrLyzjvpBBpjM38GStLMu DifABJhArAjQklN2MSRA9RLD1KY5KZdVlFF5ZJlGfYxVonNIiCGbifyNwkLX0llrjALGOuFSf1IA izBQ3D0v7qFwNUIGs5mK6bpSdDqHhJM+/bZGJe0mh0eNb1DDySRc3WZRd8gqPB6bMFI+1kDC/gwS /zup2kviVweXYJIEeA6E/gWz0yYg50Dq2uuRfz7NgZw5g9QLcrA0Nxuy4QzjDP29Atm+XkEq/TKs yUOgk5ByDhYpSf9d+av+mU1fe7F0zt4gP6Dv/SF8RvoULQnET1tciPWLyY8m86U7Qx0hdkyACeiH ACsQ/dSFTiW5EHlXL4MhoBVCxDQswhxfK5KT7Hb72/BimaJgZMjTSvCPK3/lH8+Zk6RlTHDaNiKT FEIKDV691t6FuYsyceoVCmB+h+JLfxo16zmMnfvew3d25NEv4BxfPsoP/sMEmMC0E+A5kGmvAv0L EPHN3z4i/8VXFgIN6/Ds0R643QNo/uHdaEMZij51biDQomvWkpbZhJ8c7iJFMYzWp2/DiqJV6COV seg69V49xfe6ad7kvjXYbXFjttLTacMrr3ZhmHshAZZ8wQSmmwC/0013DSR6/jTJ4XdzV34P7aaT WLVqITYpnkY0WmuxBC/4gyBr+R2w1J3AijVLsU3xNaDG7MDKLPqR5bsXiF8Bs2M9MjKcWFMMbCla CrfFiXuXy8DsmAATmG4Cs+ScyXQLkUz5yw13Mx2p1z2MIeopZGZkqENR9lqk0ijUkNiMDH9lU5hB F5CelRGY8/Dfgu9eJt0LfsNxu71ISwv2CcRI2AtuLwlbdSw4EeAhLG4GMSeQkpaBLJ/y6DqwlZTH Fpr3CMlGhgmnPGQw371QVZFsyiOECP9kAglHgHsgMa4yfqMcDXSwqxUttPtv2ZobkZsVqhJGh52J v7i9zMRaT54yswKJcV3yAyHGQJM8OW4vSV7BSV48HsJK8grm4jEBJsAE4kWAxxTiQFa+VbJjAkyA CSQ7AVYgcajhmb4KKw5IkzZJftlI2qqdEQXjIawZUc1cSCbABJhA7AmwAok9U06RCTABJjAjCLAC mRHVHOtCDmNfQfAphcHXBWh9JfgEwpHTBIdpQ+GsvFoyYMKOCTCBZCDAcyDJUItTXoYM/NOznbjW k4rUv/4a/0zne3ypyYJbr7wAH36Yiovne2Bup53oUq7g0wQVa4tTLixnyASYQJwIcA8kTmCTPdm5 i3NhyF2M3KsMisn2+Z+5HIuln2Ex0k4fQ91Lx+gEwtGnCf5OKpAgF+lkwqBgfMkEmIBOCbAC0WnF JIxYXo9qst0zoh28gRMIM2AMOk3w0hGjvGSqXftkwoQpOwvKBGY4AVYgM7wBxKX48mQpn8u+Kh8X 0n/XfN6AjJFjQdD5C2mhtxJbb74GmZmL8I2HG8nM+zYc6WF77X52/M0E9E6A50D0XkOJLh/1UKQb e6bIbPINfzIhcthcuwKN/zABnRPgHojOKyhZxAs9TTBwMiGdJuDxCAhPPyw0834TnUzIjgkwgcQg wAokMeopsaQcmQ6hVVjy3HTfaYJBR6NHOpkwsQrL0jKBmUuAh7Bmbt3HqOSpuCg0JTkH4j//IyMn cJrgqYbd5H+eEjriyYSh6fFvJsAEdEmAzbnHuFrYPHd4oJqnCUY6mTB8Uknly+0lqapzxhWGeyAx rPLXX389hqklV1KapwnK0wfTkqusXBomMFMI8BxIDGra4XDgq1/9KkpLS2OQGicx0wjItiPb0NQ7 L4aHhyF7h+yYQDQEWIFEQ80X56OPPsIjjzyCq666Cvn5+bDb7WeRGkedqQRk25FtSLYl2abi7wbR XHs7Zs1KpT04mUhPT0XB1nr0uCeXM9s2mxyvZAzNCiRCrfb29uLf/u3flI+8DnaHDx8msx0GWK1W vPHGG7jvvvtw7rlBW62DA/M1E4hAQLYd2YZkW5JtSratYBepHQaHm9g1mZcpn4OSLR+iydIN55AT vZ1mLNm7AQvX7MPgxBJRQqWlnkObPycRgYMmHwE6/IhdGAJPPvmk+NjHPiZuvPFG5SOvpd8777wj 1q5dKz796U+LlpaWMTGphYzx042HyyrKSD4pY+BjKBYmc/eUiDhkraZ8q4UzYm5Dor2xTnQOCTGx 8BET0/3N0PYi25RsW7KNybam1Q6jLZjLZlLqvrHbNSoJV2eTqKg0CYdH9XaYTaLY104MZdXC2q/e sDVVC1pgR2kYRUWZQcBoElRViuu1NI6KY/NVtEy72FgmKsuMSrxDjtF5+6LzVwIS0PHTbvpovv32 2+KSSy4RbW1tASHkdXZ2tsjKyhIPP/ywcLvdgXvBF6EPhOB7035NCsQIg2i0dIruzk7R2WkVh0wV ygOl8lD8lYjH2SnM7Z3C94wKj8NjJXkMwkrPmAmFD59KwviGay+ybck2duGFFyptLrQdyrYp22g0 rt9cRXwrhSNC5CFbndImKkxm0d1tEVVGqTCqxB+sqvKparKIbispBalIfArE42gKxHE4bKKmmO4Z qkU/5TPkU1qoqBammjoRorsiSMK39E4goVZhHTlyBPSPif7Nxdf9+te/xq233orVq1cHMpLXmzZt gtlshtfrxQ9+8IPAvcS6uBC5V+RisW/lU27uM7DiPeSX7MF3PM9gMbUIaSV3E5lob6aC0dsnGmvv hUGxLjKAg7u+i3U7G5QiV9SY8djmQmTQr+Ot+/Ddyk1opiENI8WppTif/stB3LzpED510UnspSgH 2yvw85dSkTf3GNZt+m+suOI97N5LuRgr0f78bqzM8eLAhnwl7fz02/Hq768nq77ANStzlTx6KI+7 iigPn1z1j38Xy+amwN11ADdvO4aiq/6MLVI2YxmaamvxNVVoJT09/3nooYfCirds2TKsWrVqTDuU bbOyshLy/kTdAw88oAT987FW4nMz5kSI+NYvn6cwdajZWAjZTO5/2YKmzBWo+/eViv/3vrZc8X/W vB3zKuVGUYy2bUa/pW2zLXmlZNvsu7hBCWGE5bF7sVw2liCnVfagIHG9NBqNo/jGNbMkTDyh5kCk 8qivr0/CapjaIoXapbrMuIYEeAsDNIkayUpuT/P3SXkA7d296DSbsH9LEZ7uGIT7+EFcSg/2+Xe0 gN5YsaJhG/I2H4Tb8z6a2xqw97w1MNXcgk+nDKBhbx+85N/Wth//+eFadPd2wnTRXqxa+EP0kZoI tt676KM+JbykM2yvx0KZh8ms5LHu5Dbkz9tNcUhmz2k0N+/GlpPXwtppQfXsBqzb/CIfXCXBhbgl 160lwwAtODFmwnwQHa91KG1A2Qe6Jk9REkr0lHMUk/2yw2FYO+KfOXd+0ByI37ZZJubMycQ8Uh7S 9b0/RH+lkrkC2b6XFumvByefJVPxQqqHssZNBr13kYLle/DBB4X8xNsl9xCWUVj8g9Y+kOoQg1FY yd9mKqahiErR6RwSTvr02xqVoYkmGhxX7xlFXYtV9A/RPYdDDNF4lLXGSE+WmsBYuKvbLOoOWcWg MnQxkt+QrYbSqhHv+vzlMJXihizKuHqTHBv32GiYjWShS394Ka6Sh7FO+KMIX5waEtovv79cLl8+ IcX0ZaavL/qHPUageA5hebrVoaYqsxxcGnHOdjm0BSHrWWFd1jQy1KgMfUJ8756VAsWNAX91jkqt d7UNmJT5LbJtRvXYL8i2meh2etR6DGofI7lO79VUPU+mt5TxzT2heiBx06IhCS9atAj33HMPCgsL cdNNNykfeb1jxw789re/1VwtE5JM4vz0qMMQ6l/tN0nDbT+GqQLYsCYf82j557y7nsexfjfkGyuK lgTeWNMWF2J98TKkaL55ypzWYon/jdT3hvt2n0t2JxRuob0k7bdiGV6mV4gc3/BIIu9qCF7dJ1dl yTYX2g5l25RtNBqXsvgraKkEdhYVofYw9TgGB9DVWo/Vq6hrWdaIL+Wk4OIrC4GGdXj2aA/tERlA 8w/vRhvK8JUbrgeaS9HwWh/cw114+u5tNKR1jiLGuLbNeLVWNNWl+zg04s0uHIE777wTX/nKV5Q5 D3l///79WLBggRL0pZdeUpZabt68GZdffjmeeOIJLFy4MFwyuvQbbRnXjcPPbKHJjhospgfwn8+c pGsTnLaNyKQncQoG8Fp7F+aSldzBvpO49r6XIWpcsL9+BHtWrUPFtdejXioC8zuQD27ZoLw9h7Fz 33vY8M/0w7AIc8K2sjfxF7rtHxI/TdcXzU2nv6obLSMg1YTd/jblIRWT6mQcqOqL8vkEpOpLVCc3 Em7duhXHjh2j+aNa3HCDOnMQqR1GV9YU3PDDXjSmb0MpvQhQzSvOWFkHx+5vKi8BaSu/h3bTSZp/ WYhN6l00Wmvx+WWZaK95C6tWLMAGXzwY1YtIts2GqUkFbKP54/F3chCIbwcntqnrrcvpH2r45Cc/ GViZRa0itoWOZWq+oYg6s1XQ262wtLeImkoafiKZq9vVIQ2nRQ4z0e+WTuHyDAlzjRzSgminJZmW KhoEp+Etm5MGklzdoor8DdVW4bSqcUztDuFx9Yq6MgpHq3PeDRlKGlLC+YewICobrZSHUxyqkjL4 VgbR0JSR0q0xd4p3f6MOecmhqH7fEIvMw+Xq98UpE50hQ10SV/DQVyzxxSMtyVauuApuQ/HIJ2ya HpcYcjrFkCv8ujiPi4Yxaagy9K7qHxhMHJ20jENDnxp3R4ed5l96e55MM46osve/zFE7ZjdZAnLj oNwEVlZWprw9yk1gencXkYAbitSVToqstGKpztyN9SvnKj8jvUniO1Zsb81H3py9ajGNVbB9exmy svJgqTuBFYE31gqYHeuRcWr/6DdPZRxKjUpjH3j7B/lIL5W/jWjq3IUcealhvXeuxltxLvV+hmW8 UPShv2UYnTr/ZtQp78WmpCEjgiGyFGmnLAwzLX8lKNs2C0Mseb0Syhqvf8mff0mi3qpFGlO85ppr ZBdEb6JNXp4IVnLdZD/JSwNJGRn+SQxf8r44mVkZgWGmcBlLExiZpedgiIbJMDiMtDDhtaz3eimP IRory8yInEe4fPXox9Z4p69W9P48mT4yE8+ZeyATZzVuyKuvvnrcMAkTIMKbZBo9vMO6CHFGhfec ogmNc5V5jSxSHuGclvXeiG+/4RJiPybABOJGgBVI3NBywloEMpbcAovVg0ytAOzPBJhAQhBgBZIQ 1ZRkQtI8x/KJb6JOssJzcZhA8hD4WPIUhUvCBJgAE2ACU0mAFchU0vbl5e6qp7MYStChLB8aLcBw xx66tyeiWe1h+z7Myqsdx1THMI4eqEdXmDxG5xjyy21H+axZqCUTJbFw+jgzYqIsRsJNpB5iwYfT YAKJTICHsKah9rweaYhI3QYXmn3aomKY22mVUeiN4N9y5/h4O3u9tOGr9HFYXeuDY07g2oOTFCpm ywGUHYATyDaeQSbKIijchOohnjJz2jEl4F9xFZxoJDtYel3pGSy/Hq65B6KHWgiSwes8RhZoj+Gv ZGG2pGQHaneVU49kFmYVlOOg3dcrUGyH+CINdmBrwSyU7zmq7ARXfenQIMWqrR3Sqq2/pyOt2ZbI tOiTV74HHQNy77i2c3cdREnBVuzaWqLGKdmFo/ZW7MhT0yjZdVDpKclwBQW3Y4cv3CyKc9R/vF2Q rNLKb3D+/uJMNB8pqXYaWrxCWXjRcWAX8nwcZuWV40DHAKU8Otwbf1brwW9zMBw7aQVYs460sfId JpA8BKLafjhNkRJh5yi1jHHp+I3/SeOFoS50tzYqTIIszIpqeb6C7+wFJYyhjgwZdgsya0QG7mpE b0hCvZY6MlBooMOibIrBQ60zHkLjCd9u9Ror7VD2n+NQWSdsthZBZrCUXenVhyyivWm7ci0PJvKH M1TQWQ+9ncIkd6LT+REybf+u8MGJnBcxTj4TO3NiLK9gFn9+RR5qJXfaW4U8t4JseymGIOXZR8Hh gnfBa7F7y88nTB2FVIfmz4m0F83IfOOsCCTC8+SsCjgFkcd/2k2BEBPNIhEqfCIPhIgKJMRibTgL s2r8YlFhHHlQj2EYZNVW3otkzXZU3DEKZMSark1a3Q1YY+1XTJlUBxSNakFXSSvIuq5fgbwWwcqv n4e/rFr5RLIUHJrGKIu8QSyc3VbRQmZSpHkO15BTWJsqRywJB4Xzyy11vBa7PS/uJWU0wmdUnqOg av+YSHvRjs13zoZAIjxPzqZ8UxGX50DoX7A+3XgWZpuxv01K7sRpGmcZc9ZCiFVbxYpI2DMe5CSF lpMyjD7HwXBtrm+XeTrmkrkQdSZHhtOwrnu+P22/lV+fGRSft3JeROpE8xkvDQ2LvEEsshbOh/O5 TUgtavYLRjrApF4HhRu5qZprNIRlR9aDk8QKcHB5+ZoJTJQAz4FMlFQ8wo2nvjUtzMoH7nZ0OztR ib1YWnVYUzq/VdsRa7YjQdWHf9Akxcitkasga7qhqkZKMeJU67r+3zLtYOu6Hr+VXzLzQudFgM6L AJ0XgZvIyq/iJpDP+GlEtsgrWdifLUXp7tlosTlAZ5mAzrQAPhhdEj8zf1m02X084a0A+8vI30wg GgLjPcKiSZPjTIjAB7C92gFcQKdZKM+vM5j7mavwD8FPaa2VVjKMYT4WZOViZ3s19q5ag31fc2Lj siDTd16ZaBteebULS1blqmc8bKEzHiocWH91Ov7Ld8aD6bLwpkQCRdCSIRBAXsgzIfbjyQO3Y/c/ L/KlXYnn5bm5vviXXEMn4W3ZhJ8cNmLzFy5C+9O3oWhLM8jKL/5BJjGBfJQzJ6JJI4jFMmVWfAku W5qDNFqAsHM9nWlhr8RfaD1BRlC47KBlcMr5GGHYPfapcycktyweu+klwKuw4sOfFUh8uEZMNSVV GiG0j7aKSz7VFifukEM+NDSkOP+372fA39dpkGuoslZuRlPlNqzLfxLF4n5k+8MGWbV1U7r3RrBm 64+ifqfiomCPIBlC+ypSbfhXKWlZ1/Vbyr1g+R2qxd41S0GPbHIG1JgdWEk6L/S8CK18IlkKDk3D l4XyFWzhd9dPG2FEKRam0gFK5CqqaBmC3Yw/9XuxODsHa4pJzxUtxemG3STieUoYLUvAS1JfGKkr JST9CeLl9+JvJpCsBNgab4xrVm/WVUOt2sbDmu1ErOsGMEew8hsIM95FlGmMsHBjeJDsCWdmIC3M K9RIuNGCxIOd3trL6BIn9y9/r4T3fERfz2H++USfGMfUH4FQq7ZxsWY7Aeu6ATITtdgbiBDmIso0 RljIczDCpOvzGgk3Okxc2I3Ogn8xgYQiwAokoapLn8KydV191gtLxQTiTYAVSLwJz4T02bruTKhl LiMTGEOAl/GOQcIeTIAJMAEmMBEC3AOZCKVkC+PuQHl6PhpCymUsq8JjtfcjeDVwSBD+meQE5KT+ THO0I31GFZl2qMesvKxAYoYysRI6SetNm2z/ic9/AooRRs+pbjy3uQj56y/G0KH1GGd3SGIVlqWd FIFYPmAmlTEHjjuBWL8g8BBW3KtMrxlciE/RZrrsnBzk0GexoRD/cgttgjhxWjmrXMvqLTCAg34L wfS2entta+BcknAWa2XppdXagvL6QDh5Hor/t2qJtxxbywvI4m8BnvnpkyjxWfstIIvBfou90cij V/IsFxNIFgLcA0mWmpx0OWgnvMWO82gnvNzY/tcTv8LODWQfquJWpPccxJwVpWQI2AzHjXPx87vy kLca6LfdC1fz97GO9uC1d/dirqMZS4uKsPg62gCZeggLizYpcbqvPw8HbluB/HkfoZc2N87+8H20 yfEy2ncnnffD04HfXs/7aJY3K6pRe38PNn7jLkqjBd3XX4DnLl2BPHwKrkeABZOU514eh1Nh818m EEcCrEDiCFfPSV8kd8KvyhslYnHVIfR+rxh/qi8h/0psvfka5WCrbzzciC15pTjS8118pu89unca x//0HnKvK0O/40akZ2fhraefp83odajZWAi5z/7+ly1oylyBgx1b8a3QreWhv2lvuOWxe3HOvxbQ Tu4aPLbxBmUIbWe3GUvevABdv3ho0vJQBHZMgAnEmQAPYcUZsF6TP0kP7Xanh8z5e+Bor1HEnH3x Ip9V39n0m4w0zsnEHPrMI+UhnbSca7jtx6AzNLBhTT7mZdK9u57HsX43pE4Ib7E22LiXkkzIH2mz S7X4q+iVoiWKApKB0hYXYn3xMnwck5cnJBP+yQSYQBwIsAKJA9RESTI1VXZAU5BD9rRsdApUw4Y8 1NuHEcnq7WDfKVx738sQrn7Y2ptQ1rwTFQ2/U4bB7Pa3g05F9Jt6J7Wg6BC3+iXhKEf6BlHyWeJV gpnfCaTh7TmMHTvq0ec+SdrJBDr0aYwlXy15glLnSybABOJEgBVInMAmWrKGjY+gioTeUPoE0qXl XLu0nNtFD/NhtJLl3BVFq9BHyuaPz9N8yML7YXdlwnD1lViiFPQc1dpvA1n7PdoDt3sAzT5rv18k a78p58kexDa8QPeGB+x4NJ/MKRqlKUaf81niXXSdmm89hfO6+9Bw3xrstrjx2eWTl8efNH8zASYQ RwJTcWpVrPJIhBPEqKpiVdz4paOcOjhykp4/o8DRrU1/FJY6OqnPd4Qtvf4LspyrBnNaxXblJER5 GiJ9jFXCJs+DFS7RbqoIimMUjXRaoS+SaKw0BO4ZZXz/8bzyBEZDjVBP9/WE5FshzA4XJRHqPxF5 fFnr/Etv7UVv8ui8+hJOvFjXL1vjJaKxdEllXTWC1Vv38DD1TlKQkSGnzEdcJIu1ahwyZJgxztoN X76ZWdR7GUma1gMPY9AFpJP/6FzlrfDyBEfX47Xe2ove5NFjnSWyTLGu31H/PhMZDMseBwIRrN6m ZYTfahjJYq1WnDGSa+Wr5U8JTDjtMZmxBxNgAtES4DmQaMlxPCbABJjADCfACmSGNwAuPhNgAkwg WgKsQKIlx/GYABNgAjOcAM+BxKEByIkqdkyACTCBZCfACiTGNUzr+mKcIifHBJgAE9AnAR7C0me9 sFRMgAkwAd0TSKh9ILqnyQIygQQnEOt9AgmOI+nEj3X9xqAHQsYuaBOX2+1NOthcICbABJgAE9Am cBYKZBDNtbfTIUCpyCSrrOnpqSjYWo8et3Zm4e4M22sxK682cNhQuDDSTx5KJLXnrJJaOtIo2HnR ukseRlSOjuFg/9DrYRw9UI+uiGGAicoTmjr/ZgJMgAnMNAJRKpBhHCifg5ItH6LJ0g3nkBO9nXR2 w94NWLhmHwYnQTEtlYzq+YzpRYrm9ZxWbzdvgaUvqLfj7kTdzja657uvlYj3LawqfRwfjrdsQDEJ e85oExpaabI/E2AC+iHg7kABnWr5WshLop3Ot5lVsG/cl1T9FCRxJIlKgbjtDShtABq7f4KvLV+M rIwsZOcWoqazCRVXAEP0fNc63lSisR/cgzzZm6DKvvORp0dZZtU+unQEatN/dQZ+DLz+c5AoPudF x4FdvrQp/bxyHOiQ/RVSeBvy6duO/PTbAz2V4637xh6fKg+lsP8W+/3HtlIaB/3nqvpy4S8mwAQS iICbXi4/SCB5E0jUqBTI0IB8KFfiusWjTdql5X4NzzyxEXM665XjTefTkajd3RasO7mNjjfdTebA gcGOfchbtw3rmizott6J9xpGuh9eOkpVHl0q4zkcNtx2ehsdpbonaMiqDI11lXRuRYvPz40j++k8 ClMdiintD15/HPmlO1HWYlXim1aQolv/79QjyoDxzjoY6D+T+TtYQmK7jx/EpXQE6/w76PhUknFF A+W1+SAZCJRmxvdjy8lrYe20ouZzDVhX+iK/vRAVdkwgsQkM4KD/xZBeYG+vbQ38u9Z6cXV3HURJ QTm2lsth8gI0T3aMPrGBjS99NPaIrTXGgDnucPHV+3Vk4NvnhizCQKa/a6xDIvRev3l7wJy3zVRM mygqRadzSDjp029rVEyANzk8YshmousyYXVYhJHSapLWxV0yXaNoJ79i+v6v31tFi7mTjH/TrSGn sDaRSXK/qXCPjeIZhdUnlCKH/54M320WdYesYlDJxyAsqn1x4eqU+VaKbpkoOyaQ5AToiZG4JdQ4 psBmoueVwST+cEgeN1Am2rt7RadZ/ruGqKYjBzyOJuW6wmQW9OIqaorpuAFDtegnEupzh35XVAtT TZ3oDjzUEhNTrOs3qh7IEnnwT1sLToyZMB9Ex2sdGKZ5hEjHmxrW5gXMcWfOnR80B6J9dCkVnNxp pGZfgTupu/HCK10YeL0ZduO3cXX2+coMSGbOfDj/ZxtS6e0iPXMO8tftBS70HVzkVSY3cMY3faJ1 fGoK5BGr65DjMzarRvsdBsaUVRGI/zABJqAzAudozHOe7nuPJD2J4396DxdeU4Z+hwN35GWh8xcv kH8ltt58DS0IWoRvPNxIz6RtONLjn2s1wvLYvdi4eT1CBl10VvKpFycqBZL2iWyStBk/f3X0eqjB o08if0U+fj0soHm8KcW0m+VJd6rzBh1vGukoVTX0aToWNQ2rN1Wi+QdP4NGdu1G51Ug+qnI4/nwp SnfPRovNgSGPwJC1msa1pEIYcf7GpcQIc3zqu3+nsIZPKKdwj8SCMrAV/FvrWlkppszvyDke/jCD 8duAVlti/2gItKHrndC3PfliegZLbvsxTBV06uaafMyjlaPz7noex/pl2EgvrvL5cQWyR4/WRyNY UsaJSoGkLP4KWiqBnUVFqD3cgYHBAXS11mP1qp3UQ2zE1wuLAI3jTS++spB0TykaXuujQ4C68PTd I8ebLopwlGqAPtX33OtuhtG+H3vbjLi5kJSZTxt5FV2xBJctzUHaYAceXU9p20/gL/K+crMNr7za hWH6rXV8aubHKezItEwgWyXpwK/IF9S5leMA/GEG47aByC2J706KgO85cHyATh0Lcid+2wysuATe vlO49r6XIVz9sLU3oayZ5k8bfodxX1wNizBHo1cTlM3MvIx6JM/TKxq3lyljh0RO+TZW1gnlBNKI x5t6RHvN6Hj+400jHV3q6qyjPIoFTaOQc4nGMjku2aTOs/jGPs3WQ8r8iF+eiip5LKtBtPTKCYxe US3HNuW4p0UetRp6TKp6fOrQqCNW/WOgxcI2wbFPmT47JjBRAnprL3qTZ6Ic1XBOYVL+jZeJJkun 6O11CLPvaObKFoewVMl//5V0BDP9Y3Z1iyr6t2qotgqnhY5Vls+Flk7h8gwJc42ci4Vop8eE8jyA /8jlyUmjx9Cxrt+zf9p5XGLI6RRDrrGzzB4XTYYPDSmT2qEw1XsaT2UZjybRNe6GJhXyW8pDcceK o4Rzhd7w5aURPCTt8X/GuoLGz3G8ELQAgepgTLnHi8b3p4SA3tqL3uSZdCX0W8V234uiLIv8VNS0 COW900n3jKqfcs9YRcpE5hD6MmkQNWa5SsenQIIW2yieCfwn1vXLtrCIaCydHPOn9hXLJKNMS1oK +H9os+f+QHzqIeL53euRM4nxXLkzP7OU9vbYNtNiaA1HG7jK0/OD9uOo4YxlVXis9n4sy9KIN+Xe 0hrBQcwtXo9czcJMrVD6aS9qufUmT7S14XUPY4hGstIzM5AWMvzkJtNLXtoqnJER8g+B4gzKOFkU J9qMdR4v1vUb1RyIzhmxeHLj5BRbCjhJe2yaaPFCL61scdCn22bGipM7kb++PrDWftorZqLWCKZd UBbgbAmkpGUgSyqCEOUh003LyBirPNQbapyzzXwGxU8oBfLQQw9BfthFJjA9lgIuxKdo8UJ2Tg5y 6LPYUIh/uYXWW5+QK+dUp7VZS94dsU6Qh607ylFw+wG8T/bPCspHFJC7q37Ub+30wm0YC2+NwCca fzEBJhAFgYRSIFGUb0ZGmR5LAR/AZrGjy26nJdx2HG3eh00b1NUvmVQLkawMBKwTHCILAp178Lvd DWh76zS8H76PtgYyQ+Fz3g9PB35HSq+n+ftYRwsCacMYaMMY9m8pwtMdnjHWCPzp8jcTYAJREkik +aAHH3xQyI+eHVXDtIs35ZYC3vqNKPNNWMry+z/FVYdEr28lRCQrA6HWCZztqnWCd+WKuKAVMMEr YiKlp94ziroWq+inBQS0YUzQviCaKx1tjWDaK4oE0EN7CeagN3mCZePrsycQ6/rlHggRTTY39ZYC /kb7e41od3pIe3rgaK9RkM6+eFHQBqxIm7VGWy5IvWB+2L04o+tJOz2D1oaxEGsEo9PjX0yACUyW ACuQyRJLgPBTbingkvMVKqmpcsYyBTkrN8NmKiOjl3mot6u2tcfbrGVvsfn3gyLFP2mifLsDcyiY oNWCQY0NY/6q81sj8P/mbybABKIjwAokOm66jjX1lgLk9v3RzrDxEVSR14bSJxQrzJGsDKg9pg14 9miPYp2g9qEtion/lPNkL2MbXiD/4QE7Hs0nywJG1bZZpPT++Hwe8hbeD7srE4arr8QSRTSKF2KN YLTE/IsJMIFJEzj7UbWpS4HnQCbBeiotBWhYQR2ySesBtJGrqZsE196sNfYezaMYTbT5yykaKw2B ORWj0e8vOURIT3PDWKg1gknwjFNQyUdPTm/y6IlNMsgS6/pNqI2E/iW8DzzwAHHQp4v1Rp2zLqXX jWF1RxUyQhbFK5utyH5QJq2LD10ur95LocPCwmypOpsNVxHiyjzdtF0x5Z19SF96BkNC3byobvxK o7X7oVISnQjpaW0Yc7u9SAthcdaco0xAb+1Fb/JEiZWjaRCIdf2G+RepkTN7JyaBFHrwZoVRAlQa ZbOVRqki3aOdWNBIUiO1IO8IcWWecoP48IfSyvO5gbkPufFL00VITyueXpSHZpn4BhNIEAKsQBKk omaSmGmLvgmLlXpGM6nQXFYmkIAEWIEkYKUlu8gpWYuxXDf2s5KdNpePCURPgFdhRc+OYzIBJsAE ZjQB7oHEofrlRBU7JsAEmECyE2AFEocapuV+cUiVk0xGAvyykYy1OnPKxENYM6euuaRMgAkwgZgS YAUSU5ycGBNgAkxg5hBgBTJz6jqGJR3GvoJZkMMvYz8FaH1lD/nvwaCSozwFsB5dZBJLnm44K69W PwdMxZAIJ8UEZiIBngOZibV+1mXOwD8924lrPalI/euv8c8rSvGlJgtuvfICfPhhKi6e74G53beP w3cKoNW1HsrOQPtZZ84JMAEmoBMC3APRSUUkmhhzF+fCkLsYuVcZsIiEn/+Zy7FY+hkWI+30MdS9 dIzMkow+BfB3fiu7vsJqnyiYaDRYXiYwMwmwApmZ9R67UtMZG8qZgZ4R7eA91YeGvX2UR8aoUwAv PXck20gnCo6E4qvpIDB2WDLcUCX7JSKnWLcnViCxJsrpAakjELKvyseF9N81nzcgI8jqe+cvXqBA ldh68zXIzFyEbzzcSIdIbcORHrLuyG7aCMgl6DPlQ9a9IT8zpbz+csaycfEcSCxpclpjCWieAug/ UXDvqDh97w8BOWzHZBQU/sEEdEqAeyA6rZhkEyv0FMDxTihMtvJzeZhAMhJgBZKMtTrdZRqZDhl9 CuDfRwSLdKLgSCi+YgJMQM8EeAhLz7WTELKl4qJQOeUciMHnmZGDNcXAlqKlONWwm/zPU25kLb8D lroTWLFmKR1aK50BNWYHVvLolUKD/8SWgP8wuuBU29ragn+OutbzoXWjBJ3mH6xAprkCEj77NANe CLH9lWHYDGHzlywb9x4S2Ow7BfD+Ur9/CpavfwLi67sw6ALSszIQ/tgrf3j+ZgJMQG8EWIHorUaS VB7NUwAjnCiYpCi4WNNAIFKPItK9aRA1obLkOZCEqi4WlgkwASagHwKsQPRTFywJE2ACTCChCLAC SajqYmGZABNgAvohwHMg+qmL6ZfE3YHy9Hw0jJLEgO11T2Hn+pWTnOSWVngPYm7xeuRmjErwrH9I q76ZNBk/ZNtMxlLYMYHxCfAqrPEZRROCFUg01JI4zklaTtto+Rn+8QLVeO7AsWasWrcKrvkOPHFD zsRLHmyFd+KxJhZS7jNhq74TY8WhmEA8CZB9lIRxZLdGyI+eHdWVnsWLLJvLKowwCqsrOJhH1Bkh DNUW4epsEsXGMlFZZqQze43ikMMlHGaToG0e8gxfYSirFtZ+D0UeEo1lqh9QIaxDQiOcmk+3TMOg hjdSGjan6h8+bUrdVkP51VAuie8Sur0kOP5EeJ7oHTHPgcRTOydo2n9zkUFDr5f+96Kv42d4vA34 Ul4OvJ730dzWgL3nrYGp5hZc0v9TLCzahPkmM7q7LVh3chvy5+1GX4gV3uzueo1wgPv4QVwq07ij RUljRcM25G0+iL/ateMkKFYWmwkkHQEewkq6Kj27Al2ENqyaE2ROVyZnrMLPrssGTig/YHnsXiyn yYeO2gK6V4eajYXK/Mj9L1vQlLkCBzu2YnOQFd6+/Zs1w133ylO0Cb0Gj228QZnP2NltxpI3L8Cf fnm3ZpxvhYh3diXm2EyACURLgBVIBHJHjhxR7q5evXpUKC3/UYES9IecA6lrr0f++TQHcuYMUi/I wdLcbMiGMowz9PcKZPu2jCsWS9bkjUyup5yjHC6lzJ4EWeGlpGDQCKfogqIlgTTSFhdi/WKa4qjV jpOgaDXF/u1vf4srr7xS8z7fYAJ6JcBDWBFqRtrKCWcvR8s/QlIJdOtC5F29DIZly7Bs+XI6dVBV HoECGBZhju+1Q5nLtr+N4BM8lMOlgg4EkVZ4I4WT92B+J5CGt+cwduyoRx8ZXrSPk3ZApgS/uPHG G3HnnXdicFA9RT7Bi8PizyACrEBmUGVPtKhngjVCaKSg1U8XX1kINKzDs0d74HYPoPmHd9MAWBm+ eBmNb3llb6UNr7zahTl52uEWXbeWNMUm1FMaXjedZHjfGuy2uPGZq7TjhIqU6L//8Ic/KEW47LLL 8K//+q/KAUfRlMnddQDKKXkltRgYlYAXrbsK6F45OoZH3ZjED7ksux5dUcefRFYcNGEIsAJJmKrS iaB+K7skztyV30O7qQKbVi1Eevo8lOwEGq21yJVDXEFWeH+WdptmuKxl0ipvpZJGavoCbGiogPn5 9bgkUtoSRZAc8mciu6ysLDz11FP4xS9+gWeffRbXXnst5LCWdH/729/wk5/8BFdddZXykdfSL5zz etT+H5q3wNIX9Bbg7kTdzjaK4rsfLvJ4fr5l2R/yoPd4pGbUfVYgM6q6xyls2jL8UvxSmSAPF1K1 shu8eS8NKzc+A49rCM6hIXgo7jeX+e2xq1Z4XS4P7l3+vyKE81nllWk4ZRrPoDBHaiDttMfKEU7a xPOT8yC/+tWvcNttt0EOa23atAmrVq3CT3/6Uzz22GPKR14XFBQoK+QilbDpvzoDtwde/3nI5lCg 77UDKJmlnmueV74Hdho9kz2YkpIdqN1VrvZkCspxUN6g2a8DG/Lp24789NuVXkxP675R8TsGVIXl 7jqIEoq3tVz2eArQ3OMOyMEXyUeAFUjy1emUlyhFWtTNyFAm2kMzD7bCGykcZBpk0j30BTdinNDM kuC3HIL61re+BTms1dfXh0svvRRmsxlyIYf8yOslS5bg5Zdf1ihtGRqpR9ewocU3jOXGkf07UWGq A+3XUZZBeHsOYsGKUmX5tcNhw22naen06j14j3owzc27seXktbB2WlA9uwHrNr9I6iMDxjvrqNNn gMn8HURalh261Puz83wrLjSkZe8EJ6D3jSrB8smNP4Rb959gmfmaCUQiEKk9z549W5hMpjHRpZ+8 54/rDzBkM5FfmbA6LLQhFKLJQXdcFmGgTZ/t5FdM3xbafWkzFVO4StHpHBLU6xP9tkYlrRf+v6fo Ww0j03QFb9j02AKbTK01RkHLt0Vgv+mQzAOihnaMqjKMpOGXTX775dXTt943Jgfz0+N1QvVApN1+ 2Q6n6kONC/ITmp+WvwzHjglMlkBo+5K/nU4njEYjfvnLX45J7pVXXkF9fX2gXY4OcBqp2VfgTupu vPBKFwZeb4bd+G1cnX1+0AzIbIqyF0vnZGIOfebllSpJvPtXOUdSiByfgbGgWRRaFKGsl4NcYBFx +XbIUu9g2cKVc7r9+CyQ4Bqa/HVCKZDJF49jMIHEIiAfqHIlllyRlZ2dTbvzu1FUVAS590h+5PVb b72FL3/5yxoFO03LptOwelMlmn/wBB7duRuVW43koyoAGclz5iQtQjCBLMbA46EXMk8/LOZ2/O8F 55L/JyDVi5Ybb1m2Ei9oqbdWOuyfHARYgSRHPU5PKbzHsUNOxJYfoHFydmdLQK68kiuw5EosuSKL hqrQ3t6Or3/967j77ruVj7yWvZKUlNDZoqDcad567nU3w2jfj71tRtxcSFYEgroTi65Rl07/5HAX eQ+j9enbsKJoFd7Dx+U8eXg3wWXZSmStNMKnzL4JTCBCK0zgUrHoU0Jg8I3/F7tlTg2laH3kn1Gc w80pGvByA+H3v/99vPTSS3jkkUewYcMGZRWUTOv888/Ht7/9beUzXtopqXLC2td/yLgC3y6jnTjn 3Ykr5JBU0GKorOVy6fQJrFizFNuURA2oMTvw+dk/H7s82r9cOmhZttvSR8uyT9IKsYXYpMQ3BpZv Ky8S/jjKPf6T1ASoy8xOgwDNdYS1/qvlL5OhxqKRWrJ5u0RjMUSxySyaKmlhQ5UlUMBwVnt7LY2j rPaqFnc9wtpYpUzASm4wlIlGa38gnZlwIcs9f/58cccdd9CEts8M8VQV3KVOogcmwyeQLy3LDoSi 5duClm+LEZ/ALb6YIQT4lTHC64GcxAzntPzDhU1av8FXUdoMNJkK8aWeamDFU7B/j0yf0Euwfykn KqrJau88fOaj/1SWjVaQ1V7HjXPx87vyaNko8NZ+IL90J6pbrPj6Zan4xSN5KF1/NdbQQVH+3SRJ yy+oYHK4alpsYcml05NcZTtmWXZQOfhy5hGYJRXlzCt2/Eos1/HPBKRdB8qxtHQJesX9yB62oyQz D59q6aVDp7IxbN+HzLwXYRlSNyXa95Ugb9On0OnchX8g9N6TzcrKn/r23+AfPJn4QmEuvMOD+MPh KuRXLZpRJw3OlPYSv39xnPJ0EuAeyHTST9i8+2iFT4Mi/YJZZL/E70zN2HnDRlrmKe1gjVjtVcfl 5bLRvf6QyvcpegNObdmG1CLqyvid0eS/4m8mwAR0ToBXYem8gvQonrvrv7CNVto0Wjppman8OGBr oWGs5k1oOe6brQ1ayqm1bPTSo5tQuns2WmwODNFy0iErpfGBVD7smAATSAQCrEASoZZ0JuOr/7aB NiybULw8F4sXy08ODDeUoYrkLD3wqipt0FJOrWWj756ZRWGX4LKlOUgb7MCj62lNkP0E/hK05FRn RWdxmAATCCLACiQIBl9OgIDbjjpau1u59UblBMGRGNlYV0frRnfW4c2PyDdoKae6bLQS22jZaHpq Joq2nFCWjd78la0wYicWps5C6rx8fLCukiKa8ad+1iAjXPmKCeiXAE+ix7hueFI0AlD3MAZdQDoZ TRxZ/OPG8KAXKZnkNwNn5Li9RGgvfEv3BFiBxLiK+IEQY6BJnhy3lySv4CQvHg9hJXkFc/GYABNg AvEiwAokXmQ5XSbABJhAkhNgBZLkFczFYwJMgAnEiwArkHiR1WO67g6US+u5wZ+8EuxrPT4l0g53 7KG890AekqrthnH0QD26yCrfxMJrp8R3mAATiC+BGbjuJb5A9Z76SVpf22j5Gf7xAjoXAh/irbZn UFJ0Kf54qBtPFC+Oq/hpi4pBx04gM1Iu3rewqvRxWF3rMaHwkdLie0yACcSVAPdA4opXj4lfiNwr aPNfbi5yc5eheOMzsJqKsbdkD477tl/0vXYAJb5eSl75HtgDXYYBHNxVHujB3F7bGjgH5HjrPpTk qb2bAl8cd9dBlBSUY2t5AcUpwKFjv0XdS8fwV/IvKLgdO7aWqGkVbMXRHrmDfRgHNuTTtx356bfj 9T8fU8L7LZH3yDyC5OoYUAV2d5G8JTtQ65eN8jw4IrQeK4FlYgLJQWCGWB2esmJSq5iyvCadkcuq nGstz8UOdq5OeZa2eo61x9GkmKQny7nC4bCJGjLZDkO1kEbWHYcq6F6ZaO/uFZ1mGQei2uoUrm5/ nBbR3W0R26Vp9rImMaic0U3XFdXCVFMnfv9qDcWpEe/6/A0VdaK7t1OYyigMqkQv5dFrqSPz7gZh MtvEu79Rw0txh2x1Sn5SLplHlXEkjnoOt8zHJKydFlEtZTaaREgxg4usm2tdtxfdUGJB9EpAx087 vSKLLJeuHwgaCkR9ABuFlZ64NlMxPagrRadTPSui39aoPLibHB7fPaOoa7GKfjoHot/hEGTDSlhr jKRkagIPbFe3WdQdsvoUiKqYJLUhW7ACofz8B1EMWZQzQZoc5OGxKUpO3vOHl4pAycNYJ/xRhC9O DQntl9+vGF2+fFiBRG6rfJcJnC0BHsKiJ/6Mdx7VgKH6V55oJy3nZmIOfebllSp4+t4fguG2H8NU AWxYk495mXTvrudxrN9N1nfJFS0J7C5PW1yI9cXLkDLGKq+SFP2ROa3FEv929JRzsIh83u6jbepe 9ezuMyHWTGQehjV5gTzgiyNnctT0CpEjT94jFxJV9eS/TIAJxJwAK5CYI9V/gueMWjrhxuFnttDT eS0W0wNYy3LuTYsyMdh3Ctfe9zKEqx+29iaUNe9ERcPvlEc4zO8EHtzensPYsaMe7/6dWARZ5R1N 5k38JcjjNF1fNDc94DNaRlVN2O1vB/KQAWUcqOqL8vmE/zBXxZf/MAEmEH8CrEDiz1hnObTB9moH Ojo68NrRw6jdugbr9gPVT30Dc0lSLcu5fdSf+OPzdJLgwvthd2XCcPWVZEdXOuo9XLeW5r03of5o D7zuPjTctwa7LW5kfpxuB1nlVTWNGgfYjycPdMDtHUTzD+9GGypx3WJ5nKHsnbThlVe7MOyfPSef i68spLPX1+FZysPtHvDFKcMXL/N1O4LzkVmwYwJMIO4ERr2Lxj03zmDaCVxEEmwokiudfM5Yhjpz N9avlOoDUC3nnsAKspxLxtXJGRTLuSvlGbPfsWJ7az7y/AdDGatg+/YyZGXlwVJHcVYtxCYlTgXM jvXIOEWaKcgqr9JZCPw24u0f5CNdGSEzoqlzF3Jk3IwcrCkGthQtxakGMvtrOE9Jce7K76HddBKr AnkY0WitRS7pHNoyMjqfcL+VVPgPE2ACsSTAxhRjSZPSShrjeGEt56qw3MPDNJSUgowM/ySGD6Iv TiZZ2430ZjJsr0Vm6Tl0dO1GYHAYaWHCu91eBJ+/7a8mL+UxRJMcmRmR8/CH1/t30rQXvYNm+eJC INK/87hkyIkmCAE6bjYrRD/4JU+jh3dYFyHOqPCeUzS0da4yopVFyiOcC6c8ZLgUmUe4COzHBJjA lBNgBTLlyDnDjCW3wGL1RN6RzpiYABPQPQEewopxFfGQRIyBJnly3F6SvIKTvHi8CivJK5iLxwSY ABOIFwFWIPEiq8d0w1njJdtSBeW70BGwd6VHwVkmJsAE9EiAFYgeayWOMklrvE02B3odDjjo020z Y8XJnchfXx8wjBjH7DlpJsAEkogAK5AkqsyJFeVCfGppDrJzcpBDn8WGQvzLLbTx4sTpwD6/8NZ4 tS3xRrKSW1A+opjcXfXU21F/h1rqbSZrvOEs+soyTVaeiXHgUEyACZwtAV6FdbYEEy7+B7BZ7DhP OQ8E+OuJX2Hnhmag4lZlVZS35yAWrCglw7ZmOG6ci5/fRbvPVwMdDx/Hup0AWeLFXEczlhYVYfF1 TtyReggLizYp4buvPw8HbluB/HkfoVfcj9kfvo+2BgL0ggrJ++HpwG+v5300y5sV1TDVzMOlw/+J S5V0WtB9/QV47tIVyMOn4HoEk5Ln3mW8yDfhmiQLnLgEztYaI8cfTYBawmgPPf0ia7xl0tR6yKe4 6pDo9Zm51bLG+9ijX6Z4GpZ4Na3kjpqttcgAACHWSURBVJhjlxiCreuGWtDVsuj7Ww3rwFry6An3 RGTRdXuZSAE4zIwmwENYiav7o5L8JIxod3pIy3ngaK9R0ph98SJkBzYNhrfGm/KFRzQt8WpbyY0k orR5dUUgXy2Lvh9XTCSOtQ6sJU+kHPkeE2ACsSXACiS2PBMitdRUOXKZgpyVm2Gj05waNuSh3q5Y lNK0xntd2t81LfFqWslVLLO7A3Mr8ARZR5Skgiz1KkHNYy369rlPUjgTnELA4xEQnn5Y6FxcLXkS ogJYSCaQJARYgSRJRUZbDMPGR1BFkTeUPoE++tayxvv6v18Z1hJvJCu5KefJ3sw2vEAWdIcH7Hg0 n8wzGs8ZETXIgq6WRd/PLl+rWPr9yeEusr81jNanb8OKolXQkmckcb5iAkwg7gRm9ABeHApPFRaH VGOUpOaJhL7jYpu6KSOPsNRVBs2TGESN2SGE0yq2G4PmT4xVwkbdAkFnBLab5FG3/ntG0UjH3KrO KRorDYF7Rhnfd9SsMh8SdIrh2HwrhFmeUDhpeXxZJ8iXrttLgjBkMaePAJsyibGKThrTFBrWeLUs 8UaykqvGSSPrvXLobBynZdF3kvKMk4tubidNe9ENURZkKgmwAokxbX4gxBhokifH7SXJKzjJi8dz IElewVw8JsAEmEC8CLACiRdZTpcJMAEmkOQEWIEkeQVz8ZgAE2AC8SLACiReZDldJsAEmECSE2AF kuQVzMVjAkyACcSLACuQeJHldJkAE2ACSU5gAgvzk5xAHIonl2ayYwKJSIDbbiLW2uRkpm2Hk4sQ ITQrkAhworkVy8qJJn89xnnooYcUsR544AE9iscyhRDgNhwCJIl+xvoFgYewkqhxcFGYABNgAlNJ gBXIVNLmvJgAE2ACSUSAFUgSVSYXhQkwASYwlQR4DmQqac+AvB588MExpTxy5IjiF25sPVz4MQmw BxNgArokwD0QXVYLC8UEmAAT0D8Btsar/zpKaAl7e3tx1113KWX48Y9/jAULFiR0eZJdeLYOnNw1 HOv65R5IcreXaS3dU089hZycHJw6dUr5yGvpx44JMIHkIMA9kOSoR92V4sSJEygsLER9fT1Wr16t yCfnQtavX4/W1lYsWrRIdzKzQECs31CZqb4IxLp+uQeir/pNGmlefvll3HrrrQHlIQsmFYn0k/fY MQEmkPgEWIEkfh1yCZgAE2AC00KAFci0YE/+TL/85S/jueeeg38JryyxvJZ+8h47JsAEEp8A7wNJ /DrUZQnkHMc999yjzIMYjUZFxra2NtTW1vL8hy5rjIViApMnwJPok2fGMSZBgJfxTgKWDoLGepJV B0ViEYIIxLp+uQcSBJcvY09A7vv43Oc+pyTMe0Biz5dTZALTSYDnQKaTPufNBJgAE0hgAqxAErjy WHQmwASYwHQSYAUynfQ5bybABJhAAhNgBZLAlceiMwEmMBUEvHAPD2PY7Z6KzBIqD1YgCVVdiSms PMqWj7NNzLqLXuph7CuYhZL6rkAS3p5m5M0iv9rXAn4YaFX8Dhyf+MN52L4Ps/JqMTySinI13LGH TLHswWCIf/Q/3Thav4vkS0V6ZiYy09Mp/RLUv9YXfZJJFpMVSJJVKBeHCeiDQAY+Wwg0/0cH/KrB 8Zv/AzsJ1/zsf8P/CB6w/w/5VeAfF6ZNXGzPGSgJhcRIW1QMc3sxMkP8o/vpReuua7BqQxPuaLGi 1+mEs9+Blpr52LBiAeq7QtVXdLkkeixWIIleg9Mov7urXnkj6wjzb2kib4Nab5LTWCTOOoYELjdW kbY4gne8MtFhHH1qPyrrGlFs34k3ehRP2P9nN1BxExbShoKe1n0ooR6K3KuQV74HHQNqGHfXQZQU lGNreQHdK8D/ed8zIuVgB7ZST6d8z1G4ncdQ99IxRWG5uw6gpGQHaneVK+nNovgH7WrfxH5wj9Lr mTUrD7v21aKcwnX5tZwvZe/xn6Nopx0m6xFsvGEZsrOykDU3BzdsrkFTZRn6+5xKyFDZmnvcYcsh 5Skorw/0muS/Hf9vmUZBwe3YsbXEJ+tWHKV0EsLRKXHsmEBUBIZsJgEYhXVobHSPs1OY2zuFZ+yt gM+QtYbi14gw0QNh+GJqCdBDK3YZOtuFgdJrclCSLqsw0nW70ykajRBljd3k2S9IxYjKFocYstVR W4CoMJlFd7dFVFEYoEr0Uii1ndHvimphqqkTv7dQuzHUiSFPt6ikOCiuUcMFtaeROCZh7bSI6mIK ZzSJP1tlm4XY3mgR3dZDoljGR7GwhDTCIZtsm8XC5oqMYyQfn2yvhy/HW0GyyRSD274/DUNFneju 7RSmMimTWvbIuU/+rix7LF1sU4ulZJyW7gmoDT+8AnF1N4myyiYx0Nkoiou3i5qqMuUfLoxlosnm VMqm/iP1KRCnVVQa6cFS3R5R6egeSoILGNsHjFPUGEgptPQKl61aeSjKmu+sK6aHfpMYGmpX2kRL vxDWGiM94OtE4Hk9ZFGUTw29nfjbmf8hr/4uFhXUXoIftMHtKTSOS1EINeI1mU9xY6CNDVmkXGPb sONQJflvF1L3KY4UYJmibGSeVKY6m+Idmo9WOfa8uIfijbwshZPV6i+8r+xNDr+HT4YYfMW2foXg ISwiyi72BLyn+tCwtw9ez2k0N+/GlpPXgt4EUT27Aes2v6h25eVIhGE24D2OrXPysXd2DarvXQk2 jxD7+pieFLNw3W1G7G9/A20tDfSsNyKLBLlk+Voa2vpvvNLaRr+qkD8XSKUrw5o8BGZCUs6BemKM bCQ054ErkB24ST/RjP1t8tuJ02FHe2ScQuRkyDDUxNQvON5sg6Eod6SNnU/tL4ybs+gz5GvB+/60 Uy7GhkNNONRyCDWkSd467R9GGy2bdjn+HiYXv5dMYy2W+MvnK/vbfS5/AN1+swLRbdUkuGDyX1LA GWF5bCOW5S7H5odrgDb5D4Zc6jk0GfofuPv6S7GXHiS9hzYjW73Df5OEwJLrbgZ2fx/3brOj+vrL lVKlXbqcps33Y03JThirrwfpD8jHsd3+duBBLwOeln8U1UJfhkWYE3izkO1nO7qdnaiklrO06rAM ONYZPoFQ9ZD9WSPsrwflIyfkw7iM+ZfAgDY885Kc9ieXMheFxV9D8Q3FKLjagA/8ikXeC5JNsxze j1NAt1JOGQWe4ASkx5v4i/zyOVn2i+am+3/q9psViG6rJlkEk/9Ax74JjpRuvDfJkZB8lXgEMi67 FsW0ZMoOI75wuex/kEu5BNdXqJdrvyDf9IGLrywEGtbh2aM9cLsH0PzDu+nxXYYvXubrQvie40pg +ZQ2zMeCrFzsbK8mBbUG+zpogtzfKVAC0Z/gOD6/SwtuUfJ5vLkDfcdbcXf+FrozW+nj+KMp33Nv QL2pGPtL82iC/iDsx3vQc7wDB/bcjrwtdlzo7y3IwEH5aJbjs1JNbsMLVL7hATsezd9GI2f0AqU4 +b0fTx6gFWveQV/ZK3Hd4uBMfEF19hXQ6TqTi8VJJALjtaIwb4Jq8fxvkv+CJ+cspTfJ/w3x6A2J VHKWdTwCaYuwloZ8mk/fjCU+XQAaqLrmJpr+3v82rluiKpW5K7+HdtNJrFq1EJuUNI1otNYil56h yiI/mo0POF/vVg5LZa3cTKuitmFd/pMosn2CFEsg1Ohr6U33Mgzr0d3Sj0vX5NPj3ICyMvJsuArZ AdlG4i/b+CIss3+I7aXrkEfPe9UZUFVnxnfKlvk9RuWjVQ5pT7Sx0oBSKp9UWUbjSHT1yoi3f5CP 9FL5y4imzl3ICQ2iw99szl2HlZIoIslluJl5T6POXI+8C2ikWhkNOIO5n7kK/3DiaWTmA+/agP+V BwyJzZD/RofttRRH/Y0Oul4PuGyb4Tq6B3NWbaNlk05sXOZ7U00UEEkkZ6zNfU8Wjdc9jCHSDJkZ GSPzFJNNJEL44827sKfrWtTcW6jMt/Q0346FJZ8NtM/wUeVOdDcNr6UgLSNtQnJplUPuaPdSzhkZ I29dyr+J0nMwZNsIDA4jLSs+ZZdli3X9jpQiPDn2ZQKaBFJSZRfbjg1FpCmCXLXFiTvOJw//26D/ 2x/G/1vjTbJY3M9zIX5WM+w7JS1DmWiPV7EXXvE57C8pwv6WClReZMHeBjsqmzqVlxvtPKXiCNNF 0Y4ArXKETcdziv4ZnauMwGWR8kgkxz2QRKotlpUJxJlArN9Q4yxuVMm7+7rQ9moHrd/KQO6VK7Fs 8TT3eId78NpbHly1bPGEejdRFdoXKdb1ywrkbGqD4zKBJCMQ6wdMkuFJ+OLEun4/lvBEuABMgAkw ASYwLQRYgUwL9pmV6UMPPQT5YccEmEByEWAFklz1yaVhAkyACUwZAVYgU4aaM2ICTIAJJBcBViDJ VZ9cGibABJjAlBFgBTJlqDkjJsAEmEByEWAFklz1yaVhAkyACUwZAd6JPmWoZ2ZGvb29+P3vf68U Xl4vWLBgZoLgUjOBJCTAPZAkrFS9FOmpp55CTk4OTp06pXzktfRjxwSYQHIQ4J3oyVGPuivFiRMn UFhYiPr6eqxevVqR78iRI1i/fj1aW1uxaJF6XJDuBJ/hAsV6p/IMx6m74se6frkHorsqTg6BXn75 Zdx6660B5SFLJRWJ9JP32DEBJpD4BFiBJH4dcgmYABNgAtNCgBXItGBP/ky//OUv47nnnoMctvI7 eS395D12TIAJJD4BXoWV+HWoyxLIOY577rlHmQf5/Oc/r8j46quvora2luc/dFljLBQTmDwB7oFM nhnHmCCBL33pS7jgggtw/vnnKx95Lf3YMQEmkBwEeBVWctSjLkvx1a9+Ffn5+fB65enVQEpKCqxW K1566SVdystCxf7IU2aqLwK8Cktf9cHSaBA4fPgwjh07pgxj+YPIIS3pJ++xYwJMIPEJ8BxI4teh 7krw0UcfYfPmzcp8x7nnnhuQT17LORB5z263I/heIBBfTDsB+ZbKjglMhADPgUyEEoeZFIEf/ehH uPzyy3HDDTeMiSf95D0Zhp3+CAghMFM+Dz74IORnppTXX85YtjrugcSSJqcFh8OBvXv34o033tCk 8cQTT+Cqq65CWVkZFi5cqBmObzABJqBvAtwD0Xf9JJx0W7duRWVlZUTFIJWGDCPDsmMCTCBxCbAC Sdy6053kr7/++piJcy0h/RPqMg47JsAEEpMAL+ONcb3xBGSMgc6A5OTYNLv4EpBzHaHObyXBb+wz +H648MH3+VolwHMgcWgJ/ECIA9QkTZJfOJK0YmdIsbgHEuOKjvVGnRiLx8npjAC3l+mpEHm42V13 3aVk/uMf/5gPOouyGngOJEpwHI0JMIHEJMAHncWu3rgHEjuWSkr8RhljoEmeHLeXqa1gPugstry5 BxJbnpwaE2ACOibAB53FtnJYgcSWJ6fGBJgAE5gxBFiBzJiq5oIyASbAB53Ftg3wMt7Y8uTUmAAT 0DGB4IPOjEajImlbWxsfdBZlnfEkepTgtKLxpKgWGfYPR4DbSzgq8ffjZbyxYcw9kNhw5FSYABNI IAILFizA5z73OUViec0uOgI8BxIdN47FBJgAE5jxBFiBzJAm4B4exrDbPaWllXm6fcfZTmnGnBkT YAJTQoAVyJRgnr5M+l6rRwGdMJeemYnM9HTMmlWO5q7hmAs03LGH0t6DQSXlYRzcmqfkmZ76T0H+ 0WQ7jKMH6iFFHp1HNGlxHCbABGJJgBVILGnqLa3h11C6YgOuqGtHb78T/b3daKo6iZKlX0ZHjDsj aYuKYW4vRqZk4H0LT+21o7rdgaG+qhH/aPhQWqtKH8eHNFs3Ko9o0uI4TIAJxJQAK5CY4tRXYt6/ nEQbiXTt8iuRPTcLc7MX42vbn4Wpai3OON1wdx1EQcHt2LG1hHoJszCrYCuO9oxolr7XDqBE+tMn r3wP7Gr3Asdb96EkT/Uv8Pl7ncdQ99IxuN1d2Jqar+S7bdWX8O+/tav+PjTh4pLGQceBXcjz5TUr rxwHOgYoxjAObMinbzvy02/H63/25eFLq0fKESRfx4BXuePuIrlLdqB2V7mvXOU46BfeF5e/mAAT iAEBMj3OLoYEqEpimNrZJtUrqo2Qh00IY1mlMDUeEjaHM5DokM2k3DNU1Inu3k5hKpNhq0QvhfA4 mpR7FSazcDhsoqaY7hmqxZ+7/f4torvbIrZT2ihrEoPWGgpfI4aES3S319G1QdSZreKtXz7h8xfC pRG331Kt5FXdYlXyMlXIvGqElLTXUicMlJbJbBPv/safhxBDNpkHhJRPylGllFOV3V8uVJiEtdMi qqXsRhPJpj+nr/aiPz7xlIjO/BDywy56Anp62kVfCh3F1N8DwSnaG2tEmdGgPHClfFJh9BMz9UFr FFaXD+CQhR7WEE0Ol7CZiil8peh0DgknffptjUr8PQ+uVh7u/oexq9ss6g5ZxaBt5OEuPDZhhJru UJC/tcYYNm5/t1W0mDuFh8RwDTmFtalyJFyktIx1pK5Gy15jHQqUy+IT0hUkgz+4Xr711170Qib+ crACOXvGPIRF/4KT1XkH+3D8uBcrv7kZL/zSBo/LCUtTFez7N6DuNTkedYY+a7EkzUcg5Rwsosu3 +1z0dzZ99mLpnEzMoc+8vFIl0AfDfweKlsAfJW1xIdYXL8OoDUVejxL2jDqipFzLP6nyT5i4cxfO h/N/tiGVhqPSM+cgf91e4MJzZGga3dJOy7AmLyAHfLIDMrwsVyFyMmQCcoCMHRNgAvEgwAokHlR1 kmbni6W49NJH0eeTJyUtC8u/9j2YqJthf/svPt834b+SHqfpc9HcdHjOnKRRKBNoGAkej4Dw9MNi bsfnL/w4YH4n8FD29hzGjh31eJf0ynhOUQVh4rbuL0Xp7tlosdGkO+U1ZK0GPpBKYMSdM0pDqWrC bn87IIcMKWX3qSmS/ROKClS8dPrngw8+UCT76le/CofDoVMpWSwmoE2AFYg2m4S/s/TGO6kMe7Gg vBavdfWgr6cLzbXfxiY7dQSWXUL35Fv+fjx5oIP2awyi+Yd30+R3Ja5bnIZF16wlLbMJPzncRQ/p YbQ+fRtWFK1CyvKvKv71R3vgdfeh4b412G1xI/P/p6TCObUDodxZdJ2aZmjcc5QuwhJctjQHaYMd eHT9NsrjBP4i/b1SkbThlVe7aB/LSAYXX1kINKzDsySH2z3gk70MX7zM1+2gMurdXXjhhYqI+fn5 uOqqq/DII4/go48+mnKx3V316mID/yIG+U0LKlqDFlSEE2rYXotZebXUOtjNWAJnPwrGKQQToIYU /HPar3tpQruYZJJyqR+DqD7UqcjlnwMpNvjvGUVTp392wyMsdTQXERSvxuygeKH+FcJMcybKXAdN fCuxXVZlDkTOQYzy14rbeYjC+2WgifEqma9BtPTKWRFaCCAnwel+VcPukbkRmv1oN1UEyWcUjVZ1 gcDoPENlmPYqGSWALJd077zzjli7dq349Kc/LVpaWkaFOXnypHj++eeVj7yOtVPbgUE0WTpFd2en 6LRZhKlSzpltF7LGtdxQYOGEVgh9+/McyNnXj76edmdfnmlPwf9AmHZBQgRwDdHkMn3kI9nv1Aet ujppiCbKg+/5w9CstjKJHpis9t/w+YeN4w+j9R02LikhksGlkaBL44ZHphVSLq1s9egf2l6k8pBK RCoTqVSefPJJ8bGPfUzceOONykdeS79YOlWBFAtbUKKeTrlCzyD8CxF6LY2BFxFDWbWwka5W2o+y 8k6N6DCbRoWx9quV6eqkuMXbRU1VmarwjWWiSSbgc7amamXxhsyvykQLPihsp6tfNPnDk5KtqDHH fBUdKxB/DUT/zQokenZhY4Y+EMIG0onnkLWK/kFXK8tldSLSjBMjXHtxu93i4YcfFjTEJbKzswWZ Gw9wkdeXXHKJePvttwN+Z3uhKhDq4dU1iqbGRtFoqlYUgaGqXUlaa0n3iaDVbdEuq3Za1aXk2xst ott6yKeAisV/vCh7l2WivbtXdJJikpyqfT3Msy2vPz4rED+J6L9DpiapmtjNGAIZS26BxepRd4/P mFLrr6APPfRQWKGWLVuGVatWYfXq1YH78vrWW29FZWUl5P2zcQ888MCo6E2P/0D9bbfT1k1ybx1H n3clPvjFC/SjEltvvkZpK994uBFbaFXeK+8+Tv60qILcW798HjDWoWZjobIy7v6XLWjKXIGDHVvx LWX5nRGWxzZiGU1RXfZwDbblqYskTr7yIlDciKpvLldW8jVaqpG5ogVn3pWpnsbxP72H3OvK0O+4 EenZWdIz4LS4BQKMc1FfX4/169ePE4pvRyLAk+iR6CT7vYwcLF+2ePQS3GQvM5dPg4AR9b+xwWaj D628G+psokUKG/DcG3K5d/gl3e/+dWTCX+qIaJZVn3izDYai3JE2eL7MC7j0lh+DNpRiw5p8zCM7 bvPueh7H+oNWUSihzu6PVB7+Q6XOLqWZG5t7IDOm7t20iikFGWmxrHJan0VLo1JS0pAW03RjUCle Kq83jcobg7TinERoT0CuxPrRj36Ejo4OvPnmm1i5cmWgF3LkyBE899xzaG1thTxdL14uI/dylFHi TrKhFljSbduITFoZl4IBvNbehfPOfQP3+gSQi+3UZdUje4Imsqz6os8aYX9dLsf2xfOoPZPT757C tfe9DFHjovtHsGfVOlRcez1s9y4PFDmUW+AGX0wZAe6BTBnq6czIjQMl6Sh9qRtwd6A8eLmm77qg fBc6fLautMLIJZtqEFryW3s7Lf1MRSa9Haanp6Jgaz3GWfU5OQBuuyJnbUCooOjhypBXgn2txwOB vH3/SdaHS9CRYGtMDx8+DIPBAKvVqnx27NiBwsJC3HTTTcpHXt9zzz1xUB4fwPZqh6K0Ol5rRe3W TWggmtd+doHmku73fMNXEnq0y6qXFNyiLMd+vLkDfcdbcXf+FkptNo4fyEPewvthd2XCcPWVWCIz UZadKxf8Ry8Eop8+4ZjhCFC9hvOeVj+nYmtqu2LjSihLbGnJps0heh0Osj3lEN02s9hupKWyxXWB Zbhy6W9FYzvZmaJlnXJpZ6dNdNKEpodCNCo2s2gljaWbVkA5RW+nWdBog2JvamRtzVkWWZGTXkDD TZz6ytDoX3baaRWHfEt6Kw91BzK2VNNS1Epz4LceL/ztZTqX8bo6VbtiUpbAx1AsalrU5d5jl24b hFzSPXq5dPTLqrtbVFtochVWWZlcPlwlHE6r2ib9MhmrlJVfeqzDmSyT/p52CV4b/geCforRL2hf t6hokSYSySkPX7JTFbJctrOObF/5DBiqYSBMnSGBZHSfAcbG7tELe12dTaKi0iQcY6MI7eWdTaKY lnRWlhnpoWEUh2g/ScCNq0CCbHj5IlkV+10Votsvg9OsPBBbpOEvnTrZXuSKq09+8pPKt1yBpVun taQ7SODJLqvuPlQlKqrNAZtmjkNy9ZVvPxGlqy4/D2oXQXnx5fQTiOWAOP1bYKc7AgN2bIMB5vzs INFouMJix3kXqCZB/nriV9i5oRmouDWwIktOZbY0/QxLrp2DMzQsLT+fXfkFzB6QZtbV3epBCSIt 92t45olgH/V62F6PhUWbyDCuGd3Xn4cDt61A/ryP0Cvux2zP+2huo4GSimqYaubhs/MmN2ERamvr MuMayvRFDNBc62K5IT3rStSQ2ZbG/+7CDd/MHSvcNPv4TZnI4ao33ngDCxcunGaJxsk+LQNZ41RR igwzTjLBtxde8TnsLynC/pYKVF5kwd4GOyqbOuGzJ4C0DP9VcCy+1gsBViB6qYk4yTFMZ2iQZUJc kD6SwUW0SHPDqrwRD7oqrjqE3u8VB1bDSAXSsLMUpFYCzmQbwjXHWqmzcDPmBHwjX0xseee9WB7h OeF1y6NxffnQhL1WUJ/dxaCR8kwsKQKePfnXyEJO012/KZOXXnppmiSY/mxTcorh6u1EG82/OHET rA+uxLLFk1FB01+G/9ve/YXmFMdxHP+oPcvyL8rNwx7WxKM8I4uSxmo3lESRjJXdcbPmQu5WlFy4 EPkTLubClHIh0XaDmcINai4mbWmFiylTIyu78Pudx54/ZjYczvfM+9Tm7HnOc873vL6P5/v8zvmd 3/mfI+Ak+lTPftAHf7MqCj51X6tWXe+/uMOXX9TfdSoQmF1eoWTBt0vfg8ZduOUPceZ+9mdmaqkf z6qzXa/G9Kgc1NPHT4Nv/4WkE3fvXFW03cLXZuc/6dxadztef0ve4La8576dyB+7pOsuFDyY/e1n S7R4Wa37t9T/wWRUYHoyrU076lW/YyvFw2iOxguLAjKezFR5PBjM0H3gf9cbKZHwjc8SpWqa1O3u JHWlsUqXn+cX8gWkoJ7kNKbPSbr5m7rx0B/Kyk+DD86oel217g+MNhWyz+W7d+aX9evOj5pboXk/ bQfPUMOtXnX39MidyFdPf0PuEEnxCL3D6rjgevBktmcPXwXbGNHLZ53BHL8QQCB8AQpI+Kam1jiz fMWE8WT2H9NRt1TjnpO5od/He1FJ5Ta1N0stdXU63eFaHIPv9OLuZW3c0OJGnmjTllRxNfjd7p2F 25+bqlQmnVY6nVE6NXp4ozPX7fTxgw7X7XSzdl50raazuzU/9+JhvX0krVw4J/cIMwggEJ5A8f/2 8NbLmqwIzE26C8I6dfvZO62uyX+0FoeX0sHuVrVUNerI9Xpd2JK99rg0ERz/Kl7UtVo2nXijtrLD 2uOuEva99v1U29yq/uP1Y1ot82sOqev8azckxyIdyC6ptienlXbNm6C9405y/3hKaOGPnwge9c81 1lXnl6jdq9Y7vdpXuI8fX+qaG5Nj1+oF+eWYQwCB0ASm+Y5goa2NFQX3VbBG2ne1QUsu1enzvX1j PuD/KGX+au8hd/fCslkTXuHuT4QPuaNbs1yvmn/1raXvutvvo+s15K6gLjgF9Ee7HPaLp7kLOa29 X8LeR9Y3dQUoICHn1uQHwkifGhJLtMb1ompyJ8L/i2nkhdvn5Vrv9tmf/Lc6mXy/WMUiLnMCnAMx l5K/EFBJpc733FHyw/u/sHKbqxwe+KCdXb2mi4dNOaJCYPICtEAmbzWpJflGOSkmFvomwPuFt0Kc BWiBxDl7xI4AAghEKEABiRCfTSOAAAJxFqCAxDl7xI4AAghEKEABiRCfTSOAAAJxFqCAxDl7xI4A AghEKEABiRCfTSOAAAJxFqCAxDl7xI4AAghEKEABiRCfTSOAAAJxFqCAxDl7xI4AAghEKEABiRCf TSOAAAJxFvhXA6PG2eiXY/fDUzAhgAACU12AAhJyhhmaO2RQVocAAmYFOIRlNjUEhgACCNgWoIDY zg/RIYAAAmYFKCBmU0NgCCCAgG0BCojt/BAdAgggYFaAAmI2NQSGAAII2BaggNjOD9EhgAACZgUo IGZTQ2AIIICAbQEKiO38EB0CCCBgVoACYjY1BIYAAgjYFqCA2M4P0SGAAAJmBSggZlNDYAgggIBt AQqI7fwQHQIIIGBWgAJiNjUEhgACCNgWoIDYzg/RIYAAAmYFKCBmU0NgCCCAgG0BCojt/BAdAggg YFaAAmI2NQSGAAII2BaggNjOD9EhgAACZgW+As8hz4TTNfmpAAAAAElFTkSuQmCC --Apple-Mail=_D1D4BB17-996B-4270-B8AB-9443411980B3-- --Apple-Mail=_FF3539F6-2F6F-4C76-852D-FBF300CE49C9-- From nobody Tue Feb 10 05:54:44 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06A81A026A for ; Tue, 10 Feb 2015 05:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0hcuyEavWt7 for ; Tue, 10 Feb 2015 05:54:40 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE011A0204 for ; Tue, 10 Feb 2015 05:54:40 -0800 (PST) Received: by labgq15 with SMTP id gq15so20271855lab.6 for ; Tue, 10 Feb 2015 05:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IKUN3lSSF3Zbze8XNAVr8DoEgel6mUQr+IlnzZfdFcQ=; b=xJs01V90HixRbZkYuWcJ9s9EQNN+gaonIjsejGU1jUMF1UNi75K8J/4mXizLysn7sw zCuBkIHx8gYB+tMdcgMgvUdpRaMAeJqP9xk6ArxOo5rWZqo4UETZ1DNoCNJiDalElKQR QwsZ1JxCyngEq0RElDHFDTSBRYLge1XyFFasjCksFm3dWncEUF+vMa5D1KeQJFMx9yBJ FbZ4iS942eFWg6pJdbMG245omRPOWkKC0gFQGacUzktRYE1i2B12R993l5AzhCyARhv7 enr3QsE+6afhR1CZTjDm4sM6x2Djy9SeqzqsHnkC5iIS0ocUCq3cqVbKKJrIA0heasWV CjtA== MIME-Version: 1.0 X-Received: by 10.152.8.104 with SMTP id q8mr23449785laa.56.1423576478369; Tue, 10 Feb 2015 05:54:38 -0800 (PST) Received: by 10.112.167.134 with HTTP; Tue, 10 Feb 2015 05:54:38 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Feb 2015 08:54:38 -0500 Message-ID: From: Kathleen Moriarty To: "codematch-develop@ietf.org" Content-Type: multipart/alternative; boundary=001a11c311984dcbc8050ebc3a01 Archived-At: Subject: Re: [Codematch-develop] New call time: Wed 12PM EST X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 13:54:42 -0000 --001a11c311984dcbc8050ebc3a01 Content-Type: text/plain; charset=UTF-8 Hi, This is a reminder to download and edit a version of the Card Sort PPT by end of day today. Please save the file with your name or initials on it and upload the finished version. This should take less than 15 minutes and understanding terms will be important. You can add terms - those sent with definitions to the list or add terms you see on the mock ups, etc. There are 2 examples now in case that is helpful. On Wed, Feb 4, 2015 at 11:29 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Please take a look at the PT Kristin posted in the Google drive prior > to our call in 30 minutes. Call info is included below in case anyone > missed the new information. > > > http://www.ietf.org/mail-archive/web/codematch-develop/current/msg00117.html > > Thank you! > > On Tue, Jan 13, 2015 at 3:58 PM, Kathleen Moriarty > wrote: > > Hello, > > > > From the poll, we have a new call time, 12PM EST on Wednesdays. We'll > > need a new webex (to be provided soon, by ISOC). Here is a > > placeholder invite for tomorrow's call. > > > > -- > > > > Best regards, > > Kathleen > > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --001a11c311984dcbc8050ebc3a01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This is a reminder to download and = edit a version of the Card Sort PPT by end of day today.=C2=A0 Please save = the file with your name or initials on it and upload the finished version.= =C2=A0 This should take less than 15 minutes and understanding terms will b= e important.=C2=A0 You can add terms - those sent with definitions to the l= ist or add terms you see on the mock ups, etc.

The= re are 2 examples now in case that is helpful.

On Wed, Feb 4, 2015 at 11:29 AM, K= athleen Moriarty <kathleen.moriarty.ietf@gmail.com><= /span> wrote:
Please take a look at the P= T Kristin posted in the Google drive prior
to our call in 30 minutes.=C2=A0 Call info is included below in case anyone=
missed the new information.

http://www.ietf.org/mail-archive/web/codema= tch-develop/current/msg00117.html

Thank you!

On Tue, Jan 13, 2015 at 3:58 PM, Kathleen Moriarty
<kathleen.moriarty.i= etf@gmail.com> wrote:
> Hello,
>
> From the poll, we have a new call time, 12PM EST on Wednesdays.=C2=A0 = We'll
> need a new webex (to be provided soon, by ISOC).=C2=A0 Here is a
> placeholder invite for tomorrow's call.
>
> --
>
> Best regards,
> Kathleen



--

Best regards,
Kathleen



--

Best regards,
Kathleen
--001a11c311984dcbc8050ebc3a01-- From nobody Tue Feb 10 08:02:44 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8208F1A1A12 for ; Tue, 10 Feb 2015 08:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dxmceQK9LTP for ; Tue, 10 Feb 2015 08:02:41 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244971A19E9 for ; Tue, 10 Feb 2015 08:02:18 -0800 (PST) Received: by labms9 with SMTP id ms9so21216977lab.1 for ; Tue, 10 Feb 2015 08:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1nN4J6X/+7BgdR3x01sQudvDzzOz2syEH37fTPVbhHQ=; b=pcjWgE9U//cZLSgs6CFTk9cwl7mpe6QlBtqyEnGhkUIMJk6P48DfHEHWW3Ywi/+TyZ z1HQUY0cq0Gkx5SdUVizs3UtnIaHT8MLgINChTgmFZRY29ANh242IieyivgywJ46rftU lxbxoJDkEHIvBxvMectozMFEJX1u7IxBkfenQSNAhiplmTFDTlz0BEMQf9AhEXPAlN28 9qLx8MzlPJaQW55ePBpSKKFNPgZwaEJrG7+CnGipNTIzJyBmCv2iCR8v0iJbL3v2wSe+ 9J46v1wfxr4W/voaq2BZaw8SrEpr+jJfyJV/w/FaEwitVgEeb3i7H0GXWyaFuEJt5XI6 ecbA== MIME-Version: 1.0 X-Received: by 10.152.8.104 with SMTP id q8mr24097156laa.56.1423584136526; Tue, 10 Feb 2015 08:02:16 -0800 (PST) Received: by 10.112.167.134 with HTTP; Tue, 10 Feb 2015 08:02:16 -0800 (PST) Date: Tue, 10 Feb 2015 11:02:16 -0500 Message-ID: From: Kathleen Moriarty To: "codematch-develop@ietf.org" Content-Type: multipart/alternative; boundary=001a11c31198c3ff0c050ebe02c5 Archived-At: Subject: [Codematch-develop] Table at IETF X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 16:02:43 -0000 --001a11c31198c3ff0c050ebe02c5 Content-Type: text/plain; charset=UTF-8 Hello, We will have a table for us on Sunday of the IETF in Dallas. The secretariat will help and there will be an easel for signage. We'll need volunteers to sit with Kristin. I have IESG meetings most of the day, so unfortunately, I won't be able to commit. We should be there for at least an hour or two before the new comer session, so start by 12 to get those attending the security intro and new comer session. Registration opens at 11AM typically. The new comer social starts at 4 and the regular social at 5, so maybe running up until one or both of those would be good to get a mix of people. Volunteers? Maybe for 1-2 hour blocks? -- Best regards, Kathleen --001a11c31198c3ff0c050ebe02c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

We will have a table for us on S= unday of the IETF in Dallas.=C2=A0 The secretariat will help and there will= be an easel for signage.=C2=A0 We'll need volunteers to sit with Krist= in.=C2=A0 I have IESG meetings most of the day, so unfortunately, I won'= ;t be able to commit.

We should be there for at le= ast an hour or two before the new comer session, so start by 12 to get thos= e attending the security intro and new comer session.=C2=A0 Registration op= ens at 11AM typically.=C2=A0 The new comer social starts at 4 and the regul= ar social at 5, so maybe running up until one or both of those would be goo= d to get a mix of people.

Volunteers?=C2=A0 Maybe = for 1-2 hour blocks?=C2=A0

--

Best regards,
Kat= hleen
--001a11c31198c3ff0c050ebe02c5-- From nobody Wed Feb 11 06:57:55 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9651A8966 for ; Wed, 11 Feb 2015 06:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBu0bWxR2cZ8 for ; Wed, 11 Feb 2015 06:57:52 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082181A8889 for ; Wed, 11 Feb 2015 06:57:52 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so2853499lbj.13 for ; Wed, 11 Feb 2015 06:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UhbvfnmL45uXvRIjfua0dhTrKfVVg4eC2lDgtmm+bpA=; b=OYyyl2/27Asfpmat7kCXrKaGLvFCplgsyZJfIVglqmrr8NybRpJO/BmR8FzWiPWeH2 kQ4BOvsjVfqsx0sjCphyVE6CXWRVVvaOYQCm1mJ5mGTxEhJhOd3VHehshMX8VG6lytfZ uS5Hxt+r7RP6stJDBnKJD/aVvyEsAoWdfcZd8P5ONtWHOJd6utqOQy49wP4Zg3NH+k5A h837ZnL9j+/Siapd069cBYOYoF3ARSu0uI4C8JTAeEJagHty1p0hZAGpo8LeSPPS0s0O OU7Uqh23GTIF9VV6aYau+t9Y3y0vTnKd0on/EiUt6nRXFBlU9s98O+7pjf9C3FIUCDfa XLyw== MIME-Version: 1.0 X-Received: by 10.112.16.101 with SMTP id f5mr9920008lbd.75.1423666670489; Wed, 11 Feb 2015 06:57:50 -0800 (PST) Received: by 10.112.167.101 with HTTP; Wed, 11 Feb 2015 06:57:50 -0800 (PST) Date: Wed, 11 Feb 2015 09:57:50 -0500 Message-ID: From: Kathleen Moriarty To: "codematch-develop@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3fdfe2c566d050ed13ae9 Archived-At: Subject: [Codematch-develop] Call to start at 12:15 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 14:57:54 -0000 --001a11c3fdfe2c566d050ed13ae9 Content-Type: text/plain; charset=UTF-8 Hello, We will start at 12:15 and just have the call for 45 minutes today. If you have not filled in the PPT from Kristin, please do so. Although Lisandro won't be able to make the call, the data model has been updated and is ready for review. I did get IESG feedback on the "about" page. I will incorporate this feedback into my review of the data model as it changes some things. We won't need mentors in all cases. There will be instances of older RFCs that folks may want to link to implementations that have been completed for some time to show what is available in terms of open source and proprietary code. Searches would need to be available to show which CodeMatches have mentors as well as searches that show code with particular time commitments for development. Someone will need to set up the RFC so it can be matched, but the bar on this may just require a datatracker login. It might be the implementer that creates the initial connection, but others should also be able to connect their code to the same draft or RFC. I'll respond on the data model thread. Thank you. -- Best regards, Kathleen --001a11c3fdfe2c566d050ed13ae9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

We will start at 12:15 and just = have the call for 45 minutes today. =C2=A0

If you = have not filled in the PPT from Kristin, please do so.

=
Although Lisandro won't be able to make the call, the data model h= as been updated and is ready for review.

I did get= IESG feedback on the "about" page.=C2=A0 I will incorporate this= feedback into my review of the data model as it changes some things.
=

We won't need mentors in all cases.=C2=A0 There wil= l be instances of older RFCs that folks may want to link to implementations= that have been completed for some time to show what is available in terms = of open source and proprietary code.=C2=A0 Searches would need to be availa= ble to show which CodeMatches have mentors as well as searches that show co= de with particular time commitments for development.

Someone will need to set up the RFC so it can be matched, but the bar on= this may just require a datatracker login.=C2=A0 It might be the implement= er that creates the initial connection, but others should also be able to c= onnect their code to the same draft or RFC.=C2=A0 I'll respond on the d= ata model thread.

Thank you.

--

= Best regards,
Kathleen
--001a11c3fdfe2c566d050ed13ae9-- From nobody Wed Feb 11 07:17:30 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3841A00A7 for ; Wed, 11 Feb 2015 07:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhP8NED1ym4Z for ; Wed, 11 Feb 2015 07:17:27 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935C41A0066 for ; Wed, 11 Feb 2015 07:17:26 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id b6so3713101lbj.12 for ; Wed, 11 Feb 2015 07:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vcDwoDJcFAv+VsE4TuXlj2KAsNE1qRVfE5wtKQtnHjI=; b=je00StmFytdNt0270EOxDsWCv+Kr0k5HEYqHQocN18SC7oXLxkooFAUJLUIIQgP+3H 0CCKO7TlXRcYFLwoG7lmXPX51UuaFA9SgNu6xS39G8CG5budzdRsXMhJZlxlWOwS0NXd /Kvp1DTEttlKbVz+9l7uBO5uj1biBDJ9y3CN/sM5kIFBrSTun/Y+UEdrForj58icwoQH d2sUZgDDFIWhmAd5GHGlHT7Yuy1jTHuZ9qO5ICtzeZC3QfuDWyX4vpmaQJw1T5eUCYQ4 e77dVpA5pobY7Z08Cy7Fty694iAMASeKseEaB7yV3ijuWVDW9G/tmHY9wI182PiNNUEs mwCw== MIME-Version: 1.0 X-Received: by 10.152.7.38 with SMTP id g6mr28561440laa.65.1423667844878; Wed, 11 Feb 2015 07:17:24 -0800 (PST) Received: by 10.112.167.101 with HTTP; Wed, 11 Feb 2015 07:17:24 -0800 (PST) In-Reply-To: <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> Date: Wed, 11 Feb 2015 10:17:24 -0500 Message-ID: From: Kathleen Moriarty To: Lisandro Zambenedetti Granville Content-Type: multipart/related; boundary=001a11c2906c2eb1f4050ed18007 Archived-At: Cc: "codematch-develop@ietf.org" Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 15:17:29 -0000 --001a11c2906c2eb1f4050ed18007 Content-Type: multipart/alternative; boundary=001a11c2906c2eb1ef050ed18006 --001a11c2906c2eb1ef050ed18006 Content-Type: text/plain; charset=UTF-8 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 < granville@inf.ufrgs.br> 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 > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > -- Best regards, Kathleen --001a11c2906c2eb1ef050ed18006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lisandro,

Thank you for your time and e= ffort developing the data model with the team!=C2=A0 This looks great from = what we discussed.=C2=A0 From additional feedback received from the IESG, t= he point was made that you may not always have a shepherd.=C2=A0 If we want= this to also advertise existing implementations (open source or proprietar= y) of existing RFCs, there should be flexibility to demonstrate links betwe= en a CodeRequest (in this case an RFC) and a project without having a mento= r.=C2=A0 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 mu= ltiple 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 res= trict 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, Lisand= ro Zambenedetti Granville <granville@inf.ufrgs.br> wrot= e:
De= ar 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 lis= t as well as the suggestions mentioned during the last meetings. Terms in t= his version are also aligned with the list of terms previously shared by Ka= thleen in the mailing list. Any feedback is welcomed.

<= div>Best regards,

Lisandro


________________________________= _______________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Ka= thleen
--001a11c2906c2eb1ef050ed18006-- --001a11c2906c2eb1f4050ed18007 Content-Type: image/png; x-unix-mode=0644; name="codematchv3-3.png" Content-Disposition: inline; filename="codematchv3-3.png" Content-Transfer-Encoding: base64 Content-ID: <3791F40E-73E1-499C-8999-2245631C0893@icannmeeting.org> X-Attachment-Id: dcf84126a8ee7335_0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAAZAAAAF8CAYAAADhOe01AAAAAXNSR0IArs4c6QAAQABJREFUeAHs vQ9AXNWZ9/9NCwoKqcQmm5coMY1NiXWoBnWTapIBal+jLTTdZm0LrEm1mGhNSLXml1ijEjUlrRqo OjHVBVfI1pKf2+C+Jb/dHUqIdWx1aDsTC7XEODSgBR2aQJ0xM/2d9zn3zgzDMHeAyQzcGZ6jw9w5 9/x5zuec3Oeef8+ZJciBHRNgAkyACTCBSRL42CTDc3AmwASYABNgAgoBViDcEJgAE2ACTCAqAqxA osLGkZgAE2ACTIAVCLcBJsAEmAATiIoAK5CosHEkJsAEmAATYAXCbYAJMAEmwASiIsAKJCpsHIkJ MAEmwARYgXAbYAJMgAkwgagIsAKJChtHYgJMgAkwAVYg3AaYABNgAkwgKgKsQKLCxpGYABNgAkyA FQi3ASbABJgAE4iKACuQqLBxJCbABJgAE2AFwm2ACTABJsAEoiLACiQqbByJCTABJsAEWIFwG2AC TIAJMIGoCLACiQobR2ICTIAJMAFWINwGmAATYAJMICoCrECiwsaRmAATYAJMgBUItwEmwASYABOI igArkKiwcSQmwASYABNgBcJtgAkwASbABKIiwAokKmwciQkwASbABFiBcBtgAkyACTCBqAiwAokK G0diAkyACTABViDcBpgAE2ACTCAqAqxAosLGkZgAE2ACTIAVCLcBJsAEmAATiIoAK5CosHEkJsAE mAATYAXCbYAJMAEmwASiIsAKJCpsHIkJMAEmwARYgXAbYAJMgAkwgagIsAKJChtHYgJMgAkwAVYg 3AaYABNgAkwgKgKsQKLCxpGYABNgAkyAFQi3ASbABJgAE4iKACuQqLBxJCbABJgAE2AFwm2ACTAB JsAEoiLACiQqbByJCTABJsAEWIFwG2ACTIAJMIGoCLACiQobR2ICTIAJMAFWINwGmAATYAJMICoC rECiwsaRmAATYAJMgBUItwEmwASYABOIigArkKiwcSQmwASYABNgBcJtgAkwASbABKIiwAokKmwc iQkwASbABFiBcBtgAkyACTCBqAiwAokKG0diAkyACTABViDcBpgAE2ACTCAqAqxAosLGkZgAE2AC TIAVCLcBJsAEmAATiIoAK5CosHEkJsAEmAATYAXCbYAJMAEmwASiIsAKJCpsHIkJMAEmwARYgXAb YAJMgAkwgagIsAKJChtHYgJMgAkwAVYg3AaYABNgAkwgKgKsQKLCxpGYABNgAkyAFQi3ASbABJgA E4iKACuQqLBxJCbABJgAE2AFwm2ACTABJsAEoiLACiQqbByJCTABJsAEWIFwG2ACTIAJMIGoCLAC iQobR2ICTIAJMAFWINwGmAATYAJMICoCrECiwsaRmAATYAJMgBUItwEmwASYABOIigArkKiwcSQm wASYABNgBcJtgAkwASbABKIikBJVLI6kSWDWrFma9/gGEwhHQAgRzpv9mIDuCbACiUMV8QMhDlCT NEl+4UjSip0hxeIhrBlS0VxMJsAEmECsCbACiTVRTo8JMAEmMEMIsAKZIRUdVTHdHSinOR05zDLy ycOO+qNwTyLB4Y49FH8PBicRZ3TQYRw9UI+u4dG+/IsJMIHpJcBzINPLX/e5n4QBjZaf4R8vADwk 7cCxZqxatwqu+Q48cUPOhORPW1SMFrMHmRMKHSaQ9y2sKn0cVtf6MDfZiwkwgekiwD2Q6SKfMPle iNwrcrE4Nxe59Fn5te+izgiYbX1wdx1ESUE5tpYXUA+jAM09bvS07kOJr8eSV74HHQNeeJ3H0Pjy HwO9lr7XDowKYw/qmhyX8fPUHk8BxbcPDuPAhnyiZUd++u3o4F5IwrQcFjT5CbACSf46PusS/s3l BbykCOjT1/EzPN4GfCkvB17P+2hua8De89bAVHMLLun/KRYWbcJ8kxnd3RasO7kN+fN248+n+tCw t0+Rw9tzEAtWlCphHA4bbju9DXmr92CA7rqPH8SlMv4dLUr8FQ10b/NhrLyzjvpBBpjM38GStLMu DifABJhArAjQklN2MSRA9RLD1KY5KZdVlFF5ZJlGfYxVonNIiCGbifyNwkLX0llrjALGOuFSf1IA izBQ3D0v7qFwNUIGs5mK6bpSdDqHhJM+/bZGJe0mh0eNb1DDySRc3WZRd8gqPB6bMFI+1kDC/gwS /zup2kviVweXYJIEeA6E/gWz0yYg50Dq2uuRfz7NgZw5g9QLcrA0Nxuy4QzjDP29Atm+XkEq/TKs yUOgk5ByDhYpSf9d+av+mU1fe7F0zt4gP6Dv/SF8RvoULQnET1tciPWLyY8m86U7Qx0hdkyACeiH ACsQ/dSFTiW5EHlXL4MhoBVCxDQswhxfK5KT7Hb72/BimaJgZMjTSvCPK3/lH8+Zk6RlTHDaNiKT FEIKDV691t6FuYsyceoVCmB+h+JLfxo16zmMnfvew3d25NEv4BxfPsoP/sMEmMC0E+A5kGmvAv0L EPHN3z4i/8VXFgIN6/Ds0R643QNo/uHdaEMZij51biDQomvWkpbZhJ8c7iJFMYzWp2/DiqJV6COV seg69V49xfe6ad7kvjXYbXFjttLTacMrr3ZhmHshAZZ8wQSmmwC/0013DSR6/jTJ4XdzV34P7aaT WLVqITYpnkY0WmuxBC/4gyBr+R2w1J3AijVLsU3xNaDG7MDKLPqR5bsXiF8Bs2M9MjKcWFMMbCla CrfFiXuXy8DsmAATmG4Cs+ScyXQLkUz5yw13Mx2p1z2MIeopZGZkqENR9lqk0ijUkNiMDH9lU5hB F5CelRGY8/Dfgu9eJt0LfsNxu71ISwv2CcRI2AtuLwlbdSw4EeAhLG4GMSeQkpaBLJ/y6DqwlZTH Fpr3CMlGhgmnPGQw371QVZFsyiOECP9kAglHgHsgMa4yfqMcDXSwqxUttPtv2ZobkZsVqhJGh52J v7i9zMRaT54yswKJcV3yAyHGQJM8OW4vSV7BSV48HsJK8grm4jEBJsAE4kWAxxTiQFa+VbJjAkyA CSQ7AVYgcajhmb4KKw5IkzZJftlI2qqdEQXjIawZUc1cSCbABJhA7AmwAok9U06RCTABJjAjCLAC mRHVHOtCDmNfQfAphcHXBWh9JfgEwpHTBIdpQ+GsvFoyYMKOCTCBZCDAcyDJUItTXoYM/NOznbjW k4rUv/4a/0zne3ypyYJbr7wAH36Yiovne2Bup53oUq7g0wQVa4tTLixnyASYQJwIcA8kTmCTPdm5 i3NhyF2M3KsMisn2+Z+5HIuln2Ex0k4fQ91Lx+gEwtGnCf5OKpAgF+lkwqBgfMkEmIBOCbAC0WnF JIxYXo9qst0zoh28gRMIM2AMOk3w0hGjvGSqXftkwoQpOwvKBGY4AVYgM7wBxKX48mQpn8u+Kh8X 0n/XfN6AjJFjQdD5C2mhtxJbb74GmZmL8I2HG8nM+zYc6WF77X52/M0E9E6A50D0XkOJLh/1UKQb e6bIbPINfzIhcthcuwKN/zABnRPgHojOKyhZxAs9TTBwMiGdJuDxCAhPPyw0834TnUzIjgkwgcQg wAokMeopsaQcmQ6hVVjy3HTfaYJBR6NHOpkwsQrL0jKBmUuAh7Bmbt3HqOSpuCg0JTkH4j//IyMn cJrgqYbd5H+eEjriyYSh6fFvJsAEdEmAzbnHuFrYPHd4oJqnCUY6mTB8Uknly+0lqapzxhWGeyAx rPLXX389hqklV1KapwnK0wfTkqusXBomMFMI8BxIDGra4XDgq1/9KkpLS2OQGicx0wjItiPb0NQ7 L4aHhyF7h+yYQDQEWIFEQ80X56OPPsIjjzyCq666Cvn5+bDb7WeRGkedqQRk25FtSLYl2abi7wbR XHs7Zs1KpT04mUhPT0XB1nr0uCeXM9s2mxyvZAzNCiRCrfb29uLf/u3flI+8DnaHDx8msx0GWK1W vPHGG7jvvvtw7rlBW62DA/M1E4hAQLYd2YZkW5JtSratYBepHQaHm9g1mZcpn4OSLR+iydIN55AT vZ1mLNm7AQvX7MPgxBJRQqWlnkObPycRgYMmHwE6/IhdGAJPPvmk+NjHPiZuvPFG5SOvpd8777wj 1q5dKz796U+LlpaWMTGphYzx042HyyrKSD4pY+BjKBYmc/eUiDhkraZ8q4UzYm5Dor2xTnQOCTGx 8BET0/3N0PYi25RsW7KNybam1Q6jLZjLZlLqvrHbNSoJV2eTqKg0CYdH9XaYTaLY104MZdXC2q/e sDVVC1pgR2kYRUWZQcBoElRViuu1NI6KY/NVtEy72FgmKsuMSrxDjtF5+6LzVwIS0PHTbvpovv32 2+KSSy4RbW1tASHkdXZ2tsjKyhIPP/ywcLvdgXvBF6EPhOB7035NCsQIg2i0dIruzk7R2WkVh0wV ygOl8lD8lYjH2SnM7Z3C94wKj8NjJXkMwkrPmAmFD59KwviGay+ybck2duGFFyptLrQdyrYp22g0 rt9cRXwrhSNC5CFbndImKkxm0d1tEVVGqTCqxB+sqvKparKIbispBalIfArE42gKxHE4bKKmmO4Z qkU/5TPkU1qoqBammjoRorsiSMK39E4goVZhHTlyBPSPif7Nxdf9+te/xq233orVq1cHMpLXmzZt gtlshtfrxQ9+8IPAvcS6uBC5V+RisW/lU27uM7DiPeSX7MF3PM9gMbUIaSV3E5lob6aC0dsnGmvv hUGxLjKAg7u+i3U7G5QiV9SY8djmQmTQr+Ot+/Ddyk1opiENI8WppTif/stB3LzpED510UnspSgH 2yvw85dSkTf3GNZt+m+suOI97N5LuRgr0f78bqzM8eLAhnwl7fz02/Hq768nq77ANStzlTx6KI+7 iigPn1z1j38Xy+amwN11ADdvO4aiq/6MLVI2YxmaamvxNVVoJT09/3nooYfCirds2TKsWrVqTDuU bbOyshLy/kTdAw88oAT987FW4nMz5kSI+NYvn6cwdajZWAjZTO5/2YKmzBWo+/eViv/3vrZc8X/W vB3zKuVGUYy2bUa/pW2zLXmlZNvsu7hBCWGE5bF7sVw2liCnVfagIHG9NBqNo/jGNbMkTDyh5kCk 8qivr0/CapjaIoXapbrMuIYEeAsDNIkayUpuT/P3SXkA7d296DSbsH9LEZ7uGIT7+EFcSg/2+Xe0 gN5YsaJhG/I2H4Tb8z6a2xqw97w1MNXcgk+nDKBhbx+85N/Wth//+eFadPd2wnTRXqxa+EP0kZoI tt676KM+JbykM2yvx0KZh8ms5LHu5Dbkz9tNcUhmz2k0N+/GlpPXwtppQfXsBqzb/CIfXCXBhbgl 160lwwAtODFmwnwQHa91KG1A2Qe6Jk9REkr0lHMUk/2yw2FYO+KfOXd+0ByI37ZZJubMycQ8Uh7S 9b0/RH+lkrkC2b6XFumvByefJVPxQqqHssZNBr13kYLle/DBB4X8xNsl9xCWUVj8g9Y+kOoQg1FY yd9mKqahiErR6RwSTvr02xqVoYkmGhxX7xlFXYtV9A/RPYdDDNF4lLXGSE+WmsBYuKvbLOoOWcWg MnQxkt+QrYbSqhHv+vzlMJXihizKuHqTHBv32GiYjWShS394Ka6Sh7FO+KMIX5waEtovv79cLl8+ IcX0ZaavL/qHPUageA5hebrVoaYqsxxcGnHOdjm0BSHrWWFd1jQy1KgMfUJ8756VAsWNAX91jkqt d7UNmJT5LbJtRvXYL8i2meh2etR6DGofI7lO79VUPU+mt5TxzT2heiBx06IhCS9atAj33HMPCgsL cdNNNykfeb1jxw789re/1VwtE5JM4vz0qMMQ6l/tN0nDbT+GqQLYsCYf82j557y7nsexfjfkGyuK lgTeWNMWF2J98TKkaL55ypzWYon/jdT3hvt2n0t2JxRuob0k7bdiGV6mV4gc3/BIIu9qCF7dJ1dl yTYX2g5l25RtNBqXsvgraKkEdhYVofYw9TgGB9DVWo/Vq6hrWdaIL+Wk4OIrC4GGdXj2aA/tERlA 8w/vRhvK8JUbrgeaS9HwWh/cw114+u5tNKR1jiLGuLbNeLVWNNWl+zg04s0uHIE777wTX/nKV5Q5 D3l///79WLBggRL0pZdeUpZabt68GZdffjmeeOIJLFy4MFwyuvQbbRnXjcPPbKHJjhospgfwn8+c pGsTnLaNyKQncQoG8Fp7F+aSldzBvpO49r6XIWpcsL9+BHtWrUPFtdejXioC8zuQD27ZoLw9h7Fz 33vY8M/0w7AIc8K2sjfxF7rtHxI/TdcXzU2nv6obLSMg1YTd/jblIRWT6mQcqOqL8vkEpOpLVCc3 Em7duhXHjh2j+aNa3HCDOnMQqR1GV9YU3PDDXjSmb0MpvQhQzSvOWFkHx+5vKi8BaSu/h3bTSZp/ WYhN6l00Wmvx+WWZaK95C6tWLMAGXzwY1YtIts2GqUkFbKP54/F3chCIbwcntqnrrcvpH2r45Cc/ GViZRa0itoWOZWq+oYg6s1XQ262wtLeImkoafiKZq9vVIQ2nRQ4z0e+WTuHyDAlzjRzSgminJZmW KhoEp+Etm5MGklzdoor8DdVW4bSqcUztDuFx9Yq6MgpHq3PeDRlKGlLC+YewICobrZSHUxyqkjL4 VgbR0JSR0q0xd4p3f6MOecmhqH7fEIvMw+Xq98UpE50hQ10SV/DQVyzxxSMtyVauuApuQ/HIJ2ya HpcYcjrFkCv8ujiPi4Yxaagy9K7qHxhMHJ20jENDnxp3R4ed5l96e55MM46osve/zFE7ZjdZAnLj oNwEVlZWprw9yk1gencXkYAbitSVToqstGKpztyN9SvnKj8jvUniO1Zsb81H3py9ajGNVbB9exmy svJgqTuBFYE31gqYHeuRcWr/6DdPZRxKjUpjH3j7B/lIL5W/jWjq3IUcealhvXeuxltxLvV+hmW8 UPShv2UYnTr/ZtQp78WmpCEjgiGyFGmnLAwzLX8lKNs2C0Mseb0Syhqvf8mff0mi3qpFGlO85ppr ZBdEb6JNXp4IVnLdZD/JSwNJGRn+SQxf8r44mVkZgWGmcBlLExiZpedgiIbJMDiMtDDhtaz3eimP IRory8yInEe4fPXox9Z4p69W9P48mT4yE8+ZeyATZzVuyKuvvnrcMAkTIMKbZBo9vMO6CHFGhfec ogmNc5V5jSxSHuGclvXeiG+/4RJiPybABOJGgBVI3NBywloEMpbcAovVg0ytAOzPBJhAQhBgBZIQ 1ZRkQtI8x/KJb6JOssJzcZhA8hD4WPIUhUvCBJgAE2ACU0mAFchU0vbl5e6qp7MYStChLB8aLcBw xx66tyeiWe1h+z7Myqsdx1THMI4eqEdXmDxG5xjyy21H+axZqCUTJbFw+jgzYqIsRsJNpB5iwYfT YAKJTICHsKah9rweaYhI3QYXmn3aomKY22mVUeiN4N9y5/h4O3u9tOGr9HFYXeuDY07g2oOTFCpm ywGUHYATyDaeQSbKIijchOohnjJz2jEl4F9xFZxoJDtYel3pGSy/Hq65B6KHWgiSwes8RhZoj+Gv ZGG2pGQHaneVU49kFmYVlOOg3dcrUGyH+CINdmBrwSyU7zmq7ARXfenQIMWqrR3Sqq2/pyOt2ZbI tOiTV74HHQNy77i2c3cdREnBVuzaWqLGKdmFo/ZW7MhT0yjZdVDpKclwBQW3Y4cv3CyKc9R/vF2Q rNLKb3D+/uJMNB8pqXYaWrxCWXjRcWAX8nwcZuWV40DHAKU8Otwbf1brwW9zMBw7aQVYs460sfId JpA8BKLafjhNkRJh5yi1jHHp+I3/SeOFoS50tzYqTIIszIpqeb6C7+wFJYyhjgwZdgsya0QG7mpE b0hCvZY6MlBooMOibIrBQ60zHkLjCd9u9Ror7VD2n+NQWSdsthZBZrCUXenVhyyivWm7ci0PJvKH M1TQWQ+9ncIkd6LT+REybf+u8MGJnBcxTj4TO3NiLK9gFn9+RR5qJXfaW4U8t4JseymGIOXZR8Hh gnfBa7F7y88nTB2FVIfmz4m0F83IfOOsCCTC8+SsCjgFkcd/2k2BEBPNIhEqfCIPhIgKJMRibTgL s2r8YlFhHHlQj2EYZNVW3otkzXZU3DEKZMSark1a3Q1YY+1XTJlUBxSNakFXSSvIuq5fgbwWwcqv n4e/rFr5RLIUHJrGKIu8QSyc3VbRQmZSpHkO15BTWJsqRywJB4Xzyy11vBa7PS/uJWU0wmdUnqOg av+YSHvRjs13zoZAIjxPzqZ8UxGX50DoX7A+3XgWZpuxv01K7sRpGmcZc9ZCiFVbxYpI2DMe5CSF lpMyjD7HwXBtrm+XeTrmkrkQdSZHhtOwrnu+P22/lV+fGRSft3JeROpE8xkvDQ2LvEEsshbOh/O5 TUgtavYLRjrApF4HhRu5qZprNIRlR9aDk8QKcHB5+ZoJTJQAz4FMlFQ8wo2nvjUtzMoH7nZ0OztR ib1YWnVYUzq/VdsRa7YjQdWHf9Akxcitkasga7qhqkZKMeJU67r+3zLtYOu6Hr+VXzLzQudFgM6L AJ0XgZvIyq/iJpDP+GlEtsgrWdifLUXp7tlosTlAZ5mAzrQAPhhdEj8zf1m02X084a0A+8vI30wg GgLjPcKiSZPjTIjAB7C92gFcQKdZKM+vM5j7mavwD8FPaa2VVjKMYT4WZOViZ3s19q5ag31fc2Lj siDTd16ZaBteebULS1blqmc8bKEzHiocWH91Ov7Ld8aD6bLwpkQCRdCSIRBAXsgzIfbjyQO3Y/c/ L/KlXYnn5bm5vviXXEMn4W3ZhJ8cNmLzFy5C+9O3oWhLM8jKL/5BJjGBfJQzJ6JJI4jFMmVWfAku W5qDNFqAsHM9nWlhr8RfaD1BRlC47KBlcMr5GGHYPfapcycktyweu+klwKuw4sOfFUh8uEZMNSVV GiG0j7aKSz7VFifukEM+NDSkOP+372fA39dpkGuoslZuRlPlNqzLfxLF4n5k+8MGWbV1U7r3RrBm 64+ifqfiomCPIBlC+ypSbfhXKWlZ1/Vbyr1g+R2qxd41S0GPbHIG1JgdWEk6L/S8CK18IlkKDk3D l4XyFWzhd9dPG2FEKRam0gFK5CqqaBmC3Yw/9XuxODsHa4pJzxUtxemG3STieUoYLUvAS1JfGKkr JST9CeLl9+JvJpCsBNgab4xrVm/WVUOt2sbDmu1ErOsGMEew8hsIM95FlGmMsHBjeJDsCWdmIC3M K9RIuNGCxIOd3trL6BIn9y9/r4T3fERfz2H++USfGMfUH4FQq7ZxsWY7Aeu6ATITtdgbiBDmIso0 RljIczDCpOvzGgk3Okxc2I3Ogn8xgYQiwAokoapLn8KydV191gtLxQTiTYAVSLwJz4T02bruTKhl LiMTGEOAl/GOQcIeTIAJMAEmMBEC3AOZCKVkC+PuQHl6PhpCymUsq8JjtfcjeDVwSBD+meQE5KT+ THO0I31GFZl2qMesvKxAYoYysRI6SetNm2z/ic9/AooRRs+pbjy3uQj56y/G0KH1GGd3SGIVlqWd FIFYPmAmlTEHjjuBWL8g8BBW3KtMrxlciE/RZrrsnBzk0GexoRD/cgttgjhxWjmrXMvqLTCAg34L wfS2entta+BcknAWa2XppdXagvL6QDh5Hor/t2qJtxxbywvI4m8BnvnpkyjxWfstIIvBfou90cij V/IsFxNIFgLcA0mWmpx0OWgnvMWO82gnvNzY/tcTv8LODWQfquJWpPccxJwVpWQI2AzHjXPx87vy kLca6LfdC1fz97GO9uC1d/dirqMZS4uKsPg62gCZeggLizYpcbqvPw8HbluB/HkfoZc2N87+8H20 yfEy2ncnnffD04HfXs/7aJY3K6pRe38PNn7jLkqjBd3XX4DnLl2BPHwKrkeABZOU514eh1Nh818m EEcCrEDiCFfPSV8kd8KvyhslYnHVIfR+rxh/qi8h/0psvfka5WCrbzzciC15pTjS8118pu89unca x//0HnKvK0O/40akZ2fhraefp83odajZWAi5z/7+ly1oylyBgx1b8a3QreWhv2lvuOWxe3HOvxbQ Tu4aPLbxBmUIbWe3GUvevABdv3ho0vJQBHZMgAnEmQAPYcUZsF6TP0kP7Xanh8z5e+Bor1HEnH3x Ip9V39n0m4w0zsnEHPrMI+UhnbSca7jtx6AzNLBhTT7mZdK9u57HsX43pE4Ib7E22LiXkkzIH2mz S7X4q+iVoiWKApKB0hYXYn3xMnwck5cnJBP+yQSYQBwIsAKJA9RESTI1VXZAU5BD9rRsdApUw4Y8 1NuHEcnq7WDfKVx738sQrn7Y2ptQ1rwTFQ2/U4bB7Pa3g05F9Jt6J7Wg6BC3+iXhKEf6BlHyWeJV gpnfCaTh7TmMHTvq0ec+SdrJBDr0aYwlXy15glLnSybABOJEgBVInMAmWrKGjY+gioTeUPoE0qXl XLu0nNtFD/NhtJLl3BVFq9BHyuaPz9N8yML7YXdlwnD1lViiFPQc1dpvA1n7PdoDt3sAzT5rv18k a78p58kexDa8QPeGB+x4NJ/MKRqlKUaf81niXXSdmm89hfO6+9Bw3xrstrjx2eWTl8efNH8zASYQ RwJTcWpVrPJIhBPEqKpiVdz4paOcOjhykp4/o8DRrU1/FJY6OqnPd4Qtvf4LspyrBnNaxXblJER5 GiJ9jFXCJs+DFS7RbqoIimMUjXRaoS+SaKw0BO4ZZXz/8bzyBEZDjVBP9/WE5FshzA4XJRHqPxF5 fFnr/Etv7UVv8ui8+hJOvFjXL1vjJaKxdEllXTWC1Vv38DD1TlKQkSGnzEdcJIu1ahwyZJgxztoN X76ZWdR7GUma1gMPY9AFpJP/6FzlrfDyBEfX47Xe2ove5NFjnSWyTLGu31H/PhMZDMseBwIRrN6m ZYTfahjJYq1WnDGSa+Wr5U8JTDjtMZmxBxNgAtES4DmQaMlxPCbABJjADCfACmSGNwAuPhNgAkwg WgKsQKIlx/GYABNgAjOcAM+BxKEByIkqdkyACTCBZCfACiTGNUzr+mKcIifHBJgAE9AnAR7C0me9 sFRMgAkwAd0TSKh9ILqnyQIygQQnEOt9AgmOI+nEj3X9xqAHQsYuaBOX2+1NOthcICbABJgAE9Am cBYKZBDNtbfTIUCpyCSrrOnpqSjYWo8et3Zm4e4M22sxK682cNhQuDDSTx5KJLXnrJJaOtIo2HnR ukseRlSOjuFg/9DrYRw9UI+uiGGAicoTmjr/ZgJMgAnMNAJRKpBhHCifg5ItH6LJ0g3nkBO9nXR2 w94NWLhmHwYnQTEtlYzq+YzpRYrm9ZxWbzdvgaUvqLfj7kTdzja657uvlYj3LawqfRwfjrdsQDEJ e85oExpaabI/E2AC+iHg7kABnWr5WshLop3Ot5lVsG/cl1T9FCRxJIlKgbjtDShtABq7f4KvLV+M rIwsZOcWoqazCRVXAEP0fNc63lSisR/cgzzZm6DKvvORp0dZZtU+unQEatN/dQZ+DLz+c5AoPudF x4FdvrQp/bxyHOiQ/RVSeBvy6duO/PTbAz2V4637xh6fKg+lsP8W+/3HtlIaB/3nqvpy4S8mwAQS iICbXi4/SCB5E0jUqBTI0IB8KFfiusWjTdql5X4NzzyxEXM665XjTefTkajd3RasO7mNjjfdTebA gcGOfchbtw3rmizott6J9xpGuh9eOkpVHl0q4zkcNtx2ehsdpbonaMiqDI11lXRuRYvPz40j++k8 ClMdiintD15/HPmlO1HWYlXim1aQolv/79QjyoDxzjoY6D+T+TtYQmK7jx/EpXQE6/w76PhUknFF A+W1+SAZCJRmxvdjy8lrYe20ouZzDVhX+iK/vRAVdkwgsQkM4KD/xZBeYG+vbQ38u9Z6cXV3HURJ QTm2lsth8gI0T3aMPrGBjS99NPaIrTXGgDnucPHV+3Vk4NvnhizCQKa/a6xDIvRev3l7wJy3zVRM mygqRadzSDjp029rVEyANzk8YshmousyYXVYhJHSapLWxV0yXaNoJ79i+v6v31tFi7mTjH/TrSGn sDaRSXK/qXCPjeIZhdUnlCKH/54M320WdYesYlDJxyAsqn1x4eqU+VaKbpkoOyaQ5AToiZG4JdQ4 psBmoueVwST+cEgeN1Am2rt7RadZ/ruGqKYjBzyOJuW6wmQW9OIqaorpuAFDtegnEupzh35XVAtT TZ3oDjzUEhNTrOs3qh7IEnnwT1sLToyZMB9Ex2sdGKZ5hEjHmxrW5gXMcWfOnR80B6J9dCkVnNxp pGZfgTupu/HCK10YeL0ZduO3cXX2+coMSGbOfDj/ZxtS6e0iPXMO8tftBS70HVzkVSY3cMY3faJ1 fGoK5BGr65DjMzarRvsdBsaUVRGI/zABJqAzAudozHOe7nuPJD2J4396DxdeU4Z+hwN35GWh8xcv kH8ltt58DS0IWoRvPNxIz6RtONLjn2s1wvLYvdi4eT1CBl10VvKpFycqBZL2iWyStBk/f3X0eqjB o08if0U+fj0soHm8KcW0m+VJd6rzBh1vGukoVTX0aToWNQ2rN1Wi+QdP4NGdu1G51Ug+qnI4/nwp SnfPRovNgSGPwJC1msa1pEIYcf7GpcQIc3zqu3+nsIZPKKdwj8SCMrAV/FvrWlkppszvyDke/jCD 8duAVlti/2gItKHrndC3PfliegZLbvsxTBV06uaafMyjlaPz7noex/pl2EgvrvL5cQWyR4/WRyNY UsaJSoGkLP4KWiqBnUVFqD3cgYHBAXS11mP1qp3UQ2zE1wuLAI3jTS++spB0TykaXuujQ4C68PTd I8ebLopwlGqAPtX33OtuhtG+H3vbjLi5kJSZTxt5FV2xBJctzUHaYAceXU9p20/gL/K+crMNr7za hWH6rXV8aubHKezItEwgWyXpwK/IF9S5leMA/GEG47aByC2J706KgO85cHyATh0Lcid+2wysuATe vlO49r6XIVz9sLU3oayZ5k8bfodxX1wNizBHo1cTlM3MvIx6JM/TKxq3lyljh0RO+TZW1gnlBNKI x5t6RHvN6Hj+400jHV3q6qyjPIoFTaOQc4nGMjku2aTOs/jGPs3WQ8r8iF+eiip5LKtBtPTKCYxe US3HNuW4p0UetRp6TKp6fOrQqCNW/WOgxcI2wbFPmT47JjBRAnprL3qTZ6Ic1XBOYVL+jZeJJkun 6O11CLPvaObKFoewVMl//5V0BDP9Y3Z1iyr6t2qotgqnhY5Vls+Flk7h8gwJc42ci4Vop8eE8jyA /8jlyUmjx9Cxrt+zf9p5XGLI6RRDrrGzzB4XTYYPDSmT2qEw1XsaT2UZjybRNe6GJhXyW8pDcceK o4Rzhd7w5aURPCTt8X/GuoLGz3G8ELQAgepgTLnHi8b3p4SA3tqL3uSZdCX0W8V234uiLIv8VNS0 COW900n3jKqfcs9YRcpE5hD6MmkQNWa5SsenQIIW2yieCfwn1vXLtrCIaCydHPOn9hXLJKNMS1oK +H9os+f+QHzqIeL53euRM4nxXLkzP7OU9vbYNtNiaA1HG7jK0/OD9uOo4YxlVXis9n4sy9KIN+Xe 0hrBQcwtXo9czcJMrVD6aS9qufUmT7S14XUPY4hGstIzM5AWMvzkJtNLXtoqnJER8g+B4gzKOFkU J9qMdR4v1vUb1RyIzhmxeHLj5BRbCjhJe2yaaPFCL61scdCn22bGipM7kb++PrDWftorZqLWCKZd UBbgbAmkpGUgSyqCEOUh003LyBirPNQbapyzzXwGxU8oBfLQQw9BfthFJjA9lgIuxKdo8UJ2Tg5y 6LPYUIh/uYXWW5+QK+dUp7VZS94dsU6Qh607ylFw+wG8T/bPCspHFJC7q37Ub+30wm0YC2+NwCca fzEBJhAFgYRSIFGUb0ZGmR5LAR/AZrGjy26nJdx2HG3eh00b1NUvmVQLkawMBKwTHCILAp178Lvd DWh76zS8H76PtgYyQ+Fz3g9PB35HSq+n+ftYRwsCacMYaMMY9m8pwtMdnjHWCPzp8jcTYAJREkik +aAHH3xQyI+eHVXDtIs35ZYC3vqNKPNNWMry+z/FVYdEr28lRCQrA6HWCZztqnWCd+WKuKAVMMEr YiKlp94ziroWq+inBQS0YUzQviCaKx1tjWDaK4oE0EN7CeagN3mCZePrsycQ6/rlHggRTTY39ZYC /kb7e41od3pIe3rgaK9RkM6+eFHQBqxIm7VGWy5IvWB+2L04o+tJOz2D1oaxEGsEo9PjX0yACUyW ACuQyRJLgPBTbingkvMVKqmpcsYyBTkrN8NmKiOjl3mot6u2tcfbrGVvsfn3gyLFP2mifLsDcyiY oNWCQY0NY/6q81sj8P/mbybABKIjwAokOm66jjX1lgLk9v3RzrDxEVSR14bSJxQrzJGsDKg9pg14 9miPYp2g9qEtion/lPNkL2MbXiD/4QE7Hs0nywJG1bZZpPT++Hwe8hbeD7srE4arr8QSRTSKF2KN YLTE/IsJMIFJEzj7UbWpS4HnQCbBeiotBWhYQR2ySesBtJGrqZsE196sNfYezaMYTbT5yykaKw2B ORWj0e8vOURIT3PDWKg1gknwjFNQyUdPTm/y6IlNMsgS6/pNqI2E/iW8DzzwAHHQp4v1Rp2zLqXX jWF1RxUyQhbFK5utyH5QJq2LD10ur95LocPCwmypOpsNVxHiyjzdtF0x5Z19SF96BkNC3byobvxK o7X7oVISnQjpaW0Yc7u9SAthcdaco0xAb+1Fb/JEiZWjaRCIdf2G+RepkTN7JyaBFHrwZoVRAlQa ZbOVRqki3aOdWNBIUiO1IO8IcWWecoP48IfSyvO5gbkPufFL00VITyueXpSHZpn4BhNIEAKsQBKk omaSmGmLvgmLlXpGM6nQXFYmkIAEWIEkYKUlu8gpWYuxXDf2s5KdNpePCURPgFdhRc+OYzIBJsAE ZjQB7oHEofrlRBU7JsAEmECyE2AFEocapuV+cUiVk0xGAvyykYy1OnPKxENYM6euuaRMgAkwgZgS YAUSU5ycGBNgAkxg5hBgBTJz6jqGJR3GvoJZkMMvYz8FaH1lD/nvwaCSozwFsB5dZBJLnm44K69W PwdMxZAIJ8UEZiIBngOZibV+1mXOwD8924lrPalI/euv8c8rSvGlJgtuvfICfPhhKi6e74G53beP w3cKoNW1HsrOQPtZZ84JMAEmoBMC3APRSUUkmhhzF+fCkLsYuVcZsIiEn/+Zy7FY+hkWI+30MdS9 dIzMkow+BfB3fiu7vsJqnyiYaDRYXiYwMwmwApmZ9R67UtMZG8qZgZ4R7eA91YeGvX2UR8aoUwAv PXck20gnCo6E4qvpIDB2WDLcUCX7JSKnWLcnViCxJsrpAakjELKvyseF9N81nzcgI8jqe+cvXqBA ldh68zXIzFyEbzzcSIdIbcORHrLuyG7aCMgl6DPlQ9a9IT8zpbz+csaycfEcSCxpclpjCWieAug/ UXDvqDh97w8BOWzHZBQU/sEEdEqAeyA6rZhkEyv0FMDxTihMtvJzeZhAMhJgBZKMtTrdZRqZDhl9 CuDfRwSLdKLgSCi+YgJMQM8EeAhLz7WTELKl4qJQOeUciMHnmZGDNcXAlqKlONWwm/zPU25kLb8D lroTWLFmKR1aK50BNWYHVvLolUKD/8SWgP8wuuBU29ragn+OutbzoXWjBJ3mH6xAprkCEj77NANe CLH9lWHYDGHzlywb9x4S2Ow7BfD+Ur9/CpavfwLi67sw6ALSszIQ/tgrf3j+ZgJMQG8EWIHorUaS VB7NUwAjnCiYpCi4WNNAIFKPItK9aRA1obLkOZCEqi4WlgkwASagHwKsQPRTFywJE2ACTCChCLAC SajqYmGZABNgAvohwHMg+qmL6ZfE3YHy9Hw0jJLEgO11T2Hn+pWTnOSWVngPYm7xeuRmjErwrH9I q76ZNBk/ZNtMxlLYMYHxCfAqrPEZRROCFUg01JI4zklaTtto+Rn+8QLVeO7AsWasWrcKrvkOPHFD zsRLHmyFd+KxJhZS7jNhq74TY8WhmEA8CZB9lIRxZLdGyI+eHdWVnsWLLJvLKowwCqsrOJhH1Bkh DNUW4epsEsXGMlFZZqQze43ikMMlHGaToG0e8gxfYSirFtZ+D0UeEo1lqh9QIaxDQiOcmk+3TMOg hjdSGjan6h8+bUrdVkP51VAuie8Sur0kOP5EeJ7oHTHPgcRTOydo2n9zkUFDr5f+96Kv42d4vA34 Ul4OvJ730dzWgL3nrYGp5hZc0v9TLCzahPkmM7q7LVh3chvy5+1GX4gV3uzueo1wgPv4QVwq07ij RUljRcM25G0+iL/ateMkKFYWmwkkHQEewkq6Kj27Al2ENqyaE2ROVyZnrMLPrssGTig/YHnsXiyn yYeO2gK6V4eajYXK/Mj9L1vQlLkCBzu2YnOQFd6+/Zs1w133ylO0Cb0Gj228QZnP2NltxpI3L8Cf fnm3ZpxvhYh3diXm2EyACURLgBVIBHJHjhxR7q5evXpUKC3/UYES9IecA6lrr0f++TQHcuYMUi/I wdLcbMiGMowz9PcKZPu2jCsWS9bkjUyup5yjHC6lzJ4EWeGlpGDQCKfogqIlgTTSFhdi/WKa4qjV jpOgaDXF/u1vf4srr7xS8z7fYAJ6JcBDWBFqRtrKCWcvR8s/QlIJdOtC5F29DIZly7Bs+XI6dVBV HoECGBZhju+1Q5nLtr+N4BM8lMOlgg4EkVZ4I4WT92B+J5CGt+cwduyoRx8ZXrSPk3ZApgS/uPHG G3HnnXdicFA9RT7Bi8PizyACrEBmUGVPtKhngjVCaKSg1U8XX1kINKzDs0d74HYPoPmHd9MAWBm+ eBmNb3llb6UNr7zahTl52uEWXbeWNMUm1FMaXjedZHjfGuy2uPGZq7TjhIqU6L//8Ic/KEW47LLL 8K//+q/KAUfRlMnddQDKKXkltRgYlYAXrbsK6F45OoZH3ZjED7ksux5dUcefRFYcNGEIsAJJmKrS iaB+K7skztyV30O7qQKbVi1Eevo8lOwEGq21yJVDXEFWeH+WdptmuKxl0ipvpZJGavoCbGiogPn5 9bgkUtoSRZAc8mciu6ysLDz11FP4xS9+gWeffRbXXnst5LCWdH/729/wk5/8BFdddZXykdfSL5zz etT+H5q3wNIX9Bbg7kTdzjaK4rsfLvJ4fr5l2R/yoPd4pGbUfVYgM6q6xyls2jL8UvxSmSAPF1K1 shu8eS8NKzc+A49rCM6hIXgo7jeX+e2xq1Z4XS4P7l3+vyKE81nllWk4ZRrPoDBHaiDttMfKEU7a xPOT8yC/+tWvcNttt0EOa23atAmrVq3CT3/6Uzz22GPKR14XFBQoK+QilbDpvzoDtwde/3nI5lCg 77UDKJmlnmueV74Hdho9kz2YkpIdqN1VrvZkCspxUN6g2a8DG/Lp24789NuVXkxP675R8TsGVIXl 7jqIEoq3tVz2eArQ3OMOyMEXyUeAFUjy1emUlyhFWtTNyFAm2kMzD7bCGykcZBpk0j30BTdinNDM kuC3HIL61re+BTms1dfXh0svvRRmsxlyIYf8yOslS5bg5Zdf1ihtGRqpR9ewocU3jOXGkf07UWGq A+3XUZZBeHsOYsGKUmX5tcNhw22naen06j14j3owzc27seXktbB2WlA9uwHrNr9I6iMDxjvrqNNn gMn8HURalh261Puz83wrLjSkZe8EJ6D3jSrB8smNP4Rb959gmfmaCUQiEKk9z549W5hMpjHRpZ+8 54/rDzBkM5FfmbA6LLQhFKLJQXdcFmGgTZ/t5FdM3xbafWkzFVO4StHpHBLU6xP9tkYlrRf+v6fo Ww0j03QFb9j02AKbTK01RkHLt0Vgv+mQzAOihnaMqjKMpOGXTX775dXTt943Jgfz0+N1QvVApN1+ 2Q6n6kONC/ITmp+WvwzHjglMlkBo+5K/nU4njEYjfvnLX45J7pVXXkF9fX2gXY4OcBqp2VfgTupu vPBKFwZeb4bd+G1cnX1+0AzIbIqyF0vnZGIOfebllSpJvPtXOUdSiByfgbGgWRRaFKGsl4NcYBFx +XbIUu9g2cKVc7r9+CyQ4Bqa/HVCKZDJF49jMIHEIiAfqHIlllyRlZ2dTbvzu1FUVAS590h+5PVb b72FL3/5yxoFO03LptOwelMlmn/wBB7duRuVW43koyoAGclz5iQtQjCBLMbA46EXMk8/LOZ2/O8F 55L/JyDVi5Ybb1m2Ei9oqbdWOuyfHARYgSRHPU5PKbzHsUNOxJYfoHFydmdLQK68kiuw5EosuSKL hqrQ3t6Or3/967j77ruVj7yWvZKUlNDZoqDcad567nU3w2jfj71tRtxcSFYEgroTi65Rl07/5HAX eQ+j9enbsKJoFd7Dx+U8eXg3wWXZSmStNMKnzL4JTCBCK0zgUrHoU0Jg8I3/F7tlTg2laH3kn1Gc w80pGvByA+H3v/99vPTSS3jkkUewYcMGZRWUTOv888/Ht7/9beUzXtopqXLC2td/yLgC3y6jnTjn 3Ykr5JBU0GKorOVy6fQJrFizFNuURA2oMTvw+dk/H7s82r9cOmhZttvSR8uyT9IKsYXYpMQ3BpZv Ky8S/jjKPf6T1ASoy8xOgwDNdYS1/qvlL5OhxqKRWrJ5u0RjMUSxySyaKmlhQ5UlUMBwVnt7LY2j rPaqFnc9wtpYpUzASm4wlIlGa38gnZlwIcs9f/58cccdd9CEts8M8VQV3KVOogcmwyeQLy3LDoSi 5duClm+LEZ/ALb6YIQT4lTHC64GcxAzntPzDhU1av8FXUdoMNJkK8aWeamDFU7B/j0yf0Euwfykn KqrJau88fOaj/1SWjVaQ1V7HjXPx87vyaNko8NZ+IL90J6pbrPj6Zan4xSN5KF1/NdbQQVH+3SRJ yy+oYHK4alpsYcml05NcZTtmWXZQOfhy5hGYJRXlzCt2/Eos1/HPBKRdB8qxtHQJesX9yB62oyQz D59q6aVDp7IxbN+HzLwXYRlSNyXa95Ugb9On0OnchX8g9N6TzcrKn/r23+AfPJn4QmEuvMOD+MPh KuRXLZpRJw3OlPYSv39xnPJ0EuAeyHTST9i8+2iFT4Mi/YJZZL/E70zN2HnDRlrmKe1gjVjtVcfl 5bLRvf6QyvcpegNObdmG1CLqyvid0eS/4m8mwAR0ToBXYem8gvQonrvrv7CNVto0Wjppman8OGBr oWGs5k1oOe6brQ1ayqm1bPTSo5tQuns2WmwODNFy0iErpfGBVD7smAATSAQCrEASoZZ0JuOr/7aB NiybULw8F4sXy08ODDeUoYrkLD3wqipt0FJOrWWj756ZRWGX4LKlOUgb7MCj62lNkP0E/hK05FRn RWdxmAATCCLACiQIBl9OgIDbjjpau1u59UblBMGRGNlYV0frRnfW4c2PyDdoKae6bLQS22jZaHpq Joq2nFCWjd78la0wYicWps5C6rx8fLCukiKa8ad+1iAjXPmKCeiXAE+ix7hueFI0AlD3MAZdQDoZ TRxZ/OPG8KAXKZnkNwNn5Li9RGgvfEv3BFiBxLiK+IEQY6BJnhy3lySv4CQvHg9hJXkFc/GYABNg AvEiwAokXmQ5XSbABJhAkhNgBZLkFczFYwJMgAnEiwArkHiR1WO67g6US+u5wZ+8EuxrPT4l0g53 7KG890AekqrthnH0QD26yCrfxMJrp8R3mAATiC+BGbjuJb5A9Z76SVpf22j5Gf7xAjoXAh/irbZn UFJ0Kf54qBtPFC+Oq/hpi4pBx04gM1Iu3rewqvRxWF3rMaHwkdLie0yACcSVAPdA4opXj4lfiNwr aPNfbi5yc5eheOMzsJqKsbdkD477tl/0vXYAJb5eSl75HtgDXYYBHNxVHujB3F7bGjgH5HjrPpTk qb2bAl8cd9dBlBSUY2t5AcUpwKFjv0XdS8fwV/IvKLgdO7aWqGkVbMXRHrmDfRgHNuTTtx356bfj 9T8fU8L7LZH3yDyC5OoYUAV2d5G8JTtQ65eN8jw4IrQeK4FlYgLJQWCGWB2esmJSq5iyvCadkcuq nGstz8UOdq5OeZa2eo61x9GkmKQny7nC4bCJGjLZDkO1kEbWHYcq6F6ZaO/uFZ1mGQei2uoUrm5/ nBbR3W0R26Vp9rImMaic0U3XFdXCVFMnfv9qDcWpEe/6/A0VdaK7t1OYyigMqkQv5dFrqSPz7gZh MtvEu79Rw0txh2x1Sn5SLplHlXEkjnoOt8zHJKydFlEtZTaaREgxg4usm2tdtxfdUGJB9EpAx087 vSKLLJeuHwgaCkR9ABuFlZ64NlMxPagrRadTPSui39aoPLibHB7fPaOoa7GKfjoHot/hEGTDSlhr jKRkagIPbFe3WdQdsvoUiKqYJLUhW7ACofz8B1EMWZQzQZoc5OGxKUpO3vOHl4pAycNYJ/xRhC9O DQntl9+vGF2+fFiBRG6rfJcJnC0BHsKiJ/6Mdx7VgKH6V55oJy3nZmIOfebllSp4+t4fguG2H8NU AWxYk495mXTvrudxrN9N1nfJFS0J7C5PW1yI9cXLkDLGKq+SFP2ROa3FEv929JRzsIh83u6jbepe 9ezuMyHWTGQehjV5gTzgiyNnctT0CpEjT94jFxJV9eS/TIAJxJwAK5CYI9V/gueMWjrhxuFnttDT eS0W0wNYy3LuTYsyMdh3Ctfe9zKEqx+29iaUNe9ERcPvlEc4zO8EHtzensPYsaMe7/6dWARZ5R1N 5k38JcjjNF1fNDc94DNaRlVN2O1vB/KQAWUcqOqL8vmE/zBXxZf/MAEmEH8CrEDiz1hnObTB9moH Ojo68NrRw6jdugbr9gPVT30Dc0lSLcu5fdSf+OPzdJLgwvthd2XCcPWVZEdXOuo9XLeW5r03of5o D7zuPjTctwa7LW5kfpxuB1nlVTWNGgfYjycPdMDtHUTzD+9GGypx3WJ5nKHsnbThlVe7MOyfPSef i68spLPX1+FZysPtHvDFKcMXL/N1O4LzkVmwYwJMIO4ERr2Lxj03zmDaCVxEEmwokiudfM5Yhjpz N9avlOoDUC3nnsAKspxLxtXJGRTLuSvlGbPfsWJ7az7y/AdDGatg+/YyZGXlwVJHcVYtxCYlTgXM jvXIOEWaKcgqr9JZCPw24u0f5CNdGSEzoqlzF3Jk3IwcrCkGthQtxakGMvtrOE9Jce7K76HddBKr AnkY0WitRS7pHNoyMjqfcL+VVPgPE2ACsSTAxhRjSZPSShrjeGEt56qw3MPDNJSUgowM/ySGD6Iv TiZZ2430ZjJsr0Vm6Tl0dO1GYHAYaWHCu91eBJ+/7a8mL+UxRJMcmRmR8/CH1/t30rQXvYNm+eJC INK/87hkyIkmCAE6bjYrRD/4JU+jh3dYFyHOqPCeUzS0da4yopVFyiOcC6c8ZLgUmUe4COzHBJjA lBNgBTLlyDnDjCW3wGL1RN6RzpiYABPQPQEewopxFfGQRIyBJnly3F6SvIKTvHi8CivJK5iLxwSY ABOIFwFWIPEiq8d0w1njJdtSBeW70BGwd6VHwVkmJsAE9EiAFYgeayWOMklrvE02B3odDjjo020z Y8XJnchfXx8wjBjH7DlpJsAEkogAK5AkqsyJFeVCfGppDrJzcpBDn8WGQvzLLbTx4sTpwD6/8NZ4 tS3xRrKSW1A+opjcXfXU21F/h1rqbSZrvOEs+soyTVaeiXHgUEyACZwtAV6FdbYEEy7+B7BZ7DhP OQ8E+OuJX2Hnhmag4lZlVZS35yAWrCglw7ZmOG6ci5/fRbvPVwMdDx/Hup0AWeLFXEczlhYVYfF1 TtyReggLizYp4buvPw8HbluB/HkfoVfcj9kfvo+2BgL0ggrJ++HpwG+v5300y5sV1TDVzMOlw/+J S5V0WtB9/QV47tIVyMOn4HoEk5Ln3mW8yDfhmiQLnLgEztYaI8cfTYBawmgPPf0ia7xl0tR6yKe4 6pDo9Zm51bLG+9ijX6Z4GpZ4Na3kjpqttcgAACHWSURBVJhjlxiCreuGWtDVsuj7Ww3rwFry6An3 RGTRdXuZSAE4zIwmwENYiav7o5L8JIxod3pIy3ngaK9R0ph98SJkBzYNhrfGm/KFRzQt8WpbyY0k orR5dUUgXy2Lvh9XTCSOtQ6sJU+kHPkeE2ACsSXACiS2PBMitdRUOXKZgpyVm2Gj05waNuSh3q5Y lNK0xntd2t81LfFqWslVLLO7A3Mr8ARZR5Skgiz1KkHNYy369rlPUjgTnELA4xEQnn5Y6FxcLXkS ogJYSCaQJARYgSRJRUZbDMPGR1BFkTeUPoE++tayxvv6v18Z1hJvJCu5KefJ3sw2vEAWdIcH7Hg0 n8wzGs8ZETXIgq6WRd/PLl+rWPr9yeEusr81jNanb8OKolXQkmckcb5iAkwg7gRm9ABeHApPFRaH VGOUpOaJhL7jYpu6KSOPsNRVBs2TGESN2SGE0yq2G4PmT4xVwkbdAkFnBLab5FG3/ntG0UjH3KrO KRorDYF7Rhnfd9SsMh8SdIrh2HwrhFmeUDhpeXxZJ8iXrttLgjBkMaePAJsyibGKThrTFBrWeLUs 8UaykqvGSSPrvXLobBynZdF3kvKMk4tubidNe9ENURZkKgmwAokxbX4gxBhokifH7SXJKzjJi8dz IElewVw8JsAEmEC8CLACiRdZTpcJMAEmkOQEWIEkeQVz8ZgAE2AC8SLACiReZDldJsAEmECSE2AF kuQVzMVjAkyACcSLACuQeJHldJkAE2ACSU5gAgvzk5xAHIonl2ayYwKJSIDbbiLW2uRkpm2Hk4sQ ITQrkAhworkVy8qJJn89xnnooYcUsR544AE9iscyhRDgNhwCJIl+xvoFgYewkqhxcFGYABNgAlNJ gBXIVNLmvJgAE2ACSUSAFUgSVSYXhQkwASYwlQR4DmQqac+AvB588MExpTxy5IjiF25sPVz4MQmw BxNgArokwD0QXVYLC8UEmAAT0D8Btsar/zpKaAl7e3tx1113KWX48Y9/jAULFiR0eZJdeLYOnNw1 HOv65R5IcreXaS3dU089hZycHJw6dUr5yGvpx44JMIHkIMA9kOSoR92V4sSJEygsLER9fT1Wr16t yCfnQtavX4/W1lYsWrRIdzKzQECs31CZqb4IxLp+uQeir/pNGmlefvll3HrrrQHlIQsmFYn0k/fY MQEmkPgEWIEkfh1yCZgAE2AC00KAFci0YE/+TL/85S/jueeeg38JryyxvJZ+8h47JsAEEp8A7wNJ /DrUZQnkHMc999yjzIMYjUZFxra2NtTW1vL8hy5rjIViApMnwJPok2fGMSZBgJfxTgKWDoLGepJV B0ViEYIIxLp+uQcSBJcvY09A7vv43Oc+pyTMe0Biz5dTZALTSYDnQKaTPufNBJgAE0hgAqxAErjy WHQmwASYwHQSYAUynfQ5bybABJhAAhNgBZLAlceiMwEmMBUEvHAPD2PY7Z6KzBIqD1YgCVVdiSms PMqWj7NNzLqLXuph7CuYhZL6rkAS3p5m5M0iv9rXAn4YaFX8Dhyf+MN52L4Ps/JqMTySinI13LGH TLHswWCIf/Q/3Thav4vkS0V6ZiYy09Mp/RLUv9YXfZJJFpMVSJJVKBeHCeiDQAY+Wwg0/0cH/KrB 8Zv/AzsJ1/zsf8P/CB6w/w/5VeAfF6ZNXGzPGSgJhcRIW1QMc3sxMkP8o/vpReuua7BqQxPuaLGi 1+mEs9+Blpr52LBiAeq7QtVXdLkkeixWIIleg9Mov7urXnkj6wjzb2kib4Nab5LTWCTOOoYELjdW kbY4gne8MtFhHH1qPyrrGlFs34k3ehRP2P9nN1BxExbShoKe1n0ooR6K3KuQV74HHQNqGHfXQZQU lGNreQHdK8D/ed8zIuVgB7ZST6d8z1G4ncdQ99IxRWG5uw6gpGQHaneVK+nNovgH7WrfxH5wj9Lr mTUrD7v21aKcwnX5tZwvZe/xn6Nopx0m6xFsvGEZsrOykDU3BzdsrkFTZRn6+5xKyFDZmnvcYcsh 5Skorw/0muS/Hf9vmUZBwe3YsbXEJ+tWHKV0EsLRKXHsmEBUBIZsJgEYhXVobHSPs1OY2zuFZ+yt gM+QtYbi14gw0QNh+GJqCdBDK3YZOtuFgdJrclCSLqsw0nW70ykajRBljd3k2S9IxYjKFocYstVR W4CoMJlFd7dFVFEYoEr0Uii1ndHvimphqqkTv7dQuzHUiSFPt6ikOCiuUcMFtaeROCZh7bSI6mIK ZzSJP1tlm4XY3mgR3dZDoljGR7GwhDTCIZtsm8XC5oqMYyQfn2yvhy/HW0GyyRSD274/DUNFneju 7RSmMimTWvbIuU/+rix7LF1sU4ulZJyW7gmoDT+8AnF1N4myyiYx0Nkoiou3i5qqMuUfLoxlosnm VMqm/iP1KRCnVVQa6cFS3R5R6egeSoILGNsHjFPUGEgptPQKl61aeSjKmu+sK6aHfpMYGmpX2kRL vxDWGiM94OtE4Hk9ZFGUTw29nfjbmf8hr/4uFhXUXoIftMHtKTSOS1EINeI1mU9xY6CNDVmkXGPb sONQJflvF1L3KY4UYJmibGSeVKY6m+Idmo9WOfa8uIfijbwshZPV6i+8r+xNDr+HT4YYfMW2foXg ISwiyi72BLyn+tCwtw9ez2k0N+/GlpPXgt4EUT27Aes2v6h25eVIhGE24D2OrXPysXd2DarvXQk2 jxD7+pieFLNw3W1G7G9/A20tDfSsNyKLBLlk+Voa2vpvvNLaRr+qkD8XSKUrw5o8BGZCUs6BemKM bCQ054ErkB24ST/RjP1t8tuJ02FHe2ScQuRkyDDUxNQvON5sg6Eod6SNnU/tL4ybs+gz5GvB+/60 Uy7GhkNNONRyCDWkSd467R9GGy2bdjn+HiYXv5dMYy2W+MvnK/vbfS5/AN1+swLRbdUkuGDyX1LA GWF5bCOW5S7H5odrgDb5D4Zc6jk0GfofuPv6S7GXHiS9hzYjW73Df5OEwJLrbgZ2fx/3brOj+vrL lVKlXbqcps33Y03JThirrwfpD8jHsd3+duBBLwOeln8U1UJfhkWYE3izkO1nO7qdnaiklrO06rAM ONYZPoFQ9ZD9WSPsrwflIyfkw7iM+ZfAgDY885Kc9ieXMheFxV9D8Q3FKLjagA/8ikXeC5JNsxze j1NAt1JOGQWe4ASkx5v4i/zyOVn2i+am+3/q9psViG6rJlkEk/9Ax74JjpRuvDfJkZB8lXgEMi67 FsW0ZMoOI75wuex/kEu5BNdXqJdrvyDf9IGLrywEGtbh2aM9cLsH0PzDu+nxXYYvXubrQvie40pg +ZQ2zMeCrFzsbK8mBbUG+zpogtzfKVAC0Z/gOD6/SwtuUfJ5vLkDfcdbcXf+FrozW+nj+KMp33Nv QL2pGPtL82iC/iDsx3vQc7wDB/bcjrwtdlzo7y3IwEH5aJbjs1JNbsMLVL7hATsezd9GI2f0AqU4 +b0fTx6gFWveQV/ZK3Hd4uBMfEF19hXQ6TqTi8VJJALjtaIwb4Jq8fxvkv+CJ+cspTfJ/w3x6A2J VHKWdTwCaYuwloZ8mk/fjCU+XQAaqLrmJpr+3v82rluiKpW5K7+HdtNJrFq1EJuUNI1otNYil56h yiI/mo0POF/vVg5LZa3cTKuitmFd/pMosn2CFEsg1Ohr6U33Mgzr0d3Sj0vX5NPj3ICyMvJsuArZ AdlG4i/b+CIss3+I7aXrkEfPe9UZUFVnxnfKlvk9RuWjVQ5pT7Sx0oBSKp9UWUbjSHT1yoi3f5CP 9FL5y4imzl3ICQ2iw99szl2HlZIoIslluJl5T6POXI+8C2ikWhkNOIO5n7kK/3DiaWTmA+/agP+V BwyJzZD/RofttRRH/Y0Oul4PuGyb4Tq6B3NWbaNlk05sXOZ7U00UEEkkZ6zNfU8Wjdc9jCHSDJkZ GSPzFJNNJEL44827sKfrWtTcW6jMt/Q0346FJZ8NtM/wUeVOdDcNr6UgLSNtQnJplUPuaPdSzhkZ I29dyr+J0nMwZNsIDA4jLSs+ZZdli3X9jpQiPDn2ZQKaBFJSZRfbjg1FpCmCXLXFiTvOJw//26D/ 2x/G/1vjTbJY3M9zIX5WM+w7JS1DmWiPV7EXXvE57C8pwv6WClReZMHeBjsqmzqVlxvtPKXiCNNF 0Y4ArXKETcdziv4ZnauMwGWR8kgkxz2QRKotlpUJxJlArN9Q4yxuVMm7+7rQ9moHrd/KQO6VK7Fs 8TT3eId78NpbHly1bPGEejdRFdoXKdb1ywrkbGqD4zKBJCMQ6wdMkuFJ+OLEun4/lvBEuABMgAkw ASYwLQRYgUwL9pmV6UMPPQT5YccEmEByEWAFklz1yaVhAkyACUwZAVYgU4aaM2ICTIAJJBcBViDJ VZ9cGibABJjAlBFgBTJlqDkjJsAEmEByEWAFklz1yaVhAkyACUwZAd6JPmWoZ2ZGvb29+P3vf68U Xl4vWLBgZoLgUjOBJCTAPZAkrFS9FOmpp55CTk4OTp06pXzktfRjxwSYQHIQ4J3oyVGPuivFiRMn UFhYiPr6eqxevVqR78iRI1i/fj1aW1uxaJF6XJDuBJ/hAsV6p/IMx6m74se6frkHorsqTg6BXn75 Zdx6660B5SFLJRWJ9JP32DEBJpD4BFiBJH4dcgmYABNgAtNCgBXItGBP/ky//OUv47nnnoMctvI7 eS395D12TIAJJD4BXoWV+HWoyxLIOY577rlHmQf5/Oc/r8j46quvora2luc/dFljLBQTmDwB7oFM nhnHmCCBL33pS7jgggtw/vnnKx95Lf3YMQEmkBwEeBVWctSjLkvx1a9+Ffn5+fB65enVQEpKCqxW K1566SVdystCxf7IU2aqLwK8Cktf9cHSaBA4fPgwjh07pgxj+YPIIS3pJ++xYwJMIPEJ8BxI4teh 7krw0UcfYfPmzcp8x7nnnhuQT17LORB5z263I/heIBBfTDsB+ZbKjglMhADPgUyEEoeZFIEf/ehH uPzyy3HDDTeMiSf95D0Zhp3+CAghMFM+Dz74IORnppTXX85YtjrugcSSJqcFh8OBvXv34o033tCk 8cQTT+Cqq65CWVkZFi5cqBmObzABJqBvAtwD0Xf9JJx0W7duRWVlZUTFIJWGDCPDsmMCTCBxCbAC Sdy6053kr7/++piJcy0h/RPqMg47JsAEEpMAL+ONcb3xBGSMgc6A5OTYNLv4EpBzHaHObyXBb+wz +H648MH3+VolwHMgcWgJ/ECIA9QkTZJfOJK0YmdIsbgHEuOKjvVGnRiLx8npjAC3l+mpEHm42V13 3aVk/uMf/5gPOouyGngOJEpwHI0JMIHEJMAHncWu3rgHEjuWSkr8RhljoEmeHLeXqa1gPugstry5 BxJbnpwaE2ACOibAB53FtnJYgcSWJ6fGBJgAE5gxBFiBzJiq5oIyASbAB53Ftg3wMt7Y8uTUmAAT 0DGB4IPOjEajImlbWxsfdBZlnfEkepTgtKLxpKgWGfYPR4DbSzgq8ffjZbyxYcw9kNhw5FSYABNI IAILFizA5z73OUViec0uOgI8BxIdN47FBJgAE5jxBFiBzJAm4B4exrDbPaWllXm6fcfZTmnGnBkT YAJTQoAVyJRgnr5M+l6rRwGdMJeemYnM9HTMmlWO5q7hmAs03LGH0t6DQSXlYRzcmqfkmZ76T0H+ 0WQ7jKMH6iFFHp1HNGlxHCbABGJJgBVILGnqLa3h11C6YgOuqGtHb78T/b3daKo6iZKlX0ZHjDsj aYuKYW4vRqZk4H0LT+21o7rdgaG+qhH/aPhQWqtKH8eHNFs3Ko9o0uI4TIAJxJQAK5CY4tRXYt6/ nEQbiXTt8iuRPTcLc7MX42vbn4Wpai3OON1wdx1EQcHt2LG1hHoJszCrYCuO9oxolr7XDqBE+tMn r3wP7Gr3Asdb96EkT/Uv8Pl7ncdQ99IxuN1d2Jqar+S7bdWX8O+/tav+PjTh4pLGQceBXcjz5TUr rxwHOgYoxjAObMinbzvy02/H63/25eFLq0fKESRfx4BXuePuIrlLdqB2V7mvXOU46BfeF5e/mAAT iAEBMj3OLoYEqEpimNrZJtUrqo2Qh00IY1mlMDUeEjaHM5DokM2k3DNU1Inu3k5hKpNhq0QvhfA4 mpR7FSazcDhsoqaY7hmqxZ+7/f4torvbIrZT2ihrEoPWGgpfI4aES3S319G1QdSZreKtXz7h8xfC pRG331Kt5FXdYlXyMlXIvGqElLTXUicMlJbJbBPv/safhxBDNpkHhJRPylGllFOV3V8uVJiEtdMi qqXsRhPJpj+nr/aiPz7xlIjO/BDywy56Anp62kVfCh3F1N8DwSnaG2tEmdGgPHClfFJh9BMz9UFr FFaXD+CQhR7WEE0Ol7CZiil8peh0DgknffptjUr8PQ+uVh7u/oexq9ss6g5ZxaBt5OEuPDZhhJru UJC/tcYYNm5/t1W0mDuFh8RwDTmFtalyJFyktIx1pK5Gy15jHQqUy+IT0hUkgz+4Xr711170Qib+ crACOXvGPIRF/4KT1XkH+3D8uBcrv7kZL/zSBo/LCUtTFez7N6DuNTkedYY+a7EkzUcg5Rwsosu3 +1z0dzZ99mLpnEzMoc+8vFIl0AfDfweKlsAfJW1xIdYXL8OoDUVejxL2jDqipFzLP6nyT5i4cxfO h/N/tiGVhqPSM+cgf91e4MJzZGga3dJOy7AmLyAHfLIDMrwsVyFyMmQCcoCMHRNgAvEgwAokHlR1 kmbni6W49NJH0eeTJyUtC8u/9j2YqJthf/svPt834b+SHqfpc9HcdHjOnKRRKBNoGAkej4Dw9MNi bsfnL/w4YH4n8FD29hzGjh31eJf0ynhOUQVh4rbuL0Xp7tlosdGkO+U1ZK0GPpBKYMSdM0pDqWrC bn87IIcMKWX3qSmS/ROKClS8dPrngw8+UCT76le/CofDoVMpWSwmoE2AFYg2m4S/s/TGO6kMe7Gg vBavdfWgr6cLzbXfxiY7dQSWXUL35Fv+fjx5oIP2awyi+Yd30+R3Ja5bnIZF16wlLbMJPzncRQ/p YbQ+fRtWFK1CyvKvKv71R3vgdfeh4b412G1xI/P/p6TCObUDodxZdJ2aZmjcc5QuwhJctjQHaYMd eHT9NsrjBP4i/b1SkbThlVe7aB/LSAYXX1kINKzDsySH2z3gk70MX7zM1+2gMurdXXjhhYqI+fn5 uOqqq/DII4/go48+mnKx3V316mID/yIG+U0LKlqDFlSEE2rYXotZebXUOtjNWAJnPwrGKQQToIYU /HPar3tpQruYZJJyqR+DqD7UqcjlnwMpNvjvGUVTp392wyMsdTQXERSvxuygeKH+FcJMcybKXAdN fCuxXVZlDkTOQYzy14rbeYjC+2WgifEqma9BtPTKWRFaCCAnwel+VcPukbkRmv1oN1UEyWcUjVZ1 gcDoPENlmPYqGSWALJd077zzjli7dq349Kc/LVpaWkaFOXnypHj++eeVj7yOtVPbgUE0WTpFd2en 6LRZhKlSzpltF7LGtdxQYOGEVgh9+/McyNnXj76edmdfnmlPwf9AmHZBQgRwDdHkMn3kI9nv1Aet ujppiCbKg+/5w9CstjKJHpis9t/w+YeN4w+j9R02LikhksGlkaBL44ZHphVSLq1s9egf2l6k8pBK RCoTqVSefPJJ8bGPfUzceOONykdeS79YOlWBFAtbUKKeTrlCzyD8CxF6LY2BFxFDWbWwka5W2o+y 8k6N6DCbRoWx9quV6eqkuMXbRU1VmarwjWWiSSbgc7amamXxhsyvykQLPihsp6tfNPnDk5KtqDHH fBUdKxB/DUT/zQokenZhY4Y+EMIG0onnkLWK/kFXK8tldSLSjBMjXHtxu93i4YcfFjTEJbKzswWZ Gw9wkdeXXHKJePvttwN+Z3uhKhDq4dU1iqbGRtFoqlYUgaGqXUlaa0n3iaDVbdEuq3Za1aXk2xst ott6yKeAisV/vCh7l2WivbtXdJJikpyqfT3Msy2vPz4rED+J6L9DpiapmtjNGAIZS26BxepRd4/P mFLrr6APPfRQWKGWLVuGVatWYfXq1YH78vrWW29FZWUl5P2zcQ888MCo6E2P/0D9bbfT1k1ybx1H n3clPvjFC/SjEltvvkZpK994uBFbaFXeK+8+Tv60qILcW798HjDWoWZjobIy7v6XLWjKXIGDHVvx LWX5nRGWxzZiGU1RXfZwDbblqYskTr7yIlDciKpvLldW8jVaqpG5ogVn3pWpnsbxP72H3OvK0O+4 EenZWdIz4LS4BQKMc1FfX4/169ePE4pvRyLAk+iR6CT7vYwcLF+2ePQS3GQvM5dPg4AR9b+xwWaj D628G+psokUKG/DcG3K5d/gl3e/+dWTCX+qIaJZVn3izDYai3JE2eL7MC7j0lh+DNpRiw5p8zCM7 bvPueh7H+oNWUSihzu6PVB7+Q6XOLqWZG5t7IDOm7t20iikFGWmxrHJan0VLo1JS0pAW03RjUCle Kq83jcobg7TinERoT0CuxPrRj36Ejo4OvPnmm1i5cmWgF3LkyBE899xzaG1thTxdL14uI/dylFHi TrKhFljSbduITFoZl4IBvNbehfPOfQP3+gSQi+3UZdUje4Imsqz6os8aYX9dLsf2xfOoPZPT757C tfe9DFHjovtHsGfVOlRcez1s9y4PFDmUW+AGX0wZAe6BTBnq6czIjQMl6Sh9qRtwd6A8eLmm77qg fBc6fLautMLIJZtqEFryW3s7Lf1MRSa9Haanp6Jgaz3GWfU5OQBuuyJnbUCooOjhypBXgn2txwOB vH3/SdaHS9CRYGtMDx8+DIPBAKvVqnx27NiBwsJC3HTTTcpHXt9zzz1xUB4fwPZqh6K0Ol5rRe3W TWggmtd+doHmku73fMNXEnq0y6qXFNyiLMd+vLkDfcdbcXf+FkptNo4fyEPewvthd2XCcPWVWCIz UZadKxf8Ry8Eop8+4ZjhCFC9hvOeVj+nYmtqu2LjSihLbGnJps0heh0Osj3lEN02s9hupKWyxXWB Zbhy6W9FYzvZmaJlnXJpZ6dNdNKEpodCNCo2s2gljaWbVkA5RW+nWdBog2JvamRtzVkWWZGTXkDD TZz6ytDoX3baaRWHfEt6Kw91BzK2VNNS1Epz4LceL/ztZTqX8bo6VbtiUpbAx1AsalrU5d5jl24b hFzSPXq5dPTLqrtbVFtochVWWZlcPlwlHE6r2ib9MhmrlJVfeqzDmSyT/p52CV4b/geCforRL2hf t6hokSYSySkPX7JTFbJctrOObF/5DBiqYSBMnSGBZHSfAcbG7tELe12dTaKi0iQcY6MI7eWdTaKY lnRWlhnpoWEUh2g/ScCNq0CCbHj5IlkV+10Votsvg9OsPBBbpOEvnTrZXuSKq09+8pPKt1yBpVun taQ7SODJLqvuPlQlKqrNAZtmjkNy9ZVvPxGlqy4/D2oXQXnx5fQTiOWAOP1bYKc7AgN2bIMB5vzs INFouMJix3kXqCZB/nriV9i5oRmouDWwIktOZbY0/QxLrp2DMzQsLT+fXfkFzB6QZtbV3epBCSIt 92t45olgH/V62F6PhUWbyDCuGd3Xn4cDt61A/ryP0Cvux2zP+2huo4GSimqYaubhs/MmN2ERamvr MuMayvRFDNBc62K5IT3rStSQ2ZbG/+7CDd/MHSvcNPv4TZnI4ao33ngDCxcunGaJxsk+LQNZ41RR igwzTjLBtxde8TnsLynC/pYKVF5kwd4GOyqbOuGzJ4C0DP9VcCy+1gsBViB6qYk4yTFMZ2iQZUJc kD6SwUW0SHPDqrwRD7oqrjqE3u8VB1bDSAXSsLMUpFYCzmQbwjXHWqmzcDPmBHwjX0xseee9WB7h OeF1y6NxffnQhL1WUJ/dxaCR8kwsKQKePfnXyEJO012/KZOXXnppmiSY/mxTcorh6u1EG82/OHET rA+uxLLFk1FB01+G/9ve/YXmFMdxHP+oPcvyL8rNwx7WxKM8I4uSxmo3lESRjJXdcbPmQu5WlFy4 EPkTLubClHIh0XaDmcINai4mbWmFiylTIyu78Pudx54/ZjYczvfM+9Tm7HnOc873vL6P5/v8zvmd 3/mfI+Ak+lTPftAHf7MqCj51X6tWXe+/uMOXX9TfdSoQmF1eoWTBt0vfg8ZduOUPceZ+9mdmaqkf z6qzXa/G9Kgc1NPHT4Nv/4WkE3fvXFW03cLXZuc/6dxadztef0ve4La8576dyB+7pOsuFDyY/e1n S7R4Wa37t9T/wWRUYHoyrU076lW/YyvFw2iOxguLAjKezFR5PBjM0H3gf9cbKZHwjc8SpWqa1O3u JHWlsUqXn+cX8gWkoJ7kNKbPSbr5m7rx0B/Kyk+DD86oel217g+MNhWyz+W7d+aX9evOj5pboXk/ bQfPUMOtXnX39MidyFdPf0PuEEnxCL3D6rjgevBktmcPXwXbGNHLZ53BHL8QQCB8AQpI+Kam1jiz fMWE8WT2H9NRt1TjnpO5od/He1FJ5Ta1N0stdXU63eFaHIPv9OLuZW3c0OJGnmjTllRxNfjd7p2F 25+bqlQmnVY6nVE6NXp4ozPX7fTxgw7X7XSzdl50raazuzU/9+JhvX0krVw4J/cIMwggEJ5A8f/2 8NbLmqwIzE26C8I6dfvZO62uyX+0FoeX0sHuVrVUNerI9Xpd2JK99rg0ERz/Kl7UtVo2nXijtrLD 2uOuEva99v1U29yq/uP1Y1ot82sOqev8azckxyIdyC6ptienlXbNm6C9405y/3hKaOGPnwge9c81 1lXnl6jdq9Y7vdpXuI8fX+qaG5Nj1+oF+eWYQwCB0ASm+Y5goa2NFQX3VbBG2ne1QUsu1enzvX1j PuD/KGX+au8hd/fCslkTXuHuT4QPuaNbs1yvmn/1raXvutvvo+s15K6gLjgF9Ee7HPaLp7kLOa29 X8LeR9Y3dQUoICHn1uQHwkifGhJLtMb1ompyJ8L/i2nkhdvn5Vrv9tmf/Lc6mXy/WMUiLnMCnAMx l5K/EFBJpc733FHyw/u/sHKbqxwe+KCdXb2mi4dNOaJCYPICtEAmbzWpJflGOSkmFvomwPuFt0Kc BWiBxDl7xI4AAghEKEABiRCfTSOAAAJxFqCAxDl7xI4AAghEKEABiRCfTSOAAAJxFqCAxDl7xI4A AghEKEABiRCfTSOAAAJxFqCAxDl7xI4AAghEKEABiRCfTSOAAAJxFqCAxDl7xI4AAghEKEABiRCf TSOAAAJxFvhXA6PG2eiXY/fDUzAhgAACU12AAhJyhhmaO2RQVocAAmYFOIRlNjUEhgACCNgWoIDY zg/RIYAAAmYFKCBmU0NgCCCAgG0BCojt/BAdAgggYFaAAmI2NQSGAAII2BaggNjOD9EhgAACZgUo IGZTQ2AIIICAbQEKiO38EB0CCCBgVoACYjY1BIYAAgjYFqCA2M4P0SGAAAJmBSggZlNDYAgggIBt AQqI7fwQHQIIIGBWgAJiNjUEhgACCNgWoIDYzg/RIYAAAmYFKCBmU0NgCCCAgG0BCojt/BAdAggg YFaAAmI2NQSGAAII2BaggNjOD9EhgAACZgW+As8hz4TTNfmpAAAAAElFTkSuQmCC --001a11c2906c2eb1f4050ed18007-- From nobody Thu Feb 12 23:28:42 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1CA1A1B62 for ; Thu, 12 Feb 2015 23:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUZQ_3RSmN5B for ; Thu, 12 Feb 2015 23:28:35 -0800 (PST) Received: from delivery3.ufrgs.br (delivery3.ufrgs.br [143.54.2.213]) by ietfa.amsl.com (Postfix) with ESMTP id 096331A1B5D for ; Thu, 12 Feb 2015 23:28:35 -0800 (PST) Received: from delivery3.ufrgs.br (localhost [127.0.0.1]) by delivery3.ufrgs.br (Postfix) with ESMTP id 0C8D830010D; Fri, 13 Feb 2015 05:28:32 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery3.ufrgs.br (Postfix) with ESMTP id E8FC9175; Fri, 13 Feb 2015 05:28:31 -0200 (BRST) Content-Type: multipart/alternative; boundary="Apple-Mail=_42FF28FE-5170-4AFC-905B-E80DD737B34E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: Date: Fri, 13 Feb 2015 12:37:00 +0800 Message-Id: <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: "codematch-develop@ietf.org" Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 07:28:40 -0000 --Apple-Mail=_42FF28FE-5170-4AFC-905B-E80DD737B34E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Kathleen Thanks for the feedback! The absence of a mentor as mentioned by the = IESG is interesting and reveal an aspect that in fact we didn=E2=80=99t = put much effort on it yet: the life-cycle of a CodeRequest.=20 To me, a CodeRequest is an explicit call for FUTURE developments. If = someone is questing code, that=E2=80=99s because (additional?) code is = required. To help in the development of new code throughout new = projects, mentors seem to be mandatory. 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=E2=80=99t 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. 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. Another option is checking how we tell the story. The question may be = solved if we say that =E2=80=9Cmentors exist to help in the development = of new projects=E2=80=9D, implying that already finished projects has = now association with current mentors. Too simplistic? Best regards, Lisandro > Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty = > escreveu: >=20 > Lisandro, >=20 > Thank you for your time and effort developing the data model with the = team! This looks great from what we discussed. =46rom 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. >=20 > In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >=20 > 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.). >=20 > Any other comments? >=20 > Thank you, > Kathleen >=20 > On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville = > wrote: > Dear all >=20 > 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. >=20 > Best regards, >=20 > Lisandro >=20 > >=20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop = >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_42FF28FE-5170-4AFC-905B-E80DD737B34E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Kathleen

Thanks for the feedback! The absence of a mentor as mentioned = by the IESG is interesting and reveal an aspect that in fact we didn=E2=80= =99t put much effort on it yet: the life-cycle of a = CodeRequest. 

To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=E2=80=99s because = (additional?) code is required. To help in the development of new code = throughout new projects, mentors seem to be mandatory. 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=E2=80=99t 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.

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.

Another option is checking how we tell = the story. The question may be solved if we say that =E2=80=9Cmentors = exist to help in the development of new projects=E2=80=9D, implying that = already finished projects has now association with current mentors. Too = simplistic?

Best= regards,

Lisandro

Em = 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model = with the team!  This looks great from what we discussed.  =46rom= 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 <granville@inf.ufrgs.br> 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

= --Apple-Mail=_42FF28FE-5170-4AFC-905B-E80DD737B34E-- From nobody Fri Feb 13 08:13:00 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AFE1A8741 for ; Fri, 13 Feb 2015 08:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCst3apbXM6l for ; Fri, 13 Feb 2015 08:12:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0670.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:670]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBC91A0358 for ; Fri, 13 Feb 2015 08:12:45 -0800 (PST) Received: from [IPv6:2001:13c7:7001:7000:a820:e341:30dd:d7b0] (2001:13c7:7001:7000:a820:e341:30dd:d7b0) by DM2PR0601MB780.namprd06.prod.outlook.com (10.242.173.140) with Microsoft SMTP Server (TLS) id 15.1.87.18; Fri, 13 Feb 2015 16:12:38 +0000 MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_30686484-8798-4C69-80CA-DFEEA8FBC70D" From: Christian O'Flaherty In-Reply-To: <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> Date: Fri, 13 Feb 2015 14:12:32 -0200 Message-ID: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> To: Lisandro Zambenedetti Granville X-Mailer: Apple Mail (2.2070.6) X-Originating-IP: [2001:13c7:7001:7000:a820:e341:30dd:d7b0] X-ClientProxiedBy: BLUPR01CA042.prod.exchangelabs.com (25.160.23.32) To DM2PR0601MB780.namprd06.prod.outlook.com (10.242.173.140) Authentication-Results: inf.ufrgs.br; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB780; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR0601MB780; X-Forefront-PRVS: 0486A0CB86 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(377454003)(479174004)(51704005)(24454002)(51744003)(35774003)(86362001)(93886004)(110136001)(50986999)(57306001)(76176999)(77096005)(15975445007)(2950100001)(36756003)(62966003)(84326002)(83716003)(512874002)(19580405001)(19580395003)(82746002)(50226001)(87976001)(40100003)(33656002)(77156002)(122386002)(19617315012)(46102003)(92566002)(42186005)(7059030)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB780; H:[IPv6:2001:13c7:7001:7000:a820:e341:30dd:d7b0]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB780; X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2015 16:12:38.7409 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB780 Archived-At: Cc: Kathleen Moriarty , "codematch-develop@ietf.org" Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 16:12:55 -0000 --Apple-Mail=_30686484-8798-4C69-80CA-DFEEA8FBC70D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Kathleen,=20 > To me, a CodeRequest is an explicit call for FUTURE developments. If = someone is questing code, that=E2=80=99s 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. 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. > 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=E2=80=99t 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. >=20 > 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: >=20 > 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. >=20 > 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.=20 Christian >=20 > Another option is checking how we tell the story. The question may be = solved if we say that =E2=80=9Cmentors exist to help in the development = of new projects=E2=80=9D, implying that already finished projects has = now association with current mentors. Too simplistic? >=20 > Best regards, >=20 > Lisandro >=20 >> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty = > escreveu: >>=20 >> Lisandro, >>=20 >> Thank you for your time and effort developing the data model with the = team! This looks great from what we discussed. =46rom 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. >>=20 >> In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >>=20 >> 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.). >>=20 >> Any other comments? >>=20 >> Thank you, >> Kathleen >>=20 >> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville = > wrote: >> Dear all >>=20 >> 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. >>=20 >> Best regards, >>=20 >> Lisandro >>=20 >> >>=20 >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop = >>=20 >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --Apple-Mail=_30686484-8798-4C69-80CA-DFEEA8FBC70D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi Kathleen, 

To = me, a CodeRequest is an explicit call for FUTURE developments. If = someone is questing code, that=E2=80=99s 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.

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.

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=E2=80=99t = 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.

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. 

Christian


Another option is checking how we tell the story. The = question may be solved if we say that =E2=80=9Cmentors exist to help in = the development of new projects=E2=80=9D, implying that already finished = projects has now association with current mentors. Too = simplistic?

Best= regards,

Lisandro

Em = 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model = with the team!  This looks great from what we discussed.  =46rom= 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 <granville@inf.ufrgs.br> 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_30686484-8798-4C69-80CA-DFEEA8FBC70D-- From nobody Sat Feb 14 02:22:25 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443261A1BD9 for ; Sat, 14 Feb 2015 02:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs7qrA9C0alt for ; Sat, 14 Feb 2015 02:22:19 -0800 (PST) Received: from delivery3.ufrgs.br (delivery3.ufrgs.br [143.54.2.213]) by ietfa.amsl.com (Postfix) with ESMTP id 963271A1BD4 for ; Sat, 14 Feb 2015 02:22:18 -0800 (PST) Received: from delivery3.ufrgs.br (localhost [127.0.0.1]) by delivery3.ufrgs.br (Postfix) with ESMTP id 4CC8330036A; Sat, 14 Feb 2015 08:22:15 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery3.ufrgs.br (Postfix) with ESMTP id E2FA8143; Sat, 14 Feb 2015 08:22:14 -0200 (BRST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9BEAF64-3666-4B5A-AE49-BE12426E394F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: Date: Sat, 14 Feb 2015 08:22:12 -0200 Message-Id: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> To: "codematch-develop@ietf.org" X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: Kristin Burgh , Wanderson Paim de Jesus Subject: [Codematch-develop] New version of CodeMatch prototype pages X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 10:22:22 -0000 --Apple-Mail=_C9BEAF64-3666-4B5A-AE49-BE12426E394F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all I=E2=80=99m sending this message to let you know about a new version of = the prototype pages for CodeMatch. The new version is available at: http://codematch.inf.ufrgs.br =20 Prototype pages complement the mockups that we have been discussing by = incorporating more visual elements that mockups don=E2=80=99t capture. = Mockups is still our primary material for discussions, but prototype = pages help us to check the visual aspects. That also complements = Kristin=E2=80=99s work! Don=E2=80=99t be too worry if these prototype pages are not 100% = synchronized with the mockups (it=E2=80=99s easy to change a mockup than = a page), that=E2=80=99s natural. Still, you can provide your feedback = for the visual aspects already. These prototype pages have been voluntarily created by Wanderson Paim de = Jesus (cc=E2=80=99ed in this message). I wanted to explicitly = acknowledge that and thank Wanderson for his help. Best regards, Lisandro --Apple-Mail=_C9BEAF64-3666-4B5A-AE49-BE12426E394F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all

I=E2=80=99m sending this = message to let you know about a new version of the prototype pages for = CodeMatch. The new version is available at:

http://codematch.inf.ufrgs.br 

Prototype pages = complement the mockups that we have been discussing by incorporating = more visual elements that mockups don=E2=80=99t capture. Mockups is = still our primary material for discussions, but prototype pages help us = to check the visual aspects. That also complements Kristin=E2=80=99s = work!

Don=E2=80=99= t be too worry if these prototype pages are not 100% synchronized with = the mockups (it=E2=80=99s easy to change a mockup than a page), that=E2=80= =99s natural. Still, you can provide your feedback for the visual = aspects already.

These prototype pages have been voluntarily created by = Wanderson Paim de Jesus (cc=E2=80=99ed in this message). I wanted to = explicitly acknowledge that and thank Wanderson for his help.

Best regards,

Lisandro

= --Apple-Mail=_C9BEAF64-3666-4B5A-AE49-BE12426E394F-- From nobody Sat Feb 14 08:53:08 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857B41A6F3A for ; Sat, 14 Feb 2015 08:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQykUjIHxQW9 for ; Sat, 14 Feb 2015 08:53:02 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499111A6F13 for ; Sat, 14 Feb 2015 08:53:02 -0800 (PST) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1EGqwVW023279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Feb 2015 11:52:58 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t1EGqwVW023279 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423932779; bh=3ir4qc87iyoM+tz0q/5nn2aIY+8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=qq8E3TCgh1XmkkwFfhm2ar6fK2NRG91AGXMCP5DcPwbBm0V2u9yk+2pxZ0IyMWT7F gijJkSuX9XWGRFb4Xr2zwPH28796vDAU+eN1uuLRBBzgmfU+Ko9KFZG39Mp0MEvU9S VsCy+2CKgsFm7SrkGULr3LBjlc87n9YAj+dCNcJU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t1EGqwVW023279 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Sat, 14 Feb 2015 11:52:30 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1EGqcBo027175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Feb 2015 11:52:38 -0500 Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub06.corp.emc.com (128.222.70.203) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 14 Feb 2015 11:52:38 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.216]) by MXHUB207.corp.emc.com ([10.253.68.33]) with mapi id 14.03.0224.002; Sat, 14 Feb 2015 11:52:37 -0500 From: "Moriarty, Kathleen" To: "Christian O'Flaherty" Thread-Topic: [Codematch-develop] CodeMatch data model v3 Thread-Index: AQHQQq+SGJ7q08W7q0eviA8qezQlOZzr6h8AgAJxvQCAAMJUAIABSbe1 Date: Sat, 14 Feb 2015 16:52:37 +0000 Message-ID: <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_623A4EC42BE04C33AE8E78F94D0DB6DBemccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Lisandro Zambenedetti Granville , "codematch-develop@ietf.org" , Kathleen Moriarty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 16:53:06 -0000 --_000_623A4EC42BE04C33AE8E78F94D0DB6DBemccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: Hi Kathleen, To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=92s because (additional?) code is required. To hel= p in the development of new code throughout new projects, mentors seem to b= e mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the t= erms 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 sim= pler should help reduce coding efforts. However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=92t need a mentor, of course, but the new projects do. But= because mentors are associated with CodeRequest (and not with project), on= ce 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, et= c. 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 solve= d if we say that =93mentors exist to help in the development of new project= s=94, implying that already finished projects has now association with curr= ent mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty > 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 receiv= ed from the IESG, the point was made that you may not always have a shepher= d. If we want this to also advertise existing implementations (open source= or proprietary) of existing RFCs, there should be flexibility to demonstra= te 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 cr= eates 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 > wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --_000_623A4EC42BE04C33AE8E78F94D0DB6DBemccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE develop= ments. If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new projects, m= entors seem to be mandatory.

I agree with Lisandro's reasoning. If there's a code-match, it's becau= se 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 requ= est, thereby no need to provide a shepherd. They could be just "code o= pportunity" and there's no commitment from anyone for those code-match= es.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already fin= ished, 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= =92t 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 m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 associ= ated with CodeRequest. Previously, mentors were associated with individual = projects (at that point we were referring projects to as CodeMatches, befor= e 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 CodeReq= uests that exist only to advertise already finished projects, but we need t= o live with the idea that once additional code is needed for those CodeRequ= ests, 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 projec= ts, indicating that mentors are optional. However, we may be imposing an ad= ministrative 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 quest= ion may be solved if we say that =93mentors exist to help in the developmen= t of new projects=94, implying that already finished projects has now assoc= iation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data mode= l 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.&nb= sp; 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 pr= ojects so they might only see ones that have a mentor and I'm sure they wou= ld 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for C= odeMatch has been defined. Please, find below the new version of such a dat= a 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https:/= /www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
h= ttps://www.ietf.org/mailman/listinfo/codematch-develop
--_000_623A4EC42BE04C33AE8E78F94D0DB6DBemccom_-- From nobody Tue Feb 17 04:05:29 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365C01A8033 for ; Tue, 17 Feb 2015 04:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T888NyOwPP4K for ; Tue, 17 Feb 2015 04:05:21 -0800 (PST) Received: from delivery3.ufrgs.br (delivery3.ufrgs.br [143.54.2.213]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC5C1A1AB6 for ; Tue, 17 Feb 2015 04:05:21 -0800 (PST) Received: from delivery3.ufrgs.br (localhost [127.0.0.1]) by delivery3.ufrgs.br (Postfix) with ESMTP id 0AFD5300372; Tue, 17 Feb 2015 10:05:17 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery3.ufrgs.br (Postfix) with ESMTP id 7BE37142; Tue, 17 Feb 2015 10:05:17 -0200 (BRST) Content-Type: multipart/alternative; boundary="Apple-Mail=_51CFC315-65B0-437F-81A0-846A768A63E2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> Date: Tue, 17 Feb 2015 10:05:05 -0200 Message-Id: <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <, > <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: Kathleen Moriarty , "codematch-develop@ietf.org" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 12:05:27 -0000 --Apple-Mail=_51CFC315-65B0-437F-81A0-846A768A63E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Kathleen I=92m 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 =93fixing=94 this issue by saying that =93a Mentor is the person = responsible for helping in the development of active projects=94, = implying that mentors have no role in already finished projects? In that = way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen = escreveu: >=20 > Hi, >=20 > Sent from my iPhone >=20 > On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" = > wrote: >=20 >> Hi Kathleen,=20 >>=20 >>> To me, a CodeRequest is an explicit call for FUTURE developments. If = someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new = projects, mentors seem to be mandatory. >>=20 >> 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. >=20 > Good point. >>=20 >> 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. >=20 > 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. >=20 > =20 >>=20 >>> 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=92t 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. >>>=20 >>> 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: >=20 > Yes, you are correct and I think my updated suggestion fixes this, but = let me know if I missed anything. >>>=20 >>> 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. >>>=20 >>> 2) Rollback the model back to associate mentors with projects, = indicating that mentors are optional. However, we may be imposing an = administrative burden here. >>=20 >> 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.=20 > Or just to have two options for CodeMatches - with or without a = CodeRequest. >=20 > Thanks! > Kathleen=20 >=20 >>=20 >> Christian >>=20 >>>=20 >>> Another option is checking how we tell the story. The question may = be solved if we say that =93mentors exist to help in the development of = new projects=94, implying that already finished projects has now = association with current mentors. Too simplistic? >>>=20 >>> Best regards, >>>=20 >>> Lisandro >>>=20 >>>> Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty = > escreveu: >>>>=20 >>>> Lisandro, >>>>=20 >>>> Thank you for your time and effort developing the data model with = the team! This looks great from what we discussed. =46rom 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. >>>>=20 >>>> In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >>>>=20 >>>> 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.). >>>>=20 >>>> Any other comments? >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville = > wrote: >>>> Dear all >>>>=20 >>>> 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. >>>>=20 >>>> Best regards, >>>>=20 >>>> Lisandro >>>>=20 >>>> >>>>=20 >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>=20 >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop = > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --Apple-Mail=_51CFC315-65B0-437F-81A0-846A768A63E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Kathleen

I=92m 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 =93fixing=94 this issue by saying that =93a Mentor is = the person responsible for helping in the development of active = projects=94, implying that mentors have no role in already finished = projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> = wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=92s 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=92t 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 =93mentors exist to help in the = development of new projects=94, implying that already finished projects = has now association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data = model with the team!  This looks great from what we = discussed.  =46rom 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 <granville@inf.ufrgs.br> = 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_51CFC315-65B0-437F-81A0-846A768A63E2-- From nobody Tue Feb 17 04:31:45 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD21A8874 for ; Tue, 17 Feb 2015 04:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjmuwYpw1IfV for ; Tue, 17 Feb 2015 04:31:41 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC621A1ABE for ; Tue, 17 Feb 2015 04:31:40 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1HCVa3H031947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2015 07:31:38 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t1HCVa3H031947 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1424176298; bh=B6RSOXBUBalcQZOv4shlIyqQdlg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=P3F5kO5aSM7WXawf9j0t9XfQ+f3QxaOftJHLRNveaJtdjuc9j0ezP6afD9McnlTkU EEPG/x8I3icY1sJFW/hnfywUp8sfdotPcy3SgHsNaw/zRsG0ef4JC1RZdQhGtNDhU0 WQN9klSR4sMu0HdZWrEzVm1B9Flb4iE1LQPcWUEk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t1HCVa3H031947 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd05.lss.emc.com (RSA Interceptor); Tue, 17 Feb 2015 07:31:11 -0500 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1HCVErd015681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 07:31:15 -0500 Received: from MXHUB208.corp.emc.com (10.253.68.34) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 17 Feb 2015 07:31:14 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.139]) by MXHUB208.corp.emc.com ([10.253.68.34]) with mapi id 14.03.0224.002; Tue, 17 Feb 2015 07:31:14 -0500 From: "Moriarty, Kathleen" To: Lisandro Zambenedetti Granville Thread-Topic: [Codematch-develop] CodeMatch data model v3 Thread-Index: AQHQQq+SGJ7q08W7q0eviA8qezQlOZzr6h8AgAJxvQCAAMJUAIABSbe1gAS6eYD//7N9JA== Date: Tue, 17 Feb 2015 12:31:13 +0000 Message-ID: <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <,> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com>, <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br> In-Reply-To: <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_76D13C7930124912AFDFB791EC321075emccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Kathleen Moriarty , "codematch-develop@ietf.org" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 12:31:44 -0000 --_000_76D13C7930124912AFDFB791EC321075emccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Lisandro, That accomplishes the same goals and sounds good to me. What does the upda= ted data model look like? I have a planning call with the IESG at the same time as our call tomorrow,= so I'll have to miss it. Should we find another time that works this week= ? Thank you, Kathleen Sent from my iPhone On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" > wrote: Hello Kathleen I=92m 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 possibl= e to have another relationship between Project and Specification named Code= Match too. But let me ask you if you agree with the suggestion of =93fixing= =94 this issue by saying that =93a Mentor is the person responsible for hel= ping in the development of active projects=94, implying that mentors have n= o role in already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen > escreveu: Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: Hi Kathleen, To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=92s because (additional?) code is required. To hel= p in the development of new code throughout new projects, mentors seem to b= e mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the t= erms 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 sim= pler should help reduce coding efforts. However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=92t need a mentor, of course, but the new projects do. But= because mentors are associated with CodeRequest (and not with project), on= ce 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, et= c. 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 solve= d if we say that =93mentors exist to help in the development of new project= s=94, implying that already finished projects has now association with curr= ent mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty > 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 receiv= ed from the IESG, the point was made that you may not always have a shepher= d. If we want this to also advertise existing implementations (open source= or proprietary) of existing RFCs, there should be flexibility to demonstra= te 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 cr= eates 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 > wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --_000_76D13C7930124912AFDFB791EC321075emccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Lisandro,

That accomplishes the same goals and sounds good to me.  What doe= s the updated data model look like?

I have a planning call with the IESG at the same time as our call tomo= rrow, so I'll have to miss it.  Should we find another time that works= this week?

Thank you,
Kathleen 

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf.ufrgs.br> = wrote:

Hello Kathleen

I=92m not an expert on data models, so I may be wrong. Toda= y, CodeMatch is a relationship between Project and CodeRequest. I believe i= t is not possible to have another relationship between Project and Specific= ation named CodeMatch too. But let me ask you if you agree with the suggestion of =93fixing=94 this issue by say= ing that =93a Mentor is the person responsible for helping in the developme= nt of active projects=94, implying that mentors have no role in already fin= ished projects? In that way, we don=92t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com<= /a>> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:=

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE develop= ments. If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new projects, m= entors 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 w= ill get the appropriate "coding" help if the student has some sup= port 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 &= quot;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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already fin= ished, 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= =92t 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 m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 associ= ated with CodeRequest. Previously, mentors were associated with individual = projects (at that point we were referring projects to as CodeMatches, befor= e 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 CodeReq= uests that exist only to advertise already finished projects, but we need t= o live with the idea that once additional code is needed for those CodeRequ= ests, 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 projec= ts, indicating that mentors are optional. However, we may be imposing an ad= ministrative burden here.

A third option could be to have active "code-requests&= quot; with mentors and "code-opportunities" (or a better name) fo= r 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 quest= ion may be solved if we say that =93mentors exist to help in the developmen= t of new projects=94, implying that already finished projects has now assoc= iation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data mode= l 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.&nb= sp; 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 pr= ojects so they might only see ones that have a mentor and I'm sure they wou= ld 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for C= odeMatch has been defined. Please, find below the new version of such a dat= a 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

__________________________________________= _____
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develo= p
_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https:/= /www.ietf.org/mailman/listinfo/codematch-develop

--_000_76D13C7930124912AFDFB791EC321075emccom_-- From nobody Tue Feb 17 04:54:39 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48E1A890D for ; Tue, 17 Feb 2015 04:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whk4wJlkNbyo for ; Tue, 17 Feb 2015 04:54:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0664.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F371A891C for ; Tue, 17 Feb 2015 04:54:32 -0800 (PST) Received: from BLUPR0601MB770.namprd06.prod.outlook.com (10.141.254.139) by BLUPR0601MB769.namprd06.prod.outlook.com (10.141.254.13) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 12:54:15 +0000 Received: from BLUPR0601MB770.namprd06.prod.outlook.com ([10.141.254.139]) by BLUPR0601MB770.namprd06.prod.outlook.com ([10.141.254.139]) with mapi id 15.01.0087.013; Tue, 17 Feb 2015 12:54:15 +0000 From: Christian O'Flaherty To: "Moriarty, Kathleen" Thread-Topic: [Codematch-develop] CodeMatch data model v3 Thread-Index: AQHQQq+LUos6A+w7jUitmXh4CQ9EpZzrlk0AgAJxvQCAAG6DAIAB8VmAgARmqYCAAAdNgIAABnCh Date: Tue, 17 Feb 2015 12:54:15 +0000 Message-ID: <31941B02-357F-46C2-B905-20EC31A2E175@isoc.org> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <,> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com>, <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br>, <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> In-Reply-To: <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.61.23.44] authentication-results: isoc.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR0601MB769; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR0601MB769; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(479174004)(377454003)(51744003)(24454002)(41574002)(15975445007)(50986999)(92566002)(36756003)(122556002)(2656002)(16236675004)(40100003)(77156002)(62966003)(66066001)(46102003)(2900100001)(102836002)(77096005)(76176999)(2950100001)(93886004)(54356999)(87936001)(19580395003)(82746002)(19580405001)(110136001)(19617315012)(99286002)(33656002)(106116001)(86362001)(83716003)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0601MB769; H:BLUPR0601MB770.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_31941B02357F46C2B90520EC31A2E175isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2015 12:54:15.3178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB769 Archived-At: Cc: Lisandro Zambenedetti Granville , "codematch-develop@ietf.org" , Kathleen Moriarty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 12:54:37 -0000 --_000_31941B02357F46C2B90520EC31A2E175isocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable That accomplishes the same goals and sounds good to me. +1 What does the updated data model look like? I have a planning call with the IESG at the same time as our call tomorrow,= so I'll have to miss it. Should we find another time that works this week= ? Or We can skip this week's call. We're making progress by email. Christian Thank you, Kathleen Sent from my iPhone On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" > wrote: Hello Kathleen I=92m 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 possibl= e to have another relationship between Project and Specification named Code= Match too. But let me ask you if you agree with the suggestion of =93fixing= =94 this issue by saying that =93a Mentor is the person responsible for hel= ping in the development of active projects=94, implying that mentors have n= o role in already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen > escreveu: Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: Hi Kathleen, To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=92s because (additional?) code is required. To hel= p in the development of new code throughout new projects, mentors seem to b= e mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the t= erms 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 sim= pler should help reduce coding efforts. However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=92t need a mentor, of course, but the new projects do. But= because mentors are associated with CodeRequest (and not with project), on= ce 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, et= c. 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 solve= d if we say that =93mentors exist to help in the development of new project= s=94, implying that already finished projects has now association with curr= ent mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty > 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 receiv= ed from the IESG, the point was made that you may not always have a shepher= d. If we want this to also advertise existing implementations (open source= or proprietary) of existing RFCs, there should be flexibility to demonstra= te 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 cr= eates 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 > wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --_000_31941B02357F46C2B90520EC31A2E175isocorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


That accomplishes the same goals and sounds good to me.  

+1

What does the updated data model look like?

I have a planning call with the IESG at the same time as our call tomo= rrow, so I'll have to miss it.  Should we find another time that works= this week?

Or We can sk= ip this week's call. We're making progress by email. 

Christian


Thank you,
Kathleen 

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf.ufrgs.br> = wrote:

Hello Kathleen

I=92m not an expert on data models, so I may be wrong. Toda= y, CodeMatch is a relationship between Project and CodeRequest. I believe i= t is not possible to have another relationship between Project and Specific= ation named CodeMatch too. But let me ask you if you agree with the suggestion of =93fixing=94 this issue by say= ing that =93a Mentor is the person responsible for helping in the developme= nt of active projects=94, implying that mentors have no role in already fin= ished projects? In that way, we don=92t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com<= /a>> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:=

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE develop= ments. If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new projects, m= entors 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 w= ill get the appropriate "coding" help if the student has some sup= port 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 &= quot;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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already fin= ished, 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= =92t 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 m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 associ= ated with CodeRequest. Previously, mentors were associated with individual = projects (at that point we were referring projects to as CodeMatches, befor= e 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 CodeReq= uests that exist only to advertise already finished projects, but we need t= o live with the idea that once additional code is needed for those CodeRequ= ests, 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 projec= ts, indicating that mentors are optional. However, we may be imposing an ad= ministrative burden here.

A third option could be to have active "code-requests&= quot; with mentors and "code-opportunities" (or a better name) fo= r 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 quest= ion may be solved if we say that =93mentors exist to help in the developmen= t of new projects=94, implying that already finished projects has now assoc= iation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data mode= l 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.&nb= sp; 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 pr= ojects so they might only see ones that have a mentor and I'm sure they wou= ld 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for C= odeMatch has been defined. Please, find below the new version of such a dat= a 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

__________________________________________= _____
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develo= p
_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https:/= /www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
h= ttps://www.ietf.org/mailman/listinfo/codematch-develop
--_000_31941B02357F46C2B90520EC31A2E175isocorg_-- From nobody Tue Feb 17 07:17:21 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529D01A89C5 for ; Tue, 17 Feb 2015 07:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMQ1_0pK2l67 for ; Tue, 17 Feb 2015 07:17:14 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935751A89B4 for ; Tue, 17 Feb 2015 07:17:14 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1HFHARB009654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2015 10:17:11 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t1HFHARB009654 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1424186232; bh=ghNMV36feeayAnyuVSqTN/0GTmI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=oPqGG1yPtk0YBCxCcxXZfKihq2esRfysWYfknkaCjzxLET8YSmmgQN1fGPNLfopgo TxOLL5o95SUzRfNi5IoZGhAJTjIFF+Tj116FqkCbK55F7n8Oi21+tfPQfiPG/AERlF ufE0SAgeq55JF8k4z0tDzKOd00VYDj0LV4hkbZpQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t1HFHARB009654 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 17 Feb 2015 10:16:48 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1HFGwfY015088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 10:16:58 -0500 Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub07.corp.emc.com (128.222.70.204) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 17 Feb 2015 10:16:57 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.139]) by MXHUB207.corp.emc.com ([10.253.68.33]) with mapi id 14.03.0224.002; Tue, 17 Feb 2015 10:16:57 -0500 From: "Moriarty, Kathleen" To: "Christian O'Flaherty" Thread-Topic: [Codematch-develop] CodeMatch data model v3 Thread-Index: AQHQQq+SGJ7q08W7q0eviA8qezQlOZzr6h8AgAJxvQCAAMJUAIABSbe1gAS6eYD//7N9JIAAWkCA///UDZE= Date: Tue, 17 Feb 2015 15:16:56 +0000 Message-ID: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <,> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com>, <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br>, <76D13C79-3012-4912-AFDF-B791EC321075@emc.com>, <31941B02-357F-46C2-B905-20EC31A2E175@isoc.org> In-Reply-To: <31941B02-357F-46C2-B905-20EC31A2E175@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D0D643FF92134797A6E9F57138F9D525emccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Lisandro Zambenedetti Granville , "codematch-develop@ietf.org" , Kathleen Moriarty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:17:19 -0000 --_000_D0D643FF92134797A6E9F57138F9D525emccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sent from my iPhone On Feb 17, 2015, at 7:54 AM, "Christian O'Flaherty" > wrote: That accomplishes the same goals and sounds good to me. +1 What does the updated data model look like? I have a planning call with the IESG at the same time as our call tomorrow,= so I'll have to miss it. Should we find another time that works this week= ? Or We can skip this week's call. We're making progress by email. That's fine with me. This week we need to work on Kristin's results to see when we start getting= volunteers to do the online card sort, data model reviews, and start prepp= ing for Dallas. 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 Christian Thank you, Kathleen Sent from my iPhone On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" > wrote: Hello Kathleen I=92m 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 possibl= e to have another relationship between Project and Specification named Code= Match too. But let me ask you if you agree with the suggestion of =93fixing= =94 this issue by saying that =93a Mentor is the person responsible for hel= ping in the development of active projects=94, implying that mentors have n= o role in already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen > escreveu: Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: Hi Kathleen, To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=92s because (additional?) code is required. To hel= p in the development of new code throughout new projects, mentors seem to b= e mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the t= erms 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 sim= pler should help reduce coding efforts. However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=92t need a mentor, of course, but the new projects do. But= because mentors are associated with CodeRequest (and not with project), on= ce 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, et= c. 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 solve= d if we say that =93mentors exist to help in the development of new project= s=94, implying that already finished projects has now association with curr= ent mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty > 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 receiv= ed from the IESG, the point was made that you may not always have a shepher= d. If we want this to also advertise existing implementations (open source= or proprietary) of existing RFCs, there should be flexibility to demonstra= te 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 cr= eates 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 > wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --_000_D0D643FF92134797A6E9F57138F9D525emccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Sent from my iPhone

On Feb 17, 2015, at 7:54 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:



That accomplishes the same goals and sounds good to me.  

+1

What does the updated data model look like?

I have a planning call with the IESG at the same time as our call tomo= rrow, so I'll have to miss it.  Should we find another time that works= this week?

Or We can sk= ip this week's call. We're making progress by email. 

That's fine with me.  

This week we need to work on Kristin's results to see when we start ge= tting volunteers to do the online card sort, data model reviews, and start = prepping for Dallas.

I have a couple more volunteers for coding as well lined up.  The= re 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 

Christian


Thank you,
Kathleen 

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf.ufrgs.br> = wrote:

Hello Kathleen

I=92m not an expert on data models, so I may be wrong. Toda= y, CodeMatch is a relationship between Project and CodeRequest. I believe i= t is not possible to have another relationship between Project and Specific= ation named CodeMatch too. But let me ask you if you agree with the suggestion of =93fixing=94 this issue by say= ing that =93a Mentor is the person responsible for helping in the developme= nt of active projects=94, implying that mentors have no role in already fin= ished projects? In that way, we don=92t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com<= /a>> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:=

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE develop= ments. If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new projects, m= entors 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 w= ill get the appropriate "coding" help if the student has some sup= port 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 &= quot;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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already fin= ished, 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= =92t 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 m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 associ= ated with CodeRequest. Previously, mentors were associated with individual = projects (at that point we were referring projects to as CodeMatches, befor= e 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 CodeReq= uests that exist only to advertise already finished projects, but we need t= o live with the idea that once additional code is needed for those CodeRequ= ests, 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 projec= ts, indicating that mentors are optional. However, we may be imposing an ad= ministrative burden here.

A third option could be to have active "code-requests&= quot; with mentors and "code-opportunities" (or a better name) fo= r 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 quest= ion may be solved if we say that =93mentors exist to help in the developmen= t of new projects=94, implying that already finished projects has now assoc= iation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data mode= l 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.&nb= sp; 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 pr= ojects so they might only see ones that have a mentor and I'm sure they wou= ld 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for C= odeMatch has been defined. Please, find below the new version of such a dat= a 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

__________________________________________= _____
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develo= p
_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https:/= /www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
h= ttps://www.ietf.org/mailman/listinfo/codematch-develop
--_000_D0D643FF92134797A6E9F57138F9D525emccom_-- From nobody Tue Feb 17 09:19:23 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB561A890B for ; Tue, 17 Feb 2015 09:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0R3FyeZROMn for ; Tue, 17 Feb 2015 09:19:17 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0061.outbound.protection.outlook.com [65.55.169.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3417C1A8ADC for ; Tue, 17 Feb 2015 09:19:17 -0800 (PST) Received: from BLUPR0601MB770.namprd06.prod.outlook.com (10.141.254.139) by BLUPR0601MB769.namprd06.prod.outlook.com (10.141.254.13) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 17:19:15 +0000 Received: from BLUPR0601MB770.namprd06.prod.outlook.com ([10.141.254.139]) by BLUPR0601MB770.namprd06.prod.outlook.com ([10.141.254.139]) with mapi id 15.01.0087.013; Tue, 17 Feb 2015 17:19:15 +0000 From: Christian O'Flaherty To: "Moriarty, Kathleen" Thread-Topic: [Codematch-develop] CodeMatch data model v3 Thread-Index: AQHQQq+LUos6A+w7jUitmXh4CQ9EpZzrlk0AgAJxvQCAAG6DAIAB8VmAgARmqYCAAAdNgIAABnChgAAn3QCAACIt+g== Date: Tue, 17 Feb 2015 17:19:15 +0000 Message-ID: <0A995D9A-BBBD-4FC0-BFF7-6503D403E58F@isoc.org> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <,> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com>, <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br>, <76D13C79-3012-4912-AFDF-B791EC321075@emc.com>, <31941B02-357F-46C2-B905-20EC31A2E175@isoc.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.61.97.112] authentication-results: isoc.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR0601MB769; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR0601MB769; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(479174004)(377454003)(51744003)(24454002)(41574002)(15975445007)(50986999)(36756003)(122556002)(2656002)(77096005)(16236675004)(92566002)(77156002)(62966003)(40100003)(46102003)(66066001)(2900100001)(102836002)(2950100001)(76176999)(93886004)(54356999)(87936001)(19580395003)(82746002)(19580405001)(110136001)(19617315012)(99286002)(33656002)(106116001)(86362001)(83716003)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0601MB769; H:BLUPR0601MB770.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_0A995D9ABBBD4FC0BFF76503D403E58Fisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2015 17:19:15.0211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB769 Archived-At: Cc: Lisandro Zambenedetti Granville , "codematch-develop@ietf.org" , Kathleen Moriarty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:19:22 -0000 --_000_0A995D9ABBBD4FC0BFF76503D403E58Fisocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 i= nitial 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" > wrote: Hello Kathleen I=92m 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 possibl= e to have another relationship between Project and Specification named Code= Match too. But let me ask you if you agree with the suggestion of =93fixing= =94 this issue by saying that =93a Mentor is the person responsible for hel= ping in the development of active projects=94, implying that mentors have n= o role in already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen > escreveu: Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: Hi Kathleen, To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=92s because (additional?) code is required. To hel= p in the development of new code throughout new projects, mentors seem to b= e mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the t= erms 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 sim= pler should help reduce coding efforts. However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=92t need a mentor, of course, but the new projects do. But= because mentors are associated with CodeRequest (and not with project), on= ce 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, et= c. 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 solve= d if we say that =93mentors exist to help in the development of new project= s=94, implying that already finished projects has now association with curr= ent mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty > 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 receiv= ed from the IESG, the point was made that you may not always have a shepher= d. If we want this to also advertise existing implementations (open source= or proprietary) of existing RFCs, there should be flexibility to demonstra= te 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 cr= eates 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 > wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --_000_0A995D9ABBBD4FC0BFF76503D403E58Fisocorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


I have a couple more volunteers for coding as well lined up.  The= re 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 i= nitial 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" &l= t;granville@inf.ufrgs.br> = wrote:

Hello Kathleen

I=92m not an expert on data models, so I may be wrong. Toda= y, CodeMatch is a relationship between Project and CodeRequest. I believe i= t is not possible to have another relationship between Project and Specific= ation named CodeMatch too. But let me ask you if you agree with the suggestion of =93fixing=94 this issue by say= ing that =93a Mentor is the person responsible for helping in the developme= nt of active projects=94, implying that mentors have no role in already fin= ished projects? In that way, we don=92t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com<= /a>> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:=

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE develop= ments. If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new projects, m= entors 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 w= ill get the appropriate "coding" help if the student has some sup= port 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 &= quot;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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already fin= ished, 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= =92t 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 m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 associ= ated with CodeRequest. Previously, mentors were associated with individual = projects (at that point we were referring projects to as CodeMatches, befor= e 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 CodeReq= uests that exist only to advertise already finished projects, but we need t= o live with the idea that once additional code is needed for those CodeRequ= ests, 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 projec= ts, indicating that mentors are optional. However, we may be imposing an ad= ministrative burden here.

A third option could be to have active "code-requests&= quot; with mentors and "code-opportunities" (or a better name) fo= r 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 quest= ion may be solved if we say that =93mentors exist to help in the developmen= t of new projects=94, implying that already finished projects has now assoc= iation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data mode= l 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.&nb= sp; 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 pr= ojects so they might only see ones that have a mentor and I'm sure they wou= ld 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for C= odeMatch has been defined. Please, find below the new version of such a dat= a 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

__________________________________________= _____
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develo= p
_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https:/= /www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
h= ttps://www.ietf.org/mailman/listinfo/codematch-develop
--_000_0A995D9ABBBD4FC0BFF76503D403E58Fisocorg_-- From nobody Tue Feb 17 10:01:29 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B161A8F36 for ; Tue, 17 Feb 2015 10:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arEW84OsPwV0 for ; Tue, 17 Feb 2015 10:01:23 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0261A8AF2 for ; Tue, 17 Feb 2015 10:01:22 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1HI1HvY024509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2015 13:01:19 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t1HI1HvY024509 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1424196080; bh=9WBb6fX2QkpHKF+UJv0mMPV9520=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=kvOgqAoD7dde9cRUertURNo5eBdhy8bFcNWtbIHM58FBkCIdijaKFYWwUCS5cZb60 VaOsePXZ6RU69ZozzpsHn4jKmy8vA8EvpTNphRhLxzshQe3DNnZoSKkpdLI2GgXXek Y8bgIDb9PwfflW1gUDbGshLymh9vPpvegnt+p+7c= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t1HI1HvY024509 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 17 Feb 2015 13:00:54 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1HI15CD005215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 13:01:05 -0500 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub01.corp.emc.com (10.254.141.103) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 17 Feb 2015 13:01:05 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.139]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0224.002; Tue, 17 Feb 2015 13:01:04 -0500 From: "Moriarty, Kathleen" To: "Christian O'Flaherty" Thread-Topic: [Codematch-develop] CodeMatch data model v3 Thread-Index: AQHQQq+SGJ7q08W7q0eviA8qezQlOZzr6h8AgAJxvQCAAMJUAIABSbe1gAS6eYD//7N9JIAAWkCA///UDZGAAHX9gP//t96F Date: Tue, 17 Feb 2015 18:01:04 +0000 Message-ID: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <,> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com>, <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br>, <76D13C79-3012-4912-AFDF-B791EC321075@emc.com>, <31941B02-357F-46C2-B905-20EC31A2E175@isoc.org>, , <0A995D9A-BBBD-4FC0-BFF7-6503D403E58F@isoc.org> In-Reply-To: <0A995D9A-BBBD-4FC0-BFF7-6503D403E58F@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C4C836C1ACB141B2A796E70AD01CE457emccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Lisandro Zambenedetti Granville , "codematch-develop@ietf.org" , Kathleen Moriarty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:01:28 -0000 --_000_C4C836C1ACB141B2A796E70AD01CE457emccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sent from my iPhone On Feb 17, 2015, at 12:19 PM, "Christian O'Flaherty" > wrote: 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 i= nitial volunteers for coding. That's great, thank you Christian! Christian Thank you, Kathleen Christian Thank you, Kathleen Sent from my iPhone On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" > wrote: Hello Kathleen I=92m 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 possibl= e to have another relationship between Project and Specification named Code= Match too. But let me ask you if you agree with the suggestion of =93fixing= =94 this issue by saying that =93a Mentor is the person responsible for hel= ping in the development of active projects=94, implying that mentors have n= o role in already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen > escreveu: Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: Hi Kathleen, To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=92s because (additional?) code is required. To hel= p in the development of new code throughout new projects, mentors seem to b= e mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the t= erms 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 sim= pler should help reduce coding efforts. However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=92t need a mentor, of course, but the new projects do. But= because mentors are associated with CodeRequest (and not with project), on= ce 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, et= c. 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 solve= d if we say that =93mentors exist to help in the development of new project= s=94, implying that already finished projects has now association with curr= ent mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty > 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 receiv= ed from the IESG, the point was made that you may not always have a shepher= d. If we want this to also advertise existing implementations (open source= or proprietary) of existing RFCs, there should be flexibility to demonstra= te 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 cr= eates 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 > wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --_000_C4C836C1ACB141B2A796E70AD01CE457emccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Sent from my iPhone

On Feb 17, 2015, at 12:19 PM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:



I have a couple more volunteers for coding as well lined up.  The= re 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 i= nitial volunteers for coding. 

That's great, thank you Christian!

Christian 


Thank you,
Kathleen 

Christian


Thank you,
Kathleen 

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf.ufrgs.br> = wrote:

Hello Kathleen

I=92m not an expert on data models, so I may be wrong. Toda= y, CodeMatch is a relationship between Project and CodeRequest. I believe i= t is not possible to have another relationship between Project and Specific= ation named CodeMatch too. But let me ask you if you agree with the suggestion of =93fixing=94 this issue by say= ing that =93a Mentor is the person responsible for helping in the developme= nt of active projects=94, implying that mentors have no role in already fin= ished projects? In that way, we don=92t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com<= /a>> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:=

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE develop= ments. If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new projects, m= entors 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 w= ill get the appropriate "coding" help if the student has some sup= port 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 &= quot;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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already fin= ished, 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= =92t 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 m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 associ= ated with CodeRequest. Previously, mentors were associated with individual = projects (at that point we were referring projects to as CodeMatches, befor= e 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 CodeReq= uests that exist only to advertise already finished projects, but we need t= o live with the idea that once additional code is needed for those CodeRequ= ests, 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 projec= ts, indicating that mentors are optional. However, we may be imposing an ad= ministrative burden here.

A third option could be to have active "code-requests&= quot; with mentors and "code-opportunities" (or a better name) fo= r 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 quest= ion may be solved if we say that =93mentors exist to help in the developmen= t of new projects=94, implying that already finished projects has now assoc= iation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data mode= l 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.&nb= sp; 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 pr= ojects so they might only see ones that have a mentor and I'm sure they wou= ld 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for C= odeMatch has been defined. Please, find below the new version of such a dat= a 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

__________________________________________= _____
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develo= p
_______________________________________________
Codematch-develop mailing list
Codematch-develop@= ietf.org
https:/= /www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
h= ttps://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
h= ttps://www.ietf.org/mailman/listinfo/codematch-develop
--_000_C4C836C1ACB141B2A796E70AD01CE457emccom_-- From nobody Fri Feb 20 03:18:32 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B8D1A6EDA for ; Fri, 20 Feb 2015 03:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw94nw_RV-sB for ; Fri, 20 Feb 2015 03:18:26 -0800 (PST) Received: from delivery2.ufrgs.br (delivery2.ufrgs.br [143.54.2.212]) by ietfa.amsl.com (Postfix) with ESMTP id 13BB31A6EF0 for ; Fri, 20 Feb 2015 03:18:25 -0800 (PST) Received: from delivery2.ufrgs.br (localhost [127.0.0.1]) by delivery2.ufrgs.br (Postfix) with ESMTP id B466320A3C6; Fri, 20 Feb 2015 09:18:20 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery2.ufrgs.br (Postfix) with ESMTP id 4B46230010F; Fri, 20 Feb 2015 09:18:20 -0200 (BRST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C37848DF-D8DF-4226-8A78-B6F0C2322D55" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> Date: Fri, 20 Feb 2015 09:18:16 -0200 Message-Id: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <, > <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <, <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br> <>> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: Kathleen Moriarty , "codematch-develop@ietf.org" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:18:31 -0000 --Apple-Mail=_C37848DF-D8DF-4226-8A78-B6F0C2322D55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Kathleen > That accomplishes the same goals and sounds good to me. What does the = updated data model look like? In this case, the data model remains the same, since the =93solution=94 = resides on the semantics of mentor, i.e., the person responsible for = helping in current and new projects. Do you want me to send the data = model again? Regards, Lisandro ps.: It took me a while to reply given the recent carnaval break in = Brazil > Sent from my iPhone >=20 > On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" = > wrote: >=20 >> Hello Kathleen >>=20 >> I=92m 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 =93fixing=94 this issue by saying that =93a Mentor is = the person responsible for helping in the development of active = projects=94, implying that mentors have no role in already finished = projects? In that way, we don=92t need to change the data model. Not = that we could not change it, but I believe keeping it simple is = important. >>=20 >> Best regards, >>=20 >> Lisandro >>=20 >>> Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen = > escreveu: >>>=20 >>> Hi, >>>=20 >>> Sent from my iPhone >>>=20 >>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" = > wrote: >>>=20 >>>> Hi Kathleen,=20 >>>>=20 >>>>> To me, a CodeRequest is an explicit call for FUTURE developments. = If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new = projects, mentors seem to be mandatory. >>>>=20 >>>> 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. >>>=20 >>> Good point. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> =20 >>>>=20 >>>>> 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=92t 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. >>>>>=20 >>>>> 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: >>>=20 >>> Yes, you are correct and I think my updated suggestion fixes this, = but let me know if I missed anything. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 2) Rollback the model back to associate mentors with projects, = indicating that mentors are optional. However, we may be imposing an = administrative burden here. >>>>=20 >>>> 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.=20 >>> Or just to have two options for CodeMatches - with or without a = CodeRequest. >>>=20 >>> Thanks! >>> Kathleen=20 >>>=20 >>>>=20 >>>> Christian >>>>=20 >>>>>=20 >>>>> Another option is checking how we tell the story. The question may = be solved if we say that =93mentors exist to help in the development of = new projects=94, implying that already finished projects has now = association with current mentors. Too simplistic? >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Lisandro >>>>>=20 >>>>>> Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty = > escreveu: >>>>>>=20 >>>>>> Lisandro, >>>>>>=20 >>>>>> Thank you for your time and effort developing the data model with = the team! This looks great from what we discussed. =46rom 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. >>>>>>=20 >>>>>> In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >>>>>>=20 >>>>>> 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.). >>>>>>=20 >>>>>> Any other comments? >>>>>>=20 >>>>>> Thank you, >>>>>> Kathleen >>>>>>=20 >>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville = > wrote: >>>>>> Dear all >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Lisandro >>>>>>=20 >>>>>> >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Codematch-develop mailing list >>>>>> Codematch-develop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>=20 >>>>> _______________________________________________ >>>>> Codematch-develop mailing list >>>>> Codematch-develop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>=20 >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>=20 --Apple-Mail=_C37848DF-D8DF-4226-8A78-B6F0C2322D55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Kathleen

That accomplishes the same = goals and sounds good to me.  What does the updated data model look = like?

In this case, the = data model remains the same, since the =93solution=94 resides on the = semantics of mentor, i.e., the person responsible for helping in current = and new projects. Do you want me to send the data model = again?

Regards,

Lisandro

ps.: = It took me a while to reply given the recent carnaval break in = Brazil

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br> wrote:

Hello Kathleen

I=92m 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 =93fixing=94 this issue by = saying that =93a Mentor is the person responsible for helping in the = development of active projects=94, implying that mentors have no role in = already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> = wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=92s 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=92t 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 =93mentors exist to help in the = development of new projects=94, implying that already finished projects = has now association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data = model with the team!  This looks great from what we = discussed.  =46rom 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 <granville@inf.ufrgs.br> = 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop


= --Apple-Mail=_C37848DF-D8DF-4226-8A78-B6F0C2322D55-- From nobody Fri Feb 20 03:23:29 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4841A6EE1 for ; Fri, 20 Feb 2015 03:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXaTRchIQi1n for ; Fri, 20 Feb 2015 03:23:24 -0800 (PST) Received: from delivery2.ufrgs.br (delivery2.ufrgs.br [143.54.2.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7515B1A6EF8 for ; Fri, 20 Feb 2015 03:23:23 -0800 (PST) Received: from delivery2.ufrgs.br (localhost [127.0.0.1]) by delivery2.ufrgs.br (Postfix) with ESMTP id 6CA3020A1EC; Fri, 20 Feb 2015 09:23:22 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery2.ufrgs.br (Postfix) with ESMTP id 179CF3006A1; Fri, 20 Feb 2015 09:23:22 -0200 (BRST) Content-Type: multipart/alternative; boundary="Apple-Mail=_649266C1-06D7-44D5-8680-E6E596F30198" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: <0A995D9A-BBBD-4FC0-BFF7-6503D403E58F@isoc.org> Date: Fri, 20 Feb 2015 09:23:20 -0200 Message-Id: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <, > <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <, > <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br> <, <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> <, <31941B02-357F-46C2-B905-20EC31A2E175@isoc.org>, >> <0A995D9A-BBBD-4FC0-BFF7-6503D403E58F@isoc.org> To: Christian O'Flaherty X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: "codematch-develop@ietf.org" , Kathleen Moriarty , "Moriarty, Kathleen" , Wanderson Paim de Jesus Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:23:28 -0000 --Apple-Mail=_649266C1-06D7-44D5-8680-E6E596F30198 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all Wanderson Paim (cc=92ed in this message), who develop the prototype = available at http://codematch.inf.ufrgs.br = is also a volunteer to code the = CodeMatch backend. Best regards, Lisandro > Em 17/02/2015, =E0(s) 15:19, Christian O'Flaherty = escreveu: >=20 >=20 >>=20 >> 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. >=20 > Although I never used datatracker as a coder I would like to be among = the initial volunteers for coding.=20 >=20 > Christian=20 >=20 >>=20 >> Thank you, >> Kathleen=20 >>>=20 >>> Christian >>>=20 >>>>=20 >>>> Thank you, >>>> Kathleen=20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" = > wrote: >>>>=20 >>>>> Hello Kathleen >>>>>=20 >>>>> I=92m 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 =93fixing=94 this issue by saying that =93a Mentor is = the person responsible for helping in the development of active = projects=94, implying that mentors have no role in already finished = projects? In that way, we don=92t need to change the data model. Not = that we could not change it, but I believe keeping it simple is = important. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Lisandro >>>>>=20 >>>>>> Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen = > escreveu: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" = > wrote: >>>>>>=20 >>>>>>> Hi Kathleen,=20 >>>>>>>=20 >>>>>>>> To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=92s because = (additional?) code is required. To help in the development of new code = throughout new projects, mentors seem to be mandatory. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> Good point. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> =20 >>>>>>>=20 >>>>>>>> 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=92t 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. >>>>>>>>=20 >>>>>>>> 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: >>>>>>=20 >>>>>> Yes, you are correct and I think my updated suggestion fixes = this, but let me know if I missed anything. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 2) Rollback the model back to associate mentors with projects, = indicating that mentors are optional. However, we may be imposing an = administrative burden here. >>>>>>>=20 >>>>>>> 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.=20 >>>>>> Or just to have two options for CodeMatches - with or without a = CodeRequest. >>>>>>=20 >>>>>> Thanks! >>>>>> Kathleen=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Christian >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Another option is checking how we tell the story. The question = may be solved if we say that =93mentors exist to help in the development = of new projects=94, implying that already finished projects has now = association with current mentors. Too simplistic? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Lisandro >>>>>>>>=20 >>>>>>>>> Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty = > escreveu: >>>>>>>>>=20 >>>>>>>>> Lisandro, >>>>>>>>>=20 >>>>>>>>> Thank you for your time and effort developing the data model = with the team! This looks great from what we discussed. =46rom = 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. >>>>>>>>>=20 >>>>>>>>> In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >>>>>>>>>=20 >>>>>>>>> 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.). >>>>>>>>>=20 >>>>>>>>> Any other comments? >>>>>>>>>=20 >>>>>>>>> Thank you, >>>>>>>>> Kathleen >>>>>>>>>=20 >>>>>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti = Granville > = wrote: >>>>>>>>> Dear all >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>>=20 >>>>>>>>> Lisandro >>>>>>>>>=20 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Codematch-develop mailing list >>>>>>>>> Codematch-develop@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>> Kathleen >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Codematch-develop mailing list >>>>>>>> Codematch-develop@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Codematch-develop mailing list >>>>>>> Codematch-develop@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>> _______________________________________________ >>>>>> Codematch-develop mailing list >>>>>> Codematch-develop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>=20 >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop = --Apple-Mail=_649266C1-06D7-44D5-8680-E6E596F30198 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear all

Wanderson Paim (cc=92ed in this message), who develop the = prototype available at http://codematch.inf.ufrgs.br is also a volunteer to = code the CodeMatch backend.

Best regards,

Lisandro

Em 17/02/2015, =E0(s) 15:19, = Christian O'Flaherty <oflaherty@isoc.org> 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" <granville@inf.ufrgs.br> wrote:

Hello Kathleen

I=92m 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 =93fixing=94 this issue by = saying that =93a Mentor is the person responsible for helping in the = development of active projects=94, implying that mentors have no role in = already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> = wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=92s 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=92t 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 =93mentors exist to help in the = development of new projects=94, implying that already finished projects = has now association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data = model with the team!  This looks great from what we = discussed.  =46rom 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 <granville@inf.ufrgs.br> = 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_649266C1-06D7-44D5-8680-E6E596F30198-- From nobody Fri Feb 20 07:25:55 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32451A049C for ; Fri, 20 Feb 2015 07:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQT0t5GmMiKn for ; Fri, 20 Feb 2015 07:25:49 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54941A87BF for ; Fri, 20 Feb 2015 07:23:52 -0800 (PST) Received: by lbiz11 with SMTP id z11so6906103lbi.5 for ; Fri, 20 Feb 2015 07:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jCGVjJUtqGj3stmK2GeWkDzx2qK4Ca1EFzUFic3lJLA=; b=jS7TeoQStTwn0ERjUheCkG61zfl35+iE5AQzD8HeBKEixlHM+Jlz5izeKePCBvbRlH XOaogskxaS0Jhrdo/SVJ5RRQQtBgF5zjZ7hxDWP1oH1k5Hr+OfdlAoLV7vlvfyLGKGdt 1JzhlvLXjzdHEjexoZFSvsT/N6oseJqkzlHotdHOMWExZTQw64hivm0L2UoLIeh3tfKZ /utSOsRJ9a1V/ntjGc3yaWm2JzS1ISSFWyrTl2u/WhOLQw9eczuJ3g+gKJVywloBNHv0 FZS5IA1BBforJgf2BHkmIEejSrPfV2KdXrpyKigtJyBkhmbM3Z0UUgLYQPVYfJ5oBaUg 4rxQ== MIME-Version: 1.0 X-Received: by 10.152.5.167 with SMTP id t7mr9380438lat.32.1424445831163; Fri, 20 Feb 2015 07:23:51 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 07:23:51 -0800 (PST) In-Reply-To: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <6A73C6CA-968E-4BB7-BA9A-40D21A470FC2@inf.ufrgs.br> <0A995D9A-BBBD-4FC0-BFF7-6503D403E58F@isoc.org> Date: Fri, 20 Feb 2015 10:23:51 -0500 Message-ID: From: Kathleen Moriarty To: Lisandro Zambenedetti Granville Content-Type: multipart/alternative; boundary=089e01419d86c4b3da050f86a375 Archived-At: Cc: "codematch-develop@ietf.org" , "Moriarty, Kathleen" , Christian O'Flaherty , Wanderson Paim de Jesus Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:25:53 -0000 --089e01419d86c4b3da050f86a375 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville < granville@inf.ufrgs.br> wrote: > Dear all > > Wanderson Paim (cc=E2=80=99ed 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, =C3=A0(s) 15:19, Christian O'Flaherty > 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 th= e > 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" < > granville@inf.ufrgs.br> wrote: > > Hello Kathleen > > I=E2=80=99m not an expert on data models, so I may be wrong. Today, Code= Match 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 > =E2=80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is t= he person responsible for > helping in the development of active projects=E2=80=9D, implying that men= tors have > no role in already finished projects? In that way, we don=E2=80=99t 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, =C3=A0(s) 14:52, Moriarty, Kathleen > escreveu: > > Hi, > > Sent from my iPhone > > On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: > > Hi Kathleen, > > To me, a CodeRequest is an explicit call for FUTURE developments. If > someone is questing code, that=E2=80=99s because (additional?) code is re= quired. 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 eithe= r > be a fulfilled CodeRequest mapping a project to a specification or simply > the connection between a project and specification. This let's us keep t= he > terms and model simple which may be easier for users as they will have le= ss > 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: ther= e > is a CodeRequest for an specific protocol. That CodeRequest already finds > previously finished projects but still requires further code. In that cas= e, > the previous projects don=E2=80=99t 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 wi= th > the idea that once additional code is needed for those CodeRequests, a re= al > 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 RFC= s, > 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 =E2=80=9Cmentors exist to help in the development o= f new > projects=E2=80=9D, implying that already finished projects has now associ= ation with > current mentors. Too simplistic? > > Best regards, > > Lisandro > > Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> 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 (op= en > source or proprietary) of existing RFCs, there should be flexibility to > demonstrate links between a CodeRequest (in this case an RFC) and a proje= ct > without having a mentor. You would still have a coder or the project own= er > that creates the link and it would be possible for others to connect thei= r > 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 < > granville@inf.ufrgs.br> 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. W= e >> tried to incorporate the comments received in the list as well as the >> suggestions mentioned during the last meetings. Terms in this version ar= e >> 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 >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> > > > -- > > Best regards, > Kathleen > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > > --=20 Best regards, Kathleen --089e01419d86c4b3da050f86a375 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville <granville@inf.ufrgs.br> wrote:
Dear all

Wander= son Paim (cc=E2=80=99ed in this message), who develop the prototype availab= le at http://co= dematch.inf.ufrgs.br=C2=A0is also a volunteer to code the CodeMatch bac= kend.

Excellent, it's great= to have you on the team Wanderson!=C2=A0 Thank you for volunteering!
=

Best regards,
Kathleen=C2=A0

Best regards,

Lisandro

Em 17/02/2015, =C3=A0(s) 15:19, Christian O'Fla= herty <oflaherty= @isoc.org> escreveu:



I have a couple more volunteers for coding as well lined up.=C2=A0 The= re 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 i= nitial volunteers for coding.=C2=A0

Christian=C2=A0


Thank you,
Kathleen=C2=A0

Christian<= /div>

Thank you,
Kathleen=C2=A0

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf= .ufrgs.br> wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone
Hi Kathleen,=C2=A0

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s 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 su= pport to do that work.

Good point.

We can have a different instance for those cases were there is no requ= est, thereby no need to provide a shepherd. They could be just "code o= pportunity" and there's no commitment from anyone for those code-m= atches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification.=C2=A0 This let's us k= eep the terms and model simple which may be easier for users as they will have less to understand in terms of our t= erminology.=C2=A0 Also keeping the data model simpler should help reduce co= ding efforts.

=C2=A0

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e 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 =C2=A0RFCs, etc. with no mentor.=C2=A0
Or just to have two options for CodeMatches - with or without a CodeRequest= .

Thanks!
Kathleen=C2=A0


Christian


Another option is checking how we tell the story. The question may be = solved if we say that =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model with the = team!=C2=A0 This looks great from what we discussed.=C2=A0 From additional = feedback received from the IESG, the point was made that you may not always= have a shepherd.=C2=A0 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.=C2= =A0 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop



--

Best regards,
Kathleen
--089e01419d86c4b3da050f86a375-- From nobody Fri Feb 20 07:26:41 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCEF1A8760 for ; Fri, 20 Feb 2015 07:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUKPxqjXcxp8 for ; Fri, 20 Feb 2015 07:26:35 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878EE1A87BD for ; Fri, 20 Feb 2015 07:26:04 -0800 (PST) Received: by labhs14 with SMTP id hs14so6815385lab.1 for ; Fri, 20 Feb 2015 07:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+WQcW3aB6woEpBzce90OrOyzNKQJ6Q145vovxug/2Nc=; b=YwNgc2KJgu8NmFPgza98TWlTdlJ9gY7mAafp1/8gAX6r/eJ6hYpnH46LuzKycQ/Zmk z8ApCOUWwOhocZqz8KqR9VERhMJcbaRWmA4kEIaOVEzl1u9wUmQDDkEWkeFZOzvjaRjG G/OdFsLyRC+tjS/XsYJP2bNVfXnxsBr6cqRW6Mq65Korby8Ch/8OJgkswENm4QllHlHS nvjF8McHdnvHT4nix3tcj6V997MqvJJzAQtUcqm1eYPoiZY1Qi/vXMCxnCbjd3QXOr3L 4QCXCqxCe0N7897495cgp1WFYRjxa24HcT4Py73RzTuzwhENBtW/fdo/SfuX+jUHWha4 MK2A== MIME-Version: 1.0 X-Received: by 10.112.146.66 with SMTP id ta2mr9376045lbb.0.1424445963039; Fri, 20 Feb 2015 07:26:03 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 20 Feb 2015 07:26:02 -0800 (PST) In-Reply-To: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> Date: Fri, 20 Feb 2015 10:26:02 -0500 Message-ID: From: Kathleen Moriarty To: Lisandro Zambenedetti Granville Content-Type: multipart/alternative; boundary=047d7b3a857ca0f8b1050f86ab10 Archived-At: Cc: "codematch-develop@ietf.org" , "Moriarty, Kathleen" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:26:39 -0000 --047d7b3a857ca0f8b1050f86ab10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lisandro. On Fri, Feb 20, 2015 at 6:18 AM, Lisandro Zambenedetti Granville < granville@inf.ufrgs.br> wrote: > Hello Kathleen > > That accomplishes the same goals and sounds good to me. What does the > updated data model look like? > > > In this case, the data model remains the same, since the =E2=80=9Csolutio= n=E2=80=9D > resides on the semantics of mentor, i.e., the person responsible for > helping in current and new projects. Do you want me to send the data mode= l > again? > That sounds good if that is the case as simpler is better. When I look at the data model, it appears that the Project requires a CodeRequest that connects it to the specification, but maybe I'm reading it incorrectly. So if you can explain how we can have these two possibilities in the current data model, that would help me before we go forward. Thank you! > > Regards, > > Lisandro > > ps.: It took me a while to reply given the recent carnaval break in Brazi= l > > Sent from my iPhone > > On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" < > granville@inf.ufrgs.br> wrote: > > Hello Kathleen > > I=E2=80=99m not an expert on data models, so I may be wrong. Today, Code= Match 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 > =E2=80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is t= he person responsible for > helping in the development of active projects=E2=80=9D, implying that men= tors have > no role in already finished projects? In that way, we don=E2=80=99t 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, =C3=A0(s) 14:52, Moriarty, Kathleen > escreveu: > > Hi, > > Sent from my iPhone > > On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: > > Hi Kathleen, > > To me, a CodeRequest is an explicit call for FUTURE developments. If > someone is questing code, that=E2=80=99s because (additional?) code is re= quired. 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 eithe= r > be a fulfilled CodeRequest mapping a project to a specification or simply > the connection between a project and specification. This let's us keep t= he > terms and model simple which may be easier for users as they will have le= ss > 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: ther= e > is a CodeRequest for an specific protocol. That CodeRequest already finds > previously finished projects but still requires further code. In that cas= e, > the previous projects don=E2=80=99t 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 wi= th > the idea that once additional code is needed for those CodeRequests, a re= al > 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 RFC= s, > 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 =E2=80=9Cmentors exist to help in the development o= f new > projects=E2=80=9D, implying that already finished projects has now associ= ation with > current mentors. Too simplistic? > > Best regards, > > Lisandro > > Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> 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 (op= en > source or proprietary) of existing RFCs, there should be flexibility to > demonstrate links between a CodeRequest (in this case an RFC) and a proje= ct > without having a mentor. You would still have a coder or the project own= er > that creates the link and it would be possible for others to connect thei= r > 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 < > granville@inf.ufrgs.br> 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. W= e >> tried to incorporate the comments received in the list as well as the >> suggestions mentioned during the last meetings. Terms in this version ar= e >> 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 >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> > > > -- > > Best regards, > Kathleen > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > > > --=20 Best regards, Kathleen --047d7b3a857ca0f8b1050f86ab10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lisandro.

On Fri, Feb 20, 2015 at 6:18 AM, Lisandro Zambenedetti Granvill= e <granville@inf.ufrgs.br> wrote:
Hello Kathleen

That accomplishes the sa= me goals and sounds good to me.=C2=A0 What does the updated data model look= like?

In this case, the data = model remains the same, since the =E2=80=9Csolution=E2=80=9D resides on the= semantics of mentor, i.e., the person responsible for helping in current a= nd new projects. Do you want me to send the data model again?

That sounds good if that is the = case as simpler is better.=C2=A0 When I look at the data model, it appears = that the Project requires a CodeRequest that connects it to the specificati= on, but maybe I'm reading it incorrectly.=C2=A0 So if you can explain h= ow we can have these two possibilities in the current data model, that woul= d help me before we go forward.

Thank you!
=

Regards,

Lisandro
ps.: It took me a while to reply given the recent carnaval bre= ak in Brazil

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf= .ufrgs.br> wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone
Hi Kathleen,=C2=A0

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s 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 su= pport to do that work.

Good point.

We can have a different instance for those cases were there is no requ= est, thereby no need to provide a shepherd. They could be just "code o= pportunity" and there's no commitment from anyone for those code-m= atches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification.=C2=A0 This let's us k= eep the terms and model simple which may be easier for users as they will have less to understand in terms of our t= erminology.=C2=A0 Also keeping the data model simpler should help reduce co= ding efforts.

=C2=A0

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e 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 =C2=A0RFCs, etc. with no mentor.=C2=A0
Or just to have two options for CodeMatches - with or without a CodeRequest= .

Thanks!
Kathleen=C2=A0


Christian


Another option is checking how we tell the story. The question may be = solved if we say that =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model with the = team!=C2=A0 This looks great from what we discussed.=C2=A0 From additional = feedback received from the IESG, the point was made that you may not always= have a shepherd.=C2=A0 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.=C2= =A0 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen
--047d7b3a857ca0f8b1050f86ab10-- From nobody Sun Feb 22 11:08:21 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61FE1A6EF2 for ; Sun, 22 Feb 2015 11:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.74 X-Spam-Level: X-Spam-Status: No, score=0.74 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U38ydieh2fqL for ; Sun, 22 Feb 2015 11:08:15 -0800 (PST) Received: from delivery3.ufrgs.br (delivery3.ufrgs.br [143.54.2.213]) by ietfa.amsl.com (Postfix) with ESMTP id DE26D1A6EF0 for ; Sun, 22 Feb 2015 11:08:14 -0800 (PST) Received: from delivery3.ufrgs.br (localhost [127.0.0.1]) by delivery3.ufrgs.br (Postfix) with ESMTP id AAB58300512; Sun, 22 Feb 2015 16:08:11 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery3.ufrgs.br (Postfix) with ESMTP id 423A2170; Sun, 22 Feb 2015 16:08:11 -0300 (BRT) Content-Type: multipart/alternative; boundary="Apple-Mail=_60939B60-798E-491B-995E-0A8EA744724F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: Date: Sun, 22 Feb 2015 18:54:10 +0000 Message-Id: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: "codematch-develop@ietf.org" , "Moriarty, Kathleen" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 19:08:19 -0000 --Apple-Mail=_60939B60-798E-491B-995E-0A8EA744724F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Kathleen > In this case, the data model remains the same, since the = =E2=80=9Csolution=E2=80=9D resides on the semantics of mentor, i.e., the = person responsible for helping in current and new projects. Do you want = me to send the data model again? >=20 > That sounds good if that is the case as simpler is better. When I = look at the data model, it appears that the Project requires a = CodeRequest that connects it to the specification, but maybe I'm reading = it incorrectly. So if you can explain how we can have these two = possibilities in the current data model, that would help me before we go = forward. A CodeRequest is a container for projects that both (a) are developing = new code now and (b) have developed code in the past. For (a), mentors = are important; for (b), mentors make not difference. If you have one or = more projects from the past ( as in (b) ) to connect to the same = specification, you=E2=80=99ll need a CodeRequest to link those project = to that specification.=20 You asked how we can have the two possibilities in the current data = model. The data model itself has no specific structures for both = possibilities, but that=E2=80=99s why I mentioned that it resides in the = semantics we assign to mentors, since CodeRequest would be there anyway, = to link either new or old projects to specifications. If thinks are still not clear, I can try to provide examples. Regards, Lisandro >=20 > Thank you! >=20 > Regards, >=20 > Lisandro >=20 > ps.: It took me a while to reply given the recent carnaval break in = Brazil >=20 >> Sent from my iPhone >>=20 >> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" = > wrote: >>=20 >>> Hello Kathleen >>>=20 >>> I=E2=80=99m 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 =E2=80=9Cfixing=E2=80=9D this issue by saying that = =E2=80=9Ca Mentor is the person responsible for helping in the = development of active projects=E2=80=9D, implying that mentors have no = role in already finished projects? In that way, we don=E2=80=99t need to = change the data model. Not that we could not change it, but I believe = keeping it simple is important. >>>=20 >>> Best regards, >>>=20 >>> Lisandro >>>=20 >>>> Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen = > escreveu: >>>>=20 >>>> Hi, >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" = > wrote: >>>>=20 >>>>> Hi Kathleen,=20 >>>>>=20 >>>>>> To me, a CodeRequest is an explicit call for FUTURE developments. = If someone is questing code, that=E2=80=99s because (additional?) code = is required. To help in the development of new code throughout new = projects, mentors seem to be mandatory. >>>>>=20 >>>>> 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. >>>>=20 >>>> Good point. >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> =20 >>>>>=20 >>>>>> 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=E2=80=99t 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. >>>>>>=20 >>>>>> 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: >>>>=20 >>>> Yes, you are correct and I think my updated suggestion fixes this, = but let me know if I missed anything. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 2) Rollback the model back to associate mentors with projects, = indicating that mentors are optional. However, we may be imposing an = administrative burden here. >>>>>=20 >>>>> 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.=20 >>>> Or just to have two options for CodeMatches - with or without a = CodeRequest. >>>>=20 >>>> Thanks! >>>> Kathleen=20 >>>>=20 >>>>>=20 >>>>> Christian >>>>>=20 >>>>>>=20 >>>>>> Another option is checking how we tell the story. The question = may be solved if we say that =E2=80=9Cmentors exist to help in the = development of new projects=E2=80=9D, implying that already finished = projects has now association with current mentors. Too simplistic? >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Lisandro >>>>>>=20 >>>>>>> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty = > escreveu: >>>>>>>=20 >>>>>>> Lisandro, >>>>>>>=20 >>>>>>> Thank you for your time and effort developing the data model = with the team! This looks great from what we discussed. =46rom = 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. >>>>>>>=20 >>>>>>> In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >>>>>>>=20 >>>>>>> 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.). >>>>>>>=20 >>>>>>> Any other comments? >>>>>>>=20 >>>>>>> Thank you, >>>>>>> Kathleen >>>>>>>=20 >>>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville = > wrote: >>>>>>> Dear all >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Lisandro >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Codematch-develop mailing list >>>>>>> Codematch-develop@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Kathleen >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Codematch-develop mailing list >>>>>> Codematch-develop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>=20 >>>>> _______________________________________________ >>>>> Codematch-develop mailing list >>>>> Codematch-develop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_60939B60-798E-491B-995E-0A8EA744724F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Kathleen

In this case, = the data model remains the same, since the =E2=80=9Csolution=E2=80=9D = resides on the semantics of mentor, i.e., the person responsible for = helping in current and new projects. Do you want me to send the data = model again?

That sounds good if that is the case as = simpler is better.  When I look at the data model, it appears that = the Project requires a CodeRequest that connects it to the = specification, but maybe I'm reading it incorrectly.  So if you can = explain how we can have these two possibilities in the current data = model, that would help me before we go = forward.

A CodeRequest is a container for projects that = both (a) are developing new code now and (b) have developed code in the = past. For (a), mentors are important; for (b), mentors make not = difference. If you have one or more projects from the past ( as in (b) ) = to connect to the same specification, you=E2=80=99ll need a CodeRequest = to link those project to that specification. 

You asked how we can have the two possibilities in = the current data model. The data model itself has no specific structures = for both possibilities, but that=E2=80=99s why I mentioned that it = resides in the semantics we assign to mentors, since CodeRequest would = be there anyway, to link either new or old projects to = specifications.

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

Regards,

Lisandro



Thank = you!

Regards,

Lisandro

ps.: It took me a while to reply given the recent carnaval = break in Brazil
Sent from my = iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br> wrote:

Hello Kathleen

I=E2=80=99m 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 =E2=80=9Cfixing=E2=80=9D = this issue by saying that =E2=80=9Ca Mentor is the person responsible = for helping in the development of active projects=E2=80=9D, implying = that mentors have no role in already finished projects? In that way, we = don=E2=80=99t 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, =C3=A0(s) 14:52, Moriarty, Kathleen = <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=E2=80=99s 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=E2=80=99t 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 =E2=80=9Cmentors exist to help in = the development of new projects=E2=80=9D, implying that already finished = projects has now association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data = model with the team!  This looks great from what we = discussed.  =46rom 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 <granville@inf.ufrgs.br> = 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop





--

Best regards,
Kathleen

= --Apple-Mail=_60939B60-798E-491B-995E-0A8EA744724F-- From nobody Sun Feb 22 12:31:00 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9D1A0033 for ; Sun, 22 Feb 2015 12:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6yXZOwWNlbI for ; Sun, 22 Feb 2015 12:30:54 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9906C1A000A for ; Sun, 22 Feb 2015 12:30:54 -0800 (PST) Received: by qczc9 with SMTP id c9so8320415qcz.5 for ; Sun, 22 Feb 2015 12:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BcQkNkMSfIbKYAhAxkww0ewRWlEMOZ1Zm9CKl/okkW4=; b=dxD2pHJVvy4/bszDPMy7DCkUj1HEqjgofjjlbF6fMWJzwUfD89Ac3azJXjPoMAsbeU yJ73I22Sl9xANsQzu9UkGG4vA3Izt/vxSQPJ6IYbjuxmgFswFixlX6WR7gOlxmv7x6NJ Ia/WqU2zaEhJWhmIYMIYbEck4MrhqH60OSy/l1I6TkgAxbSJoW2P09BfbYO5yWnaSsB0 erZxBDEHhezYkHHxDNbJzOcuiInfrSnKIpdLkYwD+A4yUQHEBO//5UcS4br3oi633uUR +sFM6CoJCebBSWlNZt55o0auu8wd/YyJa8Eq8WK5fBeK4ajES/qAhQeIYEHPdVWCcChY c3Aw== X-Received: by 10.140.88.17 with SMTP id s17mr17030538qgd.79.1424637053808; Sun, 22 Feb 2015 12:30:53 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id v65sm26124458qgd.20.2015.02.22.12.30.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Feb 2015 12:30:52 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-806DE029-5828-4D90-B386-B4C479BE68F2 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sun, 22 Feb 2015 15:30:51 -0500 Content-Transfer-Encoding: 7bit Message-Id: <92025554-3B11-4A84-8C12-52EAF679E519@gmail.com> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> To: Lisandro Zambenedetti Granville Archived-At: Cc: "codematch-develop@ietf.org" , "Moriarty, Kathleen" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 20:30:59 -0000 --Apple-Mail-806DE029-5828-4D90-B386-B4C479BE68F2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Feb 22, 2015, at 1:54 PM, Lisandro Zambenedetti Granville wrote: >=20 > Hello Kathleen >=20 >>> In this case, the data model remains the same, since the =E2=80=9Csoluti= on=E2=80=9D resides on the semantics of mentor, i.e., the person responsible= for helping in current and new projects. Do you want me to send the data mo= del again? >>=20 >> That sounds good if that is the case as simpler is better. When I look a= t the data model, it appears that the Project requires a CodeRequest that co= nnects it to the specification, but maybe I'm reading it incorrectly. So if= you can explain how we can have these two possibilities in the current data= model, that would help me before we go forward. >=20 > A CodeRequest is a container for projects that both (a) are developing new= code now and (b) have developed code in the past. For (a), mentors are impo= rtant; for (b), mentors make not difference. If you have one or more project= s from the past ( as in (b) ) to connect to the same specification, you=E2=80= =99ll need a CodeRequest to link those project to that specification.=20 >=20 > You asked how we can have the two possibilities in the current data model.= The data model itself has no specific structures for both possibilities, bu= t that=E2=80=99s why I mentioned that it resides in the semantics we assign t= o mentors, since CodeRequest would be there anyway, to link either new or ol= d projects to specifications. >=20 > If thinks are still not clear, I can try to provide examples. >=20 I think an explanation along with the data model will be necessary if no lin= e is included to show the code request isn't needed to link a project to a s= pecification. That and examples will help developers as we proceed. Thanks, Kathleen > Regards, >=20 > Lisandro >=20 >=20 >>=20 >> Thank you! >>>=20 >>> Regards, >>>=20 >>> Lisandro >>>=20 >>> ps.: It took me a while to reply given the recent carnaval break in Braz= il >>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" wrote: >>>>=20 >>>>> Hello Kathleen >>>>>=20 >>>>> I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch is a relationship between Project and CodeRequest. I believe it is n= ot possible to have another relationship between Project and Specification n= amed CodeMatch too. But let me ask you if you agree with the suggestion of =E2= =80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is the per= son responsible for helping in the development of active projects=E2=80=9D, i= mplying that mentors have no role in already finished projects? In that way,= we don=E2=80=99t need to change the data model. Not that we could not chang= e it, but I believe keeping it simple is important. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Lisandro >>>>>=20 >>>>>> Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen escreveu: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" wrote: >>>>>>=20 >>>>>>> Hi Kathleen,=20 >>>>>>>=20 >>>>>>>> To me, a CodeRequest is an explicit call for FUTURE developments. I= f someone is questing code, that=E2=80=99s because (additional?) code is req= uired. To help in the development of new code throughout new projects, mento= rs seem to be mandatory. >>>>>>>=20 >>>>>>> I agree with Lisandro's reasoning. If there's a code-match, it's bec= ause someone did a code request. Someone needed that code and he will get th= e appropriate "coding" help if the student has some support to do that work.= >>>>>>=20 >>>>>> Good point. >>>>>>>=20 >>>>>>> We can have a different instance for those cases were there is no re= quest, thereby no need to provide a shepherd. They could be just "code oppor= tunity" and there's no commitment from anyone for those code-matches. >>>>>>=20 >>>>>> In looking at the data model again, how about having the CodeMatch ei= ther be a fulfilled CodeRequest mapping a project to a specification or simp= ly the connection between a project and specification. This let's us keep t= he terms and model simple which may be easier for users as they will have le= ss to understand in terms of our terminology. Also keeping the data model s= impler should help reduce coding efforts. >>>>>>=20 >>>>>> =20 >>>>>>>=20 >>>>>>>> However, if you want to advertise projects that already finished, m= entors make not sense indeed. But consider the following situation: there is= a CodeRequest for an specific protocol. That CodeRequest already finds prev= iously finished projects but still requires further code. In that case, the p= revious projects don=E2=80=99t need a mentor, of course, but the new project= s do. But because mentors are associated with CodeRequest (and not with proj= ect), once we define a mentor to help in the new projects that mentor will b= e also linked with the old projects too. In summary, old projects will alway= s 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. >>>>>>>>=20 >>>>>>>> The whole issue resides in the fact that mentors are associated wit= h CodeRequest. Previously, mentors were associated with individual projects (= at that point we were referring projects to as CodeMatches, before the last c= hange in the model). Here, we have some options: >>>>>>=20 >>>>>> Yes, you are correct and I think my updated suggestion fixes this, bu= t let me know if I missed anything. >>>>>>>>=20 >>>>>>>> 1) Assume that dummy mentors can be associated with CodeRequests th= at exist only to advertise already finished projects, but we need to live wi= th the idea that once additional code is needed for those CodeRequests, a re= al mentor will be assigned, and the finished project will inherit that new r= eal mentor. >>>>>>>>=20 >>>>>>>> 2) Rollback the model back to associate mentors with projects, indi= cating that mentors are optional. However, we may be imposing an administrat= ive burden here. >>>>>>>=20 >>>>>>> A third option could be to have active "code-requests" with mentors a= nd "code-opportunities" (or a better name) for finished projects, other RFC= s, etc. with no mentor.=20 >>>>>> Or just to have two options for CodeMatches - with or without a CodeR= equest. >>>>>>=20 >>>>>> Thanks! >>>>>> Kathleen=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Christian >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Another option is checking how we tell the story. The question may b= e solved if we say that =E2=80=9Cmentors exist to help in the development of= new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Lisandro >>>>>>>>=20 >>>>>>>>> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty escreveu: >>>>>>>>>=20 >>>>>>>>> Lisandro, >>>>>>>>>=20 >>>>>>>>> Thank you for your time and effort developing the data model with t= he team! This looks great from what we discussed. =46rom additional feedba= ck 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 dem= onstrate links between a CodeRequest (in this case an RFC) and a project wit= hout having a mentor. You would still have a coder or the project owner th= at creates the link and it would be possible for others to connect their pro= ject to that same published IETF or IRTF document. >>>>>>>>>=20 >>>>>>>>> In that case, would the coder then also be connected to the CodeRe= quest so there are multiple ways to make the connections? >>>>>>>>>=20 >>>>>>>>> We would need search capabilities for coders looking for projects s= o they might only see ones that have a mentor and I'm sure they would want t= o be able to restrict their view to the projects they have time to code (1 FT= E for x weeks or months, etc.). >>>>>>>>>=20 >>>>>>>>> Any other comments? >>>>>>>>>=20 >>>>>>>>> Thank you, >>>>>>>>> Kathleen >>>>>>>>>=20 >>>>>>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville <= granville@inf.ufrgs.br> wrote: >>>>>>>>>> Dear all >>>>>>>>>>=20 >>>>>>>>>> After one of our last meetings, a new data model (v3) for CodeMat= ch 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 s= uggestions mentioned during the last meetings. Terms in this version are als= o aligned with the list of terms previously shared by Kathleen in the mailin= g list. Any feedback is welcomed. >>>>>>>>>>=20 >>>>>>>>>> Best regards, >>>>>>>>>>=20 >>>>>>>>>> Lisandro >>>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Codematch-develop mailing list >>>>>>>>>> Codematch-develop@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>> Kathleen >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Codematch-develop mailing list >>>>>>>> Codematch-develop@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>> _______________________________________________ >>>>>>> Codematch-develop mailing list >>>>>>> Codematch-develop@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>> _______________________________________________ >>>>>> Codematch-develop mailing list >>>>>> Codematch-develop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 --Apple-Mail-806DE029-5828-4D90-B386-B4C479BE68F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Feb 22, 2015, at 1:54 PM, Lisandro Zambenedetti Granville <granville@inf.ufrgs.br> wrote:
=
Hello Kathleen

=
In this case, the data model remains the same, sin= ce the =E2=80=9Csolution=E2=80=9D resides on the semantics of mentor, i.e., t= he person responsible for helping in current and new projects. Do you want m= e to send the data model again?

That sounds good if that is the= case as simpler is better.  When I look at the data model, it appears t= hat the Project requires a CodeRequest that connects it to the specification= , but maybe I'm reading it incorrectly.  So if you can explain how we c= an have these two possibilities in the current data model, that would help m= e before we go forward.

A CodeRequest is a container for projects that both (a) are de= veloping new code now and (b) have developed code in the past. For (a), ment= ors are important; for (b), mentors make not difference. If you have one or m= ore projects from the past ( as in (b) ) to connect to the same specificatio= n, you=E2=80=99ll need a CodeRequest to link those project to that specifica= tion. 

You asked how we can have th= e two possibilities in the current data model. The data model itself has no s= pecific structures for both possibilities, but that=E2=80=99s why I mentione= d that it resides in the semantics we assign to mentors, since CodeRequest w= ould be there anyway, to link either new or old projects to specifications.<= /div>

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

I think an explanation along with the data model will be necessary i= f no line is included to show the code request isn't needed to link a projec= t to a specification.  That and examples will help developers as we pro= ceed.

Thanks,
Kathleen

Regards,

Lisandro



Thank you!

Regards,

Lisandro

<= /div>
ps.: It took me a while to reply given the recent carna= val break in Brazil
<= br class=3D"">
Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <granville@inf.u= frgs.br> wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong.= Today, CodeMatch is a relationship between Project and CodeRequest. I belie= ve it is not possible to have another relationship between Project and Speci= fication named CodeMatch too. But let me ask you if you agree with the suggestion of =E2=80=9Cfixing=E2=80=9D this i= ssue by saying that =E2=80=9Ca Mentor is the person responsible for helping i= n the development of active projects=E2=80=9D, implying that mentors have no= role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe ke= eping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathlee= n.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> w= rote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE developm= ents. If someone is questing code, that=E2=80=99s 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, i= t'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 tha= t work.

Good point.

We can have a different instance for those cases were there i= s no request, thereby no need to provide a shepherd. They could be just "cod= e 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 c= onnection between a project and specification.  This let's us keep the t= erms and model simple which may be easier for users as they will have less to understand in terms of our te= rminology.  Also keeping the data model simpler should help reduce codi= ng efforts.

 

However, if you want to advertise projects that already fini= shed, mentors make not sense indeed. But consider the following situation: t= here is a CodeRequest for an specific protocol. That CodeRequest already fin= ds previously finished projects but still requires further code. In that case, the previous projects don=E2= =80=99t need a mentor, of course, but the new projects do. But because mento= rs are associated with CodeRequest (and not with project), once we define a m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proje= cts 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 d= raft revisions or drafts that extend base specifications.

The whole issue resides in the fact that mentors are associa= ted with CodeRequest. Previously, mentors were associated with individual pr= ojects (at that point we were referring projects to as CodeMatches, before t= he last change in the model). Here, we have some options:

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

1) Assume that dummy mentors can be associated with CodeRequ= ests that exist only to advertise already finished projects, but we need to l= ive 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 project= s, indicating that mentors are optional. However, we may be imposing an admi= nistrative burden here.

A third option could be to have active "code-requests" with m= entors and "code-opportunities" (or a better name) for finished projects, ot= her  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 questi= on may be solved if we say that =E2=80=9Cmentors exist to help in the develo= pment of new projects=E2=80=9D, implying that already finished projects has n= ow association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <k= athleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model= with the team!  This looks great from what we discussed.  =46rom a= dditional feedback received from the IESG, the point was made that you may n= ot always have a shepherd.  If we want this to also advertise existing implementations (open source or proprietary) of e= xisting RFCs, there should be flexibility to demonstrate links between a Cod= eRequest (in this case an RFC) and a project without having a mentor.  Y= ou would still have a coder or the project owner that creates the link and it would be possible for others to c= onnect their project to that same published IETF or IRTF document.

In that case, would the coder then also be connected to the C= odeRequest so there are multiple ways to make the connections?

We would need search capabilities for coders looking for pro= jects 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 co= de (1 FTE for x weeks or months, etc.).

Any other comments?

Thank you,
Kathleen

On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambened= etti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for Co= deMatch has been defined. Please, find below the new version of such a data m= odel. We tried to incorporate the comments received in the list as well as t= he suggestions mentioned during the last meetings. Terms in this version are also aligned with the list of t= erms previously shared by Kathleen in the mailing list. Any feedback is welc= omed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop<= /a>




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop<= /a>

___________________________________________= ____
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/= codematch-develop
_______________________________________________
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop<= /a>





--

Best regards,
Kathleen

= --Apple-Mail-806DE029-5828-4D90-B386-B4C479BE68F2-- From nobody Mon Feb 23 06:47:07 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154E91A1AC6 for ; Mon, 23 Feb 2015 06:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wjUH7z1SEO0 for ; Mon, 23 Feb 2015 06:47:02 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE461A0021 for ; Mon, 23 Feb 2015 06:47:01 -0800 (PST) Received: by labhz20 with SMTP id hz20so18788708lab.0 for ; Mon, 23 Feb 2015 06:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ExFcWK5wzmgDJ9qOP5zQLnBmX08Yb/kC4qieW00Lb8s=; b=psICR1texJG1IbeoO0sr9bihB+w7wH1bVK+wSgFQPzyig3KSTbA3mZiNvO/DxjMzqc gljOwVdjs+TXeXLc/y+PhKAdgsxR0ag5/SGdUgd3KEeKdpvrENDD4BBkycoP7lLA49eJ yxjLa3LiyI8tvIuOLbgx98ZIU9tUj7Qf3DAahvF2ioQKhKZFaruRkBqPBbcJSExGtk+R imexLWKUrzvG80lfhZ1uh38KoOZImX9WQR0woqJ3EK3IZXGsaJnyCRdo2Ehjsmdkrfht C56rtbrZTHaeRz1kzcV5357kBkEKOR9IvVjsxvN7Vr26wrX8kkWCsPdJvPMP3/REonI4 yTLg== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr10110755lbb.4.1424702819725; Mon, 23 Feb 2015 06:46:59 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 23 Feb 2015 06:46:59 -0800 (PST) In-Reply-To: <417614207.728389.1424693682219.JavaMail.root@rnp.br> References: <417614207.728389.1424693682219.JavaMail.root@rnp.br> Date: Mon, 23 Feb 2015 09:46:59 -0500 Message-ID: From: Kathleen Moriarty To: Wanderson Paim de Jesus Content-Type: multipart/alternative; boundary=001a11345b127af602050fc279c9 Archived-At: Cc: "codematch-develop@ietf.org" , Lisandro Zambenedetti Granville , Kathleen Moriarty , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:47:06 -0000 --001a11345b127af602050fc279c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 < wanderson.jesus@rnp.br> 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" > *Para: *"Lisandro Zambenedetti Granville" > *Cc: *"Christian O'Flaherty" , "Kathleen Moriarty" < > kathleen.moriarty@emc.com>, codematch-develop@ietf.org, "Wanderson Paim > de Jesus" > *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 < > granville@inf.ufrgs.br> wrote: > >> Dear all >> >> Wanderson Paim (cc=E2=80=99ed in this message), who develop the prototyp= e >> 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, =C3=A0(s) 15:19, Christian O'Flaherty >> 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" < >> granville@inf.ufrgs.br> wrote: >> >> Hello Kathleen >> >> I=E2=80=99m not an expert on data models, so I may be wrong. Today, Cod= eMatch >> 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 >> =E2=80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is = the person responsible for >> helping in the development of active projects=E2=80=9D, implying that me= ntors have >> no role in already finished projects? In that way, we don=E2=80=99t need= to change >> the data model. Not that we could not change it, but I believe keeping i= t >> simple is important. >> >> Best regards, >> >> Lisandro >> >> Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen < >> kathleen.moriarty@emc.com> escreveu: >> >> Hi, >> >> Sent from my iPhone >> >> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" >> wrote: >> >> Hi Kathleen, >> >> To me, a CodeRequest is an explicit call for FUTURE developments. If >> someone is questing code, that=E2=80=99s because (additional?) code is r= equired. To >> help in the development of new code throughout new projects, mentors see= m >> 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-matche= s. >> >> >> In looking at the data model again, how about having the CodeMatch >> either be a fulfilled CodeRequest mapping a project to a specification o= r >> simply the connection between a project and specification. This let's u= s >> keep the terms and model simple which may be easier for users as they wi= ll >> have less to understand in terms of our terminology. Also keeping the d= ata >> 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: the= re >> is a CodeRequest for an specific protocol. That CodeRequest already find= s >> previously finished projects but still requires further code. In that ca= se, >> the previous projects don=E2=80=99t need a mentor, of course, but the ne= w 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 mento= r >> 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 project= s >> (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 w= ith >> the idea that once additional code is needed for those CodeRequests, a r= eal >> 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 RF= Cs, >> 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 =E2=80=9Cmentors exist to help in the development = of new >> projects=E2=80=9D, implying that already finished projects has now assoc= iation with >> current mentors. Too simplistic? >> >> Best regards, >> >> Lisandro >> >> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> 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 feedbac= k >> 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 (o= pen >> source or proprietary) of existing RFCs, there should be flexibility to >> demonstrate links between a CodeRequest (in this case an RFC) and a proj= ect >> without having a mentor. You would still have a coder or the project ow= ner >> that creates the link and it would be possible for others to connect the= ir >> 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 < >> granville@inf.ufrgs.br> 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 mod= el. >>> We tried to incorporate the comments received in the list as well as th= e >>> suggestions mentioned during the last meetings. Terms in this version a= re >>> also aligned with the list of terms previously shared by Kathleen in th= e >>> mailing list. Any feedback is welcomed. >>> >>> Best regards, >>> >>> Lisandro >>> >>> >>> >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> >> > > > -- > > Best regards, > Kathleen > > --=20 Best regards, Kathleen --001a11345b127af602050fc279c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wanderson,

We are glad to have your ass= istance!

Dave Waltermire has also volunteered to h= elp code and we may have 1-2 other volunteers soon.=C2=A0 If anyone is atte= nding 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 ge= t the tools to install and learn more about the datatracker.=C2=A0 Please l= et me know if you need more information on the Code Sprint.

<= /div>
Thank you,
Kathleen

On Mon, Feb 23, 2015 at 7:14 AM, Wanderso= n Paim de Jesus <wanderson.jesus@rnp.br> wrote:
Hi Kathleen,
=

I find Codematch a good idea and ho= pe being able to contribute with its success.

Christian seems to be interest in coding too. Give= n that I'm not familiar with datatracker, his support would be honestly= welcome.

=
Best regards,=

Wanderson
=

De: "Kathleen Moriarty" <kathleen.moriarty.ietf@g= mail.com>
Para: "Lisandro Zambenedetti Granville"= ; <granville= @inf.ufrgs.br>
Cc: "Christian O'Flaherty" &l= t;oflaherty@isoc.or= g>, "Kathleen Moriarty" <kathleen.moriarty@emc.com>, codematch-develop@= ietf.org, "Wanderson Paim de Jesus" <wanderson.jesus@rnp.br>
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 Granvill= e <granville@inf.ufrgs.br> wrote:
Dear all

Wanderson Paim (cc=E2=80=99ed in this message), who develop the prototyp= e available at = http://codematch.inf.ufrgs.br=C2=A0is also a volunteer to code the Code= Match backend.

Excellent, it= 9;s great to have you on the team Wanderson!=C2=A0 Thank you for volunteeri= ng!

Best regards,
Kathleen=C2=A0

<= /div>
Best regards,

Lisandro

Em 17/02/2015, =C3=A0(s) 15:19, Christian O'Flaherty= <oflaherty@isoc= .org> escreveu:



I have a couple more volunteers for coding as well lined up.=C2=A0 The= re 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 i= nitial volunteers for coding.=C2=A0

Christian=C2=A0


Thank you,
Kathleen=C2=A0

Christian


Thank you,
Kathleen=C2=A0

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf= .ufrgs.br> wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone
Hi Kathleen,=C2=A0

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s 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 su= pport to do that work.

Good point.

We can have a different instance for those cases were there is no requ= est, thereby no need to provide a shepherd. They could be just "code o= pportunity" and there's no commitment from anyone for those code-m= atches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification.=C2=A0 This let's us k= eep the terms and model simple which may be easier for users as they will have less to understand in terms of our t= erminology.=C2=A0 Also keeping the data model simpler should help reduce co= ding efforts.

=C2=A0

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e 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 =C2=A0RFCs, etc. with no mentor.=C2=A0
Or just to have two options for CodeMatches - with or without a CodeRequest= .

Thanks!
Kathleen=C2=A0


Christian


Another option is checking how we tell the story. The question may be = solved if we say that =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model with the = team!=C2=A0 This looks great from what we discussed.=C2=A0 From additional = feedback received from the IESG, the point was made that you may not always= have a shepherd.=C2=A0 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.=C2= =A0 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop



--

Bes= t regards,
Kathleen



=

--

<= div>Best regards,
Kathleen
--001a11345b127af602050fc279c9-- From wanderson.jesus@rnp.br Mon Feb 23 04:15:04 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548721A1A6B for ; Mon, 23 Feb 2015 04:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGRHEH3ZqEIh for ; Mon, 23 Feb 2015 04:14:59 -0800 (PST) Received: from mx0.rnp.br (mx0.rnp.br [IPv6:2001:12f0:b01:101::87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6031A1A72 for ; Mon, 23 Feb 2015 04:14:58 -0800 (PST) Received: from mailpxy02.rnp.br (mailpxy02.rnp.br [200.130.35.9]) by mx0.rnp.br (8.14.3/8.14.3/Debian-9.4) with ESMTP id t1NCEgYK016939; Mon, 23 Feb 2015 09:14:42 -0300 Received: from mailmbs02.rnp.br (zeus.na-df.rnp.br [200.130.35.1]) by mailpxy02.rnp.br (Postfix) with ESMTP id 52A5C2C245D; Mon, 23 Feb 2015 09:14:42 -0300 (BRT) Date: Mon, 23 Feb 2015 09:14:42 -0300 (BRT) From: Wanderson Paim de Jesus To: Kathleen Moriarty Message-ID: <417614207.728389.1424693682219.JavaMail.root@rnp.br> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_728388_936985494.1424693682217" X-Mailer: Zimbra 7.2.5_GA_2906 (ZimbraWebClient - GC40 (Win)/7.2.5_GA_2906) X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: saida, @@RPTN) X-CanIt-Incident-Id: 01NTMeGBs X-CanIt-Geo: ip=200.130.35.1; country=BR; latitude=-23.5477; longitude=-46.6358; http://maps.google.com/maps?q=-23.5477,-46.6358&z=6 X-CanItPRO-Stream: saida X-Canit-Stats-ID: 01NTMeGBs - 174e9593efeb X-Scanned-By: CanIt (www . roaringpenguin . com) on 200.130.35.135 Archived-At: X-Mailman-Approved-At: Mon, 23 Feb 2015 08:54:53 -0800 Cc: codematch-develop@ietf.org, Lisandro Zambenedetti Granville , Kathleen Moriarty , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:47:55 -0000 ------=_Part_728388_936985494.1424693682217 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kathleen,=20 I find Codematch a good idea and hope being able to contribute with its suc= cess.=20 Christian seems to be interest in coding too. Given that I'm not familiar w= ith datatracker, his support would be honestly welcome.=20 Best regards,=20 Wanderson=20 ----- Mensagem original ----- De: "Kathleen Moriarty" =20 Para: "Lisandro Zambenedetti Granville" =20 Cc: "Christian O'Flaherty" , "Kathleen Moriarty" , codematch-develop@ietf.org, "Wanderson Paim de Jesus= " =20 Enviadas: Sexta-feira, 20 de fevereiro de 2015 13:23:51=20 Assunto: Re: [Codematch-develop] CodeMatch data model v3=20 On Fri, Feb 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville < granvill= e@inf.ufrgs.br > wrote:=20 Dear all=20 Wanderson Paim (cc=E2=80=99ed in this message), who develop the prototype a= vailable at http://codematch.inf.ufrgs.br is also a volunteer to code the C= odeMatch backend.=20 Excellent, it's great to have you on the team Wanderson! Thank you for volu= nteering!=20 Best regards,=20 Kathleen=20
Best regards,=20 Lisandro=20
Em 17/02/2015, =C3=A0(s) 15:19, Christian O'Flaherty < oflaherty@isoc.org >= escreveu:=20
I have a couple more volunteers for coding as well lined up. There may be m= ore decisions to be made for that and prep for developers to get familiar w= ith the datatracker and how it will be accessed.=20
Although I never used datatracker as a coder I would like to be among the i= nitial volunteers for coding.=20 Christian=20
Thank you,=20 Kathleen=20
Christian=20
Thank you,=20 Kathleen=20 Sent from my iPhone=20 On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" < granville@= inf.ufrgs.br > wrote:=20
Hello Kathleen=20 I=E2=80=99m not an expert on data models, so I may be wrong. Today, CodeMat= ch is a relationship between Project and CodeRequest. I believe it is not p= ossible to have another relationship between Project and Specification name= d CodeMatch too. But let me ask you if you agree with the suggestion of =E2= =80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is the pe= rson responsible for helping in the development of active projects=E2=80=9D= , implying that mentors have no role in already finished projects? In that = way, we don=E2=80=99t need to change the data model. Not that we could not = change it, but I believe keeping it simple is important.=20 Best regards,=20 Lisandro=20
Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen < kathleen.moriarty@emc.= com > escreveu:=20 Hi,=20 Sent from my iPhone=20 On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" < oflaherty@isoc.org >= wrote:=20
Hi Kathleen,=20
To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=E2=80=99s because (additional?) code is required. = To help in the development of new code throughout new projects, mentors see= m to be mandatory.=20
I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "coding" help if the student has some support to do that work.=20
Good point.=20
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.=20
In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the te= rms and model simple which may be easier for users as they will have less t= o understand in terms of our terminology. Also keeping the data model simpl= er should help reduce coding efforts.=20
However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=E2=80=99t need a mentor, of course, but the new projects d= o. But because mentors are associated with CodeRequest (and not with projec= t), 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 alway= s have a mentor once new projects are required.=20
If the link is to the same draft, but I suspect this will happen more with = draft revisions or drafts that extend base specifications.=20
The whole issue resides in the fact that mentors are associated with CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e in the model). Here, we have some options:=20
Yes, you are correct and I think my updated suggestion fixes this, but let = me know if I missed anything.=20
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 men= tor will be assigned, and the finished project will inherit that new real m= entor.=20 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here.=20
A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, etc= . with no mentor.=20
Or just to have two options for CodeMatches - with or without a CodeRequest= .=20 Thanks!=20 Kathleen=20
Christian=20
Another option is checking how we tell the story. The question may be solve= d if we say that =E2=80=9Cmentors exist to help in the development of new p= rojects=E2=80=9D, implying that already finished projects has now associati= on with current mentors. Too simplistic?=20 Best regards,=20 Lisandro=20
Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty < kathleen.moriarty.ietf@= gmail.com > escreveu:=20 Lisandro,=20 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 hav= ing a mentor. You would still have a coder or the project owner that create= s the link and it would be possible for others to connect their project to = that same published IETF or IRTF document.=20 In that case, would the coder then also be connected to the CodeRequest so = there are multiple ways to make the connections?=20 We would need search capabilities for coders looking for projects so they m= ight only see ones that have a mentor and I'm sure they would want to be ab= le to restrict their view to the projects they have time to code (1 FTE for= x weeks or months, etc.).=20 Any other comments?=20 Thank you,=20 Kathleen=20 On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville < granville= @inf.ufrgs.br > wrote:=20
Dear all=20 After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed.=20 Best regards,=20 Lisandro=20 =20 _______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
--=20 Best regards,=20 Kathleen=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
--=20 Best regards,=20 Kathleen=20 ------=_Part_728388_936985494.1424693682217 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>
Hi Kathleen,

I find Codematch a good idea and hope being able to contr= ibute 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.
<= font face=3D"arial, helvetica, sans-serif">
Best regards,

Wanderson

De: "Kathleen Moriarty" <kathleen.moriarty.ietf@gmai= l.com>
Para: "Lisandro Zambenedetti Granville" <granville@i= nf.ufrgs.br>
Cc: "Christian O'Flaherty" <oflaherty@isoc.org= >, "Kathleen Moriarty" <kathleen.moriarty@emc.com>, codematch-deve= lop@ietf.org, "Wanderson Paim de Jesus" <wanderson.jesus@rnp.br>
<= b>Enviadas: Sexta-feira, 20 de fevereiro de 2015 13:23:51
Assunto= : Re: [Codematch-develop] CodeMatch data model v3



On Fri, Fe= b 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville &l= t;granville@inf= .ufrgs.br> wrote:
Dear all

Wanderson Paim (cc= =E2=80=99ed in this message), who develop the prototype available at http://codematch.inf.= ufrgs.br is also a volunteer to code the CodeMatch backend.
<= /div>

Excellent, it's great to have you on = the team Wanderson!  Thank you for volunteering!

<= div>Best regards,
Kathleen 

Best regards,

Lisandro

Em 17/= 02/2015, =C3=A0(s) 15:19, Christian O'Flaherty <oflaherty@isoc.org> escreveu:
<= div>



I have a couple more volunteers for coding as well lined up.  The= re 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 i= nitial 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" <granville@inf.ufrgs.br= > wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone
Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s seem to be mandatory.

I agree with Lisandro's reasoning. If there's a code-match, it's becau= se 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 requ= est, thereby no need to provide a shepherd. They could be just "code opport= unity" and there's no commitment from anyone for those code-matches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e burden here.

A third option could be to have active "code-requests" with mentors an= d "code-opportunities" (or a better name) for finished projects, other &nbs= p;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 =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> 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.&nb= sp; 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 FT= E for x weeks or months, etc.).

Any other comments?

Thank you,
Kathleen

On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop



--

Best regards,
Kathleen

------=_Part_728388_936985494.1424693682217-- From nobody Mon Feb 23 10:13:40 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689871A1B4B for ; Mon, 23 Feb 2015 10:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxJy6AmYgflR for ; Mon, 23 Feb 2015 10:13:38 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57461A1EEA for ; Mon, 23 Feb 2015 10:13:32 -0800 (PST) Received: by labms9 with SMTP id ms9so20161804lab.10 for ; Mon, 23 Feb 2015 10:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=o84FtLMjaAz6uGjXIvFePGZjHNNSZb1tNlfVxoFqSbE=; b=r9urlXe0BxTHZLm5OGs5emVxQlibXc+9MjA5uq4FAjm68iZlN2KU+ieG2UFY2JcFX6 3zLu57bWNYfBF0Ai1zT20SUwAe1YzOoErgBT2wUSX0gbt0tJarRLULwV9uH2w0dpGVK8 P65PI0ipOkZSWE4Ga3xCdtWLiowXwY/xR0lHmbssDT12zkR6i8DXY1/3IOx/wcMfG0k8 lLVzeKX/DHuAi1tPlakPDok0r7yhoTID1CIs3SDpAsu+viESKOvUJOWjYARqe7LURpm0 g/EquqxNyanbwVPXxBSN8GZDRdBbdh9lOlyLUr0OujYzAQqj/E5/ot3h0p6/sAkFHtby mQ7A== MIME-Version: 1.0 X-Received: by 10.112.181.41 with SMTP id dt9mr501730lbc.56.1424715210958; Mon, 23 Feb 2015 10:13:30 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 23 Feb 2015 10:13:30 -0800 (PST) Date: Mon, 23 Feb 2015 13:13:30 -0500 Message-ID: From: Kathleen Moriarty To: "codematch-develop@ietf.org" Content-Type: multipart/alternative; boundary=001a11c369860e2ad1050fc55cef Archived-At: Subject: [Codematch-develop] "about" web page X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:13:39 -0000 --001a11c369860e2ad1050fc55cef Content-Type: text/plain; charset=UTF-8 Hello, Our web page is available at the following link: http://www.ietf.org/codematch/ The secretariat is looking into the subdomain still so that it will also be available at: https://codematch.ietf.org as well. We will have the subdomain to work with and this is just static content that would move to just being an "about" page when we are ready for the site to go live. -- Best regards, Kathleen --001a11c369860e2ad1050fc55cef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Our web page is available at the= following link:

The secretariat is l= ooking into the subdomain still so that it will also be available at:
=
https://codematch.ietf.org = as well.=C2=A0 We will have the subdomain to work with and this is just sta= tic content that would move to just being an "about" page when we= are ready for the site to go live.

--
=

Best regards,
Kathleen
--001a11c369860e2ad1050fc55cef-- From nobody Tue Feb 24 02:41:46 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721191A0439 for ; Tue, 24 Feb 2015 02:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksUjrkys7IFn for ; Tue, 24 Feb 2015 02:41:39 -0800 (PST) Received: from delivery1.ufrgs.br (delivery1.ufrgs.br [143.54.2.211]) by ietfa.amsl.com (Postfix) with ESMTP id C25CC1A038E for ; Tue, 24 Feb 2015 02:41:38 -0800 (PST) Received: from delivery1.ufrgs.br (localhost [127.0.0.1]) by delivery1.ufrgs.br (Postfix) with ESMTP id BDD2E300106; Tue, 24 Feb 2015 07:41:35 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery1.ufrgs.br (Postfix) with ESMTP id 68313188; Tue, 24 Feb 2015 07:41:35 -0300 (BRT) Content-Type: multipart/alternative; boundary="Apple-Mail=_25C5C817-5D85-4B76-A14A-9518FE282823" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: <92025554-3B11-4A84-8C12-52EAF679E519@gmail.com> Date: Tue, 24 Feb 2015 10:41:28 +0000 Message-Id: References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> <92025554-3B11-4A84-8C12-52EAF679E519@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: "codematch-develop@ietf.org" , "Moriarty, Kathleen" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 10:41:44 -0000 --Apple-Mail=_25C5C817-5D85-4B76-A14A-9518FE282823 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> If thinks are still not clear, I can try to provide examples. >>=20 > 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=E2=80=99t need a mentor anymore. Best regards, Lisandro >>>> Sent from my iPhone >>>>=20 >>>> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" = > wrote: >>>>=20 >>>>> Hello Kathleen >>>>>=20 >>>>> I=E2=80=99m 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 =E2=80=9Cfixing=E2=80=9D this issue by saying = that =E2=80=9Ca Mentor is the person responsible for helping in the = development of active projects=E2=80=9D, implying that mentors have no = role in already finished projects? In that way, we don=E2=80=99t need to = change the data model. Not that we could not change it, but I believe = keeping it simple is important. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Lisandro >>>>>=20 >>>>>> Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen = > escreveu: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" = > wrote: >>>>>>=20 >>>>>>> Hi Kathleen,=20 >>>>>>>=20 >>>>>>>> To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=E2=80=99s because = (additional?) code is required. To help in the development of new code = throughout new projects, mentors seem to be mandatory. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> Good point. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> =20 >>>>>>>=20 >>>>>>>> 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=E2=80=99t = 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. >>>>>>>>=20 >>>>>>>> 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: >>>>>>=20 >>>>>> Yes, you are correct and I think my updated suggestion fixes = this, but let me know if I missed anything. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 2) Rollback the model back to associate mentors with projects, = indicating that mentors are optional. However, we may be imposing an = administrative burden here. >>>>>>>=20 >>>>>>> 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.=20 >>>>>> Or just to have two options for CodeMatches - with or without a = CodeRequest. >>>>>>=20 >>>>>> Thanks! >>>>>> Kathleen=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Christian >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Another option is checking how we tell the story. The question = may be solved if we say that =E2=80=9Cmentors exist to help in the = development of new projects=E2=80=9D, implying that already finished = projects has now association with current mentors. Too simplistic? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Lisandro >>>>>>>>=20 >>>>>>>>> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty = > escreveu: >>>>>>>>>=20 >>>>>>>>> Lisandro, >>>>>>>>>=20 >>>>>>>>> Thank you for your time and effort developing the data model = with the team! This looks great from what we discussed. =46rom = 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. >>>>>>>>>=20 >>>>>>>>> In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >>>>>>>>>=20 >>>>>>>>> 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.). >>>>>>>>>=20 >>>>>>>>> Any other comments? >>>>>>>>>=20 >>>>>>>>> Thank you, >>>>>>>>> Kathleen >>>>>>>>>=20 >>>>>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti = Granville > = wrote: >>>>>>>>> Dear all >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>>=20 >>>>>>>>> Lisandro >>>>>>>>>=20 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Codematch-develop mailing list >>>>>>>>> Codematch-develop@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>> Kathleen >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Codematch-develop mailing list >>>>>>>> Codematch-develop@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Codematch-develop mailing list >>>>>>> Codematch-develop@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>> _______________________________________________ >>>>>> Codematch-develop mailing list >>>>>> Codematch-develop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>=20 --Apple-Mail=_25C5C817-5D85-4B76-A14A-9518FE282823 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99t need a mentor anymore.

Best regards,

Lisandro

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br> wrote:

Hello Kathleen

I=E2=80=99m 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 =E2=80=9Cfixing=E2=80=9D = this issue by saying that =E2=80=9Ca Mentor is the person responsible = for helping in the development of active projects=E2=80=9D, implying = that mentors have no role in already finished projects? In that way, we = don=E2=80=99t 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, =C3=A0(s) 14:52, Moriarty, Kathleen = <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=E2=80=99s 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=E2=80=99t 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 =E2=80=9Cmentors exist to help in = the development of new projects=E2=80=9D, implying that already finished = projects has now association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data = model with the team!  This looks great from what we = discussed.  =46rom 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 <granville@inf.ufrgs.br> = 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop





--

Best regards,
Kathleen

<= br class=3D"">= --Apple-Mail=_25C5C817-5D85-4B76-A14A-9518FE282823-- From nobody Tue Feb 24 13:15:54 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624F51A8915 for ; Tue, 24 Feb 2015 13:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXNsAyA-gSw5 for ; Tue, 24 Feb 2015 13:15:48 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576331A1B4E for ; Tue, 24 Feb 2015 13:15:48 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1OLFhNr012380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2015 16:15:45 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t1OLFhNr012380 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1424812545; bh=9YoGn8bRr0y5WOViNzu45fbcsAE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=lzPhUOXyafxx32rBo1L+/1LgSJ3MispFQpt1p16YeT9TTckiJXqFThY9pf1u82JBO EKJdeSYbD5aZmFcjFWYQZ2VnJdcn7g/kp3Q8Y4gcZ04xXVb1jW/3cYIwq3+7hgWwxR U1xqKlCdvWocJjY3+G4x0tSa2Qxv1HhCM2vQQU74= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t1OLFhNr012380 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 24 Feb 2015 16:15:10 -0500 Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1OLFUhl020277 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Feb 2015 16:15:31 -0500 Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub37.corp.emc.com (128.222.70.104) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 24 Feb 2015 16:15:31 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.139]) by MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 16:15:29 -0500 From: "Moriarty, Kathleen" To: Lisandro Zambenedetti Granville Thread-Topic: [Codematch-develop] CodeMatch data model v3 Thread-Index: AQHQQq+SGJ7q08W7q0eviA8qezQlOZzr6h8AgAJxvQCAAMJUAIABSbe1gAS6eYD//7N9JIAE9m0AgABFOgCAA17QAIAAGwSAgAJ//QCAAF1U+A== Date: Tue, 24 Feb 2015 21:15:29 +0000 Message-ID: <6DAA1C7D-E7D2-4057-A0DB-9438D5755A2D@emc.com> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> <92025554-3B11-4A84-8C12-52EAF679E519@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6DAA1C7DE7D24057A0DB9438D5755A2Demccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Kathleen Moriarty , "codematch-develop@ietf.org" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 21:15:53 -0000 --_000_6DAA1C7DE7D24057A0DB9438D5755A2Demccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Lisandro, Sent from my iPhone On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" > 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 li= ne 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 specif= ication. The data model is not missing a link between projects and specific= ations; projects are are linked to specifications only through a CodeReques= t. What we have discussed so far is that the mentor field in the CodeReques= t is only meaningful for active projects, since already finished projects d= on=92t 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 g= rouping, but I'd like to talk through this a bit. If you have an example f= or 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" > wrote: Hello Kathleen I=92m 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 possibl= e to have another relationship between Project and Specification named Code= Match too. But let me ask you if you agree with the suggestion of =93fixing= =94 this issue by saying that =93a Mentor is the person responsible for hel= ping in the development of active projects=94, implying that mentors have n= o role in already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen > escreveu: Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" > wrote: Hi Kathleen, To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=92s because (additional?) code is required. To hel= p in the development of new code throughout new projects, mentors seem to b= e mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the t= erms 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 sim= pler should help reduce coding efforts. However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=92t need a mentor, of course, but the new projects do. But= because mentors are associated with CodeRequest (and not with project), on= ce 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, et= c. 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 solve= d if we say that =93mentors exist to help in the development of new project= s=94, implying that already finished projects has now association with curr= ent mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty > 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 receiv= ed from the IESG, the point was made that you may not always have a shepher= d. If we want this to also advertise existing implementations (open source= or proprietary) of existing RFCs, there should be flexibility to demonstra= te 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 cr= eates 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 > wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop -- Best regards, Kathleen --_000_6DAA1C7DE7D24057A0DB9438D5755A2Demccom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Lisandro,

Sent from my iPhone

On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf.ufrgs.br> = wrote:

If thinks are still not clear, I can try to provide example= s.

I think an explanation along with the data model will be necessary if no li= ne 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 s= pecification. The data model is not missing a link between projects and spe= cifications; projects are are linked to specifications only through a CodeR= equest. What we have discussed so far is that the mentor field in the CodeRequest is only meaningful for act= ive projects, since already finished projects don=92t 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 hav= e 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" &l= t;gr= anville@inf.ufrgs.br> wrote:

Hello Kathleen

I=92m not an expert on data models, so I may be wrong. Toda= y, CodeMatch is a relationship between Project and CodeRequest. I believe i= t is not possible to have another relationship between Project and Specific= ation named CodeMatch too. But let me ask you if you agree with the suggestion of =93fixing=94 this issue by say= ing that =93a Mentor is the person responsible for helping in the developme= nt of active projects=94, implying that mentors have no role in already fin= ished projects? In that way, we don=92t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen <kathleen= .moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.= org> wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE develop= ments. If someone is questing code, that=92s because (additional?) code is = required. To help in the development of new code throughout new projects, m= entors 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 w= ill get the appropriate "coding" help if the student has some sup= port 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 &= quot;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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already fin= ished, 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= =92t 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 m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 associ= ated with CodeRequest. Previously, mentors were associated with individual = projects (at that point we were referring projects to as CodeMatches, befor= e 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 CodeReq= uests that exist only to advertise already finished projects, but we need t= o live with the idea that once additional code is needed for those CodeRequ= ests, 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 projec= ts, indicating that mentors are optional. However, we may be imposing an ad= ministrative burden here.

A third option could be to have active "code-requests&= quot; with mentors and "code-opportunities" (or a better name) fo= r 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 quest= ion may be solved if we say that =93mentors exist to help in the developmen= t of new projects=94, implying that already finished projects has now assoc= iation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <k= athleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data mode= l 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.&nb= sp; 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 pr= ojects so they might only see ones that have a mentor and I'm sure they wou= ld 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for C= odeMatch has been defined. Please, find below the new version of such a dat= a 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
= Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
= Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop

__________________________________________= _____
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinf= o/codematch-develop
_______________________________________________
Codematch-develop mailing list
= Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-deve= lop





--

Best regards,
Kathleen


--_000_6DAA1C7DE7D24057A0DB9438D5755A2Demccom_-- From nobody Wed Feb 25 04:19:10 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90D41A00BB for ; Wed, 25 Feb 2015 04:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8ojQwbDxgIi for ; Wed, 25 Feb 2015 04:19:04 -0800 (PST) Received: from delivery1.ufrgs.br (delivery1.ufrgs.br [143.54.2.211]) by ietfa.amsl.com (Postfix) with ESMTP id B78311A00B8 for ; Wed, 25 Feb 2015 04:19:01 -0800 (PST) Received: from delivery1.ufrgs.br (localhost [127.0.0.1]) by delivery1.ufrgs.br (Postfix) with ESMTP id E4F663007D2; Wed, 25 Feb 2015 09:18:58 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery1.ufrgs.br (Postfix) with ESMTP id 9138B3D701; Wed, 25 Feb 2015 09:18:58 -0300 (BRT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E5AD040-B4B9-44DB-A493-A636C3775DAB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: <6DAA1C7D-E7D2-4057-A0DB-9438D5755A2D@emc.com> Date: Wed, 25 Feb 2015 12:18:48 +0000 Message-Id: <0A629A11-0F2F-4365-99FF-02936F59A299@inf.ufrgs.br> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> <92025554-3B11-4A84-8C12-52EAF679E519@gmail.com> <, > <6DAA1C7D-E7D2-4057-A0DB-9438D5755A2D@emc.com> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.2070.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: Kathleen Moriarty , "codematch-develop@ietf.org" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 12:19:08 -0000 --Apple-Mail=_2E5AD040-B4B9-44DB-A493-A636C3775DAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Kathleen Thanks, that=92s perfect. But just confirming. The meeting will be = tomorrow or today? I thought it was today, but I may be wrong. Best regards, Lisandro > Em 24/02/2015, =E0(s) 21:15, Moriarty, Kathleen = escreveu: >=20 > Hi Lisandro, >=20 > Sent from my iPhone >=20 > On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" = > wrote: >=20 >>>> If thinks are still not clear, I can try to provide examples. >>>>=20 >>> 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. >>=20 >> Hello Kathleen >>=20 >> 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=92t need a mentor anymore. >>=20 > 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. >=20 > Thank you, > Kathleen >=20 >> Best regards, >>=20 >> Lisandro >>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" = > wrote: >>>>>>=20 >>>>>>> Hello Kathleen >>>>>>>=20 >>>>>>> I=92m 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 =93fixing=94 this issue by saying that =93a Mentor is = the person responsible for helping in the development of active = projects=94, implying that mentors have no role in already finished = projects? In that way, we don=92t need to change the data model. Not = that we could not change it, but I believe keeping it simple is = important. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Lisandro >>>>>>>=20 >>>>>>>> Em 14/02/2015, =E0(s) 14:52, Moriarty, Kathleen = > escreveu: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" = > wrote: >>>>>>>>=20 >>>>>>>>> Hi Kathleen,=20 >>>>>>>>>=20 >>>>>>>>>> To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=92s because = (additional?) code is required. To help in the development of new code = throughout new projects, mentors seem to be mandatory. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Good point. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>> 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=92t 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. >>>>>>>>>>=20 >>>>>>>>>> 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: >>>>>>>>=20 >>>>>>>> Yes, you are correct and I think my updated suggestion fixes = this, but let me know if I missed anything. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 2) Rollback the model back to associate mentors with = projects, indicating that mentors are optional. However, we may be = imposing an administrative burden here. >>>>>>>>>=20 >>>>>>>>> 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.=20 >>>>>>>> Or just to have two options for CodeMatches - with or without a = CodeRequest. >>>>>>>>=20 >>>>>>>> Thanks! >>>>>>>> Kathleen=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Christian >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Another option is checking how we tell the story. The = question may be solved if we say that =93mentors exist to help in the = development of new projects=94, implying that already finished projects = has now association with current mentors. Too simplistic? >>>>>>>>>>=20 >>>>>>>>>> Best regards, >>>>>>>>>>=20 >>>>>>>>>> Lisandro >>>>>>>>>>=20 >>>>>>>>>>> Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty = > escreveu: >>>>>>>>>>>=20 >>>>>>>>>>> Lisandro, >>>>>>>>>>>=20 >>>>>>>>>>> Thank you for your time and effort developing the data model = with the team! This looks great from what we discussed. =46rom = 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. >>>>>>>>>>>=20 >>>>>>>>>>> In that case, would the coder then also be connected to the = CodeRequest so there are multiple ways to make the connections? >>>>>>>>>>>=20 >>>>>>>>>>> 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.). >>>>>>>>>>>=20 >>>>>>>>>>> Any other comments? >>>>>>>>>>>=20 >>>>>>>>>>> Thank you, >>>>>>>>>>> Kathleen >>>>>>>>>>>=20 >>>>>>>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti = Granville > = wrote: >>>>>>>>>>> Dear all >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> Best regards, >>>>>>>>>>>=20 >>>>>>>>>>> Lisandro >>>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Codematch-develop mailing list >>>>>>>>>>> Codematch-develop@ietf.org = >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>>=20 >>>>>>>>>>> Best regards, >>>>>>>>>>> Kathleen >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Codematch-develop mailing list >>>>>>>>>> Codematch-develop@ietf.org = >>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Codematch-develop mailing list >>>>>>>>> Codematch-develop@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>> _______________________________________________ >>>>>>>> Codematch-develop mailing list >>>>>>>> Codematch-develop@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop = >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>=20 >>=20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --Apple-Mail=_2E5AD040-B4B9-44DB-A493-A636C3775DAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Kathleen

Thanks, that=92s perfect. But just confirming. The meeting = will be tomorrow or today? I thought it was today, but I may be = wrong.

Best = regards,

Lisandro

Em = 24/02/2015, =E0(s) 21:15, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi Lisandro,

Sent from my iPhone

On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br> 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=92t 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" <granville@inf.ufrgs.br> wrote:

Hello Kathleen

I=92m 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 =93fixing=94 this issue by = saying that =93a Mentor is the person responsible for helping in the = development of active projects=94, implying that mentors have no role in = already finished projects? In that way, we don=92t 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, =E0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE = developments. If someone is questing code, that=92s 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=92t 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 =93mentors exist to help in the = development of new projects=94, implying that already finished projects = has now association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =E0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data = model with the team!  This looks great from what we = discussed.  =46rom 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 <granville@inf.ufrgs.br> = 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

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop





--

Best regards,
Kathleen


_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_2E5AD040-B4B9-44DB-A493-A636C3775DAB-- From nobody Wed Feb 25 04:36:59 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155B71A014A for ; Wed, 25 Feb 2015 04:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCRaMq7Csijh for ; Wed, 25 Feb 2015 04:36:54 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CCE1A0143 for ; Wed, 25 Feb 2015 04:36:54 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id n8so2430407qaq.3 for ; Wed, 25 Feb 2015 04:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kjuxv6d+reeWMAcEasIKQSbZ9PkIeZShIgoKykD98zo=; b=Ra/RQNYb7UhnlwK9EjALRT1zSiW1urcA0FlVBeq+F4hTqaxk6+OuU6PmJK0KYewmDX C5CfZhjkpPzMeYfPJ1J4UxxBRd1U/bz8MRobWFfAEb2FrkjfWtaRdtCsOkiQKAuf8pil DxzmxR8Ht6tYhbJZ4EiHTF0O8MlQYW2iUPM2BIg5ug+OPy7nFngqhbykBBcAdh3dId2D OZKWGjyTeOoH+Mx3vKzWaLzs72VsHcPhPsQjp7xnEUJKvUcZcHoK6nr4g5G7Z+IrAGQ+ mN62yE4cB4sxUO7y+vBd/P5rBHaoq+5ZP9RoN3H17lujH27L1qU965QcrQSxcyTzzhyi 16Cw== X-Received: by 10.140.40.203 with SMTP id x69mr6180751qgx.15.1424867812276; Wed, 25 Feb 2015 04:36:52 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id r1sm1348479qai.24.2015.02.25.04.36.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 04:36:50 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-16741231-F3F3-4B3B-8AD3-913AE27C0566 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <0A629A11-0F2F-4365-99FF-02936F59A299@inf.ufrgs.br> Date: Wed, 25 Feb 2015 07:36:49 -0500 Content-Transfer-Encoding: 7bit Message-Id: <52F805E4-9D99-4CCA-90A2-A5A2077B8610@gmail.com> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> <92025554-3B11-4A84-8C12-52EAF679E519@gmail.com> <, > <6DAA1C7D-E7D2-4057-A0DB-9438D5755A2D@emc.com> <0A629A11-0F2F-4365-99FF-02936F59A299@inf.ufrgs.br> To: Lisandro Zambenedetti Granville Archived-At: Cc: "codematch-develop@ietf.org" , "Moriarty, Kathleen" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 12:36:58 -0000 --Apple-Mail-16741231-F3F3-4B3B-8AD3-913AE27C0566 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lisandro, The meeting is today, I sent my message on Tuesday. Thank you, Kathleen=20 Sent from my iPhone > On Feb 25, 2015, at 7:18 AM, Lisandro Zambenedetti Granville wrote: >=20 > Hi Kathleen >=20 > Thanks, that=E2=80=99s perfect. But just confirming. The meeting will be t= omorrow or today? I thought it was today, but I may be wrong. >=20 > Best regards, >=20 > Lisandro >=20 >> Em 24/02/2015, =C3=A0(s) 21:15, Moriarty, Kathleen escreveu: >>=20 >> Hi Lisandro, >>=20 >> Sent from my iPhone >>=20 >> On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" wrote: >>=20 >>>>> 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 n= o line is included to show the code request isn't needed to link a project t= o a specification. That and examples will help developers as we proceed. >>>=20 >>> Hello Kathleen >>>=20 >>> Just to clarify: a CodeRequest is still needed to link projects to a spe= cification. The data model is not missing a link between projects and specif= ications; projects are are linked to specifications only through a CodeReque= st. What we have discussed so far is that the mentor field in the CodeReques= t is only meaningful for active projects, since already finished projects do= n=E2=80=99t need a mentor anymore. >> Let's chat about this tomorrow as I still don't see why a direct connecti= on between a project and specification can't be made. Maybe it's to have a g= rouping, but I'd like to talk through this a bit. If you have an example fo= r tomorrow, that may help. >>=20 >> Thank you, >> Kathleen >>=20 >>> Best regards, >>>=20 >>> Lisandro >>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" wrote: >>>>>>>>=20 >>>>>>>>> Hello Kathleen >>>>>>>>>=20 >>>>>>>>> I=E2=80=99m not an expert on data models, so I may be wrong. Today= , CodeMatch is a relationship between Project and CodeRequest. I believe it i= s not possible to have another relationship between Project and Specificatio= n named CodeMatch too. But let me ask you if you agree with the suggestion o= f =E2=80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is th= e person responsible for helping in the development of active projects=E2=80= =9D, implying that mentors have no role in already finished projects? In tha= t way, we don=E2=80=99t need to change the data model. Not that we could not= change it, but I believe keeping it simple is important. >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>>=20 >>>>>>>>> Lisandro >>>>>>>>>=20 >>>>>>>>>> Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen escreveu: >>>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Kathleen,=20 >>>>>>>>>>>=20 >>>>>>>>>>>> To me, a CodeRequest is an explicit call for FUTURE development= s. If someone is questing code, that=E2=80=99s because (additional?) code is= required. To help in the development of new code throughout new projects, m= entors seem to be mandatory. >>>>>>>>>>>=20 >>>>>>>>>>> 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 ge= t the appropriate "coding" help if the student has some support to do that w= ork. >>>>>>>>>>=20 >>>>>>>>>> Good point. >>>>>>>>>>>=20 >>>>>>>>>>> We can have a different instance for those cases were there is n= o request, thereby no need to provide a shepherd. They could be just "code o= pportunity" and there's no commitment from anyone for those code-matches. >>>>>>>>>>=20 >>>>>>>>>> In looking at the data model again, how about having the CodeMatc= h either be a fulfilled CodeRequest mapping a project to a specification or s= imply the connection between a project and specification. This let's us kee= p 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 mode= l simpler should help reduce coding efforts. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>>>=20 >>>>>>>>>>>> However, if you want to advertise projects that already finishe= d, mentors make not sense indeed. But consider the following situation: ther= e is a CodeRequest for an specific protocol. That CodeRequest already finds p= reviously finished projects but still requires further code. In that case, t= he previous projects don=E2=80=99t need a mentor, of course, but the new pro= jects do. But because mentors are associated with CodeRequest (and not with p= roject), once we define a mentor to help in the new projects that mentor wil= l be also linked with the old projects too. In summary, old projects will al= ways have a mentor once new projects are required. >>>>>>>>>> If the link is to the same draft, but I suspect this will happen m= ore with draft revisions or drafts that extend base specifications. >>>>>>>>>>>>=20 >>>>>>>>>>>> The whole issue resides in the fact that mentors are associated= with CodeRequest. Previously, mentors were associated with individual proje= cts (at that point we were referring projects to as CodeMatches, before the l= ast change in the model). Here, we have some options: >>>>>>>>>>=20 >>>>>>>>>> Yes, you are correct and I think my updated suggestion fixes this= , but let me know if I missed anything. >>>>>>>>>>>>=20 >>>>>>>>>>>> 1) Assume that dummy mentors can be associated with CodeRequest= s that exist only to advertise already finished projects, but we need to liv= e 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 ne= w real mentor. >>>>>>>>>>>>=20 >>>>>>>>>>>> 2) Rollback the model back to associate mentors with projects, i= ndicating that mentors are optional. However, we may be imposing an administ= rative burden here. >>>>>>>>>>>=20 >>>>>>>>>>> A third option could be to have active "code-requests" with ment= ors and "code-opportunities" (or a better name) for finished projects, other= RFCs, etc. with no mentor.=20 >>>>>>>>>> Or just to have two options for CodeMatches - with or without a C= odeRequest. >>>>>>>>>>=20 >>>>>>>>>> Thanks! >>>>>>>>>> Kathleen=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Christian >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Another option is checking how we tell the story. The question m= ay be solved if we say that =E2=80=9Cmentors exist to help in the developmen= t of new projects=E2=80=9D, implying that already finished projects has now a= ssociation with current mentors. Too simplistic? >>>>>>>>>>>>=20 >>>>>>>>>>>> Best regards, >>>>>>>>>>>>=20 >>>>>>>>>>>> Lisandro >>>>>>>>>>>>=20 >>>>>>>>>>>>> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty escreveu: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Lisandro, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thank you for your time and effort developing the data model w= ith the team! This looks great from what we discussed. =46rom additional f= eedback received from the IESG, the point was made that you may not always h= ave 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 p= roject to that same published IETF or IRTF document. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In that case, would the coder then also be connected to the Co= deRequest so there are multiple ways to make the connections? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We would need search capabilities for coders looking for proje= cts so they might only see ones that have a mentor and I'm sure they would w= ant to be able to restrict their view to the projects they have time to code= (1 FTE for x weeks or months, etc.). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any other comments? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> Kathleen >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granvil= le wrote: >>>>>>>>>>>>>> Dear all >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> After one of our last meetings, a new data model (v3) for Cod= eMatch has been defined. Please, find below the new version of such a data m= odel. We tried to incorporate the comments received in the list as well as t= he suggestions mentioned during the last meetings. Terms in this version are= also aligned with the list of terms previously shared by Kathleen in the ma= iling list. Any feedback is welcomed. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Lisandro >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Codematch-develop mailing list >>>>>>>>>>>>>> Codematch-develop@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Kathleen >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Codematch-develop mailing list >>>>>>>>>>>> Codematch-develop@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Codematch-develop mailing list >>>>>>>>>>> Codematch-develop@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>>>>> _______________________________________________ >>>>>>>>>> Codematch-develop mailing list >>>>>>>>>> Codematch-develop@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >=20 --Apple-Mail-16741231-F3F3-4B3B-8AD3-913AE27C0566 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Lisandro,

= The meeting is today, I sent my message on Tuesday.

Thank you,
Kathleen 

Sent from my iPhone
On Feb 25, 2015, at 7:18 AM, Lisandro Zambenedetti Granville <granville@inf.ufrgs.br> wrote:
Hi Kathleen

Thanks, that=E2=80=99s perfect. But just confir= ming. The meeting will be tomorrow or today? I thought it was today, but I m= ay be wrong.

Best r= egards,

Lisandro

Em 24/02/2015, =C3=A0(s) 21:15, Moriarty, K= athleen <kathleen= .moriarty@emc.com> escreveu:

Hi Lisandro,

Sent from my iPhone

On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br> wr= ote:

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 lin= e is included to show the code request isn't needed to link a project to a s= pecification.  That and examples will help developers as we proceed.

Hello Kathleen

Just to clarify: a CodeRequest is still needed to link proje= cts to a specification. The data model is not missing a link between project= s 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 acti= ve projects, since already finished projects don=E2=80=99t need a mentor any= more.

Let's chat about this tomorrow as I still don't see why a direct connection b= etween 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 exa= mple 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" <granville@inf.u= frgs.br> wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong.= Today, CodeMatch is a relationship between Project and CodeRequest. I belie= ve it is not possible to have another relationship between Project and Speci= fication named CodeMatch too. But let me ask you if you agree with the suggestion of =E2=80=9Cfixing=E2=80=9D this i= ssue by saying that =E2=80=9Ca Mentor is the person responsible for helping i= n the development of active projects=E2=80=9D, implying that mentors have no= role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe ke= eping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathlee= n.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> w= rote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE developm= ents. If someone is questing code, that=E2=80=99s 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, i= t'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 tha= t work.

Good point.

We can have a different instance for those cases were there i= s no request, thereby no need to provide a shepherd. They could be just "cod= e 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 c= onnection between a project and specification.  This let's us keep the t= erms and model simple which may be easier for users as they will have less to understand in terms of our te= rminology.  Also keeping the data model simpler should help reduce codi= ng efforts.

 

However, if you want to advertise projects that already fini= shed, mentors make not sense indeed. But consider the following situation: t= here is a CodeRequest for an specific protocol. That CodeRequest already fin= ds previously finished projects but still requires further code. In that case, the previous projects don=E2= =80=99t need a mentor, of course, but the new projects do. But because mento= rs are associated with CodeRequest (and not with project), once we define a m= entor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proje= cts 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 d= raft revisions or drafts that extend base specifications.

The whole issue resides in the fact that mentors are associa= ted with CodeRequest. Previously, mentors were associated with individual pr= ojects (at that point we were referring projects to as CodeMatches, before t= he last change in the model). Here, we have some options:

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

1) Assume that dummy mentors can be associated with CodeRequ= ests that exist only to advertise already finished projects, but we need to l= ive 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 project= s, indicating that mentors are optional. However, we may be imposing an admi= nistrative burden here.

A third option could be to have active "code-requests" with m= entors and "code-opportunities" (or a better name) for finished projects, ot= her  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 questi= on may be solved if we say that =E2=80=9Cmentors exist to help in the develo= pment of new projects=E2=80=9D, implying that already finished projects has n= ow association with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <k= athleen.moriarty.ietf@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model= with the team!  This looks great from what we discussed.  =46rom a= dditional feedback received from the IESG, the point was made that you may n= ot always have a shepherd.  If we want this to also advertise existing implementations (open source or proprietary) of e= xisting RFCs, there should be flexibility to demonstrate links between a Cod= eRequest (in this case an RFC) and a project without having a mentor.  Y= ou would still have a coder or the project owner that creates the link and it would be possible for others to c= onnect their project to that same published IETF or IRTF document.

In that case, would the coder then also be connected to the C= odeRequest so there are multiple ways to make the connections?

We would need search capabilities for coders looking for pro= jects 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 co= de (1 FTE for x weeks or months, etc.).

Any other comments?

Thank you,
Kathleen

On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambened= etti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for Co= deMatch has been defined. Please, find below the new version of such a data m= odel. We tried to incorporate the comments received in the list as well as t= he suggestions mentioned during the last meetings. Terms in this version are also aligned with the list of t= erms previously shared by Kathleen in the mailing list. Any feedback is welc= omed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop<= /a>




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop<= /a>

___________________________________________= ____
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/= codematch-develop
_______________________________________________
Codematch-develop mailing list
C= odematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop<= /a>





--

Best regards,
Kathleen


_______________________________________________
Codematch-deve= lop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailma= n/listinfo/codematch-develop

= --Apple-Mail-16741231-F3F3-4B3B-8AD3-913AE27C0566-- From nobody Wed Feb 25 06:24:22 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0251A1A20 for ; Tue, 24 Feb 2015 16:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCCDu9wpoYcc for ; Tue, 24 Feb 2015 16:11:35 -0800 (PST) Received: from mx0.rnp.br (mx0.rnp.br [IPv6:2001:12f0:b01:101::87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1F91A0076 for ; Tue, 24 Feb 2015 16:11:34 -0800 (PST) Received: from mailpxy01.rnp.br (mailpxy01.rnp.br [200.130.35.8]) by mx0.rnp.br (8.14.3/8.14.3/Debian-9.4) with ESMTP id t1P0BKLq013886; Tue, 24 Feb 2015 21:11:20 -0300 Received: from mailmbs02.rnp.br (zeus.na-df.rnp.br [200.130.35.1]) by mailpxy01.rnp.br (Postfix) with ESMTP id 928752C2337; Tue, 24 Feb 2015 21:11:19 -0300 (BRT) Date: Tue, 24 Feb 2015 21:11:19 -0300 (BRT) From: Wanderson Paim de Jesus To: Kathleen Moriarty Message-ID: <305493615.747297.1424823079481.JavaMail.root@rnp.br> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_747296_1423922369.1424823079479" X-Mailer: Zimbra 7.2.5_GA_2906 (ZimbraWebClient - GC40 (Win)/7.2.5_GA_2906) X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: saida, @@RPTN) X-CanIt-Incident-Id: 01NUobkjL X-CanIt-Geo: ip=200.130.35.1; country=BR; latitude=-23.5477; longitude=-46.6358; http://maps.google.com/maps?q=-23.5477,-46.6358&z=6 X-CanItPRO-Stream: saida X-Canit-Stats-ID: 01NUobkjL - 15d6dc321025 X-Scanned-By: CanIt (www . roaringpenguin . com) on 200.130.35.135 Archived-At: X-Mailman-Approved-At: Wed, 25 Feb 2015 06:24:21 -0800 Cc: codematch-develop@ietf.org, Lisandro Zambenedetti Granville , Kathleen Moriarty , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:11:40 -0000 ------=_Part_747296_1423922369.1424823079479 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Kathleen,=20 I'm afraid saying, but I had not planned attending the IETF in Dallas and I= 'm not aware about Code Sprint.=20 If it is possible, after the Code Sprint such other collaborators could sen= d me the tools and manuals about the Codetracker.=20 Best regards,=20 ----- Mensagem original ----- De: "Kathleen Moriarty" =20 Para: "Wanderson Paim de Jesus" =20 Cc: "Christian O'Flaherty" , "Kathleen Moriarty" , codematch-develop@ietf.org, "Lisandro Zambenedetti G= ranville" =20 Enviadas: Segunda-feira, 23 de fevereiro de 2015 11:46:59=20 Assunto: Re: [Codematch-develop] CodeMatch data model v3=20 Wanderson,=20 We are glad to have your assistance!=20 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 abl= e 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 Cod= e Sprint.=20 Thank you,=20 Kathleen=20 On Mon, Feb 23, 2015 at 7:14 AM, Wanderson Paim de Jesus < wanderson.jesus@= rnp.br > wrote:=20 Hi Kathleen,=20 I find Codematch a good idea and hope being able to contribute with its suc= cess.=20 Christian seems to be interest in coding too. Given that I'm not familiar w= ith datatracker, his support would be honestly welcome.=20 Best regards,=20 Wanderson=20 De: "Kathleen Moriarty" < kathleen.moriarty.ietf@gmail.com >=20 Para: "Lisandro Zambenedetti Granville" < granville@inf.ufrgs.br >=20 Cc: "Christian O'Flaherty" < oflaherty@isoc.org >, "Kathleen Moriarty" < ka= thleen.moriarty@emc.com >, codematch-develop@ietf.org , "Wanderson Paim de = Jesus" < wanderson.jesus@rnp.br >=20 Enviadas: Sexta-feira, 20 de fevereiro de 2015 13:23:51=20 Assunto: Re: [Codematch-develop] CodeMatch data model v3=20 On Fri, Feb 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville < granvill= e@inf.ufrgs.br > wrote:=20
Dear all=20 Wanderson Paim (cc=E2=80=99ed in this message), who develop the prototype a= vailable at http://codematch.inf.ufrgs.br is also a volunteer to code the C= odeMatch backend.=20 Excellent, it's great to have you on the team Wanderson! Thank you for volu= nteering!=20 Best regards,=20 Kathleen=20
Best regards,=20 Lisandro=20
Em 17/02/2015, =C3=A0(s) 15:19, Christian O'Flaherty < oflaherty@isoc.org >= escreveu:=20
I have a couple more volunteers for coding as well lined up. There may be m= ore decisions to be made for that and prep for developers to get familiar w= ith the datatracker and how it will be accessed.=20
Although I never used datatracker as a coder I would like to be among the i= nitial volunteers for coding.=20 Christian=20
Thank you,=20 Kathleen=20
Christian=20
Thank you,=20 Kathleen=20 Sent from my iPhone=20 On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" < granville@= inf.ufrgs.br > wrote:=20
Hello Kathleen=20 I=E2=80=99m not an expert on data models, so I may be wrong. Today, CodeMat= ch is a relationship between Project and CodeRequest. I believe it is not p= ossible to have another relationship between Project and Specification name= d CodeMatch too. But let me ask you if you agree with the suggestion of =E2= =80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is the pe= rson responsible for helping in the development of active projects=E2=80=9D= , implying that mentors have no role in already finished projects? In that = way, we don=E2=80=99t need to change the data model. Not that we could not = change it, but I believe keeping it simple is important.=20 Best regards,=20 Lisandro=20
Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen < kathleen.moriarty@emc.= com > escreveu:=20 Hi,=20 Sent from my iPhone=20 On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" < oflaherty@isoc.org >= wrote:=20
Hi Kathleen,=20
To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=E2=80=99s because (additional?) code is required. = To help in the development of new code throughout new projects, mentors see= m to be mandatory.=20
I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "coding" help if the student has some support to do that work.=20
Good point.=20
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.=20
In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification. This let's us keep the te= rms and model simple which may be easier for users as they will have less t= o understand in terms of our terminology. Also keeping the data model simpl= er should help reduce coding efforts.=20
However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=E2=80=99t need a mentor, of course, but the new projects d= o. But because mentors are associated with CodeRequest (and not with projec= t), 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 alway= s have a mentor once new projects are required.=20
If the link is to the same draft, but I suspect this will happen more with = draft revisions or drafts that extend base specifications.=20
The whole issue resides in the fact that mentors are associated with CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e in the model). Here, we have some options:=20
Yes, you are correct and I think my updated suggestion fixes this, but let = me know if I missed anything.=20
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 men= tor will be assigned, and the finished project will inherit that new real m= entor.=20 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here.=20
A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other RFCs, etc= . with no mentor.=20
Or just to have two options for CodeMatches - with or without a CodeRequest= .=20 Thanks!=20 Kathleen=20
Christian=20
Another option is checking how we tell the story. The question may be solve= d if we say that =E2=80=9Cmentors exist to help in the development of new p= rojects=E2=80=9D, implying that already finished projects has now associati= on with current mentors. Too simplistic?=20 Best regards,=20 Lisandro=20
Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty < kathleen.moriarty.ietf@= gmail.com > escreveu:=20 Lisandro,=20 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 hav= ing a mentor. You would still have a coder or the project owner that create= s the link and it would be possible for others to connect their project to = that same published IETF or IRTF document.=20 In that case, would the coder then also be connected to the CodeRequest so = there are multiple ways to make the connections?=20 We would need search capabilities for coders looking for projects so they m= ight only see ones that have a mentor and I'm sure they would want to be ab= le to restrict their view to the projects they have time to code (1 FTE for= x weeks or months, etc.).=20 Any other comments?=20 Thank you,=20 Kathleen=20 On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambenedetti Granville < granville= @inf.ufrgs.br > wrote:=20
Dear all=20 After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed.=20 Best regards,=20 Lisandro=20 =20 _______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
--=20 Best regards,=20 Kathleen=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
_______________________________________________=20 Codematch-develop mailing list=20 Codematch-develop@ietf.org=20 https://www.ietf.org/mailman/listinfo/codematch-develop=20
--=20 Best regards,=20 Kathleen=20
--=20 Best regards,=20 Kathleen=20 --=20 Wanderson=20 ------=_Part_747296_1423922369.1424823079479 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>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, afte= r the Code Sprint such other collaborators could send me the tools and manu= als about the Codetracker.

Best regards,

De: "Kathleen = Moriarty" <kathleen.moriarty.ietf@gmail.com>
Para: "Wanders= on Paim de Jesus" <wanderson.jesus@rnp.br>
Cc: "Christian O= 'Flaherty" <oflaherty@isoc.org>, "Kathleen Moriarty" <kathleen.mor= iarty@emc.com>, codematch-develop@ietf.org, "Lisandro Zambenedetti Granv= ille" <granville@inf.ufrgs.br>
Enviadas: Segunda-feira, 23 = de fevereiro de 2015 11:46:59
Assunto: Re: [Codematch-develop] Co= deMatch data model v3

Wanderson,

We are glad to have your assistance!

Dave Walterm= ire 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 h= elp 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 da= tatracker.  Please let me know if you need more information on the Cod= e Sprint.

Thank you,
Kathleen

On Mon, Feb 23, = 2015 at 7:14 AM, Wanderson Paim de Jesus <wanderson.jesus@rnp.br&= gt; wrote:
=
= Hi Kathleen,
<= br>
I find Cod= ematch a good idea and hope being able to contribute with its success.

<= div>Christian seems to be inter= est in coding too. Given that I'm not familiar with datatracker, his suppor= t would be honestly welcome.

Best regards,

Wan= derson

De: "Kathleen Moriarty" <kathleen.moriarty.ietf@gmail.co= m>
Para: "Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br= >
Cc: "Christian O'Flaherty" <oflaherty@isoc.org>, "Kathleen Moriarty" = <kathleen= .moriarty@emc.com>, codematch-develop@ietf.org, "Wanderson Paim de Jesus" &= lt;wanderson.je= sus@rnp.br>
Enviadas: Sexta-feira, 20 de fevereiro de 2015= 13:23:51
Assunto: Re: [Codematch-develop] CodeMatch data model v= 3




On Fri, Feb 20, 2015 at 6:23 AM, Lisand= ro Zambenedetti Granville <granville@inf.ufrgs.br> wrot= e:
De= ar all

Wanderson Paim (cc=E2=80=99ed in this message), w= ho develop the prototype available at http://codematch.inf.ufrgs.br is also a vol= unteer to code the CodeMatch backend.

Excellent, it's great to have you on the team Wanderson!  Thank= you for volunteering!

Best regards,
Kat= hleen 

Best regards,

Lisandr= o

Em 17/02/2015, =C3=A0(s) 15:19, Chris= tian O'Flaherty <oflaherty@isoc.org> escreveu:



I have a couple more volunteers for coding as well lined up.  The= re 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 i= nitial 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" <granville@inf.ufrgs.br= > wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone
Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s seem to be mandatory.

I agree with Lisandro's reasoning. If there's a code-match, it's becau= se 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 requ= est, thereby no need to provide a shepherd. They could be just "code opport= unity" and there's no commitment from anyone for those code-matches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e burden here.

A third option could be to have active "code-requests" with mentors an= d "code-opportunities" (or a better name) for finished projects, other &nbs= p;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 =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> 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.&nb= sp; 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 FT= E for x weeks or months, etc.).

Any other comments?

Thank you,
Kathleen

On Sat, Feb 7, 2015 at 3:24 AM, Lisandro Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop



--

Bes= t regards,
Kathleen



=

--

<= div>Best regards,
Kathleen



--
Wanderson

------=_Part_747296_1423922369.1424823079479-- From nobody Wed Feb 25 06:30:01 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9F31A1B4A for ; Wed, 25 Feb 2015 06:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziqI29L6R4ZC for ; Wed, 25 Feb 2015 06:29:56 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6512A1A1B2D for ; Wed, 25 Feb 2015 06:29:54 -0800 (PST) Received: by labge10 with SMTP id ge10so4169099lab.12 for ; Wed, 25 Feb 2015 06:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uVNHOpZU7VjFifDE1qyI0Z7kNvqh25edI6eoNZP7h/s=; b=IMcODbmKyRJCOQpbi9y0KWNbPtSKbxxxgop9ke2EE5tG8yvEKhqOGjh+P5pdrEw6yA /yqokdtrWuB0R5GnaGkXgbdvGSJAit5KGFLP8h1isOHILsLQwqIq3I0Y6gVEsJTtaATC Zj61T/vD/ZuU09aa9T9vM9NIU5u+/ADzLAxzuq8tkBL0i7ZruGqg6kr4O+dbDmfm/Xd0 ePZmvE/SDXpF/wmNSfljSkPbw7g49AwseTh1e1aBc8ebFhrCwSPpmd9uGmLMQpC6xPsj VZe9MOtwJvl0yGWIy+bu+gG0q4/3AFgznaYoczchLKz185Mhtpg/ZJigygpigj2Ntl0Y 2qMg== MIME-Version: 1.0 X-Received: by 10.152.36.138 with SMTP id q10mr2890762laj.113.1424874592579; Wed, 25 Feb 2015 06:29:52 -0800 (PST) Received: by 10.112.167.101 with HTTP; Wed, 25 Feb 2015 06:29:52 -0800 (PST) In-Reply-To: <305493615.747297.1424823079481.JavaMail.root@rnp.br> References: <305493615.747297.1424823079481.JavaMail.root@rnp.br> Date: Wed, 25 Feb 2015 09:29:52 -0500 Message-ID: From: Kathleen Moriarty To: Wanderson Paim de Jesus Content-Type: multipart/alternative; boundary=089e0160b922f0b736050fea7769 Archived-At: Cc: "codematch-develop@ietf.org" , Lisandro Zambenedetti Granville , Kathleen Moriarty , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 14:30:00 -0000 --089e0160b922f0b736050fea7769 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 < wanderson.jesus@rnp.br> 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" > *Para: *"Wanderson Paim de Jesus" > *Cc: *"Christian O'Flaherty" , "Kathleen Moriarty" < > kathleen.moriarty@emc.com>, codematch-develop@ietf.org, "Lisandro > Zambenedetti Granville" > *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 wil= l > 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 < > wanderson.jesus@rnp.br> 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 familia= r >> with datatracker, his support would be honestly welcome. >> >> Best regards, >> >> Wanderson >> >> ------------------------------ >> *De: *"Kathleen Moriarty" >> *Para: *"Lisandro Zambenedetti Granville" >> *Cc: *"Christian O'Flaherty" , "Kathleen Moriarty" < >> kathleen.moriarty@emc.com>, codematch-develop@ietf.org, "Wanderson Paim >> de Jesus" >> *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 < >> granville@inf.ufrgs.br> wrote: >> >>> Dear all >>> >>> Wanderson Paim (cc=E2=80=99ed in this message), who develop the prototy= pe >>> 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, =C3=A0(s) 15:19, Christian O'Flaherty >>> 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 ge= t >>> 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" < >>> granville@inf.ufrgs.br> wrote: >>> >>> Hello Kathleen >>> >>> I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch >>> 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 suggestio= n of >>> =E2=80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is= the person responsible for >>> helping in the development of active projects=E2=80=9D, implying that m= entors have >>> no role in already finished projects? In that way, we don=E2=80=99t nee= d 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, =C3=A0(s) 14:52, Moriarty, Kathleen < >>> kathleen.moriarty@emc.com> escreveu: >>> >>> Hi, >>> >>> Sent from my iPhone >>> >>> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" >>> wrote: >>> >>> Hi Kathleen, >>> >>> To me, a CodeRequest is an explicit call for FUTURE developments. If >>> someone is questing code, that=E2=80=99s because (additional?) code is = required. To >>> help in the development of new code throughout new projects, mentors se= em >>> 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 wil= l >>> 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 "cod= e >>> opportunity" and there's no commitment from anyone for those code-match= es. >>> >>> >>> 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 w= ill >>> 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: th= ere >>> is a CodeRequest for an specific protocol. That CodeRequest already fin= ds >>> previously finished projects but still requires further code. In that c= ase, >>> the previous projects don=E2=80=99t need a mentor, of course, but the n= ew 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 ment= or >>> 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 projec= ts >>> (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, othe= r >>> 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 =E2=80=9Cmentors exist to help in the development= of new >>> projects=E2=80=9D, implying that already finished projects has now asso= ciation with >>> current mentors. Too simplistic? >>> >>> Best regards, >>> >>> Lisandro >>> >>> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> 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 feedba= ck >>> 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 pro= ject >>> without having a mentor. You would still have a coder or the project o= wner >>> that creates the link and it would be possible for others to connect th= eir >>> 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 wan= t 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 < >>> granville@inf.ufrgs.br> 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 mo= del. >>>> We tried to incorporate the comments received in the list as well as t= he >>>> suggestions mentioned during the last meetings. Terms in this version = are >>>> also aligned with the list of terms previously shared by Kathleen in t= he >>>> mailing list. Any feedback is welcomed. >>>> >>>> Best regards, >>>> >>>> Lisandro >>>> >>>> >>>> >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>> >>>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >>> >>> >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >>> >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >>> >>> >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >>> >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> >> > > > -- > > Best regards, > Kathleen > > > > -- > Wanderson > --=20 Best regards, Kathleen --089e0160b922f0b736050fea7769 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Wanderson,

Yes, I am sure we will = be able to help you and other volunteer developers figure out how to get st= arted and to work as a team without having to attend Dallas.

=
Thank you.



--

Bes= t regards,
Kathleen



=

--

Best regards,
Kathleen


--
Wanderson<= /tbody>

<= /div>


--=

Best regards,=
Kathleen
--089e0160b922f0b736050fea7769-- From nobody Wed Feb 25 07:18:59 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA271A1A8A for ; Wed, 25 Feb 2015 07:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNVbgCb-R1r5 for ; Wed, 25 Feb 2015 07:18:54 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29FA1A040C for ; Wed, 25 Feb 2015 07:18:53 -0800 (PST) Received: by labge10 with SMTP id ge10so4504650lab.12 for ; Wed, 25 Feb 2015 07:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q/xzXNa4RM5RiIFq/bH1AxZV9a4iEJnxx1aT1sS6jx8=; b=ipm55tHD6mTpm84ihVjYpGSt6zx4SRWmjsY4VgPZMM3EGUFgh3FGipwH6b2lDCeNo+ P/BG78bWUrkuynbJ+pWx3+QvXDNKzlTeU0wlXQV7OZfbMjafjRgvbUyNFpdaNHnOudCL pNaZeHioAd5ITLuMDF+xYR1U/1X3AaBtqfB6WEL7c0WL5TdvZ9gO7MGpqfocb7ADr6ZQ tQh8BwObeddqJL0CPE+TWAWidtxxn2/Pg0mBTRS6s7p++63jYq2uSwoP24ILvSQbxrHe Tr6BVP+we8u4y3H0mjbp8odeTy7ybXbXS/xENP5Yfm6jIhOg9bvSLa4otqK7Oq5nJ28t BJbg== MIME-Version: 1.0 X-Received: by 10.112.181.41 with SMTP id dt9mr3360781lbc.56.1424877532141; Wed, 25 Feb 2015 07:18:52 -0800 (PST) Received: by 10.112.167.101 with HTTP; Wed, 25 Feb 2015 07:18:51 -0800 (PST) In-Reply-To: <6DAA1C7D-E7D2-4057-A0DB-9438D5755A2D@emc.com> References: <4EA681E4-D2EA-49C4-A13C-E99D39C76836@inf.ufrgs.br> <546A6D5E.6060107@nostrum.com> <6BC13B4B-1E5D-4328-95F0-44DAA5B111C9@inf.ufrgs.br> <5CB9D848-1273-434E-9929-831467FEFB8B@inf.ufrgs.br> <623A4EC4-2BE0-4C33-AE8E-78F94D0DB6DB@emc.com> <76D13C79-3012-4912-AFDF-B791EC321075@emc.com> <92025554-3B11-4A84-8C12-52EAF679E519@gmail.com> <6DAA1C7D-E7D2-4057-A0DB-9438D5755A2D@emc.com> Date: Wed, 25 Feb 2015 10:18:51 -0500 Message-ID: From: Kathleen Moriarty To: "Moriarty, Kathleen" Content-Type: multipart/alternative; boundary=001a11c3698626df39050feb272a Archived-At: Cc: Lisandro Zambenedetti Granville , "codematch-develop@ietf.org" , Christian O'Flaherty Subject: Re: [Codematch-develop] CodeMatch data model v3 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 15:18:58 -0000 --001a11c3698626df39050feb272a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 < kathleen.moriarty@emc.com> wrote: > Hi Lisandro, > > Sent from my iPhone > > On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" < > granville@inf.ufrgs.br> 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 proje= ct > 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 th= e > CodeRequest is only meaningful for active projects, since already finishe= d > projects don=E2=80=99t 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" < >> granville@inf.ufrgs.br> wrote: >> >> Hello Kathleen >> >> I=E2=80=99m not an expert on data models, so I may be wrong. Today, Cod= eMatch >> 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 >> =E2=80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is = the person responsible for >> helping in the development of active projects=E2=80=9D, implying that me= ntors have >> no role in already finished projects? In that way, we don=E2=80=99t need= to change >> the data model. Not that we could not change it, but I believe keeping i= t >> simple is important. >> >> Best regards, >> >> Lisandro >> >> Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen < >> kathleen.moriarty@emc.com> escreveu: >> >> Hi, >> >> Sent from my iPhone >> >> On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" >> wrote: >> >> Hi Kathleen, >> >> To me, a CodeRequest is an explicit call for FUTURE developments. If >> someone is questing code, that=E2=80=99s because (additional?) code is r= equired. To >> help in the development of new code throughout new projects, mentors see= m >> 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-matche= s. >> >> >> In looking at the data model again, how about having the CodeMatch >> either be a fulfilled CodeRequest mapping a project to a specification o= r >> simply the connection between a project and specification. This let's u= s >> keep the terms and model simple which may be easier for users as they wi= ll >> have less to understand in terms of our terminology. Also keeping the d= ata >> 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: the= re >> is a CodeRequest for an specific protocol. That CodeRequest already find= s >> previously finished projects but still requires further code. In that ca= se, >> the previous projects don=E2=80=99t need a mentor, of course, but the ne= w 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 mento= r >> 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 project= s >> (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 w= ith >> the idea that once additional code is needed for those CodeRequests, a r= eal >> 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 RF= Cs, >> 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 =E2=80=9Cmentors exist to help in the development = of new >> projects=E2=80=9D, implying that already finished projects has now assoc= iation with >> current mentors. Too simplistic? >> >> Best regards, >> >> Lisandro >> >> Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> 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 feedbac= k >> 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 (o= pen >> source or proprietary) of existing RFCs, there should be flexibility to >> demonstrate links between a CodeRequest (in this case an RFC) and a proj= ect >> without having a mentor. You would still have a coder or the project ow= ner >> that creates the link and it would be possible for others to connect the= ir >> 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 < >> granville@inf.ufrgs.br> 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 mod= el. >>> We tried to incorporate the comments received in the list as well as th= e >>> suggestions mentioned during the last meetings. Terms in this version a= re >>> also aligned with the list of terms previously shared by Kathleen in th= e >>> mailing list. Any feedback is welcomed. >>> >>> Best regards, >>> >>> Lisandro >>> >>> >>> >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> >> >> > > > -- > > Best regards, > Kathleen > > > > --=20 Best regards, Kathleen --001a11c3698626df39050feb272a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lisandro,

I reached out to Pete Resn= ick, one of the Apps directors to see what he thought.

=
He does agree that something is missing.

I th= ink we can handle this in a few ways.=C2=A0 We need to be able to different= iate when code is requested from when a link is being made as the informati= on on each will be different. =C2=A0

The data mode= l would need a few elements to be optional, like mentor, resources (estimat= ed level of effort for coding).=C2=A0 You usually see this when there is ac= companying UML.

Pete suggested a different name fo= r CodeRequest, maybe MatchRequest with an element for CodeRequest?=C2=A0 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 MatchR= equest 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 <kathleen.moriarty@emc.com> wro= te:
Hi Lisandro,

Sent from my iPhone

On Feb 24, 2015, at 5:41 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf= .ufrgs.br> 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 li= ne is included to show the code request isn't needed to link a project = to a specification.=C2=A0 That and examples will help developers as we proc= eed.

Hello Kathleen

Just to clarify: a CodeRequest is still needed to link projects to a s= pecification. The data model is not missing a link between projects and spe= cifications; projects are are linked to specifications only through a CodeR= equest. What we have discussed so far is that the mentor field in the CodeRequest is only meaningful for act= ive projects, since already finished projects don=E2=80=99t need a mentor a= nymore.

 Let's chat about this tomorrow as I still don't see why a direct co= nnection between a project and specification can't be made.=C2=A0 Maybe= it's to have a grouping, but I'd like to talk through this a bit.= =C2=A0 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" &l= t;granville@inf= .ufrgs.br> wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone
Hi Kathleen,=C2=A0

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s 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 su= pport to do that work.

Good point.

We can have a different instance for those cases were there is no requ= est, thereby no need to provide a shepherd. They could be just "code o= pportunity" and there's no commitment from anyone for those code-m= atches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification.=C2=A0 This let's us k= eep the terms and model simple which may be easier for users as they will have less to understand in terms of our t= erminology.=C2=A0 Also keeping the data model simpler should help reduce co= ding efforts.

=C2=A0

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e 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 =C2=A0RFCs, etc. with no mentor.=C2=A0
Or just to have two options for CodeMatches - with or without a CodeRequest= .

Thanks!
Kathleen=C2=A0


Christian


Another option is checking how we tell the story. The question may be = solved if we say that =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model with the = team!=C2=A0 This looks great from what we discussed.=C2=A0 From additional = feedback received from the IESG, the point was made that you may not always= have a shepherd.=C2=A0 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.=C2= =A0 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop





--

Best regards,
Kathleen





--

Best regards,
Kath= leen
--001a11c3698626df39050feb272a-- From nobody Wed Feb 25 08:06:06 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A781A9120 for ; Wed, 25 Feb 2015 08:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEuEQqdwSR1N for ; Wed, 25 Feb 2015 08:06:00 -0800 (PST) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D68F1A1AFF for ; Wed, 25 Feb 2015 08:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424880347; bh=BMXM4OkFgfPlFMCxRemMymsSn7BNjMVAqkLOV+pbMns=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=L8npGZOxSwM0dgpbbE9ruQYpIJYfPdZiEfxaxmppYoc1Gl40zULJ+7OYfvm8j7J4TT1A0i/lxMIoLThcXnP0YhfXej0uhDmfqTBMj/1mPDSlMmfqv4wiG513RPCWs2teCdRQdWRJ0QttE6s37gHyNPu7jCWfc88j5OhVc4iVx/aCXz7jWs/ShrbCu0AXlcVHDH+ZeWCWeLscVuL9/qaUZjQA6nnmmFSWbFkxfAFGTzZiSzqN3Ai2qURLlrWvU3Wza/9CKuS6LT/JDiMeYsYh8hWLLxIu9vUZRXEJxojRKyN9lD5us5TY5AaP+dsIfCLCwx1N7Dq66Q3nJitboD9H7A== Received: from [98.139.215.141] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2015 16:05:47 -0000 Received: from [98.139.212.220] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2015 16:05:47 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 25 Feb 2015 16:05:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 292565.29319.bm@omp1029.mail.bf1.yahoo.com X-YMail-OSG: SPGf6jkVM1lKO3Q7BjaxNoUuzT4kOIOAJfFfJ_iSYXJxGNau53Qtmm31uWQbC_q 1v0oiAM0.iJv7jvE8BkB3JkeCWdMgzawQZrVy2dI1SRihgpmvUW2e1MVB.vq4LCDtAlREZwdgLfS eXq3z.4oWBclPleFXkbrPo5mKmI5Un3VdWLHXFRJJQEu4Z2bwPXp7vK4j0EZooxpCjctSAz_fx.8 SB8Rt8dPGIf17zUvPUvp15IDizHpj.hSRvbcmhXO5D_77sZJl5yFdRMhYOM8VHZHK7Yz9kvoXTEm czpkn8NK2Nv.4rHkatL6SeXuB851n6_gAsMZogi4zekyj11u5e2d34OSNUQeGIgH.X2i2aLRvr1d sp8VWceJ9UoGmZEC04OxETjPlnt1YAnpq4jLuVaMVNfk4rhSf2szw_gXpPC63ea.UUw.zPFdi8d. KKK28wYHzTAwAna0VnKi9fbWQDbl2XSOBTD0zbM.KCET0bmJ8tCQjAhlNDPftYCxdhvLEu_RyXkh 1yg-- Received: by 66.196.80.126; Wed, 25 Feb 2015 16:05:46 +0000 Date: Wed, 25 Feb 2015 16:05:45 +0000 (UTC) From: Kristin Burgh To: "codematch-develop@ietf.org" Message-ID: <197991328.6842775.1424880345698.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6842771_360133178.1424880345642" Archived-At: Subject: Re: [Codematch-develop] Codematch-develop Digest, Vol 8, Issue 22 X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kristin Burgh List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 16:06:04 -0000 ------=_Part_6842771_360133178.1424880345642 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good Morning/Afternoon/Evening Everyone -=C2=A0 I just wanted to let everyone know that I'll be sending out an updated vers= ion of the card-sort survey over this coming weekend. =C2=A0The aim is to b= e 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 e= mail thread or directly via "kmburgh@yahoo.com". 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,=C2=A0 Kristin=C2=A0 From: "codematch-develop-request@ietf.org" To: codematch-develop@ietf.org=20 Sent: Wednesday, February 25, 2015 9:30 AM Subject: Codematch-develop Digest, Vol 8, Issue 22 =20 ----- Forwarded Message ----- Send Codematch-develop mailing list submissions to =C2=A0=C2=A0=C2=A0 codematch-develop@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/codematch-develop or, via email, send a message with subject or body 'help' to =C2=A0=C2=A0=C2=A0 codematch-develop-request@ietf.org You can reach the person managing the list at =C2=A0=C2=A0=C2=A0 codematch-develop-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Codematch-develop digest..." Today's Topics: =C2=A0 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 f= igure 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 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 sen= d me the tools and manuals about the Codetracker. Best regards, De: "Kathleen Moriarty" Para: "Wanderson Paim de Jesus" Cc: "Christian O'Flaherty" , "Kathleen Moriarty" , codematch-develop@ietf.org, "Lisandro Zambenedetti G= ranville" 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.=C2=A0 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 Sat= urday before the meeting as you'll get the tools to install and learn more = about the datatracker.=C2=A0 Please let me know if you need more informatio= n on the Code Sprint. Thank you,Kathleen On Mon, Feb 23, 2015 at 7:14 AM, Wanderson Paim de Jesus wrote: Hi Kathleen, I find Codematch a good idea and hope being able to contribute with its suc= cess. Christian seems to be interest in coding too. Given that I'm not familiar w= ith datatracker, his support would be honestly welcome. Best regards, Wanderson De: "Kathleen Moriarty" Para: "Lisandro Zambenedetti Granville" Cc: "Christian O'Flaherty" , "Kathleen Moriarty" , codematch-develop@ietf.org, "Wanderson Paim de Jesus= " 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 wrote: Dear all Wanderson Paim (cc=E2=80=99ed in this message), who develop the prototype a= vailable at http://codematch.inf.ufrgs.br=C2=A0is also a volunteer to code = the CodeMatch backend. Excellent, it's great to have you on the team Wanderson!=C2=A0 Thank you fo= r volunteering! Best regards,Kathleen=C2=A0 Best regards, Lisandro Em 17/02/2015, =C3=A0(s) 15:19, Christian O'Flaherty e= screveu: I have a couple more volunteers for coding as well lined up.=C2=A0 There ma= y be more decisions to be made for that and prep for developers to get fami= liar with the datatracker and how it will be accessed. Although I never used datatracker as a coder I would like to be among the i= nitial volunteers for coding.=C2=A0 Christian=C2=A0 Thank you,Kathleen=C2=A0 Christian Thank you,Kathleen=C2=A0 Sent from my iPhone On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" wrote: Hello Kathleen I=E2=80=99m not an expert on data models, so I may be wrong. Today, CodeMat= ch is a relationship between Project and CodeRequest. I believe it is not p= ossible to have another relationship between Project and Specification name= d CodeMatch too. But let me ask you if you agree with the suggestion of =E2= =80=9Cfixing=E2=80=9D this issue by saying that =E2=80=9Ca Mentor is the pe= rson responsible for helping in the development of active projects=E2=80=9D= , implying that mentors have no role in already finished projects? In that = way, we don=E2=80=99t 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, =C3=A0(s) 14:52, Moriarty, Kathleen escreveu: Hi, Sent from my iPhone On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" w= rote: Hi Kathleen,=C2=A0 To me, a CodeRequest is an explicit call for FUTURE developments. If someon= e is questing code, that=E2=80=99s because (additional?) code is required. = To help in the development of new code throughout new projects, mentors see= m to be mandatory. I agree with Lisandro's reasoning. If there's a code-match, it's because so= meone did a code request. Someone needed that code and he will get the appr= opriate "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 b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification.=C2=A0 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.=C2=A0 Also keeping the data= model simpler should help reduce coding efforts. =C2=A0 However, if you want to advertise projects that already finished, mentors m= ake not sense indeed. But consider the following situation: there is a Code= Request for an specific protocol. That CodeRequest already finds previously= finished projects but still requires further code. In that case, the previ= ous projects don=E2=80=99t need a mentor, of course, but the new projects d= o. But because mentors are associated with CodeRequest (and not with projec= t), 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 alway= s 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 CodeRe= quest. Previously, mentors were associated with individual projects (at tha= t point we were referring projects to as CodeMatches, before the last chang= e 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 men= tor will be assigned, and the finished project will inherit that new real m= entor. 2) Rollback the model back to associate mentors with projects, indicating t= hat mentors are optional. However, we may be imposing an administrative bur= den here. A third option could be to have active "code-requests" with mentors and "co= de-opportunities" (or a better name) for finished projects, other =C2=A0RFC= s, etc. with no mentor.=C2=A0 Or just to have two options for CodeMatches - with or without a CodeRequest= . Thanks!Kathleen=C2=A0 Christian Another option is checking how we tell the story. The question may be solve= d if we say that =E2=80=9Cmentors exist to help in the development of new p= rojects=E2=80=9D, implying that already finished projects has now associati= on with current mentors. Too simplistic? Best regards, Lisandro Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty escreveu: Lisandro, Thank you for your time and effort developing the data model with the team!= =C2=A0 This looks great from what we discussed.=C2=A0 From additional feedb= ack received from the IESG, the point was made that you may not always have= a shepherd.=C2=A0 If we want this to also advertise existing implementatio= ns (open source or proprietary) of existing RFCs, there should be flexibili= ty to demonstrate links between a CodeRequest (in this case an RFC) and a p= roject without having a mentor.=C2=A0 You would still have a coder or the p= roject owner that creates the link and it would be possible for others to c= onnect 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 m= ight only see ones that have a mentor and I'm sure they would want to be ab= le 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 wrote: Dear all After one of our last meetings, a new data model (v3) for CodeMatch has bee= n defined. Please, find below the new version of such a data model. We trie= d to incorporate the comments received in the list as well as the suggestio= ns mentioned during the last meetings. Terms in this version are also align= ed with the list of terms previously shared by Kathleen in the mailing list= . Any feedback is welcomed. Best regards, Lisandro _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --=20 Best regards,Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop --=20 Best regards,Kathleen --=20 Best regards,Kathleen --=20 Wanderson --=20 Best regards,Kathleen _______________________________________________ Codematch-develop mailing list Codematch-develop@ietf.org https://www.ietf.org/mailman/listinfo/codematch-develop ------=_Part_6842771_360133178.1424880345642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<= /div>
Good Morning/Afternoon/Evening Everyone -&nb= sp;

I just wanted to let everyone= know that I'll be sending out an updated version of the card-sort survey o= ver this coming weekend.  The aim is to be able to have as much feedba= ck 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 "kmburgh@yahoo.com".

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, 

Kri= stin
 


From: "codematch-develop-= request@ietf.org" <codematch-develop-request@ietf.org>
To: codematch-develop@ietf.org
= Sent: Wednesday, February = 25, 2015 9:30 AM
Subject:<= /b> Codematch-develop Digest, Vol 8, Issue 22

----- Forwarded Message -----

Send Codematc= h-develop mailing list submissions to
    codematch-develop@ietf.org

To subscribe or unsubscribe via the= World Wide Web, visit
    https://www.ietf.or= g/mailman/listinfo/codematch-develop
or, via email, send a message w= ith subject or body 'help' to
    codematch-develop-request@ietf.org

You can reach the p= erson managing the list at
    codematch-develop-owner@ietf.org

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

Today's Topics:

  1. Re: CodeMatch d= ata model v3 (Kathleen Moriarty)
Dear Wanderson,

Yes, I am sure we will be able to he= lp you and other volunteer developers figure out how to get started and to = work as a team without having to attend Dallas.

Th= ank you.

On Tue, Feb 24, 2015 at 7:11 PM, Wanderson Pa= im de Jesus <wanderson.jesus@rnp.br> wrote:
Dear Kathleen,<= /span>

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 collaborato= rs could send me the tools and manuals about the Codetracker.
<= div>
Best regards,

De: "Kathleen Moriarty" <kathleen.moriarty= .ietf@gmail.com>
Para: "Wanderson Paim de Jesus" <wanderson.jesus@rnp.br>
Cc: "Christian O'Flaherty" <ofl= aherty@isoc.org>, "Kathleen Moriarty" <kathleen.moriarty@emc.com>, codematch-develop@ietf.org, "Lisand= ro Zambenedetti Granville" <= granville@inf.ufrgs.br>
Enviadas: Segunda-feira, 23 de fev= ereiro 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 i= n Dallas and will be able to help us code, it may be a good idea to go to t= he Code Sprint Saturday before the meeting as you'll get the tools to insta= ll and learn more about the datatracker.  Please let me know if you ne= ed more information on the Code Sprint.

Thank you,=
Kathleen

=
On Mon, Feb 23, 2015 at 7:14 AM, Wa= nderson Paim de Jesus <wanderson.jesus@rnp.br> wrote:
Hi Kathleen,<= /span>

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 ho= nestly welcome.
Best re= gards,

Wanderson=

De: "Kathleen Moriarty" <kathleen.moriarty.ietf@= gmail.com>
Para: "Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br>
= Cc: "Christian O'Flaherty" <o= flaherty@isoc.org>, "Kathleen Moriarty" <kathleen.moriarty@emc.com>, codematch-develop@ietf.org, "Wan= derson Paim de Jesus" <wande= rson.jesus@rnp.br>
Enviadas: Sexta-feira, 20 de fevereiro = de 2015 13:23:51
Assunto: Re: [Codematch-develop] CodeMatch data = model v3




On Fri, Feb 20, 201= 5 at 6:23 AM, Lisandro Zambenedetti Granville <granville@inf.ufrgs.br>= wrote:
Dear all

Wanderson Paim (cc=E2=80=99ed= in this message), who develop the prototype available at http://codemat= ch.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

<= blockquote>
Em 17/02/2015, =C3=A0(s) 15:19, Christian O'Flaherty <oflaherty@isoc.org> escreveu:



I have a couple more volunteers for coding as well lined up.  The= re 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 i= nitial 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" <granville@inf.ufrgs.br> wrote:=

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escrev= eu:

Hi,

Sent from my iPhone

On Feb 13, 2015, at 11:13 AM, "Christian O'Flaherty" <oflaherty@isoc.org> wrote:

Hi Kathleen, 

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s seem to be mandatory.

I agree with Lisandro's reasoning. If there's a code-match, it's becau= se 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 requ= est, thereby no need to provide a shepherd. They could be just "code opport= unity" and there's no commitment from anyone for those code-matches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e 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 t= erminology.  Also keeping the data model simpler should help reduce co= ding efforts.

 

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e burden here.

A third option could be to have active "code-requests" with mentors an= d "code-opportunities" (or a better name) for finished projects, other &nbs= p;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 =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.ietf@gmai= l.com> 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.&nb= sp; 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 FT= E for x weeks or months, etc.).

Any other comments?

Thank you,
Kathleen

On Sat, Feb 7, 2015 at 3:24 AM, Lis= andro Zambenedetti Granville <granville= @inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
https://www.ietf.org/mailman/listinfo/codematch= -develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
https://www.ietf.org/mailman/listinfo/codematch= -develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop= @ietf.org
https://www.ietf.org/mailman/listinfo/cod= ematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.= org
https://www.ietf.org/mailman/listinfo/codematch= -develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop= @ietf.org
https://www.ietf.org/mailman/listinfo/cod= ematch-develop



--

Bes= t regards,
Kathleen



=

--

Best regards,
Kathleen



--
Wanderson




--

Best regards,
Kathleen

_______________________________________________
Codematc= h-develop mailing list
Codematch-develop@ietf.orghttps://www.ietf.org/mailman/listinfo/codematch-develop

------=_Part_6842771_360133178.1424880345642--

On Tue, Feb 24, 2015 at 7:11 PM, Wanderson Paim de Jesus <= span dir=3D"ltr"><wanderson.jesus@rnp.br> wrote:
Dear Kathleen,
I'm afraid saying, but I had not plann= ed attending the IETF in Dallas and I'm not aware about Code Sprint.

<= /font>
If = it is possible, after the Code Sprint such other collaborators could send m= e the tools and manuals about the Codetracker.

Best regards,

De: "Kathleen Moriarty" <kathleen.moriarty.ietf@gmail.com>
Para: "Wanderson Paim de Jesus" <wanderson.jesus@rnp.br&= gt;
Cc: "Christian O'Flaherty" <oflaherty@isoc.org>, "K= athleen Moriarty" <kathleen.moriarty@emc.com>, codematch-develop@ietf.org, &quo= t;Lisandro Zambenedetti Granville" <granville@inf.ufrgs.br>
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 ass= istance!

Dave Waltermire has also volunteered to h= elp code and we may have 1-2 other volunteers soon.=C2=A0 If anyone is atte= nding 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 ge= t the tools to install and learn more about the datatracker.=C2=A0 Please l= et me know if you need more information on the Code Sprint.

<= /div>
Thank you,
Kathleen

On Mon, Feb 23, 2015 at 7:14 AM, Wanderso= n Paim de Jesus <wanderson.jesus@rnp.br> wrote:
Hi Kathleen,
=

I find Codematch a good idea and ho= pe being able to contribute with its success.

Christian seems to be interest in coding too. Give= n that I'm not familiar with datatracker, his support would be honestly= welcome.

=
Best regards,=

Wanderson
=

De: "Kathleen Moriarty" <kathleen.moriarty.ietf@g= mail.com>
Para: "Lisandro Zambenedetti Granville"= ; <granville= @inf.ufrgs.br>
Cc: "Christian O'Flaherty" &l= t;oflaherty@isoc.or= g>, "Kathleen Moriarty" <kathleen.moriarty@emc.com>, codematch-develop@= ietf.org, "Wanderson Paim de Jesus" <wanderson.jesus@rnp.br>
Enviadas: Sexta-feira, 20 de fevereiro de 2015 13:23:51
Assunto:= Re: [Codematch-develop] CodeMatch data model v3




O= n Fri, Feb 20, 2015 at 6:23 AM, Lisandro Zambenedetti Granville <gr= anville@inf.ufrgs.br> wrote:
Dear all

Wanderson= Paim (cc=E2=80=99ed in this message), who develop the prototype available = at http://codem= atch.inf.ufrgs.br=C2=A0is also a volunteer to code the CodeMatch backen= d.

Excellent, it's great to= have you on the team Wanderson!=C2=A0 Thank you for volunteering!

Best regards,
Kathleen=C2=A0

Be= st regards,

Lisandro

Em 17/02/2015, =C3=A0(s) 15:19, Christian O'Flaherty <oflaherty@isoc.org>= escreveu:



I have a couple more volunteers for coding as well lined up.=C2=A0 The= re 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 i= nitial volunteers for coding.=C2=A0

Christian=C2=A0


Thank you,
Kathleen=C2=A0

Christian


Thank you,
Kathleen=C2=A0

Sent from my iPhone

On Feb 17, 2015, at 7:05 AM, "Lisandro Zambenedetti Granville" &l= t;granville@inf= .ufrgs.br> wrote:

Hello Kathleen

I=E2=80=99m not an expert on data models, so I may be wrong. Today, Co= deMatch 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 =E2=80=9Cfixing=E2=80=9D this = issue by saying that =E2=80=9Ca Mentor is the person responsible for helpin= g in the development of active projects=E2=80=9D, implying that mentors hav= e no role in already finished projects? In that way, we don=E2=80=99t need to change the data model. Not that we could not change it, but I believe k= eeping it simple is important.

Best regards,

Lisandro

Em 14/02/2015, =C3=A0(s) 14:52, Moriarty, Kathleen <kathleen.moriarty@emc.com> escreveu:

Hi,

Sent from my iPhone
Hi Kathleen,=C2=A0

To me, a CodeRequest is an explicit call for FUTURE developments. If s= omeone is questing code, that=E2=80=99s because (additional?) code is requi= red. To help in the development of new code throughout new projects, mentor= s 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 su= pport to do that work.

Good point.

We can have a different instance for those cases were there is no requ= est, thereby no need to provide a shepherd. They could be just "code o= pportunity" and there's no commitment from anyone for those code-m= atches.

In looking at the data model again, how about having the CodeMatch either b= e a fulfilled CodeRequest mapping a project to a specification or simply th= e connection between a project and specification.=C2=A0 This let's us k= eep the terms and model simple which may be easier for users as they will have less to understand in terms of our t= erminology.=C2=A0 Also keeping the data model simpler should help reduce co= ding efforts.

=C2=A0

However, if you want to advertise projects that already finished, ment= ors make not sense indeed. But consider the following situation: there is a= CodeRequest for an specific protocol. That CodeRequest already finds previ= ously finished projects but still requires further code. In that case, the previous projects don= =E2=80=99t need a mentor, of course, but the new projects do. But because m= entors are associated with CodeRequest (and not with project), once we defi= ne a mentor to help in the new projects that mentor will be also linked with the old projects too. In summary, old proj= ects 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 C= odeRequest. Previously, mentors were associated with individual projects (a= t 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 rea= l mentor will be assigned, and the finished project will inherit that new real mentor.

2) Rollback the model back to associate mentors with projects, indicat= ing that mentors are optional. However, we may be imposing an administrativ= e 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 =C2=A0RFCs, etc. with no mentor.=C2=A0
Or just to have two options for CodeMatches - with or without a CodeRequest= .

Thanks!
Kathleen=C2=A0


Christian


Another option is checking how we tell the story. The question may be = solved if we say that =E2=80=9Cmentors exist to help in the development of = new projects=E2=80=9D, implying that already finished projects has now asso= ciation with current mentors. Too simplistic?

Best regards,

Lisandro

Em 11/02/2015, =C3=A0(s) 23:17, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> escreveu:

Lisandro,

Thank you for your time and effort developing the data model with the = team!=C2=A0 This looks great from what we discussed.=C2=A0 From additional = feedback received from the IESG, the point was made that you may not always= have a shepherd.=C2=A0 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.=C2= =A0 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 CodeReques= t so there are multiple ways to make the connections?

We would need search capabilities for coders looking for projects so t= hey 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 Zambene= detti Granville <granville@inf.ufrgs.br> wrote:
Dear all

After one of our last meetings, a new data model (v3) for CodeMatch ha= s 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 sugg= estions 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 w= elcomed.

Best regards,

Lisandro

<codematchv3-3.png>

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




--

Best regards,
Kathleen

_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop
_______________________________________________
Codematch-develop mailing list
Codematch-d= evelop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codem= atch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop