Rotierender Meeting-Moderator
Mit Alice, Bob, Carol und Dana auf der Liste moderiert beim ersten Meeting (Nummer 0) Alice, danach folgt Bob, zuvor war Dana dran; nach Dana beginnt die Runde neu. Wer dieselbe Liste nutzt, erhält dieselbe Antwort. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Teilnehmerliste
- Alice, Bob, Carol, Dana
- Meeting-Index
- 0
- Listengröße
- 4
- Verantwortlicher
- Alice
- Verantwortlichen-Index
- 0
- Zyklusposition
- 1
Wiederkehrende Standups, All-Hands und Ops-Reviews laufen besser, wenn die Moderation fair rotiert statt jede Woche denselben Verantwortlichen zu belasten. Dieser Rechner für rotierende Meeting-Moderatoren nimmt eine geordnete Namensliste und einen nullbasierten Terminvorkommensindex und wendet die klassische modulare Round-Robin-Arithmetik an, damit Sie stets wissen, wer die nächste Sitzung leitet, wer folgt und wer im Zyklus vorher war. Teams betten denselben deterministischen Vertrag in Bots, Kalender und Runbooks ein, ohne Ad-hoc-Tabellenformeln zu erfinden, die auseinanderlaufen, sobald jemand hinzukommt oder geht.
So funktioniert eine faire Rotation
Eine faire Rotation braucht nur zwei Dinge: eine feste Reihenfolge der Personen und die Zahl der bereits abgehaltenen Meetings. Das erste Meeting trägt die Nummer 0 und geht an die erste Person der Liste, das nächste an die zweite und so weiter. Am Ende der Liste beginnt die Runde von vorn: Mit Alice, Bob, Carol und Dana moderiert beim fünften Meeting wieder Alice. Zusätzlich sehen Sie, wer als Nächstes dran ist, wer zuletzt moderiert hat und an welcher Stelle der Runde Sie stehen, etwa 1 von 4.
Wann Sie sie nutzen und typische Fehler
Geeignet ist das für tägliche Stand-ups, wöchentliche Demos oder monatliche Betriebsversammlungen, wenn nicht immer dieselbe Person moderieren soll. Der häufigste Fehler ist, die Reihenfolge mittendrin zu ändern: Alle müssen dieselbe Liste und dieselbe Meetingnummer verwenden, um dasselbe Ergebnis zu erhalten. Urlaube werden nicht automatisch berücksichtigt; fehlt jemand, passen Sie die Liste an oder zählen Sie die Meetingnummer weiter. Die Liste fasst bis zu 100 Namen, leere Einträge werden abgelehnt.
So funktioniert rotierende Meeting-Ownership
Eine faire Moderatorenrotation ist nichts weiter als eine feste geordnete Personenliste und ein Zähler dafür, wie oft das Meeting bereits stattgefunden hat. Erreicht der Zähler N, wrappt der Rest auf null und die erste Person moderiert erneut; bei N plus eins übernimmt die zweite den Stuhl, und das Muster läuft ohne Sonderfälle für Schaltwochen oder Kalendermonate weiter. Weil die Formel nur den ganzzahligen Divisionsrest nutzt, stimmen zwei Clients mit derselben Roster-Reihenfolge und demselben Vorkommenszähler immer im Owner überein—auch in anderen Zeitzonen oder offline.
Die Fähigkeit erfindet keine Feiertage, Urlaube oder Skip-Listen: fehlt jemand, bearbeiten Sie den Roster oder erhöhen Sie den Index in Ihrer Orchestrierungsschicht. Ein reiner Kern bedeutet, dass Chatbots, GitHub Actions und Tabellen-Plugins ein einziges Orakel wiederverwenden statt die Modulologik in drei Sprachen neu zu schreiben.
Wann sich eine rotierende Moderation besonders lohnt
Engineering-Manager planen wöchentliche Demos und wollen, dass der Gastgeber rotiert—ohne private Tabelle, die nur eine Person pflegt. Scrum Master automatisieren die Standup-Moderation, damit nicht dauernd dieselbe Senior-Engineerin die Uhr führt. Incident Commander rotieren die wöchentliche On-Call-Zeremonie-Ownership mit einem Roster, der zum Schichtplan passt.
HR- und People-Ops-Teams vergeben monatliche All-Hands-Gastgeber fair über Abteilungen.
Anwendungsfälle
Wöchentliche Standup-Gastgeber-Rotation
Übergeben Sie Team-Roster und Standup-Wochenzähler, um zu zeigen, wer das heutige Stand-up moderiert und wer als Nächstes dran ist—ohne gemeinsame Tabelle.
Faire All-Hands- und Demo-Gastgeber
Rotieren Sie monatliche All-Hands- oder Demo-Gastgeber über Abteilungen mit demselben geordneten Roster, den Ihr Handbuch bereits veröffentlicht.
Häufige Fragen
Was, wenn jemand im Urlaub ist?
Dieser Rechner modelliert keine Abwesenheiten. Entfernen Sie die Person vorübergehend aus dem Roster oder überspringen Sie den Index in Ihrer Orchestrierung vor dem Aufruf.
Wer moderiert nach der letzten Person auf der Liste?
Die Rotation beginnt wieder beim ersten Namen. Mit Alice, Bob, Carol und Dana geht das fünfte Meeting erneut an Alice, und die Reihenfolge wiederholt sich ohne Sonderfälle für Monate oder besondere Wochen.
Warum zählt das erste Meeting als null?
Weil der Zähler angibt, wie viele Meetings schon stattgefunden haben. Das erste hat die Nummer 0 und geht an Alice; zusätzlich zeigt das Ergebnis die Stelle in der Runde ab 1 gezählt, etwa 1 von 4.
Sehe ich auch, wer als Nächstes dran ist und wer zuletzt moderiert hat?
Ja. Neben der heutigen Moderation sehen Sie Nachfolger und Vorgänger. Beim ersten Meeting sind das Bob und Dana, praktisch, wenn Sie die Notizen der Vorwoche anfragen möchten.
Was tue ich, wenn jemand ins Team kommt oder geht?
Passen Sie die Liste in der Rotationsreihenfolge an und zählen Sie die Meetings wie bisher weiter. Wer dieselbe Liste und dieselbe Meetingnummer nutzt, erhält dieselbe Person, sodass Kalender und Erinnerungen nie widersprechen.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/biz/rotating-meeting-owner \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}'const res = await fetch("https://api.kit.forhosting.com/biz/rotating-meeting-owner", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/biz/rotating-meeting-owner",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/rotating-meeting-owner", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/rotating-meeting-owner", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.rotating_meeting_owner",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Leere Namen oder negative Indizes scheitern mit invalid_input und werden nicht abgerechnet.
So funktioniert rotierende Meeting-Ownership
Indizieren Sie das erste Vorkommen als meeting_index null, das zweite als eins und so weiter. Hat der Roster N Personen, sitzt der Owner dieses Vorkommens bei owner_index gleich meeting_index modulo N. Die Zyklusposition wird als owner_index plus eins gemeldet, damit Menschen „dritter von vier in diesem Zyklus“ sagen können, ohne nullbasierte Indizes von Hand umzurechnen. Der nächste Owner ist der Name bei owner_index plus eins modulo N; der vorherige wrappt die andere Richtung—nützlich, wenn Sie den Moderator der Vorwoche um Notizen bitten müssen.
Eingabevertrag, Antwortfelder und Validierungsfehler
Optionale Ausgabefelder werden nie mit null gefüllt: in diesem einfachen Vertrag ist jedes Erfolgsfeld immer vorhanden. Senden Sie per POST einen JSON-Body mit zwei Pflichtfeldern. roster ist ein nicht leeres Array von ein bis hundert Moderatorennamen-Strings in Rotationsreihenfolge; jeder Eintrag wird getrimmt, und leere Strings nach dem Trim werden als invalid_input mit Nennung des fehlerhaften Index abgelehnt. meeting_index ist eine nichtnegative Ganzzahl von null bis eine Milliarde und kennzeichnet, welches Vorkommen der Serie Sie auflösen—null ist das erste Meeting. Aliase members, people und facilitators werden für roster akzeptiert, index, occurrence und week_number für meeting_index, damit bestehende Automatisierung bekannte Schlüssel mappen kann, ohne Payloads umzubenennen. Bei Erfolg spiegelt der Body den normalisierten Roster und meeting_index, roster_size, owner und owner_index, cycle_position (einsbasiert im Zyklus), next_owner und next_owner_index, previous_owner und previous_owner_index sowie eine kurze Formelzeichenkette, die owner_index gleich meeting_index mod roster_size festhält. Beispiel: Roster Alice, Bob, Carol, Dana mit meeting_index fünf ergibt owner_index eins, weil fünf modulo vier eins ist—Bob moderiert, Carol ist nächste, Alice vorherige. Fehlender, leerer oder nicht-Array-Roster, nichtganzzahliger oder negativer meeting_index und zu große Roster scheitern mit invalid_input und werden nicht abgerechnet.
Wo eine API für rotierende Moderatoren ihren Nutzen bringt
Product-Ops-Bots posten „diese Woche moderiert …“ in Slack oder Teams, indem sie die API mit dem in einem Zähler-Schlüssel gespeicherten Serienindex aufrufen. Weil die Implementierung Parse-Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz; fehlgeschlagene Validierung ist kostenlos. Halten Sie den Roster in jedem System of Record in derselben Reihenfolge, erhöhen Sie meeting_index einmal pro Vorkommen (auch bei übersprungenen Wochen, wenn die Rotation weiterlaufen soll), und Sie erhalten reproduzierbare Ownership-Entscheidungen für Kalender, Runbooks und Edge Worker—ohne einen eigenen Scheduling-Dienst aufzubauen.
Integrationsbeispiele
Chatbot- und Kalender-Automatisierung
Lassen Sie einen Bot die API bei jedem Vorkommen mit dem Serienindex aufrufen und „Moderator: …“ in Slack, Teams oder die Kalenderbeschreibung posten.
Technische Fragen
Wie finde ich heraus, wer moderieren soll?
Senden Sie roster (geordnete Namen) und meeting_index (0 für das erste Meeting). Der Owner ist roster[meeting_index mod Rosterlänge].
Ist meeting_index nullbasiert oder einsbasiert?
Nullbasiert: das erste Vorkommen ist 0, das zweite 1 und so weiter. cycle_position in der Antwort ist einsbasiert für die Anzeige.
Kann ich members statt roster senden?
Ja. Die Aliase members, people und facilitators mappe auf roster; index, occurrence und week_number mappe auf meeting_index.
Was kostet der Rechner für rotierende Meeting-Moderatoren?
Das Browser-Tool ist kostenlos. API-Anfragen nutzen vorab bezahltes KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige Eingaben werden nicht abgerechnet.