For TPAC Meeting Planners

The tools in this repository can be used to organize:

• multi-day group meetings during W3C TPAC events; and
• single-day breakout sessions during W3C breakouts events (e.g., during TPAC or Breakouts Day)

We use the following terms in this document:

• Session: a proposed meeting, whether a single group meeting, joint group meeting, ad-hoc meeting, or breakout. The session description includes information about the meeting, scheduling constraints and preferences from the perspective of session proponents, and information to share with meeting participants such as agendas and links to minutes.
• Event: A set of sessions to be scheduled in light of scheduling constraints from the event planner perspective: available rooms and days/slots. An event may be single-day (e.g., TPAC breakouts) or multi-day (e.g., TPAC group meetings).
• Schedule: The assignment of each session in an event to a day (or multiple days), time slot(s), and room(s). A schedule may be published in various formats, including as a series of events in a W3C calendar, as a grid, or as a list of sessions (sortable in various ways).

Overview of scheduling workflow

At a high level, here's how we create schedules:

• Event planners set up the tools described below.
• Event planners invite the community to propose sessions (up to some deadline).
• As the deadline approaches, Event planners explore potential schedules given the proposed sessions.
  • At first, we use the tool to generate schedules automatically.
  • Generally Event planners will compare different automatically generated schedules and then choose ("adopt") the schedule that works best.
  • Event planners can then make manual changes as the landscape changes. For example, it may be necessary to add or remove available rooms. Or people might propose sessions after the deadline. Or people might discover new constraints that they would like taken into account.
  • At any time, Event planners can delete schedule data and ask the tool to fill in the blanks automatically.
  • Often, Event planners work with the community to resolve scheduling conflicts.
• Draft: After the deadline for session proposals, Event planners publish a draft schedule and invite feedback from the community, likely making manual changes to the schedule to accommodate requests.
  • We publish the draft schedule as an HTML page (example) and announce it to the community.
  • Typically the draft schedule should not mention specific rooms because actual room assignments come later.
• Tentative: After handling feedback on the draft schedule, Event planners publish a tentative schedule. (The schedule may still need to be modified and can be modified through the tools.)
  • Typically the tentative schedule should not mention specific rooms because actual room assignments come later.
  • We publish the tentative schedule in the event calendar.
  • Separate tools (managed by Bert Bos) extract the session data and publish it in grid/list format in the event pages.
• Confirmed: As the meeting approaches, once a significant number of people have registered, the Event planners assign sessions to rooms (seeking a best fit of session registration to room capacity) and publishes a confirmed schedule (to the same calendar).

Note: For TPAC, group meetings are organized as one event, and breakout sessions as a second event.

Resources for Event planners and event attendees

Before talking about tooling, we want to raise awareness about resources for Event planners developed in association with these tools:

• Good Practices for Session Chairs
• Policies (deadlines, late proposal policy, hybrid, public, no zoom links made public to avoid zoom-bombing, registration policy, fee policy, recording policy, how to publish recordings, etc.)
• Scheduling considerations for meeting planners, to help reduce conflicts from the perspective of people attending sessions.
• Communications. These are emails to the community inviting sessions and announcing schedules. For sample communications, see TPAC 2023 breakouts communications

Typical planning calendar

The overall organization of W3C events is out of scope for this documentation. For W3C breakouts events, the following planning calendar reflects our experience organizing such events in 2023 and 2024:

