Comment puis-je gérer un programme difficile qui rejoint un projet open source?

J'ai un script open source pour un site spécifique (j'essaie de ne rien appeler par son nom ici) que moi-même et quelques autres développeurs avons récemment transféré sur GitHub. Nous avons eu plusieurs nouveaux développeurs depuis que nous sommes passés au nouveau système, y compris un très actif en particulier. Cependant, cet actif a commencé à changer beaucoup de projet.

Tout d'abord, il a supprimé notre système de gestion de versions (pas comme Git, mais comme cela - nous l'appelions versions v4.1.16) et a déclaré qu'il serait préférable de simplement envoyer le code sur le site lorsque nous pensons qu'il est prêt. Maintenant, il n'y a plus d'endroit centralisé pour mettre les notes de publication, ce qui est devenu agaçant.

Ce qui m'a vraiment préparé à faire mes valises et à partir, c'est le script push. Un autre développeur du projet a écrit un simple script push basé sur Python. Puisque nous gardons plusieurs versions du script en ligne à différents endroits, j'ai commencé à coder un programme Java plus volumineux avec une interface graphique qui remplacera le script Python. Je suis allé sur IRC pour informer tout le monde à ce sujet, et le programmeur a répondu avec agacement que le vieux 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 parcouru le code de l'ancien script push et constaté qu'aucune des fonctionnalités qu'il avait dites n'existait.

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 maintenant 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'as-tu fait?

MISE À JOUR 1 : J'ai désactivé l'accès de commit à tout le monde et je demande aux personnes de passer par des demandes d'extraction. J'ai également proposé plusieurs mesures pour résoudre les autres problèmes. Tout le monde n'a pas montré de soutien pour cela. Le développeur gênant a simplement dit que les personnes qui ne suivent pas "l'action engagée" de près peuvent penser que le projet est désorganisé alors qu'il ne l'est vraiment pas. Je ne suis évidemment pas d'accord avec cela, alors j'envisage sérieusement de démissionner du projet.

MISE À JOUR 2 : Le développeur principal a commencé à faire des reproches sur le fait qu’un de mes commits aurait soi-disant supprimé trois nouvelles lignes dans le code (le revert commit est apparu juste après la publication de la discussion et ne fait même pas référence à mon "commit"), puis les deux d'entre eux ont commencé à discuter de l'opportunité de révoquer mon accès de commit. Donc, j'ai fait la chose logique et quitté le projet. Merci pour votre aide avec tout le monde!

1. Vous pouvez quitter. Ce n'est pas la chose la plus constructive à faire, mais c'est parfois la seule option. Si vous le faites, ne vous asseyez pas et ne vous plaignez pas de la façon dont vous deviez y renoncer, utilisez cette énergie et mettez-la directement dans un autre domaine - «passez à autre chose».

2. Vous pouvez le fourrer. Il n'y a aucune raison pour laquelle vous devez travailler avec quelqu'un. Fork, améliorez le code et laissez les autres continuer à organiser leur propre fête de l'ego. Votre nouveau projet sera tout 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.

3. Vous pouvez engager le reste de l'équipe de développement sur le projet pour exprimer vos préoccupations. Ne faites pas cela personnel, mais dites que vous n'êtes pas satisfait du désabonnement du code, du manque de processus de qualité établis, ou du fait que les nouvelles décisions soient simplement repoussées sans l'accord de tout le monde. On vous dira soit que rien ne va assez pour changer, soit que quelques autres personnes soient d'accord avec vous pour dire que l'équipe doit régler le problème. Le gars perturbateur pourrait perdre son accès au commit. Vous conviendrez peut-être tous 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, sauf si elle se transforme en un argument massif d'opinions enracinées.)

Cela peut être difficile quand quelqu'un arrive et change les habitudes sécuritaires et confortables auxquelles vous êtes habitués, mais on pourrait dire que le fait de venir bousculer les vieilles pratiques douillettes est une bonne chose en soi.

Vous avez laissé un peu difficile de savoir exactement quel est votre rôle ici. La réponse dépend de votre position.

Si vous dirigez le projet et contrôlez le référentiel git

Reprenez le contrôle. Si ce gars 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 demandes d'extraction pour fusionner ses commits. C’est comme cela que l’open source devrait fonctionner jusqu’à ce qu’un utilisateur établisse une relation de confiance. Vous n'avez pas besoin, et ne devriez pas, donner un accès complet immédiatement.

Si quelqu'un d'autre contrôle le repo

