Wrangle

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 15135 ist silver So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15135/badge)](https://www.bestpractices.dev/projects/15135)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/15135"><img src="https://www.bestpractices.dev/projects/15135/badge"></a>


Dies sind die Kriterien das Level Silber. Sie können auch die Kriterien für die Level Passing oder Gold sehen.

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen 17/17 ●

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

    Prepare scientific data with native Polars, reusable YAML protocols, a readable CLI and reproducible evidence. Researchers and agents use the same checked preparation engine.

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

  • Voraussetzungen


    Genug für ein Badge!

    Das Projekt MUSS ein bestimmtes Level erreichen. [achieve_passing]

  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Informationen darüber, wie man mitwirken kann, MÜSSEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf einen erforderlichen Codierungsstandard) enthalten. (URL erforderlich) [contribution_requirements]

    CONTRIBUTING states acceptable researcher-focused changes, scientific declarations, coding rules, meaningful tests, documentation and review requirements. pyproject.toml specifies the enforced Ruff rules and exceptions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


  • Projektüberwachung


    Gerade genug für ein Badge.

    Das Projekt SOLLTE einen rechtlichen Mechanismus haben, wo alle Entwickler von nicht-trivialen Beiträgen versichern, dass sie rechtlich ermächtigt sind, diese Beiträge zu machen. Der häufigste und leicht umsetzbare Ansatz, ist die Verwendung eines Developer Certificate of Origin (DCO) , wo Benutzer "signed-off-by" in ihren Commits und die Projektlinks zur DCO-Website hinzufügen. Allerdings DARF dies als Contributor License Agreement (CLA) oder als ein anderer rechtlicher Mechanismus implementiert werden. (URL erforderlich) [dco]
    Die DCO ist der empfohlene Mechanismus, weil er einfach zu implementieren ist, im Quellcode verfolgt wird und git direkt eine "signed-off" Funktion mit "commit -s" unterstützt. Um am effektivsten zu sein, ist es am besten, wenn die Projektdokumentation erklärt, was "signed-off" für dieses Projekt bedeutet. Eine CLA ist eine rechtliche Vereinbarung, die die Bedingungen definiert, unter denen intellektuelle Werke an eine Organisation oder ein Projekt lizenziert wurden. Ein Contributor Assignment Agreement (CAA) ist eine gesetzliche Vereinbarung, die die Rechte an einer intellektuellen Arbeit an eine andere Person überträgt; Projekte müssen keine CAAs haben, da CAA das Risiko erhöht, dass potenzielle Mitwirkende nicht dazu beitragen werden, vor allem, wenn der Empfänger eine gewinnorientierte Organisation ist. Die Apache Software Foundation CLAs (die individuelle Contributor-Lizenz und die Corporate CLA) sind Beispiele für CLAs, für Projekte, die bestimmt haben, dass die Risiken dieser CLAs für das Projekt geringen sind als ihre Vorteile.

    The project has no DCO or CLA mechanism for non-trivial contributions. Contributions use the existing MIT license through reviewed pull requests. A compulsory legal-origin attestation is not imposed by this modernization; its absence is a considered SHOULD limitation.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/LICENSE


    Genug für ein Badge!

    Das Projekt MUSS eindeutig sein Projekt-Governance-Modell (die Art, wie es Entscheidungen fällt, einschließlich der wichtigsten Rollen) definieren und dokumentieren. (URL erforderlich) [governance]
    Es muss einen gut dokumentierten, etablierten Weg geben, Entscheidungen zu treffen und Streitigkeiten zu lösen. In kleinen Projekten kann dies so einfach sein wie, "der Projektinhaber und -Leiter trifft alle endgültigen Entscheidungen". Es gibt verschiedene Führungs-Modelle, darunter wohlwollender Diktator und formale Meritokratie; Für weitere Details siehe Governance-Modelle . Sowohl zentralisierte (z.B. Single-Maintainer) als auch dezentrale (z.B. Gruppen-Maintainer) Ansätze wurden erfolgreich in Projekten verwendet. Die Governance-Informationen müssen nicht die Möglichkeit einer Projektspaltung dokumentieren, da dies für FLOSS-Projekte immer möglich ist.

    GOVERNANCE documents scope decisions, the lead maintainer, reviewer/contributor roles, release authority, disagreement handling and the process for governance changes.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


    Genug für ein Badge!

    Das Projekt MUSS einen Code of Conduct etablieren und an einem üblichen Ort veröffentlichen. (URL erforderlich) [code_of_conduct]
    Projekte können das Miteinander ihrer Gemeinschaft verbessern und Erwartungen in Bezug auf akzeptables Verhalten setzen, indem sie einen Verhaltenskodex verfassen. Dies kann helfen, Probleme zu vermeiden, bevor sie auftreten, und das Projekt zu einem einladenderen Ort zu machen. Dies sollte sich nur auf das Verhalten innerhalb der Gemeinschaft/ am Arbeitsplatz des Projekts konzentrieren. Beispielhafte Verhaltenskodizes sind der Linux Kernel Code of Conduct, der Contributor Covenant Code of Conduct, der Debian Code of Conduct, der Ubuntu Code of Conduct, der Fedora Code of Conduct, der GNOME Code Of Conduct, der KDE Community Code of Conduct, der Python Community Code of Conduct, die Ruby Community Conduct Guideline und der Rust Code of Conduct.

    CODE_OF_CONDUCT defines respectful behavior, prohibited conduct, private reporting, maintainer investigation/enforcement and an appeal route. It applies across project participation spaces.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CODE_OF_CONDUCT.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


    Genug für ein Badge!

    Das Projekt MUSS klar und deutlich die Rollen- auf Aufgabenverteilung dokumentieren, inklusive einzelnen Tätigkeiten, die von den Rollenträgern ausgeführt werden müssen. Es MUSS eindeutig sein wer welche Rolle hat, auch wenn es in anderer Form dokumentiert ist. (URL erforderlich) [roles_responsibilities]
    Die Dokumentation für Governance und Rollen und Verantwortlichkeiten können an einem Ort sein.

    GOVERNANCE lists responsibilities and assignments for lead, reviewing and backup maintainers, contributors and security reporters. The lead is mikkokotila and the owner-confirmed backup is EnergyGuy3.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, mit minimaler Unterbrechung fortzufahren, wenn eine beliebige Person nicht in der Lage ist oder stirbt. Insbesondere MUSS das Projekt in der Lage sein, Probleme zu lösen, vorgeschlagene Änderungen zu akzeptieren und Versionen der Software freizugeben, innerhalb einer Woche nach der Bestätigung, dass eine Person nicht mehr in der Lage ist oder gestorben ist. Dies DARF sichergestellt werden, indem man jemandem anderes notwendige Schlüssel, Passwörter und gesetzliche Rechte gibt, um das Projekt fortzusetzen. Einzelpersonen, die ein FLOSS-Projekt ausführen, DÜRFEN dies durch die Bereitstellung von Schlüsseln in einer Lockbox und einer Willenserklärung zur Bereitstellung von erforderlichen gesetzlichen Rechten (z. B. für DNS-Namen). (URL erforderlich) [access_continuity]

    The project owner confirms EnergyGuy3 can handle issues, merges and GitHub releases within one week if the lead is unavailable. Existing GitHub administrator access was verified. GOVERNANCE records this affirmation; an independent rehearsal is not claimed or required by this criterion.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security/releases.md


    Genug für ein Badge!

    Das Projekt SOLLTE einen Bus-Faktor von 2 oder mehr haben. (URL erforderlich) [bus_factor]
    Ein "bus factor" (aka "LKW-Faktor") ist die minimale Anzahl von Projektmitgliedern, die plötzlich aus einem Projekt ("hit by a bus") verschwinden müssen, bevor das Projekt aufgrund fehlender kompetenter Mitarbeiter stockt. Das Truck-Factor-Tool kann dies für Projekte auf GitHub schätzen. Weitere Informationen finden Sie unter Bewertung des Busfaktors von Git-Repositories von Cosentino et al.

    The project owner identifies mikkokotila as lead and EnergyGuy3 as a functioning backup with issue/merge/release continuity and secure-development expertise. GOVERNANCE records the two maintainer assignments and owner affirmation.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine dokumentierte Roadmap, für mindestens das nächste Jahr haben, die beschreibt, was das Projekt beabsichtigt zu tun und nicht zu tun. (URL erforderlich) [documentation_roadmap]
    Das Projekt könnte die Roadmap nicht umsetzen, das ist ok; Der Zweck der Roadmap ist es, potenziellen Nutzern/innen und Entwicklern/innen zu helfen, die beabsichtigte Richtung des Projekts zu verstehen. Sie muss nicht detailliert sein.

    ROADMAP gives dated October 2026 through September 2027 plans for researcher workflows, correctness and data preparation, with explicit excluded neural-network and generic infrastructure scope.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/ROADMAP.md


    Genug für ein Badge!

    Das Projekt MUSS in der Dokumentation die Architektur (alias High-Level-Design) der vom Projekt entwickelten Software bereitstellen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [documentation_architecture]
    Eine Softwarearchitektur erläutert die grundlegenden Strukturen eines Programms, d.h. die Hauptkomponenten des Programms, die Beziehungen zwischen ihnen und die Schlüsseleigenschaften dieser Komponenten und Beziehungen.

    The shipped architecture document describes inspect/draft/prepare, expression compilation, validation, eager/disk execution, publication, evidence and the Python/CLI boundary. The agent entry file links exact engine and manual paths.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/architecture.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/AGENTS.md


    Genug für ein Badge!

    Das Projekt MUSS dokumentieren, was der/die Benutzer/in in Bezug auf die Sicherheit der Projektsoftware (seine "Sicherheitsanforderungen") erwarten kann und nicht erwarten kann. (URL erforderlich) [documentation_security]
    Dies sind Sicherheitsanforderungen, die die Software erfüllen soll.

    The shipped security requirements define accepted inputs, allowlists, unresolved-decision gates, integrity/publication guarantees and environment/resource limits. SECURITY defines supported versions and vulnerability handling.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md


    Genug für ein Badge!

    Das Projekt MUSS eine "Quickstart"-Anleitung für neue Benutzer/innen haben, um ihnen zu helfen, schnell mit der Software umgehen zu können. (URL erforderlich) [documentation_quick_start]
    Die Idee ist, den Benutzern/innen zu zeigen, wie man anfängt und was die Software überhaupt macht. Dies ist entscheidend für potenzielle Benutzer/innen, um loszulegen.

    The README and shipped getting-started guide supply complete CLI and Python examples, expected results and the real-file guided path. Executable examples are verified in CI and against installed distributions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/getting_started.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/human_workflow.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/start_workflow.py


    Genug für ein Badge!

    Das Projekt MUSS sich bemühen, die Dokumentation mit der aktuellen Version der Projektergebnisse (einschließlich der vom Projekt produzierten Software) stehts zu aktualisieren. Jegliche bekannte Dokumentationsfehler, die es inkonsistent machen, MÜSSEN behoben werden. Wenn die Dokumentation in der Regel aktuell ist, aber fälschlicherweise einige ältere Informationen enthält, die nicht mehr wahr sind, behandeln Sie diese als Störung, dann verfolgen und beheben Sie diese wie üblich. [documentation_current]
    Die Dokumentation DARF Informationen über Unterschiede oder Änderungen zwischen Versionen der Software und/oder Links zu älteren Versionen der Dokumentation enthalten. Die Absicht dieses Kriteriums ist nicht, dass die Dokumentation perfekt sein muss, vielmehr soll Arbeit investiert, um die Dokumentation konsistent zu halten

    The generated operation catalog is checked against engine definitions. Public CI executes all eight examples and installed-package workflows; the issue/PR templates match the current native preparation interface.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/build_catalog.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/verify_distribution.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/ISSUE_TEMPLATE/bug-report.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


    Genug für ein Badge!

    Die Projekt-Repository-Titelseite und / oder Website MUSS alle Errungenschaften, die erreicht wurden, einschließlich dieses Best Practices Abzeichens, innerhalb von 48 Stunden nach der öffentlichen Anerkennung ausweisen und verlinken. (URL erforderlich) [documentation_achievements]
    Eine Errungenschaft ist jegliche Form von externen Kriterien, auf die das Projekt speziell hingearbeitet hat, um diese zu erreichen, einschließlich einiger Abzeichen. Diese Informationen müssen nicht auf der ersten Seite der Website des Projekts einzusehen sein. Ein Projekt, das GitHub verwendet, kann Errungenschaften auf der Repository-Vorderseite setzen, indem man sie der README-Datei hinzufügt.

    The public README links the live OpenSSF Scorecard badge, published within forty-eight hours of assessment. Passing was awarded on 2026-10-01; the Best Practices badge is being published in the same session within its forty-eight-hour window. Evidence: https://github.com/autonomio/wrangle/blob/ae4ea7273889c39f4169ecdf7278f3f56c3be154/README.md https://www.bestpractices.dev/en/projects/15135


  • Zugänglichkeit und Internationalisierung


    Genug für ein Badge!

    Das Projekt (beide Projektwebsite und Projektergebnisse) SOLLTE den bewährten Praktiken der Erreichbarkeit folgen, damit Personen mit Behinderungen noch an dem Projekt teilnehmen und die Projektergebnisse nutzen können, wo es vernünftig ist. [accessibility_best_practices]
    Für Webanwendungen siehe Web Content Accessibility Guidelines (WCAG 2.0) und dessen unterstützendes Dokument Understanding WCAG 2.0; Siehe auch W3C accessibility information. Für GUI-Anwendungen sollten Sie die umweltbezogenen Barrierefreiheitsrichtlinien verwenden (z.B. Gnome, KDE, XFCE, Android, iOS , Mac und Windows). Einige TUI-Anwendungen (z.B. `ncurses`-Programme) können bestimmte Dinge ausführen, um sich selbst zugänglicher zu machen (z.B. `alpine`'s `force-arrow-cursor`-Einstellung). Die meisten Kommandozeilen-Anwendungen sind ziemlich unzugänglich. Dieses Kriterium ist oft N/A, z.B. für Programmbibliotheken. Hier sind einige Beispiele, welche Maßnahmen zu ergreifen oder Fragen zu berücksichtigen sind:
    • Stellen Sie Text Alternativen für alle Nicht-Text-Inhalte zur Verfügung, so dass dieser in andere Formen umgewandelt werden kann, wie z.B. Großdruck, Blindenschrift, Sprache, Symbole oder einfachere Sprache ( WCAG 2.0-guideline 1.1)
    • Farbe ist nicht das einzige Mittel um Informationen zu übermitteln, die eine Aktion anzeigen, zu einer Eingabe auffordern oder visuelle Elemente unterscheiden. (WCAG 2.0 guideline 1.4.1)
    • Die visuelle Darstellung von Text und Textbildern hat einen Kontrast Verhältnis von mindestens 4,5:1, außer für großen Text, nebensächlichen Text, und Logos(WCAG 2.0 guideline 1.4.3)
    • Machen Sie alle Funktionalitäten von einer Tastatur aus erreichbar (WCAG guideline 2.1)
    • Ein GUI oder ein webbasiertes Projekt SOLLTE mit mindestens einen Screen-Reader auf der Zielplattform(en) testen (z.B. NVDA, Jaws oder WindowEyes auf Windows; VoiceOver auf Mac & iOS; Orca auf Linux/BSD; TalkBack auf Android). TUI-Programme DÜRFEN die Übermalung reduzieren, um eine redundante Lesung durch Screenreader zu verhindern.

    The CLI provides keyboard-operated plain-text prompts, named choices, stable readable errors and complete textual guides. Unicode scientific labels are supported and notebook tables have headers. This supports accessible common paths; no unperformed user trial or formal conformance audit is claimed.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_presentation.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_cli.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/getting_started.md


    Gerade genug für ein Badge.

    Die Projektsoftware SOLLTE internationalisiert werden, um eine einfachen Zugang für die Kultur, Region oder Sprache der Zielgruppe zu ermöglichen. Wenn die Internationalisierung (i18n) nicht andzuwenden ist (z. B. die Software keine für Endbenutzer beabsichtigte Texte erzeugt und keinen menschlich lesbaren Text sortiert), wählen Sie "nicht anwendbar" (N/A). [internationalization]
    Lokalisierung "bezieht sich auf die Anpassung eines Produkt-, Applikations- oder Dokumentinhalts, um die Sprache, kulturelle und andere Anforderungen eines bestimmten Zielmarktes zu erfüllen." Internationalisierung ist die "Gestaltung und Entwicklung eines Produkt-, Applikations- oder Dokumentinhaltes, die eine einfache Lokalisierung für Zielgruppen ermöglicht, die in Kultur, Region oder Sprache variieren." (Siehe W3Cs "Lokalisierung vs. Internationalisierung" .) Software erfüllt dieses Kriterium einfach dadurch, dass sie internationalisiert ist. Es ist keine Lokalisierung für eine andere Sprache erforderlich, denn sobald Software internationalisiert wurde, ist es möglich für andere, an der Lokalisierung zu arbeiten.

    The human CLI and manuals are English and lack a localization framework. The current research workflows prioritize a small consistent interface and language-independent stable error codes; Unicode labels and data are supported. This is a considered SHOULD limitation, not N/A.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_presentation.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_cli.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md


  • Andere


    Genug für ein Badge!

    Wenn die Projektseiten (Website, Repository und Download-URLs) Passwörter für die Authentifizierung von externen Benutzern speichern, müssen die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z. B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Wenn die Projektseiten hierfür keine Passwörter speichern, wählen Sie "nicht anwendbar" (N/A) aus. [sites_password_security]
    Beachten Sie, dass die Verwendung von GitHub dieses Kriterium erfüllt. Dieses Kriterium gilt nur für Passwörter, die für die Authentifizierung von externen Benutzern in die Projektseiten verwendet werden (inbound authentication). Wenn sich die Projektseiten auf anderen Seiten anmelden müssen (outbound authentication), müssen sie eventuell Authorization-Tokens für diesen Zweck anders speichern (da das Speichern eines Hashes nutzlos wäre). Dies gilt für das Kriterium crypto_password_storage zu den Projektseiten, ähnlich wie sites_https.

    The website/repository use GitHub, which the official Silver details explicitly state satisfies this password-storage criterion. Wrangle operates no additional password-authentication site.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md https://github.com/autonomio/wrangle https://www.bestpractices.dev/en/criteria/1?details=true&rationale=true#1.sites_password_security


 Verbesserungs-/Nacharbeits-Kontrolle 1/1 ●

 Berichterstattung 3/3 ●

 Qualität 19/19 ●

 Sicherheit 13/13 ●

 Analyse 2/2 ●


Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/15135/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Wie das geht, erfahren Sie in unserem Automatisierungsvorschlagssystem. Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Mikko Kotila und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Mikko Kotila.
Eintrag erstellt: 2026-10-01 15:20:31 UTC, zuletzt aktualisiert: 2026-10-01 19:59:56 UTC. Letztes erreichtes Badge: 2026-10-01 19:54:19 UTC.