Projet Linux Foundation

Cette page contient les détails d'un projet de rédaction technique accepté pour la saison des documents Google.

Résumé du projet

Organisation Open Source:
The Linux Foundation
Rédacteur technique:
jaskiratsingh2000
Nom du projet:
CHAOSS: créer un manuel de la communauté CHAOSS
Durée du projet:
Durée standard (trois mois)

Project description

EXTRAIT DU PROJET:

Actuellement, les groupes de travail de la communauté CHAOSS ont développé leurs propres méthodes de travail et documenté leurs processus disparates à des degrés divers. Les groupes de travail incluent les groupes de travail sur les métriques communes, la diversité et l'inclusion, l'évolution, les risques et la valeur, qui ont défini leurs propres modes de participation et de travail, et adapté différents modes de communication et de culture du travail. Ces groupes de travail, conformément aux métriques, ont des domaines d'intérêt et des antécédents différents, ce qui fonctionne pour les métriques appropriées. Ils mènent diverses recherches et développements dans la catégorie de groupes de travail respectifs et connaissent le bon chemin à suivre pour mener diverses recherches et développements dans les catégories respectives. Toutefois, les processus pour les nouveaux arrivants et les contributeurs existants peuvent ne pas être connus pour savoir comment participer ou suivre le bon chemin pour les travaux respectifs.

Par conséquent, les éléments de la communauté CHAOSS ne sont pas standardisés. Par conséquent, pour connaître le processus approprié et les principes de base de la culture du travail au sein de la communauté, l'objectif du manuel de la communauté est de centraliser les informations essentielles et de les standardiser dans le cadre du projet CHAOSS. Les informations essentielles et la partie sur la standardisation se concentrent principalement sur les processus utilisés par CHAOSS afin que CHAOSS puisse s'entendre sur la manière dont la communauté accomplit son travail, comment les nouveaux membres peuvent participer et suivre les principes fondamentaux de la communauté, et quels processus et parcours les nouveaux membres ou les membres existants doivent suivre pour accéder au leadership au sein de la communauté CHAOSS.

Le manuel doit servir de manuel d'instructions aux membres existants et nouveaux de la communauté pour savoir comment travailler sur le projet CHAOSS. Ce projet implique un volet créatif consistant à collecter et à organiser le contenu du manuel, ainsi qu'un volet technique consistant à définir comment le représenter.

POURQUOI ?

Le manuel de la communauté est un document qui définit les règles et procédures clés de la communauté, et décrit sa mission, ses valeurs et son fonctionnement.

Ce manuel fournit une présentation claire et détaillée du fonctionnement de la communauté pour les nouveaux membres. Actuellement, le manuel de la communauté CHAOSS est disponible sur le dépôt GitHub. Il doit être remanié et refactorisé pour fournir plus d'informations aux nouveaux utilisateurs et aux membres existants de la communauté. Ce manuel, qui s'adresse à l'ensemble de la communauté CHAOSS, aidera les nouveaux membres et les membres existants de la manière suivante:

  • Formalisation et organisation des règles de la communauté CHAOSS, en les regroupant au même endroit
  • Présenter l'introduction, la mission, la vision et le leadership de la communauté
  • Comprendre les pratiques de la communauté CHAOSS
  • Consignes de contribution
  • Définir les workflows de projet
  • Présentation de la culture de la communauté CHAOSS
  • Questions fréquentes générales
  • Parrainage

DESCRIPTION DU PROJET:

Le manuel de la communauté sera divisé en plusieurs sections contenant des informations détaillées et adaptées à des sujets spécifiques. Les sections peuvent être divisées comme suit:

  • Introduction
  • La communauté CHAOSS
  • Chemin vers le leadership
  • Terminologie
  • Consignes pour les contributions
    • Développeur
    • Graphiste
    • Rédacteur
    • Responsable marketing
  • Métriques
  • CHAOSScon
  • CHAOSScast
  • Vidéos de réunion
  • Questions fréquentes générales
  • Parrainage
    • Google Summer of Code
    • Outreachy
    • Google Season of Docs

LIVRABLES DETAILLES DU PROJET

1.) Introduction :

Cette section constituera la première page du manuel de la communauté CHAOSS et en présentera les détails, la présentation et l'utilisation du manuel. Voici les éléments ci-dessous:

