Subject: [TOOLS-DEVELOPMENT] How do counters reset in the datatracker

From: Roman Danyliw <[email-masked]>
Date: Thu, 16 May 2019 13:31:49 +0000

Hi!

At the IESG retreat, there was a confusion in the IESG about how the timer listed next to the draft  (e.g., "for xxx days") in the datatracker is reset when a state or sub-state changes (see screenshot).  I was asked get clarity on the following:

** Which sub-state changes will trigger a reset to 0?

** Which state changes will trigger a reset to 0?

Thanks,
Roman

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 May 2019 09:36:21 -0400

Roman:

When the document moves to a new state, the counter is reset for that new state.  You are not the first AD to inherit a stale document.

Russ

> On May 16, 2019, at 9:31 AM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
>

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 16 May 2019 13:40:12 +0000

Hi Russ!

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, May 16, 2019 9:36 AM
> To: Roman Danyliw <[email-masked]>
> Cc: IETF Tools Development <[email-masked]>
> Subject: Re: [TOOLS-DEVELOPMENT] How do counters reset in the
> datatracker
> 
> Roman:
> 
> When the document moves to a new state, the counter is reset for that new
> state.  

To be clear -- any change in sub-state will trigger a reset?

> You are not the first AD to inherit a stale document.

*chuckle* This wasn't me "asking for friend" ;-)  Different ADs touted experiencing different behaviors but no one wanted to change states on the live system to find out at the time.

Roman

> > At the IESG retreat, there was a confusion in the IESG about how the timer
> listed next to the draft  (e.g., "for xxx days") in the datatracker is reset when
> a state or sub-state changes (see screenshot).  I was asked get clarity on the
> following:
> >

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 May 2019 09:43:09 -0400

> To be clear -- any change in sub-state will trigger a reset?

My memory is that only the state, not the sub-state, will reset it.  I would have to look at the code to be 100% sure, but that is my memory from my time as an AD.

Russ

---

From: Robert Sparks <[email-masked]>
Date: Thu, 16 May 2019 09:23:27 -0500

Hi Roman -

Like Russ, I will have to look at the code to give you the exact answer 
you are looking for, and I hope to do that today or tomorrow. I fear the 
answer will be "it's complicated".

For the moment, I can point to some history. Different ADs over time 
have had different opinions about what these "since" values should 
represent. Should it show time since last action, or accrued time in the 
where it is in the queue? Who is the metric there to help push along? 
I've occasionally been of the opinion that perhaps we should show state 
and sub-state staleness separately (as suggested by Adrian in one of the 
tickets below), but the display does get cluttered...

See

<https://trac.tools.ietf.org/tools/ietfdb/ticket/1371> and

<https://trac.tools.ietf.org/tools/ietfdb/ticket/1372>

RjS

On 5/16/19 8:31 AM, Roman Danyliw wrote:
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Robert Sparks <[email-masked]>
Date: Thu, 16 May 2019 10:49:34 -0500

So the direct answer is simpler than I expected. It is the last change 
in iesg state (or the date iesg-evaluation started).

The relevant code is here:

<https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/doc/templatetags/ballot_icon.py#L168>

at line 168.

RjS

On 5/16/19 9:23 AM, Robert Sparks wrote:
>
> Hi Roman -
>
> Like Russ, I will have to look at the code to give you the exact 
> answer you are looking for, and I hope to do that today or tomorrow. I 
> fear the answer will be "it's complicated".
>
> represent. Should it show time since last action, or accrued time in 
> the where it is in the queue? Who is the metric there to help push 
> along? I've occasionally been of the opinion that perhaps we should 
> show state and sub-state staleness separately (as suggested by Adrian 
> in one of the tickets below), but the display does get cluttered...
>
> See
>

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 16 May 2019 17:44:59 +0000

Ack.  Thanks for finding the code and the tickets.  https://trac.tools.ietf.org/tools/ietfdb/ticket/1371 seems to be the related issue/enhancement.

I'll talk it through with them, but the interest was around the following states:

"AD Evaluation::AD Followup"
"AD Evaluation::Revised I-D Needed"
"IESG Evaluation::Revised I-D Needed"
"IESG Evaluation::AD Followup"

Per the question of metrics and motivation, (one of the) identified drivers was to implicitly distinguish between waiting on document authors (Revised ID Needed) vs. waiting on AD/IESG (AD Followup)

I'll get back to you,
Roman

From: TOOLS-DEVELOPMENT [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Thursday, May 16, 2019 11:50 AM
To: [email-masked]
Subject: Re: [TOOLS-DEVELOPMENT] How do counters reset in the datatracker

So the direct answer is simpler than I expected. It is the last change in iesg state (or the date iesg-evaluation started).

<https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/doc/templatetags/ballot_icon.py#L168><https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/ietf/doc/templatetags/ballot_icon.py#L168>
at line 168.

RjS

Hi Roman -

Like Russ, I will have to look at the code to give you the exact answer you are looking for, and I hope to do that today or tomorrow. I fear the answer will be "it's complicated".

For the moment, I can point to some history. Different ADs over time have had different opinions about what these "since" values should represent. Should it show time since last action, or accrued time in the where it is in the queue? Who is the metric there to help push along? I've occasionally been of the opinion that perhaps we should show state and sub-state staleness separately (as suggested by Adrian in one of the tickets below), but the display does get cluttered...

See

<https://trac.tools.ietf.org/tools/ietfdb/ticket/1371><https://trac.tools.ietf.org/tools/ietfdb/ticket/1371> and

<https://trac.tools.ietf.org/tools/ietfdb/ticket/1372><https://trac.tools.ietf.org/tools/ietfdb/ticket/1372>

RjS

Hi!

Thanks,

Roman

[email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>