Wählen Sie die Passage aus, die Sie belegen möchten
Angenommen, Sie prüfen eine Installationsanweisung in der öffentlichen README Ihres eigenen Projekts, bevor Sie sie in einem Artikel erwähnen. Finden Sie die genaue Passage und die dazugehörigen Bedingungen. Ein Repository-Titel oder eine Profilbiografie ersetzt nicht die Datei, die die Aussage enthält.
Beschränken Sie die Aufgabe auf das Dokument. Sie müssen das Projekt nicht ausführen, keine persönlichen Kontaktdaten einsehen und das Konto eines Mitwirkenden nicht als Beweis für eine private Identität behandeln.
Ersetzen Sie die sich ändernde Branch-Ansicht durch einen Versionslink
GitHub erklärt, dass eine normale Dateiansicht in der Regel den aktuellen Stand eines Branches zeigt, sodass sich der Inhalt mit neuen Commits ändern kann. Wenn Sie die Datei anzeigen, ändert das Drücken von y die URL in einen Permalink, der einen bestimmten Commit anstelle des Branch-Namens verwendet. Quelle
Kopieren Sie die URL, die nach dieser Aktion tatsächlich angezeigt wird. Öffnen Sie sie erneut und bestätigen Sie, dass sie dieselbe Datei und Passage zeigt. Erfinden Sie keine Commit-Kennung und erstellen Sie kein Zitat aus einer Suchvorschau, die Sie nicht geöffnet haben.
Notieren Sie separat, wenn Sie auch die aktuelle Branch-Adresse behalten möchten. Der Versionslink beantwortet die Frage „Welchen Wortlaut habe ich geprüft?“, während die Branch-Ansicht Ihnen zeigt, was das Projekt jetzt präsentiert.
Halten Sie genügend Kontext für andere Leser fest
| Feld | Aus Ihrer Prüfung erfassen | Zweck |
|---|---|---|
| Repository und Datei | Das tatsächliche Projekt und der Dateipfad | Das zitierte Dokument identifizieren |
| Commit-Kennung | Die Version im kopierten Permalink | Diesen Snapshot von späteren Änderungen unterscheiden |
| Belegte Passage | Ein kurzer Auszug oder eine getreue Zusammenfassung | Die Aussage auf den geprüften Wortlaut begrenzen |
| Umgebungsbedingungen | Version, Umgebung oder Funktionsgrenzen | Eine Einschränkung nicht weglassen |
| Zugriffsdatum | Wann Sie die Quelle geöffnet haben | Ihre Prüfzeit von der Veröffentlichungsgeschichte trennen |
Für eine beispielhafte README, die besagt, dass eine Exportfunktion experimentell ist, behält die belegte Aussage „experimentell“ bei. Eine stabile URL rechtfertigt nicht, sie in eine getestete Garantie umzuschreiben. Dieses Beispiel veranschaulicht die Zitierpraxis; es ist kein Bericht über ein reales Repository.
Entscheiden Sie, ob eine alte Aussage noch relevant ist
Wenn der aktuelle Branch abweicht, behalten Sie beide Beobachtungen: die frühere Version, die Sie zitiert haben, und den aktuellen Wortlaut, den Sie tatsächlich geöffnet haben. Ersetzen Sie nicht stillschweigend ein älteres Zitat, während Sie es weiterhin als dieselbe Prüfung beschreiben.
Eine Datei kann Pläne, Beispiele oder veraltete Anweisungen enthalten. Schreiben Sie diese Aussagen dem Projekt zu, anstatt zu behaupten, Sie hätten die Implementierung unabhängig getestet. Wenn der Zugriff später fehlschlägt, halten Sie diese Einschränkung fest; eine Versionskennung ist kein Versprechen dauerhaften Hostings oder einer Erlaubnis.
Dies ist auch getrennt von einem Badge für signierte Commits. Der Leitfaden zum GitHub Verified-Badge behandelt dieses andere Signal. Für eine breitere Synthese öffentlicher Dokumente verwenden Sie die Checkliste zur KI-Quellenprüfung und behalten Sie die genaue Version bei, auf die sich jede wesentliche Aussage stützt.