Bonjour! Je m'appelle Dmitry Pavlov, je travaille chez , et je suis également committer et participant PMC à Apache Ignite et contributeur à Apache Training. J'ai récemment fait une présentation sur le travail d'un committer lors de la rencontre open source de la Sberbank. Avec le développement de la communauté open source, de nombreuses personnes ont commencé à se poser de plus en plus de questions : comment devenir committer, quelles tâches assumer et combien de lignes de code doivent être écrites pour obtenir ce rôle. Quand on pense aux committers, on imagine immédiatement des personnes omnipotentes et omniscientes avec une couronne sur la tête et un volume de « Clean Code » au lieu d’un sceptre. Est-ce ainsi ? Dans mon article, j'essaierai 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 pensent qu’ils ne deviendront jamais des committers. Après tout, pour beaucoup, il s'agit d'un rôle prestigieux qui ne peut être obtenu qu'avec un mérite particulier en écrivant une tonne de code. Mais ce n'est pas si simple. Jetons un coup d'œil au committer du point de vue de la communauté.
Qui est un committer et pourquoi en est-il nécessaire ?
Lorsque nous créons 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 lorsqu'il y a une distribution incontrôlée de copies de logiciels avec des modifications, nous ne recevons pas de contributions à la base de code principale et le projet ne se développe pas. C'est ici qu'il faut un committer, qui a le droit de collecter les contributions des utilisateurs au projet.
Pourquoi devenir un commiter ?
Commençons par le fait que s'engager est un plus pour un CV, et pour les débutants dans le domaine de la programmation, c'est un plus encore plus important, car souvent, lorsqu'ils postulent à un emploi, ils demandent des exemples de code.
Le deuxième avantage incontestable de l'engagement est la possibilité de communiquer avec les meilleurs spécialistes et d'intégrer 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 un emploi dans une entreprise qui le prend en charge ou l'utilise. Il existe même une opinion selon laquelle si vous ne participez pas à l’open source, vous n’accéderez pas à des postes élevés dans votre carrière.
Au-delà des bénéfices en termes de carrière et d’emploi, s’engager est en soi agréable. Vous êtes reconnu par le milieu professionnel, vous voyez clairement le résultat de votre travail. Pas comme dans certains développements d’entreprise, où parfois vous ne comprenez même pas pourquoi vous déplacez des champs dans les deux sens en 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 comme ça, ne pensez pas que vous n'avez rien à faire là-bas - il y a des tâches de différents niveaux.
Eh bien, il y a aussi des bonus supplémentaires : les committers Apache, par exemple, reçoivent une licence IntelliJ Idea Ultimate gratuite (avec quelques restrictions).
Que faire pour devenir commiter ?
C'est simple : il vous suffit de 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 dont elle a besoin. L'Apache Software Foundation dispose d'un avec des exigences pour les committers.
Quels problèmes devrez-vous résoudre ?
Les plus variés - du développement à l'écriture de tests et de documentation. Oui, oui, la contribution des testeurs et des documenteurs dans la communauté est valorisée sur un pied d'égalité avec celle des développeurs. Il existe des tâches non standard - par exemple, gérer une chaîne YouTube et expliquer aux autres utilisateurs comment vous utilisez un produit open source. Par exemple, l'Apache Software Foundation dispose d'un , où il est indiqué quelle assistance est requise.
Dois-je écrire un long article pour devenir committer ?
Non. Ce n'est pas du tout nécessaire. Le committer n'a pas besoin d'écrire des tonnes de code. Mais si vous avez écrit un long article, il sera plus facile pour le comité de gestion de projet de vous évaluer. Contribuer à la communauté ne se limite pas aux fonctionnalités, à la programmation et aux 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 est une question de confiance. Que vous deveniez un engagement ou non est décidé par des personnes comme vous, en fonction de leur vision de vous en tant que personne qui apporte des avantages au produit. Par conséquent, vous devez, par vos actions et vos actes au sein de la communauté, gagner cette confiance.
Comment se comporter?
Soyez constructif, positif, poli et patient. N'oubliez pas qu'en open source, tout le monde est bénévole et personne ne doit rien à personne. Ils ne vous répondent pas - attendez et rappelez-vous votre question dans 3-4 jours. Ils ne vous répondent pas toujours – eh bien, l’open source est volontaire.
Ne demandez pas à quelqu'un de faire quelque chose pour vous ou pour vous. Les membres expérimentés de la communauté ont un instinct pour ces « mendiants » et deviennent immédiatement allergiques à ceux qui veulent leur confier leur travail.
Si vous obtenez de l'aide, c'est bien, mais n'en abusez pas. Vous ne devriez pas écrire : « Les gars, réparez ça, sinon je perds mon bonus annuel. » Il est préférable de demander où aller ensuite et de nous dire ce que vous avez déjà découvert concernant ce bug. Et si vous promettez de mettre à jour le wiki en fonction des résultats de la résolution du problème, la probabilité qu'ils vous répondent augmentera considérablement.
Enfin, lisez et apprendre .
Comment contribuer si vous n’êtes pas engagé ?
Les projets utilisent souvent un schéma RTC, où tout passe d'abord par une révision, puis les modifications sont fusionnées dans le maître. Avec ce système, absolument tout le monde est soumis à un examen, même ceux qui s'engagent. Par conséquent, vous pouvez contribuer avec succès à un projet sans vous engager. Et afin de faciliter la sélection en tant que nouveaux committers, vous pouvez encadrer de nouveaux participants, partager des connaissances et créer de nouveaux supports.
La diversité : avantage ou inconvénient ?
Diversité - selon la compréhension de l'Apache Software Foundation, il s'agit, entre autres, de l'affiliation des participants à un projet open source par plusieurs entreprises. Si tout le monde est affilié à une seule organisation, alors avec la perte d'intérêt pour le projet, tous les participants le fuient rapidement. La diversité offre un projet stable et à long terme, une expérience diversifiée et un large éventail d’opinions des participants.
Par amour ou par commodité ?
Dans les projets open source, il existe deux types de personnes : celles qui travaillent dans une organisation qui contribue à ce produit et celles qui travaillent ici par amour, c'est-à-dire les bénévoles. Lequel est le plus productif ? Généralement, les participants qui soutiennent le produit de l'organisation contributrice. Ils ont simplement plus de temps et une motivation évidente pour aller au fond de 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 ont hâte d'étudier le projet, de rendre le monde meilleur. Et ce sont précisément ces participants qui sont les plus stables et les plus orientés vers le long terme, car il est peu probable que ceux qui sont venus dans la communauté de leur propre initiative la quittent en un jour.
Comment trouver un équilibre entre productivité et stabilité ? Il existe deux options. La première option : lorsque le participant travaille dans une entreprise officiellement impliquée dans ce projet open source et y fait quelque chose de plus, dans son propre intérêt - par exemple, soutenir les nouveaux arrivants. La deuxième option est une entreprise qui a subi une transformation open source. Par exemple, lorsque les employés travaillent sur le projet principal de l'entreprise quatre jours par semaine, et le reste du temps, ils travaillent sur l'open source.
Committer - être ou ne pas être ?
S'engager est un sujet intéressant et utile, mais vous ne devriez pas vous efforcer spécifiquement de devenir un engagement. Ce rôle n'est pas un rôle basé sur du code et ne démontre pas vos connaissances. La seule chose qui compte est l'expertise, c'est-à-dire les connaissances et l'expérience que vous acquérez en étudiant le projet, en l'approfondissant et en aidant les autres à résoudre les problèmes.
Source: habr.com