Progetto Linux Foundation

Questa pagina contiene i dettagli di un progetto di scrittura tecnica accettato per Google Season of Docs.

Riepilogo del progetto

Organizzazione open source:
La base di Linux
Technical writer:
jaskiratsingh2000
Nome progetto:
CHAOSS: crea un manuale CHAOSS per la community
Durata del progetto:
Durata standard (3 mesi)

Project description

SINTESI DEL PROGETTO:

Attualmente, i gruppi di lavoro della comunità CHAOSS hanno sviluppato il proprio modo di lavorare e documentato i diversi processi in varie misura. I gruppi di lavoro includono gruppi di lavoro sulle metriche comuni, gruppo di lavoro su diversità e inclusione, gruppi di lavoro su evoluzione, rischi e valore, che hanno definito modalità di partecipazione e lavoro e adattato diversi modi di comunicazione e cultura del lavoro. Questi gruppi di lavoro, in base alle metriche, hanno aree di interesse e background diversi, che lavorano per metriche appropriate conducono varie ricerche e sviluppi nella rispettiva categoria di gruppi di lavoro e conoscono il percorso giusto per condurre varie ricerche e sviluppi nelle rispettive categorie, ma i processi per i nuovi arrivati e i collaboratori esistenti potrebbero non sapere come partecipare o intraprendere la strada giusta per i rispettivi lavori.

Il risultato è che tutto ciò che fa parte della comunità CHAOSS non è standardizzato. Pertanto, per conoscere il processo giusto e gli elementi fondamentali della cultura del lavoro in tutta la comunità, l'obiettivo del manuale è quello di centralizzare le informazioni critiche e standardizzarne parti in tutto il progetto CHAOSS. Le parti fondamentali delle informazioni e della standardizzazione si concentrano principalmente sui processi utilizzati da CHAOSS in modo che CHAOSS abbia un accordo sulle modalità di svolgimento del lavoro della comunità, su come i nuovi arrivati possono partecipare e seguire i fondamenti della community e sui processi e percorsi che i nuovi arrivati o i membri esistenti devono seguire per assumere la leadership all'interno della comunità CHAOSS.

Questo manuale deve fungere da manuale per i membri esistenti e nuovi della comunità su come svolgere il lavoro nel progetto CHAOSS. Questo progetto prevede un componente creativo per la raccolta e l'organizzazione dei contenuti per il manuale, nonché un componente tecnico per la definizione di come rappresentare il manuale.

QUAL È LA NECESSITÀ?

Il Manuale della comunità è un documento che definisce le politiche e le procedure chiave della comunità e ne delinea la missione, i valori e il lavoro.

Questo manuale offre un'introduzione e un funzionamento chiari ai nuovi membri della comunità. Attualmente, il manuale della community CHAOSS è disponibile sul repository GitHub e deve essere rinnovato e rielaborato con maggiori informazioni per i nuovi arrivati e gli utenti esistenti della community. Quindi questo manuale CHAOSS a livello di community aiuterà i nuovi arrivati e i membri esistenti della community nei seguenti modi:

  • Formalizzare e organizzare le norme della community CHAOSS, riunendole tutte in un unico posto
  • Comunicare l'introduzione, la missione, la visione e la leadership della comunità
  • Comprendere le pratiche della community CHAOSS
  • Linee guida per i contributi
  • Definizione dei flussi di lavoro del progetto
  • Definizione della cultura della comunità CHAOSS
  • Domande frequenti generali
  • Mentoring

DESCRIZIONE PROGETTO:

Il Manuale della community sarà suddiviso in varie "Sezioni" che contengono informazioni appropriate e dettagliate su determinati argomenti. Le sezioni possono essere suddivise nei seguenti modi:

  • Introduzione
  • Lo stile della community CHAOSS
  • Il percorso verso la leadership
  • Terminologia
  • Linee guida per i contributi
    • Sviluppatore
    • Designer
    • Writer
    • Professionista del marketing
  • Metriche
  • CHAOSScon
  • CHAOSScast
  • Video delle riunioni
  • Domande frequenti di carattere generale
  • Tutoraggio
    • Summer of Code di Google
    • Pubblico
    • La stagione dei documenti Google

PROGETTI FORNITI DETTAGLIATI

1. Introduzione:

