Comment gérer un programmeur difficile rejoignant un projet open source?
J'ai un script open source pour un site spécifique (j'essaie de ne rien appeler par nom ici) que moi et quelques autres développeurs avons récemment déplacé vers GitHub. Nous avons obtenu plusieurs nouveaux développeurs depuis que nous sommes passés au nouveau système, dont un très actif en particulier. Cependant, celui-ci actif a commencé à changer une grande partie du projet.
Tout d'abord, il a supprimé notre système de gestion des versions (pas comme Git, mais comme ça - nous l'avons appelé versions v4.1.16) et a dit qu'il serait préférable de simplement pousser le code sur le site lorsque nous pensons qu'il est prêt. Maintenant, il n'y a pas d'endroit centralisé pour mettre les notes de publication, ce qui est devenu ennuyeux.
La chose qui m'a rendu presque prêt à faire mes valises et à partir était le script Push. Un autre développeur du projet a écrit un simple script Push basé sur Python. Comme nous gardons plusieurs versions du script en ligne à divers endroits, j'ai commencé à coder un programme Java Java avec une interface graphique qui remplacera le script Python. I a continué IRC pour en informer tout le monde, et j'ai reçu une réponse très ennuyeuse du programmeur disant que l'ancien script basé sur Python peut faire tout ce que le mien peut faire et est tellement plus léger (il a également commenté le fait qu'il pensait Python était meilleur que Java et ainsi de suite). J'ai regardé le code de l'ancien script Push et j'ai vu qu'aucun des caractéristiques qu'il a dit exister étaient là.
Alors maintenant, je veux savoir quoi faire. J'ai passé beaucoup de temps sur ce projet, donc je ne veux pas simplement me lever et partir, mais j'ai du mal à travailler avec ce nouveau développeur. D'un autre côté, il est désormais le committer n ° 1 du projet, avec encore plus de commits que le développeur principal. Je ne sais pas trop quoi faire à ce sujet. Quelqu'un d'autre a-t-il rencontré ce problème? Si oui, qu'avez-vous fait?
MISE À JOUR 1: J'ai désactivé l'accès à la validation de tout le monde et je demande aux gens de passer par des demandes de tirage. J'ai également proposé plusieurs mesures pour résoudre les autres problèmes. Tout le monde n'a montré aucun soutien pour cela. Le développeur gênant a simplement dit que les personnes qui ne suivaient pas de près l'action de "validation" pouvaient penser que le projet était désorganisé alors qu'il ne l'était vraiment pas. Je ne suis évidemment pas d'accord avec cela, alors j'envisage sérieusement de démissionner du projet.
PDATE 2: Le développeur principal a commencé à se plaindre du fait que l'un de mes commits aurait supprimé trois nouvelles lignes dans le code (le commit de retour est apparu juste après avoir posté la discussion, et ne fait même pas référence à mon "commit"), puis les deux ont commencé à discuter de l'opportunité de révoquer mon accès à la validation. J'ai donc fait la chose logique et quitté le projet. Merci pour votre aide avec tout le monde!
Vous pouvez quitter. Pas la chose la plus constructive à faire, mais parfois c'est la seule option. Si vous le faites, ne vous asseyez pas et ne gémissez pas sur la façon dont vous avez dû l'abandonner, prenez cette énergie et mettez-la directement dans autre chose - `` passez à autre chose '' en d'autres termes.
Vous pouvez le bifurquer. Il n'y a aucune raison pour que vous deviez travailler avec quelqu'un. Fork, améliorez le code et laissez les autres continuer à avoir leur propre ego-fest. Votre nouveau projet sera simplement en concurrence avec l'ancien et c'est à vous de décider si vous réussissez, ou si l'ancien vous bat en termes d'utilisateurs et de fonctionnalités.
Vous pouvez vous engager avec le reste de l'équipe de développement sur le projet pour exprimer vos préoccupations. Ne le faites pas de manière personnelle, mais dites que vous n'êtes pas satisfait du barattage de code, ou du manque de processus de qualité établis, ou mécontent que les nouvelles décisions soient simplement repoussées sans l'accord de tout le monde. On vous dira soit que rien ne va mal pour changer, soit quelques autres seront d'accord avec vous sur le fait que l'équipe doit arranger les choses. Cela pourrait finir par le gars perturbateur perdre son accès de validation. Peut-être serez-vous tous d'accord pour dire que certains des changements ne sont pas des améliorations et que le projet doit être annulé. (Cette dernière option est le résultat le plus probable, à moins qu'elle ne se transforme en un argument massif d'opinions bien établies.)
Cela peut être difficile quand quelqu'un arrive et change les routines sûres et confortables auxquelles vous êtes habitué, mais on pourrait dire que faire venir quelqu'un et secouer les anciennes pratiques confortables est une bonne chose en soi.
Vous avez rendu un peu flou exactement votre rôle ici. La réponse dépend de la façon dont vous vous situez.
Si vous dirigez le projet et contrôlez le référentiel git
Reprenez le contrôle. Si ce type fait des commits que vous n'aimez pas sans vous consulter, supprimez son accès direct au commit. Il peut bifurquer le projet et faire des pull demandes pour fusionner ses commits. C'est comme cela que l'open source devrait fonctionner jusqu'à ce qu'un utilisateur renforce la confiance. Vous n'avez pas besoin et ne devez pas donner un accès complet immédiatement.
Si quelqu'un d'autre contrôle le dépôt
Exprimez vos préoccupations à la personne qui le fait et encouragez un processus plus discipliné pour planifier et approuver les changements. Si le leadership ne se prête pas à un processus, alors vous pouvez choisir d'accepter le statu quo et continuer à contribuer, vous pouvez bifurquer le projet et travailler sur votre propre version (amener toute personne qui est d'accord avec vous), ou vous pouvez choisir de quitter et travailler sur d'autres choses. Dans tous les cas, vous n'êtes pas obligé de continuer à y faire face.
Veuillez pardonner ma franchise, mais votre message se lit comme une diatribe.
Vous dites que c'est l'autre gars qui veut des changements insensés, mais vous vous contredisez quand vous parlez de votre nouveau programme brillant Java Java).
Prendre une pause; ce n'est pas une rue à sens unique, veuillez essayer de trouver des compromis (si vous voulez continuer à travailler sur le projet - la fourche est la décision la plus facile mais elle ne vous mènera nulle part utile, bien qu'elle puisse caresser ton ego).
Réfléchissez également à la division du travail dans le projet - les guerres de territoire sont inévitables si vous n'avez pas de frontières claires vous indiquant qui est compétent en quoi. Oui, il faut parfois faire confiance au jugement des autres.
Il est déjà mentionné dans plusieurs réponses que la division du travail est un moyen de réduire les conflits. Voici quelques exemples concrets:
- Équilibrez productivité et stabilité. Pour emprunter une analogie aux jeux de stratégie, une équipe doit être composée d'un mélange de Boom, Turtle and Rush , et ses coéquipiers doivent être prêt à changer de rôle en réponse à la situation.
- Quand on est dans un engouement pour la productivité, les autres peuvent travailler sur:
- Autres caractéristiques
- Correction de bugs
- Spécifications (gestion des demandes de nouvelles fonctionnalités et vérification de la conformité du logiciel aux critères convenus)
- Assurance qualité
- Tests manuels (exploratoires)
- Test automatisé
- Documentation
- Refactoring et nettoyage de code
- Mener des études d'utilisateurs pour recueillir des idées d'améliorations
- etc.
- Un projet peut être modularisé (comme dans l'architecture logicielle), ou même compartimenté (comme dans la gestion de projet) afin que chaque module puisse être travaillé indépendamment.
- En général, la plupart des logiciels qui contiennent à la fois un front-end et un back-end doivent être modularisés, car ils ont une vitesse de développement différente.
- Les logiciels riches en UX peuvent être difficiles à modulariser en raison de leur utilisation intensive du routage d'événements inter-modules.
- Le responsable d'un projet peut vouloir garder le projet simple en évitant la modularisation.
- Branche de fonctionnalités . Chaque développeur peut bifurquer le projet, travailler sur sa fonctionnalité préférée pour animaux de compagnie et demander une fusion lorsque l'implémentation est terminée. Le développeur principal peut avoir le dernier mot sur l'acceptation de la fusion.
Mis à part l'aspect de prévention des conflits, il est évident que le projet peut avoir une gouvernance insuffisante .
Pourquoi la gouvernance est-elle importante? Imaginez un jour qu'un ancien coéquipier prenne un morceau du logiciel et poursuive l'équipe pour infraction. Ou l'équipe poursuivie en justice par un troll breveté. Ou un inconnu qui a décidé d'envoyer des avis DMCA au site d'hébergement du projet et d'exiger le code source du projet effacé.
Au minimum:
- La licence à utiliser par tout le code source fourni
- La ou les licences sous lesquelles le code source du projet peut être publié
- Dans le cas où une nouvelle licence publique est demandée, comment obtenir le consentement de chaque contributeur
- Qui peut avoir un accès administratif au projet
- Qui sera désigné pour répondre aux demandes légales (telles que les avis DMCA ou les trolls des brevets)
- Qui gérera le financement du projet (payer les frais de serveur et tenir la comptabilité des recettes publicitaires ou des dons)
- Qui aura le droit de vote pour inclure de nouveaux membres et expulser des membres.
- etc.
La plupart des sites de projets open source peuvent fournir des chartes de gouvernance de projet toutes faites.
J'ai déjà vu le problème. Mais après quelques années, vous en avez vraiment assez du projet, donc ma solution était de quitter le projet. Cela peut ne pas fonctionner pour vous, mais le problème est fondamentalement que différentes personnes pensent différemment. Les fonctionnalités que vous jugez très importantes ne le sont pas du tout pour les autres.
Un bon plan serait de diviser les tâches de personnes différentes. Si vous êtes d'accord avec les personnes pour lesquelles la partie du projet est sous la responsabilité de chaque personne, alors une seule personne prend des décisions sur une certaine partie du projet. Mais le travail d'équipe est toujours difficile. Vous n'aimerez toujours jamais les décisions prises par d'autres programmeurs. La meilleure solution est de ne jamais regarder ce que les autres programmeurs ont décidé. Il suffit de leur faire confiance pour faire la bonne chose suffit.
Objectif commun concentrera vos efforts sur les choses importantes. Tous ceux qui travaillent dans la même direction sont difficiles à obtenir, et des conflits surviendront de toute façon. Décider d'un objectif commun nécessite de savoir quel est l'état actuel du projet, puis de décider où il doit être après un certain temps.
Voici un exemple de choses à éviter: Par exemple, un grand nombre de programmeurs c ++ pensent que le code qui n'utilise pas la bibliothèque STL est cassé. D'autres programmeurs pensent que chaque dépendance aux bibliothèques externes est rompue, y compris STL. De tels conflits ne peuvent tout simplement pas être résolus correctement - les deux situations ne peuvent pas être remplies simultanément - et les personnes les plus problématiques pousseront leur opinion quelle que soit l'opposition qu'elles rencontreront.
Quatre choix, je pense.
- Tuez-le. Vous êtes (prétendument) toujours le mec principal de ce projet; révoquer ses privilèges Push et l'appeler un jour. Le résultat le plus probable est qu'il bifurque le projet, divise sa communauté, puis une guerre éclate, et lorsque la poussière retombera, l'une des fourchettes sera la plus populaire.
- Fourchez-le et continuez ailleurs. Moins agressif que 1., mais les conséquences sont par ailleurs les mêmes. Vous devrez cependant être actif dans la communauté pour attirer les gens à vos côtés.
- Laissez-le tranquille: laissez-le faire ce qu'il fait, calmez-vous et espérez le meilleur.
- Discutez avec la communauté, faites des compromis au besoin et résolvez la situation.
Personnellement, je préfère l'option 4.
Google a eu quelques discussions techniques à ce sujet il y a quelques années. Regardez-les: 1 , 2 . En un mot:
- Comprendre : comprendre la motivation de votre communauté à travailler sur votre projet par rapport à tous les autres coûts d'opportunité et préserver ces raisons.
- Fortifier : Construire une communauté saine avec des normes sociales de politesse, de respect, de confiance et d'humilité.
- Identifier : Recherchez les signes révélateurs de personnes toxiques (trop nombreux pour être énumérés, mais si vous posez cette question, vous connaissez probablement déjà beaucoup de leur).
- Désinfectez : Soyez calme et tenez bon, ne réagissez pas aux insultes, aux insultes, aux défis, au manque de respect, etc., et persistez à renforcer vos normes communautaires.
Un plan écrit complet est également disponible si vous préférez lire au lieu de regarder.
Vous ne pouvez pas simplement arrêter sans prendre la peine d'exprimer vos préoccupations et vos difficultés. Je sais que ça peut être difficile. Si en fait vous et les membres de votre équipe êtes assez jeunes pour ne pas rencontrer de nombreux problèmes sociaux survenant dans une équipe de développement, cela peut être très difficile.
Cela dit, je crois fermement que vous devriez exprimer vos préoccupations. Vous pouvez les écrire dans l'e-mail et le montrer à vos amis de confiance qui ne font pas partie de l'équipe et qui n'ont pas ou peu d'intérêt pour ce que vous faites. Dans ce cas, vous pouvez obtenir un bon retour afin que la formulation de votre e-mail ne soit pas trop sévère. Restez fidèle aux faits. N'accusez pas et ne blâmez pas. Juste des faits qu'il est difficile de faire quelque chose pour vous parce que "bla" manque. La raison pour laquelle 'blah' est manquant devrait être claire pour chaque membre de l'équipe, c'est-à-dire que "le nouveau programmeur" a supprimé ou n'a pas accompli quelque chose.
Encore une fois, l'envoi de cet e-mail est difficile, mais c'est en soi une excellente expérience qui peut être très utile pour vous à l'avenir. Grande leçon à apprendre.
PS: Je ne voulais pas paraître trop parental. Cependant, c'est quelque chose que je dirais à quiconque, y compris mes enfants.