OpenGHz/Open-Source-Projekt-Polish

Open Source Projekt Polish

Ziel

Ein vorhandenes Projektverzeichnis in ein hochwertiges Open-Source-Repository verwandeln, indem die öffentlich sichtbare Dokumentation, Community-Dateien, Repository-Metadaten und die Git/GitHub-Einrichtung verbessert werden, während der ursprüngliche Quellcode unberührt bleibt.

Harte Grenzen

• Ändern Sie den ursprünglichen Produkt-/Quellcode, die generierte Logik, Tests, Notebooks, Assets oder das Laufzeitverhalten nicht, es sei denn, der Benutzer fordert dies ausdrücklich an.
• Erlaubte Änderungen sind auf projektbezogene Metadaten und Dokumentation beschränkt, wie README, LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, CHANGELOG, SUPPORT, CITATION, Issue/PR-Vorlagen, Versionshinweise, Badges, .gitignore, .gitattributes, .editorconfig sowie GitHub-Workflow-/Dokumentationsgerüste.
• Fügen Sie niemals benutzerspezifische lokale Maschinenpfade in README oder öffentliche Dokumente ein, wie /home/<benutzer>/..., /Users/<benutzer>/..., Laufwerksbuchstaben-Pfade, persönliche Arbeitsbereichsnamen, Download-Ordner oder maschinenspezifische absolute Projektpfade. Verwenden Sie stattdessen relative Pfade, $HOME, <repo> oder Platzhalter.
• Standardmäßig die MIT-Lizenz verwenden, wenn keine Lizenz vorhanden ist und keine Benutzerpräferenz diese überschreibt.
• Standardmäßig automatische öffentliche GitHub-Veröffentlichung für Ordner ohne Git-Remote. Den Ziel-Besitzer/Namen bestimmen, falls nicht offensichtlich, dann einen öffentlichen Remote erstellen und dokumentationsbezogene Änderungen pushen, nachdem die Geheimnisprüfungen bestanden wurden.
• Wenn ein Netzwerk-/GitHub-Befehl fehlschlägt, einmal mit dem konfigurierten lokalen Proxy wiederholen, bevor der Remote-Schritt als blockiert deklariert wird.
• Vorhandene Dokumentation und Community-Dateien nach Möglichkeit erhalten; sie inkrementell verbessern, anstatt nützliche Inhalte zu ersetzen.

Bei fehlenden Angaben zu klärende Eingaben

Fragen Sie nur nach Informationen, die sich wesentlich auf irreversible oder öffentlichkeitswirksame Aktionen auswirken:

1. Zielbereich: Projektpfad im Arbeitsbereich oder aktueller Ordner, falls bereits klar.
2. Öffentliche Identität: GitHub-Besitzer/Repo-Name vor dem Erstellen eines Remotes, falls dies nicht aus dem Ordner und dem authentifizierten GitHub-Konto abgeleitet werden kann.
3. Lizenzüberschreibung: Vorhandene Lizenz verwenden, falls vorhanden; andernfalls standardmäßig MIT anwenden, es sei denn, der Benutzer wünscht eine andere Lizenz.
4. Projektpositionierung: Ein-Satz-Wertversprechen, Zielbenutzer und Reifegrad, falls nicht aus Code/Dokumentation ableitbar.
5. Quellcode-Bearbeitungen: Als verboten annehmen; vor dem Berühren von etwas anderem als Metadaten/Dokumentation nachfragen.

Verfahren

1. Projektzustand prüfen

• Die Ordnerstruktur, vorhandene README/Dokumentation, Paketmanifeste, Build-Dateien, Beispiele, Lizenzdateien und den Git-Status überprüfen.
• Prüfen, ob .git existiert und ob ein Remote konfiguriert ist.
• Dateien mit Geheimnisrisiko vor dem Erstellen oder Pushen eines Remotes identifizieren: .env, Anmeldeinformationen, Token, große Binärdateien, Datensätze, private Notizen, lokale Protokolle und maschinenspezifische Pfade.
• Vorhandene Stärken, fehlende Open-Source-Grundlagen und etwaige Unklarheiten zusammenfassen, die Benutzereingaben erfordern.

2. Plan für Nicht-Code-Ergänzungen

Einen prägnanten Plan erstellen, der nur erlaubte Dokumentations- und Metadatenarbeit abdeckt:

