Leitfaden für Praktiker: Einführung – Woran Sie bei der Interpretation von Kennzahlen denken sollten

  • Verwandte Metriken: Alle
  • Zielgruppe: Practitioner Guides richten sich an Praktiker, die möglicherweise keine Experten für Datenanalyse sind und besser verstehen möchten, wie die Daten zu einem Open-Source-Projekt zu interpretieren sind, um Erkenntnisse zu gewinnen, die ihnen dabei helfen können, den Projektzustand eines Open-Source-Projekts zu verbessern Projekt. Diese Leitfäden sind besonders nützlich für Open Source Program Offices (OSPOs), Projektleiter, Community-Manager, Betreuer und alle, die den Projektzustand besser verstehen und Maßnahmen ergreifen möchten, was sie aus ihren Metriken lernen.

Die Messung der Projektgesundheit ist komplex und es müssen viele potenzielle Aspekte berücksichtigt werden (Linåker et al. 2022). Die Practitioner Guide-Reihe ist darauf ausgelegt, die Projektgesundheit in eine Reihe logischer Themen aufzuschlüsseln, anhand derer Sie die Gesundheit Ihrer Open-Source-Projekte bewerten und verbessern können. Dieser Einführungsleitfaden soll Sie zum Nachdenken darüber anregen, was Sie messen möchten und wie Sie es messen können, und enthält einige allgemeine Tipps und Vorsichtsmaßnahmen. Er soll die Practitioner Guide-Reihe ergänzen, in der Sie Einzelheiten dazu finden, wie Sie Erkenntnisse zu bestimmten Themen wie Reaktionsfähigkeit, Nachhaltigkeit der Mitwirkenden, organisatorische Beteiligung und mehr gewinnen können.

Es gibt keinen allgemeingültigen Ansatz für die Verwendung von Metriken zur Messung der Projektgesundheit. Jedes Open-Source-Projekt ist ein wenig anders, und Metriken sollten immer unter Berücksichtigung der Anforderungen des jeweiligen Projekts und seines Kontexts interpretiert werden (Goggins et al. 2021). Kleine Projekte haben andere Anforderungen als große Projekte. Ein Open-Source-Betriebssystemprojekt hat ganz andere Merkmale als ein Projekt, das ein kleines Paket oder eine kleine Bibliothek erstellt. Verschiedene Communities haben unterschiedliche Arbeitsweisen bei der Erstellung ihrer Open-Source-Softwareprojekte. Projekte haben unterschiedliche Methoden zur Veröffentlichung von Releases. Projekte und die Personen, die zu ihnen beitragen, haben unterschiedliche Anforderungen und Ziele.

Am besten fängt man nicht mit den Kennzahlen an, sondern indem man sich etwas Zeit nimmt, um die Gesamtziele des Projekts zu verstehen. Wenn das Projekt in erster Linie von einer Organisation vorangetrieben wird oder einer Organisation gehört, sollten Sie auch die Ziele dieser Organisation berücksichtigen. Wenn Sie strategisch über die Gesamtziele nachdenken, können Sie besser entscheiden, was Sie messen müssen, um festzustellen, ob das Projekt seine Ziele erreicht. Open-Source-Projekte erzeugen einen Daten-Tsunami, der überwältigend sein kann, aber wenn Sie sich auf die Ziele konzentrieren, können Sie eine entwickeln Kennzahlen-Strategie So können Sie sich auf die Kennzahlen konzentrieren, die für ein bestimmtes Projekt am wichtigsten sind.

All dies und mehr wird sich auf die Interpretation aller Open-Source-Metriken auswirken. Die wahren Experten sind die Leute, die in die tägliche Arbeit an einem Projekt eingebunden sind. Neben der Konzentration auf die Ziele müssen Sie möglicherweise auch einige Zeit damit verbringen, Trends zu beobachten, die sich darauf beziehen, wer an der Community teilnimmt und wie diese teilnehmen, um ein allgemeines Gefühl für das Projekt zu bekommen und wen Sie für weitere Einzelheiten kontaktieren möchten. Sie müssen Schlüsselpersonen aus dem Projekt / der Community, die Sie messen, einbeziehen, da diese Ihnen helfen können, die Metriken und alle identifizierten Trends ethisch zu interpretieren, und zwar auf eine Weise, die für das jeweilige Projekt am sinnvollsten ist (Casari et al. 2023), wie im Abschnitt „Schritt 2: Diagnose“ ausführlicher beschrieben. Wenn Sie dies noch nicht gelesen haben Jenseits des Repositorys von Amanda Casari, Julia Ferraioli und Juniper Lovato. Ich empfehle, diesen 6-seitigen Artikel jetzt innezuhalten und zu lesen.

