Multiple counters to track days in a document state

[ietf-svn-bot]

type_enhancement | by rdd@cert.org

---

Background

---

Currently, the datatracker maintains a (WG or IESG) state and substate for each document. Based on changes to this state/substate a counter of the days the document has been in this state is presented in a number of page types. For example:

• in a WG Documents Page
• in a Individual's Document Page
• on the Telechat Agenda Page

Enhancement

---

Instead of presenting a single counter, present two -- one for the days in the major state, another for the days in the minor state.

For example,

• "WG Consensus: Waiting for Writeup" [10 days: 10 days]
• "AD Evaluation" [21 days]
• "AD Evaluation: Revised I-D needed": [57 days: 11 days]
• "IESG Evaluation::AD Followup" [39 days: 9 days]

The presentation of two counters conveys how the major activity is taking (e.g., IESG Evaluation) but also the time in the discrete sub-tasks (e.g., "AD Follow-Up" vs. "Revised I-D needed").

Validation

---

This request arose from the April 2019 IESG retreat and has IESG consensus

---

Issue migrated from trac:2771 at 2022-03-04 07:14:51 +0000

[ietf-svn-bot]

@rjsparks@nostrum.com changed priority from n/a to medium

[ietf-svn-bot]

@rjsparks@nostrum.com changed component from -- Other to doc/

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

This has come up (and implementation has been tried) before. There was disagreement among the IESG at the time whether the minor state counter should reflect all the time the document's ever been in that state, or if it should just be the time since last transition.

Unless we hear otherwise, we'll implement "time since last transition".

[ietf-svn-bot]

@rjsparks@nostrum.com changed priority from medium to major

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

See also #1371

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

I've taken several starts at this, each time having to rediscover how hard it will be to satisfy the request with the current data. Here are some notes:

1) The "substates" are implemented as tags, so this isn't a simple matter of ordering DocEvents. (and the only history we have for the tags associated with a document is what's captured in DocHistory).

2) Sometimes a DocEvent is dropped when the tags are changed (such as when a document goes into ::Revised I-D Needed) and sometimes one isn't (such as when a revised ID is published, sending the document to ::AD Followup

3) DocHistory and DocEvent objects taken together might have enough information, but we'd need careful inspection of the code to confirm that's true.

Anecdotally: for draft-ietf-cellar-ebml, here's a combination of dochistory and docevent objects. Each row shows one ore more of a docevent and the set of tags at the time the event is dropped, or a dochistory and its friendly_state()

2016-09-23 20:44:16 [u'dochistory I-D Exists']
2016-10-15 08:40:01 [u'dochistory I-D Exists']
2017-02-26 16:26:32 [u'dochistory I-D Exists']
2017-06-07 14:08:52 [u'dochistory I-D Exists']
2017-07-03 10:03:56 [u'dochistory I-D Exists']
2018-01-03 04:23:25 [u'dochistory I-D Exists']
2018-07-16 00:16:52 [u'dochistory Expired']
2018-07-18 12:33:29 [u'dochistory I-D Exists']
2018-08-28 12:53:51 [u'dochistory I-D Exists']
2018-09-25 13:14:49 [u'dochistory I-D Exists']
2018-09-26 08:17:43 [u'dochistory I-D Exists']
2018-11-27 08:36:48 [u'dochistory I-D Exists']
2018-12-04 07:46:30 [u'dochistory I-D Exists']
2018-12-04 07:48:03 [u'dochistory I-D Exists']
2018-12-04 07:49:22 [u'dochistory I-D Exists']
2018-12-04 07:49:35 ['docevent Publication Requested ', u'dochistory Publication Requested']
2018-12-04 08:23:29 [u'dochistory Publication Requested']
2019-01-03 12:33:39 ['docevent AD Evaluation ', u'dochistory AD Evaluation']
2019-01-07 13:16:15 ['docevent AD Evaluation Revised I-D Needed', u'dochistory AD Evaluation::Revised I-D Needed']
2019-01-24 06:24:58 [u'dochistory AD Evaluation::AD Followup']
2019-03-23 06:30:44 ['docevent AD Evaluation Revised I-D Needed', u'dochistory AD Evaluation::Revised I-D Needed']
2019-03-27 10:57:10 [u'dochistory AD Evaluation::Revised I-D Needed']
2019-05-27 14:40:45 [u'dochistory AD Evaluation::AD Followup']
2019-07-03 06:44:56 ['docevent AD Evaluation Revised I-D Needed', u'dochistory AD Evaluation::Revised I-D Needed']
2019-09-24 12:19:14 [u'dochistory AD Evaluation::AD Followup']
2019-10-21 08:27:41 [u'dochistory AD Evaluation::AD Followup']
2019-10-22 10:54:22 [u'dochistory AD Evaluation::AD Followup']
2019-10-24 05:41:11 ['docevent Last Call Requested ', u'dochistory Last Call Requested']
2019-10-24 06:52:18 ['docevent In Last Call ', u'dochistory In Last Call']
2019-11-06 09:43:33 [u'dochistory In Last Call (ends 2019-11-07)']
2019-11-07 00:24:12 ['docevent Waiting for Writeup ', u'dochistory Waiting for Writeup']
2019-11-18 14:36:02 [u'dochistory Waiting for Writeup']
2019-12-01 13:46:47 [u'dochistory Waiting for Writeup']
2019-12-03 07:42:55 ['docevent IESG Evaluation ', u'dochistory IESG Evaluation']
2019-12-03 08:38:53 ['docevent IESG Evaluation - Defer ', u'dochistory IESG Evaluation - Defer']
2019-12-16 06:35:46 [u'dochistory IESG Evaluation - Defer']
2019-12-18 16:11:44 [u'dochistory IESG Evaluation - Defer']
2019-12-19 08:09:08 ['docevent IESG Evaluation Revised I-D Needed', u'dochistory IESG Evaluation::Revised I-D Needed']
2019-12-20 13:20:50 [u'dochistory IESG Evaluation::Revised I-D Needed']
2019-12-22 12:38:19 [u'dochistory IESG Evaluation::AD Followup']

I had the thought of just making sure clear events are dropped going forward, but that won't solve the problem for the current IESG who have active documents that have been in a given state (with changes to the substates) for over a year, so some migration to better deal with past data is needed.

[ietf-svn-bot]

@rjsparks@nostrum.com changed _comment0 which not transferred by tractive

[ietf-svn-bot]

@rjsparks@nostrum.com changed status from new to accepted