Minutes Process

[egekorkan]

Ignoring AI transcription for now. Here are some basic requirements with what we are currently using and what can be some solutions:

1. We need a service to use during the meetings where someone types and the minutes are "sent" somewhere.
   • We use: IRC chat per TF. IRC is hosted by W3C. The commands must be used to generate an HTML from the typed minutes. We can correct in place and leave no trace of modification in the final HTML. Trace is left in the irc log.
   • We can use:
     1. IRC as usual.
     2. A service like google docs or Framapad. The minutes are recorded in the cloud. Note: Framapad can generate other formats
     3. Write directly in the wiki or GitHub repo: Risk of losing the minutes if the scribe accidentally closes it before saving/committing. This is not a good option.
     4. Locally at scribe's computer: OK but the scribe should send them somewhere quickly after the call. Not transparent for others.
2. We need a format to store the minutes in. This should be easy to change.
   • We use: HTML. Editing it is not easy. I do not like this.
   • We can use:
     1. IRC generated HTML: Not my preference.
     2. Vanilla HTML: Ok but it will not look good out of the box. Some basic CSS can fix it but will be more work to edit
     3. Markdown:
     4. Text: Not good because links and headers etc. are not rendered
3. We need a place to store. This should be stable and allow rendering of the minutes.
   • We use: W3C Servers
   • We can use:
     1. W3C servers: not good as even W3C staff cannot edit in place easily.
     2. GitHub Repo: Requires PRs, increases repo and PR counter (we will have PR number 500 quickly for no technical work)
     3. GitHub Wiki: Only editable if you have write access, I think.
     4. W3C Wiki: Write access rules not clear? Rendering is not good unless you use the wiki style.
     5. Leave at the writing tool: We can just leave at google docs and create a new link for each meeting.

My preference:

• Write in IRC. Generate MD from HTML using something like Pandoc. Commit that to each TF GitHub Wiki. That means: Minutes in W3C should be marked as useless. Nobody should end up there and think that those are the minutes. Also, the one who is doing this should ideally be the staff contact. If not, the TF lead or the scribe are the realistic options.

My other thoughts: That is quite a mess no matter what we do. There must be a better way to do this. What do the other groups do?

[TallTed]

Many other groups use rotating (either static rotation, or based on dynamic volunteerism) scribes who type into IRC, usually in combination with RRSAgent, Zakim, agendabot, and various other bot accounts. RRSAgent converts its IRC log into an HTML-formatted minutes document. This is not a perfect solution, but mostly it works. It's obviously possible for any speaker to say "this is a sensitive topic/comment; please don't minute this" which is not (currently) possible with the AI-based or other audio recording to transcript solutions. Audio and/or AV recordings in such cases are also typically made available (though they regrettably include the "don't minute" comments). This can be done with Zoom, Teams, WebEx, Google Chat, Jitsi, or pretty much any existing voice/video conference tool. It is important to have the ability to edit the end result if not the source documents, which I recommend be done within a source management tool (GitHub works pretty well) so the edits are visible and revertable in the case of vandalism.

Other groups I'm in are using Google Chat with their AI-powered transcription, which is far more accurate than it used to be, though it still messes up acronyms and other domain-specific terms. These can be fixed by human review of the transcriber output, just as with the processes above. Audio and/or AV recordings may be retained and made (not) available to whomever.

Really, there's no perfect solution. Best you/we can do is make a list of required features (including features required to be unavailable or lockable!, and including "I wish this was available"), and compare the various available solutions that might satisfy those requirements. On the bright side, none of the above are lock-in solutions, though some are not free services and/or not FOSS. You/we can always ditch whichever one gets tried out this month, and try another next month.

[chachamimm]

I agree. I think this issue should be improved as soon as possible. Because several call are held every week.

I think AI Companion feature is good tool and I don't deny to use AI Companion feature. But there are some issues. For example, 1) only the host can activate this feature, 2) it is not possible to review the minutes live during meeting, 3) when reviewing the minutes, it is not clear who said what, what are proposals and what are resolutions, 4) after meeting, transcript can't be saved by non-host, and so on.

Kaz couldn't joined at Use Cases meetings. So we created minutes by using irc. And after meetings, if we found any mistakes or typos, we asked Kaz to make corrections.

