Progetto Linux Foundation

Questa pagina contiene i dettagli di un progetto di documentazione tecnica accettato per la stagione della documentazione di Google.

Riepilogo del progetto

Organizzazione open source:
The Linux Foundation
Technical Writer:
jaskiratsingh2000
Nome del progetto:
CHAOSS: crea un manuale CHAOSS per la community
Durata del progetto:
Durata standard (3 mesi)

Project description

ABSTRACT DEL PROGETTO:

Attualmente, i gruppi di lavoro all'interno della community CHAOSS hanno sviluppato i propri modi di lavorare e hanno documentato i propri processi diversi in misura diversa. I gruppi di lavoro comprendono metriche comuni WG, diversità e inclusione WG, Evoluzione, Rischio e Valore, che hanno impostato i propri metodi di partecipazione e lavoro e hanno adattato diversi modi di comunicazione e cultura del lavoro. Questi gruppi di lavoro, in conformità con le metriche, hanno aree di interesse e background diversi, che funzionano per metriche appropriate, conducono varie ricerche e sviluppo nelle rispettive categorie di gruppi di lavoro e conoscono il percorso giusto per condurre varie ricerche e sviluppo nelle rispettive categorie, ma le procedure per i nuovi arrivati e i collaboratori esistenti potrebbero non essere noti come partecipare o prendere il percorso giusto per i rispettivi lavori.

Di conseguenza, gli elementi della community CHAOSS non sono standardizzati. Pertanto, per conoscere la procedura corretta e i principi fondamentali della cultura del lavoro all'interno della community, lo scopo del manuale della community è centralizzare le informazioni critiche e standardizzarne alcune nel progetto CHAOSS. Le parti relative alle informazioni e alla standardizzazione fondamentali si concentrano principalmente sulle procedure utilizzate da CHAOSS in modo che la community abbia un accordo su come la community svolge il proprio lavoro, su come i nuovi arrivati possono partecipare e seguire i principi fondamentali della community e su quali procedure e percorsi i nuovi arrivati o i membri esistenti devono seguire per usufruire della leadership all'interno della community CHAOSS.

Il manuale deve fungere da manuale di istruzioni per i membri esistenti e nuovi della community su come svolgere il lavoro nel progetto CHAOSS. Questo progetto prevede un componente creativo di raccolta e organizzazione dei contenuti del manuale, nonché un componente tecnico di definizione della modalità di rappresentazione del manuale.

PERCHÉ È NECESSARIO?

Il Manuale della community è un documento che definisce le norme e le procedure chiave della community e ne illustra la missione, i valori e il funzionamento.

Questo manuale fornisce una chiara introduzione e informazioni sul funzionamento della community per i nuovi membri. Attualmente, il manuale della community CHAOSS è disponibile nel repository GitHub e deve essere rinnovato e ristrutturato con maggiori informazioni per i nuovi arrivati e gli utenti esistenti della community. Questo manuale per l'intera community CHAOSS aiuterà i nuovi arrivati e i membri esistenti della community nei seguenti modi:

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

DESCRIZIONE DEL PROGETTO:

Il manuale della community sarà suddiviso in varie "sezioni" che conterranno informazioni appropriate e dettagliate su argomenti specifici. Le sezioni possono essere suddivise nei seguenti modi:

  • Introduzione
  • Il modo della community CHAOSS
  • Percorso per diventare leader
  • Terminologia
  • Linee guida per i contributi
    • Sviluppatore
    • Designer
    • Autore
    • Professionista del marketing
  • Metriche
  • CHAOSScon
  • CHAOSScast
  • Video delle riunioni
  • Domande frequenti di carattere generale
  • Tutoraggio
    • Google Summer of Code
    • Outreachy
    • Season of Docs di Google

OUTPUT DEL PROGETTO DETTAGLIATI

1.) Introduzione:

Questa sezione sarà la prima pagina del Manuale della community CHAOSS e tratterà i dettagli, la panoramica e l'utilizzo del manuale. Di seguito sono riportati i seguenti elementi:

A.) Conterrà il messaggio di benvenuto con una breve descrizione della community CHAOSS che aiuterà a convincere i lettori a leggere il manuale. Includerò anche il collage di immagini tratte da qui https://chaoss.community/chaoss-photo-album/ che mette in evidenza i vari movimenti all'interno della community. B.) La pagina conterrà anche i dettagli di tutte le sezioni con una descrizione di una riga che spiega ogni sezione e i link appropriati. C.) Uso del manuale: l’uso del manuale esiste già qui( shorturl.at/cqQU6), ma rinnoverò e rifattorizzerò l’utilizzo del manuale esistente con una migliore markdown che includerà il flusso del manuale(includerò che come accadono le cose quando qualcuno desidera aggiungere, rimuovere o discutere di cose relative al manuale. Può proseguire il processo di comunicazione per qualsiasi aspetto relativo al manuale.), Linee guida del manuale(che includono il suo utilizzo all'interno della community e il suo ambito), Contributo al manuale ( che include come utilizzare il 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. Nella sezione Condivisione feedback includerò un modello e diversi modi in cui gli utenti possono seguire le istruzioni per fornire o utilizzare i problemi di GitLab per riceverlo.

2.) La community del CHAOSS:

Il modo in cui la community CHAOSS si comporta sarà importante per far comprendere le pratiche e le linee guida della community. Workflows sarebbe in grado di metterlo maggiormente in evidenza e delineare nel modo migliore le pratiche della community. Questa sezione comprende quanto segue:

A.) Valori generali: illustrano come vengono gestite sostenibilità, apertura e trasparenza all'interno della community CHAOSS. Spiegherò questi valori in modo che i nuovi utenti o quelli esistenti possano comprenderli e tenerli in considerazione durante il lavoro all'interno della community. B.) Norme della community: indicano in che modo interagire con la community CHAOSS e seguire i termini di base. Inoltre, ti spiegherà la cultura del lavoro seguita all'interno della community. (Cosa fare e cosa non fare). Includerà l'elenco di controllo per i collaboratori principali e i manutentori, oltre a far sapere agli altri come devono lavorare con i manutentori e quale è la loro lista di controllo. C.) Gruppi di lavoro: questa pagina( https://chaoss.community/participate/ ) contiene informazioni sui gruppi di lavoro, come la descrizione del gruppo di lavoro, il link al repository e le informazioni sulle riunioni, ma nel manuale includerò come partecipare ai diversi gruppi di lavoro e comprendere la procedura di valutazione delle metriche, comprendere la cultura del lavoro per i rispettivi gruppi di lavoro e come diventare i collaboratori principali per i diversi gruppi di lavoro.

3.) Percorso per la leadership:

Acquisire la leadership in un progetto open source può essere fondamentale per il successo di una community nel mondo commerciale. Tenendo conto di questo, includerò quanto segue:

A.) Leadership tecnica: includerà le procedure e le responsabilità dei gestori del repository, degli autori della documentazione e dei gestori del sito web. B.) Leadership di governance: includerà i percorsi per i membri del consiglio di amministrazione e i responsabili delle decisioni. C.) Leadership operativa: contiene il percorso per i Community Manager

4.) Terminologia:

La terminologia aiuterebbe a descrivere i termini e le rispettive appartenenze che vengono utilizzati di frequente all'interno della community CHAOSS. Inoltre, includerò anche le linee guida per l'utilizzo della terminologia, come lettere maiuscole, abbreviazioni e parole da evitare con i relativi motivi. I termini che verranno inclusi sono Progetto CHAOSS, Salute della community open source, Revisione del codice, Gruppo di lavoro, Metrica del software open source, Metrica comune, Metrica di diversità e inclusione, Gruppo di lavoro Evolution, Gruppo di lavoro sui rischi, Gruppo di lavoro sul valore, Rilascio delle metriche, Ambito di interesse.

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 volontario, quindi aiuterà qualsiasi utente/nuovi arrivati a comprendere le necessità di base e le linee guida da seguire. Saranno inclusi i seguenti dettagli:

A.) Comprendere la roadmap della comunità: questo argomento porterà a una panoramica della roadmap della comunità CHAOSS, che aiuterà gli utenti a sapere quale modo o processo seguire dando priorità ai vari lavori all'interno del progetto CHAOSS. B.) spiegando gli elementi necessari per dare un contributo pratico, come sviluppo, documentazione, progettazione, test e così via C.) per fornire una breve panoramica del funzionamento di GitLab D.) Guida per i revisori/i manutentori

Questa sezione conterrà anche i "Ruoli e responsabilità" per ogni categoria di contributo, riportati di seguito:

a.) DESIGN: questa sottosezione includerà il "CHAOSS Design Work Flow" e le linee guida per il design che conterranno i principi di design, la procedura e gli strumenti utilizzati che i collaboratori devono seguire per dare il proprio contributo al campo del design. b.) SVILUPPO: conterrà la guida per il contributo al codice di base. Conterrà i requisiti tecnici, la struttura del progetto, la configurazione del progetto(Augur, Cregit, GremoireLab) e così via. DOCUMENTAZIONE: includerà risorse per la documentazione, inclusi strumenti e guida di stile. d.) OUTREACH: includerà come i collaboratori possono supportare la crescita della community CHAOSS nell'outreach, scrivendo blog, utilizzando handle di social, organizzando meetup ed eventi

6.) Metriche

Attualmente, il sito web della community CHAOSS contiene le informazioni sulle release delle metriche( https://chaoss.community/metrics/ ) ed è più importante per le persone capire come seguire la procedura per rendere disponibile il proprio sito web delle metriche su quel sito web. Questa sezione fornirà le informazioni che aiuteranno gli utenti a conoscere le procedure 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 i dettagli e le informazioni che spiegano le procedure e le modalità di gestione di CHAOSScon nel Manuale. Il Manuale conterrà le seguenti Informazioni:

A.) Dettagli sul comitato organizzatore: verranno spiegate le procedure per partecipare al comitato organizzatore di CHAOSScon B.) Gestione della procedura di richiesta di proposte: include la gestione della registrazione degli autori, l'invio di proposte e documentazione, la revisione e la procedura di approvazione. C.) Gestione e pubblicazione del programma CHAOSScon D.) Come gestire la pubblicità e il marketing E.) Come gestire le proposte di sponsorizzazione e i fondi, inclusi i pacchetti

8.) CHAOSScast:

Le informazioni relative a CHAOSScast sono disponibili all'indirizzo https://github.com/chaoss/governance/blob/master/community-handbook/chaosscast.md e saranno incluse nel manuale con alcuni dettagli aggiuntivi come la partecipazione, il comitato organizzatore, la pubblicità e i materiali di marketing.

9.) Video delle riunioni:

conterrà tutti i video delle riunioni, oltre alla descrizione, ad esempio i partecipanti, l'ordine del giorno e così via, che si sono svolte in passato e sono disponibili su YouTube.

10.) Domande frequenti generali:

Saranno incluse le domande generali più frequenti poste all'interno della community, che aiuteranno i nuovi arrivati e i membri esistenti della community a rispondere ad alcune di queste.

11.) Google Summer of Code:

Questa sezione contiene informazioni su Google Summer of Code, sui criteri di idoneità e su come le persone possono partecipare a Google Summer of Code nell'ambito della community CHAOSS. Questa sezione conterrà anche il modello di proposta che gli utenti possono utilizzare per redigere la bozza della proposta, nonché i ruoli e le responsabilità. Inoltre, conterrà anche le informazioni che aiuteranno i membri esistenti della community a conoscere la procedura per diventare amministratori dell'organizzazione e mentor.

  1. Contatto:

Questa sezione contiene informazioni su Outreachy, sui criteri di idoneità e su come le persone possono partecipare a Outreachy nell'ambito della community CHAOSS.Inoltre, sono riportati i ruoli e le responsabilità, inclusa la procedura per diventare amministratore dell'organizzazione e mentore.

  1. Season of Docs di Google:

Questa sezione contiene informazioni su GSoD, sui criteri di idoneità e su come le persone possono partecipare alla community CHAOSS in GSoD. Questo documento conterrà i ruoli e le responsabilità, incluso il processo per diventare amministratore dell'organizzazione e mentore.

RISULTATO ATTESO DEL PROGETTO:

I manuali svolgono un ruolo importante in qualsiasi comunità. Analogamente, questo manuale per l'intera community CHAOSS consentirà di avere una documentazione più organizzata e dettagliata per la community CHAOSS. Sarebbe facile per tutti i nuovi arrivati, nonché per i membri esistenti al suo interno, comprendere le basi e il funzionamento della community CHAOSS. Inoltre, questo manuale avrà come risultato la presenza di vari processi e percorsi per culture di lavoro diverse all'interno della community CHAOSS.

