Leitfaden für Praktiker: Erste Schritte mit Responsiveness

Primäre Kennzahlen:

Falls Sie das noch nicht gelesen haben Leitfaden für Praktiker: Einführung – Woran Sie bei der Interpretation von Kennzahlen denken solltenBitte halten Sie jetzt inne und lesen Sie diesen Leitfaden.

Reaktionsmetriken sind ein wichtiger Bestandteil der Beurteilung der Projektgesundheit (Eghbal, 2020) und besonders relevant für die Rekrutierung neuer Mitwirkender und die Bindung bestehender Mitwirkender. Die Reaktionsfähigkeit, einschließlich der Zeit bis zum Abschluss, ist einer der wichtigsten Faktoren, um neue Mitarbeiter für ein Projekt zu gewinnen (Fronchetti et al. 2019). Eine GitHub-Umfrage aus dem Jahr 2017 ergab, dass 95 % der Mitwirkenden bei der Überlegung, ob sie zu einem Open-Source-Projekt beitragen sollten, antworte, dass reaktionsschnelle Betreuer sehr oder ziemlich wichtig seien. Mitwirkende können entmutigt werden, wenn sie keine zeitnahe und angemessene Antwort auf einen Beitrag erhalten, können aber ermutigt werden, wenn sie eine schnelle und hilfreiche Lösung für ihren Beitrag erhalten. Wenn Projekte reaktionsfähig sind, kann dies dazu führen, dass die Leute mehr beitragen oder weiterhin beitragen möchten. Zeitnahe, durchdachte und freundliche Antworten an Mitwirkende zeigen, dass Sie ihre Arbeit schätzen.

Die Reaktionsfähigkeit kann sich auch auf den gesamten Projektbetrieb auswirken, insbesondere in Bezug auf Änderungsanfragen (Pull-Requests/Merge-Requests). Je länger eine Änderungsanfrage ohne Zusammenführung vorliegt, desto mehr Zusammenführungskonflikte häufen sich an, bis zu dem Punkt, an dem es möglicherweise zu schwierig oder unmöglich wird, sie anzunehmen. Manchmal wird ein Beitrag aufgrund von Inkompatibilitäten, Konflikten mit der Gesamtprojektrichtung oder anderen Erwägungen möglicherweise nie aufgenommen. In solchen Fällen ist es besser, jemandem auf freundliche und nachdenkliche Weise mitzuteilen, warum sein Beitrag nicht angenommen wird, als ihn im Unklaren zu lassen und seine Frustration durch ausbleibende Reaktion zu verstärken. Sie können technische Schulden reduzieren, die Arbeitsbelastung der Betreuer verringern und die Bindung der Mitwirkenden verbessern, indem Sie schnell reagieren und mit den Beiträgen Schritt halten.

Schritt 1: Trends identifizieren

Zwar gibt es auch komplexe Methoden zur Betrachtung der Reaktionsfähigkeit, der Einstieg in die Reaktionsfähigkeitsmetriken kann jedoch unkompliziert sein, wenn Sie zunächst die Trends identifizieren. Durch Anschauen Zeit bis zur ersten Reaktion, Zeit zum Schließen und Schließungsverhältnis von Änderungsanforderungen Zusammen können Sie ein Gefühl dafür bekommen, ob die Mitwirkenden rechtzeitig eine Antwort erhalten und ob Sie mit den Beiträgen Schritt halten, indem Sie Änderungsanfragen schließen (zusammengeführt oder ohne Zusammenführung geschlossen).

Zeit bis zur ersten Reaktion

Es gibt viele Möglichkeiten, die Zeit bis zur ersten Reaktion zu betrachten, einschließlich Änderungen des Mittelwerts/Medians. Dennoch ist es hilfreich, die Gesamtzahl der Änderungsanfragen mit der Zahl zu vergleichen, auf die innerhalb eines für Ihre Community angemessenen Maßstabs, beispielsweise innerhalb von zwei Werktagen, reagiert wird. Ich mag diesen Ansatz, weil Sie sehen können, wie sich das Gesamtvolumen der Beiträge auf Ihre Reaktionsfähigkeit auswirkt.

Die Zeit bis zur ersten Antwort zeigt, dass die meisten PRs innerhalb von 2 Werktagen geschlossen werden