Questa sezione fungerà da prima pagina del Manuale della community CHAOSS e tratterà i dettagli, la panoramica e l'utilizzo del manuale. Ecco quanto segue:

A.) Conterrà il messaggio di benvenuto con una breve descrizione della community CHAOSS che aiuterebbe a convincere i lettori a leggere il manuale. Includo anche il collage di immagini tratte da qui https://chaoss.community/chaoss-photo-album/ che evidenzierà i vari movimenti all'interno della community. B.) La pagina conterrà anche i dettagli di tutte le sezioni con una descrizione di ogni sezione e i link appropriati. C.) Utilizzo del manuale: l'uso del manuale esiste già qui( Shorturl.at/cqQU6 ) ma rinnoverò e refactoring l'uso esistente del manuale con una migliore Markdown, che includerà il flusso del manuale(includerò il modo in cui qualcuno vuole aggiungere, rimuovere o discutere di cose relative al manuale.) Potrebbe seguire il processo di comunicazione per qualsiasi argomento relativo ai manuali.), Linee guida del manuale(che comprende il suo utilizzo all'interno della community e dell'ambito), Contributo al manuale ( che include l'utilizzo del repository per apportare modifiche, creare PR, Modello da seguire per apportare modifiche al Manuale e alla Guida di stile) e Condivisione di feedback sul Manuale. All'interno di Condivisione del feedback, includo un modello e diversi modi in cui gli utenti possono rispondere per fornire o utilizzare i problemi di GitLab per riceverlo.

2. Lo stile della community CHAOSS:

Lo stile della community CHAOSS sarà fondamentale per comprendere le prassi e le linee guida della community. Workflows potrebbe metterlo in maggiore risalto e delineare le prassi della comunità nel modo migliore. Questa sezione include quanto segue:

A.) Valori generali: definizione di come la sostenibilità, l'apertura e la trasparenza vengono gestite all'interno della community CHAOSS. Spiegherò questi valori secondo cui i nuovi utenti o quelli esistenti dovrebbero comprenderli e tenerli in considerazione durante l'interazione con la community. B.) Norme della community: indicano in che modo ci si dovrebbe effettivamente istruire nella community CHAOSS e seguire i termini di base. Così facendo, spiegheremo anche la cultura del lavoro seguita all'interno della comunità. (Cosa fare e cosa non fare). Includerà l'elenco di controllo per i collaboratori principali/gestori di manutenzione e per far loro sapere agli altri che dovrebbero lavorare con i gestori e quali sono il loro elenco di controllo. C.) Gruppi di lavoro: questa pagina( https://chaoss.community/participate/ ) contiene informazioni sui gruppi di lavoro, come Descrizione del gruppo di lavoro, link al repository e informazioni sulla riunione, ma all'interno del manuale spiegherò come partecipare ai diversi gruppi di lavoro e comprendere il processo di valutazione delle metriche, comprendere la cultura del lavoro per i rispettivi gruppi di lavoro e come diventare i collaboratori principali dei diversi gruppi di lavoro.

3. Il percorso verso la leadership:

Sebbene acquisire la leadership in un progetto open source può essere vitale per il successo di una comunità nel mondo commerciale. Tenendo presente questo aspetto, includerò quanto segue:

A.) Leadership tecnica: comprende i processi e le responsabilità dei responsabili del mantenimento del repository, dello scrittore della documentazione e del gestore del sito web B.) Leadership di governance: include i percorsi per il membro del Consiglio di amministrazione e il responsabile delle decisioni C.) Leadership operativi: contiene il percorso per i Community Manager

4. Terminologia:

La terminologia è utile a descrivere i termini e i rispettivi effetti che vengono utilizzati di frequente all'interno della comunità CHAOSS. Inoltre, includerò anche le linee guida per l'utilizzo della terminologia, ad esempio lettere maiuscole, abbreviazioni e parole da evitare con i motivi. I termini che saranno inclusi sono: CHAOSS Project, Open Source Community Health, Code Review, Working Group, Open Source Software Metric, Common Metric, Diversity e Inclusion Metric, Evolution Working Group, Risk Working Group, Value Working Group, Metric Release, Focus Area.

5.) Linee guida per i contributi:

Questo è il contesto principale di qualsiasi community open source poiché la maggior parte di queste dipende dai contributi o dal lavoro di volontariato, quindi questo aiuterà a ogni nuovo utente/utente che si unisce alla community per comprendere le esigenze fondamentali e le linee guida che devono seguire. Saranno quindi inclusi i seguenti dettagli:

A.) Comprensione della Roadmap della Community: Questo argomento porterà a una panoramica della roadmap della comunità CHAOSS che aiuterà gli utenti a sapere quale modo o processo seguire dando priorità alle varie attività all'interno del progetto CHAOSS. B.) Spiegazione degli elementi necessari per fornire concretamente un qualsiasi contributo, ad esempio sviluppo, documentazione, progettazione, test e così via. C.) Faccio una breve panoramica del funzionamento di GitLab D.) Guida per revisori/gestori

Questa sezione conterrà anche i "Ruoli e responsabilità" per ciascuna categoria di contributi riportata di seguito:

a.) DESIGN: questa sottosezione includerà il "Flusso di lavoro della progettazione CHAOSS" e le linee guida di progettazione che conterranno i principi, i processi e gli strumenti utilizzati di progettazione che i collaboratori dovranno seguire mentre apportano il proprio contributo al campo del design. b.) SVILUPPO: contiene la guida per il contributo al codebase. Contiene i requisiti tecnici, la struttura del progetto, la configurazione del progetto(Augur, Cregit, GremoireLab) c.) DOCUMENTAZIONE: includerà risorse per la documentazione, compresi strumenti e guida di stile. d.) CONTATTARE: Ciò includerà il modo in cui i collaboratori possono supportare la comunità CHAOSS nella crescita del contatto: scrivere blog, utilizzare handle social, organizzare incontri ed eventi.

6.) Metriche

Attualmente, il sito web della community CHAOSS contiene informazioni sulle release delle metriche( https://chaoss.community/metrics/ ) ed è più importante che le persone capiscano come seguire la procedura per rendere disponibile il sito web delle metriche su quel sito. Pertanto, questa sezione fornirà le informazioni che aiuteranno gli utenti a conoscere i processi e il funzionamento per avere la propria release delle metriche.

7. CHAOSScon:

Le informazioni su CHAOSScon esistono già su GitHub( https://github.com/chaoss/governance/blob/master/community-handbook/chaosscon.md) e sul sito web( https://chaoss.community/CHAOSScon-2020-NA/ ), ma ha più senso aggiungere dettagli e informazioni che spiegano i processi e le modalità di gestione di CHAOSScon nel Il Manuale conterrà le seguenti informazioni:

A.) Dettagli sul comitato organizzativo: spiegherà le procedure per partecipare al comitato organizzatore del CHAOSScon B. Gestione del processo di invito a presentare proposte: comprende la gestione della registrazione degli autori, l'invio di proposte e della documentazione, del processo di revisione e approvazione. C.) Gestione e pubblicazione del programma CHAOSScon D.) Come gestire gli elementi pubblicitari e di marketing E.) Come gestire le proposte di sponsorizzazione e i fondi, compresi i pacchetti

8. CHAOSScast:

Le informazioni su CHAOSScast sono disponibili qui: https://github.com/chaoss/governance/blob/master/community-handbook/chaosscast.md e saranno incluse nel manuale con alcuni dettagli aggiuntivi, come partecipazione, comitato organizzativo, pubblicità e materiali di marketing.

9. Video delle riunioni:

L'immagine conterrà tutti i video delle riunioni con la relativa descrizione, ad esempio Partecipanti, Programma e così via, che sono accaduti in passato e disponibili su YouTube.

10. Domande frequenti generali:

Contengono le domande generali comuni che vengono poste alla community e aiuteranno i nuovi arrivati e i membri esistenti della community a rispondere ad alcune di queste domande.

11.) Summer of Code di Google:

Questa sezione contiene informazioni sul Summer of Code di Google, sui criteri di idoneità e su come le persone possono partecipare a Google Summer of Code ai sensi della community CHAOSS. Questa sezione conterrà anche il modello di proposta che gli utenti potranno utilizzare per redigere la proposta e i ruoli e le responsabilità. Inoltre, conterranno anche le informazioni che aiuterebbero i membri esistenti della comunità a conoscere il processo per diventare amministratori dell'organizzazione e mentori.

  1. Contatto:

Questa sezione conterrà informazioni sul programma di contatto e sui criteri di idoneità, nonché informazioni su come le persone possono partecipare alla community CHAOSS di Programma un programma.In questa sezione saranno riportati i ruoli e le responsabilità, incluso il processo per diventare amministratore dell'organizzazione e mentori.

  1. La stagione dei documenti Google:

Questa sezione contiene informazioni sulla GSoD, sui Criteri di idoneità e su come le persone possono partecipare alla community CHAOSS di GSoD. Conterrà i ruoli e le responsabilità, incluso il processo per diventare l'amministratore dell'organizzazione e i mentori.

RISULTATO PREVISTO DEL PROGETTO:

I manuali svolgono un ruolo importante in qualsiasi comunità. Allo stesso modo, questo manuale di CHAOSS a livello di comunità permetterà di disporre di una documentazione più organizzata e dettagliata per la comunità CHAOSS. Sarebbe facile per qualsiasi nuovo utente che si unisce alla community, così come per i membri esistenti della community, comprendere i principi e le modalità di funzionamento della community CHAOSS. Inoltre, questo manuale comporterà la presenza dei vari processi e percorsi verso le diverse culture del lavoro all'interno della comunità CHAOSS.

DETTAGLI TECNICI:

Propongo di utilizzare la piattaforma Gitbook per la gestione del manuale, perché è un progetto collaborativo facile da usare e che consente ai team di lavorare in modo più efficace ed efficiente. Alcune funzionalità della piattaforma GitBook:

  • WYSIWYG: editor di testo potente ma accattivante
  • Markdown: supporto potente e produttivo delle scorciatoie di markdown
  • Incorporamento avanzato: incorpora contenuti web esterni come video, snippet di codice, articoli, musica e altro ancora
  • Dashboard per gli autori: offrono una dashboard intelligente per gli autori che supporta l'editing visivo
  • Bozze: crea una bozza di nuove modifiche e collabora in modo asincrono
  • Commenti dell'assistenza: esamina ed esamina le modifiche alle bozze
  • Tieni traccia della cronologia di scrittura: monitora tutto. Rivedi e annulla le modifiche
  • Approfondimenti: supporta anche gli approfondimenti che monitorano il traffico, la valutazione e la qualità dei contenuti
  • Sincronizzazione GitHub: mantenere il flusso di lavoro e la sincronizzazione dei documenti con GitHub
  • Branding personalizzazione: domini personalizzati, loghi personalizzati, caratteri, colore, temi, intestazione e così via

Ecco alcune immagini che danno un'idea della piattaforma

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

-- Dove verrà ospitata la guida?

Il Manuale sarà ospitato sul GitBook stesso, dove GitHub fornisce un meccanismo adeguato per il Dominio personalizzato, l'errore comune e la SEO.

Domini personalizzati: Se la community CHAOSS vuole ospitarla sul dominio personalizzato, verrà visualizzata come segue: docs.chaoss.community L'organizzazione deve solo creare qualsiasi sottodominio che desidera avere. Per configurare il dominio Organisation, vai alle impostazioni dell'organizzazione sulla piattaforma Gitbook. Esempio di immagine: shorturl.at/GNQR4

Gli spazi GitBook vengono gestiti sulla nostra rete CDN con HTTPS abilitato per impostazione predefinita. I certificati vengono emessi da LetsEncrypt

Domini supportati:

  • Sottodominio: www.example.com
  • Dominio personalizzato: docs.example.com

-- Come sincronizzare Gitbook con GitHub in modo che la modifica possa essere eseguita in modo efficace su entrambe le piattaforme?

L'integrazione con GitHub è molto facile da usare: se qualcuno modifica dei contenuti su GitBook, le loro modifiche vengono inviate tramite push a un repository GitHub. Al contrario, i commit inviati a un repository GitHub vengono importati all'interno di GitBook.

Configura l'integrazione GitHub:

  • Dal tuo spazio all'interno della piattaforma GitBook, fai clic sulla scheda Integrazioni > GitHub
  • Autorizza GitBook ad accedere al tuo account GitHub collegato alla tua organizzazione
  • Vai al GitHub della tua organizzazione e crea un repository per "HandBook", ad esempio "chaoss-handbook"
  • Ora seleziona il repository denominato chaoss-handbook che vuoi connettere all'interno dell'opzione di autorizzazione all'interno della piattaforma GitBook.