Before I send email about this issue. Then I proposed one way to create minutes.

Dave could copy the minutes generated on IRC to GitHub. Members would then review and make corrections. After that, Dave would copy them to the minutes system. I believe this approach would achieve the same result as before.

But Ege doesn't like HTML version. I don't like HTML version. Because HTML has poor visual readability in the editor. This is one opinion. So if there are better other methods, I agree them.

I think we need to discuss what format the minutes should be created in.

On the other hand, I think meeting minutes are important documents at W3C. I think W3C needs to keep the minutes of each group. Therefore, I also think we should ask for W3C's opinions. I discussed this issue with the Japanese W3C staffs, and they said it is currently being discussed among W3C staff.

[sebastiankb]

Thank you very much for your proposals and the discussion on this matter. To be honest, I am very dissatisfied with the current situation and do not believe it is the members' job to manage the minutes!

In order to deal with the current situation as effectively as possible, I would suggest the following process:

As an intermediate solution until TPAC:
Let's stick with IRC. Here we should all help together, that all commands are executed, so the IRC works properly and everything is recorded. We can c&p the minutes directly (just tested it, it works well) into a Readme.md file and store it here.

From TPAC:
Lets use a new collaborative editing tool such as etherpad (seems to be used by IETF) or framapad. Here, I also see the option that we can run an AI tool in parallel where generated text can be taken over.

[benfrancis]

I think that sounds like a good plan @sebastiankb.

Editing

If it's helpful I have discovered there is an instance of Etherpad hosted by the W3C at https://pad.w3.org, which requires a W3C account to log in to. The current setup is a bit basic but supports exporting as plain text or HTML. If we could get an administrator to enable headings and/or install plugins to edit and export Markdown it could be even better.

Storage

One other point I would make is about the long term storage of meeting minutes, which can be an important historical record about how decisions were made. Although the current system of taking minutes using magic commands in IRC is a bit arcane, what I like about it is that it's all self-hosted by the W3C and the output is a consistently formatted HTML file publicly hosted on the W3C website, with records going back many years.

An Etherpad could be used to collaboratively edit the draft minutes, then export to HTML (or Markdown) for public publication and long term storage. If we can't store those on the W3C website then the next best thing might be to check them into the public W3C WoT GitHub repository. Then at least the meeting minutes are as permanent as the commit logs of our specifications.

The easiest workflow would probably be to edit in Etherpad, export as Markdown, then copy and paste into a new file using the GitHub web interface, creating a pull request which people can review and then merge in the next meeting.

If someone was sufficiently motivated they could add support for Markdown as input to scribe.perl and set it up to automatically generate W3C formatted HTML minutes using a GitHub Action on commit to the minutes folder, using GitHub Pages to show the rendered version.

Agenda, Speaker Queue and Chat

Just a thought, but if the agenda is on the wiki, the call is on Zoom, the minutes are in Etherpad and the speaker queue and back channel chat is still in IRC, then that's four different tools we have to use at the same time. It might be simpler to just use Etherpad for both the agenda and minutes, and Zoom for the audio conversation, text chat, and raising of hands.

AI Transcription

I'm not a big fan of AI meeting notes, but I can see that it's useful and saves someone the tedious job of being scribe. It's sometimes more accurate than a human, but it can also subtly misinterpret what was said and can't ask for clarifications. It also tends to capture things that a human wouldn't, which can be a blessing and a curse!

---

As an aside, I think we're coming to appreciate just how much work @ashimura did for us, including editing and publishing all of the minutes and sending out weekly emails!

[sebastiankb]

Thank you for pointing out the existing Etherpad host at https://pad.w3.org/. I also like the idea of putting the agenda there. I'll bring this up at the next chairs call.

[sebastiankb]

a brief interim report from W3C about Etherpad:

The Etherpad instance is essentially provided as-is. There's no usage guideline for now. Other groups use Etherpad (the Privacy WG comes to mind [1]), mostly as a place to write minutes. I do not know what workflow groups have adopted to publish the minutes afterwards. Access to pads under https://pad.w3.org is restricted to people with a W3C account, so not suitable to store public minutes.

This means that, besides using IRC, github seems to be the only option if we want to go public with the minutes.

[benfrancis]

