Subject: Re: [111attendees] [Tools-discuss] Positive observations and proposals for improvements to Meetecho (was: Re: Re: So, what are jabber scribes actually doing, these days?)

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Aug 2021 16:37:14 -0400

Bron Gondwana <[email-masked]> wrote:
    > *a "temporary mute" mode that keeps the audio stream open:*

    > This is still an issue for me.  I often mute myself while chairing so I
    > can take notes without my keyboard sound interrupting the chat - but it
    > means that I can't easily respond to somebody because the rejigging of
    > the audio channel not only creates a hiccup in the incoming audio feed
    > which means I might miss something someone says, but it also creates
    > enough of a delay that by the time I could have responded the other
    > party's mental state has moved on.

Yes, the 3s on/off latency on the audio is a problem.
So one should use a local mute instead, which of course, then causes confusion.

    > Timing is really important in conversation and we're already fighting
    > with the quarter second delay imposed by the size of the planet.
    > Additional delay makes it unwieldy.

Ah... I know of a genetically spliced lab mouse with a plan to reduce the size of the planet.

    > *allow multiple connections by the same person to the same session:*

    > I have multiple times wanted to switch device temporarily - from my
    > desktop computer to a phone / ipad so I can temporarily move to another
    > location while continuing to follow a meeting.  Multiple connection
    > support would mean I could switch over without a break.

It seems like a stretch requirement, but I also know that some chairs want a
second laptop so that they can see whether slides are really advancing.
What I don't understand is, 16 months into pandemic, and 10 years into screen
sharing, how it is that PPT people don't understand that they have to "F5"
before they share.

    > Sure it could be abused by people "sharing" a login, but that would be
    > pretty obvious if both parties tried to participate, and given that we
    > allow fee waivers anyway, it's unlikely to be abused significantly.
    > Sure there are Jabber naming issues, but we can avoid that by giving
    > each jabber name with a serial number (which I believe already happens
    > now?)

Yes. Actually, the ephermalness of the jabber names annoys me, as I can't
message people after they have left.

    > *information about who is speaking in the same place as video feeds*

The video image does do the yellow square when they are speaking.

    > See my previous email :)  Basically the "participant list" should just
    > be an ordered list of participants and only needs to be switched to
    > when seeing who is in the call or opening an individual message to them
    > (and people don't get moved out of order when they're sending
    > something).  The "who is sending something" list should be all together
    > with the video, and chairs pinned even if they're sending nothing right
    > now.

I think that I need a picture.
As my meetecho windows are more vertical than horizontal, I'd also like to be
able to move the video boxes to be under the slides.
see:  https://www.sandelman.ca/mcr/IETF111-virtual-SFO-two-sessions.png

    > Along with visual indicators of "currently sending audio" on people so
    > we know who of those with their audio channel open are currently
    > speaking, this makes it easier to look in one place to see the source
    > of all sound, and eyes can generally flit between the right hand side
    > (video and audio indicators) and the slides, without needing to also
    > track via the participant list.

I think that it would also work better for the youtube recording.

    > *flexible "assign chair"**:*

    > This one hasn't come up in practice, but the chairs for meetings are
    > pre-assigned from datatracker.  It would be great for ADs and the
    > meetecho reps in each meeting to be able to upgrade anybody to a chair
    > role or remove a chair role with a simple click.

That's a good idea.
And with that power, they should be able to advance slides, no matter who
activated them.

    > This has become less important with the ability for individuals to turn
    > on both audio and video themselves, so the chair is going less busywork
    > just approving access, but it would be good to make it possible for
    > someone else to step into the chair if the regular chairs are unable to
    > attend or lose network, rather than making the meeting less able to
    > run.

I'd like the chair to be able to pre-authorize sharing and slides.
Actually, the way I'd implement is that the chair(s) just get to decide who
of the possibly many screen-sharing/slides that are occuring, who is actually
shared.

That lets people (a) test their setup in advance of their slot,
(b) reduce the time to switch.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 1 Aug 2021 13:40:34 -0700

> So one should use a local mute instead, which of course, then causes

Actually, this is not necessary. WebRTC contains APIs which allow you to
mute
the media locally. The delay in Meetecho is a result of the decision to
release
the MediaStream which then needs to be re-acquired, which is not what
Meet, Zoom, etc. do.

-Ekr

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 2 Aug 2021 14:10:15 +0300

> I think that I need a picture.

