Skip to content

For TPAC Meeting Planners

Jump to bottom
François Daoust edited this page Apr 27, 2024 · 113 revisions

Principles

The tools in this repository can be used to organize:

  • group meetings during W3C TPAC events; or
  • breakout sessions during W3C breakouts events.

At a high level, the tools support the following flow:

  • Proposals for meetings from the community.
  • Validation of the information provided in these proposals.
  • Scheduling of all those proposed meetings, assigning them to rooms/dates/time slots, doing a "best fit" between the preferences of the proponents and available resources (e.g., available rooms and their capacities). The tool supports both "automatic scheduling" mode and manual overrides.
  • Pushing the resulting schedule to a W3C calendar.
  • Generating other pages (e.g., for an event site) from the calendar.

The general idea is to create a dedicated GitHub repository and a GitHub project per event. For W3C TPAC events, the purpose of the GitHub repository is to gather the list of groups that will meet. For W3C breakouts events, the purpose of the GitHub repository is to gather the list of breakout session proposals. In both cases, the list is managed as a set of open issues in the repository, to allow proposers and organizers to adjust things as needed over time, and encourage discussions.

On top of issues, the GitHub repository will contain:

  1. an issue template that provides the issue form for people who create issues;
  2. a series of jobs to automate (or semi-automate) event management;
  3. a README to set expectations.

The GitHub repository will not contain actual code, the jobs directly reference the w3c/tpac-breakouts repository to access the tools.

The jobs are used to validate group meetings (group names, requested times, room capacity) or breakout session proposals (topics, description format, constraints, preferences), suggest a schedule, synchronize the list of group meetings and sessions with an underlying W3C calendar, setup IRC bots, etc. The jobs are for meeting planners.

The jobs run in the name of the W3C TPAC Breakout sessions bot (@tpac-breakout-bot). That is on purpose, to make it clear that possible updates were made through some automated process.

The GitHub project is used to assign data (what GitHub calls fields) to GitHub repository issues. Through the GitHub project, meeting planners can assign and manage rooms, days, and slots to group meetings and session proposals, visualize validation issues, and take a peak at the resulting grid.

Note

A breakouts event may be associated with a W3C TPAC event but, as far as the tools are concerned, both events need to be organized separately (one repository and one project for each of them).

Organization topics

The organization of W3C TPAC events is out of scope for this documentation. For W3C breakouts events, the following considerations are based on our experience with 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).
    • Work with the systems team to create a breakout sessions in W3C Calendar for this year's TPAC (should appear under https://www.w3.org/calendar/tpacYYYY/breakout-sessions/ with YYYY the current year)
    • 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)

Calendar and Communications

Setting up the GitHub repository and project for the event