A.) Il contiendra le message de bienvenue ainsi qu'une brève description de la communauté CHAOSS, qui devrait convaincre les lecteurs de lire le manuel. Je vais également inclure le collage d'images provenant de https://chaoss.community/chaoss-photo-album/, qui met en avant les différents mouvements au sein de la communauté. B.) Cette page contient également des informations détaillées sur toutes les sections, avec une description sur une ligne qui explique chacune d'entre elles, ainsi que les liens appropriés. C.) Utilisation du manuel: l'utilisation du manuel existe déjà ici( shorturl.at/cqQU6), mais je vais remanier et refactoriser l'utilisation existante du manuel avec un meilleur markdown, qui comprendra le flux du manuel(j'expliquerai comment les choses se passent lorsqu'une personne souhaite ajouter, supprimer ou discuter des éléments liés au manuel. Il peut suivre le processus de communication pour toute question liée au manuel.), Consignes du manuel(qui incluent son utilisation au sein de la communauté et son champ d'application), contribution au manuel ( qui explique comment utiliser le dépôt pour apporter des modifications, créer des PR, le modèle à suivre pour apporter des modifications au manuel et au guide de style) et partage de commentaires sur le manuel. Dans la section "Partager des commentaires", je vais inclure un modèle et différentes façons dont les utilisateurs peuvent nous contacter pour nous envoyer des problèmes GitLab ou les utiliser pour les recevoir.

2.) La communauté CHAOSS:

Le mode de fonctionnement de la communauté CHAOSS est important pour que les utilisateurs comprennent les pratiques et les consignes de la communauté. Les workflows pourraient le mettre en avant et décrire au mieux les pratiques de la communauté. Cette section comprend les éléments suivants:

A.) Valeurs générales: description de la façon dont le développement durable, l'ouverture et la transparence sont gérés au sein de la communauté CHAOSS. Je vais expliquer comment les nouveaux utilisateurs ou les utilisateurs existants doivent les comprendre et les prendre en compte lorsqu'ils travaillent avec la communauté. B.) Règlement de la communauté: il explique comment s'impliquer dans la communauté CHAOSS et respecter les conditions de base. Cela expliquera également la culture de travail suivie au sein de la communauté. (bonnes pratiques et choses à éviter). Il comprendra la liste de contrôle des principaux contributeurs/maintenants, ainsi que pour les informer des autres qu’ils doivent savoir comment travailler avec les responsables et quelles sont leur liste de contrôle. C.) Groupes de travail: cette page( https://chaoss.community/participate/ ) contient des informations sur les groupes de travail, comme la description du groupe, le lien vers le dépôt et les informations sur les réunions. Dans le manuel, je vais expliquer comment participer aux différents groupes de travail, comprendre le processus d'évaluation des métriques, comprendre la culture de travail du groupe de travail concerné et devenir un contributeur principal pour différents groupes de travail.

3.)  Chemin vers le leadership:

Devenir leader d'un projet Open Source peut être essentiel à la réussite d'une communauté dans le monde commercial. Je vais donc inclure les éléments suivants:

A.) Leadership technique: il s'agit des processus et des responsabilités des responsables de dépôt, des rédacteurs de documentation et des responsables du site Web. B.) Leadership en matière de gouvernance: il s'agira des parcours pour les membres du conseil d'administration et le décisionnaire C. Leadership opérationnel: il s'agit du parcours des community managers.

4.) Terminologie :

La terminologie aiderait à décrire les termes et les biens respectifs utilisés fréquemment au sein de la communauté CHAOSS. De plus, je vais également inclure les consignes d'utilisation de la terminologie, comme les majuscules, les abréviations et les mots à éviter, avec les raisons. Les termes suivants seront inclus : projet CHAOSS, santé communautaire Open Source, revue de code, groupe de travail, métrique logicielle Open Source, métrique commune, métrique de diversité et d'inclusion, groupe de travail sur l'évolution, groupe de travail sur les risques, groupe de travail sur la valeur, publication des métriques, domaine d'action.

5.) Consignes de contribution:

Il s'agit du contexte principal de toute communauté Open Source, car la plupart d'entre elles dépendent des contributions ou du travail bénévole. Cela aidera tout nouveau venu ou utilisateur à comprendre les nécessités de base et les consignes qu'il doit suivre. Vous devez donc inclure les informations suivantes:

