Subject: [edu-team] Working group chairs session

From: Avri Doria <[email-masked]>
Date: Thu, 18 Aug 2005 01:04:02 -0400

Hi,

lets start planing this one early this time?

idea?

a.

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

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 18 Aug 2005 07:39:53 -0500

> lets start planing this one early this time?

Paul and I had combined the WG chairs and editor training slides into a 
"leadership" class. Assuming that we want to keep doing this ...

There is about 50 percent overlap between the editor training that Avri 
put together and what the RFC Editor does (we should take this as a 
compliment), so it's probably good to "bite the bullet" and talk about 
combining what the RFC editor thinks matters into the leadership class 
(maybe, maybe not, but people DO wonder which one they are supposed to 
go to, and no one is checking the two tutorials for conflicting 
information, because we don't see each other's slides before the meeting).

We have been talking for just over a year about providing a "new work" 
tutorial. About a month before IETF 63, Paul, Scott and I exchanged 
e-mail about this - we all three had cycles to work on it, but no two of 
us had the same understanding about what "new work" means (is it about 
new contributions to existing work, is it about new work in an existing 
working group, is it about the BOF process, etc.). So it didn't happen.

In the most entertaining part of the exchange, Paul opined that no two 
recent BoFs (that he is familiar with) have enough in common for us to 
use any of them as examples - that seemed like all the more reason to 
use recent BOFs as examples to me - but this should give a good sample 
of how confused we are.

At this point, I'm not sure whether I should be working on a tutorial on 
new work, or on normative text for a BCP/update (2.1 of RFC 2418 states 
the criteria for forming a working group pretty clearly, but it would be 
helpful to give guidance on efficient ways to meet those criteria). 
Obviously(?), normative BCP text isn't an EDU thing. If people have 
opinions on this, private e-mail is appreciated.

In private e-mail, I've been participating in a discussion about how to 
tap available reviewer cycles in the IETF, and one thing that occurs to 
me is that we now have at least one semi-formal Area Review Team, and we 
could probably mobilize more reviewers if we offered training on what 
reviewers should be looking for, when they should be looking, and who 
they should be telling what they find. Avri did an excellent summary of 
the Gen-ART experience to date; this might also make Gen-ART more 
visible to the community (we still startle authors, and sometimes even 
WG chairs, when we send reviews before each telechat).

I could come up with other suggestions, but think I should finish the 
previous suggestions first (because they were good suggestions).

Spencer

---

From: Thomas Narten <[email-masked]>
Date: Mon, 22 Aug 2005 12:01:27 -0400

> tutorial.

FWIW, I have in my head an ID on "how to host a BOF". I intend to get
it out within about 6 weeks.

Most of it will be obvious when read, but will be very useful given
what I saw at the BOFs I attended... :-(

It's also not intended to address the broader question of (say): what
work should the IETF accept.

But we clearly could use a BCP-like checklist-like thing that lists
the things one should do if they want a succesful bof.

some very rough notes, based on what I wrote down during one of the
BOFs...

How to have a successful BOF

ideal
  announce effort/mailing list to IETF list and other relevant WGs
  mailing list
  refinement of problem statement
  chance for folk to submit IDs
  chance for folk to review them
  find agreement on list of common ground
  at about this step, the ADs might be able to credibly say "yes/no"; 
  use BOF to focus on areas where there is no agreement
  circulate proposed charter in advance

general
  focus on problem statement
  to form WG:
    1) show there is agreement that there is a problem that needs
       solving
    2) identify documents that would be needed for "success"  to solve
       problem 
  
  don't get sucked into solutions 

management
  would be useful to have generic possible questions to ask the room
  go over the purpose of asking questions (to gauge the
    understanding/support of the room), to find where there is
    agreement and where not.
  refine questions on list (wording is critical)
  get AD sign off on the specific questions  in advance (maybe even
    post to list in advance ...)

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Aug 2005 11:35:04 +0200

Great idea, but I see it more as a Tao of the BOF than
as a BCP.

    Brian

P.S. A note of any omissions in draft-carpenter-procdoc-roadmap-00.txt
would be very helpful