On draft-expiration, documents with IESG state shouldn't change IESG state.

[rjsparks]

Before we added an explicit ID-Exists draft-iesg state, a decision was made (with IESG input) to have the expiration code move the iesg-state for an expired document to the Dead IESG state. Note that this could only happen if the draft was in an IESG state that did not prevent expiration.

Now that we have the ID-Exists state, is it a better target? Which will cause the IESG the least surprise (if a document moves out of "AD is watching" for example)?

[rjsparks]

@evyncke @wkumari

[evyncke]

FYI, I personally use "I-D exists" state for WG documents that I want to easily see in "my documents" page (usually for WG/document specific reasons). I.e., there are no semantic associated for me to this state.

I was unaware that when a document action holder is the IESG in some specific states (?) and when the I-D expires then it is moved to a "dead" state. I do not remember seeing it ;)

All in all, I prefer to keep the current process, i.e., move it to a "IESG dead" state upon expiration.

[wkumari]

On Tue, May 02, 2023 at 5:01 AM, Eric Vyncke ***@***.***> wrote: FYI, I personally use "I-D exists" state for WG documents that I want to easily see in "my documents" page (usually for WG/document specific reasons). I.e., there are no semantic associated for me to this state. I was unaware that when a document action holder is the IESG in some specific states (?) and when the I-D expires then it is moved to a "dead" state. I do not remember seeing it ;) All in all, I prefer to keep the current process, i.e., move it to a "IESG dead" state upon expiration.

Yes, I think I agree with this — it also helps keep it clearer where the document is in the process… W —

…

Reply to this email directly, view it on GitHub <#5560 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDG3XEC7SR74F6OOB4TEK3XEDEOHANCNFSM6AAAAAAXR4FXAE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rjsparks]

#6051 argues otherwise.

I think we have a real problem here to work out, and suggest that we want an entirely different mechansim for letting an AD put a draft that's not yet in IESG processing show up on their dashboard rather than giving it an IESG state. The very existance of an "AD is watching" state was (as my memory serves) entirely a hack to enable the original IESG tracker (pre-datatracker days) to hold information about a document that hadn't been pubreqed, and it got carried over and went essentially unused for awhile, then became used exactly and only to make a document show on the dashboard.

I'm leaning towards making it so that an AD can just mark any draft as watching, and it gets no IESG state - all it does is make it show up on the dashboard, with an explanation of why it shows up on the dashboard. Watching would automatically be turned off for a set of reasons (draft enters real IESG processing being one of them, expiry would not be - an AD would remove long expired drafts from their watch list when they were convinced they no longer needed watching).

@wkumari: With that in mind, Please say more about "keep it clearer where the document is in the process". How, in the existing system, would automatically returning a document to "idexists" make things less clear than an automatic return to "dead"? In the new system, if a watched draft never got IESG state until it was pubreqed, how would that make anything less clear?

[evyncke]

Isn't it then the same as "tracked documents" ? That I use quite often.

[Remark for below: I must admit that I am not too familiar with all the states and sub-states]

"AD is watching" could be used as a signal to the WG though that an AD is actually following up this specific document. Unsure whether it is useful for the AD or for the WG.

Back to the "IESG dead" upon I-D expiration, I think that this is not intuitive at all. I have manually set once "IESG Dead" on one I-D, as well as "WG Dead" as the document is not a useful/in charter document.

Even an expired document whose publication was requested by the WG should stay in the AD queue.

BTW, it seems that the "title" attribute (hover popup) does not work for me for some unknown reason for the "Add to your personal I-D list".

[rjsparks]

It's similar to tracked documents, yes, but "wants to appear on dashboard" isn't quite the same. But we might be able to leverage that part of the codebase.

And yes, things that are in iesg processing stay in the queue even if they expire.

[jgscudder]

The transition to "Dead" is, to me, not useful and it created some genuine confusion recently. I'm in favor of the "ID-Exists" suggestion.

[rjsparks]

This conversation should be revisited now that "AD is watching" has been removed as a state.

Before the recent change to make that state unused, drafts in iesg-states ["ID exists", "Dead", "AD is Watching"] could expire. If (and only if) IESG processing had been started on the draft, expiry while in any of those states would transition the document to "Dead".

Now, this happens only for documents that have started IESG processing at least once, and are in ["ID exists, "Dead"].

Note that any other IESG state prevents a draft from expiring.

I'm planning to not change the IESG state on expiration - if the draft can expire it is already in either "ID exists" or "Dead", and we will just leave it there.

I'll also be changing the paths that would let us bring a document out of IESG state "Dead", and investigating if we can identify those that transitioned because they expired while in "AD is watching" in the past and move those to IESG state "ID Exists".

This is coming to head of stack because of issues like #8212.

@wkumari @evyncke - please object quickly if you don't think this is the right direction to go.
cc: @cindymorgan

[evyncke]

Allow me until next Wednesday (20th of Nov) to think about, my agenda is way to busy until then.

Deeply sorry

[evyncke]

Robert, your proposal looks good to me