← Back to HAI Working Group

How We Work

This document describes the practical operation of the MONAI Human-AI Interaction Working Group (WG).

Guiding Principles

Issue-driven

GitHub issues are our system of record

Async-first

Work happens primarily between meetings

Low barrier

Early and imperfect ideas are welcome

Transparent

Priorities, discussions, and agendas are public

Community-led

Anyone can contribute or claim work

The HAI Way

Principles for productive collaboration, inspired by those who came before us:

  • • Joining a ticket is better than starting a new one.
  • • Starting a new one is better than staying silent. (When in doubt, create it.)
  • • Decisions live in issues, not in meetings.
  • • Meeting notes capture "what happened," issues capture "what we decided."
  • • Progress happens asynchronously; meetings exist to unblock.
  • • Imperfect contributions beat perfect silence.
  • • If it's important enough to discuss, it's important enough to document.
  • • Transparent is better than efficient. (When forced to choose.)
  • • Anyone can contribute. Everyone can claim work.
  • • Subscribe before you criticize - context helps.
  • • If something blocks you, speak up. We're here to unblock each other.
  • • Before it's lost in Slack/Mailinglist, capture it in GitHub.

These aren't rules - they're agreements on how we work best together.

Our Coordination Hub

All technical discussions, proposals, and decisions are documented in GitHub issues.

WG Project Board

Central coordination space for all WG activities

View Project Board

MONAI Label Milestones

Focus areas and medium-term direction (not strict deadlines)

View Milestones

What Belongs in an Issue?

Issues can represent:

  • • Feature ideas or enhancement proposals
  • • Bugs or technical problems
  • • Discussion topics or open questions
  • • Workflow improvements
  • • Research or UX questions
  • • Presentation proposals for WG meetings
  • • Anything else relevant to human-AI interaction in medical imaging

Important Notes

Issues don't need to be perfect. A short description is enough to start the conversation.

Before creating a new issue: Check if a similar one already exists. If you're unsure, create it anyway - we'd rather have duplicates than miss your input.

How Work Gets Done

1

Claim an Issue

Assign yourself and indicate you'll work on it

2

Work Async

Progress through comments, commits, and collaboration

3

Others Join

By subscribing, commenting, or co-developing

4

Share Updates

Directly in the issue thread

The WG meeting is not where implementation happens. It's where we unblock, align, and connect.

When to Request WG Discussion

If you're working on an issue and need broader input:

  1. 1 Move it to or label it "Needs Discussion"
  2. 2 A coordinator will schedule it for the next WG meeting
  3. 3 It appears in the "Next WG Meeting" column

WG Meeting Structure

Meetings serve four purposes:

Community touchpoint

Staying connected as a group

Unblocking discussions

Addressing issues that need WG-level input

Issue grooming

Reviewing new issues, identifying duplicates, assigning milestones

Knowledge sharing

Short presentations on relevant topics (when proposed)

The "Next WG Meeting" column is the agenda. It's frozen ~1 week before each meeting so you can decide if attendance is valuable for you.

Meeting Documentation

Meeting notes capture:

Organizational information only

  • • Scheduling updates
  • • Process changes
  • • Announcements

Why this approach?

All technical discussions and decisions are documented in the issues themselves, not in meeting minutes. This ensures:

  • • Contributors who can't attend aren't disadvantaged
  • • Discussions remain searchable and accessible
  • • Participation works across time zones
  • • Context is preserved where it belongs

Issue Grooming Process

At each meeting, we review:

  • • New issues created since the last meeting
  • • Issues without milestone assignments
  • • Potential duplicates
  • • Unclear problem statements

The goal is to keep the backlog organized and actionable.

Who Coordinates the WG?

The WG is led by coordinators listed on the WG homepage.

Coordinators are responsible for:

  • • Scheduling and facilitating WG meetings
  • • Managing the "Next WG Meeting" agenda
  • • Issue grooming and milestone assignment
  • • Ensuring the process remains accessible and transparent

Reach out to current coordinators if you'd like to help.

Communication Channels

Issue-specific discussions

Use the GitHub issue itself (preferred)

Quick questions & chat

Join the WG

Fill out the participation form

GitHub is the source of truth for decisions. Discussions on Slack or the mailing list should be summarized back into relevant issues.

Conflict Resolution

When contributors disagree on an approach or decision:

  1. 1 Start with discussion in the issue - most conflicts resolve through clarification
  2. 2 Request coordinator input if the discussion stalls
  3. 3 Bring to WG meeting by moving to "Needs Discussion" if broader input would help
  4. 4 Community vote as a last resort (voting mechanism: TBD based on need)

The goal is consensus where possible, clarity always. We value diverse perspectives and aim for solutions that serve the broadest community needs.

Why This Approach?

This structure ensures:

Async participation works

You don't need to attend meetings to contribute

Decisions are documented

Everything is searchable and traceable

Global inclusion

Contributors from all time zones can participate fully

Scalability

The WG can grow without bottlenecking on synchronous meetings

Getting Started

  1. 1 Browse the WG Project Board
  2. 2 Look for issues that interest you
  3. 3 Comment, subscribe, or claim issues you want to work on
  4. 4 Create new issues for ideas not yet captured
  5. 5 Join WG meetings when topics relevant to you are scheduled

Questions? Open an issue on the project board or reach out to the WG coordinators.