From cfe2404bc8b45d13c5a379b683b51b7c71a3a9e3 Mon Sep 17 00:00:00 2001 From: Jacopo Braccio Date: Mon, 23 Oct 2023 16:36:29 +0200 Subject: [PATCH 1/7] Add italian locales --- _data/locales/it.yml | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 _data/locales/it.yml diff --git a/_data/locales/it.yml b/_data/locales/it.yml new file mode 100644 index 00000000000..05560e0ffb6 --- /dev/null +++ b/_data/locales/it.yml @@ -0,0 +1,31 @@ +it: + locale_name: Italian + nav: + about: About + contribute: Contribuire + index: + lead: Il software open source è realizzato da persone come te. Scopri come lanciare e far crescere il tuo progetto. + opensourcefriday: È venerdì! Investi qualche ora per contribuire al software che usi e che ami. + article: + table_of_contents: Indice + back_to_all_guides: Torna a tutte le guide + related_guides: Guide correlate + footer: + contribute: + heading: Contribuire + description: Vuoi dare un suggerimento? Questo contenuto è open source. Aiutateci a migliorarlo. + button: Contribuisci + subscribe: + heading: Rimani in contatto + description: Sii il primo a conoscere gli ultimi suggerimenti e risorse open source di GitHub. + label: Indirizzo e-mail + button: Iscriversi + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] con [love] da [github] e [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: amore + # Label for the contributors link + friends_label: amici From 232e5746a8a61f3a43f78476ebfe08c9f05ea222 Mon Sep 17 00:00:00 2001 From: Jacopo Braccio Date: Mon, 23 Oct 2023 16:43:41 +0200 Subject: [PATCH 2/7] Add index.html in italian articles translation --- _articles/it/index.html | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 _articles/it/index.html diff --git a/_articles/it/index.html b/_articles/it/index.html new file mode 100644 index 00000000000..17410cb0374 --- /dev/null +++ b/_articles/it/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Guide open source +lang: it +permalink: /it/ +--- \ No newline at end of file From 6ccb77b7ccc0b98b2d2baea3f40d29f227fdbf54 Mon Sep 17 00:00:00 2001 From: Jacopo Braccio Date: Mon, 23 Oct 2023 16:46:14 +0200 Subject: [PATCH 3/7] Add starting-a-project italian translation --- _articles/it/starting-a-project.md | 352 +++++++++++++++++++++++++++++ 1 file changed, 352 insertions(+) create mode 100644 _articles/it/starting-a-project.md diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md new file mode 100644 index 00000000000..fa73d1b5df1 --- /dev/null +++ b/_articles/it/starting-a-project.md @@ -0,0 +1,352 @@ +--- +lang: it +title: Avviare un Progetto Open Source +description: Impara di più sul mondo dell'open source e preparati a lanciare il tuo progetto. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png + @@ -10,354 +10,345 @@ related: + - building +--- + +## Il "come" e il "perché" dell'open source + +Stai pensando di iniziare con l'open source? Congratulazioni! Il mondo apprezza il tuo contributo. Parliamo di cosa è l'open source e del perché la gente lo fa. + +### Cosa significa "open source"? + +Quando un progetto è open source, significa che **chiunque è libero di usarlo, studiarlo, modificarlo e distribuirlo per qualsiasi scopo**. Questi permessi vengono garantiti attraverso [una lincenza open source](https://opensource.org/licenses). + +L'open source è potente perché abbassa le barriere all'adozione e alla collaborazione, consentendo alle persone di diffondere e migliorare rapidamente i progetti. Inoltre, rispetto al closed source, offre agli utenti la possibilità di controllare la propria attività informatica. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software, piuttosto che affidarsi esclusivamente alle decisioni di un fornitore di prodotti closed source. + +### Perché la gente sceglie di rendere il proprio lavoro open source? + + + +[Ci sono varie ragioni](https://ben.balter.com/2015/11/23/why-open-source/) per cui una persona o un'organizzazione vorrebe rendere open source un progetto. Alcuni esempi sono: + +* **Collaborazione:** I progetti open source possono accettare modifiche da chiunque nel mondo. [Exercism](https://github.com/exercism/), ad esempio, è una piattaforma di esercizi di programmazione con oltre 350 collaboratori. + +* **Adozione e remix:** I progetti open source possono essere utilizzati da chiunque per quasi tutti gli scopi. Le persone possono anche usarli per costruire altre cose. [WordPress](https://github.com/WordPress), per esempio, è nato come fork di un progetto esistente chiamato [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Trasparenza:** Chiunque può ispezionare un progetto open source alla ricerca di errori o incoerenze. La trasparenza è importante per governi come la Bulgaria o gli Stati Uniti, per industrie regolamentate come quelle bancarie o sanitarie e per software di sicurezza come [Let's Encrypt](https://github.com/letsencrypt). + +L'open source non riguarda solo il software. Si può aprire tutto, dai set di dati ai libri. Consulta [GitHub Explore](https://github.com/explore) per avere un'idea di cos'altro si può fare con l'open source. + +### Open source significa "gratuito"? + +Una delle maggiori attrattive dell'open source è che non ha costi. La "gratuità", tuttavia, è un sottoprodotto del valore complessivo dell'open source. + +Poiché una licenza [open source prevede](https://opensource.org/osd-annotated) che chiunque possa utilizzare, modificare e condividere il progetto per quasi tutti gli scopi, i progetti stessi tendono a essere gratuiti. Se l'utilizzo del progetto costasse, chiunque potrebbe legalmente farne una copia e utilizzare la versione gratuita. + +Di conseguenza, la maggior parte dei progetti open source sono gratuiti, ma "gratuito" non fa parte della definizione di open source. Esistono modi per far pagare i progetti open source indirettamente, attraverso licenze doppie o funzionalità limitate, pur rispettando la definizione ufficiale di open source. + +## Dovrei lanciare un mio progetto open source? + +La risposta breve è sì, perché a prescindere dal risultato, lanciare il proprio progetto è un ottimo modo per imparare come funziona l'open source. + +Se non avete mai lanciato un progetto open source prima d'ora, potreste essere nervosi per quello che dirà la gente o se qualcuno se ne accorgerà mai. Se questo vi sembra il vostro caso, non siete soli! + +Il lavoro open source è come qualsiasi altra attività creativa, che si tratti di scrittura o di pittura. Può far paura condividere il proprio lavoro con il mondo, ma l'unico modo per migliorare è fare pratica, anche se non si ha un pubblico. + +Se non siete ancora convinti, prendetevi un momento per pensare a quali potrebbero essere i vostri obiettivi. + +### Stabilire gli obiettivi + +Gli obiettivi possono aiutarvi a capire su cosa lavorare, a cosa dire di no e dove avete bisogno dell'aiuto di altri. Iniziate a chiedervi: _perché sto facendo open sourcing di questo progetto?_ + +Non esiste una risposta giusta a questa domanda. Potreste avere più obiettivi per un singolo progetto, o progetti diversi con obiettivi diversi. + +Se il vostro unico obiettivo è quello di mettere in mostra il vostro lavoro, potreste anche non volere contributi e dirlo nel vostro README. D'altra parte, se si vogliono contributi, si investirà tempo in una documentazione chiara e nel far sentire i nuovi arrivati i benvenuti. + + + +Man mano che il vostro progetto cresce, la vostra comunità potrebbe avere bisogno di qualcosa di più del vostro codice. Rispondere ai problemi, rivedere il codice e promuovere il progetto sono tutti compiti importanti in un progetto open source. + +Sebbene la quantità di tempo da dedicare alle attività non legate al codice dipenda dalle dimensioni e dalla portata del progetto, in qualità di manutentori dovreste essere pronti ad affrontarle da soli o a trovare qualcuno che vi aiuti. + +**Se fate parte di un'azienda che ha un progetto in open sourcing**, assicuratevi che il vostro progetto abbia le risorse interne di cui ha bisogno per prosperare. Dovrete identificare chi è responsabile della manutenzione del progetto dopo il lancio e come condividerete questi compiti con la vostra comunità. + +Se avete bisogno di un budget dedicato o di personale per la promozione, le operazioni e la manutenzione del progetto, iniziate subito a parlarne. + + + +### Contribuire ad altri progetti + +Se il vostro obiettivo è imparare a collaborare con gli altri o capire come funziona l'open source, prendete in considerazione la possibilità di contribuire a un progetto esistente. Iniziate con un progetto che già utilizzate e amate. Contribuire a un progetto può essere semplice come correggere errori di battitura o aggiornare la documentazione. + +Se non siete sicuri di come iniziare a contribuire, consultate la nostra guida [Come contribuire all'open source](../how-to-contribute/). + +## Lanciare il proprio progetto open source + +Non esiste un momento ideale per rendere open source il proprio lavoro. Si può aprire un'idea, un lavoro in corso o dopo anni di chiusura. + +In generale, dovreste aprire il vostro progetto quando vi sentite a vostro agio nel far vedere il vostro lavoro ad altri e nel fornire un feedback. + +Indipendentemente dalla fase in cui si decide di rendere open source il progetto, ogni progetto dovrebbe includere la seguente documentazione: + +* [Licenza open source](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Linee guida per la contribuzione](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Codice di condotta](../code-of-conduct/) + +In qualità di manutentori, questi componenti vi aiuteranno a comunicare le aspettative, a gestire i contributi e a proteggere i diritti legali di tutti (compresi i vostri). Aumentano notevolmente le possibilità di avere un'esperienza positiva. + +Se il vostro progetto è su GitHub, inserire questi file nella vostra directory principale con i nomi dei file raccomandati aiuterà GitHub a riconoscerli e a farli apparire automaticamente ai vostri lettori. + +### Scelta della licenza + +Una licenza open source garantisce che altri possano usare, copiare, modificare e contribuire al vostro progetto senza ripercussioni. Inoltre, vi protegge da situazioni legali spinose. **È necessario includere una licenza quando si lancia un progetto open source**. + +Il lavoro legale non è divertente. La buona notizia è che potete copiare e incollare una licenza esistente nel vostro repository. Ci vorrà solo un minuto per proteggere il vostro duro lavoro. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), y [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono le licenze più diffuse, ma ci sono [altre opzioni](https://choosealicense.com) da poter scegliere. + +Quando si crea un nuovo progetto su GitHub, viene data la possibilità di selezionare una licenza. Includendo una licenza open source, il progetto GitHub diventa open source. + +[Devi scegliere una licenza!](/assets/images/starting-a-project/repository-license-picker.png) + +Se avete altre domande o dubbi sugli aspetti legali della gestione di un progetto open source, [siamo a vostra disposizione](../legal/). + +### Scrivere un README + +I README non si limitano a spiegare come utilizzare il progetto. Spiegano anche perché il progetto è importante e cosa possono fare gli utenti con esso. + +Nel vostro README, cercate di rispondere alle seguenti domande: + +* Cosa fa questo progetto? +* Perché questo progetto è utile? +* Come posso iniziare? +* Dove posso trovare ulteriore aiuto, se ne ho bisogno? + +Potete usare il vostro README per rispondere ad altre domande, come ad esempio come gestite i contributi, quali sono gli obiettivi del progetto e le informazioni su licenze e attribuzione. Se non volete accettare contributi o se il vostro progetto non è ancora pronto per la produzione, scrivete queste informazioni. + + + +A volte si evita di scrivere un README perché si ha l'impressione che il progetto sia incompiuto o perché non si vogliono contributi. Queste sono tutte ottime ragioni per scriverne uno. + +Per avere maggiore ispirazione, provate a usare la guida ["Make a README"](https://www.makeareadme.com/) di @dguo o il [modello README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) di @PurpleBooth per scrivere un README completo. + +Quando si include un file README nella directory principale, GitHub lo visualizza automaticamente nella homepage del repository. + +### Scrivere le linee guida per la contribuzione + +Un file CONTRIBUTING indica al pubblico come partecipare al progetto. Ad esempio, si possono includere informazioni su: + +* Come presentare una segnalazione di bug (provate a usare i modelli di issue e pull request) +* Come suggerire una nuova funzionalità +* Come configurare l'ambiente ed eseguire i test + +Oltre ai dettagli tecnici, un file CONTRIBUTING è un'opportunità per comunicare le vostre aspettative sui contributi, come ad esempio: + +* I tipi di contributi che state cercando +* La vostra roadmap o visione del progetto +* Come i collaboratori devono (o non devono) mettersi in contatto con voi. +L +'uso di un tono cordiale e amichevole e l'offerta di suggerimenti specifici per i contributi (come la stesura della documentazione o la creazione di un sito web) possono contribuire a far sentire i nuovi arrivati benvenuti ed entusiasti di partecipare. + +Ad esempio, [Active Admin](https://github.com/activeadmin/activeadmin/) inizia [la sua guida a contribuire ](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con: + +> Innanzitutto, grazie per aver pensato di contribuire ad Active Admin. Sono le persone come voi che rendono Active Admin uno strumento così grande. +Nelle prime fasi del progetto, il file CONTRIBUTING può essere semplice. Dovreste sempre spiegare come segnalare i bug o i problemi dei file e tutti i requisiti tecnici (come i test) per dare un contributo. + +Col tempo, potreste aggiungere altre domande frequenti al vostro file CONTRIBUTING. Scrivere queste informazioni significa ridurre il numero di persone che vi porranno sempre le stesse domande. + +Per maggiori informazioni sulla stesura del file di CONTRIBUTO, consultare il [modello di guida](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) per i contributi di @nayafia o ["Come costruire un file CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) di @mozilla. + +Collega il file CONTRIBUTING al file README, in modo che più persone lo vedano. Se si [inserisce il file CONTRIBUTING nel repository del progetto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub collegherà automaticamente il file quando un collaboratore crea un problema o apre una richiesta di pull. + +![Linee guida per la contribuzione](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Stabilire un codice di condotta + + + +Infine, un codice di condotta aiuta a stabilire le regole di base per il comportamento dei partecipanti al progetto. Questo è particolarmente utile se state lanciando un progetto open source per una comunità o un'azienda. Un codice di condotta vi consente di facilitare un comportamento sano e costruttivo della comunità, riducendo il vostro stress come manutentori. + +Per maggiori informazioni, consultate la nostra guida al [Codice di condotta](../code-of-conduct/). + +Oltre a comunicare _come ci si aspetta_ che i partecipanti si comportino, un codice di condotta tende anche a descrivere a chi si applicano queste aspettative, quando si applicano e cosa fare in caso di violazione. + +Come per le licenze open source, esistono anche standard emergenti per i codici di condotta, per cui non è necessario scriverne uno proprio. Il [Contributor Covenant](https://www.contributor-covenant.org/) è un codice di condotta che viene utilizzato da oltre [40.000 progetti](https://www.contributor-covenant.org/adopters) open source, tra cui Kubernetes, Rails e Swift. Indipendentemente dal testo utilizzato, dovrete essere pronti a far rispettare il vostro codice di condotta quando necessario. + +Incollate il testo direttamente in un file CODE_OF_CONDUCT nel vostro repository. Mantenete il file nella cartella principale del progetto, in modo che sia facile da trovare, e collegatelo al file dal vostro README. + +## Nome e branding del progetto + +Il branding è molto più di un logo appariscente o di un nome accattivante per un progetto. Riguarda il modo in cui parlate del vostro progetto e chi raggiungete con il vostro messaggio. + +### Scegliere il nome giusto + +Scegliete un nome che sia facile da ricordare e che, idealmente, dia un'idea di ciò che il progetto fa. Ad esempio: + +* [Sentry](https://github.com/getsentry/sentry) monitora le applicazioni per segnalare gli arresti anomali +* [Thin](https://github.com/macournoyer/thin) è un server web Ruby semplice e veloce + +Se si sta lavorando su un progetto esistente, usare il suo nome come prefisso può aiutare a chiarire cosa fa il progetto (per esempio, [node-fetch](https://github.com/bitinn/node-fetch) porta `window.fetch` su Node.js). + +Considerate la chiarezza prima di tutto. I giochi di parole sono divertenti, ma ricordate che alcune battute potrebbero non essere adatte ad altre culture o a persone con esperienze diverse dalle vostre. Alcuni dei vostri potenziali utenti potrebbero essere dipendenti dell'azienda: non vorrete metterli a disagio quando dovranno spiegare il vostro progetto al lavoro! + +### Evitare i conflitti di nome + +Controllate se ci sono progetti open source con un nome simile, soprattutto se condividete la stessa lingua o lo stesso ecosistema. Se il vostro nome si sovrappone a un progetto esistente molto popolare, potreste confondere il vostro pubblico. + +Se volete un sito web, un account Twitter o altre proprietà che rappresentino il vostro progetto, assicuratevi di poter ottenere i nomi che desiderate. L'ideale sarebbe [riservare questi nomi fin da ora](https://instantdomainsearch.com), anche se non avete intenzione di usarli subito. + +Assicuratevi che il nome del vostro progetto non violi alcun marchio. Un'azienda potrebbe chiedervi di togliere il vostro progetto in un secondo momento o addirittura intraprendere un'azione legale contro di voi. Non vale la pena rischiare. + +Potete controllare il [Global Brand Database](http://www.wipo.int/branddb/en/)dell'OMPI per verificare la presenza di conflitti tra marchi. Se siete un'azienda, questo è uno degli aspetti che il vostro team [legale](../legal/) può aiutarvi a risolvere. + +Infine, fate una rapida ricerca su Google per il nome del vostro progetto. Le persone saranno in grado di trovare facilmente il vostro progetto? Nei risultati della ricerca compare qualcosa di diverso che non vorreste vedere? + +### Anche il modo in cui scrivete (e codificate) influisce sul vostro marchio! + +Durante la vita del vostro progetto, scriverete molto: README, tutorial, documenti della comunità, risposte a problemi, forse anche newsletter e mailing list. + +Che si tratti di documentazione ufficiale o di un'email casuale, il vostro stile di scrittura fa parte del marchio del vostro progetto. Considerate come potreste apparire al vostro pubblico e se questo è il tono che volete trasmettere. + + + +L'uso di un linguaggio caldo e inclusivo (come "loro", anche quando ci si riferisce a una singola persona) può contribuire a rendere il vostro progetto accogliente per i nuovi collaboratori. Attenetevi a un linguaggio semplice, poiché molti dei vostri lettori potrebbero non essere di madrelingua inglese. + +Oltre al modo in cui scrivete le parole, anche il vostro stile di codifica può diventare parte del marchio del vostro progetto. [Angular](https://github.com/johnpapa/angular-styleguide) e [jQuery](https://contribute.jquery.org/style-guide/js/) sono due esempi di progetti con stili di codifica e linee guida rigorosi. + +Non è necessario scrivere una guida di stile per il vostro progetto quando siete agli inizi, e potreste scoprire che vi piace incorporare diversi stili di codifica nel vostro progetto. Tuttavia, dovreste prevedere come il vostro stile di scrittura e di codifica possa attrarre o scoraggiare diversi tipi di persone. Le prime fasi del progetto sono l'occasione per creare il precedente che desiderate. + +## La vostra lista di controllo pre-lancio + +Siete pronti a rendere open source il vostro progetto? Ecco una lista di controllo per aiutarvi. Selezionate tutte le caselle? Siete pronti a partire! Fate clic su ["pubblica"](https://help.github.com/articles/making-a-private-repository-public/) e datevi una pacca sulla spalla. + +**Documentazione** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Codice** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Persone** + +Se sei un individuo: + +
+ + +
+ +Se sei un'azienda o un'organizzione: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Ce l'hai fatta! + +Congratulazioni per l'open sourcing del vostro primo progetto. Indipendentemente dal risultato, lavorare in pubblico è un dono per la comunità. Con ogni commit, commento e richiesta di pull, create opportunità di apprendimento e di crescita per voi e per gli altri. \ No newline at end of file From 75311c200c4b4574c1fd0230c4a969fe89f43f25 Mon Sep 17 00:00:00 2001 From: Jacopo Braccio Date: Mon, 23 Oct 2023 16:58:13 +0200 Subject: [PATCH 4/7] Add italian best-practices --- _articles/it/best-practices.md | 73 ++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 _articles/it/best-practices.md diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md new file mode 100644 index 00000000000..34c73806960 --- /dev/null +++ b/_articles/it/best-practices.md @@ -0,0 +1,73 @@ +--- +lang: it +title: Buone Pratiche per i Manutentori del Codice. +description: Semplificare la vita di un manutentore open source, dalla documentazione dei processi alla valorizzazione della comunità. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Cosa significa essere un manutentore? + +Se mantenete un progetto open source utilizzato da molte persone, potreste aver notato che state scrivendo meno codice e rispondendo di più ai problemi. + +Nelle prime fasi di un progetto, si sperimentano nuove idee e si prendono decisioni in base a ciò che si desidera. Con l'aumentare della popolarità del progetto, vi troverete a lavorare di più con i vostri utenti e collaboratori. + +La manutenzione di un progetto richiede molto più del codice. Questi compiti sono spesso inaspettati, ma sono altrettanto importanti per un progetto in crescita. Abbiamo raccolto alcuni modi per semplificarvi la vita, dalla documentazione dei processi allo sfruttamento della vostra comunità. + +## Documentare i processi + +Scrivere è una delle cose più importanti che si possono fare come manutentori. + +La documentazione non solo chiarisce il vostro pensiero, ma aiuta gli altri a capire di cosa avete bisogno o cosa vi aspettate, prima ancora che ve lo chiedano. + +Scrivere le cose rende più facile dire di no quando qualcosa non rientra nel vostro ambito. Inoltre, è più facile che le persone si mettano a disposizione e diano una mano. Non si sa mai chi potrebbe leggere o utilizzare il vostro progetto. + +Anche se non si usano paragrafi interi, è meglio annotare i punti salienti che non scrivere affatto. + +Ricordate di tenere aggiornata la documentazione. Se non siete in grado di farlo sempre, cancellate la documentazione obsoleta o indicatela come obsoleta, in modo che i collaboratori sappiano che gli aggiornamenti sono benvenuti. + +### Scrivere la visione del progetto + +Iniziate scrivendo gli obiettivi del vostro progetto. Aggiungeteli al vostro README o create un file separato chiamato VISION. Se ci sono altri artefatti che possono essere utili, come una roadmap del progetto, rendete pubblici anche quelli. + +Avere una visione chiara e documentata vi mantiene concentrati e vi aiuta a evitare lo "scope creep" dei contributi degli altri. + +Ad esempio: +@lord ha scoperto che avere la visione di un progetto lo ha aiutato a realizzare quali richieste priorizzare. Come manutentore novizio, si pentì di non essere rimasto fedele allo scopo del progetto quando ricevette la sua prima richiesta di funzionalità per [Slate](https://github.com/lord/slate). + + + +### Comunicare le proprie aspettative + +Le regole possono essere snervanti da scrivere. A volte si può avere l'impressione di controllare il comportamento degli altri o di uccidere tutto il divertimento. + +Tuttavia, se scritte e fatte rispettare in modo equo, le buone regole responsabilizzano i manutentori. Impediscono di essere trascinati a fare cose che non si vogliono fare. + +La maggior parte delle persone che si imbattono nel vostro progetto non sanno nulla di voi o della vostra situazione. Potrebbero pensare che siate pagati per lavorarci, soprattutto se si tratta di qualcosa che usano regolarmente e da cui dipendono. Forse un tempo dedicavate molto tempo al vostro progetto, ma ora siete impegnati con un nuovo lavoro o con un familiare. + +Tutto questo va benissimo! Ma assicuratevi che gli altri lo sappiano. + +Se il mantenimento del progetto è part-time o puramente volontario, siate onesti su quanto tempo avete a disposizione. Non si tratta di quanto tempo pensate che il progetto richieda, né di quanto tempo gli altri vogliono che dedichiate. + +Ecco alcune regole che vale la pena mettere per iscritto: + +* Come viene rivista e accettata una contribuzione (_Hanno bisogno di fare dei test? C'è un modello che devono usare per le issues?_) +* I tipi di contributi che accetterai (_Vuoi aiuto solo con una parte del codice?_) +* Quando è appropriato fare un follow-up (_ad es. "Puoi aspettarti una risposta da un manutentore del codice entro i prossimi 7 giorni. Se non hai avuto notizie entro quel tempo, non esitare a pingare il thread."_) +* Quanto tempo dedichi al progetto (_ad es. "Dedichiamo solo circa 5 ore a settimana a questo progetto"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), e [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) sono alcuni esempi di progetti con regole chiare per manutentori e collaboratori. + +### Mantenere la comunicazione pubblica + +Non dimenticare di documentare anche le tue interazioni. Ovunque tu possa, mantieni la comunicazione sul tuo progetto pubblica. Se qualcuno cerca di contattarti in privato per discutere una richiesta di funzionalità o un bisogno di supporto, indirizzalo educatamente verso un canale di comunicazione pubblico, come una mailing list o un issue tracker. \ No newline at end of file From cb204e3cd35d0bad1e724cc39450d184ddb6dab2 Mon Sep 17 00:00:00 2001 From: Jacopo Braccio Date: Mon, 23 Oct 2023 17:32:15 +0200 Subject: [PATCH 5/7] Add it-building-community --- _articles/it/building-community.md | 275 +++++++++++++++++++++++++++++ 1 file changed, 275 insertions(+) create mode 100644 _articles/it/building-community.md diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md new file mode 100644 index 00000000000..c966db244a1 --- /dev/null +++ b/_articles/it/building-community.md @@ -0,0 +1,275 @@ +--- +lang: it +title: Costruire Comunità Accoglienti +description: Costruire una comunità che incoraggi le persone ad usare, contribuire ed educare con il loro progetto +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Preparando il tuo progetto per il successo + +Hai appena lanciato il tuo progetto, stai spargendo la voce e le persone lo stanno seguendo. Fantastico! Ora, come fai a farli rimanere? + +Una comunità accogliente è un investimento a lungo termine nel tuo progetto e nella tua reputazione. Se il tuo progetto sta appena iniziando a vedere i suoi primi contributi, inizia offrendo ai primi collaboratori un'esperienza positiva e rendi facile per loro tornare. + +### Fai sentire le persone benvenute + +Un modo di pensare alla comunità del progetto è attraverso ciò che @MikeMcQuaid chiama [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Mentre costruisci la tua comunità, considera come qualcuno nella parte superiore del funnel (un utente potenziale) potrebbe teoricamente fare il suo percorso verso il basso (un manutentore attivo). Il tuo obiettivo è ridurre l'attrito ad ogni fase dell'esperienza del collaboratore. Quando le persone ottengono successi facili, saranno incentivati a fare di più. + +Inizia con la tua documentazione: + +* **Rendila semplice per chiunque debba usare il progetto.** [Un documento README amichevole](../starting-a-project/#scrivendo-un-readme) e codici di esempio chiari renderanno più facile iniziare per chiunque approdi al tuo progetto. +* **Spiega chiaramente come contribuire,** utilizzando [un file CONTRIBUTING](../starting-a-project/#scrivendo-le-linee-guida-per-contribuire) e tenendo aggiornati i tuoi problemi. + +Una buona documentazione invita le persone a interagire con il tuo progetto. Prima o poi, qualcuno aprirà un problema o una pull request. + +* **Quando qualcuno di nuovo arriva al tuo progetto, ringrazialo per il suo interesse!** è sufficiente una sola esperienza negativa perché qualcuno non voglia tornare. +* **Comportati in modo sensibile.** Se non rispondi ai loro problemi per un mese, è probabile che abbiano già dimenticato del tuo progetto. +* **Mantieni una mentalità aperta riguardo ai tipi di contributi che accetterai.** Molti collaboratori iniziano segnalando un errore o con una piccola correzione. Ci sono [molti modi per contribuire](../how-to-contribute/#cosa-significa-contribuire) a un progetto. Permetti alle persone di aiutare nel modo in cui vogliono aiutare. +* **Se c'è qualche contributo con cui non sei d'accordo,** ringrazialo per la sua idea e [spiega perché](../best-practices/#imparando-a-dire-no) non si adatta all'ambito del progetto, collegando la documentazione pertinente se ne hai. + + + +La maggior parte dei collaboratori all'open source sono "collaboratori occasionali": persone che contribuiscono a un progetto solo occasionalmente. Un collaboratore occasionale probabilmente non ha il tempo di dedicarsi a tempo pieno al vostro progetto, quindi il vostro compito è quello di rendere facile il suo contributo. + +Incoraggiare altri collaboratori è un investimento anche per voi stessi. Quando si dà la possibilità ai propri fan più accaniti di portare avanti il lavoro che li entusiasma, si riduce la pressione a fare tutto da soli. + +### Documenta tutto + + + +Quando si inizia un nuovo progetto, può sembrare naturale mantenere il proprio lavoro privato. Ma i progetti open source prosperano quando si documenta il processo in pubblico. + +Quando si scrivono le cose, più persone possono partecipare a ogni fase del processo. Potreste ricevere aiuto per qualcosa di cui non sapevate nemmeno di aver bisogno. + +Scrivere significa molto di più di una semplice documentazione tecnica. Ogni volta che sentite l'esigenza di scrivere qualcosa o di discutere privatamente del vostro progetto, chiedetevi se potete renderlo pubblico. + +Siate trasparenti sulla tabella di marcia del progetto, sui tipi di contributi che state cercando, su come vengono esaminati i contributi o sul perché avete preso certe decisioni. + +Se notate che più utenti incontrano lo stesso problema, documentate le risposte nel README. + +Per le riunioni, prendete in considerazione la possibilità di pubblicare le vostre note o i vostri interventi in un problema pertinente. Il feedback che otterrete da questo livello di trasparenza potrebbe sorprendervi. + +Documentare tutto vale anche per il lavoro svolto. Se state lavorando a un aggiornamento sostanziale del vostro progetto, inseritelo in una richiesta di pull e contrassegnatelo come lavoro in corso (WIP). In questo modo, altre persone possono sentirsi coinvolte nel processo fin dalle prime fasi + +### Comportati in modo reattivo + +Man mano che [promuovi il tuo progetto](../finding-users), le persone ti daranno feedback. Potrebbero avere domande su come funzionano le cose o potrebbero aver bisogno di aiuto per iniziare. + +Cerca di rispondere quando qualcuno presenta un problema, invia una pull request o pone una domanda sul tuo progetto. Rispondendo rapidamente, fai sì che le persone si sentano parte del dialogo e saranno più entusiaste di partecipare. + +Anche se non puoi rivedere la loro richiesta immediatamente, semplicemente ringraziandoli per il loro tempestivo aiuto aumenterai il loro impegno. Questo è come @tdreyno ha risposto a una pull request su [Middleman](https://github.com/middleman/middleman/pull/1466): + +![richiesta pull di middleman](/assets/images/building-community/middleman_pr.png) + +Uno [studio di Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) ha scoperto che i collaboratori che ricevono una revisione del loro codice entro 48 ore hanno una probabilità significativamente maggiore di tornare e ripetere un contributo. + +Le conversazioni sul tuo progetto possono anche avvenire in altri luoghi su internet, come Stack Overflow, Twitter o reddit. Puoi configurare le tue notifiche in uno di questi tre luoghi in modo da essere avvisato quando qualcuno menziona il tuo progetto. + +### Dai alla comunità un luogo di aggregazione + +Ci sono due ragioni per dare alla vostra comunità un luogo di aggregazione. + +Il primo motivo è per loro. Aiutare le persone a conoscersi. Le persone con interessi comuni vorranno inevitabilmente un luogo dove parlarne. E quando la comunicazione è pubblica e accessibile, chiunque può leggere gli archivi passati per aggiornarsi e partecipare. + +La seconda ragione è per voi. Se non offrite alle persone un luogo pubblico per parlare del vostro progetto, è probabile che vi contatteranno direttamente. All'inizio può sembrare abbastanza facile rispondere ai messaggi privati "solo per questa volta". Ma col tempo, soprattutto se il vostro progetto diventa popolare, vi sentirete esausti. Resistete alla tentazione di comunicare con le persone sul vostro progetto in privato. Invece, indirizzateli a un canale pubblico designato. + +La comunicazione pubblica può essere semplice come indirizzare le persone ad aprire un topic invece di inviarvi direttamente un'e-mail o commentare sul vostro blog. Potreste anche creare una mailing list, un account Twitter, un canale Slack o IRC per parlare del vostro progetto. Oppure provate tutte queste cose! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) ha ore d'ufficio riservate per aiutare i membri della comunità ogni due settimane: + +> Kops ha anche ore riservate ogni due settimane per fornire aiuto e guida alla comunità. I manutentori di Kops hanno concordato di riservare ore dedicate specificamente per lavorare con i nuovi arrivati, aiutando con PR e discutendo nuove caratteristiche. + +Le eccezioni notevoli alla comunicazione pubblica sono: 1) questioni di sicurezza e 2) violazioni sensibili del codice di condotta. Dovresti sempre trovare un modo per permettere alle persone di segnalare questi problemi in privato. Se non vuoi usare la tua e-mail privata, configura un account di posta elettronica dedicato. + +## Far crescere la propria comunità + +Le comunità sono estremamente potenti. Questo potere può essere una benedizione o una maledizione, a seconda di come lo si gestisce. Quando la comunità del vostro progetto cresce, ci sono modi per aiutarla a diventare una forza di costruzione, non di distruzione. + +### Non tollerare i cattivi attori + +Qualsiasi progetto popolare attirerà inevitabilmente persone che danneggiano, anziché aiutare, la vostra comunità. Potrebbero avviare dibattiti inutili, cavillare su caratteristiche insignificanti o fare i prepotenti con gli altri. + +Fate del vostro meglio per adottare una politica di tolleranza zero nei confronti di questo tipo di persone. Se non vengono controllate, le persone negative metteranno a disagio gli altri membri della comunità. Potrebbero anche andarsene. + + + +I dibattiti regolari su aspetti banali del tuo progetto distraggono gli altri, compreso te, dal concentrarti su compiti importanti. Le nuove persone che arrivano al tuo progetto possono vedere queste conversazioni e potrebbero non voler partecipare. + +Quando noti un comportamento negativo, fai la corrispondente osservazione pubblicamente. Spiegagli, in tono gentile, perché tale comportamento non è accettabile. Se il problema persiste, potresti aver bisogno di [chiedergli di andarsene](../code-of-conduct/#applicando-il-tuo-codice-di-condotta). Il tuo [codice di condotta](../code-of-conduct/) può essere una guida costruttiva per queste conversazioni. + +### Incontra i collaboratori dove sono + +Una buona documentazione diventa importante solo man mano che la tua comunità cresce. I collaboratori casuali, che altrimenti non sarebbero familiari con il tuo progetto, leggono la tua documentazione per comprendere rapidamente il contesto di ciò di cui hai bisogno. + +Nel tuo file CONTRIBUTING, indica esplicitamente ai nuovi collaboratori come possono iniziare. Potresti anche voler dedicare una sezione specifica a questo scopo. [Django](https://github.com/django/django), ad esempio, ha una pagina speciale per dare il benvenuto ai nuovi collaboratori. + +![pagina nuovi collaboratori di django](/assets/images/building-community/django_new_contributors.png) + +Nel tuo elenco di problemi, etichetta gli errori che sono adatti a diversi tipi di collaboratori: ad esempio, ["_solo principianti_"](https://kentcdodds.com/blog/first-timers-only), "adatto per chi risolve il suo primo bug", o "documentazione". [Queste etichette](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) rendono più facile cercare problemi da risolvere per qualcuno nuovo nel progetto e iniziare. + +Infine, usa la tua documentazione per far sentire le persone benvenute in ogni fase del cammino. + +Non interagirete mai con la maggior parte delle persone che arrivano sul vostro progetto. Potrebbero esserci contributi che non avete ricevuto perché qualcuno si è sentito intimidito o non sapeva da dove cominciare. Anche poche parole gentili possono evitare che qualcuno abbandoni il vostro progetto con frustrazione. + +Ad esempio, ecco come [Rubinius](https://github.com/rubinius/rubinius/) inizia la sua [guida alla contribuzione](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Vogliamo iniziare ringraziandoti per l'utilizzo di Rubinius. Questo progetto è un lavoro fatto con amore, e apprezziamo tutti gli utenti che individuano errori, migliorano le prestazioni e aiutano con la documentazione. Ogni contributo è significativo, quindi grazie per partecipare. Detto ciò, ecco alcune linee guida che chiediamo di seguire affinché possiamo affrontare con successo il tuo problema. + +### Condividi la proprietà del tuo progetto + + + +Le persone sono entusiaste di contribuire a progetti quando percepiscono un senso di appartenenza. Ciò non significa che devi cambiare la visione del tuo progetto o accettare contributi che non desideri. Ma quanto più dai credito agli altri, tanto più resteranno. + +Vedi se riesci a trovare modi per condividere la proprietà della tua comunità il più possibile. Ecco alcune idee: + +* **Evita di correggere errori semplici (non critici).** Al contrario, usali come opportunità per reclutare nuovi collaboratori o mentore di qualcuno che vuole contribuire. Potrebbe sembrare innaturale all'inizio, ma il tuo investimento sarà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una pull request per un problema dettagliato successivamente a [Cookiecutter](https://github.com/audreyr/cookiecutter) invece di risolverlo lui stesso. + +![problema cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Inizia un file di COLLABORATORI o AUTORI nel tuo progetto** che elenchi tutti quelli che hanno collaborato al tuo progetto, come fa [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Se hai una comunità considerevole, **invia una newsletter o scrivi un post su un blog** ringraziando i collaboratori. Rust's [This Week in Rust](https://this-week-in-rust.org/) e Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) sono due buoni esempi. + +* **Dai a ogni collaboratore il permesso di fare commit.** @felixge ha scoperto con questo che le persone [erano entusiaste di perfezionare le loro patch](https://felixge.de/2013/03/11/the-pull-request-hack.html), e ha anche trovato nuove persone per mantenere progetti ai quali non aveva lavorato da tempo. + +* Se il tuo progetto è ospitato su GitHub, **sposta il tuo progetto dal tuo account personale a un'[Organizzazione](https://help.github.com/articles/creating-a-new-organization-account/)** e aggiungi almeno un amministratore di backup. Le Organizzazioni rendono più semplice lavorare su progetti con collaboratori esterni. + +La realtà è che [la maggior parte dei progetti ha](https://peerj.com/preprints/1233/) una o due persone che lo mantengono e che fanno la maggior parte del lavoro. Più grande è il tuo progetto e più grande è la tua comunità, più facile è trovare aiuto. + +Anche se potresti non sempre trovare qualcuno che risponda alla tua richiesta, mettere un segnale là fuori aumenta le probabilità che altre persone si presentino. E più inizi presto, prima le persone potranno aiutarti. + + + +## Risoluzione dei conflitti + +Nelle prime fasi del tuo progetto, è abbastanza facile prendere decisioni importanti. Quando vuoi fare qualcosa, lo fai semplicemente. + +Man mano che il tuo progetto diventa più conosciuto, più persone avranno interesse nelle decisioni che prendi. Anche se non hai una grande comunità di collaboratori, se il tuo progetto ha molti utenti, troverai persone che influenzano le decisioni o sollevano questioni proprie. + +Per lo più, se hai coltivato una comunità amichevole e rispettosa e hai documentato il tuo processo in modo aperto, la tua stessa comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte potresti incontrare problemi un po' più difficili da affrontare. + +### Stabilire l'asticella per la gentilezza + +Quando la tua comunità affronta una questione difficile, le tensioni possono aumentare. Le persone potrebbero arrabbiarsi o diventare frustrate e prendere le critiche in modo personale, anche da parte tua. + +Il tuo compito come responsabile è evitare che queste situazioni escano fuori controllo. Anche se hai una forte opinione su un argomento, cerca di mantenere una posizione da moderatore o facilitatore, invece di entrare in lotta e spingere i tuoi punti di vista. Se qualcuno si sta comportando in modo non educato o sta monopolizzando la conversazione, [intervieni immediatamente](../building-community/#no-toleres-a-los-malos-actores) per mantenere una discussione civile e produttiva. + + + +Gli altri ti guarderanno come una guida. Dai un buon esempio. Puoi ancora esprimere disaccordo, tristezza o preoccupazione, ma in modo calmo. + +Mantenere la calma non è facile, ma dimostrare leadership migliora la salute della tua comunità. Internet te ne sarà grato. + +### Tratta il tuo README come una costituzione + +Il tuo README è [più di un insieme di istruzioni](../starting-a-project/#escribiendo-un-readme). è anche un luogo dove puoi parlare dei tuoi obiettivi, della visione del prodotto e di una roadmap. Se le persone si stanno concentrando troppo sul dibattito su un aspetto particolare, puoi fare riferimento al README e discutere di una visione più ampia del tuo progetto. Concentrarsi sul README rende anche la conversazione meno personale, favorendo una discussione più costruttiva. + +### Concentrati sul viaggio, non sulla destinazione + +Alcuni progetti utilizzano un processo di voto per prendere decisioni importanti. Anche se sembra sensato a prima vista, il voto mette l'accento sulla "risposta", più che sull'ascolto e sulla gestione delle preoccupazioni di ognuno. + +Il voto può diventare politico, quando i membri della comunità si sentono sotto pressione per favorirsi a vicenda o per votare in un certo modo. Non tutti votano, se c'è una [maggioranza silenziosa](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) nella tua comunità o se ci sono utenti che non hanno saputo che si stava svolgendo una votazione. + +A volte il voto diventa necessario per rompere un'eguaglianza. Nella maggior parte dei casi, però, enfatizza la ["ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) anziché il consenso stesso. + +Nel processo di ricerca del consenso, i membri della comunità discutono le principali preoccupazioni finché non si sentono adeguatamente ascoltati. Quando rimangono solo preoccupazioni minori, la comunità prosegue. La "ricerca del consenso" riconosce che una comunità potrebbe non essere in grado di raggiungere una risposta perfetta. Priorizza invece l'ascolto e la discussione. + + + +Anche se non adotti un processo di ricerca del consenso, come responsabile del progetto, è importante che le persone sappiano che stai ascoltando. Far sentire le persone ascoltate e impegnarti a risolvere le loro preoccupazioni copre molta strada nella risoluzione di situazioni difficili. Poi, seguisci le tue parole con azioni. + +Non affrettarti a prendere una decisione per il bene di avere una soluzione. Assicurati che tutti si sentano ascoltati e che tutte le informazioni siano state rese pubbliche prima di passare a una soluzione. + +### Mantieni la conversazione incentrata sull'azione + +La discussione è importante, ma c'è una differenza tra conversazioni produttive e improduttive. + +Fomenta la discussione finché si sta muovendo verso una soluzione. Se è chiaro che la conversazione si sta spegnendo o sta divagando, che le cose stanno diventando personali o stanno discutendo su dettagli minori, è ora di chiuderla. + +Permettere che queste conversazioni continuino non è solo dannoso per un dato argomento, ma anche per la salute della comunità. Manda il messaggio che questo tipo di conversazioni sono permesse e addirittura incoraggiate, e può scoraggiare le persone a sollevare o risolvere problemi futuri. + +Con ogni punto che hai fatto o che gli altri hanno fatto, chiediti, _"Ciò ci avvicina a una soluzione?"_ + +Se la conversazione inizia a sciogliersi, chiedi al gruppo, _"Quali passi dovremmo prendere?"_ per ri-orientare la conversazione. + +Se la conversazione chiaramente non sta andando da nessuna parte, non ci sono azioni chiare da intraprendere o le azioni corrette sono già state intraprese, chiudi la discussione e spiega perché l'hai chiusa. + + + +### Scegli le tue battaglie saggiamente + +Il contesto è importante. Considera chi è coinvolto in una discussione e come rappresenta il resto della comunità. + +Tutti nella comunità sono sconvolti o anche coinvolti in un problema? O è un provocatore solitario? Non dimenticare di considerare i membri silenziosi della comunità, non solo le voci attive. + +Se il problema non rappresenta le esigenze più ampie della tua comunità, potresti solo aver bisogno di ringraziare alcune persone per le loro preoccupazioni. Se si tratta di un problema ricorrente senza una soluzione chiara, indirizza la discussione a discussioni precedenti e chiudi il thread di discussione. + +### Identifica un decisore nella comunità + +Con un atteggiamento positivo e una chiara comunicazione, è possibile risolvere la maggior parte delle situazioni difficili. Tuttavia, anche in una discussione produttiva, potrebbero esserci semplicemente opinioni diverse su come procedere. In questi casi, identifica un individuo o un gruppo di persone che possono agire come decisori. + +Un decisore può essere un responsabile principale del progetto, o potrebbe essere un piccolo gruppo di persone che prende una decisione basata sul voto. Idealmente, avrai identificato un decisore e il processo associato in un file chiamato GOVERNANCE prima di aver bisogno di usarlo. + +Il tuo decisore dovrebbe essere l'ultima risorsa. I problemi che dividono sono un'opportunità di crescita e apprendimento per la tua comunità. Sfrutta queste opportunità e utilizza un processo collaborativo per muoverti verso una soluzione ogni volta che sia possibile. + +## La comunità è il ❤️ dell'open source + +Le comunità sane e fiorenti alimentano le migliaia di ore di lavoro open source che vengono prodotte ogni settimana. Molti collaboratori indicano altre persone come il motivo per lavorare -o per non lavorare- in open source. Imparando a sfruttare quel potere in modo costruttivo, aiuterai qualcuno a vivere un'esperienza indimenticabile con l'open source. From 38ba7b19eeb8465f31bde20f8058ee3daab33666 Mon Sep 17 00:00:00 2001 From: Jacopo Braccio Date: Mon, 23 Oct 2023 17:39:05 +0200 Subject: [PATCH 6/7] Add italian translation for code-of-conduct --- _articles/it/code-of-conduct.md | 114 ++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 _articles/it/code-of-conduct.md diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md new file mode 100644 index 00000000000..f6a0574e452 --- /dev/null +++ b/_articles/it/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: it +title: Il Tuo Codice di Condotta +description: Favorisci un comportamento sano e costruttivo adottando e applicando un codice di condotta. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Perché è necessario un codice di condotta + +Un codice di condotta è un documento che stabilisce le aspettative di comportamento per i partecipanti al tuo progetto. Adottare e applicare un codice di condotta aiuta a creare un'atmosfera sociale positiva per la comunità. + +I codici di condotta aiutano a proteggere non solo i tuoi partecipanti, ma anche te stesso. Se gestisci un progetto, sai che gli atteggiamenti controproducenti degli altri partecipanti possono farti sentire scarico di energia o infelice riguardo al tuo lavoro. + +Un codice di condotta ti incoraggia a favorire un comportamento sano e costruttivo da parte della comunità. Essere proattivi riduce la probabilità che tu o altri si sentano stanchi del progetto, e ti aiuta ad agire quando qualcuno fa qualcosa che non approvi. + +## Stabilire un codice di condotta + +Cerca di stabilire un codice di condotta il più presto possibile, idealmente quando crei il tuo progetto. + +Oltre a comunicare le tue aspettative, un codice di condotta descrive quanto segue: + +* Dove il codice di condotta ha effetto _(solo nelle issue e nelle pull request, o anche in attività della comunità come eventi?)_ +* A chi si applica il codice di condotta _(membri della comunità e manutentori, ma cosa succede con gli sponsor?)_ +* Cosa succede se qualcuno viola il codice di condotta +* Come qualcuno può segnalare una violazione + +Ogni volta che è possibile, usa modelli già esistenti. Il [Contributor Covenant](https://www.contributor-covenant.org/) è un codice di condotta utilizzato da più di 40.000 progetti open source, inclusi Kubernetes, Rails e Swift. + +Il [Django Code of Conduct](https://www.djangoproject.com/conduct/) e il [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sono anche due esempi di buoni codici di condotta. + +Posiziona un file CODICE_DI_CONDOTTA nella directory radice del tuo progetto e collegalo dal tuo LEGGIMI, in modo che sia visibile alla tua comunità. + +## Decidere come applicare il tuo codice di condotta + + + +Dovresti spiegare come il tuo codice di condotta sarà applicato **_prima_** che una violazione si verifichi. Ci sono varie ragioni per farlo: + +* Dimostra che sei serio riguardo alle azioni quando sono necessarie. + +* La tua comunità si sentirà più sicura sapendo che le loro denunce sono davvero esaminate. + +* Fornirai alla tua comunità la rassicurazione che il processo di revisione è equo e trasparente, nel caso in cui vengano indagati per una violazione. + +Dovresti fornire alle persone un modo privato (ad esempio, tramite un'indirizzo e-mail) per segnalare una violazione del codice di condotta e spiegare chi riceverà tale segnalazione. Potrebbe trattarsi di un manutentore, un gruppo di manutentori o un gruppo di lavoro sul codice di condotta. + +Ricorda che qualcuno potrebbe voler segnalare una violazione sulla persona che riceve tali segnalazioni. In tal caso, fornisci un modo per far esaminare tali segnalazioni da qualcun altro. Ad esempio, @ctb e @mr-c [spiegano nel loro progetto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Le istanze di abuso, molestie o altri comportamenti inaccettabili possono essere segnalate inviando una e-mail a **khmer-project@idyll.org** che sarà indirizzata solo a C. Titus Brown e Michael R. Crusoe. Per segnalare un problema che coinvolge entrambi, si prega di inviare un'e-mail a **Judi Brown Clarke, Ph.D.** il Direttore della Diversità presso il BEACON Center for the Study of Evolution in Action, un centro della National Science Foundation per la Scienza e la Tecnologia. + +Per ispirarti, guarda il [manuale di esecuzione di Django](https://www.djangoproject.com/conduct/enforcement-manual/) (anche se potresti non aver bisogno di qualcosa di così ampio, a seconda delle dimensioni del tuo progetto). + +## Applicare il tuo codice di condotta + +A volte, nonostante i tuoi migliori sforzi, qualcuno farà qualcosa che violerà questo codice. Ci sono diversi modi per affrontare il comportamento negativo o dannoso nella pratica. + +### Raccogli informazioni sulla situazione + +Dai la stessa importanza a ciò che ogni membro della comunità ha da dire, proprio come daresti a ciò che hai da dire. Se ricevi una segnalazione che qualcuno ha violato il codice di condotta, prendila sul serio e indaga sulla questione, anche se non corrisponde alla tua esperienza con quella persona. In questo modo, dimostri alla tua comunità che apprezzi il loro punto di vista e ti fidi del loro giudizio. + +Il membro della comunità potrebbe essere un reincidente che costantemente mette gli altri a disagio o potrebbe avere detto o fatto qualcosa una sola volta. In entrambe le situazioni, potresti intraprendere azioni, a seconda del contesto. + +Prima di rispondere, prenditi del tempo per capire cosa è successo. Leggi i commenti e le conversazioni precedenti della persona per capire meglio chi sono e perché potrebbero aver agito in quel modo. Prova a raccogliere opinioni da altri su quella persona e il suo comportamento. + + + +### Prendi misure appropriate + +Dopo aver raccolto e elaborato informazioni sufficienti, dovrai decidere cosa fare. Mentre consideri i tuoi prossimi passi, ricorda che il tuo obiettivo come moderatore è promuovere un ambiente sicuro, rispettoso e collaborativo. Considera non solo come affrontare la situazione attuale, ma anche come la tua risposta influenzerà il comportamento e le aspettative del resto della tua comunità. + +Quando qualcuno segnala una violazione del codice di condotta, è compito tuo occupartene, non di qualcun altro. A volte, chi segnala sta rivelando informazioni correndo un grande rischio per la sua carriera, reputazione o integrità fisica. Forzare a confrontarsi con il loro molestatore potrebbe mettere in una posizione compromettente chi segnala. Dovresti comunicare direttamente con la persona in questione, a meno che chi segnala non chieda esplicitamente il contrario. + +Ci sono vari modi per rispondere a una violazione del codice di condotta: + +* **Dare alla persona in questione un avviso pubblico** e spiegare come il suo comportamento ha avuto un impatto negativo sugli altri, preferibilmente nel canale in cui è accaduto. Quando possibile, la comunicazione pubblica mostra alla comunità quanto seriamente consideri il codice di condotta. Sii gentile, ma deciso, nella tua comunicazione. + +* **Avvicinarti privatamente alla persona** in questione per spiegare come il suo comportamento ha avuto un impatto negativo sugli altri. Puoi utilizzare un canale di comunicazione privato se la situazione riguarda informazioni personali. Se ti metti in contatto privatamente con qualcuno, è una buona idea inviare una copia alla persona che ha fatto la segnalazione, in modo che sappia che hai preso delle misure. Chiedi il consenso a chi ha segnalato prima di inviare una copia. + +A volte, non è possibile trovare una soluzione. La persona in questione potrebbe diventare aggressiva e ostile quando viene affrontata o potrebbe non cambiare comportamento. In questa situazione, dovresti considerare di prendere misure più severe. Ad esempio: + +* **Sospendere la persona** in questione dal progetto, applicando un divieto di partecipazione in tutti gli aspetti del progetto. + +* **Espellere permanentemente** la persona dal progetto. + +L'espulsione dei membri non dovrebbe essere presa alla leggera e rappresenta una differenza permanente e irrimediabile di prospettive. Dovresti prendere queste misure solo quando è evidente che non si può trovare una soluzione. + +## Le tue responsabilità come manutentore + +Un codice di condotta non è una legge applicata arbitrariamente. Sei tu a applicare il codice di condotta ed è tua responsabilità seguire le regole stabilite nel codice di condotta. + +Come manutentore, stabilisci le linee guida della tua comunità e le applichi in base alle regole stabilite nel tuo codice di condotta. Ciò implica prendere sul serio qualsiasi violazione del codice di condotta. Chi segnala merita una giusta e completa revisione della sua segnalazione. Se determini che il comportamento segnalato non è una violazione, comunica chiaramente con loro e spiega perché non prenderai alcuna azione. Ciò che faranno in seguito dipende da loro: tollerare il comportamento con cui avevano un problema o smettere di partecipare alla comunità. + +Una segnalazione di comportamento che _tecnicamente_ non viola il codice di condotta potrebbe indicare che c'è un problema nella tua comunità, e dovresti indagare su questo potenziale problema e agire di conseguenza. Ciò potrebbe includere la revisione del tuo codice di condotta per chiarire comportamenti accettabili e/o parlare con la persona il cui comportamento è stato segnalato e spiegare che anche se non hanno violato il codice di condotta, stanno rasentando i limiti di ciò che è atteso e stanno mettendo a disagio certi partecipanti. + +Infine, come manutentore, stabilisci e applichi gli standard di comportamento accettabile. Hai la capacità di plasmare i valori della comunità del progetto e i partecipanti si aspettano che tu applichi questi valori in modo equo e imparziale. + +## Promuovere il comportamento che vuoi vedere nel mondo 🌍 + +Quando un progetto sembra ostile e poco accogliente, anche quando si tratta solo di una persona il cui comportamento è tollerato dagli altri, rischi di perdere molti più contributori, alcuni dei quali forse non conoscerai mai. Non è sempre facile adottare o applicare un codice di condotta, ma promuovere un ambiente accogliente aiuterà la tua comunità a crescere. \ No newline at end of file From 71e10a33b70fa78beafd3937881d89a7ffb13040 Mon Sep 17 00:00:00 2001 From: Jacopo Braccio Date: Mon, 23 Oct 2023 18:10:11 +0200 Subject: [PATCH 7/7] Add italian finding-user translation --- _articles/it/finding-user.md | 142 +++++++++++++++++++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 _articles/it/finding-user.md diff --git a/_articles/it/finding-user.md b/_articles/it/finding-user.md new file mode 100644 index 00000000000..5b3d8408792 --- /dev/null +++ b/_articles/it/finding-user.md @@ -0,0 +1,142 @@ +--- +lang: it +title: Trovare Utenti Per Il Tuo Progetto +description: Aiuta il tuo progetto open source a crescere mettendolo nelle mani di utenti soddisfatti. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - principianti + - costruzione +--- + +## Passaparola + +Non c'è una regola che dice che devi promuovere un progetto open source quando lo inizi. Ci sono molte ragioni valide per lavorare su open source che non hanno nulla a che fare con la popolarità. Tuttavia, se sperate che altri trovino e utilizzino il vostro progetto open source, è il momento di dirlo a tutti del vostro duro lavoro! + +## Definire il messaggio + +Prima di iniziare il lavoro di promozione del vostro progetto, dovreste essere in grado di spiegare cosa fa e perché è importante. + +Cosa rende il vostro progetto diverso o interessante? Perché lo avete creato? Rispondere a queste domande vi aiuterà a comunicare il significato del vostro progetto. + +Ricordate che le persone vengono coinvolte come utenti, e alla fine diventano contributori, perché il vostro progetto risolve un problema per loro. Quando pensate al messaggio e al valore del vostro progetto, cercate di vederli attraverso la lente di ciò che _utenti e collaboratori_ potrebbero desiderare. + +Ad esempio, @robb usa esempi di codice per comunicare chiaramente perché il suo progetto, [Cartography](https://github.com/robb/Cartography), è utile: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +## Aiuta le persone a trovare e seguire il tuo progetto + + + +Aiutate le persone a trovare e ricordare il vostro progetto indirizzandole verso un unico spazio dei nomi. + +**Avere un ingresso chiaro per promuovere il proprio lavoro.** Un handle di Twitter, un URL di GitHub o un canale IRC sono un modo semplice per indirizzare le persone verso il vostro progetto. Questi punti di accesso danno anche alla comunità in crescita del progetto un luogo dove riunirsi. + +Se non volete ancora creare dei punti di contatto per il vostro progetto, promuovete il vostro account Twitter o GitHub in tutto ciò che fate. Promuovendo il vostro account Twitter o GitHub, le persone sapranno come contattarvi o seguire il vostro lavoro. Se parlate a un meetup o a un evento, assicuratevi che le vostre informazioni di contatto siano incluse nella vostra biografia o nelle vostre slide. + + + +**Considerate la possibilità di creare un sito web per il vostro progetto.** Un sito web rende il vostro progetto più amichevole e più facile da navigare, soprattutto se abbinato a una documentazione chiara e a tutorial. Avere un sito web suggerisce anche che il vostro progetto è attivo, il che farà sentire il vostro pubblico più a suo agio nell'usarlo. Fornite esempi per dare alle persone idee su come utilizzare il vostro progetto. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creatore di Django, ha detto che un sito web è stato _"di gran lunga la cosa migliore che abbiamo fatto con Django nei primi giorni"_. + +Se il tuo progetto è hostato su GitHub, puoi usare [GitHub Pages](https://pages.github.com/) per creare facilmente un sito. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) sono [alcuni esempi](https://github.com/showcases/github-pages-examples) di un sito eccelente e comprensibile. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Ora che hai un messaggio per il tuo progetto e un modo facile per le persone di trovare il tuo progetto, vai a parlare con la tua audience! + +## Vai dove si trova il pubblico del tuo progetto (online) + +La sensibilizzazione online è un ottimo modo per condividere e diffondere rapidamente la notizia. Utilizzando i canali online, avete la possibilità di raggiungere un pubblico molto vasto. + +Sfrutta le comunità online esistenti e le loro piattaforme per raggiungere la tua audience. Se il tuo progetto open source è un progetto software, puoi probabilmente trovare la tua audience su [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), o [Quora](https://www.quora.com/). Trova i canali dove pensi che le persone otterranno i maggiori benefici o saranno più entusiaste del tuo lavoro. + + + +Cercate di trovare il modo di condividere il vostro progetto in modi pertinenti: + +* **Conoscere progetti e comunità open source rilevanti.** A volte non è necessario promuovere direttamente il vostro progetto. Se il vostro progetto è perfetto per gli scienziati dei dati che usano Python, conoscete la comunità degli scienziati dei dati Python. Man mano che le persone vi conosceranno, si presenteranno occasioni naturali per parlare e condividere il vostro lavoro. +* **Trovare persone che vivono il problema che il vostro progetto risolve.** Cercate nei forum correlati le persone che rientrano nel target del vostro progetto. Rispondete alle loro domande e trovate un modo delicato, quando è il caso, per suggerire il vostro progetto come soluzione. +* **Chiedere un feedback.** Presentate voi stessi e il vostro lavoro a un pubblico che potrebbe trovarlo rilevante e interessante. Siate specifici su chi pensate possa trarre beneficio dal vostro progetto. Cercate di completare la frase: _"Penso che il mio progetto aiuterebbe molto X, che sta cercando di fare Y_". Ascoltate e rispondete al feedback degli altri, anziché limitarvi a promuovere il vostro lavoro. + +In generale, concentratevi sull'aiutare gli altri prima di chiedere qualcosa in cambio. Poiché chiunque può facilmente promuovere un progetto online, ci sarà molto rumore. Per distinguervi dalla massa, date alle persone un contesto in cui siete e non solo quello che volete. + +Se nessuno presta attenzione o risponde alle vostre richieste iniziali, non scoraggiatevi! La maggior parte dei lanci di progetti è un processo iterativo che può durare mesi o anni. Se non ottenete una risposta al primo tentativo, provate una tattica diversa o cercate prima di tutto un modo per aggiungere valore al lavoro degli altri. La promozione e il lancio di un progetto richiedono tempo e dedizione. + +## Vai dove si trova il pubblico del tuo progetto (offline) + +Gli eventi offline sono un modo popolare per promuovere nuovi progetti. è un modo fantastico per raggiungere un pubblico impegnato e costruire connessioni personali più profonde, specialmente se sei interessato a raggiungere sviluppatori. + + + +Se non avete mai parlato a un evento prima d'ora, è perfettamente normale sentirsi nervosi! Ricordate che il vostro pubblico è lì perché vuole davvero conoscere il vostro lavoro. + +Quando scrivete il vostro discorso, concentratevi su ciò che il pubblico troverà interessante e da cui trarrà valore. Mantenete un linguaggio amichevole e accessibile. Sorridete, respirate e divertitevi. + + + +Quando vi sentite pronti, prendete in considerazione la possibilità di parlare a una conferenza per promuovere il vostro progetto. Le conferenze possono aiutarvi a raggiungere più persone, a volte da tutto il mondo. + +Cercate conferenze specifiche per la vostra lingua o il vostro ecosistema. Prima di presentare il vostro intervento, fate una ricerca sulla conferenza per adattare il vostro intervento ai partecipanti e aumentare le possibilità di essere accettati a parlare alla conferenza. Spesso è possibile farsi un'idea del proprio pubblico osservando i relatori di una conferenza. + + + +## Costruisci una reputazione + +Oltre alle strategie descritte sopra, il modo migliore per invitare le persone a condividere e contribuire al vostro progetto è quello di condividere e contribuire ai loro progetti. + +Aiutare i nuovi arrivati, condividere le risorse e dare contributi ponderati ai progetti degli altri vi aiuterà a costruire una reputazione positiva. Essere un membro attivo della comunità open source aiuterà le persone ad avere un contesto per il vostro lavoro e sarà più probabile che prestino attenzione al vostro progetto e lo condividano. Lo sviluppo di relazioni con altri progetti open source può persino portare a collaborazioni ufficiali. + + + +Non è mai troppo presto o troppo tardi per iniziare a costruire la propria reputazione. Anche se avete già lanciato il vostro progetto, continuate a cercare modi per aiutare gli altri. + +Non esiste una soluzione immediata per costruire un pubblico. Guadagnare la fiducia e il rispetto degli altri richiede tempo e la costruzione della vostra reputazione non finisce mai. + +## Continuate così! + +Potrebbe volerci molto tempo prima che le persone notino il vostro progetto open source. Non c'è problema! Alcuni dei progetti più popolari oggi hanno impiegato anni per raggiungere alti livelli di attività. Concentratevi sulla costruzione di relazioni invece di sperare che il vostro progetto acquisisca spontaneamente popolarità. Siate pazienti e continuate a condividere il vostro lavoro con chi lo apprezza. \ No newline at end of file