• README-Verbesserungen unter Verwendung der Fertigkeit create-readme als Grundlage für Struktur, Ton und GitHub-Flavored Markdown.
• Standardmäßig zweisprachige README: Nach Fertigstellung der primären (englischen) README eine chinesische Version erstellen, gespeichert als README.zh-CN.md, und die beiden verlinken. Die Spiegelversion direkt verfassen; die Fertigkeit baoyu-translate für lange oder terminologiedichte Dokumente reservieren, bei denen die globale Begriffskonsistenz wichtig ist.
• Community-Gesundheitsdateien: Standardmäßig MIT-Lizenz, Mitwirkungsleitfaden, Verhaltenskodex, Sicherheitsrichtlinie, Unterstützungsleitfaden, Änderungsprotokoll, Zitation, Governance, Issue-Vorlagen, PR-Vorlage.
• Repository-Hygiene: .gitignore, .gitattributes, .editorconfig, Dokumentationsindex, Beispieleindex, Badges, Projektbeschreibung, Themen, Finanzierungs-/Sponsor-Metadaten, falls relevant.
• Git/GitHub-Einrichtung: Git initialisieren, falls nicht vorhanden, öffentlichen Remote erstellen, falls nicht vorhanden, Standardbranch festlegen und dokumentationsbezogene Änderungen nach Sicherheitsprüfungen pushen.

3. README verbessern

Die Fertigkeit create-readme für die Erstellung oder Aktualisierung der README verwenden. Sicherstellen, dass die README prägnant, ansprechend und nützlich ist:

• Klarer Projektname, Slogan und kurzes Wertversprechen.
• Badges nur, wenn sie wahrheitsgemäß und wartbar sind.
• Schnellstart nach Möglichkeit mit verifizierten Befehlen.
• Befehle müssen aus dem Repository-Stammverzeichnis kopierbar sein und dürfen keine absoluten lokalen Pfade des aktuellen Benutzers enthalten; ./script.sh, $HOME/..., /path/to/... oder <repo>/...-Beispiele bevorzugen.
• Installation, Verwendung, Konfiguration, Beispiele, Projektstruktur, Fehlerbehebung und Links zu dedizierten Dateien.
• Den vollständigen Inhalt von LICENSE, CONTRIBUTING, CHANGELOG oder SECURITY nicht in der README duplizieren; auf diese Dateien verlinken.
• Vorhandenes projektspezifisches Wissen und Beispiele erhalten.

Nach Fertigstellung der englischen README.md standardmäßig eine chinesische Übersetzung erstellen:

• Die englische README.md muss standardmäßig eine Sprachumschaltzeile nahe dem oberen Rand enthalten, z.B. English | [简体中文](README.zh-CN.md). Diese auch hinzufügen, wenn die chinesische Datei noch im selben Durchlauf generiert wird – der Link zeigt auf den Pfad, der existieren wird, wenn der Workflow abgeschlossen ist.
• Die chinesische README.zh-CN.md aus README.md erstellen. Das direkte Verfassen der Spiegelversion ist für eine typische README (meist kurze Prosa plus Code/Befehle, die wörtlich bleiben müssen) zu bevorzugen; die Fertigkeit baoyu-translate nur aufrufen, wenn die README lang oder terminologiedicht ist und von deren Analyse-/Übersetzungs-/Überprüfungsablauf und einem gemeinsamen Glossar profitiert.
• Die chinesische README.zh-CN.md trägt die Spiegelumschaltzeile oben, z.B. [English](README.md) | 简体中文.
• Alle Codeblöcke, Befehle, Pfade, Links, Badges und Platzhalter unverändert lassen; nur die Prosa übersetzen.
• Die chinesische Version nur überspringen, wenn der Benutzer dies ausdrücklich ablehnt. Wenn das Projekt bereits hauptsächlich auf Chinesisch verfasst ist, README.md als chinesische Version behandeln, in README.en.md übersetzen und die entsprechende Umschaltzeile oben in jeder Datei platzieren.

4. Community-Dateien hinzufügen

Dateien nur dann hinzufügen oder aktualisieren, wenn sie dem Projekt helfen, vollständig und vertrauenswürdig zu wirken:

