Going back in the thread to this comment... > To hums: the default *appears* to be "piano" from headcount, if you do > not interact > therefore, graphing hum volume by headcount includes non-interactors > and this "moves the dial" > > if not, then why is there no clear 'abstain' button. and how is the > logic behind how the total sum and hum-weighting applied? > > APNIC designed a similar (in intent) system called "confer" to show > dynamic state of the room. Its hard. Its hard to explain and get this > stuff right. > > I did not find the hum indicated anything I felt I trusted. > Experientally, "hearing" a hum and being told "here is the weighted > sum of things you cannot see" is completely different. > > I would prefer to be told how many hummed. how many explicitly chose > to say "no view" and how many did not participate, and I would prefer > to be told how the hum weighting occurs. not in an RFC: on the tool. > all the time. I think it's often difficult to define the right or a meaningful metric for a set of measurements. In a physical room, WG chairs are able to look at how many people are in the room, and whether the hum is loudly (or softly) emanating from a few people or from the room as a whole. The chair bases their consensus metric on all these visible and audible measurements. What George said in this email resonated with me -- I would prefer to get the raw measurements rather than have the tool define a metric that is inconsistent with my metric. If we could just be provided (1) number of people in the room (which we already have), and (2) number of people humming at each volume level (loud/medium/soft), and trust the chairs not to consider this a vote (which I think should be a reasonable expectation), it would make it easier for the chair to mentally create a consensus metric, rather than have a metric imposed on them by the tool. Barbara > On Thu, Jul 30, 2020 at 2:33 PM John C Klensin <john-ietf@xxxxxxx> wrote: > > > > Without singling out any particular comment, I think there are > > at least two things have have gotten lost in the discussions and > > suggestions. I assume that, in at least some cases, people > > didn't know. > > > > First, I don't know whether this should have been made explicit > > earlier or not, but this is not the first time the IETF has used > > Meetecho. Many of us have been using it for remote > > participation for years and a great deal of effort has gone into > > making it work smoothly for IETF's way of working [1]. I assume > > we are probably a little more critical than many of their > > customers but assume "our" changes have become, possibly with > > small variations, part of their main product offering. I > > believe their other customers have including many all remote, or > > all remote other than a very small number of people in a central > > location, setups, so the assumption in some messages that > > Meetecho has never been used before in an all-remote situation > > (or very close to it) is probably incorrect. I don't know if > > the latter is accurate but, if it is important, I think we > > should ask rather than jumping to conclusions. > > > > Second, many changes have occurred, at least to the user > > interfaces, between our use for remote participants at IETF 106 > > and this week. Personally, I like some of the changes but > > believe others show signs of having been done in haste and with > > too little thought and/or time for testing and review. I accept > > Jay's assertion that those changes were not micromanaged by the > > IETF leadership or staff, but note that Greg Wood indicated > > during and after one of the test sessions that at least some of > > those changes had been made at the behest of an IETF design > > committee and that that the I-D and discussions of the hum > > feature are quite explicit that the specifications came from the > > IESG. > > > > It is probably helpful to remember something else I learned a > > half-century ago about UI design. An experimental psychologist > > colleague I worked with them was fond of staying that, when > > people tried to evaluate a system, what they already knew was > > almost always better (obviously, just because they are used to > > it). For those who did not actively use Meetecho for remote > > participation during IETF 106 and earlier and who have spent a > > significant fraction of the last months on Zoom, WebEx, > > GoToMeeting, and their competitors, and who did not attend the > > test sessions, Meetecho probably feels very strange and is at a > > significant disadvantage. I recommend giving it a chance and > > doing so with an open mind. > > > > If, as appears to be the case from the timing of the > > announcements, all of this was done on relatively short notice. > > We should be impressed that it works and identifying issues and > > making suggestions for improvements. If we want to make > > suggestions about replacing all of it with COTS software, we > > should consider how much effort has gone into trying to adapt > > Meetecho for IETF needs and remember that, before Meetecho came > > along, we tried to do remote participation with WebEx and, well, > > it didn't work out very well. > > > > best, > > john > > > > > > > > > > [1] In the interest of full disclosure, I participated in a few > > design sessions along with Alexa, Ray, and some Meetecho staff > > (and maybe others; I don't remember). I think I got sucked in > > because I started being intermittently involved in research in > > user interface and usability issues in distributed office > > teleconferencing systems in the early 1980s, studies that > > involved real experimental psychologists and controlled > > comparison of different approaches. And I may have been > > compensated with some travel reimbursements or a registration > > fee waiver or two -- not significant enough that I remember. > >
