Subject: Re: [dispatch] Updated wiki - where's the history of proposal dispatchments?

From: Patrick McManus <[email-masked]>
Date: Tue, 2 Nov 2021 20:58:15 -0400

Hi Mary,

Yes, the wiki has been updated to focus a little bit higher in the stack
than before. We wanted to focus on being an introductory point for new work
in the art area to help folks navigate their way towards an outcome (a
successful dispatch!). Minutes and updates to the list are hoped to be
sufficient for documenting the work product at this point -- Kristy and I
think that with a different focus than a traditional WG (with milestones
and what not) the emphasis makes sense.

I hope that this focus will continue to evolve and reflect the changing
needs of dispatch over time.

-Patrick

On Thu, Oct 28, 2021 at 2:16 PM Mary Barnes <[email-masked]>
wrote:

> I noticed the wiki has been updated and I don't see all the past
> information about how work items were dispatched.  I would have expected to
> at least see a link and have an annotation that it's no longer being
> updated.    I personally found it very helpful (although, I'm biased
> because I worked hard to keep it up to date).
>
> It is available under update 144, however for anyone else that was
> wondering: https://trac.ietf.org/trac/dispatch/wiki/WikiStart?version=144
>
> It is a good way to easily track stats for how proposals were progressed
> (or not).  I would periodically go back and update things once WGs were
> officially formed, etc.
>
> Regards,
> Mary.
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 5 Nov 2021 13:12:26 -0500

Yeah, it makes total sense to update the wiki to more accurately reflect
how things currently work and reflect the style of the WG chairs.  I wasn't
challenging that.

And, yes,  DISPATCH doesn't work like other WGs and the tools are not
geared towards such.

As you note, minutes are a snapshot in time and thus are not nearly
sufficient to really know what happened to an agenda topic beyond that
specific time.    The tools aren't geared towards facilitating workflow for
WGs like DISPATCH.  For one, you can't go to the datatracker or Tools page
and see all the drafts that have been submitted.  If people submitted the
drafts with the -dispatch in the file name then that would help, but it's
rare that someone does that.  And, yes, you can search the filename in
Datatracker and find the draft. However, in the case of documents that go
to a WG, unless someone makes sure to indicate that it's replacing the
draft submitted for discussion in  the DISPATCH WG, you've lost the linkage
and ability to use tools to track the draft.

And, of course, many items aren't discussed based on a draft(s). For
example, when a topic is submitted for discussion and the WG decides to
charter a mini-WG, you have to do some digging and correlate mailing list
discussion to know ultimately the WG name.  And, the reality is that while
we say decisions happen on the WG mailing list, for DISPATCH in my
experience it's not usual to go back to the mailing to confirm all the
decisions made in the meeting, nor following up on how topics were actually
dispatched.

In the case that a draft will be AD sponsored, again without the -dispatch
in the name you don't have a quick place to go to see that's the case.
And, of course, there are times when the minutes might suggest something
will be AD sponsored, but of course, it's up to the ADs ultimately whether
they do.

Certainly, everyone can Google, search mailing list archives, etc. and
figure this stuff out.  But, that ends up being a whole lot more effort
than a single person (e.g., WG chair or secretary) doing this task after
every meeting and having that one person track the work and keep the wiki
updated.  It really isn't that time consuming if you do it as you go along
and of course, the chair already has a much better idea of what's happened
to things over time than the average participant.

Now, perhaps I'm more sensitive to this issue having worked in IETF way too
long, but when I first started trying to follow WGs, the tools were
barebones and it took some time to track things, which I did manually for
all the WGs I was following.  We often talk about how to get new folks
engaged. I can't fathom coming into IETF as a newcomer and being able to
fully understand how work progresses through DISPATCH WG.  Also, for a new
person being able to quickly see items that might have come and know where
they've gone can also be helpful.   That was the objective of tracking that
information in the wiki and that gives you the similar summary of
deliverables that the WG accomplished that you get with the Datatracker for
regular WGs.   As an example, I didn't realize until I was making a pass at
updating the historical information and saw that one of the items that the
WG had decided not to progress had actually been published via the ISE.  While
that's not listed as an option for DISPATCHing, it actually is and so
seeing that might be helpful to someone.

As someone that hasn't been following DISPATCH too closely of late, if I
were  interested to see how things have gone, I know it would take me some
time to gather that information.

To me, it's valuable to the community overall to have a single person track
and document that as opposed to having anyone new come in and have to do
the work themselves.  So, perhaps this is a good opportunity to bring a WG
secretary since DISPATCH no longer has 3 WG chairs.

Regards,

Mary.

---

From: Patrick McManus <[email-masked]>
Date: Sat, 6 Nov 2021 19:53:12 -0400

Thanks for the thoughts Mary. We'll make sure to include them in our post
112 discussion with the ADs.

Less important than the big picture, I did want to make a note about one
point:

> seeing that might be helpful to someone.

That's a fine line though, right? The iSE is, by definition, Independent.
We cannot dispatch things to the ISE. OTOH, work that might not have a home
in the IETF might have a home with the ISE (as this one did!) and it makes
sense for folks to be aware of that if they are looking for other avenues
to pursue (similarly there are other SDOs, or just publishing it on a blog
or in a public github repo, etc..). That's just being helpful. But there
isn't much dispatch can (or should imo) do to facilitate or track that.
It's out of our hands.

---