Dieses Diagramm zeigt die Zeit bis zur ersten Reaktion eines Menschen. Dies ist wichtig, da die Leute viel Arbeit in einen Beitrag stecken und wahrscheinlich den Änderungsantrag oder das Problem beobachten und abwarten, wie es aufgenommen wird. Wenn die Nachricht tage- und wochenlang ohne Reaktion dasteht, können die Menschen entmutigt werden und das Gefühl haben, ihre Zeit verschwendet zu haben. In diesem Fall ist jede Antwort wahrscheinlich besser als keine Antwort, selbst wenn die Antwort darin besteht, ihnen zu danken und ihnen eine Vorstellung davon zu geben, wann sie mit Feedback rechnen können.

Zeit zum Schließen

Während die Zeit bis zur ersten Antwort zeigt, wie schnell Sie reagieren, wenn jemand einen Beitrag initiiert, gibt die Zeit bis zum Abschluss Aufschluss darüber, wie schnell das Projekt eine Anfrage von der Einleitung bis zum Abschluss bearbeitet. Die Schließungszeit wird häufig für Änderungswünsche und Probleme genutzt, kann aber auch für andere Arten von Beiträgen gelten. Wie mit der Zeit bis zur ersten Antwort können Mitwirkende entmutigt werden, wenn sie das Gefühl haben, dass ihre Beiträge keine Fortschritte machen und sich nicht dem Abschluss nähern.

Bei der Zeit bis zum Abschluss ist zu beachten, dass die Zeit, die zum Abschließen einer Anfrage oder zum Schließen eines Problems benötigt wird, je nach Komplexität stark schwankt. Bei Änderungsanfragen kann eine einzeilige Änderung häufig in sehr kurzer Zeit abgeschlossen werden, während eine vollständige Umgestaltung einer großen Komponente möglicherweise einen viel längeren Zeitraum für Überprüfung und Tests erfordert, bevor sie zusammengeführt werden kann. Die Zeit bis zum Abschluss von Problemen ist noch unterschiedlicher und kann zwischen einigen Minuten und vielen Jahren dauern, da einige Probleme möglicherweise so geringe Auswirkungen haben, dass sie nie eine so hohe Priorität haben, dass sich irgendjemand dazu entschließt, an ihnen zu arbeiten.

Aufgrund dieser Variabilität ist es oft eine gute Idee, zusätzlich zur durchschnittlichen Zeit bis zum Abschluss auch die mittlere Zeit bis zum Abschluss zu betrachten, da der Median wahrscheinlich näher daran liegt, wie Menschen die Zeit einschätzen, die erforderlich ist, um etwas zum Abschluss zu bringen.

Die durchschnittliche Zeit bis zum Abschluss betrug 8.941 Tage und die mittlere Zeit bis zum Abschluss 4.022 Tage

Verschlussverhältnis

Neben der Zeit, die es braucht, um eine erste Antwort zu erhalten und einen Beitrag abzuschließen, ist es auch wichtig zu verstehen, wie gut ein Projekt mit den Beiträgen Schritt hält. Beispielsweise wird eine große Anzahl offener Pull Requests manchmal als Zeichen dafür wahrgenommen, dass die Betreuer „im Umgang mit Personen außerhalb des Projekts nicht besonders gewissenhaft sind, da jeder offene Pull Request ein Codeangebot anzeigt, das ignoriert und nicht akzeptiert, abgelehnt oder kommentiert wird“ (Dabbish et al. 2012).

Schließungsquote – bleibt erhalten und hält mit den Beiträgen Schritt, die zeigen, dass sie im Juli und August in Rückstand geraten

In dieser Grafik wird die Abschlussquote für Änderungsanfragen (Merge-Anfragen/Pull-Anfragen) betrachtet, um zu sehen, ob ein Projekt mit den eingehenden Beiträgen Schritt hält. Dies ist aus mehreren Gründen wichtig. Alte Änderungswünsche bleiben manchmal zu lange bestehen, weil die Betreuer niemandem mitteilen wollen, dass sie nicht angenommen werden, oft aus triftigen Gründen, etwa architektonischer Inkompatibilität oder anderen Konflikten mit der Richtung des Projekts. Dadurch bleiben die Mitwirkenden hängen und wissen nicht, warum ihre Anfrage nicht zusammengeführt wird, was Zeit verschwenden und ein schlechtes Licht auf das Projekt werfen kann. In diesem Fall könnte es hilfreich sein, den Betreuern eine Schulung darüber zu geben, wie wichtig es ist, Änderungsanfragen abzuschließen und wie man dies mit Empathie und Freundlichkeit gegenüber den Menschen tun kann, die ihre Arbeit geleistet haben, um einen Beitrag zu leisten. Wenn selbst qualitativ hochwertige, relevante Änderungswünsche nicht in angemessener Zeit zusammengeführt werden, kann dies darauf hindeuten, dass das Projekt einfach nicht über genügend Betreuer verfügt oder dass die Betreuer nicht über die nötige Bandbreite verfügen, um mitzuhalten. Mit der Zeit wird es auch unpraktisch, alte Änderungswünsche zusammenzuführen, da es oft zu viele Zusammenführungskonflikte gibt, als dass sie realistisch gelöst werden könnten.

