Bonjour ! Je m'appelle Dmitri Pavlov, je travaille chez , je suis également committer et membre du PMC d'Apache Ignite et contributeur à Apache Training. Récemment, j'ai donné une présentation sur le travail des committers lors d'un meetup de Sberbank sur l'open source. Avec le développement de la communauté open source, beaucoup de gens commencent à se poser des questions : comment devenir committer, quelles tâches prendre et combien de lignes de code faut-il écrire pour obtenir ce rôle. Lorsque nous pensons aux committers, nous imaginons immédiatement des personnes omniscientes et tout-puissantes avec une couronne sur la tête et un exemplaire de « Clean Code » à la place d'un sceptre. Est-ce vraiment le cas ? Dans mon post, je vais tenter de répondre à toutes les questions importantes sur les committers pour que vous puissiez comprendre si c'est vraiment pour vous.

Tous les nouveaux venus dans la communauté open source ont parfois l'impression qu'ils ne deviendront jamais committers. Pour beaucoup, c'est un rôle prestigieux qui ne peut être obtenu qu'en raison de mérites particuliers, en écrivant une tonne de code. Mais ce n'est pas aussi simple. Regardons le rôle du committer du point de vue de la communauté.
Qui est un committer et à quoi sert-il ?
Lors de la création d'un nouveau produit open source, nous permettons toujours aux utilisateurs de l'utiliser et de l'explorer, ainsi que de modifier et de distribuer des copies modifiées. Mais lorsque la diffusion incontrôlée de copies de logiciels avec des modifications se produit, nous ne recevons pas de contributions dans la base de code principale et le projet ne se développe pas. C'est là qu'un committer est nécessaire, car il a le droit de collecter les contributions des utilisateurs au projet.
Pourquoi devenir committer ?
Commençons par dire que le rôle de committer est un atout pour le CV, et pour les nouveaux dans le domaine de la programmation, c'est un avantage supplémentaire, car souvent lors d'un entretien d'embauche, des exemples de code sont demandés.
Le deuxième avantage incontestable de devenir committer est la possibilité de dialoguer avec des experts de haut niveau et d'incorporer de super idées de l'open source dans son projet. De plus, si vous connaissez bien un produit open source, vous pouvez obtenir un emploi dans une entreprise qui le soutient ou l'utilise. Il existe même un avis selon lequel si vous ne participez pas à l'open source, vous ne pourrez pas atteindre des postes élevés dans votre carrière.
En plus des avantages en matière de carrière et d'emploi, le fait d'être contributeur est en soi une expérience agréable. Vous êtes reconnu par la communauté professionnelle et vous voyez clairement le résultat de votre travail. Ce n'est pas comme dans un développement corporatif où l'on ne comprend parfois même pas pourquoi on déplace des champs dans un XML.
Dans les communautés open-source, vous pouvez rencontrer des spécialistes de haut niveau comme Linus Torvalds. Mais si vous n'êtes pas dans ce cas, ne pensez pas que vous n'avez rien à y faire : il existe des tâches de différents niveaux.
Il y a aussi des bonus supplémentaires : par exemple, les contributeurs d'Apache reçoivent gratuitement une licence IntelliJ Idea Ultimate (bien qu'avec certaines limitations).
Que faire pour devenir contributeur ?
C'est très simple : il suffit de contribuer.

