Précisions sur les règles de contribution

Équipes documentation
1

Je déplace la discussion commencée ici : https://git.spip.net/spip-contrib-extensions/motpassecomplexe/-/merge_requests/4#note_210940

Cela concerne Contribuer au développement de SPIP - SPIP

Effectivement, le titre du chapitre était initialement, avant la modif récente de @JLuc, « Règle de contribution tout court », ce qui pouvait prêter à confusion.

Je verrais bien un chapitre en dessous, « Règles de contribution …(zone/contrib) » qui reprendrait certaines règles adaptées, plus simples.

Comment nommer ces deux chapitres pour que ce soit clair ?

proposition :

  • Règles de contribution SPIP et plugins dist
  • Règles de contribution plugins et squelettes communautaires

proposition :

  • Règles de contribution dans les groupes Gitlab spip et spip-league
  • Règles de contribution dans les groupes Gitlab spip-contrib-*

ou bien :

  • Règles de contribution
    – Dans les groupes Gitlab spip et spip-league
    – Dans les groupes Gitlab spip-contrib-*
2

La dernière option me semble très bien.

3

Il y a peut être aussi des point à revoir sur cette page.

Créer un ticket sur https://git.spip.net/spip/spip/issues avant d’envoyer une proposition

Vu qu’on a séparé ecrire et prive, c’est toujours spip/spip qu’on recommande d’ouvrir un ticket ? et l’équipe déplace ensuite elle même le ticket sur le bon projet ?
Mais du coup, le numéro du ticket peut changer, et si la personne a déjà créé une branche issue_xxx, ça peut ne plus correspondre.
Ou bien demander à faire un ticket sur ecrire ou prive ? ça peut être compliqué à déterminer pour quelqu’un qui ne connaît pas les arcanes.

Je trouve cet enchaînement de titre pas très clair :

Règles de présentation et d’écriture

Consulter les règles de codage.

Règles de programmation

Je remplacerais bien par :

Convention de codage

Consulter les conventions de codage PHP.

même si ça crée une répétition (c’est pas un blog littéraire, c’est de la doc).

A terme (mais c’est un autre sujet/chantier), ce serait bien d’avoir aussi une page pour les conventions de codage CSS et JS, voir HTML même.
On peut s’inspirer de conventions existantes.

Le chapitre sur les règles de programmation est il bien utile ?
Ça me parait verbeux, ça parle de variables globales (!), c’est pas directement lié à SPIP, et je ne sais pas ce que ça peut apporter à quelqu’un qui ne sait pas développer du tout.

Sur les pages « Standard SPIP40 » et « Standard SPIP41 », il y a des liens vers https://packagist.org/packages/spip/coding-standards, page qui indique :

This package is abandoned and no longer maintained. The author suggests using the spip-league/easy-coding-standard package instead.

Liens à mettre à jour ?

Ceci dit, je ne comprends pas trop à quoi ça correspond Standard SPIP41, je ne vois pas de fichier ou de règles de ce nom. SCS1 non plus.

Quelqu’un pour m’expliquer ?

4

J’ai posé une section pour la partie contrib, copier/coller adapté de la partie core.

Je vous laisse relire / amender.

5

On optera donc pour la config git globale suivante :

git config --global pull.ff only

Je trouve ça pas top, ça incite à modifier la config globale des gens, sans trop expliquer non plus les implications.

On retirerait pas le --global, en précisant que c’est à faire dans le répertoire git sur le(s)quel(s) on travaille ?

Ou bien préviser git rebase master --ff-only ?

Bon, on va pas faire un tuto git non plus, mais ça demanderait peut être une réécriture en deux paragraphes :

  1. les commandes précises à lancer, avec les arguments (–ff-only)
  2. comment se passer des arguments en modifiant la config git du répertoire, ou globale
6

Merci pour toutes ces modifs. J’ai effectué deux micro modifs :

  • forcé le numéro de note sur la deuxième pour éviter deux notes identiques en bas de page
  • supprimé une typo

Une question : pour la note sur la PR est-ce qu’il ne vaudrait pas mieux parler de MR puisque c’est Merge Request employé sur Gitlab ?

Je suis preneur de ce genre de précisions :slight_smile:

7

Oui, ça va comme ça, les gens qui savent quelle partie du code est concernée iront vers le bon repo, pour les autres c’est à la charge de l’équipe de maintenance de ventiler au bon endroit.

Je ne pense pas, j’ai souvenir qu’on avait déjà bien élagué cette partie…

Oui, voir Paquet spip-league/easy-coding-standard à ce sujet.

8

Ok, j’élague.

Il me semblait bien, donc ces trois pages :

ne sont plus d’actualité en fait, à remplacer par un résumé du post de @marcimat ?

9

Je viens de mettre à jour la traduction en [en] SPIP, relecture bienvenue les changements sont importants par rapport à la précédente version de la traduction de juin 2023. Ce serait bien s’il y avait un système de notifications vers les traducteurs lorsqu’un article de référence des traductions est mis à jour. Ensuite le traducteur mettrait ou pas à jour mais au moins il serait prévenu.
Par ailleurs j’ai mis en rédaction les versions [ca, es, it, co] dont les dernières modifications dataient de 2007 ou 2009…

10

Oui, ça mérite un ticket ici spip-contrib-extensions / notifications · GitLab :slight_smile:

:+1:

11

Voilà :