Re: improving WG operation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Keith,

We largely agree on most of what is in your note, but let me
make a few additional observations...

--On Friday, 29 April, 2005 14:49 -0400 Keith Moore
<moore@xxxxxxxxxx> wrote:

>> Keith,
>> 
>> Let me offer a different perspective here as well and, in the
>> process, explain why I keep coming back to the IESG.
>> 
>> Going back almost to the dawn of IESG time, the IESG has had
>> one constant and primary responsibility.  That is to manage
>> the WGs and the WG process.  Under today's rules, they
>>...

> Without quoting your entire message, let me say that I do
> agree at least partially with this.  But while at least in
> theory, IESG has all of the  authority and mechanisms it needs
> to change working group behavior, let me explain why, in
> practice, I don't think IESG can make the changes that are
> necessary.
> 
> There are many things that IESG cannot do with working groups,
> for a variety of reasons.  
> 
> 1. WG participants are "volunteers".  For the purpose of this
> discussion     it matters not whether they are volunteering
> their own personal      time and energy or whether their
> employers are "volunteering" the     time and energy.  The
>...
> Now, again, in theory IESG can specify all of this to the Nth
> degree, and there are occasions where IESG has specified most
> of these things (one at a time) and made them stick.  But it
> is generally unable to specify most of those things most of
> the time and make them stick.
> 
> It's possible to view this as a scaling problem, but I think
> it's more enlightening to view it as a cultural or education
> problem.  Our culture hasn't developed or accepted the skill
> set that it really needs to do  work on this scale (even
> though some of the individuals do have engineering skills, and
> others have intuition that serves them quite well), and our
> culture has acquired a number of bad habits that are
> counterproductive.

We agree.  How do you propose that gets fixed (see below)?

> So I don't think that IESG is in a good position to fix these
> problems, even though it is in a good position to implement
> the fixes once they are understood and accepted by the
> community.
> 
> The real trick is getting the community to be willing to
> change its  way of operating, and getting the community to
> understand that  acquiring additional discipline in developing
> protocols will produce  better output more quickly - once we
> get used to it.

