lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 11 Jun 2021 11:13:07 +0200
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        David Hildenbrand <david@...hat.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Greg KH <greg@...ah.com>, Christoph Lameter <cl@...two.de>,
        "Theodore Ts'o" <tytso@....edu>, Jiri Kosina <jikos@...nel.org>,
        ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
        linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, netdev@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: Maintainers / Kernel Summit 2021 planning kick-off

Em Fri, 11 Jun 2021 04:59:42 +0200
Willy Tarreau <w@....eu> escreveu:

> On Fri, Jun 11, 2021 at 12:43:05AM +0200, Toke Høiland-Jørgensen wrote:
> > Shuah Khan <skhan@...uxfoundation.org> writes:  
> > > I have a
> > > couple of ideas on how we might be able to improve remote experience
> > > without restricting in-person experience.
> > >
> > > - Have one or two moderators per session to watch chat and Q&A to enable
> > >    remote participants to chime in and participate.
> > > - Moderators can make sure remote participation doesn't go unnoticed and
> > >    enable taking turns for remote vs. people participating in person.
> > >
> > > It will be change in the way we interact in all in-person sessions for
> > > sure, however it might enhance the experience for remote attendees.  
> > 
> > This is basically how IETF meetings function: At the beginning of every
> > session, a volunteer "jabber scribe" is selected to watch the chat and
> > relay any questions to a microphone in the room. And the video streaming
> > platform has a "virtual queue" that remove participants can enter and
> > the session chairs are then responsible for giving people a chance to
> > speak. Works reasonably well, I'd say :)  
> 
> I was about to say the same. In addition, local participants line up
> at a microphone and do not interrupt the speaker, but the organiser
> gives them the signal to ask a question. This allows to maintain a
> good balance between local and remote participants. Also it's common
> to see some locals go back to their seat because someone else just
> asked the same question. And when remote questions are asked using
> pure text, it's easy for the organiser to skip them if already
> responded as well.
> 
> This method is rather efficient because it doesn't require to keep the
> questions for the end of the session, yet questions do not interrupt
> the speaker. It also solves the problem of people not speaking in the
> microphone. The only thing is that it can be quite intimidating for
> local participants who are too shy of standing up in front of a
> microphone and everyone else.

If someone is shy, he/she could simply type the question as a
remote participant would do.

This should work fine for a normal speech, but for BoFs and the
usual "round table" discussions we have at Kernel Maintainers,
this may not work well for local participants.

I guess that, for such kind of discussions, I can see two
possible alternatives:

1. everyone would use their laptop cameras/mics;
2. every round table would have their on camera/mic set.

(1) is probably simpler to implement, but may provide a worse
experience for local participants. (2) is probably harder to
implement, as the usual conference logistics company may not
have cameras.

In either case, a moderator (or some moderating software) is needed
in order queue requests for speech. So, basically, when someone
(either in a table or remote) wants to speak, it adds its name to
a queue, which will then be parsed at the queue's order. This is not
as natural as a physical meeting, but I guess it won't bring too
much burden to local people.

Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