Una volta completati questi passaggi, GitBook aggiungerà al repository "caoss-handbook" un webhook che gli consentirà di recuperare i contenuti su ogni modifica apportata al repository. Quando apporti modifiche a GitBook, verrà eseguito il push di un nuovo commento.

È tutto! Chiunque può continuare a effettuare modifiche da GitBook o dal repository GitHub.

-- Come si modificano le pagine sulla piattaforma GitBook?

Chiunque voglia modificare qualcosa all'interno della piattaforma GitBook deve accedere alla piattaforma GitBook con un link di invito o di partecipazione. GitBook supporta la modifica visiva in cui gli utenti possono scrivere direttamente all'interno delle pagine.

Una bozza è una versione modificabile dei contenuti dell'utente accessibile solo agli autori e viene creata automaticamente quando inizi a scrivere (prima lettera sull'editor, creazione di una nuova pagina, caricamento di un'immagine e così via).

Le modifiche apportate a una bozza vengono applicate correttamente, così gli utenti possono contribuire allo stesso documento con altri membri contemporaneamente senza creare conflitti. Queste sono le cosiddette modifiche asincrone e risoluzione dei conflitti.

La prima versione della bozza non è sempre pronta per essere pubblicata immediatamente. Utilizza "Salva" quando vuoi continuare il tuo lavoro in un secondo momento o se i tuoi contenuti non sono ancora pronti per essere "uniti".

Al termine della modifica, puoi ""unire" la bozza. I contenuti che hai scritto o le modifiche apportate saranno poi disponibili per i membri del tuo team e/o pubblici.

Esempi di immagini: shorturl.at/gATZ8 e shorturl.at/qrE57

-- Struttura dei contenuti:

Sommario: ogni spazio può contenere tutte le pagine necessarie per scrivere la documentazione. Tutte queste pagine sono visibili sul lato sinistro dello schermo in quello che chiamiamo sommario. Dal sommario puoi gestire le tue pagine: creare nuove pagine, gruppi di pagine, aggiungere link esterni, aggiungere una variante, importare documenti esterni come siti web o file che sono Markdown (.md o .markdown), HTML (.html), Microsoft Word (.docx).

Pagina iniziale: la pagina iniziale è la home page o la radice della documentazione e funziona fondamentalmente come la pagina principale di tutte le pagine della documentazione. Poiché è l'ingresso principale della documentazione e del tuo spazio, questa pagina non può essere spostata o eliminata, contiene elementi secondari o non può essere inclusa in un gruppo.

Pagine: una pagina ha un titolo e una descrizione facoltativa nella parte superiore dell'editor. Puoi quindi scrivere e aggiungere qualsiasi tipo di contenuto.Puoi nidificare le pagine trascinando una pagina sotto un'altra. Gli elementi secondari di una pagina saranno nascosti, ma possono essere compressi.

Link esterni: queste voci sono link esterni e non presentano contenuti nell'editor. La loro funzione principale è creare link a siti web esterni.

Varianti: puoi creare contenuti alternativi alla documentazione creando una variante. Questo può essere utile per documentare più versioni di un'API, una libreria o traduzioni.

Esempio di immagine: shorturl.at/eyLW1 e shorturl.at/rFRX6

-- Come verrà presentata la guida sul lato client?

Il manuale della community di Chaoss sarà accessibile con un sottodominio che può essere https://docs.chaoss.community e apparirà nei seguenti modi agli utenti finali:

  • Manuale di Mattermost: https://handbook.mattermost.com/
  • Documenti per il ponte della community Linux Foundation - https://docs.linuxfoundation.org/docs/ E molti altri

CRONOLOGIA DEL PROGETTO:

1. Fase di legame della community (17 ago - 13 set)

A.) 1a e 4a settimana:

  • Parla del progetto con i mentori
  • Effettua ricerche e raccogli le informazioni necessarie per le varie sezioni del progetto, poni domande di chiarimento alla community
  • Chiarisci alla community quale piattaforma usare per il manuale (suggerisco GitBook) e configurala
  • Contribuisci ai problemi con i documenti

2. Fase di sviluppo del documento (14 set - 30 nov)

A.) Settimana 5 (14 set - 20 set)

  • Bozza" introduttiva.

B.) Settimana 6 (21 set - 27 set)

  • Bozza della sezione "The CHAOSS Community Way"

C.) Settimana 7 (28 set - 4 ott)

  • Prepara la bozza della sezione "Percorso verso la leadership"
  • Prepara la bozza della sezione "Terminologia"

