Subject: [edu-team] Draft Guidelines for EDU Teachers

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Oct 2013 14:37:54 +1300

For comment, with the Word version for anyone who wants to edit.

   Brian

---

From: Radia Perlman <[email-masked]>
Date: Tue, 8 Oct 2013 21:41:21 -0700

Seems OK.  I might want to emphasize that the point isn't deep details of
one thing, but introducing the concepts, including controversies, as in "we
considered these 3 different alternatives, and these were the tradeoffs"
 rather than just "this is the bits and bytes of exactly how this spec
reads".  You kind of say that, though.

I also might want to emphasize that people should avoid acronyms and
area-specific jargon, but you also kind of say that by implying that this
should be aimed at people who are not in that area.

I wouldn't want to go out of our way to exclude various types of tutorials.
 If we actually have too many to choose from, we can select based on
knowing the presenter is interesting and clear, and the topic is wider.
 But for instance, I could imagine a tutorial on compression techniques, or
having NIST explain the methodology they used to whittle down the
contenders for the hash competition.  I suppose the first example
(compression techniques) is obviously useful for lots of different
protocols.  The second example is really just interesting.  Mostly what
IETF people need to know pragmatically is what a "cryptographic hash" is,
and how it's used in protocols.  But if there were lots of people who might
be interested in the methodology that NIST uses to choose one of these
arcane cryptographic primitives, and it wasn't taking up a slot from a more
obviously applicable technical tutorial, it certainly doesn't seem like it
would be harmful in any way, and I'd find it interesting.

Radia

Thanks,

Radia

On Tue, Oct 8, 2013 at 6:37 PM, Brian E Carpenter <
[email-masked]> wrote:

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

---

From: Mirjam Kuehne <[email-masked]>
Date: Wed, 09 Oct 2013 16:42:43 +0200

Thanks for putting this together, Brian.
I think it is good and will help speakers to prepare and to manage their 
expectations. I agree with Radia's comment that in most cases it will be 
more useful to give a broad overview, show the trade-offs and the 
relations to other areas or protocols rather than drilling down into one 
particular solution, but I am not sure how to put this into an 
understandable bullet point.

Shall we put this document on the Edu Team pages so we can point speaker 
to it?

Mirjam

On 9/10/13 3:37 AM, Brian E Carpenter wrote:
> This body part will be downloaded on demand.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Oct 2013 08:33:08 +1300

> Shall we put this document on the Edu Team pages so we can point speaker

Well, let me integrate Radia's comments and any others that come in the
next few days. Then, yes, certainly.

    Brian

---

From: Alice Russo <[email-masked]>
Date: Thu, 10 Oct 2013 17:42:26 -0400

Brian,

Thanks for writing these guidelines. I think they will be useful. What do you think of adding some tips for presenting with remote participants in mind? (Side benefit: these can also be helpful to attendees who do not speak English as their first language.) Perhaps along the lines of:

- At the beginning of the tutorial, provide the URL of the slides so that remote participants can view the materials in their own browsers.

- If the tutorial involves demoing specific tools or pages, consider briefly speaking your actions aloud or having them transcribed to the Jabber room*, so that remote participants can follow without watching your cursor on video.

* Does anyone think that Sunday tutorials should have Jabber rooms? In addition to the function above, it was suggested as a way for a remote participant to point out if there's an issue with the audio or video.

These points arise from feedback from a remote participant that small fonts and mouse-wiggle were not good when trying to follow the Meetecho session of 'Tools for Creating I-Ds' tutorial at IETF 87.

Thanks,
Alice

---

From: Radia Perlman <[email-masked]>
Date: Thu, 10 Oct 2013 14:53:42 -0700

I didn't think we supported remote attendees at the Sunday tutorial in
"real time", nor do I think it matters enough to bother.  If we provide the
slides and a recording, people can look at it later.  If it's available a
few weeks after the event, that should be good enough.

The only reason it might matter is for people asking questions of the
presenter, but they could do it at any time via email.  I think it would be
distracting to try to make sure that remote participation works on Sunday.

Radia

On Thu, Oct 10, 2013 at 2:42 PM, Alice Russo <[email-masked]> wrote:

> Brian,
>
> Thanks for writing these guidelines. I think they will be useful. What do
> you think of adding some tips for presenting with remote participants in
> mind? (Side benefit: these can also be helpful to attendees who do not
> speak English as their first language.) Perhaps along the lines of:
>
> - At the beginning of the tutorial, provide the URL of the slides so that
> remote participants can view the materials in their own browsers.
>
> - If the tutorial involves demoing specific tools or pages, consider
> briefly speaking your actions aloud or having them transcribed to the
> Jabber room*, so that remote participants can follow without watching your
> cursor on video.
>
> * Does anyone think that Sunday tutorials should have Jabber rooms? In
> addition to the function above, it was suggested as a way for a remote
> participant to point out if there's an issue with the audio or video.
>
> These points arise from feedback from a remote participant that small
> fonts and mouse-wiggle were not good when trying to follow the Meetecho
> session of 'Tools for Creating I-Ds' tutorial at IETF 87.
>
> Thanks,
> Alice
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Oct 2013 11:59:21 +1300

Nevertheless, providing slides in advance and documenting the URL
is helpful, and if we're making videos, or even considering people
at the back of the room, careful commentary on demos is important.

Should we be setting up a wiki-style forum for follow-up
of each tutorial?

   Brian

---

From: Mirjam Kuehne <[email-masked]>
Date: Fri, 11 Oct 2013 09:57:52 +0200

On 10/10/13 11:53 PM, Radia Perlman wrote:
> "real time", nor do I think it matters enough to bother.  If we provide
> the slides and a recording, people can look at it later.  If it's
> available a few weeks after the event, that should be good enough.

True. But to make speakers aware that the session is recorded and to 
give them tips on how to make the tutorial useful also for remote 
participants later, can't hurt.

Mirjam

> presenter, but they could do it at any time via email.  I think it would
> be distracting to try to make sure that remote participation works on
> Sunday.
> Radia
>
>
> On Thu, Oct 10, 2013 at 2:42 PM, Alice Russo <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Brian,
>
>     Thanks for writing these guidelines. I think they will be useful.
>     What do you think of adding some tips for presenting with remote
>     participants in mind? (Side benefit: these can also be helpful to
>     attendees who do not speak English as their first language.) Perhaps
>     along the lines of:
>
>     - At the beginning of the tutorial, provide the URL of the slides so
>     that remote participants can view the materials in their own browsers.
>
>     briefly speaking your actions aloud or having them transcribed to
>     the Jabber room*, so that remote participants can follow without
>     watching your cursor on video.
>
>     * Does anyone think that Sunday tutorials should have Jabber rooms?
>     In addition to the function above, it was suggested as a way for a
>     remote participant to point out if there's an issue with the audio
>     or video.
>
>     These points arise from feedback from a remote participant that
>     small fonts and mouse-wiggle were not good when trying to follow the
>     Meetecho session of 'Tools for Creating I-Ds' tutorial at IETF 87.
>
>     Thanks,
>     Alice
>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Alice Russo <[email-masked]>
Date: Fri, 11 Oct 2013 15:58:42 -0400

On Oct 11, 2013, at 3:57 AM, Mirjam Kuehne wrote:

> True. But to make speakers aware that the session is recorded and to give them tips on how to make the tutorial useful also for remote participants later, can't hurt.
> 
> Mirjam
> 

Interesting. Because the sessions can be joined in real-time and the recordings are available afterwards, e.g., see the list on http://ietf87.conf.meetecho.com, I had assumed the presenters should be aware of and support those efforts.

Thanks,
Alice

---

From: Radia Perlman <[email-masked]>
Date: Fri, 11 Oct 2013 13:13:27 -0700

Thinking about "remote" participation, whether it be in real time, or
afterwards, another useful hint to put into the speaker guidelines is
"repeat all questions" (since often even the people in the room can't hear
the question, much less  on the recording, if the question asker isn't at a
microphone).

Radia

On Thu, Oct 10, 2013 at 3:59 PM, Brian E Carpenter <
[email-masked]> wrote:

> the
> be
> that

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Oct 2013 11:33:46 +1300

Updated version attached. That's all I have time for before Vancouver.

I suggest posting the PDF and keeping the word file safe for future updates.

    Brian

---

From: Mirjam Kuehne <[email-masked]>
Date: Fri, 25 Oct 2013 11:07:22 +0200

Hi,

Just FYI:

Stephanie put the document at the bottom of this page:
http://www.ietf.org/edu/team-responsibilities.html

Regards,
Mirjam