So, currently we have the Chairs and any "active" participants (hand
up, mic and/or camera open, presenting slides or screen) moving
dynamically to the top of the Participants list on the left.  This
makes it easy to find the Chairs, but if looking for a particular
person in the list, you have to check both the top of the list and
their alphabetical position, since their dynamic status could place
them either way.  By default the Participants list is also hidden when
you're reading the chat, and vice versa.  And currently the list of
video thumbnails on the right is *strictly* those people with a camera
open, whether or not they have the mic open or are active in some
other way.

The proposal here is to include *anyone* who would normally be moved
to the top of the Participants list in the list of video thumbnails,
and make the Participants list mostly static (only Chairs at the top).
The thumbnail for people without a camera on would be the profile pic
if they have one, supplemented by the appropriate participation icons
(hand, microphone, screen, slides).  This gives a natural place to
show speaking cues, so you can see at a glance who is actually
speaking.

> able to move the video boxes to be under the slides.

This also seems like a valid optimisation of screen real estate.  The
thumbnail list should lie along the edge of the window that is least
pressured by the presentation area.

 - Jonathan Morton

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 2 Aug 2021 12:25:27 -0500

On Fri, Jul 30, 2021 at 4:14 PM Eric Rescorla <[email-masked]> wrote:

>
> To your list, I would add auto-unmuting (and even more importantly,
> muting) when people enter and exit the head of the queue. This would remove
> a lot of goofy behavior.
>

Yeah, and I'd suggest auto-muting video when you leave the queue, just
because "lowering your hand" could mean "I'm out of the line, I don't have
anything else to say, and you don't need to see me any more".

That would have fixed all *my *goofy Meetecho behavior. Fixing goofy things
I say with audio enabled is, of course, harder ...

Best,

Spencer

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 2 Aug 2021 10:48:01 -0700

One use of the Meetecho recording is to prepare minutes by double checking notes.  One issue with that is that sometimes a presenter answers comments made in the chat, but the chat log does not appear in the recording.  The person preparing the minutes now has to open the minutes, try to synchronize then with the recording and update the minutes to reflect the question/comment that triggers the response by the presenter.  There is two issues with that:

1. Someone watching only the recording only have access to half of that conversation and may not know where the chat logs are, or even that they was a chat running along the session.
2. People taking notes must follow both the chat and the presenter, which could be a bit too much.