Schritt 2: Diagnose

Wie in der Einleitung zum Leitfaden für Praktiker erwähnt, sollten Sie damit beginnen, die Daten einigen Personen zu zeigen, die eng am Projekt beteiligt sind, damit Sie gemeinsam die in diesen Diagrammen identifizierten Trends betrachten und sie im Lichte der anderen Dinge interpretieren können, die möglicherweise passieren das Projekt. Beispielsweise zeigen die Diagramme „Zeit bis zur ersten Antwort“ und „Abschlussquote“ in Schritt 1 eine größere Lücke im Juli und August, was mich vielleicht mehr beunruhigen würde, wenn es eine andere Zeit im Jahr wäre. In diesem Fall könnte es bedeuten, dass die Leute Sommerferien machten, was für die Projektbetreuer wahrscheinlich gesund ist.

Abschlussquote – hält Beiträge aufrecht und hält sie auf dem Laufenden, was zeigt, dass das Projekt nach und nach nicht mehr mithalten kann

Wenn der Trend zeigt, dass die Reaktionsfähigkeit über mehrere Monate hinweg allmählich abnimmt, ist es möglicherweise an der Zeit, herauszufinden, warum. In der Grafik oben können Sie sehen, dass das Projekt bis Juni jeden Monat mit seinen Pull-Anfragen Schritt hielt, in letzter Zeit jedoch in Rückstand geraten ist. Da es sich erst um ein paar Monate handelt, stellt dies möglicherweise kein Problem dar, und das Problem könnte durch eine Reihe von Dingen verursacht worden sein, die möglicherweise nicht auf zugrunde liegende Probleme mit der Reaktionsfähigkeit hinweisen:

  • Der Anstieg der Beiträge im August könnte zu einem Rückstand geführt haben, den sie noch abarbeiten.
  • Da das Volumen der Pull-Anfragen gering ist, haben sie möglicherweise mehrere komplexe Pull-Anfragen erhalten, deren Zusammenführung länger dauert.

Es können jedoch auch andere Ursachen dafür verantwortlich sein, die Anlass zur Sorge geben könnten. Beispielsweise haben möglicherweise eine oder mehrere der Schlüsselpersonen nicht genug Zeit, um sich dem Projekt zu widmen, oder die erhöhte Anzahl an Pull-Anfragen übersteigt ihre Kapazitäten.

Die Vorlaufzeit zeigt an, dass die Zeit bis zum Abschluss allmählich zunimmt

Bei der Diagnose der Zeit bis zum Abschluss kann es hilfreich sein, die Zeit bis zum Abschluss im Zeitverlauf zu betrachten. In diesem Projekt nimmt die Zeit bis zum Schließen tendenziell zu und es dauert länger, Probleme zu schließen, aber sie nimmt allmählich zu. Es ist wahrscheinlich, dass das Projekt in den in dieser Grafik dargestellten fünf Jahren größer und komplexer geworden ist, daher könnte dies ein akzeptabler Anstieg sein. Es wäre gut, sich anzusehen, was während der Zeitspanne einiger dieser großen Spitzen passierte, um zu sehen, was passierte, und um zu entscheiden, ob es nicht etwas gäbe, das man anders machen könnte, um diese Spitzen besser zu bewältigen.

Schritt 3: Sammeln Sie bei Bedarf zusätzliche Daten

Die in den Schritten 1 und 2 verwendeten Beispiele bieten einen Ausgangspunkt, der erweitert werden kann, um ähnliche Reaktionsmetriken über eine Vielzahl von Kanälen hinweg zu betrachten (z. B. Probleme, Änderungsanfragen, Bewertungen).

