Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Autres indications

Merci de prendre le temps de contribuer à l’extension Rancher CAPI projets.

Les améliorations dans tous les domaines du projet ; du code à la documentation ; des rapports de bogues à la conception de fonctionnalités et à l’amélioration de l’interface utilisateur sont chaleureusement accueillies. Ce guide devrait couvrir tous les aspects de l’interaction avec le projet et de l’implication dans le développement aussi facilement que possible.

Lire la documentation est souvent fastidieux, alors mettons la règle de contribution importante juste en haut : Soyez toujours aimable !

Nous avons hâte de voir vos contributions dans le dépôt !

Comment s’impliquer ?

Nous serions ravis d’accepter vos correctifs dans presque tous les domaines du développement des projets !

Si vous êtes nouveau dans le projet et souhaitez aider, mais ne savez pas par où commencer, voici une liste non exhaustive de façons dont vous pouvez contribuer :

  1. Soumettez une Demande de Tirage

    Au-delà de la correction de bogues et de la soumission de nouvelles fonctionnalités, il existe d’autres choses que vous pouvez soumettre, qui, bien que moins spectaculaires, seront profondément appréciées par tous ceux qui interagissent avec le code :

    • Étendre la couverture des tests !

    • Refactoriser !

    • Réviser et mettre à jour la documentation !

    • Ajouter une nouvelle fonctionnalité d’interface utilisateur !

    (Voir aussi Choisir quelque chose sur quoi travailler ci-dessous.)

  2. Ouvrir un problème

    Nous avons 2 types de problèmes : rapports de bogues et demandes de fonctionnalités. Si vous n’êtes pas sûr de la catégorie dont vous avez besoin, faites simplement le meilleur choix possible et fournissez autant d’informations que possible.

  3. Intéressé à aider à améliorer :

    • l’extension backend Rancher CAPI ? Participez à bugs ou help wanted problèmes. Si vous cherchez à relever un plus grand défi ou à devenir un contributeur plus expérimenté, consultez feature requests.

    • l’interface utilisateur de l’extension ? Jetez un œil à open ou help wanted problèmes.

    • peut-être, la documentation utilisateur ? Ensuite, plongez directement dans open problèmes dans le dépôt de documentation.

Ouverture de problèmes

Ces guides visent à vous aider à rédiger des problèmes de manière à garantir qu’ils soient traités aussi rapidement que possible.

Voir ci-dessous pour comment les problèmes sont priorisés.

Règles générales:

  1. Avant d’ouvrir quoi que ce soit, examinez attentivement les problèmes existants.

  2. Plus il y a d’informations, mieux c’est : donnez autant d’informations que possible. Les problèmes très détaillés sont plus susceptibles d’être pris en charge car ils peuvent être priorisés et programmés pour un travail plus rapide. Ils sont également plus accessibles à la communauté, ce qui signifie que vous n’aurez peut-être pas à attendre que l’équipe noyau s’en occupe.

  3. Veuillez ne pas ouvrir un problème avec une description qui est juste un lien vers un autre problème, un lien vers une conversation Slack, une citation de l’un de ceux-ci, ou quoi que ce soit d’autre d’aussi opaque. Cela élève la barre d’entrée et rend difficile l’implication de la communauté. Prenez le temps d’écrire une description appropriée et de résumer les points clés.

  4. Faites attention à la mise en forme. Assurez-vous que le markdown est soigné, utilisez des blocs de code etc. Plus quelque chose peut être lu rapidement, plus il peut être traité rapidement.

  5. Restez courtois. Oui, c’est ennuyeux quand les choses ne fonctionnent pas, mais c’est beaucoup plus amusant d’aider quelqu’un qui n’est pas …​ le pire. N’oubliez pas que converser par texte exacerbe le biais de négativité de chacun, alors ajoutez quelques émojis en cas de doute.

Soumission de PRs

Choisir quelque chose sur lequel travailler