From: Mary Barnes <[email-masked]>
Date: Sun, 7 Nov 2021 14:20:37 -0600

Just to be clear my suggestion wasn't that you all should maintain that
history just because that's how we did it before.  I was trying to explain
the value of maintaining that history so that it's easier for the community
to track the work.  I don't see this as an AD discussion.  It wasn't ADs
that suggested we do that in the first place.  And, current ADs weren't
around when WG was created.

 As I said, it makes *total* sense to be more flexible nowadays with
deadlines as the volume of incoming work has declined.  AFAIK that's the
primary process change you all have implemented.  If otherwise, then
perhaps RFC 7957 (and related RFC require changes).  As the RFC notes,
DISPATCH WG was a RAI area creation.  It was created to try to add some
focus to work in the RAI area  ( and alleviate the volume of work in the
SIPPING WG - 55 RFCs published in 8 years):
https://datatracker.ietf.org/wg/sipping/documents/

My fundamental point is the fact that the tools don't support tracking work
that is input and output of WGs like DISPATCH.  That hasn't changed.  And,
as a regular community member, I think it's really helpful to have that
information all in one place.  A lot happens outside the WG after DISPATCH
sessions and the WG doesn't always have visibility. The summaries give the
community that visibility without having to dig through mailing lists which
often don't give the complete picture or google drafts whose names may well
have changed.  In particular, in cases for docs that require further
discussion after the meeting.

And, yes, ISE is not a decision DISPATCH WG can make.  But, as you note, it
is certainly a viable path for a document submitted by a regular community
member that the WG decides not to DISPATCH due to lack of interest.  Again,
my point is that keeping that info in the Wiki helps the community better
navigate the work.  It puts that idea on their radar - i.e., this is how
you can make them aware.

Regards,

Mary.

---

From: Kirsty P <[email-masked]>
Date: Sun, 7 Nov 2021 20:34:54 +0000

Hi Mary,

I hear your rationale and explanation of why keeping a note of the history is valuable. I suggest we see if anyone else from the community feels similarly about keeping the history recorded in one place (as opposed to minutes and the list), and then we can work out the best way to collate that information, which may include doing it in the wiki as it was done before. Talking to the ADs makes sense to me, as recording the history might be a wider requirement wanted in other dispatching groups as well, and of course the ADs are part of the community from whom we'd like feedback!

Thanks for raising the question and giving your view; let's get feedback and take it from there.

Kirsty

________________________________
From: dispatch <[email-masked]> on behalf of Mary Barnes <[email-masked]>
Sent: 07 November 2021 20:20
To: Patrick McManus <[email-masked]>
Cc: DISPATCH <[email-masked]>
Subject: Re: [dispatch] Updated wiki - where's the history of proposal dispatchments?

Just to be clear my suggestion wasn't that you all should maintain that history just because that's how we did it before.  I was trying to explain the value of maintaining that history so that it's easier for the community to track the work.  I don't see this as an AD discussion.  It wasn't ADs that suggested we do that in the first place.  And, current ADs weren't around when WG was created.

 As I said, it makes *total* sense to be more flexible nowadays with deadlines as the volume of incoming work has declined.  AFAIK that's the primary process change you all have implemented.  If otherwise, then perhaps RFC 7957 (and related RFC require changes).  As the RFC notes, DISPATCH WG was a RAI area creation.  It was created to try to add some focus to work in the RAI area  ( and alleviate the volume of work in the SIPPING WG - 55 RFCs published in 8 years):   https://datatracker.ietf.org/wg/sipping/documents/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Fsipping%2Fdocuments%2F&data=04%7C01%7Ckirsty.p%40ncsc.gov.uk%7Cd6bcb6e684884f488ada08d9a22c233f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637719133442209660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eTAhgKTit3J66Ulw3jxxMr1uTOs3PAfw8dJLYCFiSeE%3D&reserved=0>

My fundamental point is the fact that the tools don't support tracking work that is input and output of WGs like DISPATCH.  That hasn't changed.  And, as a regular community member, I think it's really helpful to have that information all in one place.  A lot happens outside the WG after DISPATCH sessions and the WG doesn't always have visibility. The summaries give the community that visibility without having to dig through mailing lists which often don't give the complete picture or google drafts whose names may well have changed.  In particular, in cases for docs that require further discussion after the meeting.

And, yes, ISE is not a decision DISPATCH WG can make.  But, as you note, it is certainly a viable path for a document submitted by a regular community member that the WG decides not to DISPATCH due to lack of interest.  Again, my point is that keeping that info in the Wiki helps the community better navigate the work.  It puts that idea on their radar - i.e., this is how you can make them aware.

Regards,

Mary.

On Sat, Nov 6, 2021 at 6:53 PM Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the thoughts Mary. We'll make sure to include them in our post 112 discussion with the ADs.

Less important than the big picture, I did want to make a note about one point:

 WG had decided not to progress had actually been published via the ISE.  While that's not listed as an option for DISPATCHing, it actually is and so seeing that might be helpful to someone.

That's a fine line though, right? The iSE is, by definition, Independent. We cannot dispatch things to the ISE. OTOH, work that might not have a home in the IETF might have a home with the ISE (as this one did!) and it makes sense for folks to be aware of that if they are looking for other avenues to pursue (similarly there are other SDOs, or just publishing it on a blog or in a public github repo, etc..). That's just being helpful. But there isn't much dispatch can (or should imo) do to facilitate or track that. It's out of our hands.

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©