[Codematch-develop] Fwd: CodeMatch Update

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 28 August 2014 22:16 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
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 14C2B1A0053 for <codematch-develop@ietfa.amsl.com>; Thu, 28 Aug 2014 15:16:22 -0700 (PDT)
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 JWo3fzH5Mrvj for <codematch-develop@ietfa.amsl.com>; Thu, 28 Aug 2014 15:16:19 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9617B1A0035 for <codematch-develop@ietf.org>; Thu, 28 Aug 2014 15:16:18 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id 10so1686143lbg.17 for <codematch-develop@ietf.org>; Thu, 28 Aug 2014 15:16:17 -0700 (PDT)
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=v3dX7mT0LrtPARa2zYPDfSkXko9cR3JvMlmMYAAdLX0=; b=d/VALSjuq7vpUvFlmdWby08qDJGI+bdagwJUh9zzjFGn4S2NceHYVRgjhM19ioaUAd wgHT6NFN5U3/55o4RSUdYsjl61wYEv4nP4jsT8daCh440syjNQdjVlAchvOWPVUOKlrc H7tt+lS2kztu10MwdbaLiKiUdtHTj8X32jJ615mHgn+4nSCpWwTYkYKSJVHHAbByoFzz McOEniJcNqRPAr/0UjSCwxMbhLg9Rh0buAdUarmajSHZBXyri01MSnyZql13VOLTN7Vw nlcqe6WJREadfSrA6tNbCVs+2gfLQGpDNzeN6qdWSavIS/3f0u5Jclg9m/NWpLiLHQGY ACnA==
MIME-Version: 1.0
X-Received: by 10.112.199.161 with SMTP id jl1mr6763057lbc.59.1409264176860; Thu, 28 Aug 2014 15:16:16 -0700 (PDT)
Received: by 10.112.64.170 with HTTP; Thu, 28 Aug 2014 15:16:16 -0700 (PDT)
In-Reply-To: <53FF94C3.2020407@levkowetz.com>
References: <CAHbuEH7rhRF5V4buxMFZxkZqv5rZ6qQcuhPirMxyjYBbf0+E6A@mail.gmail.com> <53FF94C3.2020407@levkowetz.com>
Date: Thu, 28 Aug 2014 18:16:16 -0400
Message-ID: <CAHbuEH4mtQhcOaUC_T2fMzUL9-ux+Gf7ZaV8f12Ad96cCP9igQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: "codematch-develop@ietf.org" <codematch-develop@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c34b18a8142f0501b7e28b"
Archived-At: http://mailarchive.ietf.org/arch/msg/codematch-develop/SOrEGuRIIxJIUIDJrRyd1x_VtGI
Cc: Henrik Levkowetz <henrik@levkowetz.com>, Robert Sparks <rjsparks@nostrum.com>
Subject: [Codematch-develop] Fwd: CodeMatch Update
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\"" <codematch-develop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codematch-develop>, <mailto:codematch-develop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codematch-develop/>
List-Post: <mailto:codematch-develop@ietf.org>
List-Help: <mailto:codematch-develop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codematch-develop>, <mailto:codematch-develop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 22:16:22 -0000

Hello,

After today's mockup demo, I had said I would reach out to Henrik and
Robert to let them know where we are at in our planning.  As you can see
below, I let them know that we would like to plan to meet with them a week+
out after we have had time to develop the requirements, which Lisandro
offered to start.

Henrik provided quite a bit of information that should be helpful for our
next steps and I'm sure there will be more once we have answers to some of
his questions.  I think as a group, we were leaning toward using another
site for at least the initial interactions to help those not familiar with
IETF tools a bit more and leverage some social features that you might see
in a 'marketplace'.  However, as Henrik points out, we are probably not
quite ready to decide how we do that until we have the developed what we
were calling requirements (Henrik includes specific details that will be
needed below - interactions with the database, any new data we think needs
to be saved int he data tracker, etc.).

Thanks very much, Henrik for the detailed explanation.  The timing is
perfect for where we are at as a team.

---------- Forwarded message ----------
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Thu, Aug 28, 2014 at 4:44 PM
Subject: Re: CodeMatch Update
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Robert Sparks <
rjsparks@nostrum.com>
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Brian Haberman <
brian@innovationslab.net>


Hi Kathleen,

On 2014-08-28 20:37 Kathleen Moriarty said the following:
> Hello Henrik and Robert,

Inline:

> The team is getting a little closer to the point where we can demo a
mockup
> of the site on slides for you.  We had a couple of calls to review and
hash
> out things like format and definitions and am sure further refinement will
> be needed on that front, but are getting closer.
>
> We had Brian take a look at it today and Pete will be watching the
recorded
> session in hopes that we get feedback that improves the review with each
of
> you for additional guidance.  From Brian's feedback, the team will start
to
> put together a set of requirements for features, etc.
>
> What I am thinking is that we could hopefully get a fe things done on one
> call, maybe a week + out from now so the team has what they need for your
> review and input.
>
> CodeMatch Team:
>    1. Walk through of the site mock up slides
>    2. Review of requirements (may need to be refined with your input)
>
> Tools perpective (Henrik?)
>    1. Overview for developers and any guidance that could be offered prior
> to beginning development.  I know Henrik expressed concerns about being
> able to fold whatever is done back into the datatracker, so this will be
> very important to get your guidance and direction early.

There is some information that is needed before much guidance can be given,
which I'll detail below.  Possibly the walk-through and requirements will
cover this -- but if not already covered, the sooner you can address this,
the better.

Some background: The database schema was a total mess before the huge
re-design I did in 2010-2012, because tables and schema were added
higgledy-piggledy with no design work.  Accordingly, currently database
schema changes are only done after design work, and the design work is
done by me in cooperation with Robert and the developers involved in
the enhancement work.  This needs to happen before coding begins.

For this, the first thing that will be needed is a clear, even if
preliminary, statement of which new data you believe needs to be saved in
the datatracker database, and which existing data needs to be retrieved from
the database, in order to make the planned website work.  This may already
be covered in the requirements you mention, but if not, it should be added.

This will make it possible to start any needed database schema design.
Completion of the schema design will as mentioned need direct discussions
with the lead coders.

Another point to consider is how to best integrate the envisioned site
with the datatracker.  It could be that the best approach will be a loosely
coupled standalone site with REST interaction with the current datatracker,
or it could be that a direct integration in the current datatracker code is
the best, or it could be something in between.

The presentation of the intended site on slides will help in the decision
of how the intended site should be deployed (of course, you may already
have thought this through, and covered it extensively).  Some possibilities
I see are:

     a) as direct modification of current datatracker pages

     b) as a standalone but integrated part of the datatracker

     c) on the same server, but as a separate site

     d) on a separate server, next to the ietf server

     e) on a separate server, with some distance latency-wise from
        the ietf-server

     f) on a cloud service, as an app (e.g., on the google app engine)

If the best deployment model is one of c) to f), a suitable API for export
and modification of data needs to be determined, in addition to designing
the database schema; and this also should happen before the main part of
the coding is done.

> We may have students helping with development and the team will likely be
> in several regions of the world.  We would like to record the WebEx in
case
> English is not a first language or someone misses the call and can go back
> to watch the guidance provided.

Ok.

> We'll send out a doodle poll with meeting time options.  It won't be until
> sometime after Tuesday at the earliest.  We are going to use part of our 1
> PM call to review and collaborate on requirements before presenting them
to
> each of you.
>
> Please let me know if I am missing anything or if there should be other
> agenda items for the call.

If the answers to my points above about needed data export/modification and
about deployment model is included in the requirements already, then I'd
like to talk separately about them:

  2a. Overall requirements, presentation (Team)
  2b. Overview of current datatracker basics (Henrik)
  2c. Feedback on overall requirements (Henrik, Robert)

  3a. Known data export and modification needs (Team)
  3b. Feedback on same, with discussion (Henrik, Robert, All)

  4a. Deployment model (Team)
  4b. Discussion and feedback on same (All, Henrik, Robert)
  4c. If relevant, discussion about any needed API. (All)

If not, item 3. (Your tools perspective item 1. above) should probably
be modified to cover feedback and discussion about the requirements in
general, rather than mentioning guidance -- the data export/modification
needs, leading to schema design, and the deployment model, possibly leading
to API design, is desired before meaningful guidance can be given.

(That is, apart from such things as coding style and other things that are
already covered on
 - http://trac.tools.ietf.org/tools/ietfdb/wiki/SprintCoderSetup
 - http://trac.tools.ietf.org/tools/ietfdb/wiki/GettingStarted
 - http://trac.tools.ietf.org/tools/ietfdb/wiki
but I assume you're not thinking of those details when you mention
guidance).

Feel free to forward this reply to your team.


Regards,

        Henrik



-- 

Best regards,
Kathleen