I do not think that recording the chat at the same time than the presenter would be a good idea (OTOH displaying the name of the person talking in the recording even if they did not turn on video would help).  The reason is that not all the content of the chat log is relevant for the WG business (that's an understatement).

Having a jabber scribe and some discipline may help: The jabber scribe repeats the chat comment/question, and the presenters does not try to look at the chat, and so now the whole context is captured.

But that's still a bit clunky -- a presenter may want to comment on something that someone said in the chat room even if it was not marked as a question that the Jabber scribe must relay.  After all the chat logs are under NOTE WELL, so they are part of the WG session -- and should be part of the minutes, at least the relevant parts.

My suggestion would be to use TTS to supplement or replace the Jabber scribe.  A remote presenter who want to answer/comment on a chat message triggers TTS on the message itself, which now becomes part of the recording -- and of the minutes.  With a local presenter the Jabber scribe could also use that TTS feature.

On 7/30/21 12:38 PM, Meetecho IETF support wrote:
> All,
> 
> chiming in just to say that we at Meetecho appreciate and value your feedback. We'll definitely take it into account when developing the future releases of the platform. We'll provide comments on the points raised as soon as we get the chance to parse them, i.e., when the meeting is over.
> 
> Also, I'm cc'ing [email-masked] and setting the reply-to header to that list as well, as that's the right place to discuss enhancements and provide feedback that would be easier for us to collect.
> 
> Best,
> Alessandro
> 
[...]

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Aug 2021 14:44:58 -0400

Jonathan Morton <[email-masked]> wrote:
    > The proposal here is to include *anyone* who would normally be moved to
    > the top of the Participants list in the list of video thumbnails, and
    > make the Participants list mostly static (only Chairs at the top).  The
    > thumbnail for people without a camera on would be the profile pic if
    > they have one, supplemented by the appropriate participation icons
    > (hand, microphone, screen, slides).  This gives a natural place to show
    > speaking cues, so you can see at a glance who is actually speaking.

I understand now. This would be good.

    >> As my meetecho windows are more vertical than horizontal, I'd also
    >> like to be able to move the video boxes to be under the slides.

    > pressured by the presentation area.

+1

---

From: gang Antgam <[email-masked]>
Date: Tue, 3 Aug 2021 02:53:54 +0430

در تاریخ دوشنبه ۲ اوت ۲۰۲۱،‏ ۲۲:۱۸ Marc Petit-Huguenin <
[email-masked]> نوشت:

> One use of the Meetecho recording is to prepare minutes by double checking
> notes.  One issue with that is that sometimes a presenter answers comments
> made in the chat, but the chat log does not appear in the recording.  The
> person preparing the minutes now has to open the minutes, try to
> synchronize then with the recording and update the minutes to reflect the
> question/comment that triggers the response by the presenter.  There is two
> issues with that:
>
> 1. Someone watching only the recording only have access to half of that
> conversation and may not know where the chat logs are, or even that they
> was a chat running along the session.
> I do not think that recording the chat at the same time than the presenter
> would be a good idea (OTOH displaying the name of the person talking in the
> recording even if they did not turn on video would help).  The reason is
> that not all the content of the chat log is relevant for the WG business
> (that's an understatement).
>
> Having a jabber scribe and some discipline may help: The jabber scribe
> repeats the chat comment/question, and the presenters does not try to look
> at the chat, and so now the whole context is captured.
>
> But that's still a bit clunky -- a presenter may want to comment on
> something that someone said in the chat room even if it was not marked as a
> question that the Jabber scribe must relay.  After all the chat logs are
> under NOTE WELL, so they are part of the WG session -- and should be part
> of the minutes, at least the relevant parts.
>
> My suggestion would be to use TTS to supplement or replace the Jabber
> scribe.  A remote presenter who want to answer/comment on a chat message
> triggers TTS on the message itself, which now becomes part of the recording
> -- and of the minutes.  With a local presenter the Jabber scribe could also
> use that TTS feature.
>
> > chiming in just to say that we at Meetecho appreciate and value your
> feedback. We'll definitely take it into account when developing the future
> releases of the platform. We'll provide comments on the points raised as
> soon as we get the chance to parse them, i.e., when the meeting is over.
> >
> > Also, I'm cc'ing [email-masked] and setting the reply-to header
> to that list as well, as that's the right place to discuss enhancements and
> provide feedback that would be easier for us to collect.
> >
> > Best,
> > Alessandro
> >
> [...]
>
> --
> Marc Petit-Huguenin
> 111attendees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/111attendees
>

---

From: gang Antgam <[email-masked]>
Date: Tue, 3 Aug 2021 02:54:11 +0430

در تاریخ دوشنبه ۲ اوت ۲۰۲۱،‏ ۲۱:۵۶ Spencer Dawkins at IETF <
[email-masked]> نوشت:

> That would have fixed all *my *goofy Meetecho behavior. Fixing goofy
> things I say with audio enabled is, of course, harder ...
>
> Best,
>
> Spencer
> --

---

From: gang Antgam <[email-masked]>
Date: Tue, 3 Aug 2021 02:55:00 +0430

---

From: gang Antgam <[email-masked]>
Date: Tue, 3 Aug 2021 02:55:52 +0430

---

From: gang Antgam <[email-masked]>
Date: Tue, 3 Aug 2021 02:56:06 +0430

---

From: gang Antgam <[email-masked]>
Date: Tue, 3 Aug 2021 02:58:54 +0430

در تاریخ شنبه ۳۱ ژوئیهٔ ۲۰۲۱،‏ ۱:۴۵ Eric Rescorla <[email-masked]> نوشت:

>
>
> On Fri, Jul 30, 2021 at 2:03 PM Bron Gondwana <[email-masked]>
> wrote:
>
>> Ooh, we're going a full "suggestions for meetecho" thread?  I'd like to
>> propose some things!
>>
>> *that we replace the current "raise hands" tool:*
>>
>> *... *which is based on an expired draft which isn't going to be
>> refreshed - with a better tool that allows the chairs to:
>>
>> a) label each option
>> b) have more than 2 options (max 9 maybe)
>> c) select between "choose one" and "choose N" modes (checkbox vs radio
>> button)
>>
>> ... and which appears IN PLACE of the slides when enabled, so that
>> meeting participants don't have to navigate to a separate tab to interact.
>>
>> More generally, it's too easy for some participants to be lost on
>> different tabs where they can't see the slides.  The multiple views where
>> you can see individual talking heads in more detail are not actually
>> valuable I don't think - if slides are showing they should be the bulk of
>> the screen because they need to be read - and if a poll is showing then for
>> sure it should be taking over the screen.
>>
>
> EKR Raises Hand.
>
>
>> means that I can't easily respond to somebody because the rejigging of the
>> audio channel not only creates a hiccup in the incoming audio feed which
>> means I might miss something someone says, but it also creates enough of a
>> delay that by the time I could have responded the other party's mental
>> state has moved on.
>>
> Note that this is a respect in which Meetecho is unusual. Most other VC
> systems which I am familiar with just stop sending on the track but keep
> the microphone open rather than dropping the media stream and re-calling
> getUserMedia().
>
>> location while continuing to follow a meeting.  Multiple connection support
>> would mean I could switch over without a break.
>>
>> allow fee waivers anyway, it's unlikely to be abused significantly.  Sure
>> there are Jabber naming issues, but we can avoid that by giving each jabber
>> name with a serial number (which I believe already happens now?)
>>
>> ...
>>
>> I've already written these up separately in the past, but:
>>
>> See my previous email :)  Basically the "participant list" should just be
>> an ordered list of participants and only needs to be switched to when
>> seeing who is in the call or opening an individual message to them (and
>> people don't get moved out of order when they're sending something).  The
>> "who is sending something" list should be all together with the video, and
>> chairs pinned even if they're sending nothing right now.
>>
>> Along with visual indicators of "currently sending audio" on people so we
>> know who of those with their audio channel open are currently speaking,
>> this makes it easier to look in one place to see the source of all sound,
>> and eyes can generally flit between the right hand side (video and audio
>> indicators) and the slides, without needing to also track via the
>> participant list.
>>
>> pre-assigned from datatracker.  It would be great for ADs and the meetecho
>> reps in each meeting to be able to upgrade anybody to a chair role or
>> remove a chair role with a simple click.
>>
>> In real rooms, anyone can go sit in the chair at the front of the room,
>> and it's not abused because of social convention.  I believe that we can
>> map that to this virtual space and still have it work sensibly.  People
>> won't take the chair unless there's a legitimate reason to do it, and so
>> long as it's logged - if someone does consistently abuse it we have
>> processes to eject them from the IETF for misbehaviour.
>>
>> just approving access, but it would be good to make it possible for someone
>> else to step into the chair if the regular chairs are unable to attend or
>> lose network, rather than making the meeting less able to run.
>>
>> Bron.
>>
>> On Sat, Jul 31, 2021, at 05:38, Meetecho IETF support wrote:
>>
>> All,
>>
>> feedback. We'll definitely take it into account when developing the
>> future releases of the platform. We'll provide comments on the points
>> raised as soon as we get the chance to parse them, i.e., when the
>> meeting is over.
>>
>> to that list as well, as that's the right place to discuss enhancements
>> and provide feedback that would be easier for us to collect.
>>
>> Best,
>> Alessandro
>>
>> Il 30/07/21 19:37, Spencer Dawkins at IETF ha scritto:
>> > I should have changed the Subject a LONG time ago! But this thread has
>> > morphed into helpful observations and suggestions, so, if I might add a
>> > couple of things ...
>> >
>> > I agree that Meetecho has been improving (and just for fun, the
>> Meetecho
>> > guys were participants in the MEDIACTL session I was co-chairing in
>> > Hiroshima at IETF 76 in November 2009, and they roped in a team member
>> > from Italy during the discussion using whatever the toolset was back
>> > then, so many of you have no idea how MUCH they've improved 😀).
>> >
>> > I see that we've already mentioned detaching the chat window, and
>> > usually I remember that we can detach the chat by Tuesday of each IETF
>> > meeting week at the latest, which is almost certainly a result of not
>> > having THAT much experience with Meetecho during the four months
>> between
>> > meetings. Now that we can use Meetecho for interim meetings, that will
>> > help me remember more clearly, so good there, too.
>> >
>> > The one thing I've noticed this week is how difficult it is to figure
>> > out who is speaking if they aren't sending video, and there's a long
>> > list of people in the queue. The suggestion to move the speakers above
>> > the queue would improve that, and so would simply displaying the active
>> > speaker names in the screen space where their video would have gone, if
>> > the person had been sending video.One reason that matters, is that it's
>> > helpful for everyone to get the speaker's name right in the minutes.
>> > That's not just for new attendees, I'm starting to forget what people
>> > sound like, unless I'm talking to them regularly, or they have a very
>> > distinctive speech pattern, so I've definitely depending on seeing
>> names
>> > when I'm taking minutes. .
>> >
>> > The one thing I was thinking about, as I read through this thread, was
>> > that we are kinda *not *talking about what the IETF thinks the target
>> > audience for our conferencing tool is.
>> >
>> >   * For probably the last couple of IETFs, I have a GREAT setup for
>> >     remote participation (my laptop screen, plus two 25-inch monitors).
>> >     But I do have tiled windows on all three screens.
>> >   * If we think people who can't throw a few hundred dollars at monitor
>> >     screens are part of our target audience, that's worth noting.
>> >   * If we think we're going to have hybrid meetings, in at least some
>> >     scenarios, it's going to be good to use Meetecho in the conference
>> >     rooms (especially if we need to be distancing, so more spread out,
>> >     front to back in the conference rooms).
>> >   * Even if we aren't doing hybrid meetings, I've participated in some
>> >     working group meetings from my hotel room, but I wasn't tryng to
>> >     co-chair a meeting, or even to present at a meeting.
>> >   * When Michael Richardson and I talked to the Cellar working group
>> >     participants about switching to Meetecho for our (monthy) interims,
>> >     the first question we got was, "is there an iOS/Adroid client?" I
>> >     haven't checked Meetecho on my phone in years, but I'd bet offhand
>> >     that (1) it would work, but (2) it might not be as easy to use as
>> >     some other conferencing systems, on those devices. Do people have
>> >     experience with that?
>> >
>> > I'll let you folks continue to share these positive observations and
>> > proposals. Make Good Choices, of course.
>> >
>> > Best,
>> >
>> > Spencer
>> >
>> > On Thu, Jul 29, 2021 at 6:15 PM Jay Daley <[email-masked]
>> > <mailto:[email-masked]>> wrote:
>> >
>> >     Thanks Bron.  Personally I think that’s a great usability adjustment
>> >     and will forward to the Meetecho team for them to consider.
>> >
>> >     Jay
>> >
>> >      > On 30/07/2021, at 10:58 AM, Bron Gondwana <
>> [email-masked]
>> >     <mailto:[email-masked]>> wrote:
>> >      >
>> >      > On Fri, Jul 30, 2021, at 05:21, Jay Daley wrote:
>> >      >> No we have absolutely not pushed Meetecho into being "just a
>> >     contractor", they are a valued partner and we work very well
>> >     together.  If you have any doubts about that then ask them directly.
>> >      >>
>> >      >> It is disappointing that you have escalated a personal concern
>> >     that you have with our services into such a strong criticism when
>> >     that is entirely unsupported by any evidence.
>> >      >
>> >      > Jay, I agree with your sentiment here - this attitude to Meetecho
>> >     is counterproductive.  They've done great work for the last couple
>> >     of IETFs and the experience is improving each time.  I have
>> >     particularly appreciated the embedded slide management, and I'm sure
>> >     that will be even better next time too.
>> >      >
>> >      > Regarding the specific interface issues that remain, I do think
>> >     there's a question of "where do we propose improvements in a way
>> >     that will be noticed"?  I've seen the suggestion made very many
>> >     times that the "speaker" area (where the video shows) should have
>> >     additional lines for each person sending anything, rather than that
>> >     information being at the top of the participant list.  This is much
>> >     more like the experience with other chat systems, for example Zoom
>> >     shows either a photo or a blank item for somebody who isn't
>> >     currently sending video, but they're otherwise treated "the same" as
>> >     a person sending video in terms of real-estate and where to look for
>> >     their presence by default.
>> >      >
>> >      > Right now with meetecho, my eyes are normally at the video are
>> >     when people are speaking, but if a non-video person is speaking I
>> >     need to look across to the other side of the screen to see the audio
>> >     indication.
>> >      >
>> >      > And as was also suggested in this thread, you can't scroll the
>> >     participant list to find someone to chat to, because they jump to
>> >     the top when they are sending, then back to alphabetical position.
>> >     This is also a usability pain.  Separating "the list of
>> >     participants" (which wouldn't move about) and "the list of people
>> >     sending something" with the video and audio indications being
>> >     together in one place would be a significant improvement.  And as an
>> >     additional benefit, when you're looking at the chat window, you
>> >     would still be able to see all the details of who is sending
>> >     (including yourself - if you're sending then the indicator of your
>> >     own audio should be the same as the indicator of everyone else's
>> >     audio, rather than being in yet a third location up under your own
>> >     name).
>> >      >
>> >      > So those two names would appear in the right hand side, and also
>> >     still have their name in the participant list, and the video feeds
>> >     would each have a "here's what's being sent".  Chairs would always
>> >     have a presence on the right, with whatever they were currently
>> >     sending - and the "participants" tab would only have the list of
>> >     participants, and not be a place you needed to go to see activity,
>> >     so you could mostly keep the chat tab open.
>> >      >
>> >      > Bron.
>> >      >
>> >      >
>> >      > --
>> >      >   Bron Gondwana, CEO, Fastmail Pty Ltd
>> >      > [email-masked] <mailto:[email-masked]>
>> >      >
>> >      >
>> >      > --
>> >      > [email-masked] <mailto:[email-masked]>
>> >     <https://www.ietf.org/mailman/listinfo/111attendees>
>> >
>> >     --
>> >     Jay Daley
>> >     IETF Executive Director
>> >     [email-masked] <mailto:[email-masked]>
>> >
>> >     --
>> >     [email-masked] <mailto:[email-masked]>
>> >     <https://www.ietf.org/mailman/listinfo/111attendees>
>> >
>> >
>>
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   [email-masked]
>>
>>
>> ___________________________________________________________
>> Tools-discuss mailing list - [email-masked]
>> This list is for discussion, not for action requests or bug reports.
>> * Report datatracker and mailarchive bugs to:
>> [email-masked]
>> * Report tools.ietf.org bugs to: [email-masked]
>> * Report all other bugs or issues to: [email-masked]
>> List info (including how to Unsubscribe):
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>
> --

---

From: gang Antgam <[email-masked]>
Date: Tue, 3 Aug 2021 02:59:04 +0430

در تاریخ شنبه ۳۱ ژوئیهٔ ۲۰۲۱،‏ ۱:۳۳ Bron Gondwana <[email-masked]>
نوشت:

> ... and which appears IN PLACE of the slides when enabled, so that meeting
> participants don't have to navigate to a separate tab to interact.
>
> Timing is really important in conversation and we're already fighting with
> the quarter second delay imposed by the size of the planet.  Additional
> delay makes it unwieldy.
>
> This has become less important with the ability for individuals to turn on
> both audio and video themselves, so the chair is going less busywork just
> approving access, but it would be good to make it possible for someone else
> to step into the chair if the regular chairs are unable to attend or lose
> network, rather than making the meeting less able to run.
>
> Bron.
>
> > I agree that Meetecho has been improving (and just for fun, the Meetecho
> > having THAT much experience with Meetecho during the four months between
> > distinctive speech pattern, so I've definitely depending on seeing names
> >      > On 30/07/2021, at 10:58 AM, Bron Gondwana <[email-masked]

---

From: Meetecho IETF support <[email-masked]>
Date: Tue, 3 Aug 2021 15:46:11 +0200

Hi Bron,

> meeting participants don't have to navigate to a separate tab to interact.

I agree this would improve usability.

> different tabs where they can't see the slides.  The multiple views 
> where you can see individual talking heads in more detail are not 
> actually valuable I don't think - if slides are showing they should be 
> the bulk of the screen because they need to be read - 

This is not always true. As you may have noticed, when a new slide 
deck/screen share is started you are automatically brought to the 
"presentation view", i.e., the one that shows it. But I think you should 
still have the power to manually switch to the "gallery view" at 
anytime. A good example are the open mic sessions during the Plenary: a 
static slide is always up just saying, e.g., "IAB Open Mic", and I 
usually switch to gallery view to focus on the faces answering 
questions. I've seen the same pattern also in several WG meeting 
sessions, where the last slide of a deck is displayed for a long time 
while discussing how to move forward with the draft.

> and if a poll is showing then for sure it should be taking over the screen.

Agreed.

> Additional delay makes it unwieldy.

Noted. I personally like the idea of a temporary mute mode which just 
stops sending audio on the track without affecting the underlying WebRTC 
PeerConnection. We'll look into that.

> each jabber name with a serial number (which I believe already happens now?)
> 
> ...
> 
> be an ordered list of participants and only needs to be switched to when 
> people don't get moved out of order when they're sending something).  
> The "who is sending something" list should be all together with the 
> video, and chairs pinned even if they're sending nothing right now.
> 
> speaking, this makes it easier to look in one place to see the source of 
> all sound, and eyes can generally flit between the right hand side 

I agree that we should make it easier to find who's speaking when they 
have not video turned on.

> attend or lose network, rather than making the meeting less able to run.

I personally don't agree on this. I think that chairing a WG meeting 
session requires a minimum of preparation in order to be effective, so I 
think it needs to be arranged at least a few hours in advance. In this 
way the acting chairs can be aware of which button to press to, e.g., 
pre-load slide decks, start a poll, manage the queue, etc.. Within such 
minimum preparation there can be the request to add the acting chairs to 
the Datatracker, so that they can be recognized as chairs when they join.

Please note that the Meetecho team already has a button that allows them 
to upgrade/demote roles within a session, so it would be super easy to 
also provide ADs with such powers. I just don't think it's the right 
thing to do: the Datatracker is where roles are stored and retrieved, 
and it's where such roles should be changed (even temporarily) IMO.

Cheers,
Alessandro

>> Also, I'm cc'ing [email-masked] 
>> <mailto:[email-masked]> and setting the reply-to header
>> <mailto:[email-masked]>
>> > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> >
>> >      > On 30/07/2021, at 10:58 AM, Bron Gondwana 
>> <[email-masked] <mailto:[email-masked]>
>> >     <mailto:[email-masked] <mailto:[email-masked]>>> 
>> wrote:
>> >      >
>> >      > On Fri, Jul 30, 2021, at 05:21, Jay Daley wrote:
>> >      >> No we have absolutely not pushed Meetecho into being "just a
>> >      >>
>> >      >> It is disappointing that you have escalated a personal concern
>> >      >
>> >      > Jay, I agree with your sentiment here - this attitude to Meetecho
>> >      >
>> >      > Regarding the specific interface issues that remain, I do think
>> >      >
>> >      > Right now with meetecho, my eyes are normally at the video are
>> >      >
>> >      > And as was also suggested in this thread, you can't scroll the
>> >      >
>> >      > 
>> >      > So those two names would appear in the right hand side, and also
>> >      >
>> >      > Bron.
>> >      >
>> >      >
>> >      > --
>> >      >   Bron Gondwana, CEO, Fastmail Pty Ltd
>> >      > [email-masked] <mailto:[email-masked]> 
>> <mailto:[email-masked] <mailto:[email-masked]>>
>> >      >
>> >      >
>> >      > --
>> >      > 111attendees mailing list
>> >      > [email-masked] <mailto:[email-masked]> 
>> <mailto:[email-masked] <mailto:[email-masked]>>
>> >      > https://www.ietf.org/mailman/listinfo/111attendees 
>> >     <https://www.ietf.org/mailman/listinfo/111attendees 
>> <https://www.ietf.org/mailman/listinfo/111attendees>>
>> >
>> >     --
>> >     Jay Daley
>> >     IETF Executive Director
>> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
>> <mailto:[email-masked]>>
>> >
>> >     --
>> <mailto:[email-masked] <mailto:[email-masked]>>
>> >     <https://www.ietf.org/mailman/listinfo/111attendees 
>> <https://www.ietf.org/mailman/listinfo/111attendees>>
>> >
>> >
>>
>> -- 
> * Report datatracker and mailarchive bugs to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
>

---

From: Meetecho IETF support <[email-masked]>
Date: Tue, 3 Aug 2021 16:04:08 +0200

Hi EKR,

Il 30/07/21 23:13, Eric Rescorla ha scritto:
> 
> 
> On Fri, Jul 30, 2021 at 2:03 PM Bron Gondwana <[email-masked] 
>     Ooh, we're going a full "suggestions for meetecho" thread?  I'd like
>     to propose some things!
> 
>     c) select between "choose one" and "choose N" modes (checkbox vs
>     radio button)
> 
>     actually valuable I don't think - if slides are showing they should
>     be the bulk of the screen because they need to be read - and if a
>     poll is showing then for sure it should be taking over the screen.
> 
> 
> EKR Raises Hand.
> 
> 
>     This is still an issue for me.  I often mute myself while chairing
>     so I can take notes without my keyboard sound interrupting the chat
>     - but it means that I can't easily respond to somebody because the
>     rejigging of the audio channel not only creates a hiccup in the
>     incoming audio feed which means I might miss something someone says,
>     but it also creates enough of a delay that by the time I could have
>     responded the other party's mental state has moved on.
> 
>     Timing is really important in conversation and we're already
>     fighting with the quarter second delay imposed by the size of the
>     planet.  Additional delay makes it unwieldy.
> 
> 

