Re: "Tiny" working groups

[Michael StJohns <msj@xxxxxxxxxxxxxxxxxx>]

Hi Adrian - 

I think what I'm after is formalization of a model that seems to happen only by accident and isn't one of the specific options to Dispatch et al, and currently can easily mutate (through recharter) into the WG that never dies.

I would rephrase your comment slightly:  "The key is a very time and work limited charter  that can't be rechartered, and a ruthless chair/facilitator who is willing to kill the group if there's any hint of slowing."  

The "willing to do the work" is sort of hostage to the WG chair (and possibly the AD) enforcement of progress.    Chair can declare failure if its obvious that rough consensus can't be reached within the group (way differing opinions on approaches to the topic - no structure complete draft by 6 months, no feature complete draft by a 1 year).  Chair can declare failure on document creep.  Etc. 

On the representational issue... maybe:  a tiny WG with good representation gets to do a standard, a tiny WG with limited representation can at most get an Experimental or Informational.  Trade off between wanting the work published and having enough of a core group to do interoperable broad consensus stuff.    Experimental work can be recharted in a standard WG at a later time if wanted.

As for set up, we build a template.  1 Para description of the WG, a list of not more than 3-5? proposed documents with a one or two sentence abstract,  and the milestones (submission to AD being the milestone, not WG LC) and target stream/status.  Pre-selection of the document shepherd - can be a WG particpant.  Request to the AD to assign a non-participant chair.

Maybe even set a page count limit on the documents?

tiny WG participants get a Note Well on the progress requirements and anything else necessary for this model?

*sigh* I don't know if its doable, but it feels like we need some better ways to deal with the outliers we've gotten.

Later, Mike

h

On 7/29/2025 04:25, Adrian Farrel wrote:

Yes to what Andy says.

 

And we have more recent examples, too. L3SM and L2SM. Both were successful, delivering their planned output in a reasonably short timeframe and then closing.

 

The key, IMHO, is a very tight charter.

But equally important, as Andy explains, is a group of people who actually do the work.

In other, larger working groups, that set of people might be designated a Design Team. In a Tiny WG, it is the whole of the WG (bar tourists).

Critical to the success is that this small group of people represent more than one implementation (aka vendor) and include at least one deployer (aka operator).

 

All of this has to be set up in advance of forming the Tiny WG.

 

But apart from that, why not?

 

A

 

From: Andrew G. Malis <agmalis@xxxxxxxxx>
Sent: 28 July 2025 22:56
To: Michael StJohns <msj@xxxxxxxxxxxxxxxxxx>
Cc: ietf@xxxxxxxx
Subject: Re: "Tiny" working groups

 

Mike,

 

This is nothing new. Back in the 90s, I chaired the frnetmib WG, which had a tight charter and focus, never had more than maybe 10 people at a meeting, but everyone was there to do the work and we got five RFCs done. Well, actually seven, but two of those were updates for previous RFCs.

 

Cheers,

Andy

 

 

On Mon, Jul 28, 2025 at 12:15 PM Michael StJohns <msj@xxxxxxxxxxxxxxxxxx> wrote:

Hi -

Sitting in on the various DISPATCH and DISPATCH-like discussions, I came
to a conclusion that we may be doing ourselves a disservice in the way
we think of WGs. I.e., one size fits all.

Quite a number of the conclusions on the documents or topics were sort
of of the form "could use a WG, but none exists - maybe create one", 
but that comes with a lot of overhead.  E.g. space at the F2F meetings,
chairs, AD oversight, perhaps an overly broad focus? (I intentionally
ignore mailing lists and github repos here as the cost is negligent for
the operation).

What if we define a class of "tiny" WGs, laser focused on a single
topic, with a very short timeframe and with a small (2-3?) permitted
number of documents ALL due at the same time, and with a single chair? 
  No extensions, no recharters, feet to the fire.  Easier to get
chartered, impossible to live more than say 18 months.  Participants
agree to a bit more "chair is in charge" than we usually see or need. 
Ideally, chair is a facilitator, not a participant and/or editor and
chosen by the AD for that purpose.   Chair can kill the WG if progress
isn't being made on schedule.

At any given F2F meeting, there would be 1 or 2 sessions where each tiny
WG would get no more than 15 minutes of talk-talk time.  Any tiny WG
ending before the next F2F would get 30 minutes and that would feed into
an area review of the documents.

Any tiny WG past its expiration date would be required to focus only on
resolving last-call comments from various reviews - no feature creep
permitted.   Datatracker would identify "tiny WG" sourced documents for
the area and ADs would have a set of rules specific to those.

This is sort of a half-formed thought.  It's still *mostly* within the
way the IETF does things from the document point of view, but narrows
the focus of a given tiny WG from the broad to the specific.  And lets
us treat different topics - differently.

Thoughts?

Mike