CHAOSS verfügt über weitere Kennzahlen zur Reaktionsfähigkeit, die bei der Diagnose spezifischer Probleme in Ihrer Community helfen können.

Metriken:

Schritt 4: Nehmen Sie Verbesserungen vor

Es kann verlockend sein, zu versuchen, Probleme mit der Reaktionsfähigkeit zu lösen, indem man mehr Druck auf bestehende Betreuer ausübt, indem man sie bittet, schneller zu reagieren und mehr Beiträge zu lösen, aber das löst das langfristige Problem selten. Es kann zu kurzfristigen Gewinnen führen, aber im Laufe der Zeit könnte es der Community und dem Projekt schaden, wenn Sie Ihre Betreuer auslasten, indem Sie die zugrunde liegenden Probleme, die die mangelnde Reaktionsfähigkeit verursachen, nicht lösen.

Wenn Sie feststellen, dass die Reaktionsfähigkeit abnimmt, ist es möglicherweise an der Zeit, mehr Mitwirkende in Führungspositionen zu versetzen und einige Mitwirkende zu Betreuern Ihres Projekts zu befördern. Sie können damit beginnen, sich die Mitwirkenden in Ihrem Projekt anzusehen, um Personen zu finden, die regelmäßig Beiträge leisten, aber noch nicht Betreuer sind. Ein guter erster Schritt besteht darin, einige Mitwirkende in Prüferrollen zu befördern, wo sie die Belastung der Betreuer verringern können, indem sie Beiträge anderer Community-Mitglieder prüfen. Mehr Leute, die Beiträge überprüfen, sollten zu einer schnelleren Zeit bis zur ersten Antwort und einer verbesserten Abschlussrate von Änderungsanfragen führen, da die Betreuer weniger Arbeit für jeden Beitrag haben und sich auf die Dinge konzentrieren können, die mehr Fachwissen innerhalb des Projekts erfordern. Sie sollten auch überlegen, ob bestehende Mitwirkende bereit sind, eine Betreuerrolle innerhalb des Projekts zu übernehmen, und sie können damit beginnen, mit OWNERS oder für einen einzelnen Bereich innerhalb des Repositorys verantwortlich zu sein CODEOWNERS-Dateien um den Zugriff zu verwalten. Wenn Sie nicht bereits über eine gute Dokumentation der Führungsrollen in Ihrem Projekt verfügen, müssen Sie möglicherweise auch die Rollen und Verantwortlichkeiten für Mitwirkende, Prüfer und Betreuer besser definieren, was bei der Rekrutierung neuer Leute für diese Rollen hilfreich sein kann, indem Sie beispielsweise Folgendes verwenden: Beitragsleiter. Bitte sehen Sie sich ... an Mitwirkender Leitfaden für Nachhaltigkeitspraktiker Erfahren Sie mehr über die Rekrutierung von Mitarbeitern und deren Übernahme in Führungspositionen.

Es kann auch hilfreich sein, klare Erwartungen darüber zu formulieren, wann jemand mit einer Antwort rechnen kann. Beispielsweise kann ein „Contribution.md“-Leitfaden Mitwirkende über eine durchschnittliche oder erwartete Antwortzeit informieren. Sie können auch erwägen, in Ihren Projektmeilensteinen oder Ihrer Roadmap Details zu Freizeit oder anderen Dingen, die zu Verzögerungen bei der Reaktion führen könnten, aufzunehmen, um zu zeigen, dass es zu Verzögerungen bei der Reaktion kommen kann.

Eine weitere Möglichkeit, Reibungsverluste bei Prüfern zu verringern und es Betreuern einfacher zu machen, Beiträge zu überprüfen, ist die Verwendung von Issue- und Change-Request-Vorlagen um Mitwirkenden zu helfen, gute Beiträge zu leisten, die weniger Arbeit von den Betreuern erfordern. Hier sind a einige Beispiele für diese Art von Dingen Sie möchten möglicherweise Folgendes in diese Vorlagen und in Ihre Leitfäden für Mitwirkende aufnehmen:

  • Senden Sie keine Änderungen über X Codezeilen (500–800 könnten ein geeigneter Schwellenwert sein)
  • Senden Sie keine Änderungen, die sich auf mehr als
  • Bewahren Sie Änderungsanfragen in separaten Funktionszweigen auf.
  • Geben Sie klar an, welche Prüfungen bei einer Änderungsanforderung durchgeführt werden, bevor sie zusammengeführt werden können (z. B. Stilprüfungen, Linters, Testsuiten, signierte Commits, Prüfungen des Entwickler-Ursprungszertifikats).
  • Klare Richtlinien und Beispiele für die Benennung, Kennzeichnung und Kennzeichnung von Änderungsanforderungen.
  • Geben Sie Erwartungen an Bewertungen an (z. B. versuchen wir, Probleme/Änderungswünsche nicht länger als X Tage offen zu lassen, wir führen alle X Tage/Wochen/Monate eine Rückstandsbereinigung durch.)