Si vous êtes ici pour demander de l’aide ou demander un nouveau comportement, cette section est pour vous. Nous avons sélectionné un ensemble de problèmes pour quiconque souhaite simplement renforcer sa crédibilité en Open Source.

  • Les problèmes étiquetés good first issues devraient être accessibles aux personnes nouvelles dans les dépôts, ainsi qu’à l’Open Source en général.

    Ces problèmes devraient présenter une barrière d’entrée faible/non existante avec une description détaillée, une reproduction facile à suivre (si pertinent) et suffisamment de contexte pour que quiconque puisse s’y engager. L’objectif devrait être clair, éventuellement avec une solution suggérée ou un pseudocode. Si quelque chose de similaire a été fait, ce travail devrait être lié.

    Si vous avez rencontré un problème étiqueté good first issue que vous aimeriez revendiquer mais qui n’est pas 100% clair, n’hésitez pas à demander plus d’infos ! Lorsque les gens écrivent des problèmes, il y a une énorme quantité de connaissances supposées qui est très souvent considérée comme acquise. C’est quelque chose sur lequel nous pourrions tous nous améliorer, alors n’hésitez pas à demander ce dont vous avez besoin pour faire un excellent travail.

    Voir plus sur demander de l’aide ci-dessous !

  • help wanted problèmes sont pour ceux un peu plus familiers avec la base de code, mais devraient encore être suffisamment accessibles aux nouveaux venus.

  • Tous les autres problèmes étiquetés kind/<x> ou area/<x> sont également disponibles, mais nécessiteront probablement un bon contexte.

Développer Rancher Turtles

Consultez les notes dédiées pour commencer le développement.

Demander de l’aide

Si vous avez besoin d’aide à n’importe quelle étape de votre travail, n’hésitez pas à demander !

  • Pour obtenir plus de détails sur le problème que vous avez choisi, il est bon de commencer par demander à celui qui l’a créé de fournir plus d’informations.

  • Si vous rencontrez des difficultés pendant que vous travaillez sur votre PR, ou si vous n’êtes pas tout à fait sûr de votre approche, vous pouvez ouvrir un brouillon (préfixez le titre avec WIP:) et expliquer ce que vous pensez.

Directives de soumission de PR

  1. Forkez le dépôt souhaité, développez et testez vos modifications de code.

  2. Poussez vos modifications vers la branche de votre fork et soumettez une demande de tirage au dépôt original contre la branche main.

git push <remote-name> <feature-name>

  1. Soumettez une demande de tirage.

    1. Tout code PR doit être étiqueté avec l’un de

      • ⚠️ (:warning:, changements majeurs ou critiques)

      • ✨ (:sparkles:, ajouts de fonctionnalités)

      • 🐛 (:bug:, correctifs et corrections de bogues)

      • 📖 (:book:, documentation ou propositions)

      • 🌱 (:seedling:, mineur ou autre)

Dans la mesure du possible, veuillez regrouper vos commits pour garantir un historique propre et descriptif.

Si votre PR est encore un travail en cours, veuillez ouvrir un PR en brouillon et préfixer votre titre par le mot WIP. Lorsque votre PR est prête pour révision, vous pouvez changer le titre et supprimer le paramètre de brouillon.

Nous vous recommandons de rebaser régulièrement à partir de main du dépôt original pour garder votre branche à jour.

En général, nous fusionnerons une PR une fois qu’un mainteneur l’aura examinée et approuvée. Les changements triviaux (par exemple, corrections d’orthographe) peuvent être acceptés sans examen. Pour des changements substantiels, plus de personnes peuvent être impliquées, et il se peut que l’on vous demande de soumettre à nouveau la PR ou de diviser les changements en plusieurs PR.

Formatage des messages de commit

Pour en savoir plus sur la façon d’écrire d’excellents messages de commit, et pourquoi vous devriez le faire, consultez cet excellent article de blog.

Nous suivons une convention approximative pour les messages de commit qui est conçue pour répondre à trois questions : qu’est-ce qui a changé, pourquoi le changement a-t-il été effectué, et comment l’avez-vous fait.

La ligne de sujet doit comporter le quoi et le corps du commit doit décrire le pourquoi et le comment. Si vous avez rencontré des bizarreries en cours de route, c’est un bon endroit pour noter ce que vous avez découvert et comment vous l’avez résolu.

Le format peut être décrit plus formellement comme suivant :

<short title for what changed>
<BLANK LINE>
<why this change was made and what changed>
<BLANK LINE>
<any interesting details>
<footer>

La première ligne est le sujet et ne doit pas dépasser 70 caractères, la deuxième ligne est toujours vide, et les autres lignes doivent être limitées à un maximum de 80 caractères. Cela permet au message d’être plus facile à lire sur GitHub ainsi que dans divers outils git.

Il existe un modèle recommandé à utiliser ici.

Comment les Mainteneurs traitent les contributions

Priorisation des problèmes

L’équipe centrale traite régulièrement les problèmes entrants. Il peut y avoir un certain retard pendant les périodes de vacances.

