-
Notifications
You must be signed in to change notification settings - Fork 1
Meeting 2026 08 10
amirshehataornl edited this page Aug 20, 2026
·
3 revisions
- Date: Monday, August 10, 2026
- Time: (Slot #2) 7 pm - 8 pm US Eastern Daylight Time (View Meeting Time in Your Timezone)
- Location: Virtual Meeting.
- Meeting Link: openqse.org/captcha
- Next: Monday, August 17, 2026 @ (Slot #1) 12 pm - 1 pm US Eastern Daylight Time (View Meeting Time in Your Timezone)
- Coordination across openQSE working groups
- Meeting minutes source of truth and Confluence rendering
- Tracking milestones and working-group progress
- Possible longer virtual workshop format
- Cross-working-group issue and PR workflow
| Person | Institution |
|---|---|
| Amir Shehata | ORNL |
| Bran Radovanovic | ORNL |
| Sakshi Chhabra | IISc |
| Ryan Landfield | ORNL |
| Yoonho Park | IBM |
| Abdur Rahman Hatim | IISc |
| Smriti Bajaj | Dell Technologies |
| Jiri Schindler | IonQ |
| Andy Stone | HPE |
| Doug Oucharek | ORNL |
| Claudio Siqueira de Carvalho | IBM |
| Nick Wright | NVIDIA |
| Alain Roy | IonQ |
| Josh Moles | Snoquera |
| Jonathan Skone | NERSC/LBL |
| Kevin Kissell | Alice & Bob |
| Ermal Rrapaj | NERSC/LBL |
| Muhammad Osama | AMD |
| Jeff Heckey | AWS |
| Xulong Tang | AMD |
| Yasuko Eckert | AMD |
| Eun Kyung Lee | IBM |
| Martin Schulz | TUM |
- The meeting focused on coordination mechanics for openQSE working groups, especially how to record cross-group dependencies, requests, and decisions.
- Participants generally supported using GitHub issues, pull requests, teams, labels, and possibly CODEOWNERS-style review routing for formal artifacts and cross-working-group review.
- Confluence remains useful for informal collaboration, drafts, paper outlines, and low-friction tables, but the group leaned toward GitHub as the source of truth for meeting minutes and formal tracked artifacts.
- Amir proposed rendering GitHub-hosted Markdown pages into Confluence so GitHub can provide version history while Confluence remains a readable front end.
- The group discussed the need for clearer onboarding, documentation, style guidance, and expectations so occasional contributors can participate without getting lost in GitHub workflow details.
- The Monday openQSE meetings were proposed as a place for periodic working-group updates, with roughly quarterly updates from each active workstream.
- The group discussed tracking milestones and progress in either GitHub Projects/Milestones or Confluence, with a preference for evaluating both and choosing the lowest-effort practical option.
- Martin Schulz described the MPI Forum's virtual meeting model as a possible template for longer openQSE workshops: several days, roughly four hours per day, with plenary sessions and working-group time.
- The group agreed that a longer virtual workshop is worth exploring, but should be organized around concrete outcomes and likely after working groups have had more time to mature.
- NOTICE: Notes generated using AI; please verify accuracy.
- Amir opened by identifying a recurring coordination problem: the working groups are operating on overlapping topics, and one group may need input or requirements from another.
- He used the resource-interface group needing input from the compiler group as an example.
- The main question was how to track these dependencies and make the overall effort more cohesive.
- Ryan Landfield supported explicitly recording how groups interact, noting that some participants act as translators between different technical communities.
- Amir suggested a simple shared table in Confluence as one possible mechanism, then opened the floor for alternatives.
- Yoonho Park suggested GitHub issues as a possible tracking mechanism.
- Nick Wright suggested that two representatives from each working group could periodically sync, especially people who understand the concerns of both groups.
- Josh Moles supported using GitHub issues and pull requests:
- Issues could track requests or needed input.
- Pull requests could carry proposed edits to specs or documents.
- GitHub teams could represent working groups.
- A PR touching another group's area could request review from that group before merging.
- Josh noted two practical risks:
- Each team needs enough members so one person is not a bottleneck.
- Requests should be routed to the right teams, otherwise people will be flooded with irrelevant notifications.
- Jiri Schindler suggested using GitHub workflow features such as working-group teams, subdirectory ownership, and triggers so changes in a given repo area notify the relevant people.
- Josh noted that Slack integration could remind teams about pending reviews.
- Martin Schulz cautioned that these systems work only if there is clear documentation:
- New or occasional contributors need onboarding guidance.
- Style, policies, and expectations should be documented.
- Otherwise GitHub-based processes can become confusing quickly.
- Nick framed the desired process as something between a free-for-all and strict control through a small set of gatekeepers.
- Amir raised the need for all working groups to keep minutes in a common format and in a common location.
- Yoonho said some content had already been placed in Confluence but he was open to switching to GitHub if the group preferred.
- Smriti Bajaj said Confluence works well for collaborative writing, outlines, and paper subsections, and suggested polling the group if needed.
- Ryan Landfield also preferred Confluence for prose-heavy collaboration while being comfortable with GitHub.
- Amir proposed a hybrid approach:
- Store Markdown meeting minutes in GitHub.
- Render those GitHub pages in Confluence with a plugin.
- Treat GitHub as the source of truth while Confluence provides an accessible view.
- Kevin Kissell raised a quality concern about automatically generated meeting minutes:
- In-person workshop transcription had sometimes been phonetically close but difficult to understand without context.
- He suggested checking whether the generated workshop minutes are accurate enough before relying on them.
- Amir said Teams transcripts from fully virtual meetings seem to work better, and asked Kevin to review the compiler and system-architecture workshop minutes for accuracy.
- The group broadly accepted the idea that:
- Formal, versioned artifacts such as specs should live in GitHub.
- Informal collaboration and early drafts can remain in Confluence.
- Meeting minutes should move to GitHub and be mirrored in Confluence.
- Amir proposed using Monday meetings for regular working-group updates and coordination.
- Yoonho asked how many working groups should be considered.
- Amir listed five active or proposed workstreams:
- System architecture
- Resource interface
- Compilers
- Control electronics
- Runtime
- Yoonho suggested that quarterly updates from each group would be a reasonable cadence.
- Amir then asked how milestones and progress should be tracked across groups.
- Abdur Rahman Hatim noted that both GitHub and Confluence have project-management tools, and suggested GitHub for low-friction milestone tracking because it already supports milestones and projects.
- Claudio Siqueira de Carvalho noted that GitHub labels could identify workstreams.
- Smriti suggested that someone should demo the project-management option before asking the group to adopt it.
- Doug Oucharek agreed, noting that he is comfortable with GitHub for code but less familiar with GitHub project-management features.
- Doug pointed out that a Confluence table is easy to edit and may be simpler for some participants.
- Amir proposed evaluating both GitHub and Confluence tooling and choosing the easiest option for milestones.
- Amir introduced the idea of holding a longer virtual workshop, motivated by the productive but compressed openQSE Days meeting.
- Martin Schulz described the MPI Forum model:
- The forum meets four times per year.
- Two meetings are hybrid and two are fully virtual.
- Virtual meetings reserve roughly four hours per day for three to four days.
- The schedule includes plenary time, working-group sessions, issue discussion, ticket review, and formal decisions.
- Martin said the format is intense, but productive because it gives sustained focused time rather than isolated one-hour meetings.
- Yoonho noted the time-zone challenge, especially with U.S., Europe, and Asia participation.
- Martin said the MPI Forum typically uses late European afternoon and U.S. morning, but times could rotate if needed.
- Amir asked whether multiple workstreams meet in parallel during these events.
- Martin said the schedule depends on need:
- Some time can be reserved for parallel workstreams.
- At least part of the meeting is usually plenary.
- Workstream outputs can be brought back to the plenary for broader discussion or approval.
- Nick Wright suggested beginning with the intended outcome:
- The group should identify the right topic and desired result before choosing timing and attendees.
- A generic longer workshop is attractive, but topic selection matters.
- Amir proposed waiting roughly two months so working groups can build momentum and then revisiting workshop planning with clearer topics.
- Yoonho supported that timing, noting that the interface workstream had only recently started biweekly meetings.
- Martin explained how the MPI Forum uses plenary sessions:
- Formal readings and decisions are prioritized.
- Working groups can bring topics to plenary when they need broad feedback.
- A distinction is made between informal presentations for feedback and formal readings that lead to votes or approvals.
- Amir asked whether a requirements or analysis document could be brought to plenary before it becomes a full proposal.
- Martin said yes, and described that as a normal pattern:
- A working group discusses internally.
- It presents a draft or issue to plenary when it needs feedback.
- It then takes that feedback back into the working group.
- Yoonho said a unified interface proposal from the interface workstream would be a good example of a plenary topic once mature enough.
- Amir suggested that even preliminary analysis documents might be useful plenary topics when they need feedback from other groups such as telemetry or compilers.
- Jiri supported adopting a structure that has worked in related standards or forum activities rather than inventing a new process from scratch.
- Martin pointed the group to MPI Forum meeting agendas as examples of how plenary topics and priorities are organized.
- Amir confirmed that meeting minutes should move to GitHub and be rendered into Confluence.
- For milestone tracking, he said the group should compare GitHub and Confluence options and arrange a demo.
- For cross-working-group interaction, Amir raised a concern that a large number of issues and PRs can make it hard to maintain a global picture.
- Josh said GitHub supports filtered PR views using search syntax, such as PRs assigned to a person or mentioning a person.
- Amir asked whether those filtered views could be embedded or mirrored into Confluence for a single easy-to-read page.
- Josh said he believed that was possible, but would need to test the GitHub-Confluence integration.
- Muhammad Osama noted that filters help with views by person, label, or similar criteria, but may not fully provide the big-picture status of a project.
- Muhammad suggested:
- Using GitHub Copilot or similar tooling to summarize recent contributions.
- Associating work with milestones or releases.
- Using release notes to summarize major technical progress.
- Using CODEOWNERS so changes to a given folder automatically request review from the relevant working-group owners.
- Muhammad also noted that the big-picture narrative may still be best communicated through meeting presentations and the associated minutes.
- Amir concluded that the group may need a hybrid system:
- GitHub for detailed issues, PRs, comments, and traceability.
- Confluence or meeting summaries for the global view.
- The group agreed to move meeting minutes to GitHub.
- Amir said he would send the location where minutes should be placed.
- Amir said he would record a short video showing how to render GitHub-hosted Markdown in Confluence.
- The group will evaluate milestone tracking options next.
- Amir will work with Josh, Muhammad, and others interested in the GitHub workflow for cross-working-group interaction.
- GitHub is the preferred source of truth for formal minutes, specs, reviewable artifacts, and tracked cross-group requests.
- Confluence remains useful for readable rendering, informal collaboration, early drafts, and low-friction shared tables.
- Cross-working-group coordination should be recorded explicitly, preferably through issues, PRs, labels, teams, and review routing.
- The process needs clear onboarding and style guidance to avoid excluding contributors who are less familiar with GitHub workflows.
- A longer virtual workshop is worth pursuing, but only once working groups have enough concrete topics and desired outcomes.
- Plenary sessions can be used both for formal decisions and for working groups to request broad feedback before a proposal is final.