Create the GitHub project

  • Create the project
    • Go to the list of W3C projects
    • Click on the "New project" button
    • Set a project name. The type of project does not matter much. A "Table" project is fine. Naming suggestions: TPAC YYYY meetings, TPAC YYYY breakout sessions or Breakouts Day YYYY, with YYYY the current year, depending on the event being organized.
  • Adjust project settings
    • Go to the project's settings through the hamburger menu icon on the right.
    • Edit the project's short description as described below. This information is used by tools.
    • Consider making the project public through the "Danger zone". That is not mandatory. Experience suggests that proposers do not really like to see internals, especially if these internals include validation errors and warnings.
    • Under "Manage access", give @tpac-breakout-bot write access to the project.
    • Add a new Room field through the "+ New field" button, field type "Single select". List room names as options with their capacity in parentheses, e.g., Salon Ecija (30). The list of rooms can be provided or adjusted later on. For obvious reasons, rooms must be known before attempting to create a grid.
    • Add a new Day field through the "+ New field" button, field type "Single select". List event days as options, following the format Day (YYYY-MM-DD) or simply YYYY-MM-DD, e.g., Monday (2023-09-11). The list of days can also be provided or adjusted later on. As for rooms, days must be known before attempting to create a grid. The list will contain only one option for single day events!
    • Add a new Slot field through the "+ New field" button, field type "Single select". List TPAC breakout session slots as options, following the format HH:mm - HH:mm, e.g., 11:00 - 12:00. Duration of the slot will be computed automatically. The list of slots can also be provided or adjusted later on. As for rooms and days, slots must be known before attempting to create a grid.
    • If the sessions can be scheduled more than once during the event, add a new Meeting field through the "+ New field" button, field type "Text". That is typically needed for meetings at TPAC as groups may meet over a two-day period that spans multiple slots.
    • Add a new Error field through the "+ New field" button, field type "Text".
    • Add a new Warning field through the "+ New field" button, field type "Text".
    • Add a new Check field through the "+ New field" button, field type "Text".
    • Add a new Note field through the "+ New field" button, field type "Text".
  • Create views (views are not mandatory but may prove useful):
    • Rename the default view By room
      • Make sure layout is "Board"
      • Under "Configuration", set "Column by" to be Room. Sort by Slot
      • Make Labels a visible field; unselect Room
      • Note the view is going to be essentially useless if you created a Meeting field.
    • Create a By slot view
      • Make sure layout is "Board"
      • Under "Configuration", set "Column by" to be Slot. Sort by Room
      • Make Labels a visible field; select Room and Labels
      • Note the view is going to be essentially useless if you created a Meeting field.
    • Create a Flat list view
      • Make sure layout is "Table"
      • Adjust column headings to show Title, Room, Slot, Labels, Error, Warning, Check, Note
    • Note that you may use "Duplicate view" to speed up the creation of the last views a bit
    • Create an Errors view
      • Make sure layout is "Table"
      • Under "Configuration", set "Group by" to be "Error"
      • Adjust column headings to show Title, Room, Slot, Labels, Error, Warning, Check
    • Create a Warnings view
      • Make sure layout is "Table"
      • Under "Configuration", set "Group by" to be "Warning"
      • Adjust column headings to show Title, Room, Slot, Labels, Error, Warning, Check
    • Create a Checks view
      • Make sure layout is "Table"
      • Under "Configuration", set "Group by" to be "Check"
      • Adjust column headings to show Title, Room, Slot, Labels, Error, Warning, Check
    • Create a Notes view
      • Make sure layout is "Table"
      • Adjust column headings to show Title, Room, Slot, Labels, Error, Warning, Check, Notes
      • Fields: Title, Note, Warning
      • Under "Configuration", set "Sort by" to be "Note"
    • Be sure to Save views as you create them

Short description

The project's short description can be updated through the project's Settings page. We're using the description to set useful project's metadata that tools need. The description must be a comma separated list of key/value pairs. Possible keys are:

  • meeting (required): the name of the "Big meeting" linked to the event in the W3C calendar, typically "TPAC YYYY" for TPAC events. For example, see "Big meeting" in the calendar entry associated with one of TPAC 2023 breakout sessions. If there is no "Big meeting" for the event in the W3C calendar yet, get in touch with the Systems team. You may enter a temporary value in the meantime, but synchronization with the calendar will not work.
  • timezone (required): the timezone of the event. For example, "Europe/Madrid", "America/Los_Angeles", or "Etc/UTC". See TZ identifiers for a list of possible values.
  • type (optional, default value is "breakouts"): what issues represent. One of "breakouts" or "group".
  • calendar (optional, default value is "no"): the status that calendar entries should have in the calendar. One of "no", "draft", "tentative" or "confirmed". The "no" value means that the code will not touch the W3C calendar at all. That is typically useful when you start gathering issues and do not yet want to propagate scheduling information to a W3C calendar.
  • rooms (optional, default value is "show"): whether to set the room location (and associated Zoom information) of a meeting in calendar entries. One of "show" or "hide". Setting the value to "hide" can be useful initially if you want to propagate the overall schedule but do not want actual rooms to be known because they may still change.
  • plenary room (optional, default value is "plenary"): the name of the room that can be used for plenary sessions. This is only useful for breakouts events and if you envision that there will be "plenary" sessions.
  • plenary holds (optional, default value is 5): number of breakout sessions that a plenary meeting may contain.

Examples of descriptions:

  • meeting: TPAC 2023, timezone: Europe/Madrid: breakouts event in Spain, calendar updates disabled
  • meeting: TPAC 2024, timezone: America/Los_Angeles, type: group, calendar: confirmed: group meeting on the West Coast, calendar entries to be confirmed.
  • meeting: W3C Breakouts Day 2024, timezone: Etc/UTC, calendar: tentative, rooms: hide, plenary room: Ukulele, plenary holds: 3: virtual breakouts event, tentative calendar entries without room info, plenary room name is Ukulele and can hold 3 sessions per slot.

Using views to organize sessions

Due to GitHub:

  • In the Room view, you can move sessions from room to room, but you cannot reorder the slot times.
  • In the Slot view, you can move sessions from slot to slot, but you cannot change the room.

Note

If you created a Meeting field, in other words, if a session or group can meet during more than one slot, the views are going to be useless to review the grid. See below for an alternate mechanism.