A.) Comprendre la feuille de route de la communauté: ce sujet présente la feuille de route de la communauté CHAOSS, qui aidera les utilisateurs à savoir quelle voie ou quel processus suivre pour donner la priorité aux différents fonctionnements du projet CHAOSS. B.) Expliquer les éléments nécessaires pour contribuer de manière pratique, comme le développement, la documentation, la conception, les tests, etc. Donner un bref aperçu du fonctionnement de GitLab D.) Guide des examinateurs/des responsables

Cette section comprend également les "Rôles et responsabilités" de chaque catégorie de contribution, qui sont indiqués ci-dessous:

a.) CONCEPTION: cette sous-section inclura le flux de travail de conception CHAOSS et les consignes de conception qui contiennent les principes de conception, le processus et les outils utilisés que les contributeurs doivent suivre pour contribuer au domaine de la conception. b.) DÉVELOPPEMENT: ce dossier contient le guide de contribution au codebase. Il contiendra les exigences techniques, la structure du projet, la configuration du projet(Augur, Cregit, GremoireLab, etc.). DOCUMENTATION: cela comprendra les ressources de documentation, y compris les outils et le guide de style. d.) RÉPONSE : Cela inclura la façon dont les contributeurs peuvent aider la communauté CHAOSS à développer sa visibilité : écrire des blogs, utiliser des identifiants sur les réseaux sociaux, organiser des rencontres et des événements

6.) Métriques

Actuellement, le site Web de la communauté CHAOSS contient les informations sur les versions de métriques( https://chaoss.community/metrics/ ). Il est plus important que les utilisateurs comprennent comment suivre la procédure pour rendre leur site Web de métriques disponible sur ce site. Cette section présente les informations qui aideront les utilisateurs à connaître les processus et le fonctionnement pour créer leur propre version de métrique.

7.) CHAOSScon:

Les informations sur CHAOSScon existent déjà sur GitHub( https://github.com/chaoss/governance/blob/master/community-handbook/chaosscon.md) et sur le site Web( https://chaoss.community/CHAOSScon-2020-NA/ ), mais il est plus logique d'ajouter les détails et les informations expliquant les processus et les méthodes de gestion de CHAOSScon dans le manuel. Le manuel contient les informations suivantes:

A.) Informations sur le comité d'organisation: il explique comment participer au comité d'organisation de CHAOSScon.B.) Gestion du processus d'appel à propositions: cette tâche comprend la gestion de l'inscription des auteurs, la soumission des propositions et de la documentation, l'examen et le processus d'approbation. C.) Gestion et publication du programme CHAOSScon D.) Comment gérer les éléments liés à la publicité et au marketing E.) Gérer les propositions de sponsoring et les fonds, y compris les packages

8.) CHAOSScast:

Vous trouverez des informations sur CHAOSScast sur la page https://github.com/chaoss/governance/blob/master/community-handbook/chaosscast.md. Elles seront incluses dans le manuel avec des informations supplémentaires, comme la participation, le comité d'organisation, la publicité et les supports marketing.

9.) Vidéos de réunions:

Il contient toutes les vidéos de réunions passées et disponibles sur YouTube, ainsi que leur description (participants, ordre du jour, etc.).

10.) Questions fréquentes générales:

Elles contiennent les questions générales les plus courantes posées dans la communauté. Elles aideront les nouveaux membres et les membres existants à y répondre.

11.) Google Summer of Code:

Cette section contient des informations sur le Google Summer of Code, les critères d'éligibilité et les modalités de participation de la communauté CHAOSS au Google Summer of Code. Cette section contiendra également le modèle de proposition que les personnes pourront utiliser pour rédiger leur proposition, ainsi que leurs rôles et responsabilités. De plus, il contiendra également les informations qui aideront les membres existants de la communauté à découvrir comment devenir administrateur de l'organisation et mentor.

  1. Actions publiques:

Cette section contient des informations sur Outreachy, les critères d'éligibilité et la façon dont les membres de la communauté CHAOSS peuvent participer à Outreachy.Elle présente les rôles et les responsabilités, y compris la procédure à suivre pour devenir administrateur de l'organisation et mentor.

  1. Saison de Google Docs:

Cette section contient des informations sur le GSoD, les critères d'éligibilité et la manière dont les membres de la communauté CHAOSS peuvent participer au GSoD. Il contient les rôles et les responsabilités, y compris la procédure à suivre pour devenir administrateur de l'organisation et mentor.

RÉSULTAT ATTENDU DU PROJET:

Les manuels jouent un rôle important dans toute communauté. De même, ce manuel pour l'ensemble de la communauté CHAOSS permettra d'obtenir une documentation plus organisée et détaillée pour la communauté CHAOSS. Il serait facile pour tout nouveau membre qui rejoint la communauté, ainsi que pour les membres existants, de comprendre les principes fondamentaux et le fonctionnement de la communauté CHAOSS. De plus, ce manuel présentera les différents processus et chemins vers les différentes cultures de travail au sein de la communauté CHAOSS.

DÉTAILS TECHNIQUES:

Je propose d'utiliser la plate-forme Gitbook pour la gestion du manuel, car il s'agit d'un projet collaboratif et convivial qui permet aux équipes de travailler plus efficacement. Voici quelques-unes des fonctionnalités de la plate-forme GitBook:

  • WYSIWYG: éditeur de texte puissant et élégant
  • Markdown: prise en charge efficace et productive des raccourcis Markdown
  • Intégration enrichie: permet d'intégrer du contenu Web externe, comme des vidéos, des extraits de code, des articles, de la musique, etc.
  • Tableaux de bord pour les rédacteurs: proposez un tableau de bord intelligent pour les rédacteurs, compatible avec l'édition visuelle.
  • Brouillons: créez des modifications et collaborez de manière asynchrone
  • Commentaires d'assistance: discuter et examiner les suggestions de modifications
  • Suivre l'historique de l'écriture: suivez tout. Examiner et annuler les modifications
  • Insights: il est également compatible avec les insights qui permettent de suivre le trafic, les notes et la qualité des contenus
  • GitHub Sync: conserver le workflow et continuer à synchroniser les documents avec GitHub
  • Branding de la personnalisation: domaines personnalisés, logos personnalisés, polices, couleurs, thèmes, en-têtes, etc.

Voici quelques images qui donnent un aperçu de la plate-forme

  • shorturl.at/GNQR4
  • shorturl.at/gATZ8
  • shorturl.at/qrE57
  • shorturl.at/rFRX6
  • shorturl.at/eyLW1
  • shorturl.at/rwHS8

-- Où le manuel sera-t-il hébergé ?

Le manuel sera hébergé sur GitBook lui-même, où GitHub fournit un mécanisme approprié pour le domaine personnalisé, les erreurs courantes et le référencement.

Domaines personnalisés : si la communauté CHAOSS souhaite l'héberger sur un domaine personnalisé, elle s'affichera sous la forme docs.chaoss.community. L'organisation n'a besoin que de créer le sous-domaine souhaité. Pour configurer le domaine de l'organisation, accédez aux paramètres de l'organisation sur la plate-forme Gitbook. Exemple d'image: shorturl.at/GNQR4

Les espaces GitBook sont diffusés via notre propre CDN, avec HTTPS activé par défaut. Les certificats sont émis par LetsEncrypt.

Domaines compatibles:

  • Sous-domaine: www.example.com
  • Domaine personnalisé: docs.example.com

-- Comment synchroniser Gitbook avec GitHub pour que les modifications puissent être effectuées efficacement sur les deux plates-formes ?

L'intégration avec GitHub est très facile à utiliser: si un utilisateur modifie du contenu sur GitBook, ses modifications sont transférées vers un dépôt GitHub. À l'inverse, les commits transférés vers un dépôt GitHub sont importés dans le GitBook.

Configurez l'intégration GitHub:

  • Depuis votre espace de la plate-forme GitBook, cliquez sur l'onglet Intégrations > GitHub.
  • Autoriser GitBook à accéder à votre compte GitHub associé à votre organisation
  • Accédez à GitHub de votre organisation et créez un dépôt pour le "manuel", par exemple chaoss-handbook.
  • Sélectionnez maintenant le dépôt nommé chaoss-handbook que vous souhaitez connecter dans l'option d'autorisation de la plate-forme GitBook.

Une fois ces étapes effectuées, GitBook ajoutera un webhook au dépôt chaoss-handbook qui lui permettra de récupérer le contenu à chaque modification apportée au dépôt. Lorsque vous modifiez GitBook, un nouveau commentaire est envoyé.

Et voilà ! Tout le monde peut continuer à apporter des modifications à partir du dépôt GitBook ou GitHub.

-- Comment modifier des pages sur la plate-forme GitBook ?

