Replies: 3 comments
-
Assigned zu werden ist ja schön und gut, aber warum und wofür, was ist der Auftrag? Sollen die drei benannten nun alle Repos durchflöhen und umbauen? Abgesehen davon ein paar Kommentare zu Deiner Liste (deren Sinn und Zweck ich keineswegs in Abrede stelle; sowas muss man einfach mal festlegen.) Namespace sollte mindestens für neue Repos Pflicht sein. M.E. sollte spätestens bei nächsten Major Release ein Addon umgestellt werden. Default-Branch: main => ist das nicht eh der GitHub-Standard? Bei bestehenden umzustellen bringt Verdruss (zumindest meine Erfahrung als Git-Laie) (optional) Social Preview: AI-generiertes Bild mit dem Prompt A friendly blue T-Rex, low-poly, ... => wer sich nen AI-Abbo gönnt kann das vermutlich machen. Ich rate mal: dafür braucht es ein weitgehend vordefiniertes AI-Prompt. Wiki abwählen => warum? Opt. Repository-Ruleset importieren => was auch immer das ein mag ... mir sagt das jedenfalls nichts README.md hinzugefügt, Vorlage noch zu erstellen, z.B. an Blaupause orientieren => finde ich zu eingrenzend. Readme als Pflicht, ja aber nach vorgegebenem Schema .... was ja auch erstmal jemand schreiben muss. Blaupause passt nicht zwangsläufig für alles. package.yml an FOR anpassen => bedeutet was? Und die wichtigste Frage: Wie will man die Einhaltung der Regeln sicherstellen. Wenn man das nicht kann ist alles optional. |
Beta Was this translation helpful? Give feedback.
-
@christophboecker genau dafür habe ich dich verlinkt, um deinen Senf dazugeben zu können. :) main-Branch: Bei bestehenden ändern hat bei mir in den letzten 2 Jahren nie zu Problemen geführt. Ich meine aber, am Anfang war das evtl. anders. Ruleset: Erstellt habe ich z.B. für FOR-Addons, in denen ich stärker die Kontrolle behalten möchte, dieses Ruleset for-enforce-pr-in-main.json. Dadurch erwartet GitHub dann bei Änderungen einen PR und macht den Button rot mit einer Warnung, wenn man als Repo-Admin-Entwickler doch direkt committen möchte. Für mich vor allem auch zur eigenen Disziplinierung. README.md: Es sollten zumindest die Grundfunktionen beschrieben sein, Lizenz, Lead, beteiligte Autoren und Co. angegeben werden. Wiki: Nicht noch eine Stelle, an der Informationen liegen. Dann lieber dem Add-on beiliegend README (+ Docs). package.yml: Autor
Na zumindest durch Konvention und Selbstverpflichtung wird es leichter, Korrekturen vorzunehmen. Wenn keiner weiß, wie es sein sollte, macht jeder, wie er will. |
Beta Was this translation helpful? Give feedback.
-
Ich habe noch den Aspekt von |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Vorschlag für zusätzliche gemeinsame Standards
1. Repository-Details
redaxo
,redaxo-addon
,redaxo5
,redaxo-yform
Packages
undDeployments
abwählenBeispiel:

2. Repository-Einstellungen
Unter <https://github.com/FriendsOfREDAXO//settings`
main
A friendly blue T-Rex, low-poly, ...
Automatically delete head branches Loading
auswählen3. Basics
README.md
hinzugefügt, Vorlage noch zu erstellen, z.B. an Blaupause orientierenpackage.yml
an FOR anpassen4. Actions
5. Code
namespace FriendsOfREDAXO\<package>
als Namespacedefault_config
die möglichen Konfigurationswerte der Einstellungsseiten eintragen.6. Security
https://github.com/FriendsOfREDAXO/[package]/security
Beispiel von
redaxo\redaxo
Beta Was this translation helpful? Give feedback.
All reactions