Einen professionellen Projektmanager einstellen

Die Einstellung eines professionellen Projektmanagers für die Leitung der Migration, ähnlich wie das Warehouse-Projekt verwaltet wurde, würde zum Erfolg dieses Projekts beitragen.

Erstellen eines Playground-CPython-Issue-Trackers auf GitHub

Wir sollten einen Playground-Issue-Tracker auf GitHub erstellen, auf dem wir den neuen Workflow experimentell testen können.

Backup von GitHub-Daten

Diese Bemühung wurde gestartet und wird als Issue in core-workflow [1] verfolgt. Wir verwenden die Migrations-API von GitHub [2], um GitHub-Daten für CPython täglich herunterzuladen. Die Archive werden in einem S3-Bucket abgelegt.

Vielen Dank an Ee Durbin für die Arbeit daran.

Aktualisieren des CLA-Hosts

Derzeit wird die CLA auf bpo gehostet. Sie muss aktualisiert werden, damit die Unterzeichnung der CLA kein bpo-Konto erfordert, und sie sollte außerhalb von bpo gehostet werden.

Der aktuelle CLA-Prozess selbst ist nicht ideal. Derzeit müssen Mitwirkende zu devguide, peps und core-workflow eine CLA unterzeichnen, und dies erfordert ein bpo-Konto. Für diese Projekte sollte kein bpo-Konto erforderlich sein.

Es gibt eine laufende Bemühung, unsere eigene Instanz von CLA Assistant anstelle des aktuellen CLA-Prozesses zu nutzen. Diskussionen darüber wurden bereits in der core-workflow-Mailingliste sowie auf Discourse gestartet.

Diese Bemühung ist derzeit ins Stocken geraten, da cla-assistant noch keine im Auftrag einer Organisation unterzeichnete CLA unterstützt.

Erstellen eines „Python Triage“-Teams auf GitHub

Die Bug-Triager auf bpo sind wertvoll für den Kern-Workflow von Python, und wir werden definitiv noch mehr Hilfe bei der Triage von Issues auf GitHub benötigen.

Auf Discourse wurde vorgeschlagen, ein „Bug Triage“-Team auf GitHub zu gründen, um beim Schließen von Issues, der Benachrichtigung der zuständigen Parteien sowie beim Anwenden von Labels auf Issues und Pull Requests zu helfen.

Die neue Triage-Rolle auf GitHub befindet sich derzeit in der Beta-Phase, und die Python-Organisation hat Zugang zu dieser Rolle erhalten, sodass wir beginnen können, sie zu nutzen.

Das „Python Triage“-Team wurde erstellt. Eine Beschreibung und Erwartungen an die Triage-Rolle wurden zum Devguide hinzugefügt.

Der Fortschritt dieses Projekts kann im Projektboard „Adding Triagers“ verfolgt werden.

Labels für die Issue-Triage erstellen

In bpo haben wir derzeit die folgenden Felder für jedes Issue:

Typen: behavior, crash, compile error, resource usage, security, performance, enhancement.

Komponenten: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...

Priorität: release blocker, deferred blocker, critical, high, normal, low

Wir werden die entsprechenden Labels erstellen.

type-behavior, type-crash, type-compile error, type-resource usage, ...

components-2to3, components-argument clinic, components-asyncio, ...

priority-release blocker, priority-deferred blocker, priority-critical, ...

Zusätzlich erstellen wir ein Label needs triage.

Die endgültigen „Labels“ werden zu einem späteren Zeitpunkt festgelegt, wenn es Zeit ist, zu GitHub Issues zu wechseln.

Ein Test-Repository, das alle möglichen Labels und Farbschemata enthält, wurde von Carol Willing erstellt und kann unter https://github.com/willingc/test-581/labels eingesehen werden.

Issue-Vorlagen erstellen

Wir werden eine Issue-Vorlage erstellen und die folgenden Überschriften hinzufügen:

---
Type: behavior | crash | compile error | resource usage (choose one)
Components: 2to3 | Argument Clinic | asyncio | Build | ... (can select more than one)
Priority: release blocker | deferred blocker | critical | ...
Needs backport to: 2.7 | 3.6 | 3.7
---

Die Idee ist, dem Issue-Ersteller zu ermöglichen, uns bei der Triage des Issues zu helfen. Die oben genannten Werte sind in der Vorlage vorausgefüllt. Der Issue-Ersteller wird Texte entfernen, die für sein Issue nicht zutreffend sind.

Basierend auf den obigen Überschriften kann der bedevere-Bot die notwendigen Labels auf das Issue anwenden. Wenn der Issue-Ersteller die oben genannten Überschriften nicht angegeben hat, wendet der Bot das Label needs triage an. Zu diesem Zeitpunkt muss ein Kernentwickler das Issue korrekt labeln.

Wir können auch die Funktion von GitHub für mehrere Issue-Vorlagen nutzen, sowie die Möglichkeit, Issue-Zuweisende und Labels automatisch mithilfe von Issue-Vorlagen festzulegen.

Aktualisierungen an bedevere

Bedevere-Bot muss aktualisiert werden, um die oben beschriebenen Issue-Überschriften zu erkennen und die richtigen Labels anzuwenden.