Toute personne qui souhaite modifier un élément sur la plate-forme GitBook doit y accéder à l'aide d'une invitation ou d'un lien d'accès. GitBook prend en charge l'édition visuelle permettant aux utilisateurs d'écrire directement dans les pages.

Un brouillon est une version modifiable du contenu utilisateur qui n'est accessible qu'aux rédacteurs. Il est créé automatiquement lorsque vous commencez à écrire (première lettre dans l'éditeur, création d'une page, importation d'une image, etc.).

Les modifications apportées à un brouillon lui sont propres, ce qui permet aux utilisateurs de contribuer simultanément au même document avec d'autres membres sans créer de conflits. C'est ce que nous appelons la modification asynchrone et la résolution des conflits.

La première version du brouillon n'est pas toujours prête à être publiée immédiatement. Utilisez ""Enregistrer"" lorsque vous souhaitez poursuivre votre travail plus tard ou si votre contenu n'est pas encore prêt à être ""fusionné"".

Lorsque vous avez terminé, vous pouvez ""fusionner"" votre brouillon. Le contenu que vous avez rédigé ou les modifications que vous avez apportées seront alors disponibles pour les membres de votre équipe et/ou seront publics.

Exemples d'images: shorturl.at/gATZ8 et shorturl.at/qrE57

-- Structure du contenu:

Sommaire: chaque espace peut contenir autant de pages que vous le souhaitez pour rédiger votre documentation. Toutes ces pages sont visibles sur le côté gauche de votre écran, dans ce que nous appelons la table des matières. Dans la table des matières, vous pouvez gérer vos pages: créer des pages, des groupes de pages, ajouter des liens externes, ajouter une variante, importer des documents externes tels que des sites Web ou des fichiers au format Markdown (.md ou .markdown), HTML (.html) ou Microsoft Word (.docx).

Page initiale: la page initiale est la page d'accueil ou la racine de votre documentation. Elle sert de page maître à toutes les autres pages de votre documentation. Étant donné qu'elle constitue l'entrée principale de votre documentation et de votre espace, cette page ne peut pas être déplacée, supprimée, avoir de sous-pages ni être rattachée à un groupe.

Pages: une page comporte un titre et une description facultative en haut de l'éditeur. Vous pouvez ensuite y écrire et y ajouter n'importe quel type de contenu.Vous pouvez imbriquer des pages en les faisant glisser sous une autre. Les enfants d'une page sont masqués, mais peuvent être réduits.

Liens externes: ces entrées sont des liens externes dont le contenu n'est pas indiqué dans l'éditeur. Leur fonction principale est de créer des liens vers des sites Web externes.

Variantes: vous pouvez créer un contenu alternatif à votre documentation en créant une variante. Cela peut être utile pour documenter plusieurs versions d'une API, d'une bibliothèque ou de traductions.

Exemple d'image: shorturl.at/eyLW1 et shorturl.at/rFRX6

-- Comment le Manuel sera-t-il présenté côté client ?

Le manuel de la communauté Chaoss sera accessible via un sous-domaine, qui peut être https://docs.chaoss.community. Il se présentera comme suit pour l'utilisateur:

  • Manuel Mattermost : https://handbook.mattermost.com/
  • Documentation du pont de la communauté Linux Foundation : https://docs.linuxfoundation.org/docs/ Et bien d'autres

CALENDRIER DU PROJET:

1.) Phase de renforcement des liens au sein de la communauté (17 août - 13 septembre)

A.) Semaines 1 à 4:

  • Discuter du projet avec des mentors
  • Rechercher et recueillir les informations nécessaires pour les différentes sections du projet, poser des questions de clarification à la communauté
  • Demandez à la communauté quelle plate-forme utiliser pour le manuel (je suggère GitBook) et configurez-la
  • Signaler des problèmes liés à la documentation

2.) Phase de développement du document (14 sept. – 30 nov.)

A.) Semaine 5 (14 sept. – 20 sept.)

  • Section d'introduction de la version préliminaire

B.) Semaine 6 (21 sept. – 27 sept.)

  • Brouillon de la section "La communauté CHAOSS"

C.) Semaine 7 (28 sept. – 4 oct.)

  • Rédiger la section « Path to Leadership »
  • Rédiger la section "Terminologie"

D.) Semaine 8 (5 oct. - 11 oct.)

  • Élaborer la feuille de route de la communauté
  • Consignes provisoires pour les contributions de conception

