Beitragen¶

Beiträge sind sehr willkommen und werden geschätzt. Jede kleine Hilfe zählt, zögern Sie also nicht!

Funktionsanfragen und Feedback¶

Mögen Sie pytest? Zeigen Sie etwas Liebe auf Twitter oder in Ihren Blogbeiträgen!

Wir würden uns auch über Ihre Vorschläge und Anregungen freuen. Reichen Sie diese gerne als Issues ein und

Erklären Sie im Detail, wie sie funktionieren sollten.
Halten Sie den Umfang so eng wie möglich. Dies erleichtert die Implementierung.

Fehler melden¶

Melden Sie Fehler für pytest im Issue-Tracker.

Wenn Sie einen Fehler melden, geben Sie bitte an

Name und Version Ihres Betriebssystems.
Details zu Ihrem lokalen Setup, die bei der Fehlerbehebung hilfreich sein könnten, insbesondere die Version des Python-Interpreters, installierte Bibliotheken und die pytest-Version.
Detaillierte Schritte zur Reproduktion des Fehlers.

Wenn Sie einen Demonstrationstest schreiben können, der derzeit fehlschlägt, aber erfolgreich sein sollte (xfail), ist das ebenfalls ein sehr nützlicher Commit, auch wenn Sie den Fehler selbst nicht beheben können.

Fehler beheben¶

Sehen Sie sich die GitHub-Issues für Fehler an. Sehen Sie sich auch die Issues „good first issue“ an, die für neue Mitwirkende freundlich sind.

Sprechen Sie mit den Entwicklern, um herauszufinden, wie Sie bestimmte Fehler beheben können. Um anzuzeigen, dass Sie an einem bestimmten Problem arbeiten, fügen Sie einen entsprechenden Kommentar zu dem spezifischen Problem hinzu.

Vergessen Sie nicht, auch die Issue-Tracker Ihrer Lieblings-Plugins zu überprüfen!

Funktionen implementieren¶

Sehen Sie sich die GitHub-Issues für Erweiterungen an.

Sprechen Sie mit den Entwicklern, um herauszufinden, wie Sie bestimmte Funktionen implementieren können.

Dokumentation schreiben¶

Pytest könnte immer mehr Dokumentation gebrauchen. Was genau wird benötigt?

Mehr ergänzende Dokumentation. Haben Sie vielleicht etwas Unklares gefunden?
Dokumentationsübersetzungen. Wir haben derzeit nur Englisch.
Docstrings. Davon kann es nie zu viele geben.
Blogbeiträge, Artikel und Ähnliches – all das wird sehr geschätzt.

Sie können Dokumentationsdateien auch direkt in der GitHub-Weboberfläche bearbeiten, ohne eine lokale Kopie zu verwenden. Das kann für kleine Korrekturen praktisch sein.

Hinweis

Bauen Sie die Dokumentation lokal mit dem folgenden Befehl auf

$ tox -e docs

Die erstellte Dokumentation sollte unter doc/en/_build/html verfügbar sein, wobei 'en' sich auf die Dokumentationssprache bezieht.

Pytest hat eine API-Referenz, die größtenteils automatisch aus den Docstrings der dokumentierten Elemente generiert wird. Pytest verwendet das Sphinx-Docstring-Format. Zum Beispiel

def my_function(arg: ArgType) -> Foo:
    """Do important stuff.

    More detailed info here, in separate paragraphs from the subject line.
    Use proper sentences -- start sentences with capital letters and end
    with periods.

    Can include annotated documentation:

    :param short_arg: An argument which determines stuff.
    :param long_arg:
        A long explanation which spans multiple lines, overflows
        like this.
    :returns: The result.
    :raises ValueError:
        Detailed information when this can happen.

    .. versionadded:: 6.0

    Including types into the annotations above is not necessary when
    type-hinting is being used (as in this example).
    """

Plugins an pytest-dev übermitteln¶

Die Entwicklung des pytest-Kerns, des Support-Codes und einiger Plugins findet in Repositories unter der pytest-dev Organisation statt

pytest-dev auf GitHub

Alle Mitglieder des pytest-dev Contributors-Teams haben Schreibzugriff auf alle enthaltenen Repositories. Der pytest-Kern und seine Plugins werden im Allgemeinen über Pull-Requests an die jeweiligen Repositories entwickelt.

Die Ziele der pytest-dev Organisation sind

Ein zentraler Ort für beliebte pytest-Plugins
Teilen der Wartungsverantwortung (falls ein Maintainer ein Plugin nicht mehr warten möchte)