• LICENSE: Vorhandene Lizenz verwenden, falls vorhanden; andernfalls standardmäßig MIT mit dem erkannten aktuellen Jahr und Besitzer/Projektnamen an geeigneter Stelle hinzufügen.
• CONTRIBUTING.md: Entwicklungseinrichtung, Branch-/Commit-Konventionen, falls ableitbar, Testerwartungen, Issue-/PR-Prozess.
• CODE_OF_CONDUCT.md: Einen standardmäßigen, prägnanten Contributor-Covenant-Stil verwenden, es sei denn, der Benutzer hat eine andere Richtlinie.
• SECURITY.md: Unterstützte Versionen, Platzhalter für verantwortungsvollen Offenlegungskanal, Erwartungen an die Meldung von Schwachstellen.
• CHANGELOG.md: Mit Unreleased und aktueller öffentlicher Basislinie initialisieren; keine Versionsgeschichte erfinden.
• SUPPORT.md: Wo man Fragen stellen, Fehler melden und Funktionen anfordern kann.
• .github/ISSUE_TEMPLATE/* und .github/PULL_REQUEST_TEMPLATE.md: Praktische Formulare/Checklisten, die auf das Projekt zugeschnitten sind.
• CITATION.cff nur für Forschungs-/akademische/wissenschaftliche Projekte oder wenn Autorenmetadaten verfügbar sind.

5. Repository-Hygiene

• .gitignore basierend auf erkannten Sprachen/Werkzeugen erstellen oder verfeinern, ohne Dateien auszuschließen, die wahrscheinlich Quellartefakte sind.
• .gitattributes für Textnormalisierung und gängige Binärmuster hinzufügen, wenn nützlich.
• .editorconfig mit konservativen Leerraumvoreinstellungen hinzufügen, die dem Repo-Stil entsprechen.
• Keine CI-Workflows hinzufügen, es sei denn, Build-/Test-Befehle sind bekannt oder verifiziert; falls hinzugefügt, diese minimal und nicht invasiv halten.

6. Git- und Remote-Handhabung

Für Ordner ohne Git:

1. Ein Repository für den Zielordner initialisieren, nachdem der Ordnerpfad verifiziert wurde.
2. Nur vom diesem Workflow erstellte oder geänderte Metadaten-/Dokumentationsdateien bereitstellen.
3. Mit einer dokumentationsbezogenen Nachricht committen, wenn die Veröffentlichung fortgesetzt wird.

Für Git-Repositorys ohne Remote:

1. Den GitHub-Besitzer aus gh-Authentifizierung und den Repo-Namen nach Möglichkeit aus dem Ordner ableiten; nur bei Unklarheit nachfragen.
2. gh-Authentifizierung vor dem Erstellen eines Remotes prüfen.
3. Standardmäßig ein öffentliches GitHub-Repository erstellen.
4. origin hinzufügen, den Standardbranch festlegen und nach Überprüfung der bereitgestellten Änderungen und Bestätigung, dass keine Geheimnisse enthalten sind, pushen.

Empfohlener GitHub-CLI-Ablauf, an das Projekt angepasst:

git status --short
git remote -v
gh auth status
gh repo create BESITZER/REPO --public --source=. --remote=origin --push

Wenn Netzwerkbefehle fehlschlagen, einmal mit Folgendem wiederholen:

export {HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,http_proxy,https_proxy,all_proxy}=http://127.0.0.1:7890

7. Qualitätsprüfungen

Vor dem Abschluss:

• Geänderte Markdown-Auszüge erneut öffnen, um Überschriften, Links, Codeblöcke und kopierbare Befehlseinrückung zu überprüfen.
• README und öffentliche Dokumente vor dem Abschluss auf lokale Maschinenpfade durchsuchen, einschließlich /home/, /Users/, Laufwerksbuchstaben-Pfade, persönliche Arbeitsbereichsnamen und absolute Pfade, die aus der aktuellen Umgebung kopiert wurden.
• Bestätigen, dass keine Quellcodedateien geändert wurden, es sei denn, dies wurde ausdrücklich genehmigt.
• Bestätigen, dass alle Links zu lokalen Dateien auf tatsächlich existierende Dateien verweisen.
• Wenn eine chinesische README erstellt wurde, bestätigen, dass README.zh-CN.md existiert, die Sprachumschaltlinks in beiden Dateien funktionieren und Code/Befehle/Pfade mit der englischen Version identisch sind.
• Leichte Formatierung oder Markdown-Linting durchführen, falls verfügbar; keine schweren Abhängigkeiten nur für diesen Workflow installieren, es sei denn, der Benutzer stimmt zu.
• git diff --stat anzeigen und geänderte Dateien zusammenfassen.
• Wenn ein Remote erstellt wurde, die URL, Sichtbarkeit, den Standardbranch melden und ob etwas gepusht wurde.

Entscheidungspunkte

• Vorhandene README ist gut: Struktur erhalten und fehlende Abschnitte ergänzen, anstatt neu zu schreiben.
• Keine verifizierten Installations-/Testbefehle: Klar gekennzeichnete Platzhalter oder „Noch nicht dokumentiert“-Hinweise einfügen, anstatt Befehle zu erfinden.
• Lizenz unbekannt: Standardmäßig MIT hinzufügen, es sei denn, der Benutzer wünscht eine andere Lizenz.
• Mögliche Geheimnisse oder private Daten: Remote-Erstellung/Push stoppen und die riskanten Pfade melden.
• Kein gh-CLI oder nicht authentifiziert: Dem Benutzer genaue Befehle zum Ausführen bereitstellen, aber dennoch die lokale Dokumentationsverbesserung abschließen und einen dokumentationsbezogenen Commit vorbereiten, falls sicher.
• Monorepo: Stamm-Communitydateien und paketspezifische README-Dateien nur erstellen/aktualisieren, wenn die Paketgrenzen klar sind.

Abschlusszusammenfassung

Ende mit:

• Hinzugefügte/aktualisierte Dateien.
• Was absichtlich nicht berührt wurde, insbesondere Quellcode.
• Durchgeführte Validierung.
• Remote-Repository-Status, falls zutreffend.
• Vorgeschlagene nächste Schritte wie Aktivieren von CI, Hinzufügen von Beispielen, Erstellen einer ersten Version oder Erstellen von Projekt-Themen.