Salut Je m'appelle Dmitry Pavlov, je travaille chez
GridGain , et je suis également committer et membre de PMC chez Apache Ignite et contributeur à Apache Training. Récemment, j'ai fait un rapport sur le travail du committer lors de la réunion de Sberbank sur l'open source. Avec le développement de la communauté opensource, beaucoup ont commencé à se poser des questions: comment devenir un committer, quelles tâches entreprendre et combien de lignes de code vous devez écrire pour obtenir ce rôle. Quand on pense aux committers, on nous présente immédiatement des personnes omnipotentes et omniscientes avec une couronne sur la tête et un volume de «Code propre» au lieu d'un sceptre. En est-il ainsi? Dans mon article, je vais essayer de répondre à toutes les questions importantes sur les committers afin que vous puissiez comprendre si vous en avez vraiment besoin.
Tous les nouveaux arrivants dans la communauté open source ont une vague de pensées qu'ils ne deviendront jamais des committers. En effet, pour beaucoup, c'est un rôle prestigieux qui ne peut être obtenu que pour des mérites particuliers en écrivant une tonne de code. Mais ce n'est pas si simple. Jetez un oeil à la committer de la communauté.
Qui est un committer et pourquoi est-il nécessaire?
Lors de la création d'un nouveau produit opensource, nous autorisons toujours les utilisateurs à l'utiliser et à le rechercher, ainsi qu'à modifier et distribuer des copies modifiées. Mais quand il y a une distribution incontrôlée de copies du logiciel avec les modifications apportées, alors nous ne recevons pas de contrebuffes dans la base de code principale et le projet ne se développe pas. Ici, le même committer est déjà nécessaire, qui a le droit de collecter les contributions des utilisateurs au projet.
Pourquoi devenir committer?
Pour commencer, la validation est un atout pour le CV et pour les débutants dans le domaine de la programmation, c'est un avantage encore plus important, car souvent, lorsqu'ils postulent pour un emploi, ils demandent des exemples de code.
Le deuxième avantage incontestable de l'engagement est la capacité de communiquer avec les meilleurs experts et de tirer des idées intéressantes de l'open source dans votre projet. De plus, si vous connaissez bien un certain produit open source, vous pouvez obtenir une entreprise qui le prend en charge ou l'utilise. Il y a même une opinion selon laquelle si vous ne participez pas à l'open source, vous ne pouvez pas accéder à des postes de carrière élevés.
En plus des avantages en termes de carrière et d'emploi, s'engager en soi est agréable. La communauté professionnelle vous reconnaît, vous voyez clairement le résultat de votre travail. Pas comme dans une sorte de développement d'entreprise, où parfois vous ne comprenez même pas pourquoi vous transférez des champs en va-et-vient en XML.
Dans les communautés open source, vous pouvez rencontrer les meilleurs experts au niveau Linus Torvalds. Mais si vous n'êtes pas comme ça, vous ne devriez pas penser que vous n'avez rien à faire là-bas - il y a des tâches de différents niveaux.
Eh bien, il y a des bonus supplémentaires: les commetteurs Apache, par exemple, obtiennent une licence IntelliJ Idea Ultimate gratuite (bien qu'avec certaines limitations).
Que faire pour devenir committer?
Tout est simple - vous devez vous engager.
Si vous pensez qu'il n'y a pas de tâches pour vous sur les projets, vous vous trompez. Rejoignez simplement la communauté qui vous intéresse et faites ce qu'elle doit faire. Apache Software Foundation a un
guide séparé pour les exigences de committer.
Quelles tâches devrez-vous résoudre?
Les plus divers - du développement à la rédaction des tests et de la documentation. Oui, la contribution des testeurs et des documentaristes dans la communauté est appréciée avec la contribution des développeurs. Il existe des tâches non standard, par exemple, diriger une chaîne YouTube et indiquer aux autres utilisateurs comment vous utilisez le produit opensource. Par exemple, Apache Software Foundation a une
page séparée qui indique quelle aide est requise.
Dois-je écrire une grande fonctionnalité pour devenir un committer?
Non. Ce n'est pas du tout nécessaire. Le committer ne doit pas écrire des tonnes de code. Mais si vous avez écrit un gros article, il sera plus facile pour le comité de gestion de projet de vous évaluer. Contribuer à la communauté ne concerne pas seulement les fonctionnalités, la programmation et les tests. Si vous écrivez une lettre et parlez d'un problème, proposez une solution raisonnée - c'est aussi une contribution.
Il est important de comprendre que s'engager, c'est la confiance. Les personnes qui décident de faire de vous un contributeur ou non sont décidées par des personnes comme vous en fonction de leur point de vue sur vous en tant que personne bénéficiant du produit. Par conséquent, vous, à travers vos actions et vos actions dans la communauté, devez gagner cette confiance.
Comment se comporter?
Soyez constructif, positif, poli et patient. N'oubliez pas qu'en open source, tous les bénévoles et personne ne doivent rien à personne. Ils ne vous répondent pas - attendez et rappelez votre question dans 3-4 jours. Ils ne vous répondent pas constamment - eh bien, l'open source est volontaire.
Ne demandez pas de faire quelque chose pour vous ou pour vous. Les membres expérimentés de la communauté ont un flair pour ces «mendiants» et il y a immédiatement une allergie à ceux qui veulent leur pousser le travail.
Si vous êtes aidé, c'est super, mais n'en abusez pas. N'écrivez pas: "Les gars, corrigez cela, sinon je perds le prix annuel." Il vaut mieux demander où vous allez passer et nous dire ce que vous avez déjà trouvé sur ce bug. Et si vous vous engagez à mettre à jour le wiki en fonction des résultats de la résolution du problème, la probabilité qu'il vous réponde augmentera considérablement.
Enfin, lisez le
Code de conduite et apprenez
à poser des questions .
Comment contribuer si vous n'êtes pas un contributeur?
Les projets utilisent souvent le schéma RTC, lorsque tout le monde passe par l'examen en premier, puis les modifications sont fusionnées dans le masque. Avec ce schéma, absolument tout passe par un examen, même les committers. Par conséquent, vous pouvez contribuer avec succès au projet sans être un contributeur. Et afin de faciliter votre sélection en tant que nouveau committer, vous pouvez encadrer de nouveaux membres, partager des connaissances, créer de nouveaux supports.
Diversité - avantage ou préjudice?
La diversité - dans la compréhension de l'Apache Software Foundation, c'est, entre autres, l'affiliation des participants à un projet open source avec plusieurs entreprises. Si tout le monde est affilié à une seule organisation, alors avec la perte de son intérêt pour le projet, tous les participants s'enfuient de manière célèbre. La diversité offre une stabilité à long terme du projet, une expérience polyvalente et un large éventail d'opinions des participants.
Par amour ou par commodité?
Dans les projets open source, il existe deux types de personnes: ceux qui travaillent dans une organisation qui contribuent à ce produit, et ceux qui travaillent ici par amour, c'est-à-dire les bénévoles. Lequel d'entre eux est le plus productif? En règle générale, les participants qui soutiennent le produit de l'organisation-contributeur. Ils ont simplement plus de temps et il y a une motivation claire pour aller à la vérité, ils sont concentrés sur la tâche et plus proches de l'utilisateur.
Ceux qui le font «par amour» sont également motivés, mais d'une manière différente - ils sont désireux d'étudier le projet, de rendre le monde meilleur. Et ce sont précisément ces participants qui sont plus stables et axés sur le long terme, car il est peu probable que ceux qui sont venus dans la communauté de leur propre initiative la quittent un jour.
Comment trouver un équilibre entre productivité et stabilité? Il y a deux options. Première option: lorsqu'un participant travaille pour une entreprise qui est officiellement engagée dans ce projet open source et y fait quelque chose de plus, dans son propre intérêt - par exemple, il soutient les nouveaux arrivants. La deuxième option est une entreprise qui a connu une transformation open source. Par exemple, lorsque les employés ont vu le projet d'entreprise principal quatre jours par semaine, et le reste du temps, ils font de l'open source.
Le committer - être ou ne pas être?
L'engagement est un bon sujet et utile, mais vous ne devez pas vous efforcer de devenir un committer. Ce rôle peut être obtenu non pour du code, et il ne prouve pas vos connaissances. Seule l'expertise est importante, c'est-à-dire les connaissances et l'expérience que vous gagnerez en étudiant le projet, en vous y plongeant et en aidant les autres à résoudre les problèmes.