Im Rahmen des CHAOSS-Projekts haben wir Software (Augur und GrimoireLab) Damit können Daten gesammelt und Trends auf neutrale Weise identifiziert werden, die leicht überprüft und im Laufe der Zeit verfolgt werden können. Diese Leitfäden für Praktiker gehen jedoch nicht davon aus, dass Sie eine bestimmte Software verwenden, da Sie möglicherweise über andere Metriktools verfügen, die für Ihre spezielle Situation geeignet sind. Unabhängig davon, wie Sie Kennzahlen erfassen, helfen Ihnen diese Leitfäden bei der Interpretation dieser Kennzahlen, um aussagekräftige und umsetzbare Erkenntnisse zu gewinnen, die zur Verbesserung des Projektzustands beitragen.

Schritt 1: Trends identifizieren

Metriken für Open-Source-Projekte können verrauscht sein, da viele Datenpunkte durch die vielen Aktivitäten innerhalb eines Projekts generiert werden. Eine Möglichkeit, diesen Lärm zu durchbrechen, besteht darin, sich auf die Trends im Laufe der Zeit zu konzentrieren. Anstatt zu betrachten, was gestern oder letzte Woche passiert ist, kann es hilfreich sein, zunächst Ihre Daten nach Monaten zu aggregieren und zu prüfen, ob sich ein Aspekt Ihrer Community in den letzten drei bis sechs Monaten verbessert, stabil bleibt oder abnimmt. Sie können später einen Drilldown in die Daten für einen bestimmten Tag oder eine bestimmte Woche durchführen, um besser zu verstehen, was Sie sehen. Wenn Sie sich die Gesamttrends ansehen, können Sie übermäßige Korrekturen oder zu große Sorgen über die täglichen Schwankungen vermeiden.

Schritt 2: Diagnose

Der erste Schritt bei der Diagnose von Problemen oder der Identifizierung von Verbesserungsmöglichkeiten besteht darin, mit den Personen zu sprechen, die eng am Projekt beteiligt sind. Zeigen Sie ihnen die Daten und fragen Sie, was die Probleme verursachen könnte. Projektleiter und Community-Mitglieder wissen möglicherweise nicht, was die Probleme verursacht. Deshalb sollte jeder Leitfaden einige Tipps zum Erkunden von Bereichen und potenzielle Ideen enthalten, wo man suchen und wie man bestimmte Probleme diagnostizieren oder Verbesserungsmöglichkeiten finden kann.

Bei der Entscheidung, ob es sich bei etwas um ein Problem oder eine Sorge handelt, die angegangen werden muss, ist die erste Frage, ob es sich bei dem Problem möglicherweise um eine vorübergehende Schwankung und nicht um ein echtes Problem handelt. Was passiert sonst noch in Ihrer Community, Ihrem Projekt und Ihrem Ökosystem? Gab es eine große Konferenz, eine Hauptveröffentlichung, eine Urlaubszeit oder andere Dinge, die die Zeit der Leute zum Einbringen von Beiträgen beeinträchtigten? Es kann hilfreich sein, diese Art von Meilensteinen in einem Diagramm zu überlagern, um ihre Auswirkungen besser zu verstehen. Wenn es den Anschein hat, dass es Auswirkungen gibt, warten Sie ein oder zwei Monate und prüfen Sie, ob sich die Metrik(en) nach der vorübergehenden Unterbrechung erholen. Wie bereits erwähnt, ist es deshalb so wichtig, täglich Menschen in das Projekt einzubeziehen, die dabei helfen, die Messwerte zu interpretieren.

Ein hervorragendes Beispiel für eine vorübergehende Fluktuation sind Abwärtstrends im Juli/August und Dezember/Januar, wenn Sie viele Beitragszahler an Orten haben, an denen Ferien oder Feiertage stattfinden. Ein Abwärtstrend zeigt, dass sich die Menschen eine Auszeit nehmen, um sich auszuruhen und neue Energie zu tanken. Dies ist wahrscheinlich ein positives Zeichen für die langfristige Nachhaltigkeit Ihres Projekts und kein Problem.

Wenn Sie zu dem Schluss gekommen sind, dass das Problem wahrscheinlich andauernd und nicht nur vorübergehend ist, ist es an der Zeit, über die Ursache des Problems nachzudenken. Dies wird wahrscheinlich metrikspezifisch sein und in den Leitfäden für Praktiker zu bestimmten Themen ausführlicher behandelt.

Schritt 3: Sammeln Sie bei Bedarf zusätzliche Daten

Wenn Sie an diesem Punkt wissen, was Sie verbessern müssen und wie Sie es verbessern können, können Sie diesen Schritt vorerst überspringen. Sie können jederzeit darauf zurückgreifen, wenn Sie Änderungen vornehmen, aber in den nächsten Monaten keine Verbesserungen feststellen.

