Comment participer à l'évolution de Drupal ?

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,
Je voudrais simplement savoir la démarche à faire pour participer à l'évolution et au développement de drupal
Merci

En voilà une question qu'elle est bonne !!! :)

C'est vrai qu'un petit topo sur la manière dont fonctionne le projet Drupal, la manière dont les nouvelles fonctionnalités sont débattues et validées, la manière dont les idées sont triées, le processus permettant de faire monter, ou pas, telle ou telle fonctionnalité dans le core. Tout cela mériterais d'être explicité.

Moi-même j'avoue que je n'en sais rien. L'impression vague que j'en ai c'est qu'il y a des discussions sur Drupal.org et des décisions dans les DrupalCon. Mais peut-être me trompe-je. Damien ? je pense que tu es l'un des mieux placé pour répondre !

De ce que je comprends, tu veux savoir comment participer au code de drupal ?

Tu peux commencer par créer un compte sur drupal.org et proposer des projets ou co-maintenir des projets en demandant un "compte CVS" qui te permettra de commiter du code.

Je ne sais pas exactement comment on devient un developpeur "core" mais ça requiert une sacrée expérience à la fois en tant que dev tout court et aussi en tant que dev drupal ;-)

Je code sur drupal depuis deux ans et quand je vais voir les bugs critiques restants sur drupal 7, je me rends compte que je suis très loin de connaitre suffisament son code pour faire avancer les choses :-/

Donc bon, l'idéal ça reste de s'impliquer au max, de proposer de nouveaux modules ou de proposer des patchs pour des modules existants, participer aux discussions dans les issues, et de monter en compétence.

Concernant le commentaire de yoran, je n'en sais pas plus sur comment l'évolution de Drupal est décidée. Je suppose que ça part de discussion dans drupal.org et que pendant des sprint code ils appliquent certaines des idées qui ont émergées des discussions, en tachant de coller à la vision de Drupal que porte Dries, son concepteur .

Ces deux messieurs ont à peu près tout dit pour résumer le fonctionnement de Drupal (le projet que l'on appelle core) d'un point de vue développement.
Tout projet open source a besoin que les développeurs soient actifs pour que le produit évolue mais il n'y a pas que le développement, il faut également que le code soit documenté, qu'il y ait des exemples, des traductions, des études de cas, etc pour que le projet soit d'une très bonne qualité (c'est le cas de Drupal).
Tous ces points ont donc besoin d'avancer, si tu n'es pas développeur tu peux tout à fait aider en participant à l'un de ces chantiers.