DETTAGLI TECNICI:

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

  • WYSIWYG: editor di testo potente e allo stesso tempo accattivante
  • Markdown: supporto potente e produttivo delle scorciatoie Markdown
  • Incorporamento avanzato: consente di incorporare contenuti web esterni come video, snippet di codice, articoli, musica e altro ancora
  • Dashboard per gli autori: una dashboard intelligente per gli autori che supporta l'editing visivo
  • Bozze: crea bozze di nuove modifiche e collabora in modo asincrono
  • Commenti di assistenza: discutere e rivedere le modifiche alla bozza
  • Tieni traccia della cronologia di scrittura: tieni traccia di tutto. Rivedi e ripristina le modifiche
  • Approfondimenti: supporta anche gli approfondimenti che monitorano il traffico, le valutazioni e la qualità dei contenuti.
  • Sincronizzazione GitHub: mantenere il flusso di lavoro e continuare a sincronizzare i documenti con GitHub
  • Branding personalizzato: domini personalizzati, loghi personalizzati, caratteri, colori, 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à ospitato il Manuale?

Il manuale verrà ospitato su GitBook stesso, dove GitHub fornisce un meccanismo appropriato per dominio personalizzato, errori comuni e SEO.

Domini personalizzati: se la community CHAOSS vuole ospitare la documentazione sul dominio personalizzato, verrà visualizzata come docs.chaoss.community. L'organizzazione deve solo creare i sottodomini che desidera. Per configurare il dominio dell'organizzazione, 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 sono emessi da LetsEncrypt

Domini supportati:

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

-- Come sincronizzare Gitbook con GitHub in modo da poter modificare i file su entrambe le piattaforme in modo efficace?

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

Configura l'integrazione di 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 repository GitHub della tua organizzazione e crea un repository per il "Manuale", ad esempio chaoss-handbook
  • Ora seleziona il repository denominato chaoss-handbook che vuoi collegare all'interno dell'opzione di autorizzazione all'interno della piattaforma GitBook.

Una volta completati questi passaggi, GitBook aggiungerà un webhook al repository chaoss-handbook che gli consentirà di recuperare i contenuti a ogni modifica del repository. Quando apporti modifiche a GitBook, verrà inviato un nuovo commento.

È tutto! Chiunque può continuare a modificare dal repository GitBook o GitHub.

-- Come modificare le pagine sulla piattaforma GitBook?

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

Una bozza è una versione modificabile dei contenuti degli utenti, accessibile solo agli autori e creata automaticamente non appena inizi a scrivere (prima lettera nell'editor, creazione di una nuova pagina, caricamento di un'immagine e così via).

Le modifiche apportate a una bozza sono adeguate e ciò consente agli utenti di contribuire allo stesso documento con altri membri contemporaneamente senza creare conflitti. Questo processo è chiamato modifica asincrona e risoluzione dei conflitti.

La prima versione della bozza non è sempre pronta per essere pubblicata immediatamente. Utilizza ""salva"" quando vuoi continuare a lavorare 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 che hai apportato saranno quindi disponibili per i membri del tuo team e/o saranno pubblici.

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

-- Struttura dei contenuti:

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

Pagina iniziale: la pagina iniziale è la home page o la radice della documentazione e funziona sostanzialmente come pagina principale di tutte le pagine della documentazione. Poiché è l'ingresso principale della documentazione e dello spazio, questa pagina non può essere spostata, eliminata, non può contenere elementi secondari o far parte di 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. Le pagine secondarie di una pagina verranno nascoste, ma potranno essere compresse.

Link esterni: queste voci sono link esterni e non hanno contenuti nell'editor. La loro funzione principale è quella di indirizzare gli utenti a siti web esterni.

Varianti: puoi creare contenuti alternativi alla tua documentazione creando una variante. Ciò 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à presentato il Manuale lato client?

Il manuale della community Chaoss sarà accessibile con un sottodominio che può essere https://docs.chaoss.community e avrà i seguenti aspetti:

  • Manuale di Mattermost - https://handbook.mattermost.com/
  • Documentazione di Linux Foundation Community Bridge - https://docs.linuxfoundation.org/docs/ E molti altri

AGENDA DEL PROGETTO:

1.) Fase di Community Bonding (17 agosto - 13 settembre)

A.) Settimana 1-4:

  • Discutere del progetto con i mentor
  • Cerca e raccogli le informazioni necessarie per le varie sezioni del progetto, poni domande di chiarimento alla community
  • Chiarisci con la community quale piattaforma utilizzare per il manuale (consiglio GitBook) e configurala
  • Contribuire ai problemi relativi alla documentazione

