Démystifier la contribution Open Source

CLOUD & INFRA
Temps de lecture : 4 minutes
Microsoft profile picture
WASSIM CHEGHAM

Senior Cloud Advocate

 

 

Ce guide d’apprentissage s’adresse avant tout aux personnes qui contribuent ou envisagent de contribuer pour la première fois aux projets Open Source. Il vous apprendra pas à pas comment participer à ces projets en apportant des actions correctives.

Pourquoi contribuer selon Wissam Chegham : 

 

 En tant qu’auteur et responsable de la maintenance (« maintainer ») de plusieurs projets Open Source, je suis toujours ravi d’apprendre ou de constater que mes projets sont utilisés par d’autres développeurs. Et j’apprécie vraiment que ces développeurs proposent d’apporter des corrections ou des améliorations à ces projets.

Distribuez des applications et des bureaux à distance à partir d’Azure

Familiarisez-vous avec les concepts et outils de gestion des serveurs et des clients ainsi que les technologies de virtualisation Windows, telles que les services Bureau à distance.

Je me forme

Les différentes étapes pour contribuer

Identifiez le projet sur lequel vous souhaitez travailler

 

Il faut commencer par identifier un projet qui vous intéresse particulièrement ou qui semble correspondre à vos compétences. Les personnes qui débutent devraient commencer par un projet portant sur les outils qu’ils utilisent au quotidien, dans leur travail. Vous connaissez déjà ces outils, et vous avez peut-être déjà constaté des problèmes à corriger ou des fonctionnalités à améliorer.

 

Vous n’avez pas besoin d’une raison particulière pour sélectionner un projet. Certains choisissent un projet en fonction de la technologie qu’ils utilisent, d’autres pour s’amuser.

Dupliquer le projet

 

Avant toute chose, il faut dupliquer (« fork ») le projet dans son compte GitHub (si GitHub est utilisé). Cette opération consiste à copier le projet d’origine dans ses propres projets GitHub. Il sera ainsi possible de travailler sur une copie.

 

 

Cloner et installer les dépendances

 

L’étape suivante consiste à cloner (ou télécharger) le projet, qui vient d’être copié (fork), sur l’ordinateur pour commencer à travailler.

 

 

Si votre travail est essentiellement sur la documentation, la traduction ou la correction des fautes de frappe, faite le directement depuis votre navigateur. Inutile de cloner le projet sur son ordinateur. En revanche, si vous devez exécuter une étape de génération (« build ») ou un processus de formatage (« lint ») sur la documentation avant de publier vos modifications, vous devrez cloner le projet sur votre poste et installer les dépendances requises.

 

Une fois le projet cloné, il faut attentivement lire le fichier CONTRIBUTING.md, README.md , ou tout autre fichier qui décrit les étapes nécessaires pour exécuter et générer le projet localement. Si vous êtes bloqué, les mainteneurs du projet pourront vous aider si vous les contactez.

 

Rapport Magic Quadrant 2019 de Gartner – systèmes de bases de données

Lisez les dernières études pour faire des choix informés sur les solutions de systèmes de gestion de base de données sur ce marché de plus en plus concurrentiel.

Télécharger

Comment contribuer ?

 

Les nouveaux contributeurs sont souvent déconcertés par cette étape. Commençons par expliquer ce qu’est une « contribution ».

 

Contribuer à un projet Open Source, ça ne se limite pas à rédiger du code et à corriger des problèmes techniques. En fait, le champ des contributions est quasi illimité.

 

Quelques exemples (des tâches les plus rapides aux plus prenantes) :

 

  1. Remercier l’équipe qui travaille sur un outil que l’on utilise
  2. Faire connaître le projet lors de manifestations ou en ligne
  3. Aider à répondre aux questions
  4. Corriger les fautes de frappe dans la documentation
  5. Rédiger ou traduire la documentation
  6. Aider à reproduire les bogues et les problèmes signalés
  7. Refactoriser le code existant
  8. Corriger les bogues techniques
  9. Écrire des tests unitaires
  10. Intégrer de nouvelles fonctionnalités
  11. Remettre en question la conception de l’architecture centrale
  12. Et plein d’autres…

 

Une contribution concerne tout ce qui peut améliorer un projet.

Identifier un « correctif » à apporter

 

Un correctif et une aide que vous apportez. Un conseil pour les débutants est de ne pas être trop ambitieux. Choisissez un point facile et rapide à corriger. Les fautes de frappe dans la documentation, par exemple. Cela vous permettra de lire toute la documentation et de vous familiariser avec le projet, idéal pour vous en faire une idée précise.

 

La rédaction ou la correction des tests unitaires sont également de bons choix pour une première contribution. Les tests unitaires permettent de se plonger progressivement, à son rythme, dans l’implémentation précise d’une fonctionnalité. Si des tests d’intégration sont prévus, commencez par là avant de vous attaquer aux tests unitaires. Vous aurez ainsi une bonne idée de l’architecture générale, sans avoir à vous plonger dans les détails de l’implémentation.

 

Pensez à indiquer aux autres contributeurs du projet sur quel point vous travaillez, en postant un commentaire dans le fil correspondant, sur la page du dépôt Github.

Application du « correctif »

 

Cette étape dépend surtout du type de problème sur lequel vous travaillez. Lisez attentivement les consignes applicables aux contributions au projet, et à les respecter. La plupart des projets Open Source populaires s’accompagnent de consignes et de règles de formatage strictes qui doivent être suivies par tous les contributeurs.

 

N’hésitez pas à vous adresser au mainteneur ou à d’autres contributeurs si vous êtes bloqué ou si vous avez la moindre question.

Valider et publier des modifications

 

Une fois le correctif prêt, il faut maintenant valider (commit) les modifications et les publier (push) sur votre propre copie du projet, celle que vous avez dupliquée.

 

Encore une fois, vous devez lire attentivement les consignes pour savoir comment formater vos messages de validation et les noms des branches. Chaque projet a ses propres conventions. Une bonne pratique consiste à publier les modifications (correctifs) dans une branche autre que la branche « master » ou « develop », pour pouvoir facilement fusionner ou « rebaser » les modifications par la suite, si c’est nécessaire.

 

 

Il est généralement demandé, et parfois exigé, de fournir une description détaillée des modifications/correctifs/implémentations dans le corps de l’objet « commit ». Cela permet aux autres de connaître immédiatement les modifications apportées par cet objet.

Envoyer une Pull Request

 

Une fois prêt à envoyer vos modifications au projet d’origine ou amont (« upstream »), ouvrez une pull request et envoyez la.

 

 

Une fois votre demande reçue, les mainteneurs du projet peuvent vous demander de mettre à jour ou de revoir vos modifications avant de pouvoir fusionner votre pull request.

 

Si, pour une raison ou une autre (généralement d’ordre technique) les mainteneurs sont dans l’incapacité de fusionner votre pull request, ce n’est ni leur faute, ni la vôtre ; Vous pourrez refaire une tentative ou passez à autre chose en attaquant un nouveau correctif.

 

 

*Ce guide a été écrit en prenant l’hypothèse que vous connaissez déjà Git. 

 

Apprenez à déployer une plateforme Windows Virtual Desktop

Dans ce 1er webinar en 6 parties, nous verrons comment configurer tous les prérequis pour mettre en service un tenant Windows Virtual Desktop et déployer un premier pool d’hôtes Windows 10 avec Office 365.

Je regarde