From 95b552c5a39d604e5ca6f9a512b68311e1372957 Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Thu, 16 May 2024 18:35:20 +0200 Subject: [PATCH 1/9] add Italian translation --- _articles/it/best-practices.md | 275 +++++++++ _articles/it/building-community.md | 276 +++++++++ _articles/it/code-of-conduct.md | 113 ++++ _articles/it/finding-users.md | 148 +++++ _articles/it/getting-paid.md | 178 ++++++ _articles/it/how-to-contribute.md | 526 ++++++++++++++++++ _articles/it/index.html | 7 + _articles/it/leadership-and-governance.md | 156 ++++++ _articles/it/legal.md | 160 ++++++ ...ing-balance-for-open-source-maintainers.md | 220 ++++++++ _articles/it/metrics.md | 128 +++++ _articles/it/starting-a-project.md | 355 ++++++++++++ _data/locales/it.yml | 31 ++ 13 files changed, 2573 insertions(+) create mode 100644 _articles/it/best-practices.md create mode 100644 _articles/it/building-community.md create mode 100644 _articles/it/code-of-conduct.md create mode 100644 _articles/it/finding-users.md create mode 100644 _articles/it/getting-paid.md create mode 100644 _articles/it/how-to-contribute.md create mode 100644 _articles/it/index.html create mode 100644 _articles/it/leadership-and-governance.md create mode 100644 _articles/it/legal.md create mode 100644 _articles/it/maintaining-balance-for-open-source-maintainers.md create mode 100644 _articles/it/metrics.md create mode 100644 _articles/it/starting-a-project.md create mode 100644 _data/locales/it.yml diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md new file mode 100644 index 00000000000..b9128aa7c16 --- /dev/null +++ b/_articles/it/best-practices.md @@ -0,0 +1,275 @@ +--- +lang: it +title: Buone pratiche per i manutentori del codice. +description: Semplificarti la vita come sostenitore dell'open source, dal processo di documentazione fino a ottenere il massimo dalla community. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Cosa significa essere un manutentore del codice? + +Se il tuo lavoro è mantenere un progetto open source utilizzato da molte persone, probabilmente avrai notato che passi più tempo a rispondere alle domande che a programmare. + +Nelle prime fasi di un progetto, trascorri del tempo sperimentando nuove idee e prendendo decisioni in base a ciò che ti piace. Man mano che il tuo progetto cresce in popolarità, ti ritroverai in una situazione in cui lavorerai sempre di più con i tuoi utenti e collaboratori. + +Il mantenimento di un progetto richiede molto più del semplice codice. Questi compiti vengono solitamente trascurati, ma sono altrettanto importanti per un progetto in crescita. Abbiamo messo insieme alcune idee che ti semplificheranno la vita, dal processo di documentazione all'ottenimento del massimo dalla community. + +## Documentare i tuoi processi + +Contrassegnare le procedure è una delle migliori pratiche che puoi seguire come manutentore del codice. + +Documentare non solo chiarisce il tuo pensiero, ma aiuta anche gli altri a capire di cosa hai bisogno o cosa ti aspetti senza nemmeno doverlo chiedere. + +Tenendo conto dei processi, è più facile per te dire di no quando la proposta di qualcuno non si adatta al tuo contesto. Quindi rende anche più facile per altre persone unirsi e aiutare. Non sai mai chi potrebbe leggere o utilizzare il tuo progetto. + +Anche se non sei il tipo che scrive interi paragrafi, annotare i punti chiave è meglio di niente. + +### Chiarire la visione del tuo progetto + +Inizia scrivendo gli obiettivi del tuo progetto. Aggiungili al tuo file README o crea un file separato chiamato VISION. Se ci sono altri elementi che possono essere d'aiuto, come una mappa di progetto, rendili pubblici. + +Avere una visione chiara e documentata ti mantiene concentrato e aiuta a evitare malintesi sull'ambito da parte di altri contributori. + +Per esempio: +@lord ha scoperto che avere una visione del progetto lo ha aiutato a capire a quali richieste dare priorità. Essendo un sostenitore del codice alle prime armi, si è lamentato di non essere fedele allo scopo del progetto quando ha ricevuto la tua prima richiesta di funzionalità [Slate](https://github.com/lord/slate). + + + +### Comunica le tue aspettative + +A volte può essere difficile formulare le regole in modo che altre persone possano contribuire. Potresti avere la sensazione di comportarti come un poliziotto o di rovinare il divertimento degli altri. + +Tuttavia, le buone regole scritte e applicate in modo equo danno potere ai manutentori del codice. Ti impediscono di farti coinvolgere in cose che non vuoi fare. + +La maggior parte delle persone che incontrano il tuo progetto non sanno nulla di te o delle tue circostanze. Potrebbero presumere che tu sia pagato per lavorarci, soprattutto se è qualcosa che usano e da cui dipendono regolarmente. Forse una volta dedicavi molto tempo al tuo progetto, ma ora sei impegnato con un nuovo lavoro o con un membro della famiglia. + +Va tutto bene! Assicurati solo che la gente lo sappia. + +Sia che il mantenimento del tuo progetto sia part-time o solo volontario, sii onesto su quanto tempo hai. Questo non è lo stesso di quanto tempo pensi che richiederà il progetto o di quanto tempo gli altri vogliono che tu spenda. + +Ecco alcune regole che vale la pena tenere a mente: + +* Come viene esaminato e accettato l'input (_Hai bisogno di fare qualche test? Qualche modello da utilizzare per i problemi?_) +* I tipi di contributi che accetterai (_Vuoi aiuto solo con una parte del codice?_) +* Quando è opportuno dare seguito (_ad esempio "Puoi aspettarti una risposta dal supporto del codice entro i prossimi 7 giorni. Se non hai ricevuto alcuna risposta entro allora, sentiti libero di eseguire il ping del thread."_) +*Quanto tempo dedichi al progetto (_es. "Investiamo solo circa 5 ore settimanali in 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) questi sono alcuni esempi di progetti con regole chiare per manutentori e contributori. + +### Mantenere la comunicazione pubblica + +Non dimenticare di documentare anche le tue interazioni. Dove puoi, mantieni la comunicazione pubblica sul tuo progetto. Se qualcuno tenta di contattarti personalmente per discutere di una richiesta di funzionalità o di un'esigenza di supporto, indirizzalo educatamente a un canale di comunicazione pubblico, come un elenco di posta elettronica o un tracker dei problemi. + +Se incontri altri sostenitori o prendi decisioni importanti in privato, documenta tali conversazioni pubblicamente, anche se pubblichi solo i tuoi appunti. + +In questo modo, chiunque si unisca alla tua comunità avrà accesso alle stesse informazioni di chi è stato lì. Per anni. + +## Impara a dire di "No" + +Hai scritto tu la roba. Idealmente, tutti leggeranno la tua documentazione, ma in realtà dovrai ricordare agli altri che questa conoscenza esiste. + +Tuttavia, avere tutto scritto aiuta a spersonalizzare le situazioni in cui le regole devono essere applicate. + +Dire di no non è divertente, ma _"Il tuo contributo non soddisfa i criteri per questo progetto"_ sembra meno personale di _"Non mi piace il tuo contributo"_. + +Dire "no" si applica a molte situazioni che incontrerai come sostenitore del codice: richieste di funzionalità che non rientrano nell'ambito, qualcuno che deraglia una discussione, che fa lavoro non necessario per altri. + +### Mantieni la conversazione amichevole + +Uno dei posti più importanti in cui ti eserciterai a dire di no è nella coda di rilascio e richiesta pull. Come project manager, riceverai inevitabilmente proposte che non vuoi accettare. + +Forse il contributo cambia la portata del tuo progetto o non si adatta alla tua visione. Forse l'idea è buona, ma la realizzazione è pessima. + +Indipendentemente dal motivo, puoi gestire con tatto i contributi che non soddisfano gli standard del progetto. + +Se ricevi un messaggio che non vuoi accettare, la tua prima reazione potrebbe essere quella di ignorarlo o di far finta di non averlo visto. Ciò può ferire i sentimenti dell'altra persona e persino scoraggiare altri potenziali contributori nella tua comunità. + + + +Non lasciare aperto un contributo non richiesto perché ti senti in colpa o vuoi essere gentile. Nel corso del tempo, le tue domande senza risposta e le tue PR diventeranno ridondanti. Ciò renderà il lavoro sul tuo progetto molto più stressante e imbarazzante. + +È meglio chiudere immediatamente i contributi che sai di non voler accettare. Se il tuo progetto soffre già di un ampio arretrato o di un elenco di funzionalità da implementare, @steveklabnik ha suggerimenti su [come selezionare le domande in modo efficace](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +In secondo luogo, ignorare i contributi invia un segnale negativo alla tua comunità. Contribuire a un progetto può essere intimidatorio, soprattutto se è la prima volta per qualcuno. Anche se non accetti il ​​loro contributo, congratulati con la persona che sta dietro al progetto e ringraziala per il suo interesse. È un grande complimento! + +Se non desideri accettare una donazione: + +* **Grazie** per il loro contributo. +* **Spiegare perché non soddisfa** l'ambito del progetto e offrire chiari suggerimenti per il miglioramento, se possibile. Lo so, gentile ma fermo. +* **Condividi informazioni rilevanti** se ne hai. Se noti ripetute richieste di cose che non vuoi accettare, aggiungile alla tua documentazione per evitare di spiegare sempre la stessa cosa. +* **Chiudi la richiesta** + +Non dovresti avere più di 1-2 frasi a cui rispondere. Ad esempio, quando un utente [celery](https://github.com/celery/celery/) segnalato un errore relativo a Windows, @berkerpeksag [lui a risposto con](https://github.com/celery/celery/issues/3383): + +[celery screenshot](/assets/images/best-practices/celery.png) + +Se l’idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Ho parlato con manutentori del codice di molti diversi progetti open source, Mesos, Kubernetes, Chromium, e sono tutti d'accordo sul fatto che una delle parti più difficili dell'essere un manutentore del codice è: dire "No" alle patch che non vuoi utilizzare + +Non sentirti in colpa per non voler accettare il contributo di qualcuno. La prima regola dell'open source, [secondo](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No, è temporaneo; sì, è per sempre."_ Sebbene martirizzare l'entusiasmo di un'altra persona sia una buona cosa, rifiutare un contributo non è la stessa cosa che rifiutare la persona che sta dietro ad esso. + +Dopotutto, se un contributo non è abbastanza buono, non sei obbligato ad accettarlo. So che sii gentile e accomodante quando le persone contribuiscono al tuo progetto, ma accetta solo i cambiamenti che ritieni veramente miglioreranno il tuo progetto. Più ti eserciti a dire di no, più diventa facile. È una promessa. + +### Sii proattivo + +Per ridurre innanzitutto il volume dei contributi non richiesti, spiega il processo del tuo progetto per l'invio e l'accettazione dei contributi nella guida ai contributi. + +Se ricevi troppi contributi di bassa qualità, chiedi ai contributori di svolgere del lavoro in anticipo, ad esempio: + +* Completa un modello o un elenco di controllo per problemi o PR +*Apri un problema prima di inviare un PR + +Se non seguono le tue regole, chiudi immediatamente il problema e indirizzali alla tua documentazione. + +Sebbene questo approccio possa sembrare inizialmente imbarazzante, essere proattivi è in realtà positivo per entrambe le parti. Riduci la possibilità che qualcuno investa molte ore di lavoro sprecato su una richiesta pull che non accetti. E semplifica la gestione del carico. + + + +A volte, quando dici di no, il tuo potenziale collaboratore potrebbe arrabbiarsi o criticare la tua decisione. Se il tuo comportamento diventa ostile, [prendi provvedimenti per disinnescare la situazione](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) o addirittura rimuoverli dalla tua comunità se non sono disposti a collaborare in modo costruttivo. + +### Scegli il tutoraggio + +Forse qualcuno nella tua comunità invia regolarmente contributi che non soddisfano gli standard del tuo progetto. Può essere frustrante per entrambe le parti sottoporsi ripetutamente al processo di rifiuto. + +Se vedi qualcuno che ti entusiasma, ma ha bisogno di un po' di pratica, sii paziente. In ogni situazione, spiega chiaramente il motivo. il loro contributo non soddisfa le aspettative del progetto. Prova a dare loro un compito più semplice o meno ambiguo, come un problema etichettato come "buon primo problema" per riscaldarli. Se hai tempo, valuta la possibilità di fare da mentore tramite il tuo primo contributo o trova qualcun altro nella tua comunità che sia interessato. pronto ad istruirli. + +##Utilizzo della comunità + +Non devi fare tutto da solo. La tua community di progetto esiste per un motivo! Anche se non hai ancora una comunità attiva di contributori, se hai molti utenti, lasciali lavorare. + +### Condividi il carico + +Se stai cercando altri a cui unirsi, inizia chiedendo in giro. + +Quando vedi nuovi contributori che contribuiscono ripetutamente, dovresti riconoscere il loro lavoro offrendo loro maggiori responsabilità. Documenta come gli altri possono ottenere ruoli di leadership, se lo desiderano. + +Incoraggiare gli altri a [condividere la proprietà del progetto](../building-community/#condividi-la-proprietà-del-tuo-progetto) può ridurre significativamente il carico di lavoro, come ha trovato @lmccart nel suo progetto, [p5.js](https://github.com/processing/p5.js). + + + +Se hai bisogno di allontanarti dal tuo progetto, temporaneamente o permanentemente, non c'è vergogna nel chiedere a qualcun altro di subentrare al tuo posto. + +Se altre persone sono entusiaste della direzione del progetto, dai loro il permesso di essere coinvolte o di cedere formalmente il controllo a qualcun altro. Se qualcuno crea un fork del tuo progetto e questo viene mantenuto attivamente da qualche altra parte, considera di collegare il fork dal tuo progetto originale. È fantastico che così tante persone vogliano che il tuo progetto venga sviluppato! + +@progrium [trovato quello](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documentare la visione del tuo progetto, [Dokku](https://github.com/dokku/dokku), aiutare questi obiettivi a continuare, anche oltre ciò che resta del progetto: + +> Ho scritto una pagina wiki che descrive cosa voglio e perché lo voglio. Per qualche motivo sono rimasto sorpreso da questo! Lasciamo che i manutentori inizino a muovere il progetto in questa direzione! È successo? Come lo faresti esattamente? Non sempre. Ma comunque sia stato affrontato, ho realizzato il progetto come volevo. + +### Lascia che siano gli altri a creare le soluzioni di cui hanno bisogno + +Se un potenziale collaboratore ha un'opinione diversa su ciò che dovrebbe fare il tuo progetto, potresti dover incoraggiarlo gentilmente a lavorare sul proprio fork. + +Biforcare un progetto non è necessariamente una cosa negativa. Essere in grado di copiare e modificare progetti è una delle cose migliori dell'open source. Incoraggiare i membri della tua comunità a lavorare sul proprio fork può fornire lo sbocco creativo di cui hanno bisogno senza entrare in conflitto con la visione del tuo progetto. + + + +Lo stesso vale per un utente che desidera davvero una soluzione che semplicemente non hai la capacità di creare. Offrire API e hook personalizzati può aiutare gli altri a soddisfare le proprie esigenze senza dover modificare direttamente la fonte. +@orta [ha trovato che](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) incoraggiando i plugin CocoaPods ad "alcune delle idee più interessanti": + +> È quasi inevitabile che una volta che un progetto diventa grande, i manutentori debbano essere molto più conservatori su come introdurre il nuovo codice. Sai dire di no, ma molte persone hanno bisogni legittimi. Pertanto, finisci per trasformare il tuo strumento in una piattaforma. + +## Porta avanti i robot + +Quindi, proprio come ci sono compiti in cui altre persone possono aiutarti, ci sono anche compiti che nessun essere umano dovrebbe svolgere. I robot sono tuoi amici. Usali per semplificarti la vita come manutentore del codice. + +### Richiedi test e altri controlli per migliorare la qualità del tuo codice + +Uno dei modi più importanti per automatizzare il tuo progetto è attraverso i test. + +I test aiutano i contributori a sentirsi sicuri che non romperanno nulla. Inoltre, facilitano la revisione e l'accettazione rapida dei contributi. Più sei ricettivo, più sarai coinvolto. sii la tua comunità. + +Imposta test automatizzati per eseguire tutti i contributi in arrivo e garantire che possano essere eseguiti localmente dai contributori. È necessario che tutti i contributi al codice superino i test prima di poter essere inviati. Contribuirà a stabilire uno standard minimo di qualità per tutte le applicazioni. +[Sono necessari controlli sullo stato](https://help.github.com/articles/about-required-status-checks/) su GitHub può aiutare a garantire che nessuna modifica venga unita senza prima eseguire i test. + +Se aggiungi test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTING. + + + +### Utilizza strumenti per automatizzare le attività di manutenzione di base + +La buona notizia nel mantenere un progetto popolare è che altri manutentori hanno probabilmente riscontrato problemi simili e hanno creato una soluzione per questo. + +Sono disponibili [vari strumenti](https://github.com/showcases/tools-for-open-source) per automatizzare alcuni aspetti del lavoro di manutenzione. Alcuni esempi: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatizzare i tuoi rilasci +* [mention-bot](https://github.com/facebook/mention-bot) menzionare possibili revisori per le richieste del timone +* [Danger](https://github.com/danger/danger) aiuta ad automatizzare la revisione del codice + +Per segnalazioni di bug e altri contributi generali, GitHub dispone di [modelli di richiesta di rilascio e pull](https://github.com/blog/2111-issue-and-pull-request-templates), che puoi creare per semplificare la comunicazione che ricevi. Puoi anche configurare [filtri email](https://github.com/blog/2203-email-updates-about-your-own-activity) per gestire le tue notifiche email. + +Se vuoi diventare un po' più avanzato, le guide di stile possono standardizzare i contributi del progetto e renderli più facili da rivedere e adottare. + +Tuttavia, se i tuoi standard sono troppo complessi, possono aumentare gli ostacoli alla contribuzione. Assicurati di aggiungere solo regole per rendere la vita più semplice a tutti. + +Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l’utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target. + +## È una bella pausa + +Il lavoro open source una volta ti dava gioia. Forse ora è così che iniziano a farti sentire evasivo o colpevole. + +Forse ti senti sopraffatto o provi un crescente senso di paura quando pensi ai tuoi progetti. E nel frattempo si accumulano problemi e pull request. + +Il burnout è un problema reale e pervasivo nel lavoro open source, soprattutto tra i manutentori. In qualità di manutentore, la tua felicità è un requisito non negoziabile per la sopravvivenza di qualsiasi progetto open source. + +Anche se dovrebbe essere ovvio, prenditi una pausa! Non devi aspettare finché non ti senti stanco per fare una pausa. @brettcannon, uno sviluppatore Python, ha deciso di prendersi una [mese di vacanza](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) dopo 14 anni OSS volantariato. + +Come qualsiasi altro tipo di lavoro, fare delle pause regolari ti manterrà motivato. freschi, felici ed entusiasti del loro lavoro. + + + +A volte può essere difficile prendersi una pausa dal lavoro open source quando ritieni che il mondo intero abbia bisogno di te. Le persone potrebbero anche provare a farti sentire in colpa per esserti allontanato. + +Fai del tuo meglio per trovare supporto per i tuoi utenti e la tua comunità mentre sei lontano da un progetto. Se non riesci a trovare il supporto di cui hai bisogno, prenditi comunque una pausa. Ricordati di comunicare quando non sei disponibile in modo che le persone non si sentano confuse dalla tua mancanza di reattività. + +Fare le vacanze è qualcosa di più delle semplici vacanze. Se non vuoi lavorare con l'open source nei fine settimana o durante l'orario lavorativo, comunica queste decisioni ad altri in modo che sappiano che non sarai disturbato. + +## Prenditi cura di te prima! + +Mantenere un progetto popolare richiede competenze diverse rispetto alle prime fasi di crescita, ma non è per questo meno gratificante. In qualità di manutentore, eserciterai le capacità di leadership e di gestione delle persone a un livello che poche persone possono sperimentare. Anche se non è sempre facile da gestire, stabilire dei limiti chiari e prendere solo ciò che ti fa sentire a tuo agio ti aiuterà. per mantenerti felice, aggiornato e produttivo. \ No newline at end of file diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md new file mode 100644 index 00000000000..ca9bbc4b76a --- /dev/null +++ b/_articles/it/building-community.md @@ -0,0 +1,276 @@ +--- +lang: it +title: Costruire comunità accoglienti +description: Costruire una comunità che incoraggi le persone a utilizzare, contribuire ed educare con il tuo progetto +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Prepara il tuo progetto per il successo + +Hai appena lanciato il tuo progetto, stai spargendo la voce e le persone ti seguono. Brillante! Ora, come fai a farli restare? + +Una comunità accogliente è un investimento sul futuro del tuo progetto e della tua reputazione. Se il tuo progetto sta appena iniziando a vedere i primi contributi, inizia offrendo ai primi contributori un'esperienza positiva e rendendo facile per loro continuare a tornare. + +### Fai sentire le persone benvenute + +Un modo di pensare alla community del tuo progetto è attraverso quello che @MikeMcQuaid chiama [funnel del collaboratore](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Canalizzazione del collaboratore](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Mentre costruisci la tua community, considera come qualcuno in cima alla canalizzazione (un potenziale utente) potrebbe teoricamente scendere verso il basso (un sostenitore attivo). Il tuo obiettivo è ridurre l'attrito in ogni fase dell'esperienza associata. Quando le persone ottengono vittorie facili, saranno motivate a fare di più. + +Inizia con la tua documentazione: + +* **Semplifica le cose per coloro che hanno bisogno di utilizzare il progetto.** [Documento README intuitivo](../starting-a-project/#scrivi-readme) e chiari esempi di codice lo renderanno facile da usare. È un inizio facile per chiunque si imbatta nel tuo progetto. +* **Spiega chiaramente come contribuire** utilizzando [CONTRIBUTING file](../starting-a-project/#scrivi-le-linee-guida-per-il-tuo-contributo) e mantieni aggiornati i tuoi problemi. +* **Buone prime edizioni**: per aiutare i nuovi contributori a iniziare, pensa chiaramente a [sottolineare gli argomenti che sono abbastanza semplici da poter essere gestiti da un principiante](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub mostrerà quindi questi problemi in vari punti della piattaforma, aumentando i contributi utili e riducendo la pressione degli utenti che affrontano questioni troppo difficili per il loro livello. + +[Sondaggio open source GitHub 2017](http://opensourcesurvey.org/2017/) ha dimostrato che la documentazione incompleta o confusa è il problema più grande per gli utenti open source. Una buona documentazione invita le persone a interagire con il tuo progetto. Alla fine, qualcuno aprirà un problema o una richiesta. Usa queste interazioni come opportunità per spostarle lungo la canalizzazione. + +* **Quando qualcuno di nuovo si unisce al tuo progetto, ringrazialo per il suo interesse!** Basta un'esperienza negativa per far sì che qualcuno non voglia più tornare. +* **Sii reattivo.** Se non rispondi alla loro domanda per un mese, è probabile che si siano già dimenticati del tuo progetto. +* **Sii di mentalità aperta riguardo ai tipi di contributi che accetti.** Molti contributori iniziano segnalando un bug o apportando una piccola correzione. Ci sono [molti modi per contribuire](../how-to-contribute/#cosa-significa-contribuire) ad un progetto. Lascia che le persone aiutino nel modo in cui vogliono aiutare. +* **Se c'è un contributo con cui non sei d'accordo,** ringrazialo per la sua idea e [spiegate perchè](../best-practices/#impara-a-dire-di-no) non soddisfa lo scopo del progetto, con un collegamento alla documentazione pertinente, se disponibile. + + + +La maggior parte dei contributori open source sono "collaboratori occasionali": persone che contribuiscono a un progetto solo occasionalmente. Un collaboratore occasionale potrebbe non avere il tempo di familiarizzare completamente con il tuo progetto, quindi il tuo compito è facilitare il suo contributo. + +Incoraggiare altri contributori è anche un investimento su te stesso. Quando permetti ai tuoi più grandi fan di lavorare sul lavoro che li appassiona, c'è meno pressione nel dover fare tutto da solo. + +### Documenta tutto + + + +Quando si inizia un nuovo progetto, può sembrare naturale mantenere segreto il proprio lavoro. Ma i progetti open source prosperano quando documenti pubblicamente il tuo processo. + +Quando documenti le cose, più persone possono essere coinvolte in ogni fase del processo. Potresti ricevere aiuto per qualcosa di cui non sapevi nemmeno di aver bisogno. + +Annotare le cose significa molto più che una semplice documentazione tecnica. Ogni volta che senti il ​​bisogno di scrivere qualcosa o discutere del tuo lavoro in privato, chiediti se puoi renderlo pubblico. + +Sii trasparente riguardo alla roadmap del tuo progetto, ai tipi di contributi che stai cercando, a come vengono considerati i contributi o al motivo per cui hai preso determinate decisioni. + +Se noti che molti utenti hanno lo stesso problema, documenta le risposte nel README. + +Per le riunioni, valuta la possibilità di pubblicare i tuoi appunti o i tuoi appunti in un thread correlato. Il feedback che otterrai da questo livello di trasparenza potrebbe sorprenderti. + +Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall’inizio nel processo. + +### Sii reattivo + +Mentre [promuovi il tuo progetto](../finding-users), le persone avranno feedback su di te. Potrebbero avere domande su come funzionano le cose o aver bisogno di aiuto per iniziare. + +Cerca di essere reattivo quando qualcuno segnala un problema, invia una richiesta pull o pone una domanda sul tuo progetto. Quando rispondi rapidamente, le persone si sentiranno parte di un dialogo e saranno più entusiaste di partecipare. + +Anche se non puoi esaminare immediatamente la richiesta, confermarla tempestivamente aiuta ad aumentare il coinvolgimento. Ecco come @tdreyno ha risposto a una richiesta pull su [Middleman](https://github.com/middleman/middleman/pull/1466): + +![Middleman richiesta di download](/assets/images/building-community/middleman_pr.png) + +[Questo è ciò che ha scoperto uno studio Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) i contributori che hanno ricevuto revisioni del codice entro 48 ore hanno avuto un tasso di rendimento e ricontribuzione molto più elevato. + +Le discussioni sul tuo progetto potrebbero svolgersi anche altrove sul Web, come Stack Overflow, Twitter o Reddit. Puoi impostare le notifiche in alcuni di questi luoghi in modo da ricevere una notifica quando qualcuno menziona il tuo progetto. + +### Offri alla tua comunità un luogo in cui riunirsi + +Ci sono due ragioni per dare alla tua comunità un luogo in cui riunirsi. + +Il primo motivo è per loro. Aiuta le persone a conoscersi. Le persone con interessi comuni vorranno inevitabilmente un posto dove parlarne. E quando la comunicazione è pubblica e accessibile, chiunque può leggere gli archivi del passato per imparare e partecipare. + +Il secondo motivo è per te. Se non offri alle persone un luogo pubblico in cui parlare del tuo progetto, probabilmente ti contatteranno direttamente. All'inizio può sembrare abbastanza semplice rispondere ai messaggi privati ​​"solo per questa volta". Ma col tempo, soprattutto se il tuo progetto diventa popolare, ti sentirai esausto. Resisti alla tentazione di comunicare in privato con le persone riguardo al tuo progetto. Indirizzali invece a un canale pubblico specifico. + +La comunicazione pubblica può essere semplice come invitare le persone ad aprire un problema invece di inviarti direttamente un'e-mail o commentare sul tuo blog. Puoi anche impostare una mailing list o creare un account Twitter, Slack o un canale IRC affinché le persone possano parlare del tuo progetto. Oppure prova tutto quanto sopra! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) dedica ore di lavoro ogni due settimane per aiutare i membri della comunità: + +> Kops inoltre dedica del tempo ogni settimana per offrire aiuto e guida alla comunità. I manutentori di Kops hanno concordato di dedicare del tempo specificatamente dedicato al lavoro con i nuovi arrivati, aiutando con le PR e discutendo le nuove funzionalità. + +Eccezioni notevoli alla comunicazione pubblica sono: 1) questioni di sicurezza e 2) violazioni sensibili del codice di condotta. Dovresti sempre avere la possibilità che le persone possano segnalare questi problemi di persona. Se non desideri utilizzare la tua email personale, imposta un indirizzo email dedicato. + +## Fai crescere la tua comunità + +Le comunità sono estremamente forti. Questo potere può essere una benedizione o una maledizione, a seconda di come lo eserciti. Man mano che la community del tuo progetto cresce, ci sono modi per aiutarla a diventare una forza di costruzione, non di demolizione. + +### Non tollerare i cattivi attori + +Qualsiasi progetto popolare attirerà inevitabilmente persone che danneggiano, non aiutano, la tua comunità. Potrebbero avviare dibattiti non necessari, discutere su aspetti banali o fare il prepotente con gli altri. + +Fai del tuo meglio per adottare una politica di tolleranza zero nei confronti di questo tipo di persone. Se lasciate senza controllo, le persone negative metteranno a disagio le altre persone nella tua comunità. Potrebbero anche andarsene. + + + +Discussioni regolari su aspetti banali del tuo progetto distraggono gli altri, te compreso, dal concentrarsi su compiti importanti. Le nuove persone che arrivano al tuo progetto potrebbero vedere queste conversazioni e non voler partecipare. + +Quando vedi che si verifica un comportamento negativo, fai un'osservazione pubblica al riguardo. Spiegare in tono amichevole perché tale comportamento non è accettabile. Se il problema persiste, potrebbe essere necessario [chiedergli di andarsene](../code-of-conduct/#le-tue-responsabilità-come-manutentore). Il tuo [codice di condotta](../code-of-conduct/) può essere una guida costruttiva per queste conversazioni. + +### Incontra i contributori ovunque si trovino + +Una buona documentazione diventa sempre più importante man mano che la tua comunità cresce. I contributori occasionali che altrimenti potrebbero non avere familiarità con il tuo progetto leggono la tua documentazione per ottenere rapidamente il contesto di cui hanno bisogno. + +Nel tuo file CONTRIBUTING, indica esplicitamente ai nuovi contributori come iniziare. Potresti anche voler creare una sezione speciale per questo scopo. [Django](https://github.com/django/django), ad esempio, ha una pagina di destinazione speciale per accogliere i nuovi contributori. + +![Django pagin acon i nuovi contributori](/assets/images/building-community/django_new_contributors.png) + +Nella coda degli argomenti, contrassegna i bug appropriati per i diversi tipi di contributori: ad esempio [_"per principianti"_](https://kentcdodds.com/blog/first-timers-only), _"buon primo argomento"_ o _"documentazione"_. [Questi appunti](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) rendi facile per qualcuno che non conosce il tuo progetto scansionare rapidamente i tuoi argomenti e iniziare. + +Infine, usa la tua documentazione per far sentire le persone benvenute in ogni fase del processo. + +Non interagirai mai con la maggior parte delle persone che saranno coinvolte nel tuo progetto. Potrebbero esserci contributi che non hai ricevuto perché qualcuno si è sentito intimidito o non sapeva da dove cominciare. Anche poche parole gentili possono evitare che qualcuno lasci deluso il tuo progetto. + +Ad esempio, ecco come [Rubinius](https://github.com/rubinius/rubinius/) ha iniziato [la sua guida che contribuisce](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Vogliamo iniziare ringraziandoti per aver utilizzato Rubinius. Questo progetto è un lavoro d'amore e apprezziamo tutti gli utenti che rilevano bug, apportano miglioramenti alle prestazioni e aiutano con la documentazione. Ogni contributo conta, quindi grazie per aver partecipato. Tenendo questo a mente, ecco alcune linee guida che ti chiediamo di seguire per poter risolvere con successo il tuo problema. + +### Condividi la proprietà del tuo progetto + + + +Le persone sono entusiaste di contribuire ai progetti quando sentono un senso di appartenenza. Ciò non significa che devi stravolgere la visione del tuo progetto o accettare input che non desideri. Ma più riconosci gli altri, più rimarranno presenti. + +Vedi se riesci a trovare modi per condividere il più possibile la proprietà con la tua comunità. Ecco alcune idee: + +* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All’inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo. + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Avvia un file CONTRIBUTORI o AUTORI nel tuo progetto** che elenca tutti coloro che hanno contribuito al tuo progetto come [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Se hai una community numerosa, **invia una newsletter o scrivi un post sul blog** ringraziando i contributori. [This Week in Rust](https://this-week-in-rust.org/) di Rust e [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) di Hood sono due ottimi esempi. + +* **Concedi l'accesso al commit a ogni collaboratore.** @felixge ha scoperto che rendeva le persone [più entusiaste di migliorare le proprie soluzioni](https://felixge.de/2013/03/11/the-pull -request-hack. html) e ha anche trovato nuovi manutentori per progetti su cui non lavorava da un po'. + +* Se il tuo progetto è su GitHub, **sposta il tuo progetto dal tuo account personale a [Organizzazione](https://help.github.com/articles/creating-a-new-organization-account/)** e aggiungilo a almeno un amministratore di backup. Le organizzazioni facilitano il lavoro di progetto con collaboratori esterni. + +La realtà è che [la maggior parte dei progetti ha solo](https://peerj.com/preprints/1233/) uno o due manutentori che svolgono la maggior parte del lavoro. Più grande è il tuo progetto e la tua comunità, più facile sarà trovare aiuto. + +Anche se potresti non trovare sempre qualcuno che risponda alla chiamata, diffondere il segnale aumenta le possibilità che altre persone vengano coinvolte. E prima inizi, prima le persone potranno aiutarti. + + + +## Risoluzione dei conflitti + +Nelle prime fasi del tuo progetto, prendere decisioni importanti è facile. Quando vuoi fare qualcosa, fallo e basta. + +Man mano che il tuo progetto diventa più popolare, sempre più persone saranno interessate alle decisioni che prendi. Anche se non hai una grande comunità di contributori, se il tuo progetto ha molti utenti, troverai persone che valutano soluzioni o sollevano i propri problemi. + +Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po’ più difficile da risolvere. + +### Stabilisci lo standard di civiltà + +Quando la tua comunità è alle prese con una questione difficile, il morale può risollevarsi. Le persone potrebbero arrabbiarsi o frustrarsi e prendersela con gli altri o con te. + +Il tuo compito come sostenitore è evitare che queste situazioni peggiorino. Anche se hai una forte opinione sulla questione, prova ad assumere la posizione di moderatore o facilitatore invece di buttarti nella mischia e promuovere le tue opinioni. Se qualcuno è scortese o monopolizza la conversazione, [agisci immediatamente](../building-community/#non-tollerare-i-cattivi-attori) per mantenere la discussione civile e produttiva. + + + +Altre persone si rivolgono a te per avere una guida. Dai il buon esempio. Puoi ancora esprimere frustrazione, infelicità o preoccupazione, ma fallo con calma. + +Mantenere la calma non è facile, ma mostrare leadership migliora la salute della tua comunità. Internet ti ringrazia. + +### Tratta il tuo README come una costituzione + +Il tuo README è [più di un semplice insieme di istruzioni](../starting-a-project/#scrivi-readme). È anche un luogo in cui parlare dei tuoi obiettivi, della visione del prodotto e della tabella di marcia. Se le persone sono troppo concentrate nel discutere i meriti di una particolare funzionalità, potrebbe essere utile rivisitare il tuo README e parlare della visione più elevata del tuo progetto. Concentrarsi sul README spersonalizza anche la conversazione in modo da poter avere una discussione costruttiva. + +### Concentrati sul viaggio, non sulla destinazione + +Alcuni progetti utilizzano un processo di voto per prendere decisioni importanti. Anche se a prima vista ragionevole, il voto enfatizza il raggiungimento di una "risposta" piuttosto che l'ascolto e la considerazione delle preoccupazioni degli altri. + +Il voto può diventare politico quando i membri della comunità si sentono spinti a fare favori o a votare in un certo modo. Non tutti votano, siano essi [la 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 tra gli utenti attuali che non sapevano che fosse in corso una votazione. + +A volte è richiesto un voto di parità. Tuttavia, per quanto puoi, enfatizza ["la ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), piuttosto che consenso. + +In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all’ascolto e alla discussione. + + + +Anche se in realtà non adotti un processo di ricerca del consenso, come progetto di supporto è importante che le persone sappiano che stai ascoltando. Far sì che le altre persone si sentano ascoltate e impegnate a risolvere le loro preoccupazioni è molto utile per allentare la tensione in situazioni delicate. Quindi segui le tue parole con l'azione. + +Non affrettarti a prendere una decisione per il gusto di prendere una decisione. Assicurati che tutti si sentano ascoltati e che tutte le informazioni siano condivise prima di passare a una decisione. + +### Mantieni la conversazione focalizzata sull'azione + +La discussione è importante, ma esiste una differenza tra conversazioni produttive e improduttive. + +Incoraggiare la discussione fintanto che si muove attivamente verso la risoluzione. Se è chiaro che la conversazione sta morendo o sta andando fuori tema, che il fastidio sta diventando personale o che le persone litigano su dettagli minori, è ora di chiuderla. + +Consentire che queste conversazioni continuino non è solo dannoso per il problema in questione, ma anche per la salute della tua comunità. Invia il messaggio che questo tipo di conversazione è consentito o addirittura incoraggiato e potrebbe scoraggiare le persone dal sollevare o risolvere problemi futuri. + +Per ogni punto sollevato da te o da altri, chiediti: "In che modo questo ci avvicina a una soluzione?"_ + +Se la conversazione inizia a sgretolarsi, chiedi al gruppo _"Quali passi dovremmo intraprendere dopo?"_ per reindirizzare la conversazione. + +Se la conversazione non sta chiaramente andando da nessuna parte, non c'è alcuna azione chiara da intraprendere o l'azione appropriata è già stata intrapresa, chiudi il problema e spiega perché l'hai chiuso. + + + +### Scegli saggiamente le tue battaglie + +Il contesto è importante. Considera chi partecipa alla conversazione e come rappresenta il resto della comunità. + +Tutti nella comunità sono sconvolti o addirittura preoccupati per questo? Oppure è un piantagrane solitario? Ricorda di considerare i membri silenziosi della tua comunità, non solo le voci attive. + +Se il problema non rappresenta le esigenze più ampie della tua comunità, potresti dover semplicemente accogliere le preoccupazioni di alcune persone. Se si tratta di un problema ricorrente senza una soluzione chiara, rimandali alle discussioni precedenti sull'argomento e chiudi l'argomento. + +### Definire il criterio di equilibrio comunitario + +Con un buon comportamento e una comunicazione chiara, le situazioni più difficili vengono risolte. Tuttavia, anche in una discussione produttiva, potrebbe esserci semplicemente una divergenza di opinioni su come procedere. In questi casi, identifica una persona o un gruppo di persone che possano fungere da equilibratore. + +Un livellatore può essere il principale sostenitore del progetto, oppure può essere un piccolo gruppo di persone che prendono una decisione in base a un voto. Idealmente, è necessario definire un livellatore e la procedura associata in un file GOVERNANCE prima di doverlo utilizzare. + +La decisione sulla parità dovrebbe essere l'ultima risorsa. Le questioni di divisione rappresentano un’opportunità per la tua comunità di crescere e imparare. Cogli queste opportunità e utilizza un processo collaborativo per procedere verso la risoluzione quando possibile. + +## La community è ❤️ open source + +Comunità sane e fiorenti alimentano le migliaia di ore investite ogni settimana nell'open source. Molti contributori citano altre persone come motivo per lavorare - o non lavorare - con l'open source. Imparando a sfruttare questo potere in modo costruttivo, aiuterai qualcuno a vivere un'esperienza open source indimenticabile. diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md new file mode 100644 index 00000000000..1459c665d5e --- /dev/null +++ b/_articles/it/code-of-conduct.md @@ -0,0 +1,113 @@ +--- +lang: it +title: Il tuo codice di condotta +description: Facilitare un comportamento comunitario sano e costruttivo adottando e applicando un codice di condotta. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Perché ho bisogno di un codice di condotta? + +Un codice di condotta è un documento che definisce le aspettative comportamentali dei partecipanti al tuo progetto. L’adozione e l’applicazione di un codice di condotta può contribuire a creare un’atmosfera sociale positiva per la tua comunità. + +I codici di condotta aiutano a proteggere non solo i tuoi partecipanti ma anche te stesso. Se stai portando avanti un progetto, potresti scoprire che l'atteggiamento improduttivo degli altri partecipanti può farti sentire svuotato o insoddisfatto del tuo lavoro nel tempo. + +Un Codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità. Essere proattivi riduce le probabilità che tu o gli altri vi stanchiate del vostro progetto e vi aiuta ad agire quando qualcuno fa qualcosa con cui non siete d'accordo. + +## Stabilire un codice di condotta + +Cerca di creare un codice di condotta il prima possibile: idealmente quando crei per la prima volta il tuo progetto. + +Oltre a comunicare le vostre aspettative, il codice di condotta descrive quanto segue: + +* Dove entra in vigore il codice di condotta _(solo per problemi e pull request o attività della community come eventi?)_ +* A chi si applica il codice di condotta _(membri della comunità e sostenitori, ma per quanto riguarda gli sponsor?)_ +* Cosa succede se qualcuno infrange il codice di condotta +* Come qualcuno può segnalare violazioni + +Usa la tecnica precedente dove puoi. [Accordo dei contributori](https://contributor-covenant.org/) è un codice di comportamento utilizzato da oltre 40.000 progetti open source, inclusi Kubernetes, Rails e Swift. + +[Il codice di condotta di Django](https://www.djangoproject.com/conduct/) e [Il codice di condotta dei cittadini](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sono due buoni esempi di codice di condotta. + +Inserisci un file CODE_OF_CONDUCT nella directory principale del tuo progetto e rendilo visibile alla tua comunità collegandolo dal tuo file CONTRIBUTING o README. + +## Decidi come applicherai il tuo codice di condotta + + +È necessario spiegare come verrà applicato il codice di condotta **_prima_** di una violazione. Ci sono diversi motivi per farlo: + +* Dimostra che sei seriamente intenzionato ad agire quando necessario. + +* La tua comunità si sentirà più sicura che i reclami vengano effettivamente esaminati. + +* Assicurerai alla tua comunità che il processo di revisione è giusto e trasparente nel caso in cui si trovassero indagati per una violazione. + +Dovresti fornire alle persone un modo personale (ad esempio un indirizzo e-mail) per segnalare una violazione del codice di condotta e spiegare chi riceve tale segnalazione. Potrebbe trattarsi di un manutentore, di un gruppo di manutentori o di un gruppo di lavoro sul codice di condotta. + +Ricorda che qualcuno può chiedere di segnalare una violazione a una persona che riceve queste segnalazioni. In questo caso, date loro la possibilità di segnalare le violazioni a qualcun altro. Ad esempio, @ctb e @mr-c [spiegano il loro progetto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Casi di abuso, molestie o comportamenti altrimenti inaccettabili possono essere segnalati inviando un'e-mail a **khmer-project@idyll.org** solo a C. Titus Brown e Michael R. Crusoe. Per segnalare un problema con uno di questi, inviare un'e-mail a **Judi Brown Clarke, Ph.D.** Direttore della Diversità presso il BEACON Center for the Study of Evolution in Action, NSF Science and Technology Center.* + +Per trovare ispirazione, consulta il [manuale di applicazione delle norme](https://www.djangoproject.com/conduct/enforcement-manual/) di Django (anche se potresti non aver bisogno di qualcosa di così completo, a seconda delle dimensioni del tuo progetto). + +## Applicare il codice di condotta + +A volte, nonostante i tuoi migliori sforzi, qualcuno fa qualcosa che viola questo codice. Esistono diversi modi per affrontare un comportamento negativo o dannoso quando si verifica. + +### Raccogli informazioni sulla situazione + +Considera la voce di ogni membro della comunità importante quanto la tua. Se ricevi una segnalazione secondo cui qualcuno ha violato il codice di condotta, prendila sul serio e indaga sulla questione, anche se non corrisponde alla tua esperienza con quella persona. Ciò segnala alla tua comunità che apprezzi la loro prospettiva e ti fidi del loro giudizio. + +Il membro della comunità in questione potrebbe essere un recidivo che mette costantemente a disagio gli altri, o potrebbe aver detto o fatto qualcosa solo una volta. In entrambi i casi, possono costituire motivo di azione a seconda del contesto. + +Prima di rispondere, concediti il ​​tempo di capire cosa è successo. Leggi i commenti e le conversazioni passate della persona per capire meglio chi è e perché potrebbe essersi comportato in quel modo. Prova a raccogliere punti di vista diversi dal tuo su questa persona e sul suo comportamento. + + + +### Intraprendi le azioni appropriate + +Una volta raccolte ed elaborate informazioni sufficienti, dovrai decidere cosa fare. Mentre consideri i passaggi successivi, ricorda che il tuo obiettivo come moderatore è promuovere un ambiente sicuro, rispettoso e collaborativo. Considera non solo come gestire la situazione in questione, ma anche come la tua risposta influenzerà il comportamento e le aspettative del resto della tua comunità in futuro. + +Quando qualcuno segnala una violazione del codice di condotta, è compito tuo, non suo, occupartene. A volte un giornalista rivela informazioni che mettono a grave rischio la sua carriera, reputazione o incolumità fisica. Costringerli ad affrontare il loro aggressore può mettere il giornalista in una posizione compromettente. È necessario mantenere una comunicazione diretta con la persona in questione, a meno che chi ha segnalato non richieda espressamente il contrario. + +Esistono diversi modi per rispondere a una violazione del codice di condotta: + +* **Dai alla persona in questione un avvertimento pubblico** e spiega come il suo comportamento ha influenzato negativamente gli altri, preferibilmente nel canale in cui è successo. Quando possibile, la comunicazione pubblica comunica al resto della comunità che si prende sul serio il codice di condotta. Sii gentile ma fermo nella tua comunicazione. + +* **Contatta di persona la persona in questione** per spiegare in che modo il suo comportamento ha influenzato negativamente gli altri. Potresti voler utilizzare un canale di comunicazione privato se la situazione coinvolge informazioni personali sensibili. Se stai comunicando con qualcuno in privato, è una buona idea mettere in copia coloro che per primi hanno segnalato la situazione in modo che sappiano che hai preso provvedimenti. Chiedere il consenso all'informatore prima di inviarlo in CC. + +A volte non è possibile raggiungere alcuna soluzione. La persona in questione può diventare aggressiva o ostile quando confrontata o non cambiare il proprio comportamento. In questa situazione, potresti prendere in considerazione l’idea di intraprendere azioni più drastiche. Per esempio: + +* **Espulsione della persona in questione** dal progetto, imposta tramite un'interdizione temporanea dalla partecipazione a qualsiasi aspetto del progetto + +* **Permanente** banna la persona dal progetto + +L’esclusione dei membri non dovrebbe essere presa alla leggera e rappresenta una divergenza di opinioni permanente e inconciliabile. Dovresti adottare queste misure solo quando è chiaro che non è possibile raggiungere una soluzione. + +## Le tue responsabilità come manutentore + +Un codice di condotta non è una legge applicata arbitrariamente. Tu sei il garante del codice di condotta ed è tua responsabilità seguire le regole stabilite dal codice di condotta. + +In qualità di manutentore, stabilisci le linee guida per la tua comunità e applichi tali linee guida secondo le regole stabilite nel tuo codice di condotta. Ciò significa prendere sul serio ogni segnalazione di violazione del codice di condotta. Al giornalista è dovuta un'analisi approfondita e corretta della sua denuncia. Se ritieni che il comportamento segnalato non costituisca una violazione, chiariscilo e spiega perché non intendi intraprendere alcuna azione in merito. Ciò che fanno dipende da loro: tollerare il comportamento con cui hanno avuto problemi o smettere di partecipare alla comunità. + +Segnalare un comportamento che _tecnicamente_ non viola il codice di condotta può comunque indicare che c'è un problema nella tua comunità e dovresti indagare su quel potenziale problema e agire di conseguenza. Ciò potrebbe comportare la revisione del codice di condotta per chiarire quale sia il comportamento accettabile e/o parlare alla persona il cui comportamento è stato segnalato e dirle che, sebbene non abbia violato il codice di condotta, sta aggirando il limite di ciò che ci si aspetta e assicurarsi che i partecipanti si sentano a disagio. + +In definitiva, come sostenitore, definisci 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 tali valori in modo giusto ed equo. + +## Incoraggia il comportamento che vuoi vedere nel mondo 🌎 + +Quando un progetto appare ostile o inospitale, anche se si tratta di una sola persona il cui comportamento è tollerato dagli altri, rischi di perdere molti altri contributori, alcuni dei quali potresti non incontrare nemmeno. Non è sempre facile adottare o far rispettare un codice di condotta, ma promuovere un ambiente accogliente aiuterà la tua comunità a crescere. diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md new file mode 100644 index 00000000000..6eedbf024c0 --- /dev/null +++ b/_articles/it/finding-users.md @@ -0,0 +1,148 @@ +--- +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: + - beginners + - building +--- + +## Diffondere la parola + +Non esiste una regola che dice che devi pubblicizzare un progetto open source al momento del lancio. Ci sono molte buone ragioni per passare all'open source che non hanno nulla a che fare con la popolarità. Invece di sperare che altri trovino e utilizzino il tuo progetto open source, dovresti spargere la voce sul tuo duro lavoro! + +## Trasmetti il ​​tuo messaggio + +Prima di iniziare il lavoro vero e proprio di promozione del tuo progetto, devi essere in grado di spiegare cosa fa e perché è importante. + +Cosa rende il tuo progetto diverso o interessante? Perché l'hai creato? Rispondere solo a queste domande ti aiuterà a comunicare l’importanza del tuo progetto. + +Ricorda che le persone vengono coinvolte come utenti e alla fine diventano contributori perché il tuo progetto risolve loro un problema. Mentre pensi al messaggio e al valore del tuo progetto, prova a vederlo attraverso la lente di ciò che _utenti e contributori_ potrebbero desiderare. + +Ad esempio, @robb utilizza 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) + +Per un approfondimento sulla messaggistica, consulta l'esercizio ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) di Mozilla sullo sviluppo dei personaggi degli utenti. + +## Aiuta le persone a trovare e seguire il tuo progetto + + + +Aiuta le persone a trovare e ricordare il tuo progetto indirizzandole a un singolo spazio dei nomi. + +**Avere un approccio chiaro per promuovere il tuo lavoro.** Un handle di Twitter, un URL GitHub o un canale IRC è un modo semplice per indirizzare le persone al tuo progetto. Questi punti vendita forniscono anche un luogo di ritrovo per la crescente comunità del tuo progetto. + +Se ancora non vuoi creare output per il tuo progetto, promuovi il tuo account Twitter o GitHub in tutto ciò che fai. Promuovere il tuo Twitter o GitHub permetterà alle persone di sapere come contattarti o seguire il tuo lavoro. Se parli a una riunione o a un evento, assicurati che le informazioni di contatto siano incluse nella biografia o nelle diapositive. + + + +**Considera l'idea di creare un sito web per il tuo progetto.** Un sito web rende il tuo progetto più user-friendly e facile da navigare, soprattutto se abbinato a documentazione e tutorial chiari. Avere un sito web suggerisce anche che il tuo progetto è attivo, il che farà sentire il tuo pubblico più a suo agio nell'utilizzarlo. Fornisci esempi per dare alle persone idee su come utilizzare il tuo progetto. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), сco-creatore di Django, ha detto che il sito web è stato _"di gran lunga la cosa migliore che abbiamo fatto con Django nei primi giorni"_. + +Se il tuo progetto è ospitato su GitHub, puoi utilizzare [GitHub Pages](https://pages.github.com/) per creare facilmente un sito web. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) e [Middleman](https://middlemanapp.com/) sono [alcuni esempi](https://github.com/showcases/github-pages-examples) di siti Web eccellenti e completi. + +![Pagina iniziale di Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +Ora che hai un annuncio sul tuo progetto e un modo semplice per consentire alle persone di trovarlo, usciamo e parliamo con il tuo pubblico! + +## Vai dove si trova il pubblico del tuo progetto (online) + +La sensibilizzazione online è un ottimo modo per condividere e spargere rapidamente la voce. Utilizzando i canali online, hai il potenziale per raggiungere un pubblico molto vasto. + +Sfrutta le community e le piattaforme online esistenti per raggiungere il tuo pubblico. Se il tuo progetto open source è un progetto software, probabilmente puoi trovare il tuo pubblico in [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 in cui ritieni che le persone trarranno maggiori benefici o saranno entusiaste del tuo lavoro. + + + +Vedi se riesci a trovare modi per condividere il tuo progetto in modi appropriati: + +* **Conosci progetti e comunità open source rilevanti.** A volte non è necessario pubblicizzare direttamente il tuo progetto. Se il tuo progetto è perfetto per i data scientist che utilizzano Python, consulta la community di data science di Python. Man mano che le persone ti conosceranno, ci saranno opportunità naturali per parlare e condividere il tuo lavoro. +* **Trova persone che affrontano il problema risolto dal tuo progetto.** Cerca nei forum correlati le persone che rientrano nel pubblico target del tuo progetto. Rispondi alla loro domanda e trova un modo discreto, se appropriato, per presentare il tuo progetto come soluzione. +* **Chiedi feedback.** Presenta te stesso e il tuo lavoro a un pubblico che lo troverà pertinente e interessante. Sii specifico su chi ritieni trarrà beneficio dal tuo progetto. Prova a completare la frase: _"Penso che il mio progetto aiuterà davvero X persone che stanno cercando di fare Y_". Ascolta e rispondi al feedback degli altri invece di limitarti a promuovere il tuo lavoro. + +In generale, concentrati sull’aiutare gli altri prima di chiedere qualcosa in cambio. Dato che chiunque può facilmente pubblicizzare un progetto online, ci sarà molto fermento. Per distinguerti dalla massa, dai alle persone un contesto su chi sei, non solo cosa vuoi. + +Se nessuno presta attenzione o risponde al tuo contatto iniziale, non scoraggiarti! La maggior parte dei lanci di progetti sono un processo iterativo che può richiedere mesi o anni. Se non ricevi risposta la prima volta, prova una tattica diversa o cerca prima modi per aggiungere valore al lavoro degli altri. Promuovere e lanciare il tuo progetto richiede tempo e dedizione. + +## Vai dove si trova il pubblico del tuo progetto (offline) + +![Discorso pubblico](/assets/images/finding-users/public_speaking.jpg) + +Gli eventi offline sono un modo popolare per promuovere nuovi progetti al pubblico. Sono un ottimo modo per raggiungere un pubblico coinvolto e creare connessioni umane più profonde, soprattutto se sei interessato a raggiungere gli sviluppatori. + +Se sei [nuovo nel parlare in pubblico](https://Speaking.io/), inizia trovando un incontro locale correlato alla lingua o all'ecosistema del tuo progetto. + + + +Se non hai mai parlato a un evento prima, è del tutto normale sentirsi nervoso! Ricorda che il tuo pubblico è lì perché vuole davvero conoscere il tuo lavoro. + +Mentre scrivi il tuo discorso, concentrati su ciò che il tuo pubblico troverà interessante e da cui trarrà beneficio. Mantieni il tuo linguaggio amichevole e accessibile. Sorridi, respira e divertiti. + + + +Quando ti senti pronto, considera di parlare a una conferenza per promuovere il tuo progetto. Le conferenze possono aiutarti a raggiungere più persone, a volte da tutto il mondo. + +Cerca conferenze specifiche per la tua lingua o ecosistema. Prima di inviare il tuo discorso, fai ricerche sulla conferenza per adattare il tuo discorso ai tuoi partecipanti e aumentare le tue possibilità di essere accettato a parlare alla conferenza. Spesso puoi farti un'idea del tuo pubblico guardando i relatori della conferenza. + + + +## Costruisci una reputazione + +Oltre alle strategie sopra descritte, il modo migliore per invitare le persone a condividere e contribuire al tuo progetto è condividere e contribuire ai loro progetti. + +Aiutare i nuovi arrivati, condividere risorse e contribuire in modo ponderato ai progetti di altre persone ti aiuterà a costruire una reputazione positiva. Essere un membro attivo della comunità open source aiuterà le persone a trovare un contesto per il tuo lavoro e ad essere più propense a prestare attenzione e a condividere il tuo progetto. Lo sviluppo di collegamenti con altri progetti open source può anche portare a partenariati formali. + + + +Non è mai troppo presto o troppo tardi per iniziare a costruire la tua reputazione. Anche se hai già avviato il tuo progetto, continua a cercare modi per aiutare gli altri. + +Non esiste una soluzione immediata per creare un pubblico. Guadagnarsi la fiducia e il rispetto degli altri richiede tempo e costruire la propria reputazione non finisce mai. + +## Continuare! + +Può volerci molto tempo prima che le persone notino il tuo progetto open source. Questo è buono! Alcuni dei progetti più popolari oggi hanno impiegato anni per raggiungere livelli elevati di attività. Concentrati sulla costruzione di relazioni invece di sperare che il tuo progetto ottenga spontaneamente popolarità. Sii paziente e continua a condividere il tuo lavoro con chi lo apprezza. \ No newline at end of file diff --git a/_articles/it/getting-paid.md b/_articles/it/getting-paid.md new file mode 100644 index 00000000000..7f35ab451ad --- /dev/null +++ b/_articles/it/getting-paid.md @@ -0,0 +1,178 @@ +--- +lang: it +title: Essere pagati per il lavoro open source +description: Mantieni il tuo lavoro open source ottenendo supporto finanziario per il tuo tempo o il tuo progetto. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Perché alcune persone cercano un sostegno finanziario + +Gran parte del lavoro open source è volontario. Ad esempio, qualcuno potrebbe imbattersi in un bug in un progetto che sta utilizzando e inviare una soluzione rapida, oppure potrebbe divertirsi armeggiare con un progetto open source nel tempo libero. + + + +Ci sono molte ragioni per cui non si vorrebbe essere pagati per il proprio lavoro open source. + +* **Potrebbero già avere un lavoro a tempo pieno che amano,** che consente loro di contribuire all'open source nel tempo libero. +* **A loro piace pensare all'open source come a un hobby** o a una fuga creativa e non vogliono sentirsi finanziariamente obbligati a lavorare sui propri progetti. +* **Ottengono altri vantaggi dal contributo all'open source,** come costruire una reputazione o un portfolio, apprendere nuove competenze o sentirsi vicini a una comunità. + + + +Per altri, soprattutto quando il contributo è in corso o richiede molto tempo, essere pagati per contribuire all'open source è l'unico modo per partecipare, sia perché il progetto lo richiede sia per motivi personali. + +Mantenere progetti popolari può essere una responsabilità significativa, impiegando 10 o 20 ore a settimana invece di poche ore al mese. + + + +Il lavoro retribuito consente inoltre a persone provenienti da percorsi di vita diversi di dare un contributo significativo. Alcune persone non possono permettersi di dedicare tempo non retribuito a progetti open source a causa della loro attuale situazione finanziaria, dei debiti, delle responsabilità familiari o di altro tipo. Ciò significa che il mondo non vede mai contributi da parte di persone di talento che non possono permettersi di offrire volontariato. Ciò ha implicazioni etiche, come @ashedryden [descritto](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) poiché il lavoro svolto è distorto nel favorire coloro che hanno già vantaggi nella vita, che poi ricevono ulteriori vantaggi in base ai loro contributi volontari, mentre ad altri che non possono fare volontariato vengono negate opportunità successive, rafforzando l'attuale mancanza di diversità nella comunità open source. + + + +Se stai cercando un sostegno finanziario, ci sono due modi da considerare. Puoi finanziare il tuo tempo come collaboratore oppure puoi trovare finanziamenti organizzativi per il progetto. + +## Finanziare il proprio tempo + +Oggi molte persone vengono pagate per lavorare part-time o full-time nell’open source. Il modo più comune per essere pagato per il tuo tempo è parlare con il tuo datore di lavoro. + +È più semplice sostenere il lavoro open source se il tuo datore di lavoro utilizza effettivamente il progetto, ma sii creativo con la tua presentazione. Forse il tuo datore di lavoro non utilizza il progetto, ma usa Python e il mantenimento di un progetto Python popolare aiuta ad attrarre nuovi sviluppatori Python. Forse fa sembrare il tuo datore di lavoro più amichevole agli sviluppatori in generale. + +Se non hai un progetto open source esistente su cui ti piacerebbe lavorare, ma preferisci che il tuo lavoro attuale sia open source, chiedi al tuo datore di lavoro di rendere open source alcuni dei loro software interni. + +Molte aziende stanno sviluppando programmi open source per rafforzare il proprio marchio e assumere talenti di qualità. + +@hueniverse ad esempio, ha scoperto che c'erano ragioni finanziarie per giustificare [l'investimento di Walmart nell'open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). E @jamesgpearce ha scoperto che il programma open source di Facebook [è importante](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) nel reclutamento: + +> È strettamente correlato alla nostra cultura hacker e al modo in cui la nostra organizzazione veniva percepita. Abbiamo chiesto ai nostri dipendenti: "Conoscevi il programma software open source di Facebook?". Due terzi hanno detto "Sì". La metà ha affermato che il programma ha contribuito positivamente alla decisione di lavorare per noi. Questi non sono numeri estremi e spero che la tendenza continui. + +Se la tua azienda segue questa strada, è importante mantenere chiari i confini tra le operazioni comunitarie e aziendali. Dopotutto, l'open source è supportato dal contributo di persone di tutto il mondo, e questo è più grande di quello di qualsiasi altra azienda o luogo. + + + +Se non riesci a convincere il tuo attuale datore di lavoro a dare priorità al lavoro open source, valuta la possibilità di trovare un nuovo datore di lavoro che incoraggi il contributo dei dipendenti all'open source. Cerca aziende che sottolineano il loro impegno verso l'open source. Per esempio: + +* Ad alcune aziende piace [Netflix](https://netflix.github.io/) o [PayPal](https://paypal.github.io/), hanno siti web che evidenziano il loro coinvolgimento nell'open source +* [Zalando](https://opensource.zalando.com) пdivulga la sua [politica di contributo open source](https://opensource.zalando.com/docs/using/contributing/) per i dipendenti + +È probabile che anche i progetti che provengono da una grande azienda, come [Go](https://github.com/golang) o [React](https://github.com/facebook/react), assumano persone per lavorare con l'open source. + +A seconda delle tue circostanze personali, puoi provare a raccogliere fondi in modo indipendente per finanziare il tuo lavoro open source. Per esempio: + +* @Homebrew (e [molti altri sostenitori e organizzazioni](https://github.com/sponsors/community)) finanziano il loro lavoro tramite [Sponsor Github](https://github.com/sponsors) +* @gaearon ha finanziato il suo lavoro su [Redux](https://github.com/reactjs/redux) attraverso una [campagna di crowdfunding Patreon](https://redux.js.org/) +* I fondi @andrewgodwin lavorano sulle migrazioni dello schema Django [tramite campagna Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +Infine, a volte i progetti open source offrono premi per problemi che potresti considerare di aiutare. + +* @ConnorChristie è riuscito a essere pagato per [aiuto](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F% 2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol sta lavorando sulla propria libreria JavaScript [tramite ricompensa gitcoin](https://gitcoin.co/). +* @mamiM ha realizzato traduzioni giapponesi per @MetaMask dopo [il rilascio è stato finanziato da Bounties Network](https://explorer.bounties.network/bounty/134). + +## Trovare finanziamenti per il tuo progetto + +Oltre agli accordi per i singoli contributori, i progetti a volte raccolgono fondi da aziende, individui o altri per finanziare il lavoro in corso. + +I finanziamenti organizzativi possono essere utilizzati per pagare i contributori attuali, coprire i costi di gestione del progetto (come le tariffe di hosting) o investire in nuove funzionalità o idee. + +Con la crescente popolarità dell’open source, trovare finanziamenti per i progetti è ancora sperimentale, ma esistono alcune opzioni comuni. + +### Raccogli fondi per il tuo lavoro attraverso il crowdfunding o campagne di sponsorizzazione + +Trovare una sponsorizzazione funziona bene se hai già un pubblico o una reputazione forti o se il tuo progetto è molto popolare. +Alcuni esempi di progetti sponsorizzati includono: + +* **[webpack](https://github.com/webpack)** raccoglie denaro da aziende e privati ​​[via OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** organizzazione no-profit che paga il lavoro di [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) e altri progetti infrastrutturali di Ruby + +### Crea un flusso di reddito + +A seconda del tuo progetto, potresti essere in grado di addebitare il supporto commerciale, le opzioni di hosting o le funzionalità aggiuntive. Alcuni esempi includono: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** offre versioni a pagamento per ulteriore supporto +* **[Travis CI](https://github.com/travis-ci)** offre versioni a pagamento del suo prodotto +* **[Ghost](https://github.com/TryGhost/Ghost)** è un'organizzazione no-profit con un servizio gestito a pagamento + +Alcuni progetti popolari, come [npm](https://github.com/npm/cli) e [Docker](https://github.com/docker/docker), stanno addirittura raccogliendo capitali di rischio per sostenere la crescita di i loro affari. + +### Richiedi un finanziamento + +Alcune fondazioni e aziende di software offrono sovvenzioni per il lavoro open source. A volte le sovvenzioni possono essere pagate a individui senza creare un'entità legale per il progetto. + +* **[Leggi i documenti](https://github.com/rtfd/readthedocs.org)** ha ricevuto una sovvenzione da [Support of Mozilla Open Source](https://www.mozilla.org/en-US/grants/) +* Il lavoro su **[OpenMRS](https://github.com/openmrs)** è finanziato dall'[Open Source Retreat of Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** ha ricevuto una sovvenzione dalla [Fondazione Sloan](https://sloan.org/programs/digital-technology) +* **[Python Software Foundation](https://www.python.org/psf/grants/)** offre sovvenzioni per lavori legati a Python + +Per opzioni più dettagliate e casi di studio @nayafia [ha scritto una guida](https://github.com/nayafia/lemonade-stand) su come essere pagato per il lavoro open source. Diversi tipi di finanziamento richiedono competenze diverse, quindi considera i tuoi punti di forza per scoprire quale opzione funziona meglio per te. + +## Costruire una causa per il sostegno finanziario + +Che il tuo progetto sia una nuova idea o sia in circolazione da anni, dovresti aspettarti di dedicare molta attenzione all'identificazione del finanziatore target e alla presentazione di un caso convincente. + +Sia che tu voglia pagare per il tuo tempo libero o raccogliere fondi per un progetto, devi essere in grado di rispondere alle seguenti domande. + +### Impatto + +Perchè è utile questo progetto? Perché piace così tanto ai tuoi utenti o potenziali utenti? Dove sarà tra cinque anni? + +### Trazione + +Cerca di raccogliere prove dell'importanza del tuo progetto, che si tratti di parametri, aneddoti o testimonianze. Ci sono aziende o persone importanti che utilizzano il tuo progetto in questo momento? In caso contrario, una persona di spicco lo ha approvato? + +### Valore per il finanziatore + +Ai finanziatori, siano essi il tuo datore di lavoro o una fondazione che concede sovvenzioni, vengono spesso offerte opportunità. Perché dovrebbero sostenere il tuo progetto rispetto a qualsiasi altra opzione? Come ne traggono beneficio personalmente? + +### Utilizzo dei fondi + +Cosa otterrete esattamente con il finanziamento proposto? Concentrarsi sulle tappe fondamentali o sui risultati finali del progetto piuttosto che sul pagamento di uno stipendio. + +### Come riceverai i fondi + +Il finanziatore ha dei requisiti di rimborso? Ad esempio, potrebbe essere necessario essere un'organizzazione senza scopo di lucro o avere uno sponsor fiscale senza scopo di lucro. O forse i fondi dovrebbero essere assegnati a un singolo appaltatore piuttosto che a un’organizzazione. Questi requisiti variano tra i finanziatori, quindi assicurati di fare le tue ricerche in anticipo. + + + +## Sperimenta e non mollare + +Raccogliere fondi non è facile, che tu sia un progetto open source, un'organizzazione no profit o una startup di software, e nella maggior parte dei casi richiede che tu sia creativo. Determinare come vuoi essere pagato, fare le tue ricerche e metterti nei panni del tuo finanziatore ti aiuterà a costruire un caso convincente per il finanziamento. diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md new file mode 100644 index 00000000000..5462d85c9d2 --- /dev/null +++ b/_articles/it/how-to-contribute.md @@ -0,0 +1,526 @@ +--- +lang: it +title: Come contribuire all'open source +description: Vuoi contribuire all'open source? Una guida per fornire contributi open source sia per principianti che per veterani. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Perché contribuire all'Open Source? + + + +Contribuire all'open source può essere un modo gratificante per apprendere, insegnare e sviluppare competenze in quasi tutte le competenze immaginabili. + +Perché le persone contribuiscono all'open source? Molte ragioni! + +### Migliora il software su cui fai affidamento + +Molti contributori open source iniziano come utenti del software a cui contribuiscono. Quando trovi un bug nel software open source che stai utilizzando, potresti voler guardare la fonte per vedere se puoi risolverlo da solo. Se questo è il caso, ripristinare la patch è il modo migliore per garantire che i tuoi amici (e te stesso quando aggiorni alla versione successiva) possano trarne vantaggio. + +### Migliorare le competenze esistenti + +Che si tratti di codifica, progettazione dell'interfaccia utente, progettazione grafica, scrittura o organizzazione, se stai cercando pratica, c'è un progetto open source adatto a te. + +### Incontra persone interessate a cose simili + +I progetti open source con comunità calorose e accoglienti fanno sì che le persone ritornino per anni. Molte persone stringono amicizie durature attraverso la loro partecipazione all'open source, sia che si incontrino alle conferenze o alle chat di burrito online a tarda notte. + +### Trova mentori e insegna agli altri + +Lavorare con altri su un progetto condiviso significa che dovrai spiegare come stai facendo le cose e chiedere aiuto ad altre persone. Gli atti di apprendimento e insegnamento possono essere un'attività soddisfacente per tutti i soggetti coinvolti. + +### Costruisci artefatti pubblici che ti aiutino a sviluppare una reputazione (e una carriera) + +Per definizione, tutto il tuo lavoro open source è pubblico, il che significa che ottieni esempi gratuiti da portare ovunque come dimostrazione di ciò che sai fare. + +### Impara le abilità delle persone + +L'open source offre opportunità per esercitare capacità di leadership e gestione, come la risoluzione dei conflitti, l'organizzazione di gruppi di persone e la definizione delle priorità del lavoro. + +### Essere in grado di apportare cambiamenti, anche piccoli, dà potere + +Non è necessario essere un collaboratore permanente per apprezzare la partecipazione all'open source. Hai mai visto un errore di battitura su un sito web e vorresti che qualcuno lo correggesse? In un progetto open source, puoi fare proprio questo. L’open source aiuta le persone a sentirsi indipendenti riguardo alla propria vita e al modo in cui sperimentano il mondo, e questo di per sé è soddisfacente. + +## Cosa significa contribuire + +Se sei un nuovo collaboratore open source, il processo può creare confusione. Come trovi il progetto giusto? E se non sai programmare? E se qualcosa va storto? + +Non preoccuparti! Esistono molti modi per essere coinvolti in un progetto open source e alcuni suggerimenti ti aiuteranno a ottenere il massimo dalla tua esperienza. + +### Non è necessario aggiungere alcun codice + +Un malinteso comune riguardo al contributo all'open source è che si debba contribuire con il codice. In effetti, sono spesso le altre parti del progetto ad essere [più trascurate o trascurate](https://github.com/blog/2195-the-shape-of-open-source). Farai un _enorme_ favore al progetto offrendoti di contribuire con questo tipo di contributi! + + + +Anche se ti piace scrivere codice, altri tipi di contributi sono un ottimo modo per essere coinvolto in un progetto e incontrare altri membri della comunità. Costruire queste relazioni ti darà l’opportunità di lavorare su altre parti del progetto. + +### Ti piace pianificare eventi? + +* Organizzare workshop o incontri per il progetto, [come ha fatto @fzamperin per NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organizzare una conferenza di progetto (se applicabile) +* Aiuta i membri della comunità a trovare le conferenze giuste e a inviare proposte di interventi + +### Ti piace progettare? + +* Ristrutturare i layout per migliorare l'usabilità del progetto +* Condurre ricerche sugli utenti per riorganizzare e perfezionare la navigazione o i menu del progetto, [come suggerito da Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Compila una guida di stile per aiutare il progetto ad avere un design visivo coerente +* Crea una grafica per la maglietta o un nuovo logo, [come hanno fatto i contributori di hapi.js](https://github.com/hapijs/contrib/issues/68) + +### Ti piace scrivere? + +* Scrivi e migliora la documentazione del progetto, [come ha fatto @CBID2 per la documentazione di OpenSauced](https://github.com/open-sauced/docs/pull/151) +* Preparare una cartella di esempi che mostrano come viene utilizzato il progetto +* Avvia una newsletter del progetto o cura i punti salienti della mailing list, [come ha fatto @opensauced per il suo prodotto](https://news.opensauced.pizza/about/) +* Scrivi tutorial per il progetto, [come hanno fatto i contributori PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Scrivi una traduzione per la documentazione del progetto, [come ha fatto @frontendwizard per le istruzioni CSS Flexbox della sfida freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### Ti piace organizzare? + +* Collegamento a problemi duplicati e suggerimento di nuovi thread di problemi per mantenerti organizzato +* Esamina i problemi aperti e suggerisci di chiudere quelli vecchi, [come ha fatto @nzakas per ESLint](https://github.com/eslint/eslint/issues/6765) +* Fai domande chiarificatrici sui problemi appena scoperti per portare avanti la discussione + +### Ti piace programmare? + +* Trova un problema aperto da risolvere, [come ha fatto @dianjin per Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Chiedi se puoi aiutare a registrare una nuova funzionalità +* Automatizza le impostazioni del progetto +* Migliorare strumenti e test + +### Ti piace aiutare le persone? + +* Rispondi alle domande sul progetto, ad es. Stack Overflow ([come questo esempio di Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) o Reddit +* Rispondi alle domande delle persone in domande aperte +* Aiuta a moderare forum di discussione o canali di chat + +### Ti piace aiutare gli altri a programmare? + +* Rivedi il codice delle dichiarazioni di altre persone +* Scrivi tutorial su come utilizzare un progetto +* Offrirti di fare da mentore a un altro collaboratore, [come ha fatto @ereichert per @bronzdoc in Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Non devi lavorare solo su progetti software! + +Sebbene "open source" si riferisca spesso al software, puoi collaborare praticamente su qualsiasi cosa. Ci sono libri, ricette, elenchi e lezioni che vengono sviluppati come progetti open source. + +Per esempio: + +* @sindresorhus preparare [un elenco di elenchi "grandi".](https://github.com/sindresorhus/awesome) +* @h5bp mantenere un [elenco di potenziali domande per l'intervista](https://github.com/h5bp/Front-end-Developer-Interview-Questions) per i candidati sviluppatori front-end +* @stuartlynn e @nicole-a-tesla hanno realizzato una [raccolta di curiosità sui puffini](https://github.com/stuartlynn/puffin_facts) + +Anche se sei uno sviluppatore di software, lavorare su un progetto di documentazione può aiutarti a iniziare con l'open source. Spesso è meno intimidatorio lavorare su progetti che non implicano codice e il processo collaborativo aumenterà la tua sicurezza e la tua esperienza. + +## Orientamento verso un nuovo progetto + + + +Oltre a correggere un errore di battitura, contribuire all'open source è come avvicinarsi a un gruppo di sconosciuti a una festa. Se inizi a parlare dei lama mentre sono immersi in una discussione sui pesci rossi, probabilmente ti guarderanno in modo un po' strano. + +Prima di lanciarti alla cieca con i tuoi suggerimenti, inizia imparando a leggere la stanza. In questo modo aumenti le possibilità che le tue idee vengano notate e ascoltate. + +### Anatomia di un progetto open source + +Ogni comunità open source è diversa. + +Trascorrere anni su un progetto open source significa che hai acquisito familiarità con un progetto open source. Passa a un altro progetto e potresti scoprire che il vocabolario, le norme e gli stili di comunicazione sono completamente diversi. + +Tuttavia, molti progetti open source seguono una struttura organizzativa simile. Comprendere i diversi ruoli nella comunità e il processo complessivo ti aiuterà a navigare rapidamente in qualsiasi nuovo progetto. + +Un tipico progetto open source prevede i seguenti tipi di persone: + +* **Autore:** La/e persona/e o organizzazione che ha creato il progetto +* **Proprietario:** la/e persona/e che ha la proprietà amministrativa dell'organizzazione o del repository (non sempre coincide con l'autore originale) +* **Sostenitori:** Collaboratori responsabili della gestione della visione e della gestione degli aspetti organizzativi del progetto (possono anche essere autori o proprietari del progetto.) +* **Contributori:** chiunque abbia contribuito con qualcosa al progetto +* **Membri della comunità:** le persone che utilizzano il progetto. Possono essere attivi nelle conversazioni o esprimere la loro opinione sulla direzione del progetto + +I progetti più grandi possono anche avere sottocomitati o gruppi di lavoro focalizzati su compiti diversi, come strumenti, smistamento, moderazione della comunità e organizzazione di eventi. Cerca nel sito web di un progetto una pagina "team" o il repository della documentazione di gestione per trovare queste informazioni. + +C'è anche la documentazione del progetto. Questi file sono generalmente elencati al livello più alto del repository. + +* **LICENZA:** Per definizione, ogni progetto open source deve avere una [licenza open source](https://choosealicense.com). Se il progetto non ha una licenza, non è open source. +* **README:** Il README è la guida pratica che accoglie i nuovi membri della comunità nel progetto. Spiega perché il progetto è utile e come iniziare. +* **CONTRIBUTO:** Mentre i README aiutano le persone a _utilizzare_ il progetto, i documenti che contribuiscono aiutano le persone a _contribuire_ al progetto. Spiega quali tipi di contributi sono richiesti e come funziona il processo. Anche se non tutti i progetti hanno un file CONTRIBUTOR, la sua presenza segnala che è un progetto accogliente a cui contribuire. Un buon esempio di guida ai contributi efficace sarebbe questo dal [repository di documenti Codecademy](https://www.codecademy.com/resources/docs/contribution-guide). +* **CODE_OF_CONDUCT:** Il Codice di condotta stabilisce le regole di base per la condotta associata dei partecipanti e aiuta a creare un ambiente amichevole e accogliente. Anche se non tutti i progetti hanno un file CODE_OF_CONDUCT, la sua presenza segnala che si tratta di un progetto accogliente a cui contribuire. +* **Altra documentazione:** Potrebbe essere presente documentazione aggiuntiva come tutorial, istruzioni o politiche di gestione, in particolare per progetti più grandi come [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +Infine, i progetti open source utilizzano i seguenti strumenti per organizzare la discussione. Leggere gli archivi ti darà una buona idea di come pensa e funziona la comunità. + +* **Tracciamento dei problemi:** dove le persone discutono questioni relative al progetto. +* **Richieste pull:** quando le persone discutono e rivedono le modifiche in corso, sia che si tratti di migliorare l'ordine del codice dei contributori, l'utilizzo della grammatica, l'utilizzo delle immagini, ecc. Alcuni progetti, come [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), utilizzano determinati flussi di azioni GitHub per automatizzare e velocizzare le loro revisioni del codice. +* **Forum di discussione o mailing list:** Alcuni progetti possono utilizzare questi canali per argomenti di conversazione (ad esempio _"Come..."_ o _"Cosa ne pensi di..."_ invece di segnalazioni di bug o richieste per le funzioni). Altri utilizzano il tracker dei problemi per tutte le chiamate. Un buon esempio di ciò potrebbe essere la [newsletter settimanale CHAOSS](https://chaoss.community/news/) +* **Canale di chat sincrono:** alcuni progetti utilizzano canali di chat (come Slack o IRC) per conversazioni informali, collaborazione e scambi rapidi. Un buon esempio di ciò potrebbe essere [EddieHub Discord Community](http://discord.eddiehub.org/). + +## Trova un progetto a cui contribuire + +Ora che hai capito come funzionano i progetti open source, è il momento di trovare un progetto a cui contribuire! + +Se non hai mai contribuito all'open source prima, segui il consiglio del presidente degli Stati Uniti John F. Kennedy, che una volta disse: "Non chiederti cosa può fare il tuo paese per te, chiediti cosa puoi fare tu per il tuo paese". + + + +Il contributo all'open source avviene a tutti i livelli, in tutti i progetti. Non devi pensare troppo a quale sarà esattamente il tuo primo contributo o come sarà. + +Inizia invece pensando ai progetti che già usi o che desideri utilizzare. I progetti a cui partecipi attivamente sono quelli a cui continui a tornare. + +All'interno di questi progetti, ogni volta che ti sorprendi a pensare che qualcosa potrebbe essere migliore o diverso, agisci secondo il tuo istinto. + +L'open source non è un club esclusivo; è fatto da persone proprio come te. "Open source" è solo un termine elegante per considerare i problemi del mondo come risolvibili. + +È possibile eseguire la scansione del README e trovare un collegamento interrotto o un errore di battitura. O sei un nuovo utente e hai notato che qualcosa non funziona, oppure c'è un problema che ritieni dovrebbe essere presente nella documentazione. Invece di ignorarlo e andare avanti o chiedere a qualcun altro di risolverlo, vedi se puoi aiutare partecipando. Ecco cos'è l'open source! + +> Secondo uno studio di Igor Steinmacher e altri ricercatori di informatica, [il 28% dei contributi accessori](https://www.igor.pro.br/publica/papers/saner2016.pdf) in open source sono documenti, come come correzioni di errori di battitura, riformattazione o scrittura di traduzioni. + +Se stai cercando problemi esistenti che puoi risolvere, ogni progetto open source ha una pagina "/contribute" che evidenzia problemi adatti ai principianti con cui puoi iniziare. Vai alla pagina principale del repository GitHub e aggiungi "/contribute" alla fine dell'URL (ad es.[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Puoi anche utilizzare una delle seguenti risorse per aiutarti a scoprire e contribuire a nuovi progetti: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### Lista di controllo prima di contribuire + +Quando trovi un progetto a cui vuoi contribuire, esegui una rapida scansione per assicurarti che il progetto sia idoneo ad accettare contributi. Altrimenti, il tuo duro lavoro potrebbe non ricevere mai risposta. + +Ecco una pratica lista di controllo per valutare se un progetto è adatto ai nuovi contributori. + +**Soddisfa la definizione di open source** + +
+ + +
+ +**Il progetto accetta attivamente contributi** + +Guarda l'attività di commit sul ramo master. Su GitHub, puoi vedere queste informazioni nella scheda Approfondimenti della home page di un repository, ad esempio[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Poi guarda i problemi del progetto. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Ora fai lo stesso per le richieste pull del progetto. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Il progetto è accogliente** + +Un progetto amichevole e accogliente segnala che saranno ricettivi verso nuovi collaboratori. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Come inviare un contributo + +Hai trovato un progetto che ti piace e sei pronto a contribuire. Finalmente! Ecco come ottenere il tuo contributo nel modo giusto. + +### Comunicazione effettiva + +Che tu collabori occasionalmente o cerchi di entrare a far parte di una comunità, lavorare con gli altri è una delle competenze più importanti che svilupperai nell'open source. + + + +Prima di aprire un problema o una richiesta pull o porre una domanda in chat, tieni a mente questi punti per aiutare le tue idee a prendere vita in modo efficace. + +**Fornisci contesto.** Aiuta gli altri a salire a bordo rapidamente. Se riscontri un errore, spiega cosa stai cercando di fare e come riprodurlo. Se stai proponendo una nuova idea, spiega perché pensi che sarebbe utile per il progetto (non solo per te!). + +> 😇 _"X non accade quando faccio Y"_ +> +> 😢 _"X è rotto! Per favore aggiustalo."_ + +**Fai i compiti in anticipo.** Va bene non sapere le cose, ma dimostra che ci hai provato. Prima di chiedere aiuto, assicurati di controllare il README del progetto, la documentazione, i problemi (aperti o chiusi), la mailing list e cerca una risposta in Internet. Le persone apprezzeranno quando dimostrerai che stai cercando di imparare. + +> 😇 _"Non sono sicuro di come implementare X. Ho controllato i documenti di aiuto e non ho trovato alcuna menzione."_ +> +> 😢 _"Come faccio X?"_ + +**Mantieni le richieste brevi e dirette.** Come inviare un'email, qualsiasi contributo, non importa quanto semplice o utile, richiede che qualcun altro lo esamini. Molti progetti hanno più richieste in arrivo che persone che possono aiutare. Sii breve. Aumenterai le possibilità che qualcuno possa aiutarti. + +> 😇 _"Vorrei scrivere un tutorial API."_ +> +> 😢 _"L'altro giorno stavo guidando lungo l'autostrada e mi sono fermato per fare benzina e poi ho avuto questa fantastica idea di qualcosa che dovremmo fare, ma prima di spiegartelo, lascia che te lo mostri..."_ + +**Mantieni pubbliche tutte le comunicazioni.** Sebbene sia allettante, non contattare personalmente i manutentori a meno che non sia necessario condividere informazioni sensibili (come un problema di sicurezza o una cattiva condotta grave). Quando mantieni pubblica la conversazione, più persone possono imparare e trarre vantaggio dal tuo scambio. Le discussioni possono essere di per sé un contributo. + +> 😇 _(come commento) "@-maintainer Ciao! Come procediamo con questo PR?"_ +> +> 😢 _(come email) "Ciao, scusa se ti disturbo via email, ma mi chiedevo se avessi la possibilità di rivedere il mio PR"_ + +**Va bene fare domande (ma sii paziente!).** Tutti sono stati nuovi ad un progetto ad un certo punto, e anche i contributori più esperti devono aggiornarsi quando guardano un nuovo progetto. Allo stesso modo, anche i manutentori di lunga data non hanno sempre familiarità con ogni parte del progetto. Mostra loro la stessa pazienza che vorresti che mostrassero a te. + +> 😇 _"Grazie per aver esaminato questo errore. Ho seguito i tuoi suggerimenti. Ecco il risultato."_ +> +> 😢 _"Perché non riesci a risolvere il mio problema? Non è questo il tuo progetto?"_ + +**Rispetta le decisioni della comunità.** Le tue idee potrebbero differire dalle priorità o dalla visione della comunità. Potrebbero offrire feedback o decidere di non perseguire la tua idea. Anche se dovresti discutere e trovare un compromesso, i manutentori devono convivere con la tua decisione più a lungo di te. Se non sei d'accordo con la loro direzione, puoi sempre lavorare sul tuo fork o iniziare il tuo progetto. + +> 😇 _"Mi dispiace che tu non possa supportare il mio caso d'uso, ma come hai spiegato tu riguarda solo una piccola parte di utenti, capisco il motivo. Grazie per l'ascolto."_ +> +> 😢 _"Perché non supporti il ​​mio caso d'uso? Questo è inaccettabile!"_ + +**Soprattutto, mantienilo elegante.** L'open source è composto da contributori provenienti da tutto il mondo. Si perde il contesto tra lingue, culture, aree geografiche e fusi orari. Inoltre, la comunicazione scritta rende più difficile trasmettere il tono o l’umore. Assumi buone intenzioni in queste conversazioni. Va bene rifiutare educatamente un'idea, chiedere più contesto o chiarire ulteriormente la tua posizione. Prova solo a lasciare Internet in un posto migliore di quando l'hai trovato. + +### Raccogli il contesto + +Prima di agire, fai un rapido controllo per assicurarti che la tua idea non sia stata discussa altrove. Visualizza il README del progetto, i problemi (aperti e chiusi), la mailing list e Stack Overflow. Non devi passare ore a esaminare tutto, ma una rapida ricerca di alcuni termini chiave può fare molto. + +Se non riesci a trovare la tua idea altrove, sei pronto a fare una mossa. Se il progetto è su GitHub, probabilmente comunicherai nel modo seguente: + +* **Sollevare un problema:** è come avviare una conversazione o una discussione +* **Le richieste pull** servono per iniziare a lavorare su una soluzione. +* **Canali di comunicazione:** se il progetto ha un canale Discord, IRC o Slack designato, valuta la possibilità di avviare una conversazione o chiedere chiarimenti sul tuo contributo. + +Prima di aprire un problema o una richiesta pull, controlla i documenti che contribuiscono al progetto (di solito un file chiamato CONTRIBUTING o nel README) per vedere se è necessario includere qualcosa di specifico. Ad esempio, potrebbero chiederti di seguire uno schema o richiederti di utilizzare dei test. + +Se vuoi dare un contributo significativo, apri un issue da chiedere prima di lavorarci. È utile guardare il progetto per un po' (su GitHub, [puoi fare clic su "Guarda"](https://help.github.com/articles/watching-repositories/) per ricevere una notifica di tutte le conversazioni) e accedere a conoscere i membri della comunità prima di svolgere lavori che potrebbero non essere accettati. + + + +### Apertura di un problema + +Di solito dovresti aprire un problema nelle seguenti situazioni: + +* Segnala un bug che non puoi risolvere da solo +* Discutere un argomento o un'idea di alto livello (ad esempio comunità, visione o politiche) +* Suggerisci una nuova funzionalità o un'altra idea di progetto + +Suggerimenti per comunicare sui problemi: + +* **Se vedi un problema aperto su cui vuoi lavorare**, commenta il problema per far sapere alle persone che ci stai lavorando. In questo modo, le persone avranno meno probabilità di duplicare il tuo lavoro. +* **Se un problema è stato scoperto qualche tempo fa,** potrebbe essere stato risolto altrove o già risolto, quindi commenta per chiedere conferma prima di iniziare il lavoro. +* **Se hai aperto un problema ma hai trovato la risposta da solo in seguito,** commenta il problema per farlo sapere alle persone, quindi chiudi il problema. Anche documentare questo risultato è un contributo al progetto. + +### Apertura di una richiesta pull + +Di solito dovresti aprire una richiesta pull nelle seguenti situazioni: + +* Invia correzioni minori come errori di battitura, collegamenti interrotti o errori evidenti. +* Inizia a lavorare su un contributo che ti è già stato richiesto o di cui hai già parlato in un numero. + +Una richiesta pull non deve rappresentare un lavoro completato. Di solito è meglio aprire una richiesta pull in anticipo in modo che altri possano guardare o fornire feedback sui tuoi progressi. Basta aprirlo come "bozza" o contrassegnarlo come "WIP" (Lavori in corso) nella riga dell'oggetto o nelle sezioni "Note ai revisori" se fornite (oppure puoi semplicemente crearne una tua. In questo modo: `** # # Note per il revisore**`). Puoi sempre aggiungere altri impegni in un secondo momento. + +Se il progetto è su GitHub, ecco come inviare una richiesta pull: + +* **[Fork il repository](https://guides.github.com/activities/forking/)** e clonalo localmente. Connetti il ​​tuo locale al repository upstream originale aggiungendolo come remoto. Estrai spesso le modifiche da "upstream" per rimanere aggiornato, quindi quando invii la tua richiesta di pull, i conflitti di unione saranno meno probabili. (Vedi istruzioni più dettagliate [qui](https://help.github.com/articles/syncing-a-fork/).) +* **[Crea un ramo](https://guides.github.com/introduction/flow/)** per le tue modifiche. +* **Elenca eventuali problemi rilevanti** o documentazione di supporto nel tuo PR (ad esempio "Chiude n. 37.") +* **Includi screenshot prima e dopo** se le modifiche comportano differenze HTML/CSS. Trascina e rilascia le immagini nel corpo della tua richiesta pull. +* **Testa le tue modifiche!** Esegui le tue modifiche confrontandole con eventuali test esistenti, se presenti, e creane di nuovi quando necessario. È importante assicurarsi che le modifiche non interrompano il progetto esistente. +* **Contribuisci allo stile del progetto** secondo le tue capacità. Ciò può significare utilizzare il rientro, il punto e virgola o i commenti in modo diverso rispetto a quanto faresti nel tuo repository, ma rende più facile per il manutentore unirli e per gli altri comprenderli e mantenerli in futuro. + +Se questa è la tua prima richiesta pull, dai un'occhiata a [Crea una richiesta pull](http://makeapullrequest.com/) che @kentcdodds ha creato come tutorial video dimostrativo. Puoi anche esercitarti a creare una richiesta pull sul repository [First Contributions](https://github.com/Roshanjossey/first-contributions) creato da @Roshanjossey. + +## Cosa succede dopo aver inviato il tuo contributo + +Prima di iniziare a festeggiare, dopo che avrai inviato il tuo contributo si verificherà una delle seguenti situazioni: + +### 😭 Non riceverai risposta + +Ci auguriamo che tu abbia [controllato eventuali segni di attività nel progetto](#lista-di-controllo-prima-di-contribuire) prima di contribuire. Anche con un progetto attivo, però, è possibile che il tuo contributo non riceva risposta. + +Se non ricevi notizie da più di una settimana, è giusto rispondere educatamente nello stesso thread chiedendo a qualcuno di recensire. Se conosci il nome della persona giusta per rivedere il tuo contributo, puoi @ menzionarla in questo thread. + +**Non contattare personalmente questa persona**; ricorda che la comunicazione pubblica è vitale per i progetti open source. + +Se fai un cortese promemoria e continui a non ricevere risposta, è possibile che nessuno risponderà mai. Non è una sensazione fantastica, ma non lasciarti scoraggiare! 😄 Esistono molte possibili ragioni per cui non hai ricevuto una risposta, comprese circostanze personali che potrebbero andare oltre il tuo controllo. Prova a trovare un altro progetto o un modo per contribuire. Se non altro, è un buon motivo per non investire troppo tempo nel contribuire prima che gli altri membri della comunità siano coinvolti e reattivi. + +### 🚧 Qualcuno vuole modifiche al tuo contributo + +È comune che ti venga chiesto di apportare modifiche al tuo contributo, che si tratti di feedback sulla portata della tua idea o di modifiche al tuo codice. + +Quando qualcuno chiede modifiche, sii reattivo. Si sono presi il tempo per rivedere il tuo contributo. Aprire un PR e andarsene è una cattiva forma. Se non sai come apportare modifiche, ricerca il problema e poi chiedi aiuto se ne hai bisogno. Un buon esempio di ciò potrebbe essere [il feedback che un altro collaboratore ha dato a @a-m-lamb sulla sua richiesta di pull ai documenti Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +Se non hai più tempo per lavorare sul problema perché la conversazione va avanti da mesi e le tue circostanze sono cambiate o non riesci a trovare una soluzione, informa un manutentore in modo che possa aprire il problema a qualcun altro , come ha fatto [@RitaDee per un problema nelle applicazioni OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 Il tuo contributo non è accettato + +Il tuo contributo potrebbe essere accettato o meno alla fine. Spero che tu non ci abbia già dedicato troppo lavoro. Se non sei sicuro del motivo per cui non è stato accettato, è perfettamente ragionevole chiedere al manutentore feedback e chiarimenti. Alla fine, però, dovrai rispettare il fatto che è una loro decisione. Non discutere e non essere ostile. Sei sempre il benvenuto ad espanderti e lavorare sulla tua versione se non sei d'accordo! + +### 🎉 Il tuo contributo è accettato + +Evviva! Hai dato con successo un contributo open source! + +## Fallo! 🎉 + +Se hai appena dato il tuo primo contributo open source o stai cercando nuovi modi per contribuire, speriamo che tu sia ispirato ad agire. Anche se il tuo contributo non è stato accettato, assicurati di dire grazie quando il manutentore ha fatto uno sforzo per aiutarti. L'open source è creato da persone come te: un problema, una richiesta pull, un commento o il cinque alla volta. \ No newline at end of file diff --git a/_articles/it/index.html b/_articles/it/index.html new file mode 100644 index 00000000000..4944583ea67 --- /dev/null +++ b/_articles/it/index.html @@ -0,0 +1,7 @@ +--- +layout: index +title: Guide Open Source +lang: it +permalink: /it/ +--- + diff --git a/_articles/it/leadership-and-governance.md b/_articles/it/leadership-and-governance.md new file mode 100644 index 00000000000..e2d0c9aca80 --- /dev/null +++ b/_articles/it/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: it +title: Leadership e governo +description: I progetti open source in crescita possono trarre vantaggio da regole formali per prendere decisioni. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Comprendere la gestione del tuo progetto in crescita + +Il tuo progetto sta crescendo, le persone sono coinvolte e tu ti impegni a mantenere questa cosa. A questo punto, ti starai chiedendo come includere contributori regolari al progetto nel tuo flusso di lavoro, sia che si tratti di fornire accesso al commit o di risolvere i dibattiti della comunità. Se hai domande, abbiamo le risposte. + +## Quali sono esempi di ruoli formali utilizzati nei progetti open source? + +Molti progetti seguono una struttura simile per quanto riguarda i ruoli dei contributori e il riconoscimento. + +Il significato effettivo di questi ruoli, tuttavia, dipende interamente da te. Ecco alcuni tipi di ruoli che potresti riconoscere: + +* **Supporto** +* **Associato** +* **Committente** + +**Per alcuni progetti, i "sostenitori"** sono le uniche persone in un progetto con accesso come commit. In altri progetti, sono semplicemente le persone elencate nel README come manutentori. + +Un manutentore non deve essere qualcuno che scrive il codice per il tuo progetto. Potrebbe essere qualcuno che ha svolto molto lavoro per evangelizzare il tuo progetto o documentazione scritta che ha reso il progetto più accessibile agli altri. Indipendentemente da ciò che fa quotidianamente, un manutentore è probabilmente qualcuno che si sente responsabile della direzione del progetto e si impegna a migliorarlo. + +Un **"Collaboratore" può essere chiunque** commenti un problema o una richiesta pull, persone che aggiungono valore al progetto (che si tratti di valutare problemi, scrivere codice o organizzare eventi) o chiunque abbia una richiesta pull combinata (magari la definizione più ristretta di contributore). + + + +**Il termine "agente"** può essere utilizzato per distinguere l'accesso all'impegno, che è un tipo specifico di responsabilità, da altre forme di contributo. + +Sebbene tu possa definire i ruoli del tuo progetto come desideri, [considera l'utilizzo di definizioni più ampie](../how-to-contribute/#cosa-significa-contribuire) per incoraggiare più forme di contributo. Puoi utilizzare i ruoli di leadership per riconoscere formalmente le persone che hanno apportato contributi eccezionali al tuo progetto, indipendentemente dalle loro competenze tecniche. + + + +## Come formalizzo questi ruoli di leadership? + +Formalizzare i ruoli di leadership aiuta le persone a sentirsi proprietarie e dice agli altri membri della comunità a chi rivolgersi per chiedere aiuto. + +Per un progetto più piccolo, designare i leader può essere semplice come aggiungere i loro nomi al file di testo README o CONTRIBUTORS. + +Per un progetto più ampio, se hai un sito web, crea una pagina del team o elenca lì i tuoi project manager. Ad esempio, [Postgres](https://github.com/postgres/postgres/) ha una [pagina completa del team](https://www.postgresql.org/community/contributors/) con brevi profili di ciascun contributore. + +Se il tuo progetto ha una comunità di contributori molto attiva, puoi formare un "core team" di manutentori o anche sottocomitati di persone che si assumono la responsabilità di diverse aree problematiche (ad esempio sicurezza, classificazione dei problemi o comportamento della comunità). Consentire alle persone di auto-organizzarsi e fare volontariato per i ruoli che li appassionano di più, piuttosto che esternalizzarli. + + + +I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/ CONTRIBUIRE .md#talking-with-other-devs). + +Una volta stabiliti i ruoli di leadership, assicurati di documentare come le persone possono raggiungerli! Stabilisci un processo chiaro su come qualcuno può diventare un sostenitore o unirsi a un sottocomitato nel tuo progetto e scrivilo nel tuo GOVERNANCE.md. + +Strumenti come [Vossibility](https://github.com/icecrime/vossibility-stack) possono aiutarti a tenere traccia pubblicamente chi sta (o non sta) contribuendo al progetto. Documentare queste informazioni evita la percezione della comunità secondo cui i manutentori sono una cricca che prende le proprie decisioni in privato. + +Infine, se il tuo progetto è su GitHub, valuta la possibilità di spostare il progetto dal tuo account personale a un'organizzazione e di aggiungere almeno un amministratore di backup. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) semplifica la gestione delle autorizzazioni e di più repository e protegge l'eredità del tuo progetto tramite [proprietà condivisa](../building-community/#condividi-la-proprietà-del-tuo-progetto). + +## Quando dovrei dare a qualcuno l'accesso per impegnarsi? + +Alcune persone pensano che dovresti dare accesso al coinvolgimento a tutti coloro che danno un contributo. Ciò può incoraggiare più persone a sentirsi proprietarie del tuo progetto. + +D'altra parte, soprattutto per progetti più grandi e complessi, potresti voler concedere l'accesso al coinvolgimento solo alle persone che hanno dimostrato il proprio impegno. Non esiste un modo giusto per farlo: fai ciò che ti fa sentire più a tuo agio! + +Se il tuo progetto è su GitHub, puoi utilizzare [rami protetti](https://help.github.com/articles/about-protected-branches/) per gestire chi può puntare a un particolare ramo e in quali circostanze. + + + +## Quali sono alcune delle strutture di governance comuni per i progetti open source? + +Esistono tre strutture di governance generale associate ai progetti open source. + +* **BDFL:** BDFL sta per "Dittatore benevolo per la vita". In questa struttura, una persona (di solito l'autore originale del progetto) ha l'ultima parola su tutte le principali decisioni del progetto. [Python](https://github.com/python) è un classico esempio. I progetti più piccoli probabilmente utilizzano BDFL per impostazione predefinita perché ci sono solo uno o due manutentori. Anche un progetto che nasce da un'azienda può rientrare nella categoria BDFL. + +* **Meritocrazia:** (Nota: il termine "meritocrazia" ha connotazioni negative per alcune comunità e ha una [storia sociale e politica complessa](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** Nella meritocrazia ai partecipanti attivi al progetto (coloro che dimostrano "merito") viene assegnato un ruolo decisionale formale. Le decisioni vengono solitamente prese sulla base del voto per puro consenso. Il concetto di meritocrazia è stato introdotto dalla [Fondazione Apache](https://www.apache.org/); [tutti i progetti Apache](https://www.apache.org/index.html#projects-list) sono meritocrazie. I contributi possono essere versati solo da individui che rappresentano se stessi e non da un'azienda. + +* **Contributo liberale:** In un modello di contribuzione liberale, le persone che lavorano di più sono riconosciute come le più influenti, ma questo si basa sul lavoro attuale, non sul contributo storico. Le decisioni sui grandi progetti vengono prese sulla base di un processo di ricerca del consenso (discussione delle principali lamentele) piuttosto che sul puro voto, e cercano di includere quante più prospettive comunitarie possibile. Esempi popolari di progetti che utilizzano un modello di contribuzione liberale includono [Node.js](https://foundation.nodejs.org/) e [Rust](https://www.rust-lang.org/). + +Quale dovresti usare? Sta a te! Ogni modello presenta vantaggi e compromessi. E anche se a prima vista possono sembrare molto diversi, tutti e tre i modelli hanno più cose in comune di quanto sembri. Se sei interessato ad adottare uno di questi modelli, dai un'occhiata a questi modelli: + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Ho bisogno di documenti gestionali quando inizio il mio progetto? + +Non esiste un momento giusto per scrivere la gestione del tuo progetto, ma è molto più semplice definirlo una volta che hai visto svolgersi le dinamiche della tua comunità. La parte migliore (e più difficile) della gestione open source è che è modellata dalla comunità! + +Tuttavia, alcuni dei primi documenti contribuiranno inevitabilmente alla gestione del progetto, quindi inizia a registrare ciò che puoi. Ad esempio, puoi definire aspettative chiare sul comportamento o sul funzionamento del processo di collaborazione, anche all'inizio del tuo progetto. + +Se fai parte di un'azienda che lancia un progetto open source, vale la pena tenere una discussione interna prima del lancio su come la tua azienda prevede di supportare e prendere decisioni sui progressi del progetto. Potresti anche voler spiegare pubblicamente qualcosa di specifico su come la tua azienda sarà (o non sarà!) coinvolta nel progetto. + + + +## Cosa succede se i dipendenti aziendali iniziano a inviare contributi? + +I progetti open source di successo vengono utilizzati da molte persone e aziende e alcune aziende potrebbero finire per avere flussi di entrate che sono in definitiva legati al progetto. Ad esempio, un'azienda può utilizzare il codice di progetto come componente nell'offerta di un servizio commerciale. + +Man mano che il progetto diventa più diffuso, le persone con esperienza in esso diventano più richieste: potresti essere uno di loro! - e talvolta verranno pagati per il lavoro svolto sul progetto. + +È importante considerare l'attività commerciale come una cosa normale e semplicemente come un'altra fonte di energia per lo sviluppo. Naturalmente, gli sviluppatori pagati non dovrebbero ricevere un trattamento speciale rispetto a quelli non pagati; ogni contributo dovrebbe essere giudicato in base ai suoi meriti tecnici. Tuttavia, le persone dovrebbero sentirsi a proprio agio nell’impegnarsi in attività commerciali e sentirsi a proprio agio nel citare i propri casi d’uso quando si discute a favore di un particolare miglioramento o funzionalità. + +"Commerciale" è pienamente compatibile con "open source". "Commerciale" significa semplicemente che da qualche parte sono coinvolti dei soldi, che il software viene utilizzato commercialmente, il che è sempre più probabile man mano che un progetto ottiene l'accettazione. (Quando il software open source viene utilizzato come parte di un prodotto non open source, il prodotto complessivo è ancora software "proprietario", sebbene, come l'open source, possa essere utilizzato per scopi commerciali e non commerciali.) + +Come chiunque altro, gli sviluppatori motivati ​​dal punto di vista commerciale ottengono influenza nel progetto attraverso la qualità e la quantità del loro contributo. Ovviamente, un programmatore che viene pagato per il suo tempo può essere in grado di guadagnare più di qualcuno che non lo fa, ma va bene così: il pagamento è solo uno dei tanti possibili fattori che possono influenzare quanto qualcuno guadagna. Mantieni le discussioni del tuo progetto focalizzate sul contributo, non sui fattori esterni che consentono alle persone di dare quel contributo. + +## Ho bisogno di una persona giuridica per sostenere il mio progetto? + +Non hai bisogno di un'entità legale per supportare il tuo progetto open source a meno che non gestisci denaro. + +Ad esempio, se desideri avviare un'attività commerciale, ti consigliamo di costituire una C Corp o LLC (se risiedi negli Stati Uniti). Se stai solo lavorando a un contratto relativo al tuo progetto open source, puoi accettare denaro come unico proprietario o formare una LLC (se risiedi negli Stati Uniti). + +Se desideri accettare donazioni per il tuo progetto open source, puoi impostare un pulsante di donazione (utilizzando PayPal o Stripe, ad esempio), ma il denaro non sarà deducibile dalle tasse a meno che tu non sia un'organizzazione no-profit qualificata (501c3, se sei sono negli Stati Uniti). + +Molti progetti non vogliono prendersi la briga di creare un'organizzazione no-profit, quindi trovano invece uno sponsor fiscale senza scopo di lucro. Uno sponsor fiscale accetta donazioni per tuo conto, solitamente in cambio di una percentuale della donazione. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) e [Open Collective](https://opencollective.com/opensource) sono esempi di organizzazioni che fungono da sponsor fiscali per progetti open source. + + + +Se il tuo progetto è strettamente correlato a un particolare linguaggio o ecosistema, potrebbe esserci anche una base software associata con cui puoi lavorare. Ad esempio, la [Python Software Foundation](https://www.python.org/psf/) aiuta a supportare [PyPI](https://pypi.org/), il gestore pacchetti Python e [Node.js Foundation] (https://foundation.nodejs.org/) aiuta a mantenere [Express.js](https://expressjs.com/), un framework basato su Node. diff --git a/_articles/it/legal.md b/_articles/it/legal.md new file mode 100644 index 00000000000..6f0c1b50011 --- /dev/null +++ b/_articles/it/legal.md @@ -0,0 +1,160 @@ +--- +lang: it +title: Il lato legale dell'open source +description: Tutto quello che ti sei sempre chiesto riguardo al lato legale dell'open source e alcune cose che non ti sei chiesto. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Comprendere le implicazioni legali dell'open source + +Condividere il tuo lavoro creativo con il mondo può essere un'esperienza emozionante e gratificante. Può anche significare un sacco di cose legali di cui non sapevi di doverti preoccupare. Fortunatamente, con questa guida non è necessario ricominciare da zero. (Prima di approfondire, assicurati di leggere il nostro [disclaimer](/notices/).) + +## Perché le persone si preoccupano così tanto del lato legale dell'open source? + +Sono felice che tu l'abbia chiesto! Quando realizzi un'opera creativa (come scrittura, grafica o codice), quell'opera è protetta da copyright esclusivo per impostazione predefinita. Cioè, la legge presuppone che, come autore del tuo lavoro, tu abbia voce in capitolo su ciò che gli altri possono fare con esso. + +In genere, ciò significa che nessun altro può utilizzare, copiare, distribuire o modificare il tuo lavoro senza correre il rischio di rimozione, squalifica o contenzioso. + +Tuttavia, l'open source è una circostanza insolita perché l'autore si aspetta che altri utilizzino, modifichino e condividano il lavoro. Ma poiché il valore legale predefinito è ancora il diritto d'autore esclusivo, è necessario concedere esplicitamente queste autorizzazioni con una licenza. + +Queste regole si applicano anche quando qualcuno contribuisce al tuo progetto. Senza licenza o altro accordo, tutti i contributi sono di proprietà esclusiva dei loro autori. Ciò significa che nessuno – nemmeno tu – può utilizzare, copiare, distribuire o modificare il proprio contributo. + +Infine, il tuo progetto potrebbe avere dipendenze con requisiti di licenza di cui non eri a conoscenza. La comunità del tuo progetto o le politiche del tuo datore di lavoro potrebbero anche richiedere che il tuo progetto utilizzi licenze open source specifiche. Esamineremo queste situazioni di seguito. + +## Публичните GitHub проекти с отворен код ли са? + +Quando [crei nuovo progetto](https://help.github.com/articles/creating-a-new-repository/) su GitHub, hai la possibilità di rendere il repository **privato** o **pubblico**. + +![Crea un archivio](/assets/images/legal/repo-create-name.png) + +**Rendere pubblico il tuo progetto GitHub non equivale a concedergli una licenza.** I progetti pubblici sono coperti dai [Termini di servizio di GitHub](https://help.github.com/en/github/site-policy/github-Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), che consente ad altri di rivedere e creare un fork del tuo progetto, ma per il resto il tuo lavoro arriva senza autorizzazioni. + +Se desideri che altri utilizzino, distribuiscano, modifichino o contribuiscano al tuo progetto, devi includere una licenza open source. Ad esempio, qualcuno non può utilizzare legalmente alcuna parte del tuo progetto GitHub nel proprio codice, anche se è pubblico, a meno che tu non gli conceda specificatamente il diritto di farlo. + +## Dammi solo un riepilogo di ciò di cui ho bisogno per proteggere il mio progetto. + +Sei fortunato perché oggi le licenze open source sono standardizzate e facili da usare. Puoi copiare e incollare una licenza esistente direttamente nel tuo progetto. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono [licenze open source popolari](https://innovationgraph.github.com/global-metrics/licenses), ma ci sono altre opzioni tra cui scegliere. È possibile trovare il testo completo di queste licenze e le istruzioni su come utilizzarle all'indirizzo [choosealicense.com](https://choosealicense.com/). + +Quando crei un nuovo progetto su GitHub, ti verrà [chiesto di aggiungere una licenza](https://help.github.com/articles/open-source-licensing/). + + + +## Quale licenza open source è adatta al mio progetto? + +È difficile sbagliare con la [licenza MIT](https://choosealicense.com/licenses/mit/) se inizi con un foglio bianco. È breve, facile da capire e consente a chiunque di fare qualsiasi cosa purché conservi una copia della licenza, inclusa la nota sul copyright. Potrai rilasciare il progetto con una licenza diversa, se mai ne avessi bisogno. + +Altrimenti, la scelta della giusta licenza open source per il tuo progetto dipende dai tuoi obiettivi. + +Molto probabilmente il tuo progetto ha (o avrà) **dipendenze**, ognuna delle quali avrà la propria licenza open source con termini che dovrai rispettare. Ad esempio, se stai rendendo open source un progetto Node.js, probabilmente utilizzerai le librerie di Node Package Manager (npm). + +Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci. + +Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl - 3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano. + +Puoi anche controllare le **community** che speri di utilizzare e contribuire al tuo progetto: + +* **Vuoi che il tuo progetto venga utilizzato come dipendenza da altri progetti?** Probabilmente è meglio utilizzare la licenza più popolare nella comunità pertinente. Ad esempio, [MIT](https://choosealicense.com/licenses/mit/) è la licenza più popolare per [librerie npm](https://libraries.io/search?platforms=NPM). +* **Vuoi che il tuo progetto attiri le grandi imprese?** Le grandi imprese possono essere confortate da una licenza di brevetto espressa da parte di tutti i contributori. In tal caso, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) copre te (e loro). +* **Vuoi che il tuo progetto attiri i contributori che non vogliono che i loro contributi vengano utilizzati in software closed source?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (se non vogliono contribuire ai servizi closed source) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) andrà benissimo. + +La tua **azienda** potrebbe avere politiche di licenza per progetti open source. Alcune aziende richiedono che i tuoi progetti abbiano una licenza permissiva per consentire l'integrazione con i prodotti proprietari dell'azienda. Altre politiche impongono una forte licenza copyleft e un accordo di collaborazione aggiuntivo (vedi sotto), in modo che solo la tua azienda possa utilizzare il progetto nel software closed source. Le organizzazioni possono anche avere determinati standard, obiettivi di responsabilità sociale o esigenze di trasparenza che potrebbero richiedere una strategia di licenza specifica. Rivolgiti a [l'ufficio legale della tua azienda](#il-mio-progetto-necessita-di-un-contratto-di-collaborazione-aggiuntivo) per ricevere assistenza. + +Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una delle licenze sopra menzionate renderà il tuo progetto GitHub open source. Se vuoi vedere altre opzioni, controlla [choosealicense.com](https://choosealicense.com) per trovare la licenza giusta per il tuo progetto, anche se è [non software](https://choosealicense.com/non-software/). + +## Cosa succede se voglio cambiare la licenza del mio progetto? + +Nella maggior parte dei progetti non è mai necessario modificare le licenze. Ma a volte le circostanze cambiano. + +Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti oppure la tua azienda cambia strategie, ognuna delle quali potrebbe richiedere o richiedere una licenza diversa. Inoltre, se hai dimenticato di concedere la licenza al tuo progetto fin dall'inizio, aggiungere una licenza equivale praticamente a modificare le licenze. Ci sono tre cose principali da tenere a mente quando aggiungi o modifichi la licenza del tuo progetto: + +**È complicato.** Determinare la compatibilità e la conformità della licenza e chi possiede il copyright può diventare complicato e creare confusione molto rapidamente. Passare a una licenza nuova ma compatibile per nuove versioni e contributi è diverso dal concedere nuovamente in licenza tutti i contributi esistenti. Coinvolgi il tuo team legale al primo accenno di desiderio di modificare le licenze. Anche se hai o puoi ottenere il permesso dai detentori del copyright del tuo progetto per modificare la licenza, considera l'impatto della modifica sugli altri utenti e contributori al tuo progetto. Pensa a una modifica della licenza come a un "evento di gestione" per il tuo progetto, che è più probabile che si svolga senza intoppi con una comunicazione chiara e una consultazione con le parti interessate del progetto. Un motivo in più per scegliere e utilizzare una licenza adeguata per il tuo progetto fin dal suo inizio! + +**Licenza esistente del tuo progetto.** Se la licenza esistente del tuo progetto è compatibile con la licenza che desideri modificare, puoi semplicemente iniziare a utilizzare la nuova licenza. Questo perché se la licenza A è compatibile con la licenza B, rispetterai i termini di A rispettando allo stesso tempo i termini di B (ma non necessariamente il contrario). Pertanto, se stai attualmente utilizzando una licenza permissiva (ad esempio MIT), puoi passare a una licenza con più termini purché conservi una copia della licenza MIT e di eventuali avvisi di copyright associati (ovvero continui a rispettare i termini minimi della licenza licenza MIT). Ma se la tua licenza attuale non è permissiva (ad esempio copyleft o non hai una licenza) e non sei l'unico detentore del copyright, non puoi semplicemente cambiare la licenza del tuo progetto MIT. In sostanza, con una licenza permissiva, i detentori dei diritti d'autore del progetto hanno dato il permesso preventivo di modificare le licenze. + +**Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software. + +In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza. + +## Il mio progetto necessita di un contratto di collaborazione aggiuntivo? + +Probabilmente no. Per la stragrande maggioranza dei progetti open source, la licenza open source funge implicitamente sia da licenza in entrata (dai contributori) che da licenza in uscita (ad altri contributori e utenti). Se il tuo progetto è su GitHub, i Termini di servizio di GitHub rendono "inbound=outbound" [esplicito per impostazione predefinita](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributi-sotto-licenza-repository). + +Un ulteriore contratto di collaborazione, spesso chiamato Contributor License Agreement (CLA), può creare lavoro amministrativo per i manutentori del progetto. La quantità di lavoro aggiunta da un accordo dipende dal progetto e dall'implementazione. Un tipico accordo potrebbe richiedere ai contributori di confermare con un clic di possedere i diritti necessari per contribuire secondo la licenza open source del progetto. Un accordo più complesso può richiedere la revisione legale e la firma da parte dei datori di lavoro dei contributori. + +Inoltre, aggiungendo "documentazione" che alcuni ritengono non necessaria, difficile da comprendere o ingiusta (quando il destinatario dell'accordo ottiene più diritti dei contributori o del pubblico attraverso la licenza open source del progetto), un ulteriore accordo con il contributore può essere percepito come ostile alla comunità del progetto. + + + +Alcune situazioni in cui potresti prendere in considerazione un accordo di collaborazione aggiuntivo per il tuo progetto includono: + +* I tuoi avvocati vogliono che tutti i contributori accettino esplicitamente (_firmano_, online o offline) i termini del contributo, forse perché ritengono che la licenza open source da sola non sia sufficiente (anche se lo è!). Se questa è l'unica preoccupazione, dovrebbe essere sufficiente un accordo di collaborazione che riconosca la licenza open source del progetto. Il contratto di licenza per collaboratore individuale jQuery è un buon esempio di contratto per collaboratore aggiuntivo leggero. +* Tu o i tuoi avvocati volete che gli sviluppatori dichiarino che ogni impegno che assumono è autorizzato. Il requisito del [Certificato di origine dello sviluppatore](https://developercertificate.org/) indica quanti progetti raggiungono questo obiettivo. Ad esempio, la comunità Node.js [utilizza](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [invece di](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) dal loro precedente CLA. Una semplice opzione per automatizzare l'implementazione di DCO nel tuo repository è [DCO Probot](https://github.com/probot/dco). +* Il tuo progetto utilizza una licenza open source che non include una concessione espressa di brevetto (come il MIT) e hai bisogno dell'autorizzazione al brevetto da parte di tutti i contributori, alcuni dei quali potrebbero lavorare per aziende con ampi portafogli di brevetti che potrebbero essere utilizzati per prendere di mira te o altri contributori e utenti del progetto. Il [Contratto di licenza per collaboratore personale Apache](https://www.apache.org/licenses/icla.pdf) è un contratto per collaboratore supplementare comunemente utilizzato che prevede una concessione di brevetto che rispecchia quella presente nella licenza Apache 2.0. +* Il tuo progetto è protetto da licenza copyleft, ma devi anche distribuire la tua versione del progetto. Ogni collaboratore dovrà assegnarti il ​​copyright o concedere a te (ma non al pubblico) una licenza permissiva. Il [Contratto di collaborazione MongoDB](https://www.mongodb.com/legal/contributor-agreement) è un esempio di questo tipo di contratto. +* Ritieni che il tuo progetto potrebbe dover modificare le licenze nel corso della sua vita e desideri che i partecipanti accettino tali modifiche in anticipo. + +Se hai comunque bisogno di utilizzare un contratto di collaborazione aggiuntivo con il tuo progetto, prendi in considerazione l'utilizzo di un'integrazione come [Assistente CLA](https://github.com/cla-assistant/cla-assistant) per ridurre al minimo la distrazione del collaboratore. + +## Cosa deve sapere il team legale della mia azienda? + +Se stai lanciando un progetto open source come dipendente dell'azienda, innanzitutto il tuo team legale deve sapere che sei un progetto open source. + +Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un progetto personale. Probabilmente hai un "accordo di proprietà intellettuale dei dipendenti" con la tua azienda che dà loro un certo controllo sui tuoi progetti, soprattutto se sono legati all'attività aziendale o se stai utilizzando risorse aziendali per sviluppare il progetto. La tua azienda _dovrebbe_ concederti facilmente l'autorizzazione e potrebbe già averlo fatto tramite un accordo IP o una politica aziendale favorevole ai dipendenti. In caso contrario, puoi negoziare (ad esempio spiegando che il tuo progetto serve agli obiettivi di apprendimento e sviluppo professionale dell'azienda per te) o evitare di lavorare sul tuo progetto finché non trovi un'azienda migliore. + +**Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare: + +* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto. + +* **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato. + +* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ] (#quale-licenza-open-source-è-adatta-al-mio-progetto)). + +* **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source. + +* **Privacy:** Il tuo progetto raccoglie dati degli utenti? "Telefono di casa" ai server aziendali? Il tuo team legale può aiutarti a rispettare le politiche aziendali e le normative esterne. + +Se stai lanciando il primo progetto open source della tua azienda, quanto sopra è più che sufficiente per farcela (ma non preoccuparti, la maggior parte dei progetti non dovrebbe essere un grosso problema). + +Nel lungo termine, il tuo team legale può fare di più per aiutare l'azienda a ottenere di più dal suo coinvolgimento open source e rimanere al sicuro: + +* **Regole per il contributo dei dipendenti:** Valuta la possibilità di sviluppare una politica aziendale che definisca il modo in cui i tuoi dipendenti contribuiscono ai progetti open source. Una politica chiara ridurrà la confusione tra i tuoi dipendenti e li aiuterà a contribuire a progetti open source nel migliore interesse dell'azienda, sia come parte del loro lavoro che nel loro tempo libero. Un buon esempio è [un IP modello e una politica di contributo open source](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) di Rackspace. + + + +* **Cosa pubblicare:** [(Quasi) tutto?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) АQuando il tuo team legale comprende ed è investito nella strategia open source della tua azienda, sarà in grado di aiutarti meglio piuttosto che ostacolare i tuoi sforzi. +* **Conformità:** Anche se la tua azienda non rilascia progetti open source, utilizza software open source di terze parti. [Consapevolezza e processo](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) possono prevenire mal di testa, ritardi nei prodotti e azioni legali. + + + +* **Brevetti:** la tua azienda potrebbe voler aderire a [Open Invention Network](https://www.openinventionnetwork.com/), un pool di brevetti condiviso e sicuro per proteggere l'uso da parte dei membri di grandi progetti open source o per esplorare altre [licenze di brevetti alternative](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Soprattutto se e quando ha senso trasferire un progetto a [un'entità legale esterna all'azienda](../leadership-and-governance/#ho-bisogno-di-una-persona-giuridica-per-sostenere-il-mio-progetto). \ No newline at end of file diff --git a/_articles/it/maintaining-balance-for-open-source-maintainers.md b/_articles/it/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..644b85b34c5 --- /dev/null +++ b/_articles/it/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,220 @@ +--- +lang: it +untranslated: true +title: Mantenere l'equilibrio per i sostenitori dell'open source +description: Suggerimenti per la cura di sé ed evitare il burnout come caregiver. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +Man mano che il progetto open source cresce in popolarità, diventa importante stabilire confini chiari per aiutarti a mantenere un equilibrio e rimanere aggiornato e produttivo a lungo termine. + +Per ottenere informazioni dettagliate sulle esperienze dei manutentori e sulle loro strategie di bilanciamento, abbiamo condotto un workshop con 40 membri della comunità dei manutentori, che ci ha permesso di imparare da le loro esperienze di prima mano con il burnout open source e le pratiche che li hanno aiutati a mantenere l'equilibrio nel loro lavoro. È qui che entra in gioco il concetto di ecologia personale. + +Allora, cos’è l’ecologia personale? Come descritto dal Rockwood Leadership Institute, implica "mantenere equilibrio, ritmo ed efficienza per sostenere la nostra energia per tutta la vita". Questo inquadra le nostre conversazioni, aiutando i sostenitori a riconoscere le loro azioni e i loro contributi come parti di un ecosistema più ampio che si evolve nel tempo. Burnout, una sindrome derivante dallo stress cronico sul lavoro, come [definita dall’OMS](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), non è raro tra i manutentori. Ciò spesso porta a una perdita di motivazione, incapacità di concentrazione e mancanza di empatia verso i colleghi e la comunità con cui lavori. + + + +Abbracciando il concetto di ecologia personale, gli operatori sanitari possono evitare in modo proattivo il burnout, dare priorità alla cura di sé e mantenere un senso di equilibrio per svolgere al meglio il proprio lavoro. + +## Suggerimenti per la cura di sé ed evitare il burnout come personale di supporto: + +### Determina le tue motivazioni per lavorare con l'open source + +Prenditi del tempo per pensare a quali parti del supporto open source ti danno energia. Comprendere la tua motivazione può aiutarti a dare priorità al lavoro in un modo che ti mantenga impegnato e pronto per nuove sfide. Che si tratti del feedback positivo degli utenti, della gioia di collaborare e interagire con la community o della soddisfazione di immergersi nel codice, riconoscere le proprie motivazioni può aiutarti a dirigere la tua attenzione. + +### Pensa a cosa ti fa sentire sbilanciato e stressato + +È importante capire cosa ci fa bruciare. Ecco alcuni temi comuni che abbiamo riscontrato tra i sostenitori dell'open source: + +* **Mancanza di feedback positivo:** è molto più probabile che gli utenti si mettano in contatto con noi in caso di reclamo. Se tutto funziona bene, tendono a tacere. Può essere scoraggiante vedere un elenco crescente di problemi senza il feedback positivo che mostri come il tuo contributo stia facendo la differenza. + + + +* **Non dire di "NO":** Può essere facile assumersi più responsabilità del dovuto per un progetto open source. Che si tratti di utenti, contributori o altri sostenitori, non sempre possiamo essere all'altezza delle loro aspettative. + + + +* **Lavorare da soli:** Essere un manutentore può essere incredibilmente solitario. Anche se lavori con un gruppo di manutentori, negli ultimi anni è stato difficile convocare di persona i team distribuiti. + + + +* **Tempo o risorse insufficienti:** Ciò è particolarmente vero per i volontari di supporto che devono sacrificare il proprio tempo libero per lavorare a un progetto. + + + +* **Richieste contrastanti:** L'open source è pieno di gruppi con motivazioni diverse che possono essere difficili da orientare. Se sei pagato per lavorare nell'open source, gli interessi del tuo datore di lavoro a volte possono essere in contrasto con quelli della comunità. + + + +### Fai attenzione ai segni di esaurimento + +Riesci a mantenere il tuo ritmo per 10 settimane? 10 mesi? 10 anni? + +Esistono strumenti come [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) di [@shaunagm](https://github.com/shaunagm) che possono aiutarti a riflettere sul tuo ritmo attuale e vedi se ci sono modifiche che puoi apportare. Alcuni operatori sanitari utilizzano anche la tecnologia indossabile per monitorare parametri come la qualità del sonno e la variabilità della frequenza cardiaca (entrambi legati allo stress). + + + +### Di cosa hai bisogno per continuare a sostenere te stesso e la tua comunità? + +Questo apparirà diverso per ogni manutentore e cambierà a seconda della fase della tua vita e di altri fattori esterni. Ma ecco alcuni temi che abbiamo sentito: + +* **Affidati alla community:** Delegare e trovare collaboratori può alleggerire il carico di lavoro. Avere più punti di contatto per un progetto può aiutarti a stare tranquillo. Connettiti con altri manutentori e con la comunità più ampia - in gruppi come [Comunità dei manutentori](http://maintainers.github.com/). Questa può essere una grande risorsa per il supporto e la formazione tra pari. + + Puoi anche cercare modi per interagire con la comunità di utenti in modo da poter ascoltare regolarmente feedback e comprendere l'impatto del tuo lavoro open source. + +* **Esplora i finanziamenti:** Che tu stia cercando dei soldi per la pizza o stia cercando di passare a tempo pieno all'open source, ci sono molte risorse per aiutarti! Come primo passo, valuta la possibilità di attivare [Sponsor Github](https://github.com/sponsors) per consentire ad altri di sponsorizzare il tuo lavoro open source. Se stai pensando di trasferirti a tempo pieno, fai domanda per il turno successivo [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Utilizza gli strumenti:** esplora strumenti come [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions), per automatizzare le attività banali e liberare tempo per contributi più significativi. + + + +* **Riposati e ricaricati:** prenditi del tempo per i tuoi hobby e interessi al di fuori dell'open source. Prenditi dei giorni liberi per rilassarti e rigenerarti e imposta il tuo [stato GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), per riflettere la tua disponibilità! Una buona notte di sonno può fare una grande differenza nella tua capacità di sostenere i tuoi sforzi a lungo termine. + + Se trovi particolarmente piacevoli alcuni aspetti del tuo progetto, prova a strutturare il tuo lavoro in modo da poterlo sperimentare durante tutta la giornata. + + + +* **Imposta dei limiti:** non puoi dire sì a ogni richiesta. Può essere semplice come dire "Non posso farlo adesso e non ho piani per il futuro" o specificare cosa vuoi fare e cosa non fare nel README. Ad esempio, potresti dire: "Unisco solo i PR che hanno chiaramente elencato i motivi per cui sono stati creati" oppure "Esamino i problemi solo il giovedì dalle 18:00 alle 19:00". Ciò definisce le aspettative per gli altri e ti dà qualcosa a cui puntare in altri momenti per ridurre le richieste di tempo da parte di collaboratori o utenti. + + + + Impara ad essere fermo nel fermare comportamenti tossici e interazioni negative. È bene non dare energia a cose che non ti interessano. + + + + + +Ricorda che l'ecologia personale è una pratica continua che si evolverà man mano che avanzi nel tuo viaggio open source. Dando priorità alla cura di sé e mantenendo un senso di equilibrio, puoi contribuire alla comunità open source in modo efficace e sostenibile, garantendo sia il tuo benessere che il successo a lungo termine dei tuoi progetti. + +## Risorse addizionali + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series + +## Associati + +Mille grazie a tutti i manutentori che hanno condiviso con noi la loro esperienza e i loro consigli per questa guida! + +Questa guida è stata scritta da [@abbycabs](https://github.com/abbycabs) con il contributo di: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + moltri altri! \ No newline at end of file diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md new file mode 100644 index 00000000000..dbb3d9e49d2 --- /dev/null +++ b/_articles/it/metrics.md @@ -0,0 +1,128 @@ +--- +lang: it +title: Metriche Open Source +description: Prendi decisioni informate per aiutare il tuo progetto open source a prosperare misurando e monitorandone il successo. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Perché misurare qualcosa? + +I dati, se utilizzati con saggezza, possono aiutarti a prendere decisioni migliori come sostenitore dell'open source. + +Per ulteriori informazioni, puoi: + +* Scopri come gli utenti reagiscono a una nuova funzionalità +* Scopri da dove provengono i nuovi utenti +* Identificare e decidere se supportare un caso d'uso o una funzionalità eccezionale +*Quantificare la popolarità del tuo progetto +* Scopri come viene utilizzato il tuo progetto +* Raccogliere fondi attraverso sponsorizzazioni e sovvenzioni + +Per esempio [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) scopre che Google Analytics li aiuta a dare priorità al lavoro: + +> Homebrew è fornito gratuitamente ed è gestito interamente da volontari nel loro tempo libero. Di conseguenza, non abbiamo le risorse per effettuare studi dettagliati sugli utenti di Homebrew per decidere come progettare al meglio le funzionalità future e dare priorità al lavoro attuale. L'analisi anonima degli utenti aggregati ci consente di dare priorità a correzioni e funzionalità in base a come, dove e quando le persone utilizzano Homebrew. + +La popolarità non è tutto. Tutti entrano nell'open source per motivi diversi. Se il tuo obiettivo come sostenitore dell'open source è mostrare il tuo lavoro, essere trasparente riguardo al tuo codice o semplicemente divertirti, le metriche potrebbero non essere importanti per te. + +Se sei interessato a comprendere il tuo progetto a un livello più profondo, leggi i modi per analizzare l'attività del tuo progetto. + +## Scoperta + +Prima che chiunque possa utilizzare o contribuire al tuo progetto, deve sapere che esiste. Chiediti: _le persone trovano questo progetto?_ + +![Grafico del traffico](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Se il tuo progetto è ospitato su GitHub, [puoi vedere](https://help.github.com/articles/about-repository-graphs/#traffic) quante persone arrivano al tuo progetto e da dove provengono . Dalla pagina del tuo progetto, fai clic su Approfondimenti, quindi su Traffico. In questa pagina puoi vedere: + +* **Visualizzazioni di pagina totali:** indica quante volte il tuo progetto è stato visualizzato + +* **Visitatori unici totali:** Ti dice quante persone hanno visto il tuo progetto + +* **Siti di riferimento:** ti dice da dove provengono i tuoi visitatori. Questa metrica può aiutarti a capire dove raggiungere il tuo pubblico e se i tuoi sforzi di promozione stanno funzionando. + +* **Contenuti popolari:** indica dove stanno andando i visitatori nel tuo progetto, suddivisi per visualizzazioni di pagina e visitatori unici. + +[Le stelle di GitHub](https://help.github.com/articles/about-stars/) possono anche aiutare a fornire una misura di base della popolarità. Anche se le star di GitHub non sono necessariamente legate ai download e all'utilizzo, possono dirti quante persone prestano attenzione al tuo lavoro. + +Potresti anche voler [monitorare la rilevabilità di posizioni specifiche](https://opensource.com/business/16/6/pirate-metrics): ad esempio, Google PageRank, traffico proveniente da referral dal sito web del tuo progetto o referral da altri progetti o siti web open source. + +## Utilizzo + +Le persone trovano il tuo progetto in questa cosa selvaggia e folle che chiamiamo Internet. Idealmente, quando vedranno il tuo progetto, si sentiranno obbligati a fare qualcosa. La seconda domanda che dovrai porre è: _ci sono persone che utilizzano questo progetto?_ + +Se utilizzi un gestore di pacchetti come npm o RubyGems.org per distribuire il tuo progetto, potresti essere in grado di monitorare i download del tuo progetto. + +Ogni gestore di pacchetti può utilizzare una definizione leggermente diversa di "download" e i download non sono necessariamente correlati alle installazioni o all'utilizzo, ma forniscono alcune linee di base per il confronto. Prova a utilizzare [Libraries.io](https://libraries.io/) per tenere traccia delle statistiche di utilizzo su molti gestori di pacchetti popolari. + +Se il tuo progetto è su GitHub, apri nuovamente la pagina Traffico. Puoi utilizzare il [grafico dei cloni](https://github.com/blog/1873-clone-graphs) per vedere quante volte il tuo progetto è stato clonato in un determinato giorno, suddiviso in cloni totali e cloni unici. + +![Grafico dei cloni](/assets/images/metrics/clone_graph.png) + +Se l'utilizzo è basso rispetto al numero di persone che hanno scoperto il tuo progetto, ci sono due problemi da considerare. O: + +* Il tuo progetto non sta convertendo con successo il tuo pubblico, o +* Stai attirando il pubblico sbagliato + +Ad esempio, se il tuo progetto arriva sulla prima pagina di Hacker News, probabilmente noterai un picco nella scoperta (traffico) ma un tasso di conversione inferiore perché stai raggiungendo tutti su Hacker News. Tuttavia, se il tuo progetto Ruby viene presentato a una conferenza Ruby, è più probabile che tu ottenga un tasso di conversione elevato da un pubblico target. + +Cerca di capire da dove proviene il tuo pubblico e chiedi feedback agli altri sulla pagina del tuo progetto per scoprire quale di questi due problemi stai affrontando. + +Una volta che sai che le persone utilizzano il tuo progetto, potresti provare a scoprire cosa ne fanno. Si basano su di esso biforcando il codice e aggiungendo funzionalità? Lo usano per la scienza o per gli affari? + +## Presa + +Le persone trovano il tuo progetto e lo usano. La prossima domanda che ti dovrai porre è: _le persone contribuiscono a questo progetto?_ + +Non è mai troppo presto per iniziare a pensare ai collaboratori. Senza l'intervento di altre persone, rischi di metterti in una situazione malsana in cui il tuo progetto è _popolare_ (molte persone lo usano) ma non _mantenuto_ (non abbastanza tempo di supporto per soddisfare la domanda). + +La conservazione richiede anche [un afflusso di nuovi contributori](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) poiché i contributori precedentemente attivi alla fine passeranno a altre cose. + +Esempi di parametri della community che potresti voler monitorare regolarmente includono: + +* **Totale contributori e impegni per collaboratore:** indica quanti collaboratori hai e chi è più o meno attivo. Su GitHub puoi vederlo in Approfondimenti -> Collaboratori. Attualmente, questo grafico riporta solo i contributori che si sono impegnati nel ramo predefinito del repository. + +![Graffico dei collaboratori](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Primi contributori, collaboratori occasionali e ricorrenti:** ti aiuta a monitorare se ottieni nuovi contributori e se ritornano. (I contributori occasionali sono contributori con un numero limitato di commit. Che si tratti di un commit, di meno di cinque commit o di qualcos'altro dipende da te.) Senza nuovi contributori, la comunità del tuo progetto può ristagnare. + +* **Numero di problemi aperti e richieste pull aperte:** Se questi numeri diventano troppo alti, potresti aver bisogno di aiuto con l'ordinamento dei problemi e le revisioni del codice. + +* **Numero di problemi _aperti_ e richieste pull _aperte_:** I problemi aperti indicano che qualcuno è sufficientemente interessato al tuo progetto da aprire un problema. Se questo numero aumenta nel tempo, significa che le persone sono interessate al tuo progetto. + +* **Tipi di contributi:** Ad esempio, commit, correzione di errori di battitura o di commento o commento su un problema. + + + +## Attività di supporto + +Infine, ti consigliamo di chiudere il ciclo assicurandoti che i sostenitori del tuo progetto siano in grado di gestire il volume dei contributi ricevuti. L'ultima domanda che vorrai farti è: _sto (o stiamo) rispondendo alla nostra community?_ + +I manutentori che non rispondono diventano un ostacolo per i progetti open source. Se qualcuno invia un contributo ma non riceve mai risposta dal manutentore, potrebbe sentirsi scoraggiato e andarsene. + +[Una ricerca di Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggerisce che la reattività del manutentore è un fattore critico nell'incoraggiare la ripetizione dei contributi. + +Prendi in considerazione [il monitoraggio del tempo impiegato da te (o da un altro manutentore) per rispondere alle richieste pull](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), che si tratti di un problema o di una richiesta di download. La risposta non richiede alcuna azione. Potrebbe essere semplice come dire: _"Grazie per il tuo contributo! Esaminerò la questione la prossima settimana."_ + +Puoi anche misurare il tempo necessario per passare da una fase all'altra del processo di contribuzione, ad esempio: + +*Tempo medio in cui il problema rimane aperto +* Se i problemi vengono risolti dai PR +* Se i problemi obsoleti sono chiusi +*Tempo medio per unire una richiesta pull + +## Usa 📊 per conoscere le persone + +Comprendere le metriche ti aiuterà a costruire un progetto open source attivo e in crescita. Anche se non tieni traccia di tutte le metriche della dashboard, utilizza la struttura sopra per focalizzare la tua attenzione sul tipo di comportamento che aiuterà il tuo progetto a prosperare. + +[CHAOSS](https://chaoss.community/) è un'accogliente comunità open source focalizzata su analisi, metriche e software sulla salute della comunità. \ No newline at end of file diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md new file mode 100644 index 00000000000..82476c0fd9e --- /dev/null +++ b/_articles/it/starting-a-project.md @@ -0,0 +1,355 @@ +--- +lang: it +title: Avvio di un progetto open source +description: Scopri di più sul mondo dell'open source e preparati a iniziare il tuo progetto. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## Il "cosa" e il "perché" dell'open source + +Quindi stai pensando di iniziare con l'open source? Congratulazioni! Il mondo apprezza il tuo contributo. Parliamo di cos'è l'open source e perché le persone lo fanno. + +### Cosa significa "open source"? + +Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenze). + +L’open source è potente perché abbassa le barriere all’adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source. + +_Software Libero_ si riferisce allo stesso insieme di progetti di _Open Source_. A volte vedrai anche [questi termini](https://en.wikipedia.org/wiki/Free_and_open-source_software) combinati come "software libero e open source" (FOSS) o "software libero e open source" (FLOSS). _Free_ e _libre_ si riferiscono alla libertà, [non al prezzo](#open-source-significa-gratuito). + +### Защо хората отварят кода на работата си? + + + +[Ci sono molte ragioni](https://ben.balter.com/2015/11/23/why-open-source/) per cui un individuo o un'organizzazione vorrebbe rendere open source un progetto. Alcuni esempi includono: + +* **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 contributori. + +* **Adozione e remix:** i progetti open source possono essere utilizzati da chiunque per quasi tutti gli scopi. Le persone possono persino usarlo per costruire altre cose. [WordPress](https://github.com/WordPress), ad esempio, è iniziato 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ò verificare la presenza di bug o incoerenze in un progetto open source. La trasparenza è importante per governi come la [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o gli [Stati Uniti](https://sourcecode.cio.gov/), settori regolamentati come quello bancario o sanitario e software di sicurezza come [Let's Encrypt](https://github.com/letsencrypt). + +L'open source non riguarda solo il software. Puoi aprire qualsiasi cosa, dai set di dati ai libri. Dai un'occhiata a [GitHub Explore](https://github.com/explore) per idee su cos'altro puoi aprire. + +### Open source significa "gratuito"? + +Uno dei maggiori vantaggi dell'open source è che non costa denaro. Tuttavia, "gratuito" è un sottoprodotto del valore complessivo dell'open source. + +Poiché la [licenza open source richiede](https://opensource.org/definition-annotated/) che chiunque sia in grado di utilizzare, modificare e condividere il tuo progetto per quasi tutti gli scopi, i progetti stessi sono generalmente gratuiti. Se l'utilizzo del progetto costa denaro, chiunque può legalmente farne una copia e utilizzare invece 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 doppia licenza o funzionalità limitate, pur rispettando la definizione ufficiale di open source. + +## Dovrei iniziare il mio progetto open source? + +La risposta breve è sì, perché indipendentemente dal risultato, avviare il proprio progetto è un ottimo modo per imparare come funziona l'open source. + +Se non hai mai aperto un progetto open source prima, potresti essere preoccupato per ciò che la gente dirà o se qualcuno se ne accorgerà. Se suona come te, non sei solo! + +Il lavoro open source è come qualsiasi altra attività creativa, che si tratti di scrivere o disegnare. Potresti avere paura di condividere il tuo lavoro con il mondo, ma l'unico modo per migliorare è esercitarsi, anche se non hai un pubblico. + +Se non sei ancora convinto, prenditi un momento per pensare a quali potrebbero essere i tuoi obiettivi. + +### Stabilisci i tuoi obiettivi + +Gli obiettivi possono aiutarti a capire su cosa lavorare, a cosa dire di no e dove hai bisogno dell'aiuto degli altri. Inizia chiedendoti _perché sto utilizzando questo progetto open source?_ + +Non esiste un’unica risposta corretta a questa domanda. Puoi avere più obiettivi per un progetto o progetti diversi con obiettivi diversi. + +Se il tuo unico obiettivo è mettere in mostra il tuo lavoro, potresti non volere nemmeno un contributo e addirittura dirlo nel tuo README. D'altra parte, se desideri contributori, investirai tempo in una documentazione chiara e farai sentire i nuovi arrivati ​​i benvenuti. + + + +Man mano che il tuo progetto cresce, la tua comunità potrebbe aver bisogno di qualcosa di più del semplice codice, da parte tua. Rispondere ai problemi, rivedere il codice ed evangelizzare il tuo progetto sono compiti importanti in un progetto open source. + +Anche se la quantità di tempo che dedichi ad attività non di codifica dipenderà dalle dimensioni e dall'ambito del tuo progetto, dovresti essere preparato come manutentore a gestirle da solo o a trovare qualcuno che ti aiuti. + +**Se fai parte di un'azienda che offre un progetto open source,** assicurati che il tuo progetto disponga delle risorse interne necessarie per prosperare. Ti consigliamo di determinare chi è responsabile del mantenimento del progetto dopo il lancio e come condividerai tali attività con la tua comunità. + +Se hai bisogno di un budget o di personale dedicato per la promozione, le operazioni e la manutenzione del progetto, avvia queste conversazioni in anticipo. + + + +### Contributo ad altri progetti + +Se il tuo obiettivo è imparare a collaborare con gli altri o capire come funziona l'open source, valuta la possibilità di contribuire a un progetto esistente. Inizia con un progetto che già usi e che ti piace. Contribuire a un progetto può essere semplice come correggere un errore di battitura o aggiornare la documentazione. + +Se non sei sicuro di come iniziare come collaboratore, consulta la nostra [Come contribuire alla guida Open Source](../how-to-contribute/). + +## Inizia il tuo progetto open source + +Non esiste il momento perfetto per aprire la tua attività. Puoi rendere open source un'idea, in lavorazione o dopo anni di closed source. + +In generale, dovresti aprire il tuo progetto quando ti senti a tuo agio con gli altri che visualizzano e forniscono feedback sul tuo lavoro. + +Non importa in quale fase decidi di aprire il tuo progetto, ogni progetto deve includere la seguente documentazione: + +* [Open source license](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) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +In qualità di sostenitore, questi componenti ti aiuteranno a comunicare le aspettative, a gestire i contributi e a proteggere i diritti legali di tutti (inclusi i tuoi). Aumentano notevolmente le tue possibilità di un'esperienza positiva. + +Se il tuo progetto è su GitHub, posizionare questi file nella directory root con i nomi file consigliati aiuterà GitHub a riconoscerli e a mostrarli automaticamente ai tuoi lettori. + +### Selezione della licenza + +Una licenza open source garantisce che altri possano utilizzare, copiare, modificare e contribuire al tuo progetto senza conseguenze. Ti protegge anche da situazioni legali difficili. **Devi includere una licenza quando avvii un progetto open source.** + +Il lavoro legale non è divertente. La buona notizia è che puoi copiare e incollare una licenza esistente nel tuo repository. Ci vorrà solo un minuto per proteggere il tuo duro lavoro. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono le licenze open source più popolari, ma [ci sono altre opzioni](https://choosealicense.com), da qualle scegliere . + +Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una licenza open source renderà il tuo progetto GitHub open source. + +![Seleziona una licenza](/assets/images/starting-a-project/repository-license-picker.png) + +Se hai altre domande o dubbi sugli aspetti legali della gestione di un progetto open source, [ti abbiamo coperto](../legal/). + +### Scrivi README + +I README fanno molto di più che spiegare come utilizzare il tuo progetto. Spiegano anche perché il tuo progetto è importante e cosa possono farci i tuoi utenti. + +Nel README, prova a rispondere alle seguenti domande: + +*Cosa fa questo progetto? +*Perché è utile questo progetto? +* Come iniziare? +* Dove posso ottenere ulteriore aiuto se ne ho bisogno? + +Puoi utilizzare il file README per rispondere ad altre domande, ad esempio come gestisci i contributi, quali sono gli obiettivi del progetto e informazioni su licenza e attribuzione. Se non vuoi accettare contributi o il tuo progetto non è ancora pronto per la produzione, salva queste informazioni. + + + +Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв. + +Per ulteriore ispirazione, prova a utilizzare [la guida "Crea un README" di @dguo](https://www.makeareadme.com/) o [README nel modello](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) di @PurpleBooth per scrivere un completo README. + +Quando includi un file README nella directory root, GitHub lo visualizzerà automaticamente nella home page del repository. + +### Scrivi le linee guida per il tuo contributo + +Un file CONTRIBUTO indica al tuo pubblico come partecipare al tuo progetto. Ad esempio, puoi includere informazioni su: + +* Come inviare una segnalazione di bug (prova a utilizzare [modelli di richiesta problemi e pull](https://github.com/blog/2111-issue-and-pull-request-templates)) +* Come proporre una nuova funzionalità +* Come configurare il tuo ambiente ed eseguire i test + +Oltre ai dettagli tecnici, il file CONTRIBUTI è un'opportunità per comunicare le vostre aspettative per i contributi, come ad esempio: + +*I tipi di contributi che stai cercando +* La tua tabella di marcia o visione per il progetto +* Come i contributori dovrebbero (o non dovrebbero) contattarti + +Usare un tono caldo e amichevole e offrire suggerimenti specifici per i contributi (come scrivere documentazione o creare un sito web) può fare molto per far sentire i nuovi arrivati ​​benvenuti ed entusiasti di partecipare. +Per esempio [Active Admin](https://github.com/activeadmin/activeadmin/) inizia [la sua guida ai contributi](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con: + +> Innanzitutto, grazie per aver considerato di contribuire ad Active Admin. Sono le persone come te che rendono Active Admin uno strumento così eccezionale. + +Nelle prime fasi del tuo progetto, il tuo file CONTRIBUTO può essere semplice. Dovresti sempre spiegare come segnalare bug o problemi, ed eventuali requisiti tecnici (come i test) per dare un contributo. + +Nel tempo, potresti aggiungere altre domande frequenti al tuo file CONTRIBUTING. Annotare queste informazioni significa che meno persone ti faranno sempre le stesse domande. + +Per ulteriore assistenza nella scrittura del file CONTRIBUTING, consulta @nayafia [modello guida per la collaborazione](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) o @mozilla ["Come creare CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Collega il tuo file CONTRIBUTE dal tuo README in modo che più persone possano vederlo. Se [posiziona il file CONTRIBUTING nel repository del tuo progetto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub si collegherà automaticamente al tuo file quando un collaboratore crea un problema o apre una richiesta pull. + +![Linee guida per i contributi](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Creazione di un codice di condotta + + + +Infine, un codice di condotta aiuta a definire le regole di base per la condotta dei partecipanti al progetto. Ciò è particolarmente utile se stai avviando un progetto open source per una comunità o un'azienda. Un codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità che ridurrà il tuo stress come sostenitore. + +Per ulteriori informazioni, consultare 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 tali aspettative, quando si applicano e cosa fare se si verifica una violazione. + +Come per le licenze open source, esistono standard emergenti per i codici di condotta, quindi non è necessario scriverne uno proprio. Il [Contributor Covenant](https://contributor-covenant.org/) è un codice di condotta utilizzato da [oltre 40.000 progetti open source](https://www.contributor-covenant.org/adopters), incluso Kubernetes, Rails e Swift. Indipendentemente dal testo che utilizzi, devi essere pronto a far rispettare il tuo codice di condotta quando necessario. + +Incolla il testo direttamente in un file CODE_OF_CONDUCT nel tuo repository. Archivia il file nella directory principale del tuo progetto in modo che sia facile da trovare e collegalo dal tuo file README. + +## Assegna un nome e un marchio al tuo progetto + +Il branding è più di un logo appariscente o di un nome di progetto accattivante. Riguarda il modo in cui parli del tuo progetto e chi raggiungi con il tuo messaggio. + +### Scegliere il nome giusto + +Scegli un nome che sia facile da ricordare e che, idealmente, dia un'idea di ciò che fa il progetto. Per esempio: + +* [Sentry](https://github.com/getsentry/sentry) monitora le applicazioni di segnalazione degli arresti anomali +* [Thin](https://github.com/macournoyer/thin) è un server web Ruby facile e veloce + +Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window .fetch ` a Node.js). + +Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che alcune battute potrebbero non essere applicabili ad altre culture o persone con esperienze diverse dalle tue. Alcuni dei tuoi potenziali utenti potrebbero essere dipendenti dell'azienda: non vuoi farli sentire a disagio quando devono spiegare il tuo progetto al lavoro! + +### Evitare conflitti di nomi + +[Verifica la presenza di progetti open source con nomi simili](http://ivatomic.com/projects/ospnc/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico. + +Se desideri che un sito web, un account Twitter o altre proprietà rappresentino il tuo progetto, assicurati di poter ottenere i nomi che desideri. Idealmente, [salva questi nomi adesso](https://instantdomainsearch.com/) per la massima tranquillità, anche se non intendi ancora utilizzarli. + +Assicurati che il nome del tuo progetto non violi alcun marchio. Un'azienda potrebbe chiederti di rimuovere il tuo progetto in un secondo momento o addirittura intraprendere un'azione legale contro di te. Non vale la pena rischiare. + +Puoi controllare il [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) per eventuali conflitti tra marchi. Se lavori in un'azienda, questa è una delle cose in cui il tuo [team legale può aiutarti](../legal/). + +Infine, esegui una rapida ricerca su Google per il nome del tuo progetto. Le persone riusciranno a trovare facilmente il tuo progetto? C'è qualcos'altro che appare nei risultati di ricerca che non vuoi che venga visualizzato? + +### Anche il modo in cui scrivi (e codifichi) influisce sul tuo marchio! + +Nel corso della vita del tuo progetto, scriverai molto: README, tutorial, documenti della community, risposte a problemi, forse anche newsletter e mailing list. + +Che si tratti di documentazione formale o di un'e-mail informale, il tuo stile di scrittura fa parte del marchio del tuo progetto. Pensa a come potresti percepire il tuo pubblico e se questo è il tono che vuoi trasmettere. + + + +Usare un linguaggio caldo e inclusivo (come "loro" anche quando si riferisce a una sola persona) può fare molto per far sì che il tuo progetto si senta accogliente per i nuovi contributori. Attieniti a un linguaggio semplice poiché molti dei tuoi lettori potrebbero non essere di madrelingua inglese. + +Oltre al modo in cui digiti le parole, anche il tuo stile di codifica può diventare parte del marchio del tuo progetto. [Angular](https://angular.io/guide/styleguide) e [jQuery](https://contribute.jquery.org/style-guide/js/) sono due esempi di progetti con stili e linee guida di codifica rigorosi. + +Non è necessario scrivere una guida di stile per il tuo progetto quando hai appena iniziato e potresti scoprire che ti diverti comunque a incorporare diversi stili di codifica nel tuo progetto. Ma devi prevedere in che modo il tuo stile di scrittura e programmazione potrebbe attrarre o scoraggiare diversi tipi di persone. Le prime fasi del tuo progetto sono la tua opportunità per creare il precedente che desideri vedere. + +## La tua lista di controllo pre-lancio + +Pronto per aprire il tuo progetto? Ecco una lista di controllo per aiutarti. Seleziona tutte le caselle? Sei pronto per andare! [Fai clic su "pubblica"](https://help.github.com/articles/making-a-private-repository-public/) e datti una pacca sulla spalla. + +**Documentazione** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Код** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Хора** + +Se sei un privato: + +
+ + +
+ +Se sei un'azienda o un ente: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Fallo! + +Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere. \ No newline at end of file diff --git a/_data/locales/it.yml b/_data/locales/it.yml new file mode 100644 index 00000000000..a475c6c4a1b --- /dev/null +++ b/_data/locales/it.yml @@ -0,0 +1,31 @@ +it: + locale_name: Italiano + nav: + about: Chi siamo + contribute: Contribuire + index: + lead: Il software open source è creato da persone come te. Scopri come avviare e sviluppare il tuo progetto. + opensourcefriday: È venerdì! Investi qualche ora contribuendo al software che usi e ami + article: + table_of_contents: Contenuto + 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. Aiutaci a migliorarlo. + button: Contribuire + subscribe: + heading: Rimania in contatto + description: Sii il primo a conoscere gli ultimi suggerimenti e risorse open source su GitHub. + label: Email + button: Sottoscrivi + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] con [love] da [github] e [amici]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: friends \ No newline at end of file From 64676ee3cc22b447d7d4a3d7fa0ec56d1d626ab3 Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Thu, 16 May 2024 19:15:45 +0200 Subject: [PATCH 2/9] fix the links --- _articles/it/building-community.md | 2 +- _articles/it/legal.md | 6 +++--- _articles/it/starting-a-project.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md index ca9bbc4b76a..dc310250523 100644 --- a/_articles/it/building-community.md +++ b/_articles/it/building-community.md @@ -165,7 +165,7 @@ Vedi se riesci a trovare modi per condividere il più possibile la proprietà co * Se hai una community numerosa, **invia una newsletter o scrivi un post sul blog** ringraziando i contributori. [This Week in Rust](https://this-week-in-rust.org/) di Rust e [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) di Hood sono due ottimi esempi. -* **Concedi l'accesso al commit a ogni collaboratore.** @felixge ha scoperto che rendeva le persone [più entusiaste di migliorare le proprie soluzioni](https://felixge.de/2013/03/11/the-pull -request-hack. html) e ha anche trovato nuovi manutentori per progetti su cui non lavorava da un po'. +* **Concedi l'accesso al commit a ogni collaboratore.** @felixge ha scoperto che rendeva le persone [più entusiaste di migliorare le proprie soluzioni](https://felixge.de/2013/03/11/the-pull-request-hack.html) e ha anche trovato nuovi manutentori per progetti su cui non lavorava da un po'. * Se il tuo progetto è su GitHub, **sposta il tuo progetto dal tuo account personale a [Organizzazione](https://help.github.com/articles/creating-a-new-organization-account/)** e aggiungilo a almeno un amministratore di backup. Le organizzazioni facilitano il lavoro di progetto con collaboratori esterni. diff --git a/_articles/it/legal.md b/_articles/it/legal.md index 6f0c1b50011..8db4806177d 100644 --- a/_articles/it/legal.md +++ b/_articles/it/legal.md @@ -86,7 +86,7 @@ Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti op **Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software. -In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza. +In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza. ## Il mio progetto necessita di un contratto di collaborazione aggiuntivo? @@ -122,11 +122,11 @@ Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un pro **Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare: -* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-ource-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto. +* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto. * **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato. -* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ] (#quale-licenza-open-source-è-adatta-al-mio-progetto)). +* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ](#quale-licenza-open-source-è-adatta-al-mio-progetto)). * **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source. diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md index 82476c0fd9e..1a8ced0e053 100644 --- a/_articles/it/starting-a-project.md +++ b/_articles/it/starting-a-project.md @@ -222,7 +222,7 @@ Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che a ### Evitare conflitti di nomi -[Verifica la presenza di progetti open source con nomi simili](http://ivatomic.com/projects/ospnc/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico. +[Verifica la presenza di progetti open source con nomi simili](https://ivatomic.com/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico. Se desideri che un sito web, un account Twitter o altre proprietà rappresentino il tuo progetto, assicurati di poter ottenere i nomi che desideri. Idealmente, [salva questi nomi adesso](https://instantdomainsearch.com/) per la massima tranquillità, anche se non intendi ancora utilizzarli. From 9db15471f28fe0b451efdd0ea1f34b14972cdb82 Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Fri, 17 May 2024 09:46:59 +0200 Subject: [PATCH 3/9] fix the links file legal and starting-a-project --- _articles/it/legal.md | 2 +- _articles/it/starting-a-project.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/_articles/it/legal.md b/_articles/it/legal.md index 8db4806177d..14a361f9044 100644 --- a/_articles/it/legal.md +++ b/_articles/it/legal.md @@ -62,7 +62,7 @@ Molto probabilmente il tuo progetto ha (o avrà) **dipendenze**, ognuna delle qu Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci. -Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl - 3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano. +Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano. Puoi anche controllare le **community** che speri di utilizzare e contribuire al tuo progetto: diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md index 1a8ced0e053..6866d09921d 100644 --- a/_articles/it/starting-a-project.md +++ b/_articles/it/starting-a-project.md @@ -16,7 +16,7 @@ Quindi stai pensando di iniziare con l'open source? Congratulazioni! Il mondo ap ### Cosa significa "open source"? -Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenze). +Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenses). L’open source è potente perché abbassa le barriere all’adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source. From 1df5ad8fe20542a1ba417f0c4359b300b7f15710 Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Fri, 17 May 2024 09:54:35 +0200 Subject: [PATCH 4/9] fix the links file legam.md --- _articles/it/legal.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_articles/it/legal.md b/_articles/it/legal.md index 14a361f9044..0a841e46029 100644 --- a/_articles/it/legal.md +++ b/_articles/it/legal.md @@ -86,7 +86,7 @@ Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti op **Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software. -In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-datta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza. +In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza. ## Il mio progetto necessita di un contratto di collaborazione aggiuntivo? @@ -122,11 +122,11 @@ Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un pro **Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare: -* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-datta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto. +* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto. * **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato. -* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra ](#quale-licenza-open-source-è-adatta-al-mio-progetto)). +* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)). * **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source. From 473a814b199e5274f1aec55233fc1c29c47ff13e Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Fri, 17 May 2024 10:04:42 +0200 Subject: [PATCH 5/9] fix the link into folder "ms" file legal.md line 101 because it doesn't exist --- _articles/it/legal.md | 2 +- _articles/ms/legal.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/_articles/it/legal.md b/_articles/it/legal.md index 0a841e46029..d8fcd5d6768 100644 --- a/_articles/it/legal.md +++ b/_articles/it/legal.md @@ -100,7 +100,7 @@ Inoltre, aggiungendo "documentazione" che alcuni ritengono non necessaria, diffi avatar Abbiamo rimosso il CLA per Node.js. Ciò riduce la barriera all’ingresso per i contributori di Node.js, espandendo così la base dei contributori.

-— @bcantrill, ["Estensione dei contributi Node.js"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Estensione dei contributi Node.js"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md index c235cf083c9..3885ab5f60b 100644 --- a/_articles/ms/legal.md +++ b/_articles/ms/legal.md @@ -98,7 +98,7 @@ Juga, dengan menambahkan "kertas kerja" yang diyakini oleh beberapa orang tidak avatar Kami telah menghilangkan CLA untuk Node.js. Melakukan ini mengurangkan halangan kemasukan penyumbang Node.js sehingga memperluas pangkalan penyumbang.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

From 9f42419ff6d91a8e1319c94eff09db056701f245 Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Fri, 17 May 2024 10:16:32 +0200 Subject: [PATCH 6/9] I changed the link between lines 101 and 115 for the text Broadening Node.js Contributions in each legal.md file because it was persistent --- _articles/bg/legal.md | 2 +- _articles/de/legal.md | 2 +- _articles/el/legal.md | 2 +- _articles/es/legal.md | 2 +- _articles/fa/legal.md | 2 +- _articles/fr/legal.md | 2 +- _articles/hi/legal.md | 2 +- _articles/hu/legal.md | 2 +- _articles/id/legal.md | 2 +- _articles/ja/legal.md | 2 +- _articles/ko/legal.md | 2 +- _articles/legal.md | 2 +- _articles/nl/legal.md | 2 +- _articles/pcm/legal.md | 2 +- _articles/pl/legal.md | 2 +- _articles/pt/legal.md | 2 +- _articles/ro/legal.md | 2 +- _articles/ru/legal.md | 2 +- _articles/ta/legal.md | 2 +- _articles/tr/legal.md | 2 +- _articles/zh-hans/legal.md | 2 +- _articles/zh-hant/legal.md | 2 +- 22 files changed, 22 insertions(+), 22 deletions(-) diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md index 2e56c75652d..dc0024794da 100644 --- a/_articles/bg/legal.md +++ b/_articles/bg/legal.md @@ -100,7 +100,7 @@ related: avatar Премахнахме CLA за Node.js. Това намалява бариерата за навлизане на сътрудниците на Node.js, като по този начин разширява базата на сътрудниците.

-— @bcantrill, ["Разширяване на Node.js приноси"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Разширяване на Node.js приноси"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/de/legal.md b/_articles/de/legal.md index bcb45ca972a..919e8c8b671 100644 --- a/_articles/de/legal.md +++ b/_articles/de/legal.md @@ -106,7 +106,7 @@ Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verstä _We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/el/legal.md b/_articles/el/legal.md index 1abe77edf65..17a3a23c88a 100644 --- a/_articles/el/legal.md +++ b/_articles/el/legal.md @@ -98,7 +98,7 @@ related: avatar Εξαλείψαμε το CLA για το Node.js. Με αυτόν τον τρόπο μειώνουμε το εμπόδιο εισόδου για τους συνεισφέροντες του Node.js, διευρύνοντας έτσι τη βάση των συνεισφερόντων.

-- @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +- @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/es/legal.md b/_articles/es/legal.md index 241af52cf3c..3a35a1d90e2 100644 --- a/_articles/es/legal.md +++ b/_articles/es/legal.md @@ -99,7 +99,7 @@ También, al añadir "papeleo" que algunos consideran innecesario, d avatar Hemos eliminado la CLA para Node.js. Esto, reduce la barrera de entrada para colaboradores de Node.js, ampliando así la base de contribuyentes.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md index 6184e649a43..ec3c92d0b54 100644 --- a/_articles/fa/legal.md +++ b/_articles/fa/legal.md @@ -98,7 +98,7 @@ related: avatar ما «توافق‌نامه مجوز مشارکت‌کننده» را برای «Node.js» حذف کردیم. انجام این کار موانع ورود مشارکت‌کنندگان به Node.js را کاهش می‌دهد و در نتیجه میزان مشارکت‌کنندگان را گسترش می‌دهد.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md index 3a4c2818225..d1f6684bb81 100644 --- a/_articles/fr/legal.md +++ b/_articles/fr/legal.md @@ -98,7 +98,7 @@ En outre, en ajoutant de la "paperasse" jugée inutile, difficile à comprendre avatar Nous avons éliminé le CLA pour Node.js. Cela réduit la barrière à l'entrée pour les contributeurs Node.js, élargissant ainsi la base des contributeurs.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md index 7c41426a213..e2338bbd91a 100644 --- a/_articles/hi/legal.md +++ b/_articles/hi/legal.md @@ -101,7 +101,7 @@ related: avatar हमने Node.js के लिए CLA को हटा दिया है। ऐसा करने से Node.js योगदानकर्ताओं के लिए प्रवेश की बाधा कम हो जाती है जिससे योगदानकर्ता आधार का विस्तार होता है।

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md index 53395f7487e..bac119d5a27 100644 --- a/_articles/hu/legal.md +++ b/_articles/hu/legal.md @@ -98,7 +98,7 @@ Amikor ez olyan "papírmunkát" okoz, amit egyesek szükségtelennek, nehezen é avatar Megszüntettük a CLA-kat a Node.js projektben. Ezzel csökkenthető a közreműködői belépés előtt álló akadályok száma, ezáltal növelve a projektben résztvevők bázisát.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/id/legal.md b/_articles/id/legal.md index 2747d1ff891..55a93340dc6 100644 --- a/_articles/id/legal.md +++ b/_articles/id/legal.md @@ -98,7 +98,7 @@ Juga, dengan menambahkan "pekerjaan administratif" yang dipercaya oleh sebagian avatar Kami telah menghilangkan CLA untuk Node.js. Dengan melakukan hal ini akan mengurangi hambatan bagi kontributor Node.js untuk bergabung sehingga memperluas area basis kontributor.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md index 0f1be7475eb..3acc4cf2e65 100644 --- a/_articles/ja/legal.md +++ b/_articles/ja/legal.md @@ -98,7 +98,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択 avatar Node.js では CLA を廃止しました。こうすることによって、 Node.js のコントリビューターになる敷居が下がり、コントリビューターの層を広げる事ができます。

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md index 57ae35c31c8..de3c53fb3d0 100644 --- a/_articles/ko/legal.md +++ b/_articles/ko/legal.md @@ -98,7 +98,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 avatar We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.

-— @bcantrill, ["Node.js 기여 확대"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Node.js 기여 확대"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/legal.md b/_articles/legal.md index f0727ca1200..4f71db10270 100644 --- a/_articles/legal.md +++ b/_articles/legal.md @@ -100,7 +100,7 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand avatar We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md index 959495864a5..db8c07a420c 100644 --- a/_articles/nl/legal.md +++ b/_articles/nl/legal.md @@ -104,7 +104,7 @@ Door ook 'papierwerk' toe te voegen waarvan sommigen denken dat het onnodig, moe _We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._

-— @bcantrill, ["Node.js-bijdragen verbreden"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Node.js-bijdragen verbreden"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

Enkele situaties waarin u wellicht een aanvullende bijdrageovereenkomst voor uw project wilt overwegen, zijn onder meer: diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md index 7af472bef30..e4064022d10 100644 --- a/_articles/pcm/legal.md +++ b/_articles/pcm/legal.md @@ -100,7 +100,7 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand avatar We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md index b04a307d79b..82a1d32419f 100644 --- a/_articles/pl/legal.md +++ b/_articles/pl/legal.md @@ -102,7 +102,7 @@ Ponadto poprzez dodanie „dokumentacji”, którą niektórzy uważają za niep We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md index 9f593bc73fe..83933ba9c30 100644 --- a/_articles/pt/legal.md +++ b/_articles/pt/legal.md @@ -99,7 +99,7 @@ Além disso, adicionando "papelada" que alguns acreditam ser desnecessária, dif avatar Nós eliminamos o CLA do Node.js. Isso reduziu a barreira de entrada para contribuidores Node.js, consequentemente expandindo a base de contribuidores.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md index ed324150c7f..cc8aac227d2 100644 --- a/_articles/ro/legal.md +++ b/_articles/ro/legal.md @@ -112,7 +112,7 @@ De asemenea, prin adăugarea de „hârtii” pe care unii le cred nenecesare, g

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md index 37b77211338..30681090907 100644 --- a/_articles/ru/legal.md +++ b/_articles/ru/legal.md @@ -98,7 +98,7 @@ related: avatar Мы удалили CLA для Node.js. Это снижает барьер для входа в Node.js, тем самым расширяя базу участников.

-— @bcantrill, ["Расширение сообщества Node.js"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Расширение сообщества Node.js"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md index 21966f56f7d..ea5d212b395 100644 --- a/_articles/ta/legal.md +++ b/_articles/ta/legal.md @@ -98,7 +98,7 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ avatar நாம் CLA ஐ Node.js க்கு அகற்றினோம். இதை செய்வதால், Node.js பங்களிப்பாளர்களுக்கு நுழைவுக்கான தடையை குறைக்கிறது, இதனால் பங்களிப்பு தளத்தை அதிகரிக்கிறது.

-— @bcantrill, ["Node.js பங்களிப்புகளை அதிகரிக்கிறது"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Node.js பங்களிப்புகளை அதிகரிக்கிறது"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md index a12c6ec348f..b6e7b77122a 100644 --- a/_articles/tr/legal.md +++ b/_articles/tr/legal.md @@ -98,7 +98,7 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız avatar Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.

-— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md index 3f6fe8d3306..763d1149944 100644 --- a/_articles/zh-hans/legal.md +++ b/_articles/zh-hans/legal.md @@ -99,7 +99,7 @@ redirect_from: /zh-cn/legal/ avatar 我们已经删除了Node.js的CLA。这样做降低了Node.js贡献者的参与门槛，从而吸引更多的贡献者。

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md index df2d2ed9ef8..cd40cf324b8 100644 --- a/_articles/zh-hant/legal.md +++ b/_articles/zh-hant/legal.md @@ -99,7 +99,7 @@ redirect_from: /zh-tw/legal/ avatar 我們已經刪除了Node.js的CLA。這樣做降低了Node.js貢獻者的參與門檻，從而吸引更多的貢獻者。

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

From 3d619adcbb8f267714e9d23b3fa009f7f948d89a Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Fri, 17 May 2024 10:51:50 +0200 Subject: [PATCH 7/9] fix the apostrophe in folder "it" --- _articles/it/best-practices.md | 4 ++-- _articles/it/building-community.md | 10 +++++----- _articles/it/code-of-conduct.md | 7 ++++--- _articles/it/finding-users.md | 4 ++-- _articles/it/getting-paid.md | 8 ++++---- _articles/it/how-to-contribute.md | 6 +++--- _articles/it/leadership-and-governance.md | 4 ++-- _articles/it/legal.md | 4 ++-- .../maintaining-balance-for-open-source-maintainers.md | 4 ++-- _articles/it/metrics.md | 4 ++-- _articles/it/starting-a-project.md | 10 +++++----- 11 files changed, 33 insertions(+), 32 deletions(-) diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md index b9128aa7c16..73f290d99ec 100644 --- a/_articles/it/best-practices.md +++ b/_articles/it/best-practices.md @@ -119,7 +119,7 @@ Non dovresti avere più di 1-2 frasi a cui rispondere. Ad esempio, quando un ute [celery screenshot](/assets/images/best-practices/celery.png) -Se l’idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/): +Se l'idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/): > Ho parlato con manutentori del codice di molti diversi progetti open source, Mesos, Kubernetes, Chromium, e sono tutti d'accordo sul fatto che una delle parti più difficili dell'essere un manutentore del codice è: dire "No" alle patch che non vuoi utilizzare @@ -242,7 +242,7 @@ Se vuoi diventare un po' più avanzato, le guide di stile possono standardizzare Tuttavia, se i tuoi standard sono troppo complessi, possono aumentare gli ostacoli alla contribuzione. Assicurati di aggiungere solo regole per rendere la vita più semplice a tutti. -Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l’utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target. +Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l'utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target. ## È una bella pausa diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md index dc310250523..94ec2a38069 100644 --- a/_articles/it/building-community.md +++ b/_articles/it/building-community.md @@ -71,7 +71,7 @@ Se noti che molti utenti hanno lo stesso problema, documenta le risposte nel REA Per le riunioni, valuta la possibilità di pubblicare i tuoi appunti o i tuoi appunti in un thread correlato. Il feedback che otterrai da questo livello di trasparenza potrebbe sorprenderti. -Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall’inizio nel processo. +Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall'inizio nel processo. ### Sii reattivo @@ -157,7 +157,7 @@ Le persone sono entusiaste di contribuire ai progetti quando sentono un senso di Vedi se riesci a trovare modi per condividere il più possibile la proprietà con la tua comunità. Ecco alcune idee: -* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All’inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo. +* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All'inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo. ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) @@ -187,7 +187,7 @@ Nelle prime fasi del tuo progetto, prendere decisioni importanti è facile. Quan Man mano che il tuo progetto diventa più popolare, sempre più persone saranno interessate alle decisioni che prendi. Anche se non hai una grande comunità di contributori, se il tuo progetto ha molti utenti, troverai persone che valutano soluzioni o sollevano i propri problemi. -Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po’ più difficile da risolvere. +Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po' più difficile da risolvere. ### Stabilisci lo standard di civiltà @@ -219,7 +219,7 @@ Il voto può diventare politico quando i membri della comunità si sentono spint A volte è richiesto un voto di parità. Tuttavia, per quanto puoi, enfatizza ["la ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), piuttosto che consenso. -In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all’ascolto e alla discussione. +In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all'ascolto e alla discussione. -Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв. +A volte le persone evitano di scrivere un README perché pensano che il progetto sia incompiuto o non vogliono contributi. Questi sono tutti ottimi motivi per scriverne uno. Per ulteriore ispirazione, prova a utilizzare [la guida "Crea un README" di @dguo](https://www.makeareadme.com/) o [README nel modello](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) di @PurpleBooth per scrivere un completo README. @@ -191,7 +191,7 @@ Collega il tuo file CONTRIBUTE dal tuo README in modo che più persone possano v avatar Tutti abbiamo avuto esperienze in cui ci siamo imbattuti in quello che probabilmente era un abuso, sia come manutentore che cercava di spiegare perché qualcosa dovrebbe essere in un certo modo, sia come utente... che poneva una semplice domanda. (...) Il Codice di condotta diventa un documento con riferimenti e collegamenti facili che dimostra che il vostro team prende molto sul serio il discorso costruttivo.

-— @mlynch, ["Rendere l’open source un luogo più felice"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f) +— @mlynch, ["Rendere l'open source un luogo più felice"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)

@@ -216,7 +216,7 @@ Scegli un nome che sia facile da ricordare e che, idealmente, dia un'idea di ci * [Sentry](https://github.com/getsentry/sentry) monitora le applicazioni di segnalazione degli arresti anomali * [Thin](https://github.com/macournoyer/thin) è un server web Ruby facile e veloce -Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window .fetch ` a Node.js). +Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window.fetch` a Node.js). Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che alcune battute potrebbero non essere applicabili ad altre culture o persone con esperienze diverse dalle tue. Alcuni dei tuoi potenziali utenti potrebbero essere dipendenti dell'azienda: non vuoi farli sentire a disagio quando devono spiegare il tuo progetto al lavoro! @@ -305,7 +305,7 @@ Pronto per aprire il tuo progetto? Ecco una lista di controllo per aiutarti. Sel
@@ -316,7 +316,7 @@ Se sei un privato:
@@ -352,4 +352,4 @@ Se sei un'azienda o un ente: ## Fallo! -Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere. \ No newline at end of file +Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere. From 0b001cd99d8466f6a48b098a98858f6b957a9280 Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Fri, 17 May 2024 11:04:52 +0200 Subject: [PATCH 9/9] add new empty line file maintainin-balance folder it --- _articles/it/maintaining-balance-for-open-source-maintainers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/it/maintaining-balance-for-open-source-maintainers.md b/_articles/it/maintaining-balance-for-open-source-maintainers.md index bc4173c0dca..6ed6b760fc8 100644 --- a/_articles/it/maintaining-balance-for-open-source-maintainers.md +++ b/_articles/it/maintaining-balance-for-open-source-maintainers.md @@ -217,4 +217,4 @@ Questa guida è stata scritta da [@abbycabs](https://github.com/abbycabs) con il [@thisisnic](https://github.com/thisisnic) [@tudoramariei](https://github.com/tudoramariei) [@UlisesGascon](https://github.com/UlisesGascon) -[@waldyrious](https://github.com/waldyrious) + moltri altri! \ No newline at end of file +[@waldyrious](https://github.com/waldyrious) + moltri altri!