Zum Inhalt springen

Repository Management Tasks

Dies sind die Aufgaben, die von Teammitgliedern zur Verwaltung des SQLModel-Repositorys durchgeführt werden können.

Tipp

Dieser Abschnitt ist nur für eine Handvoll Leute nützlich, Teammitglieder mit Berechtigungen zur Verwaltung des Repositorys. Du kannst ihn wahrscheinlich überspringen. 😉

...also, bist du ein Teammitglied von SQLModel? Wow, du bist so cool! 😎

Du kannst bei allem, was unter Hilfe für SQLModel - Hilfe erhalten steht, auf die gleiche Weise helfen wie externe Mitwirkende. Aber zusätzlich gibt es einige Aufgaben, die nur du (als Teil des Teams) ausführen kannst.

Hier sind die allgemeinen Anweisungen für die Aufgaben, die du ausführen kannst.

Vielen Dank für deine Hilfe. 🙇

Sei nett

Zuerst einmal, sei nett. 😊

Du bist wahrscheinlich super nett, wenn du ins Team aufgenommen wurdest, aber es ist erwähnenswert. 🤓

Wenn Dinge schwierig werden

Wenn die Dinge großartig sind, ist alles einfacher, daher braucht das nicht viele Anweisungen. Aber wenn die Dinge schwierig werden, hier sind einige Richtlinien.

Versuche, die gute Seite zu finden. Generell gilt: Wenn Leute nicht unfreundlich sind, versuche, ihre Bemühungen und ihr Interesse zu würdigen, auch wenn du mit dem Hauptthema (Diskussion, PR) nicht einverstanden bist, bedanke dich einfach dafür, dass sie sich für das Projekt interessieren, oder dafür, dass sie sich die Zeit genommen haben, etwas zu versuchen.

Es ist schwierig, Emotionen in Text zu vermitteln, benutze Emojis, um zu helfen. 😅

In Diskussionen und PRs bringen die Leute in vielen Fällen ihre Frustration ungefiltert zum Ausdruck, in vielen Fällen übertreiben sie, beschweren sich, sind anspruchsvoll usw. Das ist wirklich nicht nett und wenn es passiert, senkt es unsere Priorität, ihre Probleme zu lösen. Aber versuche trotzdem, tief durchzuatmen und mit sanften Antworten zu reagieren.

Versuche, bitteren Sarkasmus oder potenziell passive-aggressiven Kommentare zu vermeiden. Wenn etwas falsch ist, ist es besser, direkt (versuche, sanft zu sein) als sarkastisch zu sein.

Versuche, so spezifisch und objektiv wie möglich zu sein, vermeide Verallgemeinerungen.

Für schwierigere Gespräche, z. B. zum Ablehnen eines PRs, kannst du mich (@tiangolo) bitten, diese direkt zu bearbeiten.

PR-Titel bearbeiten

  • Bearbeite den PR-Titel so, dass er mit einem Emoji von gitmoji beginnt.
    • Verwende das Emoji-Zeichen, nicht den GitHub-Code. Verwende also 🐛 anstelle von :bug:. Dies geschieht, damit es auch außerhalb von GitHub korrekt angezeigt wird, z. B. in den Release Notes.
  • Beginne den Titel mit einem Verb. Zum Beispiel Hinzufügen, Refaktorieren, Beheben usw. Auf diese Weise beschreibt der Titel die Aktion, die der PR ausführt. Zum Beispiel Unterstützung für Teleportation hinzufügen, anstatt Teleportation funktionierte nicht, daher behebt dieser PR dies.
  • Bearbeite den Text des PR-Titels, damit er im "Imperativ" beginnt, wie ein Befehl. Anstatt also Unterstützung für Teleportation hinzufügen verwende Füge Unterstützung für Teleportation hinzu.
  • Versuche, den Titel beschreibend darüber zu machen, was er erreicht. Wenn es sich um ein Feature handelt, versuche es zu beschreiben, zum Beispiel Unterstützung für Teleportation hinzufügen anstatt Teleport-Adapter-Klasse erstellen.
  • Beende den Titel nicht mit einem Punkt (.).

Sobald der PR zusammengeführt wurde, wird eine GitHub Action (latest-changes) den PR-Titel verwenden, um die letzten Änderungen automatisch zu aktualisieren.

Ein schöner PR-Titel sieht also nicht nur auf GitHub gut aus, sondern auch in den Release Notes. 📝

Labels zu PRs hinzufügen

Dieselbe GitHub-Aktion latest-changes verwendet ein Label im PR, um zu entscheiden, in welchem Abschnitt der Release Notes dieser PR platziert werden soll.

