Record meetings - Discussion

[syrusakbary]

Hi,

I proposed in other issue to record the meetings as a way to assure alignment with people that may not be present at the time of the meeting, to avoid any misunderstandings for lack of context.

Unfortunately I’ll not be able to join the call tomorrow as I was planning and I mentioned in a previous issue (can’t comment there because the issued is locked).
It would be great if some could propose the idea of recording the meetings.
I’ll check the meeting minutes after to see if someone chimed in, and that was discussed. Otherwise I’ll try to propose the discussion for the meeting after.

Thanks!

[conrad-watt]

I’ll check the meeting minutes after to see if someone chimed in, and that was discussed. Otherwise I’ll try to propose the discussion for the meeting after.

I won't be able to make the meeting today either, but if it's not proposed today I can do so in the following meeting. Do you have any recommendations for recording/transcription software I could experiment with in the meantime?

[syrusakbary]

Do you have any recommendations for recording/transcription software I could experiment with in the meantime?

Most of the Videoconf apps already have it bundled (Google Meet, Zoom & Microsoft Teams).
If the Community is already using Zoom, is as easy as clicking "Record on the Cloud" (is already bundled with the app). That's probably the easiest and smoothest way of doing it (we use it extensibly at Wasmer, and it works like a charm!).

Both Google Meet and Microsoft Teams seem to also support it (although I have less personal experience on them).

[penzn]

Garbage Collection subgroup used Zoom recordings and those worked magically. Since CG uses Zoom it would be one or two clicks to enable.

[dschuff]