Comment trouver les choses à faire ?
Deux méthodes, la première consiste à chercher directement sur le site Drupal.org ou bien demander à ce que l'on t'aiguille sur IRC (#drupal). Il faut savoir que dans Drupal la majorité des choses à faire se trouve dans le tracker de Drupal, les choses à faire sont appelées des "issues" (tickets), cela peut être un bug mais cela peut être également une discussion ou une traduction à faire par exemple.
Par exemple si tu veux savoir quelles sont les pages à documenter il te suffit de faire cette recherche
ou pour la recherche des bugs critiques il te suffit de faire cette recherche

Dans le contexte actuel tout le monde voudrait que Drupal 7 puisse voir le jour, comment aider ?
On parle donc principalement de résolution de bugs et dans cette catégorie, vous pouvez tous aider à différents niveaux.
Un bug critique (Définition : http://drupal.org/node/45111) passe par différents états : active, needs work, needs review, review & tested by the community, patch, fixed. (Descriptions complètes http://drupal.org/node/156119)
Active : Statut lorsqu'un bug est rapporté, tu viens de découvrir un problème et tu le rapportes sur le site pour que quelqu'un essaye de le résoudre. Si tu as rencontré des problèmes bloquants en utilisant Drupal tu peux aider en en créant.
Needs work : Statut lorsqu'il faut faire des modifications sur un patch déjà soumis qui ne fait pas exactement tout ce qu'il devrait faire. Si tu connais un peu Drupal et que tu sais programmer tu peux aider.
Needs review : Status lorsqu'un patch a été soumis et qu'il faut maintenant le tester (tous les patchs doivent être testés par au moins deux personnes différentes (créateur exclu)). Si tu comprends le PHP tu peux aider, pas besoin de connaitre Drupal en profondeur, il te suffit d'appliquer le patch, de vérifier qu'il fonctionne, de vérifier qu'il est compréhensible et respectueux des standards. (http://acquia.com/blog/kieran/How-we-trained-120-people-core-contributor...)
Review & tested by the community : Statut lorsque plusieurs personnes ont validé le fonctionnement du patch, Dries ou Webchick n'ont plus qu'à committer le patch dans le CVS du core.
Patch : Statut lorsqu'un patch a été porté dans une branche mais qu'il ne fonctionne pas pour toutes les branches, il reste un peu de travail à faire.
Fixed : Statut lorsqu'un patch a été commité dans le projet.

Voilà pour le projet core, à côté de tout cela il y a les projets des modules contribués, tu peux te porter volontaire pour aider chaque module existant à progresser, tu soumets des patches ou tu écris de la documentation, participe aux débats dans le but de faire avancer les choses, le responsable du projet te nommera peut être co-mainteneur. Si tu tombes sur des projets non mis à jour et que tu souhaites reprendre le flambeau c'est également possible.

Au final tout le monde peut participer à Drupal, si tu es développeur en évaluant / créant des patches, si tu es utilisateur en participant à la documentation / traduction, si tu es marketeux en écrivant des études de cas, si tu es chef de projet en aidant à concentrer les efforts sur les bons tickets (en fermant les tickets qui sont en doublons), si tu es graphiste il y a des initiatives sur l'expérience utilisateur où tu pourras également contribuer.
Si tu as juste des idées pour améliorer Drupal tu peux ouvrir un ticket en décrivant ce que tu aimerais améliorer et de préférence en suggérant une solution, les utilisateurs qui liront ton sujet trouveront pertinent ou non ton idée et si tu as de la chance peut être que ça deviendra une amélioration au projet Drupal ! Toute personne qui fait avancer les choses peut devenir "core developer", ça n'est pas juste une liste fermée de personnes. Le processus décisionnel est surtout régie par la masse, les gens qui ont déjà contribué aux fonctionnalités ont forcément une voix qui pèse plus mais principalement les décisions se font sur la base de discussions au sein même des tickets. Lors des DrupalCons certains débats qui n'ont pas été tranchés online sont débattus de vive voix et du coup les choses avancent. Je t'invite donc à regarder selon ton profil les tickets déjà ouverts et à ne pas hésiter à contribuer, il faut se décomplexer, tout le monde peut aider à son niveau !

Merci pour ce topo du "comment faire/finir/corriger ce qui a été décidé" (sans ironie, c'est bien documenté). Il reste cependant la question à laquelle je ne sais pas répondre, et c'est bien celle là que je posais au début. C'est comment influencer sur le processus décisionnel de ce qu'il y AURA ou pas dans une version à venir de Drupal.

Pour prendre un exemple que je connais bien, Java, le processus de décision est relativement clair et documenté (cf. http://jcp.org/en/home/index). Ainsi chacun sait où l'on va, et surtout comment orienter le produit dans un sens ou dans l'autre. Et ce n'est pas le seul projet libre qui ait un processus décisionnel documenté.

Pour Drupal j'ai souvent cherché sur le site, sans jamais trouver de réponse. Lorsque l'on cherche par exemple comment c'est niché FieldAPI dans le core de Drupal 7, dans quels conditions a été changé la couche base de données, etc, pas facile de trouver la source, mise à part les annonces de Dries.

Alors peut-être que la réponse est qu'il faut grenouiller auprès des bonnes personnes aux drupalcon (et là je suis mal barré ;-), peut-être est-ce sur IRC, ou sur une mailling liste que tout se passe. Bref, c'est celui-là le point qui me semble intéressant de comprendre.

Et une fois de plus, ma question est (je préfère cette fois prendre les devant :-) dénuée de toute animosité en partant du principe que je loupe juste quelque chose d'énorme.

Pour la fieldAPI et le choix "un champ = une table" je n'ai trouvé aucune discussion où cela a été réellement débattu (deux ou trois conversations il n'y a pas eu d'accord trouvé entre les différents points de vues, voire qui sont restées au status de désaccord total) : il me semble que cela a été décidé plus ou moins en petit comité et enterriné par un sprint.

Mais j'ai peut être raté des discussions.

Donc je me pose la même question en fait :-)