In anderen Fällen sollten Sie sich einen Bereich genauer ansehen, bevor Sie entscheiden, welche Verbesserungsmaßnahmen durchgeführt werden sollen. Die Leitfäden für Praktiker zu bestimmten Themen enthalten zusätzliche Metriken, die zur Erfassung zusätzlicher Daten zur Diagnose spezifischer Probleme verwendet werden können.

Schritt 4: Nehmen Sie Verbesserungen vor

Für diesen Schritt ist es wichtig, die Zustimmung der Community und der Projektleitung einzuholen, bevor Sie Maßnahmen zur Verbesserung ergreifen. Wenn das Projekt keine Unterstützung erhält, kann dies dazu führen, dass Änderungen unwirksam, störend oder sogar schädlich für das Projekt und die daran beteiligten Personen sind.

Open-Source-Projekte, Communities und Ökosysteme sind komplex; Änderungen, die Sie in einem Bereich vornehmen, können sich auf andere Teile des Projekts auswirken. Viele Leute, die an Open-Source-Projekten arbeiten, sind wahrscheinlich beschäftigt und haben wenig Zeit für zusätzliche Arbeit. Daher ist es wichtig, die Leute nicht bis zum Burnout zu überlasten. Aus diesen Gründen ist es normalerweise am besten, sich auf nicht mehr als zwei oder drei Verbesserungsmaßnahmen gleichzeitig zu konzentrieren.

Wie bei den anderen Schritten enthalten die Practitioner-Leitfäden für bestimmte Themen weitere Details dazu, wie Verbesserungen für dieses Thema vorgenommen werden können.

Schritt 5: Ergebnisse überwachen

Ein wichtiger Schritt, um festzustellen, ob Ihre Maßnahmen zur Verbesserung eines Themas wirksam waren, besteht darin, diese Ergebnisse weiter zu messen und dann zu überwachen. Sie sollten die Situation mindestens zwei oder drei Monate lang (bei komplexen Änderungen länger) überwachen, bevor Sie entscheiden, ob Ihre Maßnahmen anfangen, Wirkung zu zeigen. Denken Sie daran, dass Sie diesen Zeitrahmen verlängern sollten, wenn etwas passiert, das vorübergehende Schwankungen verursachen könnte.

Sie sollten es auch langfristig weiter beobachten, um zu sehen, ob Ihre Verbesserungen weiterhin Wirkung zeigen. Ein häufiges Muster ist, dass Verbesserungen dazu neigen, sich fortzusetzen, während sich die Menschen darauf konzentrieren, aber dann zurückfallen können, wenn Menschen in alte Muster verfallen und aufhören, Verbesserungen vorzunehmen. Möglicherweise durchlaufen Sie diese Schritte, um das Interesse der Menschen zu wecken und weitere Verbesserungen vorzunehmen.

Vorsichtsmaßnahmen und Überlegungen

  • Wenn Sie Metriken interpretieren und Verbesserungen an Ihrem Open-Source-Projekt vornehmen, sollten Sie immer zuerst an die an Ihrem Projekt beteiligten Personen denken und daran, welche Auswirkungen diese Änderungen auf sie haben könnten (positiv und negativ).
  • Binden Sie immer die an dem Projekt arbeitenden Personen in die Erfassung und Interpretation der Kennzahlen sowie in alle möglichen Verbesserungsmaßnahmen ein, die Sie möglicherweise durchführen.
  • Jedes Projekt ist ein wenig anders, daher ist es wichtig, die Kennzahlen im Lichte der individuellen Bedürfnisse und Betriebsweisen eines Projekts zu interpretieren.
  • Vermeiden Sie nach Möglichkeit die Verwendung von Metriken, um Projekte miteinander zu vergleichen. Wenn Sie jedoch Projekte vergleichen müssen, stellen Sie sicher, dass Sie nur Projekte mit ähnlichen Merkmalen vergleichen. Um nur einige der vielen Beispiele zu nennen: Javascript-Projekte weisen ganz andere Eigenschaften und Muster auf als C/C++-Projekte; Stiftungseigene Projekte werden sich von Projekten unterscheiden, die von Unternehmen getragen werden. und ein Projekt von der Größe von Kubernetes wird nichts mit einem Projekt zu tun haben, das eine kleine Bibliothek oder ein kleines Paket produziert.
  • Achten Sie darauf, sich niemals darauf einzulassen, dass andere Ihre Kennzahlen zu einer Waffe machen, und gehen Sie sehr vorsichtig mit Kennzahlen um, die dazu verwendet werden können, Menschen auf eine Weise miteinander zu vergleichen, die zur Bestrafung einzelner Personen führen könnte.
  • Denken Sie daran, dass Automatisierung und Bot-Aktivität die Interpretation vieler Metriken beeinflussen können. Daher ist es wichtig zu verstehen, wie Automatisierung und Bots Ihre Ergebnisse beeinflussen können.

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
  • Luis Cañas Díaz

Referenzen

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/introduction.md