Ok, we have gotten ourselves into a bit of a mess in how we
handle some things.   Whether one agrees with your specific list
or not, or with the relative importance of particular points, it
is clear that no one (on or off the IESG) can wave a magic wand
and make things perfect.  It is also clear that at least some of
the issues you identify meet my criteria (and Dave's) of having
real impacts on the efficiency, timeliness, and quality of our
processes and results.  Others probably don't.

I suggest that whining, bemoaning our fate, generally sitting
around being miserable, or even casting blame without
identifying solutions, are not only not productive in getting us
to better and more timely results, but may actively distract us
and divert resources from improvements.

It seems to me that there are only three paths out of here:

(1) We know there are other standards bodies out there that, by
their definitions (although not necessarily by ours) are
"successful".  They have formulas for getting things done,
formulas that involve memberships (usually at a price), at least
presumed technical qualifications and approval mechanisms for
participation in working groups, very specific voting rules at
almost every level, including rules about voting by multiple
people from one company, institution, or country, and so on.
They have very specific management and organizational models and
rituals.  They also tend to be characterized by very strong
professional secretariats who end up doing a lot of the
management work that we have assigned to the IESG (or let the
IESG accumulate).  The IETF community has traditionally had
doubts about the quality and/or timeliness of the results from
those bodies, but they do manage to get documents out.   We
could stop what we are doing and emulate them in a greater or
lesser number of ways.

(2) We know that there are standards-producing consortia out
there.  The classic version involves a body organized for the
benefit of a particular cluster of companies, with rather
expensive memberships and participation by people who are not
affiliated with those companies only on a very restricted basis.
They often have elaborate rules for sharing of intellectual
property and about contributions to the consortium as well.
(Note that some consortia, by plan or incremental evolution,
have started to more strongly resemble the above standards
bodies, or other creatures, sometimes even the IETF -- don't get
confused by labels).  They typically have management
arrangements that, among other things, end up dictating their
work plans.  The IETF community has traditionally had doubts
about that model and its products, especially with regard to
openness and quality of review, but they do manage, usually, to
get work done and documents out.   We could stop what we are
doing and emulate them in a greater or lesser number of ways.

(3) We can conclude that we have had --and, I think, still do
have-- something a little bit unique here, with some history of
producing good work that actually permits decentralized networks
to hang together and function reasonably well.  While the IETF
has not been around that long, there are core principles in how
we produce and evaluate work that aren't much different, in
principle, from the way the core ARPANET protocols, TCP/IP,
etc., were produced.  We can even conclude that there is little
point trying to turn into one of those traditional standards
bodies or consortia: they do what they do pretty well, at least
under their definitions.  Maybe those who prefer to work that
way should go to them and we should continue to work with, and
work out, the IETF way of doing things.  If we conclude that it
doesn't work any more because <insert your favorite excuse
here>, then we can either identify that problem and get it
acceptably under control, or it is time to close shop and move
on.

That suggests to me that we need to be on a quest, not for
things to complain about or groups to cast blame on, but for
targets of opportunity that, if changed, might have high
leverage on getting better quality work done and in a more
timely way.   Dave and I may disagree about whether the ISD work
is likely to be worth the amount of trouble that has gone into
it, and others might disagree about likelihood of its success.
But the intent there was to go after something that would have
fairly high leverage on a specific and identified set of
problems that are, themselves, relevant to speed and quality of
output.   The leadership to identify those high-importance,
critical-path problems and possible things to do about them
needs to come from somewhere.  Several of us have been trying to
do just that work from among the masses, even though some
efforts (e.g., the tools one) have been lots more successful
than others (e.g., ISDs and some reorganization attempts).  But
some of that leadership needs to come from what is, you will
recall, called a "steering group"... both because they have a
different, and I pray better, perspective on what might work and
because, especially procedurally, they can block nearly anything
just by bogging it down or picking it to death.   

So I agree with you that there are many things that might be
done that the IESG can't do by themselves.  Some of those things
are just matters in which, if the IESG concludes something is
the right thing to do, they need to educate, and steer, and
lead... rather than having either them, or us, assume that they
can announce or declare something and have everyone salute.  It
seems to me that is A Good Thing, no matter how much more
efficient an imperial regime might be.

Looking at that matter of leverage and the critical path to
significant improvements in quality and timeliness, I've got
doubts about some of your points.  I want to pick on two as
examples, but the issue, for me, isn't whether you are right or
not, but how to think about this:

(i) People are sitting in meeting rooms, with wireless, paying
attention to email, not the work at hand.  I suggest that a
change to this is unlikely to be useful enough to be worth the
trouble.  If they weren't in the room doing email, they might be
asleep.  Or they might be somewhere else doing email.   Neither
case would appreciably increase the number of people in the room
who are making active and useful contributions to the work at
hand. Measured in terms of getting quality work done in a timely
way, those people are the only ones who count.  Sometimes people
who are mostly paying attention to email notice an issue in the
room and make a useful point, and we are better off for that,
however marginally.  Can the added people who aren't paying
attention be annoying?  Sure, but so would loud snoring be.
Would taking away the wireless make a noticeable improvement in
the quality or timeliness of our work (even ignoring arguments
about its value in making materials available, permitting better
off-site participation, etc.)?  Well, I'm unconvinced.

There is also the possibility that some of those who are doing
email are doing so because the S/N ratio in the meeting rooms,
especially for those who have read and thought about the
documents, is just not high enough to take up their full
attention.  You know, I do email in meeting rooms and often
follow the Jabber script of meetings on not in at the same time.
I stop when there is something to which I need to pay attention.
If a WG Chair wants an estimate of my opinion of the S/N ratio
of what is going on in the room, just watch how much I'm typing.
Gee... a clue.  Maybe that is an advantage of wireless :-(.
And that brings me to the Powerpoint problem.

(ii) The first thing to notice about the Powerpoint problem is
that, even more so than the wireless one, it is of fairly recent
origin.  The second is that the "presentations" issue is
actually separate from the powerpoint one, and that the former
has, to one degree or another, always been with us.  Now, for
that problem, the IESG has, from my observation, been letting
WGs do pretty much as they like.  But I'd predict that, if a WG
Chair went to his or her AD and said, "I'm not going to permit
any more presentations", there wouldn't be large pushback.  I'd
also suggest that, if a lot of us started going to ADs, or
standing up in plenaries, and saying "WG X has had nothing but
presentations for the last three meetings and has had no useful
discussions, should it really continue to exist", the ADs might
actually start pushing back on WG chairs about this sort of
thing.  As you know, I'm personally a pretty strong believer in
the "oh, you haven't read the documents, go to the back of the
room and be quiet" school of WG meeting leadership.  I've gotten
a lot of pushback for that, and been called several bad names,
but it has never come from the IESG.    So, on a WG by WG basis,
I suggest what we have met the problem and it is us.   But I
also think the IESG could be doing some more aggressive
leadership in the area _and_ that they would be doing so if more
of the community were obviously supportive.

PowerPoint itself is another issue.  I, personally, hate it for
IETF WG-like meetings, not because of all of the cliche reasons,
but because it discourages real interaction.   When I was able
to walk into a room with a few overhead projector foils and a
handful of colored markers, I could measure how useful and
effective a discussion was by how much more those foils were
marked up by the end of the meeting than they were coming in.
The same comment would apply to flip-chart pads, although they
work less well in larger rooms.  Powerpoint discourages that
sort of interactive markup and revisions.  The more
professional-looking the deck, the harder it becomes to mark up
on the fly.  As a sometime WG Chair, I don't know if I could get
an overhead projector or flip chart back if I asked for them --
I haven't tried and, after this conversation, probably will.
But I certainly know how to turn the projector off and/or
confiscate the connector cord.  Would it have a big impact on
productivity?   I don't really know... it might.  But it is a
really easy experiment and I can't imagine the IESG pushing back
on a WG Chair who made that choice or on an AD who made the
choice for an Area... or even having a lot of sympathy for
someone who came to them whining that the WG Chair had refused
to give them 20 minutes to make a presentation when no one else
was making presentations either.

Conclusion (and you, Keith, are not really my subject/target):
stop complaining and whining.  If the IETF's way of working,
even at its best, isn't an environment in which you think you
can and want to work effectively, go elsewhere.   If you see
ways to make the IETF work better --enough better to be worth
the trouble, the arguments, the debates, and the transition--
make specific suggestions, discuss them here, and discuss them
with the IESG (plenaries have been, IMO, _much_ too quiet lately
and maybe that is a symptom).   If there is a good suggestion
that would have significant positive effects, and that has
strong community support, and the IESG blocks it, then it is
time to get rid of the IESG... either en mass or one AD at a
time until they get the point.  I assume, and hope, it won't
come to that: while I have had, and have, a lot of disagreements
with the way the IESG and individual ADs do business, and I
think things are worse in that regard than they were a
half-dozen years ago, I believe that, on the average day, the
average AD understands that we are all on the same side and will
either succeed or fail together.

     john


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]