Bedevere-Bot kann auch die Labels für Pull-Requests kopieren, die dem Issue entsprechen.

Aktualisieren des Devguide

Der Devguide sollte mit Informationen über den neuen Workflow der Nutzung von GitHub Issues aktualisiert werden. Dies kann als separater Branch erfolgen und sollte vor der Migration erfolgen, nicht danach.

Button in bpo hinzufügen, um Issues nach GitHub zu migrieren

Dies erfordert eine Aktualisierung von bpo. Ich glaube jedoch, dass der Aufwand dafür deutlich geringer ist als eine vollständige Überarbeitung.

Wir werden einen Button in bpo erstellen, der die Issue-Beschreibung und zugehörige Kommentare in ein GitHub-Issue kopiert.

Wir müssen einen neuen Status hinzufügen: „moved“ mit der URL des GitHub-Issues.

Wir sollten nicht alle offenen Issues nach GitHub verschieben. Nur wenn jemand interessiert ist, die Arbeit oder Diskussion über ein Issue fortzusetzen, sollte das Issue nach GitHub „verschoben“ werden.

Migrierte Issues

Wenn ein Issue als „moved“ markiert ist, sollte dieses Issue schreibgeschützt sein. bpo sollte die Bearbeitung des Issues verbieten.

bpo auf schreibgeschützt setzen

Dies sollte der letzte Schritt sein. Sobald wir GitHub Issues nutzen, setzen wir bpo auf schreibgeschützt, anstatt es abzuschalten. Keine neuen Registrierungen zulassen. Keine Kommentare oder Issues erstellen lassen.

Zuordnung zwischen Issues von bpo und GitHub

Normalerweise verweisen wir bei der Referenzierung eines Issues von bpo auf bpo-XYZ, aber mit GitHub haben wir eine neue Referenz in diesem Format: https://github.com/python/cpython/issue/XYZ.

Da wir die Issues von bpo nach GitHub migrieren, benötigen wir ein neues Feld in bpo für die Referenz zu den Issues auf GitHub und dasselbe auf GitHub für die „eventuelle“ Referenz von bpo.

Für GitHub müssen wir origin: https://bugs.python.org/issueXYZ hinzufügen. Für bpo fügen wir ein neues Feld hinzu: moved to: https://github.com/python/cpython/issue/XYZ.

Benachrichtigung der Experten

Eine aktuelle Funktionalität in bpo besteht darin, Personen, die als Experten für einen bestimmten Bereich aufgeführt sind, automatisch zu benachrichtigen. Mehrere Python-Kernentwickler haben geäußert, dass sie es vorziehen, sich nicht auf alles auf GitHub zu abonnieren, sondern nur für Issues benachrichtigt zu werden, die sich auf ihren Interessen- und Fachbereich beziehen.

Um diese Situation zu verbessern, können wir einen Bot entwickeln, der Personen benachrichtigt, wenn ein Issue mit Labels kategorisiert wurde. Wenn beispielsweise ein Issue mit dem Label area-windows versehen wurde, können die Windows-Experten benachrichtigt werden. Die Benachrichtigung kann in Form einer E-Mail-Benachrichtigung oder einer @-Erwähnung auf GitHub erfolgen.

Ein GitHub-Konto sollte keine Voraussetzung sein

Als die Migration der CPython-Codebasis von Mercurial zu GitHub diskutiert wurde [3] [4], wurde angesprochen, dass wir immer noch das Hochladen von Patches auf bpo ermöglichen müssten und dass ein GitHub-Konto keine Voraussetzung für die Beteiligung an Python sein sollte.

Wenn bpo auf schreibgeschützt gesetzt wird, müssen wir eine andere Lösung finden, um Personen die Beteiligung zu ermöglichen, die kein GitHub-Konto haben.

Eine Lösung ist die Erstellung einer neuen Mailingliste „python-issues“, ähnlich der Mailingliste docs@python.org [5], damit Personen dort ihre Issues einreichen können.

In diesem Zusammenhang erinnere ich mich, dass es nach der Migration zu GitHub im Jahr 2017 einen Fall gab [6], bei dem ein Mitwirkender, der einen Patch an Mercurial übermittelte und sich weigerte, ein GitHub-Konto zu erstellen. Aus diesem Grund konnte unser Bot nicht erkennen, ob sie die CLA unterzeichnet hatten. Eine andere Person hatte sich freiwillig gemeldet, ihren Patch auf GitHub hochzuladen. Es war jedoch immer noch erforderlich, dass beide Personen die CLA unterzeichneten.

Diese spezielle Situation war kompliziert. Es kostete fünf Kernentwickler Zeit für die Untersuchung und manuelle Überprüfung der CLA, was zu Verwirrung führte.

Abschneiden der „Components“-Liste

Ist die aktuelle „Components“-Liste noch sinnvoll und relevant? Kann die Liste gekürzt werden?

Prioritätenliste

Ist die aktuelle „Priority“-Liste nützlich? Alyssa Coghlan bemerkte, dass vielleicht nur release blocker und deferred blocker nützlich sind.