DiscourseSkill.md

Entwickler
6

Einverstanden. Wie bereits erwähnt, handelte es sich dabei um einen ersten Entwurf, der aufgrund eures Feedbacks verbessert wurde. Wir haben uns das noch einmal angesehen, und ihr hattet recht.

Hinzugefügt zur Prüfungs-Methode

  • Kandidaten-Klassifizierung vor der Dateiprüfung:

    • Plugin
    • Theme
    • Theme-Komponente
    • Hybrid-Erweiterung
    • Integrations-Repository
    • Release-Artefakt

  • Getrennte Inventarisierung des gemeinsamen Repositories/Releases:

    • README, Lizenz, Änderungsprotokoll
    • Paketdateien und Lockfiles
    • CI-Workflows
    • Installations-/Docker-Skripte
    • Integrationen externer Dienste
    • Erzeugte Release-Assets
    • Getaggtes/archiviertes Release
    • Relevante nicht verfolgte und ignorierte Dateien

  • Erweiterte Plugin-Inventarisierung:

    • Jede Datei, die von plugin.rb geladen, registriert oder offengelegt wird
    • config/routes.rb
    • db/post_migrate/
    • Views, Engines, Validatoren und Middleware
    • Admin- und Public-Frontend-Code
    • Connectors, Komponenten, Routen, Dienste, Vorlagen und Frontend-Tests
    • Gemeinsame, Desktop-, Mobile-, Admin- und eingebettete Stile
    • Fixtures, Support-Dateien und Browser-/Systemtests
    • Ruby-, JavaScript-, System- und externe Dienstabhängigkeiten
    • .discourse-compatibility
    • d-compat/*-Branches und Workflows
    • Deklarierte Discourse-Versionsgrenzen

  • Neue Theme/Theme-Komponenten-Inventarisierung:

    • about.json im Stammverzeichnis
    • component-Klassifizierung
    • Lizenz-, Autoren-, Versions- und Kompatibilitätsmetadaten
    • Deklarierte Assets, Farbschemata, Screenshots und thematisierbare Einstellungen
    • settings.yml im Stammverzeichnis
    • locales/ im Stammverzeichnis
    • common/, desktop/ und mobile/
    • SCSS- und unterstützte HTML-Injectionsdateien
    • javascripts/ im Stammverzeichnis
    • api-initializers/
    • Alle .js, .gjs und .hbs-Dateien
    • stylesheets/ im Stammverzeichnis und importierte Stylesheets
    • assets/ im Stammverzeichnis und alle Verweise darauf
    • Vorschau/Screenshots
    • Tests und Lint-/Build-Konfiguration
    • Kompatibilitätsmetadaten und Branches
    • Verpackte/exportierte Theme-Bytes

  • Neue Strukturprüfungen:

    • Der deklarierte Erweiterungstyp muss zu about.json und dem Installationsverhalten passen.
    • component: true bedeutet Theme-Komponente.
    • component: false oder weggelassen bedeutet vollständiges Theme.
    • Hybrid-Repositories erhalten alle anwendbaren Inventarisierungen.
    • Falsch platzierte oder unerwartete Dateien werden untersucht und nicht stillschweigend ignoriert.
    • Fehlende optionale Verzeichnisse sind nicht automatisch Mängel.
    • Arbeitsbaum, Release-Archiv, installierte Erweiterung, erzeugte Assets und öffentlicher Kandidat sind separate Beweisebenen.

  • Neue Checkliste für vollständige Themes:

    • Metadaten-Identität
    • Rendering des vollständigen Themes
    • Abdeckung der Kernseiten
    • Einstellungen, Lokalisierungen und Assets
    • Unterstützte JavaScript-/API-Initialisierer
    • Responsives Verhalten, Barrierefreiheit und RTL
    • Verhalten von Foundation, Horizon und Embeds
    • Interaktionen mit Theme-Komponenten
    • Installations-, Update-, Rollback- und Kompatibilitätsprüfungen

Meine Hoffnung ist, dass die Gemeinschaftsmitwirkung die Skill verbessert und die Skill anderen hilft, ihre eigene Arbeit oder, ganz offen, die Arbeit anderer vor der Installation zu bewerten, falls Zweifel an der Qualität bestehen.

Bisher stehen wir bei 2 zu 2. Euer Input hat zu Verbesserungen der Skill geführt und @satonotdead fand sie hilfreich. Danke für die freundlichen Worte und die Unterstützung, @satonotdead