Subject: Re: [edu-team] Action Items from the meeting

From: Thomas Narten <[email-masked]>
Date: Fri, 03 Mar 2006 09:48:31 -0500

Looking at the charter, and thinking about what I'd like to see EDU
focus on...

One way to look at the IETF document production process is from an
engineering perpsective. It has often be asserted that we don't even
use good engineering techniques in our _processes_. Thus, I'd like to
see a broad focus on ways to improve our processes. Not through
"process changes", but through changes in the way we operate.

Some thoughts:

WGs are often not run like software projects. I.e., where realistic
milestones are laid out, there are frequent and regular checkpoints on
progress, with the folks who have action items being held
accountable. A lot of this is Management 101, but sadly, we are pretty
weak in this area in a lot of WGs. ADs can help here (by regularly
asking chairs for status reports), but the real responsibility lies
with chairs.

Tools can help here, and we have a tools team. But tools are only good
when they get used. We still have a lot of WGs that aren't using issue
trackers. But issue trackers are hugely beneficial, in that they make
visible recordings of all issues, and transparent handling of all
issues. One of the big issues WGs have is issues that get raised that
fall through the cracks. Bad for process, bad for moral (who likes to
review, only to have their reviews ignored?), etc.

There are good ways and ineffective ways to use mailing  lists for
resolving issues. Focus on this area (not just for chairs, but for
editors (trying to figure out what the WG wants in a document) and
other participants (i.e., how to raise  issues effectively),
etc. There is clearly work to be done here.

The entire topic of consensus building. How to peel the layers of the
onion to have the WG figure out what it agrees on, what it doesn't,
and then how to make progress on those issues where there is
disagreement (or lack of understanding, as is often the case).

How to structure protocol documents, to make them easier to
read/understand/implement. For example, we have a wealth of experience
on how to structure documents so that they are readable. But many
documents don't follow that. E.g., start with a good high-level
overview. Lay out the security model (or lack thereof). Lay out the
packet formats. Then describe the protocol behavior, but organize it
in ways an implementor would find useful, e.g., by having all the
sender actions in one place (for a particular message type) and same
for receiver actions. Scattering stuff in random ways throughout a
document makes it hard to figure out what is going on. (I've actually
got a note on this somewhere, as I've found it necessary in the past
to send out such recommendations after reviewing a document)

Sorry if this is a bit rambling, but its the above sort of issues that
I think the IETF needs to do better at, and it seems like EDU is the
best place to try and do something.

Thomas

_______________________________________________
edu-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/edu-team

---

From: "Margaret Wasserman" <[email-masked]>
Date: Fri, 3 Mar 2006 12:30:03 -0500

> Sorry if this is a bit rambling, but its the above sort of 
> issues that I think the IETF needs to do better at, and it 
> seems like EDU is the best place to try and do something.

As usual, I agree with your rambling...  :-)

Seriously,  we need to find the time to sit down and come up with at most 3
or 4 changes that we want to effect in the IETF that fall into this
category...

>From there, we can develop a plan to effect those changes.  The plan might
include teaching specific classes, modifying existing classes, presenting
topics in the WG chairs lunch, writing educational I-Ds and/or wiki pages,
feeding input into the tools team and/or the secretariat, presenting in
plenary, holding BOF-like meetings, etc.

We have a lot of tools available to us and we have people with time and
energy.  What we seem to be lacking is a vision for how we can improve the
IETF through the process of educating people, and I think that your note
captures several ways that we could do that.

I think it is important that our goals not be at the level of "we should
have a class on this".  They should be at the level of "Here is a serious
problem with how we do things in the IETF.  Let's teach the whole
organization (by creating a culture shift) to do this better!".

Margaret

(Who is looking forward to having more time to work on these types of
things.)