E.) Semaine 9 (12-18 octobre)

  • Section "Développement du brouillon"

F.) Semaine 10 (19-25 octobre)

  • Consignes concernant la section Rédaction et Communication

G.) Semaine 11 (26 octobre – 1er novembre)

  • Section "Métriques" provisoire
  • Section "Brouillon de CHAOSScon"

H.) Semaine 12 (2 nov. – 8 nov.)

  • Section "Préparer la réunion"

  • Draft General FAQs of community

    I.) Semaine 13 (9-15 nov.)

  • Draft about GSoC Guidelines

J.) Semaine 14 (16 nov. – 22 nov.)

  • Draft about Outreachy Guidelines

K.) Semaine 15 (23-29 nov.)

  • Temps de mise en mémoire tampon : peaufiner et améliorer l'ensemble de la documentation

3.)  Phase d'évaluation (30 novembre - 5 décembre)

A.) Semaine 16:

  • Rédiger un rapport de projet
  • Remplir l’évaluation pour le projet

INTERACTIONS AVEC LA COMMUNAUTÉ

1.) Participation et discussions avec la communauté.

Je suis membre de la communauté CHAOSS depuis avril 2020 et j'ai participé à diverses discussions avec les membres de la communauté et avec mes mentors de projet( Georg Link et Armstrong Foundjem). L'une de ces discussions qui a suscité un plus grand intérêt de la part des membres de la communauté était "Proposing Gitbook as a platform for hosting Community Handbook" (Proposer Gitbook comme plate-forme d'hébergement du manuel de la communauté). Vous pouvez la retrouver dans le fil de discussion de la liste de diffusion d'archives CHAOSS, intitulé "Proposing Gitbook as a platform for hosting Community Handbook". J'ai également participé aux appels hebdomadaires de la communauté, ce qui m'a aidé à la tenir au courant.

2.) Comment allez-vous collecter les informations requises pour ce projet ?

Étant donné que ce projet nécessite la mise en place d'un manuel à l'échelle de la communauté, les informations qui doivent être consultées dans celui-ci seront collectées auprès des membres de la communauté et discutées avec elles. Comme je l'ai indiqué ci-dessus, je pourrai discuter et recueillir les informations nécessaires pendant la période d'intégration à la communauté.

Je ferai des recherches sur les différentes sections conformément à CHAOSS et je maintiens les fils de discussion sur la liste de diffusion. J'essaierai de poser des questions de clarification à mes mentors et à la communauté en fonction des exigences.

Pour des discussions concises, je participerai également à des appels hebdomadaires.

3.)  Comment comptez-vous tenir la communauté au courant de votre progression, ainsi que des problèmes ou questions que vous pourriez rencontrer au cours du projet ?

Pour plus de flexibilité et de transparence, je vais essayer de communiquer via la discussion de la liste de diffusion pour poser mes questions.

Je publierai mes progrès hebdomadaires dans un article de blog qui inclura la documentation Scrum et les défis auxquels il a été confronté. Il sera publié sur la liste de diffusion de la communauté afin de toucher une audience plus large au sein de l'organisation Open Source.

Je participerai également aux appels hebdomadaires de la communauté afin de recevoir des suggestions et de discuter des principaux problèmes.

Je prévois également de créer un tableau Trello avec les tâches hebdomadaires disponibles. Les mentors peuvent ensuite utiliser ce tableau pour avoir une compréhension claire et concise des problèmes actuels et des fonctionnalités qui sont traitées.

4.) Que ferez-vous si vous restez bloqué dans votre projet et que votre mentor n'est pas là ?

Je pense que le rôle du mentor est de guider les élèves dans la bonne direction et non de leur expliquer chaque recoin des boucles. La recherche et la mise en œuvre du projet relèvent de la seule responsabilité de l'étudiant. Je n'essaierai donc de demander l'aide de mon mentor qu'en dernier recours.

Toutefois, si le mentor n'est pas disponible ou est occupé au moment où j'ai besoin d'aide, je vais partager le problème que je rencontre avec la communauté CHAOSS. Je suis sûr que quelqu'un pourra m'aider à relever les défis que je rencontrerai. Je vais également partager le problème sur des forums en ligne/communautés de développeurs comme dev.to

De plus, j'essayais de participer à des appels hebdomadaires à l'aide de la communauté CHAOSS afin de poser mes questions.