Subject: Re: [vmeet] Etherpad deployment for this meeting

From: John C Klensin <[email-masked]>
Date: Sat, 31 Mar 2012 08:57:15 -0400

(copying vmeet)

--On Saturday, March 31, 2012 10:31 +0200 Simon Perreault
<[email-masked]> wrote:

> Henrik,
> 
> I used Etherpad as a minute taker and overall loved it. FYI, I
> found two minor annoyances, don't know if they are already
> known:
> 
> - About every 30 minutes (not exactly sure), it "disconnects"
> and asks me to reconnect. The button is above the page cut (I
> have a small netbook) so it took me a while to notice it. When
> I clicked it I got reconnected without data loss.
> 
> - The "chat" button at the bottom right is in the way when
> typing. It would be better if it was somewhere else.

Let me add two things from the perspective of the remote
participant.

	- I had to manually scroll the window after every lines
	that were typed at the meeting.   Attempts to work
	around that by having the minute taker insert a "this is
	the bottom line" (or equivalent) line and then type
	above it didn't help consistently.   Minor annoyance if
	one is trying to track only the Etherpad but, if one
	needs to also track a Jabber room while paging through a
	slide deck, the behavior becomes enough of a problem to
	make remote viewing of the Etherpad much less useful.

	 - There were a number of WGs in which the Etherpad
	 never came up remotely. Clicking on the link brought
	 up only the "type here..." screen and refreshing
	 didn't change anything.  I had no way to know whether
	 that was some sort of connection problem or whether
	 that particular WG just wasn't using the tool.  I was
	 so busy fighting with other problems that I didn't
	 even bother asking about that on Jabber.

>From the perspective of longer-term RPS use, this suggests
another three "operational" observations (with the same "if it
isn't practically usable for operational reasons, it doesn't
make any difference what the tools are" comment I've made
before).  

(1) If we are going to have a variety of these services floating
around, most of which are optional (I think that at present only
streaming audio and Jabber are not optional) we need to get much
better about telling remote folks that something is not planned
for use in a particular WG.  I'd much rather have links
(preferably from a consolidated agenda rather than a "remote
participation" page) for WebEx and Meetecho that often lead to
"not scheduled for this session" pages than to try to deduce
that from the absence of mention in a table and hoping that I
didn't miss an email message indicating that one or the other
was scheduled late and is expected after all.  Such links can be
updated if needed; then the most the remote participant needs to
do is to reload the agenda page frequently.  

(2) If a WG is not going to use Etherpad, then either the
Chair(s) need to tell the Secretariat (or whomever) that they
don't intend to use it so _that_ link can be pointed to a "not
using this" page or ask someone to explicitly type "WG foo is
not using Etherpad for its minutes" into the Etherpad page,
preferably both.  The latter would permit the remote user to
easily distinguish between intentional non-use (the above
caption) and connectivity/ transmission issues (the "start
typing here" caption) so that the latter could be reported and,
one hopes, fixed.

(3) Just as we have an ongoing discussion about how early slides
need to be posted, but (I believe) no disagreement that they
should be posted, I think we should look at how early a WG's
leadership is expected to get organized about what remote
participation features (including Etherpad) it intends to use.
My recommendation is that we make it part of the meeting request
template and process, making the same procedures for updating
the information that we make for updating agendas and/or the
requests themselves.   I can see very little reason why at least
the intentions of WG Chairs should not be available far enough
in advance of the meeting (previous Monday? Wednesday? Friday?)
to avoid a fire drill during the meeting week.  There will
always be exceptions --if we can change our minds about whether
to hold a meeting or when it will be held after IETF starts, we
should certainly be able to change our minds about a remote
participation tool-- but they should be infrequent enough that
the two suggestions above should be sufficient.

thanks,
     john