Contribution guide

[vianmora]

Je voudrais qu'un contributeur qui propose une PR

• Puisse voir ses CI se lancer directement (hors première contribution)
• Que les CI qui nécessitent l'utilisation du token github ne se lancent pas si ce n'est pas un maintener qui propose la PR

Je voudrais proposer un template de PR

• toujours lié à une issue
• validation de règles de bonnes pratiques de PR auto pour première contribution (sur le modèle du repo coolify)
• qu'un bot indique en commentaire l'image docker qui vient d'être build

[vianmora]

Diagnostic

CI / secrets sur PR externes

• webstudio-fork/.github/workflows/docker-publish.yml : trigger pull_request (opened/synchronize/reopened) avec packages: write et push vers GHCR → se lance sur toute PR, y compris externe, et échoue faute de token en écriture.
• webstudio-fork/main.yml a déjà un modèle de gating pour les jobs à secrets : job ssg-artifact protégé par pull_request_target + label safe-to-deploy posé manuellement par un mainteneur.
• webstudio-publisher/docker-publish.yml : même souci que fork (pull_request + packages:write, aucun gating).
• webstudio-self-host : aucun .github/ → pas de CI, pas de template PR, rien.
• Aucun des 3 repos n'a de PR template imposant un lien vers une issue, ni de vérif auto "bonnes pratiques 1ère contribution", ni de commentaire bot avec l'image Docker buildée (juste un job summary dans fork/publisher).
• "CI se lance direct sauf 1ère fois" est un réglage GitHub natif (Settings → Actions → General → "Fork pull request workflows"), pas du code — à vérifier/activer par repo.
• Modèle Coolify étudié : action peakoss/anti-slop (pull_request_target, exempt-author-association: OWNER,MEMBER,COLLABORATOR) qui valide template + issue liée + titre, seulement pour les contributeurs externes.

Plan proposé (même logique sur les 3 repos)

1. Gater les jobs à secrets sur les PR externes (fork + publisher docker-publish.yml) : ne pousser sur GHCR que si mainteneur/collaborateur (via author_association ou réutilisation du label safe-to-deploy) ; sinon build-only, sans push ni secret.
2. Vérifier/activer le réglage GitHub natif "Require approval for first-time contributors" sur les 3 repos.
3. PR template avec lien issue obligatoire, harmonisé sur les 3 repos (créer pour publisher et self-host, ajuster celui du fork).
4. Workflow pr-quality.yml (nouveau, modèle Coolify) sur les 3 repos, actif seulement pour non-mainteneurs, qui vérifie template respecté + issue liée.
5. Commentaire bot avec l'image Docker buildée sur la PR (fork + publisher, via sticky-pull-request-comment déjà utilisé dans lint-pull-request.yaml), déclenché seulement quand le build a réellement été poussé.