Sie können Ihr Plugin einreichen, indem Sie ein neues Thema im pytest-dev GitHub Discussions veröffentlichen, das auf Ihr bestehendes pytest-Plugin-Repository verweist, welches Folgendes enthalten muss:

PyPI-Präsenz mit Verpackungsmetadaten, die einen pytest- Präfixnamen, Versionsnummer, Autoren, Kurz- und Langbeschreibung enthalten.
eine tox-Konfiguration zum Ausführen von Tests mit tox.
eine README, die beschreibt, wie das Plugin zu verwenden ist und auf welchen Plattformen es läuft.
eine LICENSE-Datei mit Lizenzinformationen, die mit den Informationen in ihren Verpackungsmetadaten übereinstimmen.
ein Issue-Tracker für Fehlerberichte und Funktionsanfragen.
ein Changelog.

Wenn kein Mitwirkender stark widerspricht und zwei zustimmen, kann das Repository an die pytest-dev Organisation übertragen werden.

Hier ist eine Übersicht darüber, wie eine Repository-Übertragung normalerweise abläuft (am Beispiel eines Repositorys namens joedoe/pytest-xyz)

joedoe überträgt den Repository-Besitz an den pytest-dev Administrator calvin.
calvin erstellt die Teams pytest-xyz-admin und pytest-xyz-developers und lädt joedoe zu beiden als **Maintainer** ein.
calvin überträgt das Repository an pytest-dev und konfiguriert den Teamzugriff
- pytest-xyz-admin **Administratorzugriff**;
- pytest-xyz-developers **Schreibzugriff**;

Das Team pytest-dev/Contributors hat Schreibzugriff auf alle Projekte, und jeder Projektadministrator ist darin enthalten. Wir empfehlen, dass jedes Plugin mindestens drei Personen hat, die berechtigt sind, auf PyPI zu veröffentlichen.

Repository-Besitzer können sicher sein, dass kein pytest-dev Administrator jemals Veröffentlichungen aus ihrem Repository vornimmt oder auf irgendeine Weise die Kontrolle übernimmt, außer in seltenen Fällen, in denen jemand nach monatelangen Kontaktversuchen nicht mehr erreichbar ist. Wie erwähnt, ist das Ziel die gemeinsame Wartung und die Vermeidung von „Plugin-Aufgaben-Abgabe“.

Vorbereitung von Pull-Requests¶

Kurzfassung¶