D.) Settimana 8 (5 ott - 11 ott)

  • Prepara una bozza della Roadmap della community
  • Linee guida per i contributi alla progettazione della bozza

E.) Settimana 9 (12 ott - 18 ott)

  • Sezione Sviluppo della bozza

F.) Settimana 10 (19 ott - 25 ott)

  • Linee guida per la sezione Scrittura e promozione

G.) Settimana 11 (26 ott - 1 nov)

  • Sezione Metriche della bozza
  • Bozza di sezione CHAOSScon

H.) Settimana 12 (2 nov - 8 nov)

  • Progetta la sezione Riunione

  • Crea una bozza di domande frequenti generali della community

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

  • Bozza sulle linee guida per GSoC

J.) Settimana 14 (16 nov - 22 nov)

  • Bozza sulle linee guida per il contatto

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

  • Tempi di attesa; lucidatura e miglioramento di tutti i documenti

3. Fase di valutazione (30 nov - 5 dic)

A.) 16a settimana:

  • Preparare la bozza di un report sul progetto
  • Compila la valutazione del progetto

INTERAZIONI CON LA COMMUNITY

1. Coinvolgimento e discussioni con la community.

Bene, da aprile 2020 ho fatto surf nella community CHAOSS e ho partecipato a varie discussioni con i membri della community e con i miei mentori specifici del progetto( Georg Link e Armstrong Foundjem). Una di queste discussioni che ha suscitato un maggiore interesse da parte dei membri della community è stata "Proporre Gitbook come piattaforma per ospitare il Manuale della community" ed è disponibile nel thread di una mailing list dell'archivio di CHAOSS, intitolato Proposta di Gitbook come piattaforma per ospitare il Manuale della community. Ho anche partecipato alle chiamate settimanali della community, che mi hanno aiutato a fornire aggiornamenti alla comunità.

2. Come raccoglierai le informazioni richieste per questo progetto?

Poiché questo progetto richiede la creazione di un manuale a livello di comunità, le informazioni a cui si deve accedere al suo interno saranno raccolte e discusse con i membri della comunità. Come ho proposto qui sopra, quindi, in base a questo, sarò in grado di discutere e raccogliere le informazioni necessarie durante il mio periodo di legame con la comunità.

Effettuerò ricerche sulle varie sezioni in conformità con CHAOSS e continuerò a pubblicare i thread sulla mailing list. Cercherò di porre domande di chiarimento ai miei mentori e alla community in base ai requisiti.

Al fine di avere discussioni concise, parteciperò anche a chiamate settimanali.

3. Come pensi di tenere la community informata dei tuoi progressi e di eventuali problemi o domande che potresti avere nel corso del progetto?

Per flessibilità e trasparenza, proverò a comunicare tramite la discussione della mailing list per chiedere i miei dubbi.

Condividerò i miei progressi settimanali con un post del blog che includerà la documentazione di scrum e le sfide affrontate che saranno condivise nella mailing list della community stessa per raggiungere un pubblico più ampio all'interno dell'organizzazione open source.

Parteciperò anche a chiamate settimanali della community per avere suggerimenti e discussioni sulle questioni principali.

Ho anche in programma di creare una lavagna Trello con le attività settimanali disponibili. I mentori possono quindi utilizzare questa bacheca per ottenere una comprensione chiara e concisa dei problemi e delle funzionalità attuali che stanno lavorando.

4. Cosa farai se ti blocchi con il progetto e il tuo mentore non è nei paraggi?

Credo che il ruolo del mentore sia guidare gli studenti nella giusta direzione e non spiegare ogni angolo agli studenti. La ricerca e l'implementazione del progetto sono le uniche responsabilità dello studente. Tenendo presente questo aspetto, cercherò di chiedere aiuto al mio mentore solo come ultima risorsa.

Tuttavia, se il mentore non è disponibile/occupato nel momento in cui ho bisogno di aiuto, passerò a condividere il problema che sto riscontrando con la community CHAOSS. Sono sicura che qualcuno sarà in grado di aiutarmi con le sfide che mi imbatterò. Condividerò il problema anche su forum online/community di sviluppatori come dev.to

Inoltre, proverei a partecipare a qualsiasi chiamata settimanale di assistenza all'interno della comunità CHAOSS per porre i miei dubbi.