Chaque problème se verra attribuer une étiquette priority/<x>. Les niveaux de priorité sont :

  • critical-urgent: Ce sont des problèmes sensibles au temps qui doivent être pris en charge immédiatement. Si un problème étiqueté critical n’est pas attribué ou sur lequel aucun travail actif n’est effectué, on s’attend à ce que quelqu’un interrompe immédiatement ce qu’il fait pour s’en occuper. Cela signifie généralement l’équipe centrale, mais les membres de la communauté sont invités à prendre en charge les problèmes, quel que soit leur niveau de priorité, s’ils se manifestent en premier. Cependant, compte tenu du délai pressant, si un contributeur non central demande à être assigné à un problème critical, il sera associé à un membre de l’équipe centrale pour gérer le suivi, la communication et la publication de toute correction, ainsi que pour assumer la responsabilité de l’ensemble des progrès réalisés.

  • important-soon: Doit être attribué dès qu’une capacité est disponible. Idéalement, quelque chose devrait être livré à temps pour la prochaine version.

  • important-longterm: Important à long terme, mais pouvant ne pas être actuellement pourvu en personnel et/ou nécessiter plusieurs versions pour être finalisé.

  • backlog: Il semble y avoir un accord général sur le fait que cela serait bon à avoir, mais nous n’avons peut-être personne disponible pour y travailler en ce moment ou dans un avenir immédiat. Les PR sont toujours les bienvenus, bien que cela puisse prendre un certain temps pour les faire examiner si les examinateurs sont entièrement occupés par des problèmes de priorité plus élevée, par exemple juste avant une version.

Ces catégories de priorité ont été inspirées par le guide de contribution de Kubernetes.

D’autres étiquettes incluent a:

  • adr-required: Indique que le problème ou la PR contient une décision qui doit être documentée dans un ADR avant qu’il puisse être travaillé.

  • needs-investigation: Il y a actuellement des informations insuffisantes pour soit catégoriser correctement, soit comprendre et mettre en œuvre une solution. Cela pourrait être dû au fait que l’initiateur du problème n’a pas fourni suffisamment d’informations pertinentes, ou parce qu’une recherche plus approfondie est nécessaire avant que le travail puisse commencer.

Révision des PR

L’équipe centrale vise à vider la file d’attente des PR aussi rapidement que possible. Les membres de la communauté devraient également se sentir libres de garder un œil sur les choses et de fournir leurs propres réflexions et leur expertise.

Les contributions de grande valeur et/ou de haute priorité seront traitées aussi rapidement que possible, tandis que celles de moindre priorité ou optionnelles pourraient prendre un peu plus de temps pour être approuvées.

Pour faciliter une révision plus fluide et plus rapide, suivez les directives ci-dessus. Les soumissions qui ne répondent pas aux normes seront dépriorisées pour la révision.

ADRs (Registres de Décision Architecturale)

N’hésitez pas à sauter ceci et sous-section ci-dessous, car ils ne sont pertinents que pour le dépôt rancher-turtles.

Toute décision impactante sur l’architecture, le design, le développement et le comportement des rancher-turtles doit être enregistrée sous la forme d’un ADR.

Un modèle peut être trouvé à docs/adr/0000-template.md du dépôt, avec de nombreux exemples d’ADR complétés dans le même répertoire.

Les contributeurs sont également invités à compléter les ADR s’ils sont jugés manquants.

Processus

  1. Démarrez une nouvelle discussion en utilisant la catégorie ADR.

  2. Choisissez un titre approprié, clair et concis (par exemple, ADR: Implement X in Go).

  3. Fournissez un contexte de la décision à prendre. Décrivez les différentes options, s’il y en a plus d’une, et expliquez les avantages et les inconvénients. Mettez en évidence les domaines sur lesquels vous aimeriez que les réviseurs prêtent attention, ou ceux sur lesquels vous aimeriez spécifiquement un avis.

  4. Taguez dans les mainteneurs comme les "Décideurs", et invitez-les à participer et à peser sur la décision et ses conséquences.

  5. Une fois qu’une décision a été prise, ouvrez une PR ajoutant un nouvel ADR au répertoire. Copiez et complétez le modèle;

    • Incrémentez le numéro de fichier de 1

    • Définissez le statut sur "Accepté"

    • Définissez les décideurs comme ceux qui ont approuvé le résultat de la discussion

    • Résumez la décision et les conséquences du fil de discussion

    • Faites le lien avec le fil de discussion depuis le document ADR