Forken Sie das Repository.
Holen Sie sich bei Bedarf Tags von Upstream (wenn Sie nur den Hauptzweig geklont haben git fetch --tags https://github.com/pytest-dev/pytest).
Aktivieren und installieren Sie pre-commit, um sicherzustellen, dass Stilrichtlinien und Code-Prüfungen eingehalten werden.
Folgen Sie PEP-8 für die Benennung.
Tests werden mit tox ausgeführt
```
tox -e linting,py313
```
Die Testumgebungen oben reichen normalerweise aus, um die meisten Fälle lokal abzudecken.
Schreiben Sie einen changelog-Eintrag: changelog/2574.bugfix.rst, verwenden Sie die Issue-ID-Nummer und einen der folgenden Typen: feature, improvement, bugfix, doc, deprecation, breaking, vendor, packaging, contrib oder misc für den Issue-Typ.
Sofern Ihre Änderung keine triviale Änderung oder eine Dokumentationskorrektur ist (z. B. ein Tippfehler oder eine Umformulierung eines kleinen Abschnitts), fügen Sie sich selbst zur AUTHORS-Datei hinzu, in alphabetischer Reihenfolge.

Ausführliche Version¶

Was ist ein „Pull-Request“? Er informiert die Kernentwickler des Projekts über die von Ihnen gewünschten Änderungen zur Überprüfung und Zusammenführung. Pull-Requests werden auf GitHub-Servern gespeichert. Sobald Sie einen Pull-Request senden, können wir mögliche Änderungen diskutieren und sogar später weitere Commits hinzufügen. Es gibt ein hervorragendes Tutorial darüber, wie Pull-Requests funktionieren, im GitHub Help Center.

Hier ist eine einfache Übersicht mit pytest-spezifischen Details

Forken Sie das pytest GitHub Repository. Es ist in Ordnung, pytest als Namen für Ihr Fork-Repository zu verwenden, da es unter Ihrem Benutzer leben wird.
Klonen Sie Ihren Fork lokal mit git und erstellen Sie einen Branch
```
$ git clone git@github.com:YOUR_GITHUB_USERNAME/pytest.git
$ cd pytest
$ git fetch --tags https://github.com/pytest-dev/pytest
# now, create your own branch off "main":

    $ git checkout -b your-bugfix-branch-name main
```
Gegebenenfalls werden Bugfixes in Micro-Releases und Features in Minor-Releases veröffentlicht, während inkompatible Änderungen in Major-Releases erfolgen.

Sie benötigen die Tags, um lokal zu testen, also stellen Sie sicher, dass Sie die Tags aus dem Hauptrepository haben. Wenn Sie vermuten, dass Sie sie nicht haben, setzen Sie das Hauptrepository als Upstream und holen Sie sich die Tags
```
$ git remote add upstream https://github.com/pytest-dev/pytest
$ git fetch upstream --tags
```
Wenn Sie Hilfe bei Git benötigen, folgen Sie dieser Schnellstartanleitung: https://git.wiki.kernel.org/index.php/QuickStart
Installieren Sie pre-commit und seine Hooks im pytest-Repository
```
$ pip install --user pre-commit
$ pre-commit install
```
Danach wird pre-commit bei jedem Commit ausgeführt.

https://pre-commit.com/ ist ein Framework zur Verwaltung und Wartung von mehrsprachigen Pre-Commit-Hooks, um sicherzustellen, dass Code-Stil und Code-Formatierung konsistent sind.
tox installieren

tox wird verwendet, um alle Tests auszuführen und richtet automatisch virtuelle Umgebungen ein, um die Tests darin auszuführen. (verwendet implizit https://virtualenv.pypa.io/en/stable/)
```
$ pip install tox
```
Alle Tests ausführen

Sie müssen eine unterstützte Python-Version auf Ihrem System verfügbar haben. Das Ausführen von Tests ist nun so einfach wie die Eingabe dieses Befehls
```
$ tox -e linting,py
```
Dieser Befehl führt Tests über das Tool „tox“ gegen Ihre Standard-Python-Version aus und führt auch „lint“-Code-Stil-Prüfungen durch.
Sie können nun Ihre lokale Arbeitskopie bearbeiten und die Tests nach Bedarf erneut ausführen. Bitte folgen Sie PEP-8 für die Benennung.

Sie können tox verschiedene Optionen übergeben. Um beispielsweise Tests unter Python 3.13 auszuführen und Optionen an pytest zu übergeben (z. B. bei einem Fehler in den pdb-Modus zu wechseln), können Sie dies tun
```
$ tox -e py313 -- --pdb
```
Oder um nur Tests in einem bestimmten Testmodul unter Python 3.12 auszuführen
```
$ tox -e py312 -- testing/test_config.py
```
Beim Committen formatiert pre-commit die Dateien bei Bedarf neu.
Wenn Sie es vorziehen, die Tests direkt auszuführen, anstatt tox zu verwenden, empfehlen wir, eine virtuelle Umgebung zu erstellen und eine bearbeitbare Installation mit dem dev-Extra zu verwenden
```
$ python3 -m venv .venv
$ source .venv/bin/activate  # Linux
$ .venv/Scripts/activate.bat  # Windows
$ pip install -e ".[dev]"
```
Danach können Sie die Dateien bearbeiten und pytest wie gewohnt ausführen
```
$ pytest testing/test_config.py
```
Erstellen Sie einen neuen Changelog-Eintrag in changelog. Die Datei sollte <issueid>.<type>.rst heißen, wobei *issueid* die Nummer des Problems ist, auf das sich die Änderung bezieht, und *type* einer der folgenden ist: feature, improvement, bugfix, doc, deprecation, breaking, vendor, packaging, contrib oder misc. Sie können die Erstellung des Changelog-Eintrags überspringen, wenn die Änderung das dokumentierte Verhalten von pytest nicht beeinflusst.
Fügen Sie sich selbst zur AUTHORS-Datei hinzu, falls noch nicht geschehen, in alphabetischer Reihenfolge.
Committen und pushen Sie, sobald Ihre Tests erfolgreich sind und Sie mit Ihren Änderungen zufrieden sind
```
$ git commit -a -m "<commit message>"
$ git push -u
```

Reichen Sie schließlich einen Pull-Request über die GitHub-Website ein, indem Sie diese Daten verwenden

head-fork: YOUR_GITHUB_USERNAME/pytest
compare: your-branch-name

base-fork: pytest-dev/pytest
base: main

Tests schreiben¶

Das Schreiben von Tests für Plugins oder für pytest selbst geschieht oft mit dem pytester-Fixture, als „Black-Box“-Test.

Um beispielsweise sicherzustellen, dass ein einfacher Test erfolgreich ist, können Sie Folgendes schreiben

def test_true_assertion(pytester):
    pytester.makepyfile(
        """
        def test_foo():
            assert True
    """
    )
    result = pytester.runpytest()
    result.assert_outcomes(failed=0, passed=1)

Alternativ ist es möglich, Prüfungen basierend auf der tatsächlichen Ausgabe des Terminals mit *glob-ähnlichen* Ausdrücken vorzunehmen

def test_true_assertion(pytester):
    pytester.makepyfile(
        """
        def test_foo():
            assert False
    """
    )
    result = pytester.runpytest()
    result.stdout.fnmatch_lines(["*assert False*", "*1 failed*"])

Wählen Sie beim Schreiben eines neuen Tests eine Datei aus, die gut passt. Ein Regressionstest für einen Fehler in der Option --lf sollte beispielsweise in test_cacheprovider.py gehen, da diese Option in cacheprovider.py implementiert ist. Im Zweifelsfall öffnen Sie einen PR mit Ihrer besten Vermutung, und wir können dies im Code besprechen.

Dem Entwicklungsteam beitreten¶

Jeder, der erfolgreich einen Pull-Request abgeschlossen hat, der keine zusätzlichen Arbeiten des Entwicklungsteams zum Mergen erforderte, erhält selbst Commit-Zugriff, wenn er dies wünscht (wenn wir vergessen zu fragen, senden Sie bitte eine freundliche Erinnerung). Das bedeutet nicht, dass sich Ihr Beitrags-Workflow ändert: Jeder durchläuft denselben Pull-Request- und Überprüfungsprozess, und niemand merged seine eigenen Pull-Requests, es sei denn, sie wurden bereits genehmigt. Es bedeutet jedoch, dass Sie vollständiger am Entwicklungsprozess teilnehmen können, da Sie Pull-Requests von anderen Mitwirkenden selbst mergen können, nachdem Sie sie überprüft haben.

Merge/Squash-Richtlinien¶

Wenn ein PR genehmigt und bereit ist, in den main-Branch integriert zu werden, hat man die Wahl, die Commits unverändert zu *mergen* oder alle Commits zu einem einzigen Commit *zu squashen*.

Hier sind einige Richtlinien, wie Sie vorgehen können, basierend auf Beispielen eines einzelnen PR-Commit-Verlaufs

Verschiedene Commits
- Implementiere X
- Behebe test_a
- Füge mich zur AUTHORSDatei hinzu
- fixup! Behebe test_a
- Aktualisiere tests/test_integration.py
- Merge origin/main into PR branch
- Aktualisiere tests/test_integration.py
In diesem Fall bevorzugen Sie die **Squash**-Merge-Strategie: Der Commit-Verlauf ist etwas unübersichtlich (nicht abfällig gemeint, oft committet man Änderungen einfach, weil man weiß, dass die Änderungen schließlich zusammengefasst werden), daher ist es am besten, alles in einem einzigen Commit zusammenzufassen. Sie müssen die Commit-Nachricht bereinigen und sicherstellen, dass sie nützliche Details enthält.
Separate Commits zum selben Thema
- Implementiere X
- Füge mich zur AUTHORSDatei hinzu
- Aktualisiere CHANGELOG für X
In diesem Fall bevorzugen Sie die **Squash**-Merge-Strategie: Obwohl der Commit-Verlauf nicht „unübersichtlich“ ist wie im obigen Beispiel, bringen die einzelnen Commits insgesamt nicht viel Wert, besonders wenn man die Änderungen einige Monate/Jahre später betrachtet.
Separate Commits, jeder mit seinem eigenen Thema (Refactorings, Umbenennungen usw.), aber immer noch mit einem größeren Thema/Zweck.
- Refaktoriere Klasse X zur Vorbereitung auf Feature Y
- Entferne ungenutzte Methode
- Implementiere Feature Y
In diesem Fall bevorzugen Sie die **Merge**-Strategie: Jeder Commit ist für sich wertvoll, auch wenn sie insgesamt einem größeren Thema dienen. Wenn man den Verlauf später betrachtet, ist es nützlich, die Entfernung der ungenutzten Methode separat in einem eigenen Commit zu haben, zusammen mit weiteren Informationen (wie z. B. wie sie überhaupt ungenutzt wurde).
Separate Commits, jeder mit seinem eigenen Thema, aber ohne einen größeren Thema/Zweck, außer die Codebasis zu verbessern (mit moderneren Techniken, Verbesserung der Typisierung, Entfernung von Unordnung usw.).
- Verbessere interne Namen in X
- Füge Typannotationen zu Y hinzu
- Entferne unnötige Dict-Zugriffe
- Entferne unerreichbaren Code wegen EOL Python
In diesem Fall bevorzugen Sie die **Merge**-Strategie: Jeder Commit ist für sich wertvoll, und die Informationen in jedem sind langfristig wertvoll.

Wie erwähnt, handelt es sich hierbei um allgemeine Richtlinien, nicht um in Stein gemeißelte Regeln. Dieses Thema wurde in #12633 diskutiert.

Backport-PRs* (wie die automatisch aus einem backport-Label erstellten) sollten immer **gesquasht** werden, da sie den ursprünglichen PR-Autor beibehalten.

Backporting von Fehlerbehebungen für die nächste Patch-Version¶

Pytest veröffentlicht alle paar Wochen oder Monate eine neue Feature-Version. Dazwischen werden Patch-Versionen für die vorherige Feature-Version veröffentlicht, die nur Fehlerbehebungen enthalten. Die Fehlerbehebungen beheben normalerweise Regressionen, können aber jede Änderung sein, die Benutzer vor der nächsten Feature-Version erreichen sollte.

Angenommen, die neueste Version war beispielsweise 1.2.3, und Sie möchten einen Fehler in 1.2.4 aufnehmen (prüfen Sie https://github.com/pytest-dev/pytest/releases auf die tatsächliche neueste Version). Das Verfahren hierfür ist:

Stellen Sie zunächst sicher, dass der Fehler in der main-Branch behoben ist, mit einem regulären Pull-Request, wie oben beschrieben. Eine Ausnahme davon ist, wenn die Fehlerbehebung für main nicht mehr anwendbar ist.

Automatisches Verfahren

Fügen Sie dem zu backportenden PR ein backport 1.2.x-Label hinzu. Dies erstellt einen Backport-PR gegen den 1.2.x-Branch.

Manuelles Verfahren

git checkout origin/1.2.x -b backport-XXXX # Verwenden Sie hier die Haupt-PR-Nummer
Finden Sie den Merge-Commit im PR in der *gemergten* Nachricht, zum Beispiel

nicoddemus merged commit 0f8b462 into pytest-dev:main
git cherry-pick -x -m1 REVISION # Verwenden Sie die oben gefundene Revision (0f8b462).
Öffnen Sie einen PR, der auf 1.2.x abzielt
- Präfixieren Sie die Nachricht mit [1.2.x].
- Löschen Sie den PR-Körper, er enthält normalerweise eine duplizierte Commit-Nachricht.

Wer macht die Backports¶

Wie oben erwähnt, sollten Fehler zuerst in main behoben werden (außer in seltenen Fällen, in denen ein Fehler nur in einer früheren Version auftritt). Wer sollte also das oben beschriebene Backport-Verfahren durchführen?

Wenn der Fehler von einem Kernentwickler behoben wurde, liegt die Hauptverantwortung für den Backport bei diesem Kernentwickler.
Oft erfolgt der Merge jedoch durch einen anderen Maintainer. In diesem Fall ist es nett von ihm, das Backport-Verfahren durchzuführen, wenn er die Zeit hat.
Für Fehler, die von Nicht-Maintainern eingereicht wurden, wird erwartet, dass ein Kernentwickler den Backport durchführt, normalerweise derjenige, der den PR unter main gemergt hat.
Wenn ein Nicht-Maintainer einen Fehler bemerkt, der in main behoben ist, aber noch nicht backgeportet wurde (weil Maintainer vergessen haben, das Label *needs backport* anzuwenden, oder es einfach übersehen haben), können sie auch gerne einen PR mit dem Backport öffnen. Das Verfahren ist einfach und hilft sehr bei der Wartung des Projekts.

All das oben Genannte sind keine Regeln, sondern lediglich einige Richtlinien/Vorschläge darüber, was wir in Bezug auf Backports erwarten sollten.

Backports sollten **gesquasht** werden (nicht **gemergt**), da dies den ursprünglichen PR-Autor korrekt beibehält.

Umgang mit veralteten Issues/PRs¶

Veraltete Issues/PRs sind solche, bei denen pytest-Mitwirkende Fragen/Änderungen angefragt haben und die Autoren noch nicht geantwortet/diese umgesetzt haben, oder die Diskussion einfach eingeschlafen ist, weil das Interesse verloren ging.

Es gibt viele Gründe, warum Leute nicht auf Fragen antworten oder angeforderte Änderungen umsetzen: Sie könnten beschäftigt sein, das Interesse verlieren oder es einfach vergessen, aber die Tatsache ist, dass dies in Open-Source-Software sehr häufig vorkommt.

Das pytest-Team schätzt jedes Issue und jeden Pull-Request sehr, aber da es sich um ein Projekt mit hohem Volumen handelt, bei dem täglich viele Issues und Pull-Requests eingereicht werden, versuchen wir, die Anzahl veralteter Issues und PRs durch regelmäßiges Schließen zu reduzieren. Wenn ein Issue/Pull-Request auf diese Weise geschlossen wird, ist dies keineswegs eine Ablehnung des behandelten Themas, sondern lediglich eine Möglichkeit für uns, die Warteschlange zu leeren und die Arbeit der Maintainer überschaubarer zu machen. Einreicher können das Issue/Pull-Request jederzeit später wieder öffnen, wenn es sinnvoll ist.

Wann schließen¶

Hier sind einige allgemeine Regeln, die die Maintainer bei der Entscheidung anwenden, wann Issues/PRs aufgrund von mangelnder Aktivität geschlossen werden

Issues mit dem Label question oder needs information: geschlossen nach 14 Tagen Inaktivität.
Issues mit dem Label proposal: geschlossen nach sechs Monaten Inaktivität.
Pull-Requests: Nach einem Monat sollte der Autor angepingt, das verlinkte Issue aktualisiert oder das Schließen in Betracht gezogen werden. Bei fast fertigen Pull-Requests sollte das Team erwägen, diese fertigzustellen und zu mergen.

Die oben genannten sind **keine harten Regeln**, sondern lediglich **Richtlinien**, und können (und werden oft!) von Fall zu Fall überprüft werden.

Schließen von Pull-Requests¶

Beim Schließen eines Pull-Requests muss die Zeit, Mühe und das Interesse der Person, die ihn eingereicht hat, anerkannt werden. Wie bereits erwähnt, ist es nicht die Absicht des Teams, einen ins Stocken geratenen Pull-Request vollständig abzulehnen, sondern lediglich unsere Warteschlange zu bereinigen. Eine Nachricht wie die folgende ist daher bei einem veralteten Pull-Request angebracht:

Hallo <Mitwirkender>,

Zunächst einmal möchten wir Ihnen für Ihre Zeit und Mühe bei der Arbeit an diesem Projekt danken. Das pytest-Team schätzt dies zutiefst.

Wir haben jedoch festgestellt, dass es eine Weile her ist, seit Sie diesen PR aktualisiert haben. pytest ist ein Projekt mit hoher Aktivität, bei dem täglich viele Issues/PRs eröffnet werden. Daher ist es für uns Maintainer schwierig zu verfolgen, welche PRs zum Mergen bereit sind, überprüft werden müssen oder weitere Aufmerksamkeit benötigen.

Aus diesen Gründen halten wir es für das Beste, den PR vorerst zu schließen, aber nur mit der Absicht, unsere Warteschlange zu leeren. Es ist keinesfalls eine Ablehnung Ihrer Änderungen. Wir ermutigen Sie dennoch, diesen PR wieder zu öffnen (es ist nur ein Klick entfernt), wenn Sie bereit sind, daran zurückzukehren.

Nochmals vielen Dank für Ihre Arbeit daran, und wir hoffen, dass Sie sich zu einem späteren Zeitpunkt wieder damit beschäftigen!

<Auf Wiedersehen>

Schließen von Issues¶

Wenn ein Pull-Request zur Behebung eines Problems eingereicht wird, fügen Sie Text wie closes #XYZW zur PR-Beschreibung und/oder den Commits hinzu (wobei XYZW die Issue-Nummer ist). Weitere Informationen finden Sie in der GitHub-Dokumentation.

Wenn ein Issue auf Anwendungsfehler (z. B. Missverständnis einer Funktionalität) zurückzuführen ist, erklären Sie dem Benutzer höflich, warum das aufgeworfene Problem tatsächlich kein Problem ist, und bitten Sie ihn, das Issue zu schließen, wenn er keine weiteren Fragen hat. Wenn der ursprüngliche Anfrager nicht antwortet, wird das Issue wie im Abschnitt Handling stale issues/PRs oben beschrieben behandelt.