Facilitateur de réunion tournante

Ce calculateur de facilitateur de réunion tournante prend une liste ordonnée de noms et un index d'occurrence à base zéro, puis applique l'arithmétique modulaire classique du round-robin pour que vous sachiez toujours qui anime la prochaine session, qui suit et qui a précédé dans le cycle. Les noms vides ou les index négatifs échouent avec invalid_input et ne sont pas facturés.

Comment fonctionne la rotation du propriétaire de réunion

Une rotation équitable des facilitateurs n'est rien d'autre qu'une liste ordonnée fixe de personnes et un compteur indiquant combien de fois la réunion a déjà eu lieu. Lorsque le compteur atteint N, le reste revient à zéro et la première personne facilite à nouveau ; à N plus un, la deuxième prend la chaise, et le motif continue sans cas particuliers pour les semaines bissextiles ou les mois du calendrier. Garder le noyau pur permet aux chatbots, à GitHub Actions et aux plugins de tableur de réutiliser un seul oracle au lieu de recoder la logique modulo dans trois langages. Indexez la première occurrence comme meeting_index zéro, la deuxième comme un, et ainsi de suite. Si le roster compte N personnes, le propriétaire de cette occurrence se trouve à owner_index égal à meeting_index modulo N. Comme la formule n'utilise que le reste de la division entière, deux clients partageant le même ordre de roster et le même compteur d'occurrence s'accordent toujours sur le même propriétaire même dans des fuseaux horaires différents ou hors ligne. La position dans le cycle est indiquée comme owner_index plus un afin que l'on puisse dire « troisième sur quatre dans ce cycle » sans convertir à la main les index à base zéro. Le propriétaire suivant est le nom à owner_index plus un modulo N ; le précédent enveloppe dans l'autre sens, utile lorsque vous devez demander des notes au facilitateur de la semaine précédente. La capacité n'invente ni jours fériés, ni congés, ni listes d'omission : si quelqu'un est absent, modifiez le roster ou avancez l'index dans votre couche d'orchestration.

Contrat d'entrée, champs de réponse et erreurs de validation

Les champs de sortie optionnels ne sont jamais remplis avec null : dans ce contrat simple chaque champ de succès est toujours présent. Envoyez en POST un corps JSON avec deux champs obligatoires. roster est un tableau non vide d'une à cent chaînes de noms de facilitateur dans l'ordre de rotation ; chaque entrée est tronquée des espaces, et les chaînes vides après trim sont rejetées comme invalid_input en nommant l'index fautif. meeting_index est un entier non négatif de zéro à un milliard identifiant quelle occurrence de la série vous résolvez—zéro est la première réunion. Les alias members, people et facilitators sont acceptés pour roster, et index, occurrence et week_number pour meeting_index, afin que l'automatisation existante mappe des clés familières sans renommer les charges utiles. En cas de succès le corps renvoie le roster normalisé et meeting_index, roster_size, owner et owner_index, cycle_position (base un dans le cycle), next_owner et next_owner_index, previous_owner et previous_owner_index, plus une courte chaîne de formule indiquant owner_index égal à meeting_index mod roster_size. Exemple : roster Alice, Bob, Carol, Dana avec meeting_index cinq produit owner_index un car cinq modulo quatre vaut un, donc Bob facilite, Carol est suivant et Alice est précédent. Roster manquant, vide, non tableau, meeting_index non entier ou négatif, et rosters trop grands échouent avec invalid_input et ne consomment pas de solde.

Où une API de facilitateur tournant apporte de la valeur

Les bots de product ops publient « le facilitateur de cette semaine est … » dans Slack ou Teams en appelant l'API avec l'index de la série stocké dans une clé compteur. Comme l'implémentation est parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant ; l'échec de validation est gratuit. Gardez le roster dans le même ordre dans chaque système d'enregistrement, incrémentez meeting_index une fois par occurrence (y compris les semaines sautées si vous voulez que la rotation avance) et vous obtenez des décisions de propriété reproductibles pour calendriers, runbooks et edge workers sans déployer votre propre service de planification.