we have been actually required to implement such behavior a long time 
ago by the IETF, as we have been told that the tool should not have 
access to your mic or webcam devices if you're just an "observer" and 
not really intend to send media. I understand things and needs might 
have changed now, so we're happy to explore alternatives (see the 
"temporary mute" suggested by Bron).

> muting) when people enter and exit the head of the queue. This would 
> remove a lot of goofy behavior.

I personally don't agree on this. My opinion is that that unmuting 
should never be triggered by somebody else's action, e.g., when you're 
second in line and the person ahead of you leaves the queue. A long time 
might have passed since you joined the queue, you might be doing 
something completely different of even speaking to a different WG 
session, and you don't want your mic to be turned on automatically.

Cheers,
Alessandro

>     desktop computer to a phone / ipad so I can temporarily move to
>     another location while continuing to follow a meeting.  Multiple
>     connection support would mean I could switch over without a break.
> 
>     Sure it could be abused by people "sharing" a login, but that would
>     be pretty obvious if both parties tried to participate, and given
>     that we allow fee waivers anyway, it's unlikely to be abused
>     significantly.  Sure there are Jabber naming issues, but we can
>     avoid that by giving each jabber name with a serial number (which I
>     believe already happens now?)
> 
>     ...
> 
>     See my previous email :)  Basically the "participant list" should
>     just be an ordered list of participants and only needs to be
>     switched to when seeing who is in the call or opening an individual
>     message to them (and people don't get moved out of order when
>     they're sending something).  The "who is sending something" list
>     should be all together with the video, and chairs pinned even if
>     they're sending nothing right now.
> 
>     Along with visual indicators of "currently sending audio" on people
>     so we know who of those with their audio channel open are currently
>     speaking, this makes it easier to look in one place to see the
>     source of all sound, and eyes can generally flit between the right
>     hand side (video and audio indicators) and the slides, without
>     needing to also track via the participant list.
> 
>     meetecho reps in each meeting to be able to upgrade anybody to a
>     chair role or remove a chair role with a simple click.
> 
>     In real rooms, anyone can go sit in the chair at the front of the
>     room, and it's not abused because of social convention.  I believe
>     that we can map that to this virtual space and still have it work
>     sensibly.  People won't take the chair unless there's a legitimate
>     reason to do it, and so long as it's logged - if someone does
>     consistently abuse it we have processes to eject them from the IETF
>     for misbehaviour.
> 
>     This has become less important with the ability for individuals to
>     turn on both audio and video themselves, so the chair is going less
>     busywork just approving access, but it would be good to make it
>     possible for someone else to step into the chair if the regular
>     chairs are unable to attend or lose network, rather than making the
>     meeting less able to run.
> 
>     Bron.
> 
>>     >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>> wrote:
>>     >      >
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     * Report tools.ietf.org <http://tools.ietf.org> bugs to:
>     [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tools-discuss>
> 
>

---

From: Meetecho IETF support <[email-masked]>
Date: Tue, 3 Aug 2021 16:36:39 +0200

Hi Marc,

while the TTS suggestion is interesting and worth exploring, in the 
short run I think it might be worth revamping the custom recording 
player we had in the past, which integrated the YouTube video, the 
Jabber logs and also the audio transcripts automatically generated by 
YouTube. See for instance:

	https://play.conf.meetecho.com/Playout/?session=IETF106-DISPATCH-20191118-1000

Cheers,
Alessandro

Il 02/08/21 19:48, Marc Petit-Huguenin ha scritto:
> One use of the Meetecho recording is to prepare minutes by double 
> checking notes.  One issue with that is that sometimes a presenter 
> answers comments made in the chat, but the chat log does not appear in 
> the recording.  The person preparing the minutes now has to open the 
> minutes, try to synchronize then with the recording and update the 
> minutes to reflect the question/comment that triggers the response by 
> the presenter.  There is two issues with that:
> 
> I do not think that recording the chat at the same time than the 
> presenter would be a good idea (OTOH displaying the name of the person 
> talking in the recording even if they did not turn on video would 
> help).  The reason is that not all the content of the chat log is 
> relevant for the WG business (that's an understatement).
> 
> repeats the chat comment/question, and the presenters does not try to 
> look at the chat, and so now the whole context is captured.
> 
> something that someone said in the chat room even if it was not marked 
> as a question that the Jabber scribe must relay.  After all the chat 
> logs are under NOTE WELL, so they are part of the WG session -- and 
> should be part of the minutes, at least the relevant parts.
> 
> triggers TTS on the message itself, which now becomes part of the 
> recording -- and of the minutes.  With a local presenter the Jabber 
> scribe could also use that TTS feature.
> 
>> Also, I'm cc'ing [email-masked] and setting the reply-to 
>> header to that list as well, as that's the right place to discuss 
>> enhancements and provide feedback that would be easier for us to collect.
>>
>> Best,
>> Alessandro
>>
> [...]
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 3 Aug 2021 20:25:31 -0500

Hi, Alessandro,

> https://play.conf.meetecho.com/Playout/?session=IETF106-DISPATCH-20191118-1000

I'm sending Meetecho more email in the past 24 hours than in the previous
24 months. But YES YES YES! The audio transcript was the part that I
couldn't remember!

Having spent a LOT of time wandering through Jabber conversations for
several years, including a couple of working group sessions where the
Jabber scribe was asked to say at the Mic:, "you folks should probably be
in Jabber, because that's where the REAL meeting is going on" (😉, and I'm
not naming names), I often find the side conversations incredibly helpful,
but Context Also Matters, so seeing someone make a terse comment in Jabber
that is synchronized with the video is helpful, while the same comment in
isolation is at best confusing, and often not useful at all.

The audio transcript is better than we have any right to expect for most
things except technical terms and proper names. But when someone is
speaking at speed, there have been times when I was checking minutes
against the video, and it was still difficult to parse, so anything I could
dig out of the audio transcript helps!

Please do think about this in more depth. Some of us liked that ...

Best,

Spencer