[personal disclaimer: I have participated remotely, a few times, and I agree 
that it's not the same as being there, and I agree that it could be improved.  
But I think we need to balance the needs of remote participants, vs. the goals 
of physical meetings: to get work done that can only get done with direct human 
interaction, with real-time interactive discussion, and hallway co-mingling, 
etc.  In my opinion being remote will *never* be the same as being there, and 
that's why we have physical meetings to begin with, instead of just virtual 
ones - ultimately I want you to come to the meeting *physically*... but I want 
to do as much as possible and *practical* to accommodate remote participants, 
because I know not everyone has the luxury to come, and I want their input 
regardless.]


I think one challenge with this discussion, at least for me, is that it feels 
like the solutions being proposed are completely out of whack with the severity 
and nature of the problems at hand, and the people they apply to.  Adding more 
rules and processes is about the surest way I know to annoy engineers, let 
alone volunteer ones.  And if your right hand is sore, you don't cut it off and 
replace with a mechanical one, or go build a billion-dollar robot to be 
controlled by brain-waves.

People on this list are saying things like "we don't know who's at the mic", 
and "we can't see the slides well enough", and "presenters are hard to follow". 
 ISTM there are practical and low-tech means of fixing those problems.

Here're some ideas of possible solutions - but most of these boil down to 
either "have WG Chairs do their job", or "get over it":

Problem-1: we don't know who's at the mic, because people forget to say their 
names.
Solution: (a) train WG Chairs to remind people at mic, and interrupt them if 
they haven't said their names, (b) have jabber scribes sit next to mics, to do 
the same as WG chairs, (c) if chairs and scribes forget, send a chat message in 
jabber to remind them.  Is it annoying?  Sure.  Will it sometimes fail to work? 
 Sure.  But every other solution will also be annoying and not always work, and 
this solution is very low-tech and simple.  This is what happens in RAI area WG 
meetings, and appears to work afaict.  If it doesn't work, then we go to a 
Plan-B in the future.

Problem-2: we can't see the slides well enough, in video.  Meetecho is ok, but 
they don't cover all meetings.
Solution: we pay Meetecho to cover all WG meetings.  Last time I checked, we 
weren't paying them anything; but if we really want that type of technology in 
all meetings, then it's only fair to pay them. (frankly we should be paying 
them now already)  We also need to remind people to use reasonable font size.  
10pt is bad mojo even in the physical room.  That type of thing is what a WG 
chair should be telling people, though - we don't need slide police.

Problem-3: presenters are hard to hear/follow/understand.
Solution: that's life.  We're a volunteer organization, not trained 
professional thespians.  We have drafts written in plain ascii available in 
advance, and audio, and video, and jabber, and (hopefully) Meetecho-type 
service, and that's about as good as it can reasonably be.

Problem-4: we want slides 7 days in advance to translate to our native language
Solution: You're doing it wrong - or rather, the presenters are doing it wrong. 
 The slides aren't a replacement for drafts, or a copy-paste of draft text.  WG 
Chairs know this, and should remind presenters of it.  As an aside, if you 
really need a week to translate them, it's highly unlikely you'll be able to 
truly *participate* interactively during the meeting - and you don't need to be 
real-time if all you're going to do is listen/watch - we record the whole thing 
for your later viewing pleasure.

Problem-5: we want slides 48 hours in advance to translate to our native 
language, download it, etc.
Solution: sounds reasonable.  Have WG chairs use 48 hours as their guideline, 
but not as a strictly enforced rule a la I-D submission deadlines.  WG chairs 
can figure out when exceptions need to be made, how to deal with it, etc.  We 
don't need this in an RFC.

Problem-6: if you change slides, I don't know which slides you changed
Solution: it happens, and that's life.  You've got to follow the speaker's 
words, not a published script.  The point of these meetings is for real-time 
discussion on relevant matters that can only be handled live.

Problem-7: 

-hadriel


On Aug 8, 2013, at 10:43 AM, John C Klensin <john-i...@jck.com> wrote:

> --On Tuesday, August 06, 2013 11:06 -0400 Andrew Feren
> <andr...@plixer.com> wrote:
> 
>> ...
>> I think this sort of misses the point.  At least for me as a
>> remote participant.
>> 
>> I'm not interested in arguing about whether slides are good or
>> bad. I am interested in following (and being involved) in the
>> WG meeting.  When there are slides I want to be able to see
>> them clearly from my remote location.  Having them integrated
>> with Meetecho works fine.  Having slides and other materials
>> ...
> 
> Let me say part of this differently, with the understanding I
> may be more fussy (or older and less tolerant) than Andrew is...
> 
> If the IETF is going to claim that remote participation (rather
> than remote passive listening/ observation with mailing list
> follow up) is feasible, then it has to work.  If, as a remote
> participant, I could be guaranteed zero-delay transmission and
> receipt of audio and visual materials (including high enough
> resolution of slides to be able to read all of them) and that
> speakers (in front of the room and at the mic) would identify
> themselves clearly and then speak clearly and at reasonable
> speed, enunciating every word, I wouldn't care whether slides
> were posted in advance or not.  
> 
> Realistically, that doesn't happen.  In some cases (e.g.,
> lag-free audio) it is beyond the state of the art or a serious
> technical challenge (e.g., video that is high enough resolution
> that I can slides that have been prepared with 12 point type).
> In others, we haven't done nearly enough speaker training or it
> hasn't been effective (e.g., people mumbling, speaking very
> quickly, swallowing words, or wandering out of microphone or
> camera range).   And sometimes there are just problems (e.g.,
> intermittent audio or video, servers crashing, noisy audio
> cables or other audio or video problems in the room).   
> 
> In those cases, as a remote participant, I need all the help I
> can get.  I'd rather than no one ever use a slide that has
> information on it in a type size that would be smaller than 20
> pt on A4 paper.  But 14 pt and even 12 pt happen, especially if
> the slides were prepared with a tool that quietly shrinks things
> to fit in the image area.  If I'm in the room and such a slide
> is projected, I can walk to the front to see if if I'm not
> already in front and can't deduce what I need from context.  If
> I'm remote and have such a slide in advance, I can zoom in on it
> or otherwise get to the information I need (assuming high enough
> resolution).  If I'm remote and reading the slide off video,
> especially low resolution video, is hopeless.  
> 
> More generally, being able to see an outline of what the speaker
> is talking about is of huge help when the audio isn't completely
> clear.  Others have mentioned this, but, if I couldn't read and
> understand slides in English easily in real time, it would be of
> even more help if I had the slides far enough in advance to be
> able to read through them at my own pace before the WG session
> and even make notes abut what they are about in my most-familiar
> language ... and that is true whether I'm remote or in the room.
> 
> And, yes, for my purposes, 48 hours ahead of the WG meeting
> would be plenty.  But I can read and understand English in real
> time.  If the IETF cares about diversity as well as about remote
> participation and someone whose English is worse than mine is
> trying to follow several WGs, 48 hours may not be enough without
> requiring a lot of extra effort.
> 
> That is not, however, the key reason I said "a week".  The more
> important part of the reason is that a one-week cutoff gives the
> WG Chair (or IETF or IAB Chairs for the plenaries) the time to
> make adjustments.  If there is a nominal one week deadline, then
> the WG Chair has lots of warning when things don't show up.  She
> can respond by getting on someone's case, by accepting a firm
> promise and a closer deadline, by finding someone else to take
> charge of the presentation or discussion-leading, or by
> rearranging the agenda.  And exceptions can be explained to the
> WG on the mailing list.  With a 48 hour deadline, reasonable
> ways to compensate are much less likely, the Chair is likely to
> have only the choice that was presented this time (accepting
> late slides or hurting the WG's ability to consider important
> issues) and one needs to start talking about sanctions for bad
> behavior.   I would never suggest a firm "one week or no agenda
> time" rule.  I am suggesting something much more like a "one
> week or the WG Chair needs to make an exception, explain it to
> the WG, and be accountable if the late slides cause too much of
> a problem".  There is some similarity between this and the
> current I-D cutoff rule and its provision for AD-authorized
> exceptions.  That similarity is intentional.
> 
> 
> --On Monday, August 05, 2013 13:36 -0500 James Polk
> <jmp...@cisco.com> wrote:
> 
>> At 12:38 PM 8/5/2013, John C Klensin wrote:
>>> Hi.
>>> 
>>> I seem to have missed a lot of traffic since getting a few
>>> responses yesterday.  I think the reasons why slides should be
>>> available well in advance of the meeting have been covered
>>> well by others.  And, as others have suggested, I'm willing
>>> to see updates to those slides if things change in the hours
>>> leading up to the meeting, but strongly prefer that those
>>> updates come as new alides with update-type "numbers" or other
>>> identification rather than new decks.  In other words, if a
>>> deck is posted in advance with four slides numbered 1, 2, 3,
>>> and 4, and additional information is needed for 3, I'd prefer
>>> to see the updated deck consist of slides 1, 2, 3, 3a, 3b, 4
>>> or 1, 2, 3a, 3b, 3c, 4, rather than 1, 2, 3, 4, 5, 6.
>> 
>> How exactly do you do this in pptx? Numbering slides is a
>> linear operation AFAICT, and it's binary (it's either on or
>> off). Please educate me if I'm wrong; lord knows I don't know
>> don't know how to do everything flag/setting in powerpoint...
> 
> Hmm.  First, I missed the IESG Statement requiring the people
> use pptx or any other particular piece of
> presentation-preparation software, much less the IETF consensus
> for that statement.  If the tools you choose to use don't meet
> the needs of the IETF, that doesn't seem to me to be an IETF
> problem.
> 
> Second and more important, while having slide preparation
> software number pages, I'm not aware of anything that prevents
> you from typing in numbers, especially with something that is as
> inherently page (slide)-oriented as presentation-preparation
> software.  Yes, it is an annoyance, but having the need to
> update slides within a short interval before the meeting/
> presentation/ discussion is an annoyance to participants who
> depend on the ability to access those slides and who might want
> to prepare reference or discussion notes in advance.
> 
>> And, in my 8 years as TSVWG chair, I've rarely had completely
>> new individual slides sprinkled throughout an existing deck.
>> Rather, I've received updated slides - each with part of their
>> content altered. Does this fall into your desire for a "3a",
>> or is that just "3" (because 3a means an entirely new slide
>> from scratch)?
> 
> 3a.  
> 
>> BTW - I'm very much *not* in favor of stipulating to my WG
>> that slides must be turned in 7 days in advance of a TSVWG
>> meeting. I personally think no more than a 48 hour advanced
>> window should ever be considered.
> 
> See above.
> 
>   best,
>   john

Reply via email to