2.) Fase di sviluppo della documentazione (14 settembre - 30 novembre)

A.) Settimana 5 (14-20 settembre)

  • Bozza" sezione introduttiva

B.) Settimana 6 (21-27 settembre)

  • Bozza della sezione "The CHAOSS Community Way"

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

  • Redigi la sezione "Percorso verso la leadership"
  • Crea la bozza della sezione "Terminologia"

D.) Settimana 8 (5-11 ott)

  • Redigere la roadmap della community
  • Linee guida per i contributi alla bozza del design

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

  • Sezione Sviluppo bozza

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

  • Linee guida per la scrittura e la promozione della sezione

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

  • Sezione Metriche in bozza
  • Sezione CHAOSScon bozza

H.) Settimana 12 (2-8 nov)

  • Progetta la sezione per le riunioni

  • Draft General FAQs of community

    I.) Settimana 13 (9-15 novembre)

  • Bozza sulle linee guida GSoC

J.) Settimana 14 (16-22 novembre)

  • Bozza sulle linee guida per il sociale

K.) Settimana 15 (23-29 novembre)

  • Tempo di attesa; perfezionamento e miglioramento dell'intero documento

3.) Fase di valutazione (30 novembre - 5 dicembre)

A.) 16ª settimana:

  • Prepara la bozza di un report di progetto
  • Compila la valutazione del progetto

INTERAZIONI CON LA COMMUNITY

1.) Coinvolgimento e discussioni con la community.

Faccio parte della community CHAOSS da aprile 2020 e ho partecipato a varie discussioni con i membri della community e con i miei mentor di progetto specifici( Georg Link e Armstrong Foundjem). Una di queste discussioni che ha suscitato un maggiore interesse tra i membri della community è stata "Proposing Gitbook as a platform for hosting Community Handbook" ed è disponibile nel thread della mailing list dell'archivio CHAOSS con il nome Proposing Gitbook as a platform for hosting Community Handbook. Ho anche partecipato alle chiamate settimanali della community, che mi hanno aiutato a fornire aggiornamenti alla community.

2.) Come raccoglierai le informazioni richieste per questo progetto?

Poiché questo progetto richiede la creazione di un manuale per l'intera community, le informazioni a cui è necessario accedere verranno raccolte e discusse con i membri della community. Ho proposto le tempistiche precedenti, quindi in base a ciò sarò in grado di discutere e raccogliere le informazioni necessarie durante il mio periodo di legame con la comunità.

Effettuerò ricerche nelle varie sezioni in conformità con CHAOSS e manterrò attivi i thread nella mailing list. Proverò a porre domande esplicative dai miei mentori e dalla comunità in base ai requisiti.

Per avere discussioni concise, parteciperò anche alle chiamate settimanali.

3.) Come pensi di tenere aggiornata la community sui tuoi progressi e su eventuali problemi o domande che potresti avere nel corso del progetto?

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

Condividerò i miei progressi settimanali su un post del blog che includerà la documentazione relativa alla Scrum e le sfide affrontate, che verrà condivisa nella mailing list della community stessa per raggiungere il pubblico più vasto all'interno dell'organizzazione open source.

Parteciperò inoltre alle chiamate settimanali della community per poterti fornire suggerimenti e discutere dei problemi principali.

Inoltre, ho intenzione di creare una bacheca di Trello con le attività settimanali disponibili. I mentor possono quindi utilizzare questa bacheca per avere una comprensione chiara e concisa dei problemi e delle funzionalità attuali in fase di elaborazione.

4.) Cosa farai se rimani bloccato sul progetto e il tuo mentore non c'è?

Ritengo che il ruolo del mentore sia guidare gli studenti nella giusta direzione e non spiegare loro ogni dettaglio. La ricerca e l'implementazione del progetto sono responsabilità esclusive dello studente. Tenendo presente che cercherò di chiedere aiuto al mio mentore solo come ultima risorsa.

Tuttavia, se il mentore non è presente o non è occupato al momento in cui ho bisogno di aiuto, passerò a condividere il mio problema all'interno della community CHAOSS. Sono sicuro che qualcuno sarà in grado di aiutarmi a risolvere eventuali problemi. Condividerò il problema anche su forum/community di sviluppatori online come dev.to

Inoltre, proverei a partecipare alle chiamate settimanali di assistenza all'interno della community CHAOSS per poter chiarire i miei dubbi.