• Early Prep
  • Define/Refine policies (deadlines, late proposal policy, hybrid, public, no zoom links made public to avoid zoom-bombing, registration policy, fee policy)
  • Find volunteers to be session buddies for first time chairs (possibly starting from last year's pool of chairs).
  • Create the GitHub repo and project for this year's TPAC.
• Three months before TPAC:
  • Gather sessions
  • Train session organizers (chairing, tools, accessibility)
  • Strategy Team (or CG) should work so that hot topics are surfaced at TPAC.
• Close to TPAC:
  • Schedule sessions (rooms and sizes, slot lengths, tagging for themes, timing constraints, avoiding conflicts, mergers, ...)
  • Socialize breakouts to reach full w3c community (slack events channel? social media?)
  • Socialize draft schedule with staff to perceive any conflicts; ask them to sign up for sessions.
• During TPAC:
  • Last-minute management of sessions (scheduling or room changes)
  • Help those running sessions (IRC or other, minutes)
  • Strategy Team (or CG) should be aware of breakouts and attend critical ones.
• After TPAC:
  • Communicate (get feedback, gather minutes, "next steps" as GitHub discussion)
  • Strategy Team (or CG) should review breakouts
  • Publish any recordings
• Throughout:
  • Collaborate with meeting planners (space, communications)
  • Maintain tools (IRC bots, calendar)

For sample timelines, see the TPAC 2023 breakout planning calendar and the TPAC 2025 breakout planning calendar

Set up

Tool overview

• A Google spreadsheet for specifying event metadata, generating and editing schedules, and publishing acceptable schedules to the W3C calendar.
• A GitHub repository for collecting session proposals.
• Other tools We use a small number of other tools, including a script to translate the calendar representation of the schedule into an HTML representation, generally used within the event Web site on w3.org.

We use, but do not discuss here, other sources of information (e.g, W3C databases, event registration data).

Note: For breakouts (for both TPAC and Breakouts Day) we invite the community to propose sessions directly in GitHub (via issues). Because planning TPAC group meetings is more complex, we have traditionally asked group chairs to use WBS to provide information to the event planners, and then the event planners translate this information into GitHub session proposals. This allows group Chairs to focus express their needs simply via WBS, and for the meeting planners to schedule simple meetings as well as joint meetings and ad hoc meetings via GitHub session proposals.

W3C calendar

• Create a Big meeting for the event so that calendar entries can be associated with the event in the W3C Calendar.
• Give the event a name. Typical names:
  • TPAC YYYY. (This is the name for both the main TPAC calendar and the TPAC breakout sessions calendar)
  • Breakouts Day YYYY
• Suggested calendar URLs (where YYYY is the current year):
  • For a W3C TPAC event, https://www.w3.org/calendar/tpacYYYY/
  • For a breakouts event linked to TPAC, https://www.w3.org/calendar/tpacYYYY/breakout-sessions/
  • For a breakouts event on its own, https://www.w3.org/calendar/breakouts-day-YYYY/

Google spreadsheet

Work with Ian and François to get a properly setup Google spreadsheet for the event (see Setting up a spreadsheet for a new event).

Default Sheets

A new spreadsheet created from the template will include these sheets:

• Event: Metadata about the event
• Rooms
• Slots: Includes both day and time slot information

You can define custom columns in the Rooms and Slots sheets. The tooling will simply ignore them.

Rooms

Rooms may be physical (e.g., TPAC groups) or virtual (e.g., for Breakouts Day). (Some data that makes sense for a physical room may not be relevant for a virtual room.)

Room name may be anything, e.g., Salon Ecija. Casing in names and spaces does not matter.

Recognized room characteristics (columns in the sheet) are:

• capacity: to set the room's capacity in number of seats. Value must be an integer.
• location: to set the room's location. Value can be any string, e.g., 2nd floor, or next to the registration desk. This information can help achieve some scheduling goals (through manual edits) such as scheduling accessibility-related sessions on the same floor.
• vip: boolean flag to make the room a VIP room. A VIP room appears in the schedule grid and you can assign a session or group meeting to a VIP room yourself by manually editing the schedule, but the scheduler never assigns any session or group meeting to a VIP room by itself. Value must be true or false.
• Zoom related information (typically provided by Ralph). This data is copied to the calendar except where noted.
  • Zoom ID column
  • Zoom passcode
  • Zoom link
  • Zoom host code (not copied to the calendar)

Rooms can be filled out or updated at any time.

Slots

A slot is defined by a date, start time, and end time.

Days and slots should not change once people begin to propose sessions because the GitHub template hard-codes the days/slots. If it is necessary to update them, then contact Ian and François who will (1) update the spreadsheet (2) update the template and (3) consider options for existing issues.

Recognized slot characteristics (columns in the sheet) are:

• vip: boolean flag to make the slot a VIP slot. A VIP slot appears in the schedule grid and you can assign a session or group meeting to a VIP room yourself by manually editing the schedule, but the scheduler never assigns any session or group meeting to a VIP slot by itself. Value must be true or false.

Note: This was useful to help implement our plan to schedule breakout sessions in two phases: Monday-Wednesday for sessions proposed before TPAC, and Thursday for sessions proposed during TPAC. We implemented the Thursday slot as a "VIP" slot for the initial round of scheduling. Then removed that label when the time came to schedule Thursday breakouts.

Generated sheets

The following sheets are generated by the tooling:

• List: Data gathered from GitHub about proposed group meetings or breakout sessions. This is not a schedule, just a list of sessions to be scheduled.
• Schedule vN / Schedule vN issues: The Schedule vN sheet is generated by the tool when you propose a schedule. It represents the schedule as a grid. The corresponding Shedule vN issues sheet lists errors and warnings produced by the scheduling tool. Each time you propose a schedule, the tool generates a new pair of Sheets (and increased the value of "N").
• Meetings: This sheet is created when you adopt a proposed schedule. Each row is a session slot, with the session title, the time of the slot, and the room. Once registration has opened, registration data is also stored in each row.
• People: A list of chair and team contact information, per W3C Working/Interest/Community group. Note that when a session does not involve a group, we don't have contact information.

The Event menu

Each event Spreadsheet has an Event menu with these options:

• Refresh sessions/groups (from GitHub). This reads GitHub session data as well as registration data.
• Schedule sessions/groups
  • Propose schedule (to new sheet). This menu also generates a second sheet with any errors and warnings.
  • Adopt schedule (on current sheet). Select a proposed sheet before using this menu.
  • Revalidate metadata / adopted schedule (after manual edits). Use this after making manual edits on the Meetings sheet.
• Publish adopted schedule and calendar. See the relevant values of "Meeting name in calendar," "Meeting slug," "Timezone," "Sync with W3C calendar," "Show rooms in calendar," and "Show tracks in calendar" on the Event sheet.
• Advanced
  • Export
    • Export event info rooms, days, slots (to GitHub). Useful after updating spreadsheet variables and pushing them to GitHub variables.
    • Export event to files (HTML, JSON)
    • Export emails of group chairs/team contacts (Groups only)
  • Set things up
    • Create GitHub repository. This is the repository where group meetings or breakout sessions will be proposed. It should only be necessary to use this menu once per event.
    • Set authorization token (Groups only)
  • Get backup from GitHub
    • Recover published schedule (from GitHub). This is only needed if the schedule data exists in GitHub but has been lost from the spreadsheet.
    • Fetch event info rooms, days, slots (from GitHub)

GitHub Repo

Work with Ian and François to get a properly setup GitHub repo for the event (see Generating and configuring the GitHub repo). Once the repo has been set up:

• Event planners should set "watch" to "All Activity" for the repo to be sure to receive comments left on issues.
• Event planners can track changes by sorting issues by "Last updated" (with filter is:issue state:open sort:updated-desc)

Sessions

Identifying chairs and groups

Calendars generated by the tools include invitations to W3C groups and individuals. Where possible, the tool uses information from the W3C database.

However, when a session proposal (on GitHub) refers to groups or individuals and the tool cannot find a matching group or individual in the W3C database, the tool issues an error. Here are ways to resolve those errors:

• Ask users to update the W3C account to include their GitHub identity, and/or
• Update a spreadsheet for unknown GitHub or group names. This spreadsheet connects the string found in the session proposal to a W3C ID in the W3C database.
  • There are two sheets: one for user accounts and one for groups.
  • If there is no entry in the W3C database (for a user account or group), use a -1 value (or a string) to tell the tool to ignore the problem. Examples: "Web Platform Tests", "WHATWG" or "W3C Chapters and Evangelists" might be used in the session proposal but have no entry in the W3C database.

Notes:

• After correcting in session descriptions, you can manually revalidate the sessions via the Refresh sessions/groups menu in the Event menu.
• After updating the spreadsheet for unknown GitHub or group names, you need to push the "Revalidate metadata / adopted schedule" button in the Advanced Menu. This has a side effect (for now) of generating an empty schedule, which can then be promptly deleted.

Validation

The description of a breakout session or group meeting issue needs to follow a specific structure so that code can parse it. This structure is more or less enforced by the issue template, but nothing prevents proposers from further editing the issue description afterwards, and experience shows that they will do that. Proposers may also set a number of constraints (room capacity, sessions that would conflict with this one, instructions for meeting planners, etc.).

The tool supports validation of session descriptions and reports errors, warnings, and notes. Event planners typically will need to edit session proposals for a variety of reasons:

• To resolve warnings and errors (see below).
• To adjust IRC channel names.
• To add or fix references to other sessions where the event planners should avoid conflicts.

Errors

• chair conflict: Session scheduled at the same time as another session with an overlapping chair. Pick up another slot.
• group conflict: Session scheduled at the same time as another session with an overlapping group. Manually edit the adopted schedule.
• chairs: Cannot retrieve the W3C account of a session chair. See Identifying chairs and groups.
• groups: Two possibilities: either the group(s) cannot be identified from the session title, or the group already had a dedicated issue. See Identifying chairs and groups
• conflict: One of the issues listed as a conflicting session is not a breakout session proposal. Drop it from the list.
• format: Jobs cannot parse the issue due to some formatting issue. Fix the session description, making sure that it respects the structure imposed by the issue template.
• irc: IRC channel conflicts with another session scheduled in the same time slot. Use different IRC channels.
• scheduling: Session scheduled in the same room and at the same time as another session. Error also reported for plenary meetings when they are not scheduled in the plenary room or when there are too many sessions scheduled in the same plenary meeting. Pick up another slot or another room for the session.
• meeting format: The meeting string could not be parsed as a list of meetings. Fix the string.
• meeting duplicate: The meeting string contains two meetings that are at the exact same time. Remove the duplicate.

Warnings

• capacity: Session room is smaller than requested capacity. Pick up another room if possible.
• conflict: Session scheduled at the same time as another session identified as conflicting. Pick up another slot if possible.
• duration: Session scheduled during a 30mn slot but 60mn was preferred. Pick up another slot if possible.
• minutes: No link to the minutes whereas session is past. Check with session chairs.
• minutes origin: Minutes are not stored on www.w3.org or lists.w3.org. Publish minutes on W3C's web site.
• switch: Session scheduled in two different rooms from one slot to the other (note a switch of room between days and non consecutive slots is not reported as a warning)
• track: Session scheduled at the same time as another session in the same track. Pick up another slot if possible.
• times: Session scheduled at different times than requested ones in the session description. Make sure that everyone is fine with the schedule.
• plenary: Session scheduled in parallel with a plenary meeting. Make sure that is intended.

Some warnings cannot be fixed: a session may have no minutes, there may be too many sessions in a track to avoid scheduling conflicts, there may be no room left to meet the requested capacity, etc. To tell the validation logic to stop reporting a warning, add a -warning:[value] instruction to the "Note" custom project field. For instance, to drop the "minutes" warning, add -warning:minutes to the "Note" field.

Checks

• instructions: Proposal has instructions for meeting planners. Check and remove flag once addressed.
• irc channel: IRC channel name was generated from the title. Check and remove flag once addressed.

Schedules

Below we describe the flow for creating, editing, and publishing a schedule.

For Breakouts sessions, the Breakouts sheet represents the adopted schedule. It includes the sessions that have been loaded into it from GitHub (see "Refresh sessions" below) as well as the assignment of days/slots and rooms to those sessions.

For Group meetings, the Meetings sheet represents the adopted schedule (the assignment of days/slots and rooms to sessions). The 'List' sheet includes the sessions that have been loaded into it from GitHub (see "Refresh sessions" below)

For both types of events, assignments of days/slots, and rooms to sessions can be made automatically (see "Generate a schedule" below) or manually (see "Manually edit a schedule").

Note that you can always use the Spreadsheet "undo" function to undo edits, although below we describe more convenient ways to experiment with and restore schedules.

Refresh sessions

Activate the Refresh sessions/groups (from GitHub) menu:

• to read the latest session data from GitHub into the Breakouts sheet (or List sheet for group meetings). It is good practice to refresh sessions on a regular basis, especially before doing any schedule generation.
• to read registration data (once registration has opened).
• to read chair and team contact information (into the "People" sheet)

Generate a schedule

Activate the Schedule sessions/groups menu, which generates a grid view of the schedule on a new sheet. In the generated grid view on a new sheet:

• Where rooms or days/slots have already been assigned to a session in the Breakouts sheet (or Meetings sheet for group meetings), the tool preserves those assignments.
• Where there are no assignments, the tool automatically generates assignments (taking into account constraints expressed in the session descriptions and not-yet-assigned rooms and days/slots).

The tool does not modify the Breakouts sheet (or Meetings sheet for group meetings) itself during this process; the tool only "fills in the blanks" (if any) in the generated grid view.

See Common scheduling use cases below.

Notes:

• You should refresh session data before generating a schedule.
• Validation errors and warnings are published in a companion sheet with the same name.
• The spreadsheet is set up to protect sheets so that they are not modified or deleted accidentally. In general, if you are prompted with a warning not to proceed, you should obey the warning. There is, however, once exception: when you want to delete a sheet that holds a generated schedule, you will be prompted twice and, if you are certain you want to delete the generated schedule, you should proceed despite the warnings.

Adopt a schedule

The tool randomizes sessions as part of generating a grid and filling in the blanks. The randomization means that generated grids are all different from each other, and some are likely more interesting than others. Event planners generally compare a series of generated grids and pick the best one. Thus, after generating several grids:

• Choose the "best" generated grid.
• Correct any errors and warnings.
• "Adopt it" as the official schedule by selecting the sheet with your preferred schedule and activating the Adopt schedule (on current sheet) menu.

This causes the tool to modify the Breakouts sheet (or Meetings sheet for group meetings) itself (filling in the blanks).

Once registration for the event has opened, the registration numbers are stored in the Meetings sheet.

Note: We recommend not deleting a sheet (e.g., "Schedule v3") that holds the data adopted into the Breakouts sheet (or Meetings sheet). This sheet can serve as a backup in case you decide to "throw out" the adopted schedule and try something else, then decide you actually want to restore the previous schedule.

Manually edit an adopted schedule

To change an adopted schedule (e.g., switch rooms for two sessions, or switch their slots), edit data on the Breakouts Day. Then you can activate the Schedule sessions/groups menu to generate a new sheet that is a grid view of the manually edited schedule.

Note: You may wish to revalidate the schedule after manual editing via the Revalidate metadata / adopted schedule (after manual edits) (advanced) menu. This will generate a new pair of sheets (which can be deleted once checked).

Publish an adopted schedule and calendar

The data on the Breakouts sheet (or Meetings sheet for group meetings) represents the current (adopted) schedule. The tool uses this data to generate the calendar.

To publish the calendar (including after any manual editing of the schedule), activate the Publish adopted schedule and calendar menu.

To avoid confusing event attendees, we refrain from publishing an unstable / evolving schedule. The status of calendar entries generated by the Publish adopted schedule and calendar menu depends on the "Sync with W3C calendar" parameter in the "Event" sheet. Values are:

• no (default): the tool will not touch the W3C calendar at all.
• draft: publish the schedule to the W3C calendar where all the events are in "draft" state. Draft entries are not publicly visible but are visible to the calendar administrators. This setting is useful for confirming the tool is correctly pushing information to the calendar. Draft entries can be deleted.
• tentative: publish the schedule to the W3C calendar where all the events are in "tentative" state. Use this setting in conjunction with announcing a draft schedule to the community. It is a feature of the W3C calendar system that tentative entries cannot be deleted, only canceled.
  • In addition, it is customary not to publish room names for TPAC group meetings until the schedule has been finalized. To hide room names, set the "Show rooms in calendar" parameter to "no" when publishing calendar entries in the tentative state. Note: it is generally not harmful to show room names for virtual meetings.
  • In addition, by default we do not publish any track names in the calendar so the "Show tracks in calendar" parameter is set to "no" by default. Setting it to "yes" causes track information to be shown in the calendar.
• confirmed: publish the schedule to the W3C calendar where all the events are in "confirmed" state. Only use this setting when you are ready to announce the "final" schedule. Note that you can still update/modify calendar entries in the "confirmed" state after schedule changes. If you have set the "Show rooms in calendar" parameter to "no" for a "tentative" calendar, be sure to set it to "yes" for a confirmed calendar.

Note: The tool does not yet automatically remove canceled sessions from a calendar; see issue 30 for what needs to be done.

Note: Once registration has opened, any changes to the group meeting schedule need to be reported to the Events Team so that they can update the registration form and let people who have already registered know about the changes.

Common scheduling use cases

Automatically allocate rooms based on registration data

Typically we announce a tentative schedule for group meeting sessions when registration opens. The tentative schedule does not reflect actual room allocations. As the event nears, we allocate the group meeting sessions to rooms based on registration data and room capacity. To do so:

• In the Meetings Sheet, clear the data in the Room column.
• Use the "Propose Schedule" menu to propose a schedule (or more than one and choose the best)
• Use the "Adopt Schedule" menu
• Manually edit the Meetings sheet as needed (e.g., to eliminate unnecessary room switches, or to override the scheduler to put related sessions on the same floor, etc.)
• Check the results with "Revalidate metadata / adopted schedule" in the "Advanced" menu
• Use the "Publish adopted schedule and calendar" menu. Note: If this is the final schedule, change the value of "Sync with W3C calendar" on the Event sheet to "Confirmed"

Regenerate a brand new schedule

Suppose you have generated, adopted, and even manually edited a schedule and then conclude you think starting from scratch might be useful. To generate a brand new schedule:

• Call "Schedule v3" the previously adopted schedule. Don't delete this sheet; it's a backup.
• On the Breakouts sheet (or Meetings sheet) clear all the room and day/slot data. You can also delete just some of the data (leaving scheduling details you know you want to preserve) and the scheduling tool will fill in the blanks.
• Activate the Refresh sessions/groups (from GitHub) menu
• Activate the Schedule sessions/groups menu. Suppose this generates sheet "Schedule v4".
• Select the v4 sheet and activate the Adopt schedule (on current sheet) menu. This updates the Breakouts sheet (or Meetings sheet) with v4 data, which you can now manually edit.
• If you still prefer "Schedule v3" to "Schedule v4" you can restore v3 by selecting the "Schedule v3" sheet and activating the Adopt schedule (on current sheet) menu.

Cancel a session

From time to time a group cancels its session(s). As of October 2025, here are the steps to take when this happens:

• Close the GitHub issue(s) for the session(s), including any relevant joint sessions.
• Remove mention of these issues from the "avoid conflict" part of any other issues that referred to them (see issue 30).
• Within the spreadsheet, refresh sessions and generate a new schedule to see if there are any errors. Note that some errors may go away because conflicts have been resolved.
• Correct any errors then adopt the newly generated schedule.
• If the session(s) appear in the event calendar, mark those entries as canceled.
• Inform the Events Team so that they may (1) remove the session(s) from the registration form and (2) inform people who have already registered that the sessions(s) have been canceled.

Allocate a room without adding it to the event calendar

Note: See issue 294 for a proposal to handle this.

Labeling a room "vip" removes it from the scheduling algorithm, so that room remains available to the events team for other purposes for the entirety of an event.

However, from time to time, the event planners want to provide a room to a group (e.g., staff task force) for a limited period, without adding that meeting to the event calendar.

The tools do not directly address this scenario. The recommended approach:

• Track these meeting requests in the same spreadsheet as the meetings that will appear in the event calendar, but in a new tab (e.g., named "Additional requests" with columns Title, Room, Slot, Nb participants).
• Schedule "public" meetings first, then allocate any remaining rooms for the additional requests and update the "Additional requests" tab accordingly.

Special Cases

Tracks

Optionally we can assign a session to one or more tracks. The scheduler does its best to put all sessions assigned to a given track in the same room. Naturally, if a session is assigned to more than one track, the scheduler cannot satisfy competing constraints and will try different tracks until one works.

To assign a session to a track, on the List sheet add the track name in the row for that session in the Track column. The value of a cell in the Track column is either a single Track name or a comma-separated list of track names.

By default, track names are only used for scheduling purposes and are not displayed in generated calendars. If you want to display track names in the calendar, set the value of the "Show tracks in calendar" parameter in the Event sheet to "yes."

Custom start/end times

All sessions are scheduled in slots using the predefined values from the Slots sheet. However, a group may want to ''advertise'' in calendars that their meeting starts after the slot's official start time and/or ends before the slot's official end time. For example, if a slot is 90 minutes but the group only needs 60 minutes, they can advertise in calendars that the session will start 30 minutes after the official slot start time.

Please note that custom start/end times do not affect the scheduling algorithm, only the generation of calendars from a Schedule. For this reason, we use the Meetings sheet to specify custom start/end times for a session as follows:

• Locate the session in the Meetings sheet.
• In the Actual start time column for that session (and/or Actual end time column), provide an actual start (or end) time using HH:MM syntax. Examples: 9:45, 09:45, 14:40.

The custom start/end times must make sense:

• The custom start time cannot overlap with a previous slot
• The custom end time cannot overlap with a next slot
• The custom start/end times must be different from the times they refine
• The custom start time must be before the custom end time.

Group meetings and joint meetings (e.g., TPAC)

For a single group meeting, the issue title must be the name of the group that will meet, as it appears in the W3C database, group type included (e.g., Community Group, Working Group). The group type may be abbreviated (BG, CG, IG, WG) to keep the title shorter. Casing does not matter.

For a joint meeting, the title must be the list of group names separated by a comma, and or &. The title must also end with joint meeting. Casing also does not matter.

For example:

• Second Screen CG
• WebTransport Working Group
• Media WG & Web Real-Time Communitcations WG joint meeting
• JSON for linking data CG, Web of Things WG, RDF Dataset Canonicalization and Hash WG Joint Meeting

Session validation fails when the name of a group cannot be identified as an existing W3C group. If the group is supposed to be a W3C group, check the group name and type against the W3C database and fix the name accordingly. If the group is not a W3C group, add it to the spreadsheet for identifying chairs and groups.

Note: Session validation fails when more than one issue exists for the same group, unless highlights are used as described below.

Highlighting a specific group topic

In general, session titles for group meetings are limited to a group's name. However, from time to time a Working Group (e.g., one with many deliverables) wants to highlight for other groups when (in which day/slot) they plan to discuss a particular topic.

The tooling supports the ability to put a topic in the session title in addition to the group's name. Meeting highlights must come after a : or a >. Any number of spaces may be inserted before/after these characters.

For example:

• WICG: Digital Credentials API
• Second Screen WG > OSP
• Media WG : WebCodecs

The full issue title (with the meeting highlight) will be used in the schedule grid and calendar.

Multiple issues may be defined for the same group(s) provided they define different meeting highlights. For example, there may be three issues defined with the following titles:

• WICG
• WICG: Digital Credential API
• WICG: Fenced Frame

Plenary sessions

Warning

Changes made to the tools to handle group meetings partially broke the plenary meeting mechanism. If you need plenary meetings for your event, ask François (@tidoust) to stop procrastinating.

To enable plenary meetings at the event (larger and broader audience, to raise awareness on a series of sessions):

1. Make sure that the session.yml file contains a type selection field that lets proposers choose between breakouts and plenary types, as done for Breakouts day 2024
2. If the name of the plenary room is different from "Plenary", add plenary room: [room] to the project's short description, e.g., plenary room: BigGreatRoom.
3. If the number of sessions in a plenary meeting is different from 5, add plenary holds: [nb] to the project's short description, e.g., plenary holds: 6.
4. If the IRC channel for plenary meetings is different from #plenary, add plenary channel: [channel] to the project's short description, e.g., plenary channel: #brilliant-ideas.

The scheduler will automatically assign a plenary meeting to an available slot and avoid scheduling breakout sessions in parallel with any other sessions. To force a specific slot, assign it to one of the sessions in the plenary before you run the scheduler.

The scheduler will create one calendar event per plenary meeting, linked from all sessions in the plenary meeting.

Sessions in a plenary meeting are listed in the agenda of the calendar event in the order of their issue number. To specify a different order, add order: [pos] instructions to the "Note" custom project field of each session in the plenary, where order: 1 signals the first position (sessions without an explicit order are listed last, in the order of their issue number).

Internal and low-level Matters

Setting up a spreadsheet for a new event

• In the shared drive, in the folder tpac-breakouts create a copy of [Template] TPAC YYYY - [group meetings or breakouts]. Rename the new spreadsheet appropriately.
• Add the Event menu to that spreadsheet by opening the tpac-breakouts script, in the pulldown selecting the function _createOnOpenTrigger, and running it. This function attaches the Event menu to all spreadsheets in the current folder where tpac-breakouts is run.
• In the Event sheet:
  • Set the meeting Type
  • Specify the GitHub repository name in the w3c organization (where YYYY is the current year):
    • For a W3C TPAC event, tpacYYYY-meetings
    • For a breakouts event linked to TPAC, tpacYYYY-breakouts
    • For a breakouts event on its own, breakouts-day-YYYY
  • Put the same name provided for the calendar in the "Meeting name in calendar" value cell (e.g., "Breakouts Day 2025").
    • NOTE: This will likely be replaced by a meeting slug (that will give access to both calendar and registrant info).
  • Check/Set the timezone value and other calendar settings

Generating and configuring the GitHub repo

• Once you have identified the GitHub repo in the Event sheet, you can create it by selecting the Advanced / Create GitHub Repository menu. This will take a while (typically over 1 minute).
  • The GitHub repo does not contain actual code. The jobs directly reference the w3c/tpac-breakouts repository to access the tools.
  • The new GitHub repo is created by cloning this repo template.
• Set "watch" to "All Activity" for the repo to be sure to receive comments left on issues.
• Give W3C TPAC Breakout sessions bot (@tpac-breakout-bot) write access to the repository through the Settings > Collaborators and teams menu. this makes clear when updates were made through some automated process.
• Add any events planners to the list of collaborators with Maintainer access.
• François sets up the necessary secrets and variables for access to W3C systems such as the calendar. This involves creating a GRAPHQL token under the account of tpac-breakout-bot. Select the "repo" token scope. Then assign the secret to a secret named GRAPHQL_TOKEN in the repository.
• Modify the issue template as needed (e.g., to display days/slots for group meetings because group chairs may prefer slots based on their duration).
• Create a README to describe the event and provide instructions to those proposing sessions. It is generally sufficient to copy the README from the previous year's repo and update the information appropriately.
• In the wiki for event attendees:
  • Publish the days/slots for the event (as defined in the Slots sheet)
  • Publish policies for attendees. Typically this is a set of event-specific policies followed by a link to general policies (see example policies for Breakouts Day 2025)
• In the wiki for event planners:
  • Calendar for sending messages and other activities
  • Draft messages to send to the community (look at last year's messages)

Command line usage

Additional tools

Updating session descriptions with minutes

IRC channel and bot management

Managing and publishing recordings

Getting a list of chair emails