Re: Requirements for improving IETF remote participation

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

 



At 14:05 05-01-2012, Paul Hoffman wrote:
This first draft compiles many (but certainly not all!) of the comments I have heard so far, but I expect it to change a fair amount in the coming months. If you are active in the IETF, even if you rarely or never come to IETF meetings, your input is welcome.

  'There are two types of participants at the three-times-a-year IETF
   meetings: those who are at the meeting in person ("local attendees")
   and those who are not at the meeting in person but participate by
   following the meeting online ("remote attendees").'

There are more than two types of participants:

  (a) The old boys club

  (b) usual attendees

  (c) "local" attendees

  (d) people who follow the work to see what is going on

  (e) remote attendees

In Section 2:


  "Bar BoFs at regular IETF meetings are not listed above
   because they mostly happen in places where remote participation can't
   be scheduled."

Aren't Bar BoFs informal? There are also BoFs and "side-meetings" (draft-eggert-successful-bar-bof-06).

In Section 3:

  "Some participants think the tools are fine and are grateful that they
   exist"

Some participants are grateful because they don't take things for granted.

  "Local attendees don't have a feeling for how many remote attendees
   are just listening like most of the local attendees."

Local attendees do not care about remote participants. It is left to the reader to determine whether participant (b) gives any thought to from participant (c) (language issue).

  "The IETF has years of experience with the two primary tools used at
   its regular meetings"

And yet the same issues occur again and again.

  "At recent IETF meetings, remote attendance is almost always
   less than 10% of local attendance, and is often less than 5%."

It would be interesting to compare local and remote contributions as attendance can be passive.

  "Further, a WG chair might copy the latest information and send it
   to the WG mailing list, but there can be later changes."

Please see "Topics to Add" at http://wiki.tools.ietf.org/group/wgchairs/ There hasn't been a lot of contributions to that web page over the last five years. The community has a culture of arguing against each other and getting RFC published as quickly as possible instead of contributing.

In Section 3.2.3:

  "It has become fairly common for presenters to not have their
   presentations available for distribution until just before the WG
   meeting."

http://www.ietf.org/mail-archive/web/ietf/current/msg70388.html

The following working groups have not submitted their minutes:

 DHC
 PCP
 SOFTWIRE
 TRILL
 MULTRANS (BOF)
 RADEXT
 AVTCORE
 AVTEXT
 CODEC
 P2PSIP
 VIPR
 TSVWG

Is it fairly common for WG Chairs to do nothing until an AD complains?

In Section 3.3:

  "This method of participation often works adequately, but there are
   many places where it fails."

The problem is the audio delay. Even if the delay was a few seconds only, that would still happen as it is difficult to manage the in-room discussion and remote participation at the same time.

  'The presentation ends and is over time, so Carl says "we need
   to move on", so Robert never gets to ask his question.'

And it can discourage Robert from further participation.

  "Sam only volunteered to be scribe because no one else would do it"

Instead of asking for scribes, it might be helpful to explain what is required of a scribe and see that people are not disadvantaged from participating when they volunteer.

In Section 3.4:

  "Although the previous section may seem like it is a bit harsh on WG
   chairs"

Stating the facts can be a harsh.

  "Chris cannot do something about the situation without making
   Sam look bad."

And the WG Chair ends up looking bad.

In Section 3.5, I'll mention that Meetecho can also be used for remote presentations (I suggest asking them about the details instead of assuming anything). The problem with any tool is that people expect them to work. Some people do not pay attention to the details and that can cause last minute surprises.

In Section 4:

  "Meeting rooms have many mics: one or two for the chairs,
   one for the presenter, and at least one for other local attendees to
   ask questions."

And sometimes the mic does not work.

In Section 4.1.2:

  "Remote attendees who are speaking over the
   audio must be visible to the local attendees."

That's not a good idea if the remote participant is many time zones away. :-)

In Section 4.1.3:

  "The instant messaging system must allow any registered user (even
   those registered anonymously) to post messages in the WG's or BoF's
   room."

Isn't the current XMPP approach workable? What is the meaning of "those registered anonymously"?

In Section 4.1.4:

  "The input format for slide presentations must  be either PDF
   or PowerPoint."

See long thread at http://www.ietf.org/mail-archive/web/ietf/current/msg70422.html about PPTX.

In Section 4.2.1:

  "There is no such confusion in the room of local attendees
   because everyone has a name badge."

There is confusion in the room as the name badge may not be visit or for other reasons.

  "The RPS tools must be available for lunch meetings scheduled by
   the IETF Secretariat, such  as for the Security Directorate"

I object to the non-inclusion of the kangaroo directorate (no offense intended). :-)

In Section 4.2.2:

  "Mixing remote attendees into this social structure will be a daunting
   task, but one that has been dealt with in many remote participation
   systems"

This is using a technical solution to solve a social problem. Going back to my first comment, participant (c) can be useful input to participant (e) as they share similar constraints.

  "It is not yet clear how the set of remote attendees would be treated."

The same way participant (a) treat participants from outside their group.

in Section 4.4:

  "At recent IETF meetings, there has been very little input from remote
   attendees even when there is a lot in the room, but that may be due
   to the current setup, not lack of interest."

It's difficult to figure which audio stream is available for the plenaries. There isn't anyone to channel questions to the mic.

While a lot of the issues covered in draft-ietf-genarea-rps-reqs-00 affect remote participation, they fall outside the scope of the IAOC. A session with 20 attendees does not have the same dynamics as one with 200 attendees. 25% participation in the first group is workable; it's not for a wider group. The Remote Participation Services takes a one size fits all approach. I suggest not trying to solve all the problems at once. The social issues could be discussed in a separate document. As for the technical issues, the requirements could target a small and manageable audience. It might be a way to gain more experience about the problems (identify what works, what can be addressed without too much effort, and what cannot be fixed). This could be done as an experiment.

The alternative is to pursue the current approach. WG Chairs might be blamed for problems outside their control.

On an unrelated note, the newcomers training is a failure. It tries to cover too much in a limited amount of time. There is limited interaction.

Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


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