Exprimez vos préoccupations à la personne qui le fait et encouragez un processus plus discipliné pour la planification et l'approbation des changements. Si les dirigeants ne sont pas disposés à suivre un processus, vous pouvez alors choisir d'accepter le statu quo et continuer à contribuer, vous pouvez créer le projet et travailler sur votre propre version (avec tout le monde 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 à gérer cela.

S'il vous plaît pardonnez-moi mon franc-parler, mais votre message se lit comme un diatribe.

Vous dites que c'est l'autre type qui souhaite des changements stupides, mais vous vous contredisez quand vous parlez de votre nouveau programme Java brillant.

Prendre une pause; ce n'est pas une rue à sens unique , s'il vous plaît essayer de trouver des compromis (si vous voulez continuer à travailler sur le projet - fork est la décision la plus facile , mais il ne vous mènera nulle part utile, bien qu'il puisse caresser votre ego).

Veuillez également bien réfléchir à 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.

Plusieurs réponses ont déjà indiqué que la division du travail est un moyen de réduire les conflits. Voici quelques exemples concrets:

1. Équilibre entre 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 et Rush , et ses coéquipiers doivent être prêts à changer de rôle pour faire face à 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 que le logiciel répond aux critères convenus)
   • Assurance qualité
     • Tests manuels (exploratoires)
     • Test automatisé
   • Documentation
   • Refactoring et nettoyage de code
   • Réaliser des études d'utilisateurs pour recueillir des idées d'amélioration
   • etc.
2. Un projet peut être modularisé (comme dans une 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 contenant à la fois un serveur frontal et un serveur principal 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 des événements entre modules.
   • Le responsable du projet peut vouloir garder le projet simple en évitant la modularisation.
3. Branche de fonctionnalité . Chaque développeur peut créer un projet, travailler sur sa fonction animal préférée et demander une fusion une fois l'implémentation terminée. Le développeur principal peut avoir le dernier mot sur l'acceptation de la fusion.

Outre l'aspect de prévention des conflits, il est évident que la gouvernance du projet peut être insuffisante .

Pourquoi la gouvernance est-elle importante? Imaginez un jour un ancien coéquipier a saisi une partie du logiciel et a poursuivi l’équipe en justice pour infraction. Ou l'équipe poursuivie par brevet troll. Ou personne ne sait qui a décidé d'envoyer des avis DMCA au site d'hébergement du projet et d'exiger que le code source du projet soit effacé.

Au minimum:

• La licence à utiliser par tous les codes sources fournis
• 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 agents de brevets)
• Qui gérera le financement du projet (prise en charge des dépenses de serveur et comptabilité des recettes publicitaires ou des dons)
• Qui aura le droit de vote pour inclure les nouveaux membres et les membres expulsés.
• etc.

La plupart des sites de projet open source peuvent fournir des chartes prêtes à l'emploi pour la gouvernance de projet.

J'ai déjà vu le problème. Mais après quelques années, vous en avez vraiment marre du projet. Ma solution a donc été de quitter le projet . Cela pourrait ne pas fonctionner pour vous, mais le problème est fondamentalement que différentes personnes pensent de différentes manières. Les caractéristiques que vous jugez très importantes n’ont aucune importance pour d’autres personnes.

Un bon plan serait de diviser les tâches de différentes personnes. Si vous êtes d’accord avec les personnes pour déterminer quelle partie du projet relève de la responsabilité de chaque personne, une seule personne prend les décisions concernant certaines parties du projet. Mais le travail d'équipe est toujours difficile. Vous n'allez toujours pas aimer 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.

Un objectif commun concentrera vos efforts sur les éléments importants. Tous ceux qui travaillent dans la même direction sont difficiles à obtenir et des conflits surviendront de toute façon. Pour définir un objectif commun, il faut connaître l’état actuel du projet, puis décider où il doit être après un certain temps.

Voici un exemple d'éléments à é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 à des bibliothèques externes est brisée, y compris STL. De tels conflits ne peuvent tout simplement pas être résolus correctement - les deux situations ne peuvent pas être résolues simultanément - et les personnes les plus problématiques exprimeront leur opinion, quelle que soit leur opposition.

Quatre choix, je pense.

1. Kick le sortir. Vous êtes (prétendument) toujours le mec principal de ce projet; révoquer ses privilèges push et appeler un jour. Le résultat le plus probable est qu'il bricole le projet, divise sa communauté, puis une guerre se déchaîne et, lorsque la poussière retombe, une des fourchettes devient populaire.
2. Fourchette et continuer ailleurs. Moins agressif que 1., mais les conséquences sont sinon les mêmes. Cependant, vous devrez être actif dans la communauté pour attirer les gens à vos côtés.
3. Laissez-le être: laissez-le simplement faire ce qu'il est en train de faire, calmez-vous et espérez le meilleur.
4. Discutez avec la communauté, faites les compromis nécessaires et résolvez la situation.

Personnellement, je préférerais l'option 4.

Google a eu quelques discussions techniques à ce sujet il y a quelques années. Regarde-les:1 ,2 . En un mot:

1. Compréhension : comprenez la motivation de votre communauté à travailler sur votre projet par rapport à tous les autres coûts d'opportunité, et préservez ces raisons.
2. Fortifier : Construisez une communauté saine avec des normes sociales de politesse, de respect, de confiance et d'humilité.
3. Identifiez : Recherchez les signes révélateurs de personnes empoisonnées (trop nombreux pour être énumérés, mais si vous posez cette question, vous en connaissez probablement déjà beaucoup).
4. Désinfectez : restez calme et tenez ferme, ne réagissez pas aux insultes, aux affronts, aux défis, au manque de respect, etc., et persistez à renforcer les normes de votre communauté.

Un plan écrit complet est également disponible si vous préférez lire au lieu de regarder.

Vous ne pouvez pas simplement quitter sans prendre un effort pour exprimer vos préoccupations et vos difficultés. Je sais que ça peut être difficile. Si le fait est que si vous et les membres de votre équipe êtes suffisamment jeunes pour ne pas être confrontés à 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 le courrier électronique et le montrer à vos amis de confiance qui ne font pas partie de l'équipe et qui ne s'intéressent pas ou peu à ce que vous faites. Dans ce cas, vous pouvez obtenir un bon retour d'information afin que la formulation de votre courrier électronique ne soit pas trop dure. S'en tenir aux faits cependant. Ne pas accuser ou blâmer. Juste des faits qu'il est difficile de faire quelque chose pour vous parce que "blah" est manquant. Pourquoi "bla" est manquant devrait être clair pour chaque membre de l'équipe, c'est-à-dire que "le nouveau programmeur" a été supprimé ou n'a pas accompli quelque chose.

Encore une fois, l'envoi de cet email est difficile, mais c'est en soi une excellente expérience qui peut vous être très utile pour aller de l'avant. Grande leçon à apprendre.

PS: Je ne voulais pas paraître trop parental. Cependant, c'est effectivement quelque chose que je dirais à quiconque, y compris à mes enfants.