Other notes on the project

  • While the project will de facto be tied to the repository, projects are at the organizational level on GitHub.
  • The project's Status field serves no purpose but it cannot be removed (you may still remove the options it contains)

Create the GitHub repository

Naming suggestions:

  • For a W3C TPAC event, w3c/tpacYYYY-meetings with YYYY the current year. For example, w3c/tpac2024-meetings
  • For a breakouts event linked to TPAC, w3c/tpacYYYY-breakouts with YYYY the current year. For example, w3c/tpac2023-breakouts
  • For a breakouts event on its own, w3c/breakouts-day-YYYY with YYYY the current year. For example, w3c/breakouts-day-2024

Give W3C TPAC Breakout sessions bot (@tpac-breakout-bot) write access to the repository through "Settings > Collaborators and teams" menu.

Copy the code to the repo

Latest version of the code should be in past year's repository. Get it from there. You should typically end up with the following structure:

  • .github
    • ISSUE_TEMPLATE
      • session.yml
    • workflows
      • a bunch of .yml files
  • .gitignore
  • README.md
  • package-lock.json
  • package.json

Adjust the contents of the README.md file to match the event.

Adjust the contents of the issue template (the session.yml file) to match the event, but please note that substantive changes to the issue template probably require also adjusting underlying tools.

Note: Tools are shared among breakout year repos, and the source is in the w3c/tpac-breakouts repository.

Associate project to repo

  • Under the Projects tab, associate the repo to the project

Copy wiki pages

Given the small number of wiki pages, we just copied last year's pages to this year's wiki. The resources of interest are:

  • Breakout time slots
  • Meeting planner resources, including a calendar for breakout-related activities and drafts of communications to the community.

Setup action secrets and variables, labels

For both Secrets and Actions:

  • Go to the repo "Settings"
  • Under "Secrets and Variables", click on "Actions"

Secrets tab

  • Ask François (@tidoust) to create a new repository secret named GRAPHQL_TOKEN, set to a valid Personal Access Token (classic version) with repo (public_repo is enough if repository is public, not if the repository is private) and project scopes, created on the @tpac-breakout-bot account. This secret is used to retrieve information from GitHub and update information on GitHub. Most jobs will fail to run without that secret.
  • Unless you prefer to run the tool that uploads breakout sessions info to the W3C calendar locally, create a new repository secret named W3C_PASSWORD, set to the W3C team password of the person, identified by the W3C_LOGIN variable defined below, on behalf of which the calendar entries will be edited. This step can be done at a later time, once you start integrating with the W3C calendar.

Note: We recommend attaching the Personal Access Token to @tpac-breakout-bot, and not to your own GitHub user account, so that it is clear to session proposers that validation operations get done by a bot, and are not the result of some manual processing. The @tpac-breakout-bot account is currently managed by François (@tidoust).

Variables tab

  • Create a new repository variable named PROJECT_NUMBER set to the number of the project you created. That number appears in the URL of the project's pages, e.g., https://github.com/orgs/w3c/projects/xx
  • (Optional) Create a new repository variable named PROJECT_OWNER set to the name of the repository owner. Default value if this variable is not defined is w3c which should be what you need.
  • Create a new repository variable named CHAIR_W3CID initially set to {}. That variable is to contain the mapping between GitHub identities or names of sessions chairs and their W3C IDs, when that mapping cannot be determined automatically, typically because the person did not associate their W3C account with their GitHub identity.
  • Create a new repository variable named ROOM_ZOOM initially set to {}. That variable is to contain the mapping between room names and Zoom meeting coordinates. Zoom coordinates can either be a URL, or an object with url, id and passcode properties.
  • Unless you prefer to run the tool that uploads breakout sessions info to the W3C calendar locally, create a new repository variable named W3C_LOGIN set to the W3C login of the person on behalf of which the calendar entries will be edited, e.g., fd. The W3C_PASSWORD secret must be set to the W3C password of the person identified by the W3C_LOGIN variable.

Initialize labels

The person who sets up the secrets and variables also needs to set up the labels.

  • Make sure that the GRAPHQL_TOKEN is set (see above)
  • Go the repo's "Actions" tab
  • Select the "Initialize labels" job
  • Run the job (on the main branch) through the "Run workflow" menu to setup the list of labels in the repo used to flag issues as session proposals.

For info, the project only needs a session label, which is used to distinguish session proposals from any other issues people may raise in the repo. The session label is added via the template. You may create labels to manage tracks. These labels must start with track: , e.g., track: media. There must be a space between the ":" and the track name.

