Je comprends bien que ça vous intéresse de discuter sur la solution à prendre.
Je ne veux absolument pas imposer ma solution, je suis tout à fait ouvert à la critique (comme dans le commentaire ci-dessous qui dit que ça ne tient pas sur mobile), mais je ne voulais pas attendre 15 jours avant de commencer à coder.
J'exagère un peu, mais ma motivation et mon temps était disponible au moment où je me suis intéressé au projet.
Je ne suis pas un jeune étudiant comme le laisse penser ZeroHeure ci-dessous: je suis père de famille, j'ai un travaille à assurer à 42h par semaines (eh non, je ne suis pas français ;)) et j'ai vraiment rarement du temps.
Avec un conseil comme "Contactez-moi d'abord", ça me laisse passer le message: "tu dois attendre que je te donne un feu vert et si moi je n'ai pas de temps maintenant pour en parler, ben, tu attendras mon retour de rush du boulot ou de vacances".
Dans la notion de collaborer, il faut que les 2 parties fassent un pas vers l'autre. C'est justement toute la force des forges comme Gitlab: elles permettent de discuter facilement des nouvelles fonctionnalités, d'en proposer 15 versions dans 15 branches différentes si nécessaire et de choisir à la fin la plus pertinente.
Avec cette vision, je comprends tout à fait pourquoi des contributeurs ont donné un patch / une nouvelle fonctionnalité puis sont partis: cette attitude ne me semble pas accueillante et même rebute à continuer à aider, car il y a un énorme goulot d'étranglement: une seule personne est capable de fusionner le code et ce sera toujours selon son temps disponible.
La solution pour détruire ce goulot d'étranglement est de faire du développement en communauté pour répartir les tâches: avoir plusieurs personnes pour trier les bugs, pour faire la revue de code et pour donner des idées quant à la direction à prendre. C'est un peu comme la parallélisation de nos CPUs: c'est un peu dur à gérer comme il faut au début (il faut avoir des gens de confiance), mais quand c'est bien géré, le projet avance beaucoup plus vite, puisque plusieurs cerveaux peuvent travailler en même temps !
[^] # Re: Oui : contactez-moi d'abord
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Forker ou ne pas forker ?. Évalué à 2. Dernière modification le 15 septembre 2018 à 14:12.
Je comprends bien que ça vous intéresse de discuter sur la solution à prendre.
Je ne veux absolument pas imposer ma solution, je suis tout à fait ouvert à la critique (comme dans le commentaire ci-dessous qui dit que ça ne tient pas sur mobile), mais je ne voulais pas attendre 15 jours avant de commencer à coder.
J'exagère un peu, mais ma motivation et mon temps était disponible au moment où je me suis intéressé au projet.
Je ne suis pas un jeune étudiant comme le laisse penser ZeroHeure ci-dessous: je suis père de famille, j'ai un travaille à assurer à 42h par semaines (eh non, je ne suis pas français ;)) et j'ai vraiment rarement du temps.
Avec un conseil comme "Contactez-moi d'abord", ça me laisse passer le message: "tu dois attendre que je te donne un feu vert et si moi je n'ai pas de temps maintenant pour en parler, ben, tu attendras mon retour de rush du boulot ou de vacances".
Dans la notion de collaborer, il faut que les 2 parties fassent un pas vers l'autre. C'est justement toute la force des forges comme Gitlab: elles permettent de discuter facilement des nouvelles fonctionnalités, d'en proposer 15 versions dans 15 branches différentes si nécessaire et de choisir à la fin la plus pertinente.
Avec cette vision, je comprends tout à fait pourquoi des contributeurs ont donné un patch / une nouvelle fonctionnalité puis sont partis: cette attitude ne me semble pas accueillante et même rebute à continuer à aider, car il y a un énorme goulot d'étranglement: une seule personne est capable de fusionner le code et ce sera toujours selon son temps disponible.
La solution pour détruire ce goulot d'étranglement est de faire du développement en communauté pour répartir les tâches: avoir plusieurs personnes pour trier les bugs, pour faire la revue de code et pour donner des idées quant à la direction à prendre. C'est un peu comme la parallélisation de nos CPUs: c'est un peu dur à gérer comme il faut au début (il faut avoir des gens de confiance), mais quand c'est bien géré, le projet avance beaucoup plus vite, puisque plusieurs cerveaux peuvent travailler en même temps !