Re: [TOOLS-DEVELOPMENT] Next (and I think final) version of the Meeting application SoW

Russ Housley <> Tue, 22 January 2019 21:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 994211310FE for <>; Tue, 22 Jan 2019 13:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kDIpwq5VaVo4 for <>; Tue, 22 Jan 2019 13:22:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B4A91277CC for <>; Tue, 22 Jan 2019 13:22:18 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D2CA300A32 for <>; Tue, 22 Jan 2019 16:04:00 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id UB-VHuz1dDz1 for <>; Tue, 22 Jan 2019 16:03:58 -0500 (EST)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id 618B73005D5; Tue, 22 Jan 2019 16:03:58 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Russ Housley <>
In-Reply-To: <>
Date: Tue, 22 Jan 2019 16:22:14 -0500
Cc: Robert Sparks <>, IETF Tools Development <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Alissa Cooper <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [TOOLS-DEVELOPMENT] Next (and I think final) version of the Meeting application SoW
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Development list server <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Jan 2019 21:22:19 -0000


> Have we done any serious investigation of whether we could use an off-the-shelf tool like Sched to meet the bulk of our needs, rather than continuing to develop more bespoke functionality that we have to maintain over time for meeting scheduling and display? I know we think the IETF is a special flower, but in many ways it isn’t, e.g., we have a bunch of tracks and sessions that need to be de-conflicted based on certain criteria and fit into a grid.

We looked at a bunch of different packages before we went down the current path.  That was now a few years ago.

I did a very quick look at Sched, and it seems to be more of a service than a software package.  A non-profit pays $3000/year for a subscription, so it will not integrate easily with the way we handle proceedings.

	It says things like:	You can export your sessions and their details as a spreadsheet.

	This makes me think that we would spend as much making it fit together as we would on the new code.

This did not exist when we started:

	A quick review, and it falls very short of our needs.

Another one is:

	This seems to be aimed at the attendee, not the meeting planner.

> I’m also curious who we expect to consume the improved meeting statistics. As far as I know, no one on the IESG makes use of the existing reports cited in the RFP. Generally I find the datatracker statistics kind of hard to consume for a number of reasons, so I would hesitate to add more functionality there without a compelling justification.

The current manual report is for the IESG.  They idea is to automate it, but if it is not useful, we can drop that from the SOW altogether.