Re: Automated minutes publication

This discussion has gone a little far afield from where it started, but I
wanted to add something. In the W3C Privacy Interest Group, we use Zoom for
audiovisual and CryptPad for queuing and notes.

On Sat, Nov 16, 2019, 19:37 Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 11/16/19 5:15 PM, Stephen Curran wrote:
> > Yup - I know you've had to deal with that question before - my
> > apologizes.  I just can't figure out the motivation to stay with
> > this. So two more questions, if you would indulge me:
> >
> > 1.  What part of the service must be open source?
>
> Ideally, all of it. Or at least it should use open standards for all
> parts. The issue is vendor lock in. A number of years ago, Skype was all
> the rage and we were having this same discussion. Now it's Zoom. The
> issue is that some poor sap has to write the software and when people
> decide to jump from one proprietary vendor to another, all of the
> software needs to be rewritten to match the new proprietary APIs.
>
> > From that list, Zoom (and others) does all that except it's not open
> >  source.
>
> Ehh, Zoom also doesn't do the following things on the list:
>
> * Bridges to IRC for control
> * Does queue management
> * Automatically records/archives/uploads IRC logs
>
> It's just a simple matter of programming to write something that does
> those things and integrates into Zoom... and of course, someone would
> have to volunteer to pick up the cost for the Zoom account to host/run
> the meetings. Digital Bazaar has been doing that for the past decade or
> so, and we'd welcome someone else picking up the maintenance and
> operations costs :).
>
> So, if someone would like to put in the work (and pick up the cost), I'm
> sure the group might consider it... especially since we have a fall back
> solution now w/ PBX/SIP/IRC. In the very worst case, we can fall back to
> what we're doing today (which is why I think Zoom could be an option).
>
> > The functions listed would be done slightly differently in some
> > cases, but every one of them is supported today. After the recording
> > and chat log is captured and put into github, etc. does the call
> > management system matter?
>
> It does, and I'll explain why below.
>
> > 2. When is the existing system going to be upgraded to support
> > screen sharing?
> >
> > I suspect that might take even longer to the existing system than
> > adding the features you list. I'm certain that eventually, the need
> > for that feature will overcome the argument against staying with the
> > current system.
>
> I don't find screen sharing that compelling of a feature. Yes, super
> useful for demos, sharing slide decks, etc... but most of the decisions
> made in the standards realm don't require screen sharing... I mean, we
> built the Internet and Web to where it is today without screen sharing.
>
> I will grant that it's useful every now and then, but keep in mind that
> Adrian's recent presentation to the group was just as easily
> accomplished by sharing the slide deck before the call (which is good
> form so that everyone has a copy) and then going through it calling out
> slide numbers so folks can go at their own pace.
>
> > I gather this is a W3C requirement?
>
> Since we're a Community Group, we can run the calls however we'd like as
> long as we're keeping the IPR clean.
>
> That said, there is one argument against Zoom that isn't easily cast
> aside... and that is that what you're suggesting we use it for
> marginalizes people with accessibility needs.
>
> The reason we largely use open standards and text to communicate is that
> it's easily converted into forms that people with accessibility needs
> can use to engage. Text to speech is vital for people that can't see,
> and multi-modal presentations are so incredibly challenging when you
> can't see but can hear, or you can't hear, but you can see.
>
> To help illustrate the problem, the next time someone starts screen
> sharing, shut your monitor off and just listen to what they're saying...
> and then interrupt them every time they try to convey something by
> highlighting the screen, or circling a part of the screen with their
> mouse, or saying "so, as you can see on the left...". Your desire to
> interrupt, or just stay silent and see if you can figure out what
> they're saying with other context, will lead to a certain uneasiness
> leaving you at a disadvantage wrt. the discussion.
>
> ... and that's the real problem with screen sharing... it lacks
> affordances and metadata that's necessary to make it accessible to
> people with certain accessibility needs.
>
> The Web is for all, and W3C has a mandate to ensure that it builds and
> uses systems that are broadly accessible. That means using open
> standards and making accessibility mandatory.
>
> I haven't heard the W3C Accessible Platform Architectures WG take on
> using Zoom for screen sharing at W3C meetings, but if you're game for
> proposing it, I'll bring my popcorn along for the show. :P
>
> So, I guess what I'm trying to say, is that suggesting that we use a
> proprietary system with questionable accessibility characteristics and a
> mode of communication that marginalizes certain people with
> accessibility needs is unlikely to be seen in a positive light by folks
> that are trying to build an open Web for all.
>
> """
> The power of the Web is in its universality.
> Access by everyone regardless of disability is an essential aspect.
> """
>
> -- Tim Berners-Lee
>
> """
> Access to information and communications technologies, including the
> Web, is a basic human right.
> """
>
> -- UN Convention on the Rights of Persons with Disabilities
>
> https://www.w3.org/standards/webdesign/accessibility
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>