Re: [Tools-discuss] Time in States on Datatracker

John C Klensin <john-ietf@jck.com> Thu, 16 June 2022 08:39 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898DEC15D885 for <tools-discuss@ietfa.amsl.com>; Thu, 16 Jun 2022 01:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQTsy5BQsYpE for <tools-discuss@ietfa.amsl.com>; Thu, 16 Jun 2022 01:39:25 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150FBC15B249 for <tools-discuss@ietf.org>; Thu, 16 Jun 2022 01:39:24 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1o1l28-000F3A-St; Thu, 16 Jun 2022 04:39:20 -0400
Date: Thu, 16 Jun 2022 04:39:15 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bob Hinden <bob.hinden@gmail.com>, Greg Wood <ghwood@staff.ietf.org>
cc: tools-discuss@ietf.org, Robert Sparks <rjsparks@nostrum.com>
Message-ID: <45481F25AF37BD727A8438E9@PSB>
In-Reply-To: <142B72FC-0E15-434D-AEC8-C211A3110F3E@gmail.com>
References: <3C6B878C-E03E-49BC-9880-2F707D3EBCEC@gmail.com> <4bc8a25c-0a87-3db7-1b24-4caa4d1379ac@nostrum.com> <37156F61-D95C-42F7-97EE-C0830CA1A710@gmail.com> <E080D53E-936B-47B8-B2EA-B3E2EC797624@staff.ietf.org> <142B72FC-0E15-434D-AEC8-C211A3110F3E@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/jaDVj0s0sT3q2fF5egeEuleftuo>
Subject: Re: [Tools-discuss] Time in States on Datatracker
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2022 08:39:29 -0000


--On Wednesday, June 15, 2022 16:15 -0700 Bob Hinden
<bob.hinden@gmail.com> wrote:

> Greg,
> 
>>>>> 
>>>>> It no longer shows how long a document has been in a
>>>>> particular state. Is this a bug or was it removed
>>>>> purposely?
>>>> 
>>>> Lars put a great deal of downward pressure on the visual
>>>> complexity of these tables. If this is a bit of data you
>>>> really needed on those tables, please raise it as an issue,
>>>> and we'll work to find the middle ground (as we've just
>>>> done at https://github.com/ietf-tools/datatracker/pull/4069
>>>> for example).
>>> 
>>> Will do.
>> 
>> Hi Bob,
>> 
>> I notice the info is available on roll-over of the hour
>> glass, in case that helps.
>> 
>> And it looks like the hour glasses are color-coded to give
>> hints at a glance, which is neat.
> 
> Thanks, I missed that completely.   I had no idea it would do
> that.   The hour class doesn't show for most documents, I
> assume only shows if they exceed some limit.
> 
> This is way to subtle IMHO.

Agreeing with "too subtle", let me raise my usual question: how
is a relative newcomer to the IETF and/or the tool supposed to
know this?"

More broadly, would it be useful to ask that every change that
might result in a reduction in functionality (or in obvious
access to information) be announced to the community in advance
with an opportunity for comment rather than deployed,
effectively seeing if anyone screaming in agony?  If nothing
else and with respect to Lars (and I generally agree with his
design taste), making design decisions based on "downward
pressure" is a little bit more top-down than the IETF is
supposed to operate.  That is especially problematic when the
pressure and decisions are invisible to the community until
after the fact.
 
  john