Stelle sicher, dass du ein unterstütztes Label aus der Liste der Labels von latest-changes verwendest.

  • breaking: Breaking Changes
    • Bestehender Code wird brechen, wenn sie die Version aktualisieren, ohne ihren Code zu ändern. Dies geschieht selten, daher wird dieses Label nicht häufig verwendet.
  • security: Security Fixes
    • Dies ist für Sicherheitskorrekturen, wie z. B. Schwachstellen. Es würde fast nie verwendet werden.
  • feature: Features
    • Neue Features, die Unterstützung für Dinge hinzufügen, die es vorher nicht gab.
  • bug: Fixes
    • Etwas, das unterstützt wurde, funktionierte nicht, und dies behebt es. Es gibt viele PRs, die als Fehlerbehebungen deklariert werden, weil der Benutzer etwas auf unerwartete Weise tut, das nicht unterstützt wird, sie aber als standardmäßig unterstützungswürdig erachten. Viele davon sind eigentlich Features oder Refactorings. In einigen Fällen gibt es jedoch einen tatsächlichen Fehler.
  • refactor: Refactors
    • Dies ist normalerweise für Änderungen am internen Code, die das Verhalten nicht ändern. Normalerweise verbessert es die Wartbarkeit oder ermöglicht zukünftige Features usw.
  • upgrade: Upgrades
    • Dies ist für Upgrades von direkten Abhängigkeiten des Projekts oder zusätzlichen optionalen Abhängigkeiten, normalerweise in pyproject.toml. Dinge also, die Endbenutzer betreffen, würden das Upgrade in ihrer Codebasis erhalten, sobald sie aktualisieren. Dies gilt jedoch nicht für Upgrades von internen Abhängigkeiten, die für Entwicklung, Tests, Dokumentation usw. verwendet werden. Diese internen Abhängigkeiten, normalerweise in requirements.txt-Dateien oder GitHub Actions-Versionen, sollten als internal und nicht als upgrade markiert werden.
  • docs: Docs
    • Änderungen in der Dokumentation. Dies beinhaltet die Aktualisierung der Dokumentation, die Korrektur von Tippfehlern. Änderungen an Übersetzungen sind jedoch nicht enthalten.
    • Du kannst dies normalerweise schnell erkennen, indem du zum Tab "Files changed" im PR gehst und prüfst, ob die geänderten Datei(en) mit docs/en/docs beginnt. Die Originalversion der Dokumentation ist immer auf Englisch, daher in docs/en/docs.
  • internal: Internal
    • Verwende dies für Änderungen, die nur die Verwaltung des Repos beeinflussen. Zum Beispiel Upgrades von internen Abhängigkeiten, Änderungen in GitHub Actions oder Skripten usw.

Tipp

Einige Tools wie Dependabot fügen einige Labels hinzu, z. B. dependencies, aber beachte, dass dieses Label nicht von der latest-changes GitHub Action verwendet wird, daher wird es nicht in den Release Notes verwendet. Bitte stelle sicher, dass eines der obigen Labels hinzugefügt wird.

PRs überprüfen

Wenn ein PR nicht erklärt, was er tut oder warum, frage nach mehr Informationen.

Ein PR sollte einen spezifischen Anwendungsfall haben, den er löst.

  • Wenn der PR für ein Feature ist, sollte er Dokumentation haben.
    • Es sei denn, es ist ein Feature, das wir nicht fördern wollen, wie z. B. die Unterstützung eines Eckfalls, den wir nicht nutzen lassen wollen.
  • Die Dokumentation sollte eine Beispielquelldatei enthalten, anstatt Python direkt in Markdown zu schreiben.
  • Wenn die Beispielquelldatei unterschiedliche Syntax für Python 3.8, 3.9, 3.10 haben kann, sollte es verschiedene Versionen der Datei geben und diese sollten in Tabs in der Dokumentation angezeigt werden.
  • Es sollte Tests geben, die das Beispiel testen.
  • Bevor der PR angewendet wird, sollten die neuen Tests fehlschlagen.
  • Nachdem der PR angewendet wurde, sollten die neuen Tests bestehen.
  • Die Abdeckung sollte bei 100 % bleiben.
  • Wenn du denkst, dass der PR sinnvoll ist, oder wir ihn besprochen und für akzeptabel befunden haben, kannst du Commits auf den PR aufsetzen, um ihn zu verfeinern, Dokumentation, Tests, Formatierung hinzuzufügen, zu refaktorisieren, zusätzliche Dateien zu entfernen usw.
  • Fühle dich frei, im PR zu kommentieren, um nach weiteren Informationen zu fragen, Änderungen vorzuschlagen usw.
  • Wenn du denkst, dass der PR bereit ist, verschiebe ihn in das interne GitHub-Projekt, damit ich ihn überprüfen kann.

Dependabot PRs

Dependabot erstellt PRs zur Aktualisierung von Abhängigkeiten für verschiedene Dinge, und diese PRs sehen alle ähnlich aus, aber einige sind weitaus heikler als andere.

  • Wenn der PR für eine direkte Abhängigkeit ist, d. h. Dependabot ändert pyproject.toml, **merge ihn nicht**. 😱 Lass mich das zuerst prüfen. Es besteht eine gute Chance, dass einige zusätzliche Anpassungen oder Aktualisierungen erforderlich sind.
  • Wenn der PR eine der internen Abhängigkeiten aktualisiert, z. B. wenn er requirements.txt-Dateien oder GitHub Actions-Versionen ändert, und die Tests erfolgreich sind, die Release Notes (in einer Zusammenfassung im PR angezeigt) keine offensichtlichen potenziellen Breaking Changes aufzeigen, kannst du ihn mergen. 😎

GitHub Discussions Antworten markieren

Wenn eine Frage in GitHub Discussions beantwortet wurde, markiere die Antwort, indem du auf "Mark as answer" klickst.

Viele der aktuellen Diskussionsfragen wurden aus alten Issues migriert. Viele haben das Label answered, was bedeutet, dass sie als Issues beantwortet wurden, aber jetzt in GitHub Discussions ist nicht bekannt, was die tatsächliche Antwort aus den Nachrichten ist.

Du kannst Diskussionen filtern nach Fragen, die offen und unbeantwortet sind.