Jobs for meeting planners

The jobs are used to validate group meetings or breakout session proposals, synchronize the information in the repository and project with the W3C calendar, setup IRC bots, etc.

Validate session and update W3C calendar

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 "Validate session and update W3C calendar" job runs whenever an issue gets created or edited. As its name suggests, its name is twofolds:

  1. Validate the breakout session or group meeting, reporting errors, warnings and things to check in the "Error", "Warnings" and "Check" custom project fields. This allows meeting organizers to track what needs fixing through the project's user interface. Possible values are described below.
  2. Synchronize the information in the issue with the W3C calendar. That step only happens if the project's short description enables calendar synchronization (calendar key set to something else than no), if the issue does not have any validation error, and if the issue is scheduled already.

For breakouts events, upon issue creation, the job also adds a message from the bot to thank the session proposer and set expectations.

Note

You may use the "Note" custom project field to store meeting planner notes on the session.

Errors

  • chair conflict: Session scheduled at the same time as another session with an overlapping chair. Pick up another slot.
  • chairs: Cannot retrieve the W3C account of a session chair. Adjust the CHAIR_W3CID variable accordingly.
  • 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.
  • 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. Pick up another slot or another room.

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.
  • track: Session scheduled at the same time as another session in the same track. Pick up another slot if possible.

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.

Manually validate session

This job can only be triggered manually through the "Run workflow" menu on the GitHub's repository Actions tab. It allows meeting planners to re-validate a session manually, which is useful if a scheduling conflict was fixed. You will need to provide the issue number of the session to re-validate.

Manual session validation does not synchronize the W3C calendar. Run the "Manually update W3C calendar" job to do that.

Manually validate all sessions

This job can only be triggered manually through the "Run workflow" menu on the GitHub's repository Actions tab. It allows meeting planners to re-validate the whole schedule, or to re-validate everything. Validation does not touch the W3C calendar. Run the "Manually update W3C calendar" job to do that.

Manually update W3C calendar

This job can only be triggered manually through the "Run workflow" menu on the GitHub's repository Actions tab. It allows meeting planners to synchronize the contents of the repository with the W3C calendar. Depending on the parameters provided, the job can either synchronize a specific session (identified by its nuber) or the entire list. Synchronizing the entire list may take a few minutes.

The job will typically need to run to fill the calendar in the first place once meeting planners are confident that the schedule is good enough to share.

Note

Sessions that have validation errors cannot be synchronized with the calendar.

Manually view current schedule

This job can only be triggered manually through the "Run workflow" menu on the GitHub's repository Actions tab. It allows meeting planners to visualize the current schedule in an HTML page.

There is no direct way to create an HTML page as an output of a job on GitHub. To work around that, the job produces what GitHub calls an artifact, which is a ZIP file that contains the HTML page and that gets attached to the job run results. To download the ZIP and visualize the HTML page, click on the last run of the job and retrieve the "schedule" artifact that should appear at the end of the page.

Manually create a schedule

This job can only be triggered manually through the "Run workflow" menu on the GitHub's repository Actions tab. It allows meeting planners to create a schedule for the entire event. The job requires a few parameters to run:

  • First parameter describes what previous meeting information the scheduling algorithm needs to preserve. This is useful when there already exists a partial schedule that you would like to complete. Default is to preserve everything.
  • If the first parameter says "preserve everything", second parameter describes exceptions to the rule, sessions for which existing meetings should be discarded.
  • Third parameter sets whether to suggest a schedule (default) or apply it. Applying it updates the information on GitHub. To be done with care once you're confident the schedule looks good!
  • Fourth parameter can be used to set the seed that is used to shuffle the list of sessions at the beginning of the scheduling algorithm. The fourth parameter is useful to re-generate the schedule of a previous run (the seed appears in the generated HTML page).

The job reports the created schedule in an HTML page. As with the Manually view current schedule job, there is no direct way to create an HTML page as an output of a job on GitHub, so the job produces an artifact attached to the job run results. To download the ZIP and visualize the HTML page, click on the last run of the job and retrieve the "schedule" artifact that should appear at the end of the page.

Local tools for meeting planners

The good thing about jobs is that they can be triggered from the user interface on GitHub without having to install anything. No technical knowledge required! Now, some of the tools have not been turned into jobs yet, and it can sometimes be more convenient to run tools locally for immediate feedback. This section explains how to do so. No need for deep technical expertise, but a bit of familiarity with command-line interfaces, Git and Node.js probably helps.

Pre-requisites

The following tools must be installed on your computer:

