Autant je suis d'accord avec toi que le point 1 et 3 peuvent rendre agréable le développement, autant je ne suis absolument pas d'accord avec toi sur le point 2.
Ce n'est pas parce qu'on ne donne pas les clés à tout le monde au dépôt de source que le projet est moins communautaire. Très franchement, je préfère qu'une certaine confiance s'instaure entre les dirigeants d'un projet, et un contributeur, avant de lui donner les clés. Pourquoi ?
- parce que même si on peut annuler des modifs, c'est franchement une perte de temps que de corriger les merdes de contributeurs peu scrupuleux, codant comme des porcs, ou tout simplement débutant. Et dieu sait si le temps nous est particulièrement précieux.
- J'ai pas envie, sur mes projets que les types commit n'importe quoi, des fonctionnalités dans tout les sens, des trucs qui font dévier le projet de ses objectifs, ou encore des trucs inutiles, au risque de mettre en péril le produit même : au niveau stabilité, utilisabilité etc.. (c'est du vecu)
- Si on s'aperçoit qu'un type auquel on vient de donner l'accés, fait du mauvais boulot, c'est encore une perte de temps pour le virer (lui expliquer, tout ça...), et ce n'est jamais agréable pour les deux parties. En tout cas, c'est un risque fort de tuer l'ambiance du projet si le gars en question n'est pas content et qu'il fait des histoires parce qu'on lui a couper son accès. Éviter ce genre de problème, c'est des soucis en moins. Bref, je préfère qu'il y ait une sélection à l'entrée, plutôt que de devoir virer les gens.
- Corollaire : Ne pas donner accès en écriture à tout le monde est un gage d'une certaine qualité, en tout cas d'une qualité du niveau de ce qu'attendent les responsables du projet.
- Je ne vois pas franchement à quoi ça sert de livrer l'accés en écriture si il y a un outils de suivi (bugzilla ou autre) et qu'il est utilisé efficacement : n'importe qui peut faire un checkout, faire sa modif en locale, et proposer un patch dans un ticket. Où est le problème ?
De plus, tu penses qu'un processus de review c'est long et contre-communautaire : moi je dis que l'absence de review est synonyme de code pourri (en tout cas, pourrissement à moyen et long terme, donc de plus en plus dur à maintenir). Les reviews permettent d'une part aux nouveaux venus d'apprendre par leurs erreurs, et d'autre part de faire en sorte que le code commité soit d'un niveau de qualité minimal. Par exemple, dans Mozilla, les patchs, de qui que ce soit (qu'il soit débutant sur le projet ou un vieux de la vieille), sont revues par au moins deux personnes. Et pour un projet d'une telle complexité, c'est pas du superflu.
D'ailleurs, la revue de code est un des fondements des méthodes "agiles" de développement, et garantissent, avec les tests unitaires, d'une qualité **constante**, et en tout cas plus uniforme sur l'ensemble du projet.
Bref, je préfère donner les clés à des contributeurs qui ont montré par leurs contributions passées, qu'ils sont sérieux, qu'ils codent pas trop mal et qu'ils sont actifs.
Il est possible que les devs de KDE donnent accès en écriture à tous, mais je serais vraiment étonné si ils ne mettent pas des droits restreints sur certains répertoires...
Pour conclure, non, restreindre l'accès en écriture au dépôt de source n'est pas une condition pour que le développement soit agréable. Ça n'empêche nullement de coder, de proposer des patchs. Ce qui fait qu'il est agréable de contribuer à un projet, c'est le contact que l'on a avec les devs, c'est le fait qu'il ne soit pas fait n'importe quoi sur le projet, et donc qu'il y ait des objectifs clairs et définis, qu'il y ait un minimum de serieux (sans tombé dans une atmosphère dictatoriale), que les reviewers soient "pédagogiques" genre pas dire, "ton patch il est nul", mais expliquer pourquoi ici ou là ça ne va pas, qu'est ce qu'il est préférable de faire etc. Bref, avoir l'impression qu'on apprend quelque chose, qu'on avance tous ensemble dans la même direction.
Ah oui au fait, en utilisant des dépôts décentralisés, ton point 2 n'a pas lieu d'être... les dépôts centralisés sont has been, surtout pour les gros projets... (même si j'aime bien et j'utilise subversion :-) )
# Pas le point 2
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Logiciel libre ou communautaire : Ma définition.. Évalué à 3.
Ce n'est pas parce qu'on ne donne pas les clés à tout le monde au dépôt de source que le projet est moins communautaire. Très franchement, je préfère qu'une certaine confiance s'instaure entre les dirigeants d'un projet, et un contributeur, avant de lui donner les clés. Pourquoi ?
- parce que même si on peut annuler des modifs, c'est franchement une perte de temps que de corriger les merdes de contributeurs peu scrupuleux, codant comme des porcs, ou tout simplement débutant. Et dieu sait si le temps nous est particulièrement précieux.
- J'ai pas envie, sur mes projets que les types commit n'importe quoi, des fonctionnalités dans tout les sens, des trucs qui font dévier le projet de ses objectifs, ou encore des trucs inutiles, au risque de mettre en péril le produit même : au niveau stabilité, utilisabilité etc.. (c'est du vecu)
- Si on s'aperçoit qu'un type auquel on vient de donner l'accés, fait du mauvais boulot, c'est encore une perte de temps pour le virer (lui expliquer, tout ça...), et ce n'est jamais agréable pour les deux parties. En tout cas, c'est un risque fort de tuer l'ambiance du projet si le gars en question n'est pas content et qu'il fait des histoires parce qu'on lui a couper son accès. Éviter ce genre de problème, c'est des soucis en moins. Bref, je préfère qu'il y ait une sélection à l'entrée, plutôt que de devoir virer les gens.
- Corollaire : Ne pas donner accès en écriture à tout le monde est un gage d'une certaine qualité, en tout cas d'une qualité du niveau de ce qu'attendent les responsables du projet.
- Je ne vois pas franchement à quoi ça sert de livrer l'accés en écriture si il y a un outils de suivi (bugzilla ou autre) et qu'il est utilisé efficacement : n'importe qui peut faire un checkout, faire sa modif en locale, et proposer un patch dans un ticket. Où est le problème ?
De plus, tu penses qu'un processus de review c'est long et contre-communautaire : moi je dis que l'absence de review est synonyme de code pourri (en tout cas, pourrissement à moyen et long terme, donc de plus en plus dur à maintenir). Les reviews permettent d'une part aux nouveaux venus d'apprendre par leurs erreurs, et d'autre part de faire en sorte que le code commité soit d'un niveau de qualité minimal. Par exemple, dans Mozilla, les patchs, de qui que ce soit (qu'il soit débutant sur le projet ou un vieux de la vieille), sont revues par au moins deux personnes. Et pour un projet d'une telle complexité, c'est pas du superflu.
D'ailleurs, la revue de code est un des fondements des méthodes "agiles" de développement, et garantissent, avec les tests unitaires, d'une qualité **constante**, et en tout cas plus uniforme sur l'ensemble du projet.
Bref, je préfère donner les clés à des contributeurs qui ont montré par leurs contributions passées, qu'ils sont sérieux, qu'ils codent pas trop mal et qu'ils sont actifs.
Il est possible que les devs de KDE donnent accès en écriture à tous, mais je serais vraiment étonné si ils ne mettent pas des droits restreints sur certains répertoires...
Pour conclure, non, restreindre l'accès en écriture au dépôt de source n'est pas une condition pour que le développement soit agréable. Ça n'empêche nullement de coder, de proposer des patchs. Ce qui fait qu'il est agréable de contribuer à un projet, c'est le contact que l'on a avec les devs, c'est le fait qu'il ne soit pas fait n'importe quoi sur le projet, et donc qu'il y ait des objectifs clairs et définis, qu'il y ait un minimum de serieux (sans tombé dans une atmosphère dictatoriale), que les reviewers soient "pédagogiques" genre pas dire, "ton patch il est nul", mais expliquer pourquoi ici ou là ça ne va pas, qu'est ce qu'il est préférable de faire etc. Bref, avoir l'impression qu'on apprend quelque chose, qu'on avance tous ensemble dans la même direction.
Ah oui au fait, en utilisant des dépôts décentralisés, ton point 2 n'a pas lieu d'être... les dépôts centralisés sont has been, surtout pour les gros projets... (même si j'aime bien et j'utilise subversion :-) )