In my view, meeting notes/records serve 2 purposes. One is for people who might otherwise attend but can't for some reason, so they can stay up to date on what's happening. The other is for anyone to look back and find past discussions and decisions, better understand the reasons for decisions, know what has been discussed before, etc. (in-between would be the use case for someone who would not otherwise attend the meeting, but who still wants to know what's being discussed).

Meeting recordings sort of serve the first purpose (since someone can watch the recording and get up-to-date) but IMO they are terrible for the second, and not good for the in-between case either. They are not searchable, and not skimmable they way a document is; and it takes much longer to watch a recording than to read notes. If the current notes aren't good enough, I would rather have something like auto-generated captions (that the chairs or note-takers can fix up if necessary before posting) if the technology is good enough. Obviously that depends on how accurate they are, since if it's bad it would be either a lot of work to fix, or incomprehensible and thus worse than the status quo.
Just speaking for myself, not sure how others feel about that.

[penzn]

I think recordings are useful for those who are committed to consuming the whole meeting they missed, because they can be ran in background or sped up, I personally do that where possible. That said, I think notes are useful as well for exactly the reasons you mention.

Zoom supports automated captions.

[conrad-watt]

I've become aware that there's significant existing W3C guidance and discussion on this topic, including:

https://www.w3.org/Guide/meetings/transcripts.html
https://www.w3.org/2021/Process-20211102/#meeting-recording
w3c/process#334

I'd like to take more time to understand and discuss these, so any immediate discussion on the topic in next week's meeting should be somewhat non-committal.

[rossberg]

Interesting. Those rules seem to be pretty clear on not allowing publishing recordings or even automated transcripts in general.

Moreover, I think I'd deduce from the stated intent that our habit of immediately putting meeting notes through a public code review on Github also is in violation of the W3C process. There must be a period that allows participants to request changes before they become publicly accessible. And the history of such changes must also not become accessible, which may be tricky when using software like Google docs (or does it allow turning off version history?). At a minimum, we must disallow participants to share the link to the notes doc, which may be far from obvious to everybody.

[conrad-watt]

Moreover, I think I'd deduce from the stated intent that our habit of immediately putting meeting notes through a public code review on Github also is in violation of the W3C process. There must be a period that allows participants to request changes before they become publicly accessible.

Can you point to what's leading you to this conclusion? My understanding is that the W3C distinguishes between meeting notes/minutes, which are a summary of the events of the meeting (and must be published publicly for Community Groups), and a raw automated transcript/recording, which appears to be what the above guidance is concerned about. One distinction at least appears to be that automated transcripts and recordings may (IANAL) come with additional legal obligations regarding consent in comparison to a hand-typed summary.

We've not yet found ourselves in a situation where someone has asked that their exact words not be minuted, but I imagine this would be pretty easy to handle with our current process.

[rossberg]

This page e.g. mentions that notes may not be published before the group approves. It's not clear how to verify approval, but I would expect that any such mechanism would at least require giving individuals time for checking and possibly objecting to the written notes and requesting changes.

The ability that "participants are able to occasionally request that a statement not be minuted, or be minuted differently—this sometimes happens after the statement was made" (as mentioned in the OP of the third of your links) is a specific instance of something that those participants may want to verify.

[conrad-watt]

I think this is already somewhat covered by our initial use of the Google doc, followed by the "real" meeting notes PR some time later. Perhaps we could be more explicit about saying "please check the meeting notes doc" at the end of each meeting.

It is worth noting that, as a CG, we have some freedom to diverge from guidance which is strictly binding to WGs. My concerns would be that:

• We should follow guidance as a default and explicitly understand when and why we're diverging
• If we wish to break from the guidance in some aspect, we should understand which parts of the guidance reflect potential legal exposures, as opposed to the W3C's "social best practice"

[rossberg]

I think this is already somewhat covered by our initial use of the Google doc, followed by the "real" meeting notes PR some time later. Perhaps we could be more explicit about saying "please check the meeting notes doc" at the end of each meeting.

The PR is already public, so too late and inadequate for that purpose. As for the meeting doc, a participant may not have time to check it immediately after the meeting (because of follow-up appointments), or even on the same day (due to time zones). So there needs to be a reasonable time period. And as I said, we have to ask participants to not share the link to the doc.

[conrad-watt]

As for the meeting doc, a participant may not have time to check it immediately after the meeting (because of follow-up appointments), or even on the same day (due to time zones). So there needs to be a reasonable time period.

This is fair, although I think the ultimate outcome of this is that if someone raises concerns about the precise wording of the notes (due to a fractious debate, etc), we leave the doc open for edits/suggestions for a few days before opening the PR. The W3C process suggests it's not unreasonable for minutes to be available within 48 hours.

And as I said, we have to ask participants to not share the link to the doc.

I don't think it's clear that we have to do this, although I agree it might be preferable in the case that the wording of the notes is contested. The strict wording in the "transcripts" guidance only relates to automatic transcriptions.

[syrusakbary]

I honestly think the W3C guidance regarding meetings is not up to the bar that we should measure, especially given that we need to excel through transparency and not secrecy.

So I'm not sure we do any good by blindly following any of their suggestions regarding meeting transcripts.
I still think a two side approach (Automatically recorded meetings & auto-transcribed meetings) will solve most of the issues and will have little to no downsides, other than divergence from the default W3C guidance (for good reason I believe)

[conrad-watt]

Even if we did implement recording/transcribing, it seems clear to me now that it could only be with the unanimous consent of the meeting participants. Bearing this in mind, it doesn't seem that recordings/transcriptions would help much in combatting "secrecy".

I'd still be interested in finding ways to improve our meeting records, but I think the important principle from the point of view of transparency is that votes in meetings, especially controversial ones, should be signposted and discussed well in advance - this is already part of our normal practice.

[rossberg]

And as I said, we have to ask participants to not share the link to the doc.

I don't think it's clear that we have to do this, although I agree it might be preferable in the case that the wording of the notes is contested. The strict wording in the "transcripts" guidance only relates to automatic transcriptions.

If participants were allowed to "leak" the link to the public, then the implementation of "off-the-record" would not be sound, because the version history of that doc would be a publicly accessible record.

As usual with procedural questions like this, it all seems hypothetical. But once it actually happens it is too late. At the moment, I would certainly advise strongly against speaking "openly" or off the record at any of our meetings.

At least we have to acknowledge that transparency and openness/inclusiveness are conflicting goals.

[conrad-watt]

At the moment, I would certainly advise strongly against speaking "openly" or off the record at any of our meetings.

I think the balance in a CG is already somewhat different in comparison to a WG, since CG meetings are publicly accessible and the attendee list is fairly fluid. I'd certainly assume that anything we discuss in the meeting becomes public knowledge. That being said, I think we'd still require unanimous consent from attendees before conducting any automated recording/transcription.

[fgmccabe]

There are a couple of points here:

1. The notes that Conrad references seem to focus on working group meetings, not community group meetings.
2. If the guidelines are applicable, the issue about publishing minutes has a longstanding resolution: the first item of a meeting (in the 'good old days') was usually to approve the minutes of the meeting before.

[penzn]

I don't think the notes linked above apply to community groups, because the process doc explicitly says this about its scope:

this document describes the formation and policies of its chartered Working Groups and Interest Groups, see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. W3C also operates Community and Business Groups, which are separately described in their own process document [BG-CG].

Relevant sections of the Community process seem to be

• Community Group Communications
• Community Group Meeting Policies

Both are straight-forward, and neither of them prevents recordings, in fact the former section explicitly says that "All communications must be archived". This document does not require getting unanimous consent for meeting recordings either.

As an aside, the community doc also states that CG deliverables require signing a CLA, but that is a topic for a separate discussion.

[conrad-watt]

This document does not require getting unanimous consent for meeting recordings either.

I don't believe it would be prudent for us to record anyone without their consent, and I wouldn't want to make that consent a condition to participate in meetings. As I said above, while the guidance is not strictly binding to a CG, it may, at the very least, reflect underlying legal obligations that we have to be careful of.

This doesn't have to mean that we give up on transcription - one could imagine attaching a disclaimer "this meeting will be recorded unless there is an objection" to the meeting event and so on. It's also worth noting that the guidance here is phrased more broadly in terms of "W3C Groups", although I agree it was likely drafted with Working Groups in mind. I'm definitely going to seek clarification here.

[penzn]

It's also worth noting that the guidance here is phrased more broadly in terms of "W3C Groups", although I agree it was likely drafted with Working Groups in mind. I'm definitely going to seek clarification here.

It sounds like community groups are certainly less private. For example a group that doesn't have meetings (which Community and Business process doc states is allowed), then all its communication would be in an online forum, which would make it effectively entirely public and on record. But yes, clarification would be helpful.

[jeff-hykin]

As an outsider doing their best to follow all the guides/rules for propsals; not having recordings is a massive barrier to entry (on top of other small barriers).

This discussion seems over complicated to me.
I believe everyone can agree:

1. people's privacy wishes should be respected
   • For this, it seems appropriate to simply ask the group (at the next meeting) if a policy like @conrad-watt's can be used. E.g. "Hey, can the next meeting start with 'this meeting will be recorded unless there is an objection' and can a member then record the meeting"
2. we shouldn't do anything (accidentally) illegal
   • For legality, I live in a one-party consent state in the US. So unless the audio is copyrighted (which I'm almost certain is not the case) recording and publishing the audio of a meeting will not be a legal issue. I can't guarantee that I will be at all future meetings, but if I am I would be willing to screen record and upload.

[syrusakbary]

As an outsider doing their best to follow all the guides/rules for propsals; not having recordings is a massive barrier to entry

Agreed

This discussion seems over complicated to me.

Same. Feedback was provided, hopefully the Wasm group will be able to move forward from it.

In any case, I really like your proposal @jeff-hykin! Hope we can agree on it :)

[tlively]

FWIW I just finished editing the first day of the Pittsburgh CG meeting notes with access to an automatic transcription produced by Zoom. The transcription quality is terrible, especially for all the jargon we use, and it turns out that people do not talk in complete sentences anyway. My judgment is that our current process of manually producing "notes" that are abbreviated and edited near-transcriptions produces a much more useful document than an automatic process would.

[ttraenkler]

FWIW I just finished editing the first day of the Pittsburgh CG meeting notes with access to an automatic transcription produced by Zoom. The transcription quality is terrible, especially for all the jargon we use, and it turns out that people do not talk in complete sentences anyway. My judgment is that our current process of manually producing "notes" that are abbreviated and edited near-transcriptions produces a much more useful document than an automatic process would.

The amount of editing necessary may depend heavily on the transcription service used. Maybe give OpenAI's Whisper API a try?

Will a recording of the in person CG meeting be available? In general transcription errors would be less significant if one could refer to the original audio or video recording. In a recording the listener could also jump to the parts that are relevant instead of having to attend the whole meeting or not being able to attend at all because of time constraints.