Si vous pensez qu'il n'y a pas de tâches pour vous sur les projets, vous vous trompez. Il suffit de rejoindre la communauté qui vous intéresse et de faire ce dont elle a besoin. La fondation Apache Software a des exigences spécifiques pour les contributeurs. Il existe des exigences pour les contributeurs.
Quelles tâches devrez-vous accomplir ?
Les tâches sont variées, allant du développement à la rédaction de tests et de documentation. Oui, la contribution des testeurs et des rédacteurs est prise en compte au même titre que celle des développeurs. Il existe des tâches atypiques, par exemple, gérer une chaîne YouTube et expliquer aux autres utilisateurs comment vous utilisez un produit open-source. Par exemple, la fondation Apache Software a une page distincte ,
Doit-on écrire une grande fonctionnalité pour devenir contributeur ?
Non. Ce n'est pas du tout nécessaire. Un contributeur ne doit pas écrire des tonnes de code. Mais si vous avez écrit une grande fonctionnalité, il sera plus facile pour le comité de gestion de projet de vous évaluer. La contribution à la communauté ne se limite pas aux fonctionnalités, à la programmation et aux tests. Si vous écrivez un e-mail et que vous parlez d'un problème, en proposant une solution argumentée, cela compte également comme une contribution.
Il est important de comprendre que le statut de contributeur repose sur la confiance. La décision de vous faire contributeur ou non est prise par des personnes comme vous, sur la base de leurs opinions à votre égard en tant que personne apportant une valeur ajoutée au produit. Ainsi, vous devez gagner cette confiance par vos actions et comportements au sein de la communauté.
Comment se comporter ?
Soyez constructif, positif, courtois et patient. N'oubliez pas que dans l'open source, tout le monde est bénévole et personne n'est obligé de quoi que ce soit. Si vous n'obtenez pas de réponse, attendez et rappelez votre question dans 3-4 jours. Si vous ne recevez toujours pas de réponse, eh bien, l'open source est une affaire volontaire.

Ne demandez pas à quelqu'un de faire quelque chose pour vous ou à votre place. Les membres expérimentés de la communauté ont un flair pour ce genre de « demandeurs » et réagissent souvent avec allergie envers ceux qui veulent leur déléguer leur travail.
Si quelqu'un vous aide, c'est génial, mais ne profitez pas de la situation. Inutile d'écrire : « Les gars, corrigez ça, sinon je perds ma prime annuelle ». Il vaut mieux demander où vous devez aller ensuite et expliquer ce que vous avez déjà découvert sur ce bug. Et si vous promettez de mettre à jour le wiki une fois le problème résolu, la probabilité d'obtenir une réponse augmentera considérablement.
Enfin, lisez et apprenez .
Comment contribuer si vous n'êtes pas committer ?
Dans les projets, un schéma RTC est souvent utilisé, où tout le monde passe d'abord par une révision, puis les modifications sont fusionnées dans la branche principale. Avec ce système, tout le monde est révisé, y compris les committers. Ainsi, il est possible de contribuer avec succès à un projet sans être committer. Pour être plus facilement choisi comme nouveau committer, vous pouvez vous engager dans le mentorat des nouveaux participants, partager vos connaissances et créer de nouveaux documents.
La diversité – un atout ou un inconvénient ?
La diversité – au sens de la Fondation Apache Software, cela inclut également l'affiliation des participants au projet open source avec plusieurs entreprises. Si tous sont affiliés à une seule organisation, alors à la perte de son intérêt pour le projet, tous les participants s'enfuient rapidement. La diversité assure la pérennité, la stabilité du projet, une expérience variée et un large éventail d'opinions parmi les participants.
Par amour ou par intérêt ?
Dans les projets open source, on trouve deux types de personnes : celles qui travaillent pour une organisation qui contribue à ce produit, et celles qui travaillent ici par passion, c'est-à-dire des bénévoles. Qui est le plus productif ? En général, les participants qui soutiennent le produit du côté de l'organisation contributrice. Ils ont simplement plus de temps et une motivation claire à découvrir 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 différemment : ils ont soif d'explorer le projet et d'améliorer le monde. C'est précisément ce type de participants qui est plus stable et orienté vers le long terme, car celui qui a rejoint la communauté de son propre chef est peu susceptible de la quitter du jour au lendemain.
Comment trouver un équilibre entre productivité et stabilité ? Il y a deux options. La première option : lorsque le participant travaille dans une entreprise qui s'occupe officiellement de ce projet opensource et fait quelque chose de plus par intérêt personnel, par exemple en soutenant les débutants. La deuxième option est celle d'une entreprise ayant vécu une transformation opensource. Par exemple, lorsque les employés passent quatre jours par semaine à travailler sur le projet commercial principal, et le reste du temps à s'occuper de l'open source.
Committer : être ou ne pas être ?

Le committer est un sujet intéressant et utile, mais il ne faut pas nécessairement viser à devenir committer. Ce rôle peut être obtenu sans coder, et il ne prouve pas vos connaissances. Ce qui compte, c'est l'expertise, c'est-à-dire les connaissances et l'expérience que vous acquerrez en étudiant le projet, en l'explorant et en aidant les autres à résoudre des problèmes.
Source : habr.com