FWIW it looks like the Privacy Working Group keep a live agenda and meeting minutes on this Etherpad (requires W3C login) and then export plain text to .md files which they directly push to the minutes directory of a repository on GitHub, with an index maintained here.

Note that the current W3C instance of Etherpad does not have section headings enabled, or the ability to edit or export as Markdown, so they just appear to be writing raw Markdown in Etherpad. It's ugly but it works, e.g. I've created a test pad for the Profiles meeting here.

[TallTed]

I should have thought to mention above...

Other groups keep their agenda in a Google Doc which then forms the backbone for live notetaking. All attendees are empowered to edit the doc, which helps keep their own words accurate, as well as enabling typo, grammar, and similar fixes by others on the call (which in the groups I'm in are either Zoom for WG, or Gmeet for CG). When the meeting is over (and an indeterminate time has lapsed for late corrections), the content of the Gdoc goes into a GitHub Markdown doc, which is persisted in a Minutes directory in the relevant GitHub repo.

There'a almost as much variety in agenda and minutes as there is in WG/CG/IG/BG/etc., group topics.

[sebastiankb]

Other groups keep their agenda in a Google Doc which then forms the backbone for live notetaking.

The problem is that the Google service is not accessible everywhere in the world. I think that the same task can also be done by Etherpad, which is hosted by the W3C.

[egekorkan]

@benfrancis I really like your proposal/idea. Just noting that the staff contact Tara Whalen seems to be doing the work with the minutes and not the members or chairs.

[TallTed]

Etherpad, which is hosted by the W3C

It's W3C hosted, but that instance appears not to be really maintained.

E.g., I'm not sure, and can't see a way to learn, how close to "latest version" this instance is. It's apparently behind Cloudflare, so the Server header is obscured.

Newer versions of Etherpad include the instance version in the Settings dialog, and there's no version shown in the Settings for https://pad.w3.org, just "Powered by Etherpad".

Nothing's ever as simple as we hope.

[egekorkan]

The proposal from the TD TF for the group is below. We try to optimize the workload for TF leads. Also see https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#November_26-27%2C_2025

1. We use one Etherpad forever, i.e. a new link is not created for every meeting. The Etherpad has two titles, one for each day. For other TFs which do not meet twice a week, they have one title
2. At the end of the meeting, we click on the star button to create a snapshot for that day.
3. We review on the minutes of last week from Etherpad on Wednesday
4. We create a new GitHub file for the with Etherpad minutes and commit on the spot, without a PR. We do not change the people's initials. ek stays ek and does not become Ege Korkan
5. We delete Etherpad minutes content but keep the rest (like a template). This reduced the effort for next week
6. We delete and recreate the pad with the same link once every couple months to avoid memory/storage issues. This is done by the TF leads and should not bother the TF participants.

Here are the minutes link for the TD: https://pad.w3.org/p/wot-td-minutes

We use markdown conventions for titles to make it look nice when shown in GitHub

[benfrancis]

We review on the minutes of last week from Etherpad on Wednesday
We create a new GitHub file for the with Etherpad minutes and commit on the spot, without a PR.

I think personally I would have gone with a PR right after the meeting (exported to Markdown from Etherpad after light editing to fix typos etc.) which people have a week to review and can suggest changes to, since this will make the review process more transparent than having to track changes in a password protected Etherpad. I realise this means the draft minutes are made public, but that has historically been the case. I like the idea of getting email notifications of minutes to review (like the weekly summaries Kaz used to provide), rather than having to manually navigate to several different password-protected Etherpad URLs. I would keep the PRs in the top level wot repo to prevent noisy commit logs in the other repos though.

[egekorkan]

• I am fine with minutes being public as they are written and if I am not wrong, that is a W3C-wide policy. We made the change to minutes being public some years ago. Theoretically, we cannot even use Etherpad as it is against that policy. You need a W3C account to see them. Thus, your proposal is more aligned with W3C.
• The reason I have proposed to make a commit after review is to reduce GitHub comments and review process over there. Also it is slightly more work for TF leads to make a PR vs doing a commit during the call.
• I agree that it is more annoying to review multiple Etherpad links. It would be also annoying to go to multiple PRs. Best would be that the staff contact makes a PR with all the minutes