Bei Vorlagen für Probleme und Änderungsanforderungen ist darauf zu achten, dass Sie eine Balance finden: Einerseits müssen Sie genügend Informationen bereitstellen, um den Betreuern die Überprüfung der Anforderungen zu erleichtern, andererseits dürfen Sie nicht so viele Informationen anfordern, dass Sie neue Mitwirkende abschrecken, bevor sie etwas beitragen können.

Sprechen Sie mit Ihren Betreuern und finden Sie heraus, wofür sie sonst noch Zeit aufwenden. Wenn Betreuer viel Zeit mit Dingen wie Community-Management, Dokumentation oder anderen nicht programmierenden Aufgaben verbringen, dann ist es gut investierte Zeit, Leute zu rekrutieren, die in diesen Rollen helfen. In anderen Fällen kann eine verbesserte Dokumentation dazu beitragen, die Arbeitsbelastung des Betreuers zu verringern. Wenn Betreuer beispielsweise viel Zeit damit verbringen, Mitwirkende einzubinden oder Fragen zum Beitragsprozess zu beantworten, könnten bessere Onboarding-Dokumente oder Mitwirkenden-Leitfäden möglicherweise etwas Zeit gewinnen, um sich auf die Beantwortung eingehender Beiträge zu konzentrieren.

Schritt 5: Ergebnisse überwachen

Wie Sie die Ergebnisse überwachen, hängt davon ab, welche Verbesserungen Sie vornehmen möchten. Die kontinuierliche Überwachung der Zeit bis zur ersten Antwort, der Zeit bis zum Abschluss und der Abschlussquote von Änderungsanfragen ist ein guter Anfang. Wenn Sie andere Daten aus Schritt 3 verwendet haben, sollten Sie diese Metriken ebenfalls überwachen.

Wenn Sie neue Genehmiger und Betreuer einstellen, kann es eine Weile dauern, bis Sie die Ergebnisse dieser Bemühungen sehen, sodass Sie möglicherweise erst nach drei bis sechs Monaten wesentliche Verbesserungen feststellen.

Die Reaktionsfähigkeit kann eine schwer zu verbessernde Messgröße sein, da sich viele Dinge, die in Ihrem Projekt passieren, auf die Reaktionsfähigkeit auswirken können. Es kommt häufig vor, dass Menschen sich auf die Reaktionsfähigkeit konzentrieren und kurzfristige Verbesserungen feststellen, die wieder verschwinden, wenn die Leute aufhören, sich darauf zu konzentrieren. Das bedeutet, dass die Reaktionsfähigkeit wahrscheinlich eine Kennzahl ist, die Sie immer überwachen sollten, unabhängig davon, ob Sie sich darauf konzentrieren oder nicht.

Vorsichtsmaßnahmen und Überlegungen

  • Die Reaktionsfähigkeit ist schwer zu diagnostizieren, da sich viele Dinge auf die Reaktionsfähigkeit auswirken können. Lassen Sie sich also nicht entmutigen, wenn Ihr erster Versuch nicht zu einer Verbesserung führt.

Zusätzliche Lektüre

Feedback

Wir würden uns über Feedback freuen, um mehr darüber zu erfahren, wie Menschen die CHAOSS Practitioner Guides nutzen und wie wir sie im Laufe der Zeit verbessern können. Bitte füllen Sie dies aus kurze Umfrage um Ihr Feedback abzugeben.

Mitwirkende

Die folgenden Personen haben zu diesem Leitfaden beigetragen:

  • Morgenröte
  • Chan Voong
  • Remy DeCausemaker
  • Luis Cañas Díaz
  • Joachim Noreiko

Literaturhinweise

CHAOSS Practitioner Guides sind MIT-lizenzierte, lebendige Dokumente und wir freuen uns über Ihr Feedback und Ihren Input. Sie können Änderungen an diesem Dokument vorschlagen unter https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/responsiveness.md