Subject: [Tools-discuss] Fwd: Visibility of shepherd writeup

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Aug 2013 07:53:36 -0700

This seems like a very good idea from Carsten. Two, actually; sending out announcements with URLs that will 404 seems bad.

--Paul Hoffman

Begin forwarded message:

> From: Carsten Bormann <[email-masked]>
> Subject: Visibility of shepherd writeup
> Date: August 23, 2013 3:31:40 AM PDT
> To: Barry Leiba <[email-masked]>
> Cc: Pete Resnick <[email-masked]>, Crocker Dave <[email-masked]>, IETF discussion list <[email-masked]>
> 
> On Aug 22, 2013, at 21:23, Barry Leiba <[email-masked]> wrote:
> 
>> Most Excellent(tm)
>> shepherd report:
>> https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/shepherdwriteup/
> 
> (This may not have helped much in this case, but:)
> 
> Why is it that IETF last-calls do not contain a direct reference the shepherd writeup?
> Shouldn't those be required first reading for anyone commenting?
> 
> Grüße, Carsten
> 
> PS.: The last-call does contain a direct reference to
> http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ballot/
> which is 404 at this point in the procedure.
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Aug 2013 16:59:01 +0200

On Aug 23, 2013, at 16:53, Paul Hoffman <[email-masked]> wrote:

> good idea

Thanks.
Let's do that first.

In the long run, I think every document should have a *document dashboard* that, for those who haven't memorized the process rules by heart, gives quick access to the current status of the document and provides all relevant links.

So a last-call announcement would simply point to the dashboard for this document.

While the LC is running, this would show the LC end date, the shepherd write up etc.
After that, it would show who we are waiting for (first AD, then author, ...).
When it's in IESG balloting, it would show the ballots (that link that currently is sent too early).
And so on.
Requires some more design, but could actually make the process *much* more transparent for non-process-jockeys.

Grüße, Carsten

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 Aug 2013 13:48:29 -0400

> In the long run, I think every document should have a *document dashboard* that,
> for those who haven't memorized the process rules by heart, gives quick access
> to the current status of the document and provides all relevant links.

There is; it's the datatracker page for the document, and that link is
in the last call notices now.  The CBOR datatracker page is here:
https://datatracker.ietf.org/doc/draft-bormann-cbor/

It shows the document states, it has a link to the writeup, and the
tabs on top will take you to the IESG ballot and the document history.

> So a last-call announcement would simply point to the dashboard for this document.

Right, and it does.

> When it's in IESG balloting, it would show the ballots (that link that currently is sent too early).

It has all of that (if you look at the datatracker page for a doc
that's in Last Call, you'll see that it says when last call ends.

So, I'm glad that we could handle your request so quickly, and I wish
it were always that easy.

But for those same process-non-jockeys, knowing what they can find is
often a challenge.  The IESG Evaluation Record is called out in the
last call notice because we want to make sure that people are aware
that it exists and that it's something they might want to look at.  I
think the same goes for the shepherd writeup.

Now, it's true that the IESG Evaluation Record page doesn't usually
exist when the last call notice goes out (it's created when the
responsible AD issues the IESG ballot, which is usually near the end
of or after last call), but consider that the last call notice is the
only official notice to the community that the IESG is processing the
document.  I don't really think it would be an improvement to send
another notice later.

I'm proposing to the IESG that the last call notice be changed to say
this at the end:

---------------------------------------
The file can be obtained via
http://datatracker.ietf.org/doc/<doc-name>/

The document shepherd writeup is available via
http://datatracker.ietf.org/doc/<doc-name>/shepherdwriteup/

Once IESG discussion begins, the IESG comments will be visible via
http://datatracker.ietf.org/doc/<doc-name>/ballot/
---------------------------------------

So far, all ADs who have weighed in think it's a fine idea.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 Aug 2013 13:49:48 -0400

> tabs on top will take you to the IESG ballot and the document history.

If you have suggestions for changes to that page to make things easier
to find, clearer, or whatever, please take them to
<[email-masked]>.

Barry

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 23 Aug 2013 17:59:04 +0000

> In the long run, I think every document should have a *document dashboard* that, for those who haven't memorized the process rules by heart, gives quick access to the current status of the document…

I thought that was the data tracker? What specifically are we looking for that isn't on pages like
    http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/
besides the shepherd's report?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Aug 2013 20:00:26 +0200

On Aug 23, 2013, at 19:48, Barry Leiba <[email-masked]> wrote:

> often a challenge.

That was my point here -- after having been WG chair for a while, I think I know how to find things in the datatracker.
But it's a discouraging smorgasbord to most others, and so much less useful as a tool for delegating things in the WG to others than it could be.

The point of a dashboard style page would be to direct the attention to what is important now.
It would be designed with a view to what the specific user wants or needs now, not with respect to looking the same for all documents and completeness of coverage.
(It would still reference the existing datatracker for the whole set of information.)

(Imagine your amazon purchasing process mapped to something like the datatracker page...)

It looks like I won't be in an interop during the Vancouver code sprint, maybe I can prototype something like that there.

Grüße, Carsten