You may now clone the GitHub repository of the event to a local directory and install dependencies, through the following commands (replacing xxx with the name of the repository you created for the event):

git clone git@github.com:w3c/xxx.git
cd xxx
npm ci

Note

You do not need to clone the w3c/tpac-breakouts repository. The tools are installed as dependencies.

Next, you need to create a Personal Access Token (classic version), with repo (public_repo is enough if repository is public, not if the repository is private) and project scopes. This can be done through your profile page on GitHub (under "Settings > Developer Settings").

Save the token to a local config.json file in the directory where you cloned the repository. The file should look like:

{
    "GRAPHQL_TOKEN": "..."
}

Tools tend to evolve rapidly. To make sure that you're using the latest version of the tools, we recommend that you refresh the contents of the repository and re-install dependencies before you run the tools:

git pull origin main
npm ci

If you want to bump the version of the tools used by the repository yourself, you may run:

npm update
git add package-lock.json
git commit -m "Bump tools"
git push origin main

Visualize the current schedule

For breakouts events, the project views ("By room", "By slot") are useful to visualize the current schedule. These views are totally useless for group meetings events though, because the schedule of a group needs to be captured in the meeting field in that case, which is an opaque string for GitHub. The view-event tool can be used to create an HTML page that contains the current schedule, and additional information about sessions.

The view-event tool is the tool run by the Manually view current schedule job.

To run the tool and save the result to a grid.html file:

npx view-event > grid.html

Create a schedule

The suggest-grid tool creates a possible schedule grid for the event. The tool reports an HTML page that contains the resulting grid and additional information about sessions. The tool does not alter the data on GitHub by default but you may instruct it to apply the created grid, which will effectively update the project's data fields (meeting, room, day, slot) on GitHub.

The suggest-grid tool is the tool run by the Manually create a schedule job.

Internally, the tool starts by randomizing the list of issues. This is done both to give equal weight to issues (no reason why first created issues would take precedence for instance) and to suggest different schedules with each and every run. The tool reports the short string that was used to seed this randomizing process. To make the tool deterministic and re-create the same schedule, just pass the same seed to the tool.

Note

Passing the seed just guarantees that the sessions will be listed in a particular order at the beginning of the scheduling process. The created schedule may differ if other changes were made in between runs. For example, if a conflict was fixed or an additional issue created.

Some examples:

  • Run npx suggest-grid > grid.html to create a schedule locally and save the HTML page to a file.
  • Run npx suggest-grid all none false myseed to create a schedule locally with the seed myseed that preserves meetings information already assigned to session issues.
  • Run npx suggest-grid all none apply myseed to create a schedule with the seed myseed that preserves meetings information already assigned to session issues, and to update the session issues with the created schedule.

Validate a session

The validate-session tool is the tool run by the Manually validate session job. To run it, just pass the session issue number.

npx validate-session 61

Validate all sessions

The validate-grid tool is the tool run by the Manually validate all sessions job. By default, the tool only validates the schedule but you may tell it to validate everything.

npx validate-grid
npx validate-grid everything

Update W3C calendar

The update-calendar tool is the tool run by the Manually update W3C calendar job. It allows you to synchronize the contents of the GitHub repository with the W3C calendar.

The tool may synchronize a specific session, or all of them. You may also pass a calendar status (draft, tentative or confirmed) to override the project's calendar setting.

To interact with the W3C calendar, the tool needs to be able to impersonate you. For that to be possible, you need to set two environment variables locally (either as real environment variables or as entries in the config.json file):

  • W3C_LOGIN with your W3C login
  • W3C_PASSWORD with your W3C password

Note

Writing down your W3C password in plain text is obviously not a fantastic feature. We'll try to improve tools. In the meantime, take care of your credentials!

npx update-calendar 61
npx update-calendar all
npx update-calendar 42 tentative
npx update-calendar all confirmed

List session chairs

The list-chairs tool returns information about session chairs, including W3C IDs, and emails whenever possible. This tool is only useful for breakouts events. The tool returns private information about session chairs (email, mapping between GitHub account and W3C ID). That information is retrieved from team-only pages on the W3C web site. As with the Update W3C calendar, this means that you need to set two environment variables locally (either as real environment variables or as entries in the config.json file) so that the tool can impersonate you when it accesses the team-only pages:

  • W3C_LOGIN with your W3C login
  • W3C_PASSWORD with your W3C pasword

To get the list:

npx list-chairs

Plenary meetings

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).

Cancel a session

Not yet automated; see issue 30 for what needs to be done.

Clone this wiki locally