From 9fce0585b7b69a803933a275d01324726ca33c9c Mon Sep 17 00:00:00 2001
From: pipobarari <51032438+pipobarari@users.noreply.github.com>
Date: Fri, 18 Aug 2023 21:00:55 -0600
Subject: [PATCH 1/3] check current translated files
---
_articles/it/best-practices.md | 72 +++
_articles/it/building-community.md | 291 ++++++++++++
_articles/it/code-of-conduct.md | 114 +++++
_articles/it/finding-users.md | 57 +++
_articles/it/getting-paid.md | 150 +++++++
_articles/it/how-to-contribute.md | 514 ++++++++++++++++++++++
_articles/it/index.html | 6 +
_articles/it/leadership-and-governance.md | 156 +++++++
_articles/it/legal.md | 165 +++++++
_articles/it/metrics.md | 126 ++++++
_articles/it/starting-a-project.md | 363 +++++++++++++++
_data/locales/it.yml | 31 ++
12 files changed, 2045 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/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..5d089e5f089
--- /dev/null
+++ b/_articles/it/best-practices.md
@@ -0,0 +1,72 @@
+---
+lang: it
+title: Buone Pratiche per i Manutentori del Codice.
+description: Rendendo la tua vita più facile come manutentore di codice open source, dal processo di documentazione al massimizzare i benefici dalla comunità.
+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 di codice aperto che molte persone usano, probabilmente ti sei reso conto che passi più tempo a rispondere ai problemi che a programmare.
+
+Nelle prime fasi di un progetto, passi il tempo a sperimentare nuove idee e a prendere decisioni basate su ciò che ti piace. Man mano che il tuo progetto cresce in popolarità, ti troverai a lavorare sempre di più con i tuoi utenti e collaboratori.
+
+Mantenere un progetto richiede più che solo codice. Queste attività spesso non vengono prese in considerazione, ma sono altrettanto importanti per un progetto in crescita. Abbiamo raccolto alcune idee che renderanno la tua vita più facile, dal processo di documentazione al massimizzare i benefici dalla comunità.
+
+## Documentare i tuoi processi
+
+Prendere nota delle 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 cosa ti aspetti o cosa stai aspettando, senza nemmeno dover chiedere.
+
+Prendere nota dei processi semplifica il fatto di dire no quando la proposta di qualcuno non si adatta al tuo contesto. Così come rende più facile per altre persone partecipare e aiutare. Non sai mai chi potrebbe leggere o usare il tuo progetto.
+
+Anche se non sei il tipo di persona che scrive paragrafi completi, avere le note chiave è meglio che non avere niente.
+
+### Rendere chiara la visione del tuo progetto
+
+Inizia scrivendo gli obiettivi del tuo progetto. Aggiungili al tuo file README o crea un file separato chiamato VISIONE. Se ci sono altri oggetti che possono aiutare, come una mappa del progetto, rendili pubblici anche.
+
+Avere una visione chiara e documentata ti mantiene focalizzato e aiuta ad evitare malintesi sullo scopo da parte degli altri collaboratori.
+
+Ad esempio:
+@lord ha scoperto che avere la visione di un progetto lo ha aiutato a realizzare quali richieste priorizzare. Come manutentore novizio, si pentì di non essere rimasto fedele allo scopo del progetto quando ricevette la sua prima richiesta di funzionalità per [Slate](https://github.com/lord/slate).
+
+
+
+### Comunicare le tue aspettative
+
+A volte può essere difficile dettagliare le regole affinché altre persone possano contribuire. Potresti sentirti come se stessi agendo come un poliziotto o rovinando il divertimento per gli altri.
+
+Se scritte ed applicate in modo equo, le buone regole danno potere ai manutentori del codice. Ti impediscono di farti trascinare 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 venga pagato per lavorarci, specialmente se è qualcosa di cui si affidano e dipendono regolarmente. Forse un tempo dedicavi molto tempo al tuo progetto, ma ora sei occupato con un nuovo lavoro o con un membro della famiglia.
+
+¡Va benissimo! Assicurati solo che la gente lo sappia.
+
+Se mantieni il tuo progetto part-time o semplicemente come volontario, sii onesto su quanto tempo hai. Questo non è lo stesso di quanto tempo pensi che il progetto richieda o quanto tempo gli altri vogliano che tu spenda.
+
+Ecco alcune regole che potresti voler considerare:
+
+* Come viene rivista e accettata una contribuzione (_Hanno bisogno di fare dei test? C'è un modello che devono usare per le issues?_)
+* I tipi di contributi che accetterai (_Vuoi aiuto solo con una parte del codice?_)
+* Quando è appropriato fare un follow-up (_ad es. "Puoi aspettarti una risposta da un manutentore del codice entro i prossimi 7 giorni. Se non hai avuto notizie entro quel tempo, non esitare a pingare il thread."_)
+* Quanto tempo dedichi al progetto (_ad es. "Dedichiamo solo circa 5 ore a settimana a questo progetto"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), e [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) sono alcuni esempi di progetti con regole chiare per manutentori e collaboratori.
+
+### Mantenere la comunicazione pubblica
+
+Non dimenticare di documentare anche le tue interazioni. Ovunque tu possa, mantieni la comunicazione sul tuo progetto pubblica. Se qualcuno cerca di contattarti in privato per discutere una richiesta di funzionalità o un bisogno di supporto, indirizzalo educatamente verso un canale di comunicazione pubblico, come una mailing list o un issue tracker.
+
diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md
new file mode 100644
index 00000000000..6973fd583cc
--- /dev/null
+++ b/_articles/it/building-community.md
@@ -0,0 +1,291 @@
+---
+lang: it
+title: Costruendo Comunità Accoglienti
+description: Costruire una comunità che incoraggi le persone ad usare, contribuire ed educare con il loro progetto
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## Preparando il tuo progetto per il successo
+
+Hai appena lanciato il tuo progetto, stai spargendo la voce e le persone lo stanno seguendo. Fantastico! Ora, come fai a farli rimanere?
+
+Una comunità accogliente è un investimento a lungo termine nel tuo progetto e nella tua reputazione. Se il tuo progetto sta appena iniziando a vedere i suoi primi contributi, inizia offrendo ai primi collaboratori un'esperienza positiva e rendi facile per loro tornare.
+
+### Fai sentire le persone benvenute
+
+Un modo di pensare alla comunità del progetto è attraverso ciò che @MikeMcQuaid chiama [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+
+
+Mentre costruisci la tua comunità, considera come qualcuno nella parte superiore del funnel (un utente potenziale) potrebbe teoricamente fare il suo percorso verso il basso (un manutentore attivo). Il tuo obiettivo è ridurre l'attrito ad ogni fase dell'esperienza del collaboratore. Quando le persone ottengono successi facili, saranno incentivati a fare di più.
+
+Inizia con la tua documentazione:
+
+* **Rendilo semplice per chiunque debba usare il progetto.** [Un documento README amichevole](../starting-a-project/#scrivendo-un-readme) e codici di esempio chiari renderanno più facile iniziare per chiunque approdi al tuo progetto.
+* **Spiega chiaramente come contribuire,** utilizzando [un file CONTRIBUTING](../starting-a-project/#scrivendo-le-linee-guida-per-contribuire) e tenendo aggiornati i tuoi problemi.
+
+Una buona documentazione invita le persone a interagire con il tuo progetto. Eventualmente, qualcuno aprirà un problema o una pull request.
+
+* **Quando qualcuno di nuovo arriva al tuo progetto, ringrazialo per il suo interesse!** è sufficiente una sola esperienza negativa perché qualcuno non voglia tornare.
+* **Comportati in modo sensibile.** Se non rispondi ai loro problemi per un mese, è probabile che abbiano già dimenticato del tuo progetto.
+* **Mantieni una mentalità aperta riguardo ai tipi di contributi che accetterai.** Molti collaboratori iniziano segnalando un errore o con una piccola correzione. Ci sono [molti modi per contribuire](../how-to-contribute/#cosa-significa-contribuire) a un progetto. Permetti alle persone di aiutare nel modo in cui vogliono aiutare.
+* **Se c'è qualche contributo con cui non sei d'accordo,** ringrazialo per la sua idea e [spiega perché](../best-practices/#imparando-a-dire-no) non si adatta all'ambito del progetto, collegando la documentazione pertinente se ne hai.
+
+
+
+
+La mayoria de los colaboradores con el codigo abierto son "colaboradores casuales": personas que contribuyen con un proyecto solo ocasionalmente. Un colaborador casual probablemente no disponga del tiempo para dedicarse a tiempo completo a tu proyecto, por lo que tu trabajo es el de hacer que sea mas sencillo para ellos contribuir.
+
+Animar a otros colaboradores es tambien invertir en ti mismo . Cuando brinda poder a sus mas grandes seguidores paraa continuar con el trabajo que los mantiene entusiasmados, hay menos presion que si lo hicieras tu mismo.
+
+
+
+La maggior parte dei collaboratori in open source sono "collaboratori occasionali": persone che contribuiscono a un progetto solo occasionalmente. Un collaboratore occasionale probabilmente non avrà il tempo di dedicarsi a tempo pieno al tuo progetto, quindi il tuo compito è rendere più facile per loro contribuire.
+
+Incoraggiare altri collaboratori è anche un investimento in te stesso. Quando dai potere ai tuoi seguaci più grandi per continuare il lavoro che li mantiene entusiasti, c'è meno pressione rispetto a farlo da solo.
+
+### Documenta tutto
+
+
+
+Quando inizi un progetto, mantenere il tuo lavoro in privato può sembrare naturale. Ma i progetti open source progrediscono molto di più quando processi la tua documentazione in pubblico.
+
+Quando scrivi le cose, più persone possono partecipare ad ogni passo del cammino. Potresti aver bisogno di aiuto o di qualcosa che ancora non sai di aver bisogno.
+
+Documentare significa molto più che semplice documentazione tecnica. Ogni volta che senti il bisogno di scrivere qualcosa o discutere del tuo progetto in privato, chiediti se puoi farlo pubblicamente.
+
+Rimani trasparente riguardo alla roadmap del tuo progetto, ai tipi di contributi che stai cercando, come viene rivisto il lavoro di coloro che contribuiscono e perché prendi determinate decisioni.
+
+Se vedi che diversi utenti stanno lavorando sullo stesso problema, documenta le loro risposte nel README.
+
+Per le riunioni, considera di pubblicare le tue note o manifesti in un argomento rilevante. Rimarrai sorpreso dal feedback che otterrai da questo livello di trasparenza.
+
+Documentare tutto si applica anche al lavoro che fai. Se stai lavorando su un aggiornamento significativo del tuo progetto, mettilo in una pull request e contrassegnalo come lavoro in corso (WIP). In questo modo, altre persone possono sentirsi coinvolte nel processo fin dall'inizio.
+
+### Comportati in modo sensibile
+
+Man mano che [promuovi il tuo progetto](../finding-users), le persone ti daranno feedback. Potrebbero avere domande su come funzionano le cose o potrebbero aver bisogno di aiuto per iniziare.
+
+Cerca di rispondere quando qualcuno presenta un problema, invia una pull request o pone una domanda sul tuo progetto. Rispondendo rapidamente, fai sì che le persone si sentano parte del dialogo e saranno più entusiaste di partecipare.
+
+Anche se non puoi rivedere la loro richiesta immediatamente, solo ringraziando per il loro contributo anticipato aumenterai il loro impegno.
+
+Anche se non puoi rivedere la loro richiesta immediatamente, semplicemente ringraziandoli per il loro tempestivo aiuto aumenterai il loro impegno. Questo è come @tdreyno ha risposto a una pull request su [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+
+
+Uno [studio di Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) ha scoperto che i collaboratori che ricevono una revisione del loro codice entro 48 ore hanno una probabilità significativamente maggiore di tornare e ripetere un contributo.
+
+Le conversazioni sul tuo progetto possono anche avvenire in altri luoghi su internet, come Stack Overflow, Twitter o reddit. Puoi configurare le tue notifiche in uno di questi tre luoghi in modo da essere avvisato quando qualcuno menziona il tuo progetto.
+
+### Fornisci alla tua comunità un luogo di ritrovo
+
+Ci sono due ragioni per fornire alla tua comunità un luogo di ritrovo.
+
+La prima ragione è per loro. Aiuta le persone a conoscersi. Le persone con interessi comuni vorranno inevitabilmente un luogo dove parlare di esso. E quando la comunicazione è pubblica e accessibile, chiunque può leggere gli archivi passati per essere aggiornato e partecipare.
+
+La seconda ragione è per te. Se non fornisci alle persone un luogo pubblico dove parlare del tuo progetto, probabilmente ti contatteranno direttamente. All'inizio potrebbe non sembrare troppo rispondere ai messaggi privati "solo questa volta". Ma nel tempo, specialmente se il tuo progetto diventa noto, ti sentirai esausto. Evita la tentazione di comunicare con le persone sul tuo progetto in privato. Invece, indirizzali al canale pubblico designato.
+
+La comunicazione pubblica può essere semplice come indirizzare le persone a aprire un argomento piuttosto che inviarti un'e-mail direttamente o commentare sul tuo blog. Potresti anche configurare una mailing list, o creare un account su Twitter, Slack o un canale IRC affinché le persone possano discutere del tuo progetto. ¡O prova tutto!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) ha ore d'ufficio riservate per aiutare i membri della comunità ogni due settimane:
+
+> Kops ha anche ore riservate ogni due settimane per fornire aiuto e guida alla comunità. I manutentori di Kops hanno concordato di riservare ore dedicate specificamente per lavorare con i nuovi arrivati, aiutando con PR e discutendo nuove caratteristiche.
+
+Le eccezioni notevoli alla comunicazione pubblica sono: 1) questioni di sicurezza e 2) violazioni sensibili del codice di condotta. Dovresti sempre trovare un modo per permettere alle persone di segnalare questi problemi in privato. Se non vuoi usare la tua e-mail privata, configura un account di posta elettronica dedicato.
+
+## Crescere la tua comunità
+
+Le comunità sono estremamente potenti. Questa potenza può essere una benedizione o una maledizione, a seconda di come la gestisci. Man mano che la comunità del tuo progetto cresce, ci sono modi per aiutarla a diventare una forza costruttiva, non distruttiva.
+
+### Non tollerare gli attori malvagi
+
+Qualsiasi progetto popolare attirerà inevitabilmente persone che danneggiano la tua comunità, piuttosto che aiutarla. Potrebbero iniziare discussioni inutili, discutere di caratteristiche banali o prendersi gioco degli altri.
+
+Fai tutto il possibile per adottare una politica di tolleranza zero nei confronti di queste persone. Se non controllato, le persone negative faranno sì che altri membri della tua comunità si sentano a disagio. Potrebbero persino andarsene.
+
+
+
+I dibattiti regolari su aspetti banali del tuo progetto distraggono gli altri, compreso te, dal concentrarti su compiti importanti. Le nuove persone che arrivano al tuo progetto possono vedere queste conversazioni e potrebbero o non voler partecipare.
+
+Quando noti un comportamento negativo, fai la corrispondente osservazione pubblicamente. Spiegagli, in tono gentile, perché tale comportamento non è accettabile. Se il problema persiste, potresti aver bisogno di [chiedergli di andarsene](../code-of-conduct/#applicando-il-tuo-codice-di-condotta). Il tuo [codice di condotta](../code-of-conduct/) può essere una guida costruttiva per queste conversazioni.
+
+### Incontra i collaboratori dove sono
+
+Una buona documentazione diventa importante solo man mano che la tua comunità cresce. I collaboratori casuali, che altrimenti non sarebbero familiari con il tuo progetto, leggono la tua documentazione per comprendere rapidamente il contesto di ciò di cui hai bisogno.
+
+Nel tuo file CONTRIBUTING, indica esplicitamente ai nuovi collaboratori come possono iniziare. Potresti anche voler dedicare una sezione specifica a questo scopo. [Django](https://github.com/django/django), ad esempio, ha una pagina speciale per dare il benvenuto ai nuovi collaboratori.
+
+
+
+Nel tuo elenco di problemi, etichetta gli errori che sono adatti a diversi tipi di collaboratori: ad esempio, ["_solo principianti_"](https://kentcdodds.com/blog/first-timers-only), "adatto per chi risolve il suo primo bug", o "documentazione". [Queste etichette](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) rendono più facile cercare problemi da risolvere per qualcuno nuovo nel progetto e iniziare.
+
+Infine, usa la tua documentazione per far sentire le persone benvenute in ogni fase del cammino.
+
+Mai interagirai con la maggior parte delle persone che si avvicinano al tuo progetto. Potrebbero esserci collaboratori che non hai accolto perché qualcuno si è sentito intimidito o non sapeva da dove iniziare. Anche alcune parole gentili possono impedire a queste persone di abbandonare il tuo progetto per frustrazione.
+
+Ad esempio, ecco come [Rubinius](https://github.com/rubinius/rubinius/) inizia la sua [guida alla contribuzione](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> Vogliamo iniziare ringraziandoti per l'utilizzo di Rubinius. Questo progetto è un lavoro fatto con amore, e apprezziamo tutti gli utenti che individuano errori, migliorano le prestazioni e aiutano con la documentazione. Ogni contribuzione è significativa, quindi grazie per partecipare. Detto ciò, ecco alcune linee guida che chiediamo di seguire affinché possiamo affrontare con successo il tuo problema.
+
+### Condividi la proprietà del tuo progetto
+
+
+
+Le persone sono entusiaste di contribuire a progetti quando percepiscono un senso di appartenenza. Ciò non significa che devi cambiare la visione del tuo progetto o accettare contributi che non desideri. Ma quanto più dai credito agli altri, tanto più resteranno.
+
+Vedi se riesci a trovare modi per condividere la proprietà della tua comunità il più possibile. Ecco alcune idee:
+
+* **Evita di correggere errori semplici (non critici).** Al contrario, usali come opportunità per reclutare nuovi collaboratori o mentore di qualcuno che vuole contribuire. Potrebbe sembrare innaturale all'inizio, ma il tuo investimento sarà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una pull request per un problema dettagliato successivamente a [Cookiecutter](https://github.com/audreyr/cookiecutter) invece di risolverlo lui stesso.
+
+
+
+* **Inizia un file di COLLABORATORI o AUTORI nel tuo progetto** che elenchi tutti quelli che hanno collaborato al tuo progetto, come fa [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
+
+* Se hai una comunità considerevole, **invia una newsletter o scrivi un post su un blog** ringraziando i collaboratori. Rust's [This Week in Rust](https://this-week-in-rust.org/) e Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) sono due buoni esempi.
+
+* **Dai a ogni collaboratore il permesso di fare commit.** @felixge ha scoperto con questo che le persone [erano entusiaste di perfezionare le loro patch](https://felixge.de/2013/03/11/the-pull-request-hack.html), e ha anche trovato nuove persone per mantenere progetti ai quali non aveva lavorato da tempo.
+
+* Se il tuo progetto è ospitato su GitHub, **sposta il tuo progetto dal tuo account personale a un'[Organizzazione](https://help.github.com/articles/creating-a-new-organization-account/)** e aggiungi almeno un amministratore di backup. Le Organizzazioni rendono più semplice lavorare su progetti con collaboratori esterni.
+
+La realtà è che [la maggior parte dei progetti ha](https://peerj.com/preprints/1233/) una o due persone che lo mantengono e che fanno la maggior parte del lavoro. Più grande è il tuo progetto e più grande è la tua comunità, più facile è trovare aiuto.
+
+Anche se potresti non sempre trovare qualcuno che risponda alla tua richiesta, mettere un segnale là fuori aumenta le probabilità che altre persone si presentino. E più inizi presto, prima le persone potranno aiutarti.
+
+
+
+## Risoluzione dei conflitti
+
+Nelle prime fasi del tuo progetto, è abbastanza facile prendere decisioni importanti. Quando vuoi fare qualcosa, lo fai semplicemente.
+
+Man mano che il tuo progetto diventa più conosciuto, più persone avranno interesse nelle decisioni che prendi. Anche se non hai una grande comunità di collaboratori, se il tuo progetto ha molti utenti, troverai persone che influenzano le decisioni o sollevano questioni proprie.
+
+Per lo più, se hai coltivato una comunità amichevole e rispettosa e hai documentato il tuo processo in modo aperto, la tua stessa comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte potresti incontrare problemi un po' più difficili da affrontare.
+
+### Stabilire l'asticella per la gentilezza
+
+Quando la tua comunità affronta una questione difficile, le tensioni possono aumentare. Le persone potrebbero arrabbiarsi o diventare frustrate e prendere le critiche in modo personale, anche da parte tua.
+
+Il tuo compito come responsabile è evitare che queste situazioni escano fuori controllo. Anche se hai una forte opinione su un argomento, cerca di mantenere una posizione da moderatore o facilitatore, invece di entrare in lotta e spingere i tuoi punti di vista. Se qualcuno si sta comportando in modo non educato o sta monopolizzando la conversazione, [intervieni immediatamente](../building-community/#no-toleres-a-los-malos-actores) per mantenere una discussione civile e produttiva.
+
+
+
+Gli altri ti guarderanno come una guida. Dai un buon esempio. Puoi ancora esprimere disaccordo, tristezza o preoccupazione, ma in modo calmo.
+
+Mantenere la calma non è facile, ma dimostrare leadership migliora la salute della tua comunità. Internet te ne sarà grato.
+
+### Tratta il tuo README come una costituzione
+
+Il tuo README è [più di un insieme di istruzioni](../starting-a-project/#escribiendo-un-readme). è anche un luogo dove puoi parlare dei tuoi obiettivi, della visione del prodotto e di una roadmap. Se le persone si stanno concentrando troppo sul dibattito su un aspetto particolare, puoi fare riferimento al README e discutere di una visione più ampia del tuo progetto. Concentrarsi sul README rende anche la conversazione meno personale, favorendo una discussione più costruttiva.
+
+### Concentrati sul viaggio, non sulla destinazione
+
+Alcuni progetti utilizzano un processo di voto per prendere decisioni importanti. Anche se sembra sensato a prima vista, il voto mette l'accento sulla "risposta", più che sull'ascolto e sulla gestione delle preoccupazioni di ognuno.
+
+Il voto può diventare politico, quando i membri della comunità si sentono sotto pressione per favorirsi a vicenda o per votare in un certo modo. Non tutti votano, se c'è una [maggioranza silenziosa](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) nella tua comunità o se ci sono utenti che non hanno saputo che si stava svolgendo una votazione.
+
+A volte il voto diventa necessario per rompere un'eguaglianza. Nella maggior parte dei casi, però, enfatizza la ["ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) anziché il consenso stesso.
+
+Nel processo di ricerca del consenso, i membri della comunità discutono le principali preoccupazioni finché non si sentono adeguatamente ascoltati. Quando rimangono solo preoccupazioni minori, la comunità prosegue. La "ricerca del consenso" riconosce che una comunità potrebbe non essere in grado di raggiungere una risposta perfetta. Priorizza invece l'ascolto e la discussione.
+
+
+
+Anche se non adotti un processo di ricerca del consenso, come responsabile del progetto, è importante che le persone sappiano che stai ascoltando. Far sentire le persone ascoltate e impegnarti a risolvere le loro preoccupazioni copre molta strada nella risoluzione di situazioni difficili. Poi, seguisci le tue parole con azioni.
+
+Non affrettarti a prendere una decisione per il bene di avere una soluzione. Assicurati che tutti si sentano ascoltati e che tutte le informazioni siano state rese pubbliche prima di passare a una soluzione.
+
+### Mantieni la conversazione incentrata sull'azione
+
+La discussione è importante, ma c'è una differenza tra conversazioni produttive e improduttive.
+
+Fomenta la discussione finché si sta muovendo verso una soluzione. Se è chiaro che la conversazione si sta spegnendo o sta divagando, che le cose stanno diventando personali o stanno discutendo su dettagli minori, è ora di chiuderla.
+
+Permettere che queste conversazioni continuino non è solo dannoso per un dato argomento, ma anche per la salute della comunità. Manda il messaggio che questo tipo di conversazioni sono permesse e addirittura incoraggiate, e può scoraggiare le persone a sollevare o risolvere problemi futuri.
+
+Con ogni punto che hai fatto o che gli altri hanno fatto, chiediti, _"Ciò ci avvicina a una soluzione?"_
+
+Se la conversazione inizia a sciogliersi, chiedi al gruppo, _"Quali passi dovremmo prendere?"_ per ri-orientare la conversazione.
+
+Se la conversazione chiaramente non sta andando da nessuna parte, non ci sono azioni chiare da intraprendere o le azioni corrette sono già state intraprese, chiudi la discussione e spiega perché l'hai chiusa.
+
+
+
+### Scegli le tue battaglie saggiamente
+
+Il contesto è importante. Considera chi è coinvolto in una discussione e come rappresenta il resto della comunità.
+
+Tutti nella comunità sono sconvolti o anche coinvolti in un problema? O è un provocatore solitario? Non dimenticare di considerare i membri silenziosi della comunità, non solo le voci attive.
+
+Se il problema non rappresenta le esigenze più ampie della tua comunità, potresti solo aver bisogno di ringraziare alcune persone per le loro preoccupazioni. Se si tratta di un problema ricorrente senza una soluzione chiara, indirizza la discussione a discussioni precedenti e chiudi il thread di discussione.
+
+### Identifica un decisore nella comunità
+
+Con un atteggiamento positivo e una chiara comunicazione, è possibile risolvere la maggior parte delle situazioni difficili. Tuttavia, anche in una discussione produttiva, potrebbero esserci semplicemente opinioni diverse su come procedere. In questi casi, identifica un individuo o un gruppo di persone che possono agire come decisori.
+
+Un decisore può essere un responsabile principale del progetto, o potrebbe essere un piccolo gruppo di persone che prende una decisione basata sul voto. Idealmente, avrai identificato un decisore e il processo associato in un file chiamato GOVERNANCE prima di aver bisogno di usarlo.
+
+Il tuo decisore dovrebbe essere l'ultima risorsa. I problemi che dividono sono un'opportunità di crescita e apprendimento per la tua comunità. Sfrutta queste opportunità e utilizza un processo collaborativo per muoverti verso una soluzione ogni volta che sia possibile.
+
+## La comunità è il ❤️ dell'open source
+
+Le comunità sane e fiorenti alimentano le migliaia di ore di lavoro open source che vengono prodotte ogni settimana. Molti collaboratori indicano altre persone come il motivo per lavorare -o per non lavorare- in open source. Imparando a sfruttare quel potere in modo costruttivo, aiuterai qualcuno a vivere un'esperienza indimenticabile con l'open source.
diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md
new file mode 100644
index 00000000000..19cbe15d0a5
--- /dev/null
+++ b/_articles/it/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: it
+title: Il Tuo Codice di Condotta
+description: Favorisci un comportamento sano e costruttivo adottando e applicando un codice di condotta.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## Perché è necessario un codice di condotta
+
+Un codice di condotta è un documento che stabilisce le aspettative di comportamento per i partecipanti al tuo progetto. Adottare e applicare un codice di condotta aiuta a creare un'atmosfera sociale positiva per la comunità.
+
+I codici di condotta aiutano a proteggere non solo i tuoi partecipanti, ma anche te stesso. Se gestisci un progetto, sai che gli atteggiamenti controproducenti degli altri partecipanti possono farti sentire scarico di energia o infelice riguardo al tuo lavoro.
+
+Un codice di condotta ti incoraggia a favorire un comportamento sano e costruttivo da parte della comunità. Essere proattivi riduce la probabilità che tu o altri si sentano stanchi del progetto, e ti aiuta ad agire quando qualcuno fa qualcosa che non approvi.
+
+## Stabilire un codice di condotta
+
+Cerca di stabilire un codice di condotta il più presto possibile, idealmente quando crei il tuo progetto.
+
+Oltre a comunicare le tue aspettative, un codice di condotta descrive quanto segue:
+
+* Dove il codice di condotta ha effetto _(solo nelle issue e nelle pull request, o anche in attività della comunità come eventi?)_
+* A chi si applica il codice di condotta _(membri della comunità e manutentori, ma cosa succede con gli sponsor?)_
+* Cosa succede se qualcuno viola il codice di condotta
+* Come qualcuno può segnalare una violazione
+
+Ogni volta che è possibile, usa modelli già esistenti. Il [Contributor Covenant](https://www.contributor-covenant.org/) è un codice di condotta utilizzato da più di 40.000 progetti open source, inclusi Kubernetes, Rails e Swift.
+
+Il [Django Code of Conduct](https://www.djangoproject.com/conduct/) e il [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sono anche due esempi di buoni codici di condotta.
+
+Posiziona un file CODICE_DI_CONDOTTA nella directory radice del tuo progetto e collegalo dal tuo LEGGIMI, in modo che sia visibile alla tua comunità.
+
+## Decidere come applicare il tuo codice di condotta
+
+
+
+Dovresti spiegare come il tuo codice di condotta sarà applicato **_prima_** che una violazione si verifichi. Ci sono varie ragioni per farlo:
+
+* Dimostra che sei serio riguardo alle azioni quando sono necessarie.
+
+* La tua comunità si sentirà più sicura sapendo che le loro denunce sono davvero esaminate.
+
+* Fornirai alla tua comunità la rassicurazione che il processo di revisione è equo e trasparente, nel caso in cui vengano indagati per una violazione.
+
+Dovresti fornire alle persone un modo privato (ad esempio, tramite un'indirizzo e-mail) per segnalare una violazione del codice di condotta e spiegare chi riceverà tale segnalazione. Potrebbe trattarsi di un manutentore, un gruppo di manutentori o un gruppo di lavoro sul codice di condotta.
+
+Ricorda che qualcuno potrebbe voler segnalare una violazione sulla persona che riceve tali segnalazioni. In tal caso, fornisci un modo per far esaminare tali segnalazioni da qualcun altro. Ad esempio, @ctb e @mr-c [spiegano nel loro progetto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Le istanze di abuso, molestie o altri comportamenti inaccettabili possono essere segnalate inviando una e-mail a **khmer-project@idyll.org** che sarà indirizzata solo a C. Titus Brown e Michael R. Crusoe. Per segnalare un problema che coinvolge entrambi, si prega di inviare un'e-mail a **Judi Brown Clarke, Ph.D.** il Direttore della Diversità presso il BEACON Center for the Study of Evolution in Action, un centro della National Science Foundation per la Scienza e la Tecnologia.
+
+Per ispirarti, guarda il [manuale di esecuzione di Django](https://www.djangoproject.com/conduct/enforcement-manual/) (anche se potresti non aver bisogno di qualcosa di così ampio, a seconda delle dimensioni del tuo progetto).
+
+## Applicare il tuo codice di condotta
+
+A volte, nonostante i tuoi migliori sforzi, qualcuno farà qualcosa che violerà questo codice. Ci sono diversi modi per affrontare il comportamento negativo o dannoso nella pratica.
+
+### Raccogli informazioni sulla situazione
+
+Dai la stessa importanza a ciò che ogni membro della comunità ha da dire, proprio come daresti a ciò che hai da dire. Se ricevi una segnalazione che qualcuno ha violato il codice di condotta, prendila sul serio e indaga sulla questione, anche se non corrisponde alla tua esperienza con quella persona. In questo modo, dimostri alla tua comunità che apprezzi il loro punto di vista e ti fidi del loro giudizio.
+
+Il membro della comunità potrebbe essere un reincidente che costantemente mette gli altri a disagio o potrebbe avere detto o fatto qualcosa una sola volta. In entrambe le situazioni, potresti intraprendere azioni, a seconda del contesto.
+
+Prima di rispondere, prenditi del tempo per capire cosa è successo. Leggi i commenti e le conversazioni precedenti della persona per capire meglio chi sono e perché potrebbero aver agito in quel modo. Prova a raccogliere opinioni da altri su quella persona e il suo comportamento.
+
+
+
+### Prendi misure appropriate
+
+Dopo aver raccolto e elaborato informazioni sufficienti, dovrai decidere cosa fare. Mentre consideri i tuoi prossimi passi, ricorda che il tuo obiettivo come moderatore è promuovere un ambiente sicuro, rispettoso e collaborativo. Considera non solo come affrontare la situazione attuale, ma anche come la tua risposta influenzerà il comportamento e le aspettative del resto della tua comunità.
+
+Quando qualcuno segnala una violazione del codice di condotta, è compito tuo occupartene, non di qualcun altro. A volte, chi segnala sta rivelando informazioni correndo un grande rischio per la sua carriera, reputazione o integrità fisica. Forzare a confrontarsi con il loro molestatore potrebbe mettere in una posizione compromettente chi segnala. Dovresti comunicare direttamente con la persona in questione, a meno che chi segnala non chieda esplicitamente il contrario.
+
+Ci sono vari modi per rispondere a una violazione del codice di condotta:
+
+* **Dare alla persona in questione un avviso pubblico** e spiegare come il suo comportamento ha avuto un impatto negativo sugli altri, preferibilmente nel canale in cui è accaduto. Quando possibile, la comunicazione pubblica mostra alla comunità quanto seriamente consideri il codice di condotta. Sii gentile, ma deciso, nella tua comunicazione.
+
+* **Avvicinarti privatamente alla persona** in questione per spiegare come il suo comportamento ha avuto un impatto negativo sugli altri. Puoi utilizzare un canale di comunicazione privato se la situazione riguarda informazioni personali. Se ti metti in contatto privatamente con qualcuno, è una buona idea inviare una copia alla persona che ha fatto la segnalazione, in modo che sappia che hai preso delle misure. Chiedi il consenso a chi ha segnalato prima di inviare una copia.
+
+A volte, non è possibile trovare una soluzione. La persona in questione potrebbe diventare aggressiva e ostile quando viene affrontata o potrebbe non cambiare comportamento. In questa situazione, dovresti considerare di prendere misure più severe. Ad esempio:
+
+* **Sospendere la persona** in questione dal progetto, applicando un divieto di partecipazione in tutti gli aspetti del progetto.
+
+* **Espellere permanentemente** la persona dal progetto.
+
+L'espulsione dei membri non dovrebbe essere presa alla leggera e rappresenta una differenza permanente e irrimediabile di prospettive. Dovresti prendere queste misure solo quando è evidente che non si può trovare una soluzione.
+
+## Le tue responsabilità come manutentore
+
+Un codice di condotta non è una legge applicata arbitrariamente. Sei tu a applicare il codice di condotta ed è tua responsabilità seguire le regole stabilite nel codice di condotta.
+
+Come manutentore, stabilisci le linee guida della tua comunità e le applichi in base alle regole stabilite nel tuo codice di condotta. Ciò implica prendere sul serio qualsiasi violazione del codice di condotta. Chi segnala merita una giusta e completa revisione della sua segnalazione. Se determini che il comportamento segnalato non è una violazione, comunica chiaramente con loro e spiega perché non prenderai alcuna azione. Ciò che faranno in seguito dipende da loro: tollerare il comportamento con cui avevano un problema o smettere di partecipare alla comunità.
+
+Una segnalazione di comportamento che _tecnicamente_ non viola il codice di condotta potrebbe indicare che c'è un problema nella tua comunità, e dovresti indagare su questo potenziale problema e agire di conseguenza. Ciò potrebbe includere la revisione del tuo codice di condotta per chiarire comportamenti accettabili e/o parlare con la persona il cui comportamento è stato segnalato e spiegare che anche se non hanno violato il codice di condotta, stanno rasentando i limiti di ciò che è atteso e stanno mettendo a disagio certi partecipanti.
+
+Infine, come manutentore, stabilisci e applichi gli standard di comportamento accettabile. Hai la capacità di plasmare i valori della comunità del progetto e i partecipanti si aspettano che tu applichi questi valori in modo equo e imparziale.
+
+## Promuovere il comportamento che vuoi vedere nel mondo 🌍
+
+Quando un progetto sembra ostile e poco accogliente, anche quando si tratta solo di una persona il cui comportamento è tollerato dagli altri, rischi di perdere molti più contributori, alcuni dei quali forse non conoscerai mai. Non è sempre facile adottare o applicare un codice di condotta, ma promuovere un ambiente accogliente aiuterà la tua comunità a crescere.
diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md
new file mode 100644
index 00000000000..358ce598a01
--- /dev/null
+++ b/_articles/it/finding-users.md
@@ -0,0 +1,57 @@
+---
+lang: it
+title: Trovando Utenti Per Il Tuo Progetto
+description: Aiuta il tuo progetto open source a crescere mettendolo nelle mani di utenti soddisfatti.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - principianti
+ - costruzione
+---
+
+## Passaparola
+
+Non c'è una regola che dice che devi promuovere un progetto open source quando lo inizi. Ci sono molte ragioni valide per lavorare su open source che non hanno nulla a che fare con la popolarità. Tuttavia, se sperate che altri trovino e utilizzino il vostro progetto open source, è il momento di dirlo a tutti del vostro duro lavoro!
+
+## Pensando al tuo messaggio
+
+Prima di iniziare il vero lavoro di promuovere il tuo progetto, dovresti essere in grado di spiegare cosa fa e perché è importante.
+
+Cosa rende il tuo progetto diverso o interessante? Perché lo hai creato? Rispondere a queste domande per te stesso renderà più facile convincere gli altri.
+
+Ricorda che le persone si impegnano come utenti, e eventualmente come contributori, perché risolve un problema per loro. Mentre pensi al messaggio per il tuo progetto e al suo valore, prova a vederlo attraverso gli occhi di ciò che vorrebbero.
+
+## Aiuta le persone a trovare e seguire il tuo progetto
+
+Idealmente, hai bisogno di un solo URL "home" che puoi promuovere e indicare alle persone in relazione al tuo progetto. Non c'è bisogno di spendere in un template di lusso o anche in un dominio, ma il tuo progetto ha bisogno di un punto focale.
+
+**Ottieni un handle chiaro per promuovere il tuo lavoro.** Un account Twitter, un URL di GitHub o un canale IRC sono modi facili per indicare alle persone del tuo progetto. Inoltre, dà alla crescente comunità del tuo progetto un luogo dove riunirsi.
+
+Se non sei ancora pronto a stabilire questi canali per il tuo progetto, promuovi con il tuo account personale di Twitter o GitHub tutto ciò che fai. Ad esempio, assicurati che sia incluso nella tua biografia o nelle tue slide se parli a un incontro o evento. In questo modo, le persone sapranno come raggiungerti o seguire il tuo lavoro.
+
+**Considera di creare un sito web per il tuo progetto.** Un sito web rende il tuo progetto più user-friendly e più facile da navigare, specialmente se accompagnato da una chiara documentazione e tutorial. Suggerisce anche che il tuo progetto è attivo, il che rende la tua audience più confortevole nell'usarlo. Usa esempi per dare alle persone idee su come utilizzare il tuo progetto.
+
+Ora che hai un messaggio per il tuo progetto e un modo facile per le persone di trovare il tuo progetto, vai a parlare con la tua audience!
+
+## Vai dove si trova il pubblico del tuo progetto (online)
+
+Estendere online è un ottimo modo per condividere e diffondere rapidamente la parola.
+
+Sfrutta le comunità online esistenti e le loro piattaforme per raggiungere la tua audience. Se il tuo progetto open source è un progetto software, puoi probabilmente trovare la tua audience su [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), o [Quora](https://www.quora.com/). Trova i canali dove pensi che le persone otterranno i maggiori benefici o saranno più entusiaste del tuo lavoro.
+
+## Vai dove si trova il pubblico del tuo progetto (offline)
+
+Gli eventi offline sono un modo popolare per promuovere nuovi progetti. è un modo fantastico per raggiungere un pubblico impegnato e costruire connessioni personali più profonde, specialmente se sei interessato a raggiungere sviluppatori.
+
+## Costruisci una reputazione
+
+Oltre alle strategie menzionate sopra, il modo migliore per incoraggiare le persone a condividere e contribuire al tuo progetto è condividere e contribuire ai loro progetti.
+
+Aiutare i nuovi arrivati, condividere risorse e fare contributi riflessivi al lavoro degli altri ti aiuterà a costruire una reputazione positiva. Poi, le persone avranno un contesto per il tuo lavoro e saranno più propensi a prestare attenzione e condividere ciò che stai facendo.
+
+A volte, queste relazioni possono persino portare a partnership ufficiali con l'ecosistema più ampio.
+
+## Continua!
+
+A volte ci vuole molto tempo prima che le persone notino il tuo progetto open source. Va bene! Alcuni dei progetti più popolari di oggi hanno impiegato anni per raggiungere alti livelli di attività. Concentrati sulla costruzione di relazioni piuttosto che cercare una pallottola magica. Sii paziente e continua a condividere il tuo lavoro con quelli che lo apprezzano.
diff --git a/_articles/it/getting-paid.md b/_articles/it/getting-paid.md
new file mode 100644
index 00000000000..9cd3ed0fcf2
--- /dev/null
+++ b/_articles/it/getting-paid.md
@@ -0,0 +1,150 @@
+---
+lang: it
+title: Ricevere Pagamenti per Lavori in Codice Aperto
+description: Mantieni il tuo lavoro nel codice aperto trovando sostegno finanziario per il tuo tempo o per il tuo progetto.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## Perché alcune persone cercano sostegno finanziario?
+
+La maggior parte del lavoro svolto nei progetti di codice aperto è volontario. Per esempio, qualcuno potrebbe imbattersi in un bug in un progetto che utilizza e decide di applicare una rapida correzione, oppure potrebbe semplicemente amare correggere progetti di codice aperto nel loro tempo libero.
+
+
+
+Ci sono molte ragioni per cui a qualcuno potrebbe non piacere ricevere un pagamento per il suo lavoro in codice aperto.
+
+* **Potrebbero già avere un lavoro a tempo pieno che amano**, che li permette di contribuire al codice aperto nel loro tempo libero.
+* **Gli piace contribuire ai progetti di codice aperto come hobby** o come distrazione creativa e non vogliono sentirsi vincolati finanziariamente a lavorarci.
+* **Ricevono altri benefici contribuendo al codice aperto,** come costruire il proprio portafoglio di reputazione, acquisire nuove competenze o sentirsi parte di una comunità.
+
+
+
+Per altri, specialmente quando le contribuzioni sono in corso o richiedono molto tempo, ricevere denaro per contribuire al codice aperto è l'unico modo per poter partecipare. Sia perché il progetto lo richiede, sia per motivi personali.
+
+Mantenere progetti popolari può diventare una responsabilità significativa, richiedendo da 10 a 20 ore a settimana piuttosto che un paio d'ore al mese.
+
+
+
+Essere pagati per lavorare permette a tutti di contribuire significativamente. Alcuni non possono permettersi di lavorare gratuitamente sui progetti di codice aperto, a causa della loro situazione finanziaria, debiti, responsabilità familiari, o altre responsabilità. Ciò significa che il mondo non vede le contribuzioni di persone talentuose che non possono permettersi di lavorare come volontari. Queste implicazioni etiche, come descritto da @ashedryden, derivano dal fatto che il lavoro viene effettuato principalmente per il beneficio di chi è in una posizione privilegiata, che a sua volta ottiene ulteriori vantaggi dalle sue contribuzioni volontarie, mentre coloro che non possono fare volontariato non ottengono nuove opportunità, rafforzando la mancanza attuale di diversità nella comunità di codice aperto.
+
+
+
+Se stai cercando supporto finanziario, ci sono due possibili percorsi da seguire: puoi cercare di essere pagato per il tuo tempo come contributore, o puoi cercare organizzazioni che finanzino il tuo progetto.
+
+## Finanziare il tuo tempo
+
+Oggi, molte persone vengono pagate per lavorare a tempo parziale o a tempo pieno sul codice aperto. Il modo più comune per essere pagati per il proprio tempo è parlare con il proprio datore di lavoro.
+
+è più facile ottenere un lavoro sul codice aperto se il tuo datore di lavoro usa il progetto, ma cerca di essere creativo. Forse il tuo datore di lavoro non usa il progetto, ma usa Python, e mantenere un popolare progetto Python potrebbe attrarre nuovi sviluppatori Python. Potrebbe anche rendere il tuo datore di lavoro più attraente per gli sviluppatori in generale.
+
+Se non hai un interessante progetto di codice aperto su cui vorresti lavorare, ma ti piacerebbe che il tuo lavoro attuale contribuisse al codice aperto, stabilisci un accordo con il tuo datore di lavoro per contribuire ad alcune delle software interne dell'organizzazione alla comunità di codice aperto.
+
+Molte aziende stanno sviluppando programmi di codice aperto per costruire il loro marchio e reclutare talenti di qualità.
+
+@hueniverse, per esempio, ha scoperto che c'erano ragioni finanziarie per giustificare [gli investimenti di Walmart nel codice aperto](http://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 di codice aperto di Facebook ha [fatto la differenza](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) nel reclutamento:
+
+> è in linea con la nostra cultura hacker e come viene percepita la nostra organizzazione. Abbiamo chiesto ai nostri dipendenti, "Conoscevi il programma di software di codice aperto di Facebook?". Due terzi hanno detto "Sì". La metà ha detto che il programma ha contribuito positivamente alla loro decisione di lavorare per noi. Questi non sono numeri marginali e spero che questa tendenza continui.
+
+Se l'azienda decide di seguire questa strada, è importante mantenere chiara la relazione tra la comunità e l'attività aziendale. Alla fine, il codice aperto si mantiene attraverso le contribuzioni di persone di tutto il mondo, e questo è più importante dell'azienda o della sua posizione.
+
+
+
+Se non riesci a convincere il tuo attuale datore di lavoro a dare priorità al lavoro sul codice aperto, potresti considerare di trovare un nuovo datore di lavoro che incoraggi i dipendenti a contribuire. Cerca aziende che rendono esplicito il loro impegno per il codice aperto. Ad esempio:
+
+* Alcune aziende, come [Netflix](https://netflix.github.io/) o [PayPal](https://paypal.github.io/), hanno pagine web che evidenziano il loro coinvolgimento nel codice aperto.
+* [Zalando](https://opensource.zalando.com) ha pubblicato le sue [politiche di contribuzione al codice aperto](https://opensource.zalando.com/docs/using/contributing/) per i dipendenti.
+
+I progetti che hanno origine in grandi aziende, come [Go](https://github.com/golang) o [React](https://github.com/facebook/react), potrebbero considerare di assumere persone per lavorare sul codice aperto.
+
+Infine, a seconda delle tue circostanze personali, potresti considerare di cercare di guadagnare denaro in modo indipendente per finanziare il tuo lavoro sul codice aperto. Ad esempio:
+
+* @Homebrew (e [diversi manutentori e organizzazioni](https://github.com/sponsors/community)) finanziano il loro lavoro attraverso [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon ha finanziato il suo lavoro su [Redux](https://github.com/reactjs/redux) attraverso una [campagna di crowdfunding su Patreon](https://redux.js.org/)
+* @andrewgodwin ha finanziato il suo lavoro sulla migrazione degli schemi di Django attraverso [una campagna su Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+de## Trovare finanziamenti per il tuo progetto
+
+Oltre agli accordi con singoli contributori, a volte i progetti raccolgono denaro da aziende, individui o altre organizzazioni per finanziare il lavoro in corso.
+
+Il finanziamento organizzativo potrebbe andare a sostenere il pagamento dei contributori, a coprire i costi di esecuzione dei progetti (come i costi di hosting), o a esplorare nuove funzionalità o idee.
+
+Sebbene la popolarità del codice aperto stia aumentando, trovare finanziamenti per i progetti rimane sperimentale, ma ci sono alcune opzioni comunemente disponibili.
+
+### Raccogli fondi attraverso campagne di crowdfunding o sponsor.
+
+Trovare sponsor funziona se hai un'audience forte o una reputazione già stabilita, o se il tuo progetto è molto popolare.
+Esempi comuni di progetti sponsorizzati includono:
+
+* **[webpack](https://github.com/webpack)** raccoglie fondi da aziende e individui [attraverso OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://rubytogether.org/)**, un'organizzazione senza scopo di lucro che paga per il lavoro su [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) e altri progetti dell'infrastruttura Ruby.
+
+### Crea una fonte di reddito.
+
+A seconda del tuo progetto, potresti essere in grado di addebitare per il supporto commerciale o per funzionalità aggiuntive. Alcuni esempi includono:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offre versioni a pagamento per supporto aggiuntivo.
+* **[Travis CI](https://github.com/travis-ci)** offre versioni a pagamento del suo prodotto.
+* **[Ghost](https://github.com/TryGhost/Ghost)** è un ente no-profit con una versione gestita a pagamento del servizio.
+
+Alcuni progetti popolari, come [npm](https://github.com/npm/cli) e [Docker](https://github.com/docker/docker), hanno raccolto venture capital per sostenere la crescita del loro business.
+
+### Richiedere sovvenzioni.
+
+Alcune organizzazioni offrono sovvenzioni per il lavoro sul codice aperto:
+
+* **[Mozilla](https://www.mozilla.org/)** ha lanciato il suo [Open Source Support Program](https://www.mozilla.org/en-US/moss/) nel 2015.
+* **[Stripe](https://stripe.com/)** ha pagato per il lavoro su progetti specifici, come [curl](https://github.com/curl/curl).
+* **[The Python Software Foundation](https://www.python.org/psf/)** offre sovvenzioni per eventi e progetti Python.
+* **[Rails Girls Summer of Code](https://railsgirlssummerofcode.org/)** paga le donne e le persone non binarie per lavorare sui progetti di codice aperto.
+
+### Ricevere fondi come organizzazione senza scopo di lucro.
+
+Alcuni progetti hanno ottenuto lo status di ente no-profit per ricevere donazioni. Alcuni esempi includono:
+
+* **[Apache Software Foundation](https://www.apache.org/)**
+* **[Eclipse Foundation](https://www.eclipse.org/org/)**
+* **[Software in the Public Interest](https://spi-inc.org/)** (che ospita molti progetti, tra cui [Debian](https://www.debian.org/))
+* **[The Document Foundation](https://www.documentfoundation.org/)** (che ospita [LibreOffice](https://github.com/libreoffice))
+
+### Partecipare a un incubatore di codice aperto.
+
+Alcuni incubatori di codice aperto, come [Code for Science & Society](https://codeforscience.org/) o [NumFOCUS](https://numfocus.org/), offrono supporto per la gestione e la governanza dei progetti, oltre ad aiutare a trovare finanziamenti.
+
+---
+
+Speriamo che queste informazioni ti aiutino a trovare sostegno finanziario per il tuo lavoro o progetto in codice aperto. Ricorda che ogni progetto e situazione è unico, quindi ciò che funziona per uno potrebbe non funzionare per tutti. Esplora le opzioni e trova ciò che funziona meglio per te e la tua comunità. Buona fortuna!
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
new file mode 100644
index 00000000000..d6ba5d58d41
--- /dev/null
+++ b/_articles/it/how-to-contribute.md
@@ -0,0 +1,514 @@
+---
+lang: es
+title: Cómo Contribuir con el Código Abierto
+description: ¿Quieres colaborar con el código abierto? Una guía para hacer contribuciones al código abierto, para principiantes y veteranos.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## ¿Para qué contribuir?
+
+
+
+Contribuir en proyectos de código abierto puede ser una provechosa manera de aprender, enseñar, y conseguir experiencia en cualquier habilidad que puedas imaginar.
+
+¿Para qué contribuye la gente en proyectos de código abierto? ¡Por muchas razones!
+
+### Mejora tus habilidades existentes
+
+Ya sea codificación, diseño de interfaces de usuario, diseño gráfico, redacción u organización, si lo que estás buscando es práctica, hay una tarea esperándote en un proyecto de código abierto.
+
+### Conoce personas que están interesadas en temas similares
+
+Los proyectos de código abierto con comunidades cálidas y acogedoras hacen que la gente regrese a través de los años. Muchas personas forman amistades de por vida a través de su participación en el código abierto, ya sea para presenciar exposiciones en conferencias entre pares o largas conversaciones nocturnas sobre burritos.
+
+### Encuentra mentores y enseña a otros
+
+Trabajar con otros en un proyecto compartido significa que tendrás que explicar cómo haces las cosas, así como pedir ayuda. Los momentos de aprendizaje y enseñanza pueden ser actividades satisfactorias para todos los involucrados.
+
+### Construye artefactos públicos que te ayudarán a construir una reputación (y una carrera)
+
+Por definición, todo tu código abierto es público, lo que significa que consigues ejemplos de manera gratuita para llevar a cualquier lugar como una demostración de lo que haces.
+
+### Conoce las habilidades de las personas
+
+El código abierto ofrece oportunidades para practicar habilidades de liderazgo y gestión, a resolver conflictos, organizar equipos y a priorizar el trabajo.
+
+### Es poderoso ser capaz de hacer cambios, incluso pequeños
+
+No necesitas convertirte en un colaborador de toda la vida para disfrutar la participación con el código abierto. ¿Alguna vez viste un error de tipografía, y deseaste que alguien pudiera corregirlo? En un proyecto de código abierto, es justamente lo que puedes hacer. El código abierto ayuda a las personas a sentir acción en sus vidas, en la forma en que experimentan al mundo y eso en si mismo es gratificante.
+
+## Qué significa contribuir
+
+Si eres un colaborador de código abierto nuevo, el proceso puede ser intimidatorio. ¿Cómo encontrar el proyecto adecuado? ¿Qué hacer si no sabes cómo codificar? ¿Qué pasa si algo sale mal?
+
+¡No debes preocuparte! Hay todo tipo de formas de involucrarse con un proyecto de código abierto, y unos pocos consejos te ayudarán a sacar el máximo provecho de tu experiencia.
+
+### No necesitas contribuir con código
+
+Un error conceptual común acerca de contribuir con el código abierto es que debes contribuir con código. De hecho, son a menudo las otras partes de un proyecto las [más descuidadas o pasadas por alto](https://github.com/blog/2195-the-shape-of-open-source). ¡Le harás un _enorme_ favor al proyecto si te ofreces a trabajar en este tipo de contribuciones!
+
+
+
+Incluso si te gusta codificar, otro tipo de contribuciones son una gran manera de involucrarse con un proyecto y conocer a otros miembros de la comunidad. Construir esas relaciones te dará oportunidades de trabajar en otras partes del proyecto.
+
+### ¿Te gusta planificar eventos?
+
+* Organiza workshops o reuniones acerca del proyecto, [como hizo @fzamperin para NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organiza la conferencia del proyecto (si es que tienen una)
+* Ayuda a la comunidad de miembros a encontrar las conferencias apropiadas y a presentar propuestas para disertar
+
+### ¿Te gusta diseñar?
+
+* Reestructura los diseños para mejorar la usabilidad del proyecto
+* Dirige la investigación de los usuarios para reorganizar y refinar la navegación del proyecto o sus menús, [como lo sugiere Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Reúne una guía de estilos para ayudar al proyecto a tener un diseño con consistencia visual
+* Crea diseños para las remeras o un nuevo logo, [como hicieron los colaboradores de hapi.js's](https://github.com/hapijs/contrib/issues/68)
+
+### ¿Te gusta escribir?
+
+* Escribe y mejora la documentación del proyecto
+* Sanea la carpeta de ejemplos para mostrar cómo se usa el proyecto
+* Inicia el boletín informativo para el proyecto, o aspectos más destacados a enviar a la lista de correos
+* Escribe tutoriales para el proyecto, [como hicieron los colaboradores de pypa's](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Escribe una traducción de la documentación del proyecto
+
+
+
+### ¿Te gusta organizar?
+
+* Vincula los problemas duplicados, y sugiere nuevas etiquetas para los problemas, para mantener todo organizado
+* Recorre los problemas abiertos y sugiere cerrar los más antiguos, [como hizo @nzakas para eslint](https://github.com/eslint/eslint/issues/6765)
+* Realiza preguntas clarificadoras en los problemas recientemente abiertos para hacer que la discusión avance
+
+### ¿Te gusta programar?
+
+* Encuentra un problema abierto para entrar, [como lo hizo @dianjin para Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Pregunta si puedes ayudar a escribir alguna nueva funcionalidad
+* Automatiza la configuración del proyecto
+* Mejora las herramientas y las pruebas
+
+### ¿Te gusta ayudar a las personas?
+
+* Responde las preguntas acerca del proyecto en, por ejemplo, Stack Overflow ([como este ejemplo Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) o en reddit
+* Responde preguntas a las personas en los problemas abiertos
+* Ayuda a moderar los foros de discusión o canales de conversación
+
+### ¿Te gusta ayudar a otros a programar?
+
+* Revisa el código que otras personas presentan
+* Escribe tutoriales sobre cómo puede usarse un proyecto
+* Ofrécete como tutor de otro colaborador, [como lo hizo @ereichert para @bronzdocen on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### ¡No tienes que trabajar solamente en proyectos de software!
+
+Mientras que el "código abierto" a menudo se refiere a software, puedes colaborar en casi cualquier cosa. Existen libros, recetas, listas y clases que se desarrollan como proyectos de código abierto.
+
+Por ejemplo:
+
+* @sindresorhus sanea una [lista de "asombrosos"](https://github.com/sindresorhus/awesome)
+* @h5bp mantiene una [lista de preguntas potenciales para entrevistas](https://github.com/h5bp/Front-end-Developer-Interview-Questions) para desarrolladores candidatos de front-end
+* @stuartlynn y @nicole-a-tesla hicieron una [colección de hechos graciosos sobre puffins](https://github.com/stuartlynn/puffin_facts)
+
+Incluso si no eres un desarrollador de software, trabajar en la documentación de un proyecto puede ayudar a comenzar en el código abierto. Es con frecuencia menos intimidante trabajar en proyectos que no involucran código, y ese proceso de colaboración te dará confianza y experiencia.
+
+## Orientándote a un nuevo proyecto
+
+
+
+Para cualquier otra cosa distinta de una corrección de error tipográfico, contribuir con el código abierto es como caminar hacia un grupo de extraños en una fiesta. Si comienzas a hablar sobre las llamas, mientras ellos están muy involucrados en una discusión sobre el pez dorado, es probable que te miren de manera un poco extraña.
+
+Antes de lanzarte con los ojos cerrados con tus propias sugerencias, comienza aprendiendo cómo leer a la sala. Si lo haces, aumentan las probabilidades de que tus ideas se noten y sean escuchadas.
+
+### Anatomía de un proyecto de código abierto
+
+Todas las comunidades de código abierto son diferentes.
+
+Luego de pasar años en un proyecto de código abierto significa que aprendiste a conocer un proyecto de código abierto. Si te mueves a un proyecto diferente encontrarás que el vocabulario, las normas, y los estilos de comunicación son completamente diferentes.
+
+Dicho esto, muchos proyectos de código abierto siguen una estructura organizacional similar. Entender los roles de las diferentes comunidades y el proceso en general te ayudará a estar rapidamente orientado para cualquier proyecto nuevo.
+
+Un proyecto de código abierto tiene los siguientes tipos de personas:
+
+* **Autor:** La/s persona/s u organización que creó/crearon el proyecto.
+* **Dueño:** La/s persona/s que tiene/n la propiedad administrativa sobre la organización o el repositorio (no siempre es la misma que el autor original)
+* **Encargados:** Colaboradores que son responsables de dirigir la visión y de administrar aspectos organizacionales del proyecto. (Pueden también ser autores o dueños del proyecto.)
+* **Colaboradores:** Cualquiera que haya contribuido con algo al proyecto.
+* **Miembros de la comunidad:** Las personas que utilizan al proyecto. Pueden tener un rol activo en las conversaciones o expresar su opinión sobre la dirección que toma el proyecto.
+
+Los proyectos más grandes pueden tener también subcomisiones o grupos de trabajo enfocados en tareas diferentes, como herramientas, priorización de urgencias, moderación de la comunidad, y organización de eventos. Busca en el sitio web del proyecto una página del "equipo", o en su repositorio para encontrar la documentación política de gobierno, para encontrar esta documentación.
+
+Un proyecto también tiene documentación. Estos archivos están normalmente listados en un nivel alto del repositorio.
+
+* **LICENSE:** Por definición, cada proyecto de código abierto debe tener una [licencia open source](https://choosealicense.com). Si el proyecto no tiene una licencia, entonces no es de código abierto.
+* **README:** El archivo README es un manual de instrucción que da la bienvenida al proyecto a los nuevos miembros de la comunidad. Explica por qué el proyecto es útil y cómo comenzar.
+* **CONTRIBUTING:** Mientras que el archivo README ayuda a las personas a _usar_ el proyecto, el archivo CONTRIBUTING ayuda a las personas a _contribuir_ con el proyecto. Explica qué tipo de contribuciones son necesarias y cómo llevar adelante el trabajo. Si bien no todos los proyectos tienen un archivo CONTRIBUTING, su presencia señala que se trata de un buen proyecto para contribuir.
+* **CODE_OF_CONDUCT:** Sienta sólidas reglas sobre la conducta de los participantes asociados y ayuda a facilitar un entorno acogedor y amistoso. Si bien no todos los proyectos tienen un archivo CODE_OF_CONDUCT, su presencia señala que se trata de un buen proyecto para contribuir.
+* **Otra documentación:** Puede haber documentación adicional, como tutoriales, recorridos o políticas de gobierno, especialmente en proyectos de mayor envergadura.
+
+Finalmente, los proyectos de código abierto utilizan las siguientes herramientas para organizar la discusión. La lectura de estos archivos te darán una buena imagen de cómo piensa y trabaja la comunidad.
+
+* **Seguidor de problemas (Issue tracker):** Es donde las personas discuten los problemas relacionados con el proyecto.
+* **Pull requests:** Es donde las personas discuten y revisan los cambios que están en progreso.
+* **Foros de discusión o lista de correos electrónicos:** Algunos proyectos pueden utilizar estos canales de conversación para tópicos de conversación (por ejemplo _"Cómo hago para..._ o _"Qué piensas sobre..."_ en luga de reportes de errores o pedido de requerimientos). Otros utilizan un rastreador de problemas para todas las conversaciones.
+* **Canal de chat síncrono:** Algunos proyectos utilizan canales de chat (como Slack o IRC) para conversaciones casuales, colaboración e intercambios rápidos.
+
+## Encontrando un proyecto donde contribuir
+
+¡Ahora que ya has descubierto cómo funcionan los proyectos de código abierto, es tiempo de encontrar un proyecto con el que contribuir!
+
+Si nunca antes contribuiste al código abierto, acepta algunos consejos del presidente de los Estados Unidos, John F. Kennedy, quien una vez dijo, _"No preguntes qué es lo que tu país puede hacer por ti; pregúntate qué es lo que tú puedes hacer por él"_
+
+Las contribuciones al código abierto ocurren en todos los niveles a lo largo de los proyectos. No necesitas pensar demasiado cuál será tu primera colaboración, o cómo se verá.
+
+En su lugar, comienza pensando sobre el proyecto que ya estás utilizando o que quisieras utilizar. Los proyectos con los que contribuirás activamente son aquellos a los que volverás.
+
+En esos proyectos, cuando te encuentres pensando que algo podría hacerse mejor o diferente, actúa siguiendo tu instinto.
+
+El código abierto no es un club exclusivo; está hecho de personas igual a tí. El término de fantasía "Código abierto" es solo un nombre para tratar a los problemas del mundo como resolubles.
+
+Puedes recorrer un archivo README y encontrar un vínculo roto o un error tipográfico. O tal vez eres un nuevo usuario y te diste cuenta de que algo está roto, o hay un problema que crees que realmente debería estar en la documentación. En lugar de ignorarlo y continuar, o solicitar que alguien lo solucione, observa si puedes ayudar lanzándote sobre él. ¡De eso se trata el código abierto!
+
+> [El 28% de las contribuciones casuales](https://www.igor.pro.br/publica/papers/saner2016.pdf) a la documentación del código abierto se trata de documentación, como correcciones tipográficas, reformateos o redacción de una traducción.
+
+Puedes también utilizar algunos de los siguientes recursos para ayudarte a descubrir nuevos proyectos:
+
+* [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/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+
+### Una lista de verificación antes de que contribuyas
+
+Una vez que hayas encontrado un proyecto con el que quisieras contribuir, realiza un recorrido rápido para asegurarte de que el proyecto es adecuado para aceptar contribuciones. De otra manera, tu duro trabajo puede no tener nunca una respuesta.
+
+Aquí tienes una lista práctica para evaluar si un proyecto es conveniente para nuevos colaboradores.
+
+**Satisface la definición de código abierto**
+
+
+
+
+
+
+**El proyecto acepta contribuciones activamente**
+
+Observa la actividad de los commit en la rama principal. En GitHub, puedes ver esta información en la página del repositorio.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luego, busca en los problemas del proyecto.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ahora haz lo mismo para los pull requests del proyecto.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**El proyecto es acogedor**
+
+Un proyecto que es amigable y acogedor indica que será receptivo de nuevos colaboradores.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## Cómo enviar una contribución
+
+Ya encontraste un proyecto que te gustaba, y estás listo para hacer una contribución. ¡Por fin! A continuación te mostramos cómo hacer que tu contribución siga por el buen camino.
+
+### Comunicándote de manera efectiva
+
+Sin importar si eres un colaborador para una sola vez o estás intentando unirte a una comunidad, trabajar con otras personas es una de las habilidades más importantes que desarrollarás en un proyecto de código abierto.
+
+
+
+Antes de abrir un problema o un pull request, o de hacer una pregunta en un chat, ten en cuenta los siguientes puntos para ayudar a que tus ideas lleguen a buen puerto de manera efectiva.
+
+**Da contexto.** Ayuda a los demás a ponerse al día rápidamente. Si tienes un error, explica lo que estás tratando de hacer y cómo reproducirlo. Si estás sugiriendo una nueva idea, explica por qué crees que sería útil para el proyecto (¡no solamente para tí¡).
+
+> 😇 _"No ocurre X cuando yo hago Y"_
+>
+> 😢 _"¡X se ha roto! Por favor repárenlo."_
+
+**Haz tu tarea de antemano.** Está bien desconocer cosas, pero mostrando que lo intentaste. Antes de solicitar ayuda, asegúrate de comprobar el README, la documentación, los problemas (abiertos o cerrados), la lista de correos, y de buscar en internet por una respuesta. Las personas agradecerán cuando demuestres que estás tratando de aprender.
+
+> 😇 _"No estoy seguro de cómo implementar X. Verifiqué en los documentos de ayuda y no encontré ninguna mención."_
+>
+> 😢 _"¿Cómo soluciono X?"_
+
+**Mantén tus solicitudes cortas y directas.** Al igual que el envío de un correo, cualquier contribución, sin importar lo simple o útil que sea, requiere la revisión de parte de otra persona. Muchos proyectos tienen más solicitudes de entrada que personas disponibles para ayudar. Sé conciso. Aumentarás las probabilidades de que alguien pueda ayudarte.
+
+> 😇 _"Me gustaría escribir un tutorial para una API."_
+>
+> 😢 _"Días atrás estaba manejando por la autopista y me detuve para cargar combustible, y entonces tuve la gran idea de algo que deberíamos estar haciendo pero antes de explicarlo, permítanme mostrarles..."_
+
+**Mantén todas las comunicaciones públicas.** Pese a que es tentador, no te dirijas a los responsables de manera privada a menos que necesites compartir información sensible (como un problema de seguridad o violaciones a la conducta serias). Cuando mantienes las conversaciones públicas, más personas pueden aprender y verse beneficiadas de tu intercambio. La discusión puede ser, en sí misma, una contribución.
+
+> 😇 _(como un comentario) "@-responsable ¡Qué tal! ¿Cómo deberíamos proceder con este PR?"_
+>
+> 😢 _(como un correo electrónico) "Que tal, disculpa que te moleste con un correo electrónico, pero me estaba preguntando si tendrás la oportunidad de revisar mi PR"_
+
+**Está bien hacer preguntas (¡pero sé paciente!).** Todos fueron nuevos en el proyecto en algún momento, e incluso los colaboradores experimentados necesitan ponerse al día cuando miran un nuevo proyecto. Por lo mismo, incluso responsables de mucha antigüedad no están siempre familiarizados con todas las partes del proyecto. Muéstrales la misma paciencia que quieres que ellos tengan contigo.
+
+> 😇 _"Gracias por estudiar éste error. Seguí tus sugerencias. Esta es la salida."_
+>
+> 😢 _"¿Por qué no pueden solucionar mi problema? ¿No es este acaso su proyecto?"_
+
+**Respeta las decisiones de la comunidad.** Tus ideas pueden ser diferentes a las prioridades de la comunidad o a la visión. Pueden devolverte alguna retroalimentación o decidir no continuar con tu idea. Mientras que tu buscas atención y compromiso, los responsables deben convivir con tu decisión por más tiempo que tú. Si no estás de acuerdo con la dirección tomada, siempre puedes trabajar en tu propio fork o comenzar tu propio proyecto.
+
+> 😇 _"Lamento que no puedan dar soporte a mi situación, pero como lo explicas solo afecta a una minoría de usuarios, y lo entiendo. Gracias por escuchar."_
+>
+> 😢 _"¿Por qué no dan soporte a mi situación? ¡Es inaceptable!"_
+
+**Por encima de todo mantenlo con clase.** El código abierto está formado por colaboradores de todo el mundo. El contexto se pierde a través de idiomas, culturas, geografías y zonas horarias. Además, la comunicación escrita hace más difícil transmitir un tono o estado de ánimo. Asume buenas intenciones en esas conversaciones. Está bien, tratando de volver a una idea, solicitar más contexto, o aclarar más tu posición. Trata de dejar a Internet como un lugar mejor del que tú lo encontraste.
+
+### Dando contexto
+
+Antes de hacer nada, haz una rápida verificación para asegurarte que tu idea no se haya discutido anteriormente. Navega por el README del proyecto, los problemas (abiertos y cerrados), lista de correos electrónicos, y en Stack Overflow. No necesitas dedicar horas para todo esto, pero una mirada rápida buscando algunas palabras clave resolverá gran parte de la tarea.
+
+Si no puedes encontrar tu idea en ningún otro lado, estás listo para dar el paso. Si el proyecto está en GitHub, es probable que lo comuniques abriendo un problema o un pull request:
+
+* **Problemas (Issues)** son como comenzar una conversación o discusión.
+* **Pull requests** son para comenzar a trabajar en una solución.
+* **Para una comunicación ligera,** como una explicación o una pregunta de "cómo", trata preguntando en Stack Overflow, IRC, Slack u otro canal de chat, si el proyecto tiene alguno.
+
+Antes de abrir un problema o un pull request, verifica los documentos de verificación del proyecto (comúnmente es un archivo que se llama CONTRIBUTING), para ver si se necesitan incluir algo específico, puede ser que soliciten que respetes un modelo, o requerir que utilices pruebas.
+
+Si quieres hacer una contribución sustancial, abre un problema para preguntar antes de ponerte a trabajar en ello. Es de gran ayuda observar el proyecto por un tiempo (en GitHub, [puedes hacer click en "Watch"](https://help.github.com/articles/watching-repositories/) para ser notificado de todas las conversaciones), y conocer a los miembros de la comunidad, antes de realizar trabajo alguno que pueda no ser aceptado.
+
+
+
+### Abriendo un problema
+
+Frecuentemente deberías abrir un problema en las siguientes situaciones:
+
+* Reportar un error que tú no puedes resolver.
+* Discutir un tópico o idea de alto nivel (por ejemplo sobre la comunidad, la visión o políticas).
+* Proponer una nueva característica u otra idea del proyecto.
+
+Consejos para comunicar los problemas:
+
+* **Si ves un problema abierto en el que quieres entrar,** coméntalo en el problema, para permitir que las personas sepan que te preocupa. De esa manera, es menos probable que se duplique el trabajo en la comunidad.
+* **Si un problema fue abierto hace mucho tiempo,** es posible que se esté tratando en otro lugar o que ya haya sido resuelto, de modo que primero pregunta por una confirmación antes de ponerte a trabajar.
+* **Si abriste un problema, pero más tarde descubriste que estaba resuelto,** comenta en tu propio problema, para que las personas lo sepan, y luego cierra el problema. Incluso documentar ese resultado es una contribución al proyecto.
+
+### Abriendo un pull request
+
+Usualmente deberías abrir un pull request en las siguientes situaciones:
+
+* Enviar arreglos triviales (por ejemplo una corrección tipográfica, un enlace caído o un error obvio).
+* Comenzar a trabajar en una contribución que ya fue solicitada, o que ya discutiste en un problema.
+
+Un pull request no representa trabajo terminado. Usualmente es mejor abrir un pull request de forma temprana, de manera que otros puedan observar o dar retroalimentación a tu progreso. Solo márcalo como "trabajo en proceso" (WIP por sus siglas en inglés, work in progress) en la línea del tema. Siempre puedes agregar más commits después.
+
+Si el proyecto está alojado en GITHUB, acá te explicamos los pasos para enviar un pull request:
+
+* **[Abre un fork del repositorio](https://guides.github.com/activities/forking/)** y haz un clon local. Conecta tu repositorio local con el repositorio "superior" original agregándolo como remoto. Descarga los cambios desde el repositorio superior con frecuencia de manera que puedas mantener al día, de forma que cuando tu envíes tu pull request, sea menos probable que haya conflictos. (ver más instrucciones detalladas [aquí](https://help.github.com/articles/syncing-a-fork/).)
+* **[Crea una rama](https://guides.github.com/introduction/flow/)** para tus ediciones.
+* **Haz referencia a cualquier problema relevante** o documentación de soporte en tu PR (por ejemplo "Cierra #37.")
+* **Incluye capturas de pantalla del antes y del después** si tus cambios incluyen diferencias en el HTML o CSS. Arrastra y suelta las imágenes en el cuerpo de tu pull request.
+* **¡Haz pruebas de tus cambios!** Corre tus cambios contra las pruebas existentes si realmente existen, y crea nuevas pruebas si es necesario. Sin importar que existan o no las pruebas, asegúrate que tus cambios no produzcan roturas del proyecto existente.
+* **Contribuye con el estilo del proyecto** con el máximo de tus capacidades. Esto significa utilizar indentación, punto y comas o comentarios de manera diferente a lo que harías en tu repositorio, pero que hacen más sencillo para los responsables combinar y para otros de entender y mantener el proyecto en el futuro.
+
+Si se trata de tu primer pull request, verifica [Haz un Pull Request](http://makeapullrequest.com/), que fue creado por @kentcdodds como un recurso de recorrido gratuito.
+
+## Qué pasa luego de que enviaste una contribución
+
+¡Lo hiciste! Felicitaciones por convertirte en un colaborador open source. Esperamos que ésta sea la primera de muchas.
+
+Luego de que enviaste tu contribución, una de las siguientes situaciones puede ocurrir:
+
+### 😭 No tienes una respuesta.
+
+Ojalá que [hayas verificado el proyecto buscando signos de actividad](#una-lista-de-verificación-antes-de-que-contribuyas) antes de hacer cualquier contribución. Incluso en proyectos activos, de cualquier manera, es posible que tu contribución no tenga una respuesta.
+
+Si no tuviste una respuesta en más de una semana, es justo responder en el mismo hilo, preguntando a alguien por una revisión. Si conoces el nombre de la persona correcta para que revise tu contribución, puedes hacer una @-mención en ese hilo.
+
+**No contactes a esa persona** de manera privada; recuerda que las comunicaciones públicas son vitales para los proyectos de código abierto.
+
+Si haces una llamada educada y todavía nadie responde, es posible que nadie te responda jamás. No es un sentimiento agradable, pero no dejes que te desanime. ¡Les pasa a todos! Existen muchas razones posibles por las que no tuviste tu respuesta, incluyendo circunstancias personales que pueden estar fuera de control. Trata de encontrar otro proyecto u otra forma de contribuir. En todo caso, ésta es una buena razón para no invertir mucho tiempo en hacer contribuciones antes de ver que existen otros miembros en la comunidad que están comprometidos y responden.
+
+### 🚧 Alguien pide cambios a tu colaboración.
+
+Es común que te pidan hacer cambios a tu contribución, ya sea una retroalimentación sobre el alcance de tu idea, o cambios en tu código.
+
+Cuando alguien te pide cambios, compórtate de manera sensible, se tomaron el tiempo necesario para revisar tu contribución. Abrir un pull request y luego alejarse es de malos modales. Si no sabes cómo hacer los cambios, investiga el problema, y luego pregunta por ayuda si la necesitas.
+
+Si no tienes el tiempo para volver a trabajar en ese problema (por ejemplo, si la conversación tuvo lugar durante meses, y tus circunstancias cambiaron), permite que el responsable lo sepa, de manera que no quede a la espera de una respuesta. Alguien puede sentirse complacido de hacerse cargo.
+
+### 👎 Tu contribución no es aceptada.
+
+Al final tu contribución puede o no ser aceptada. Con suerte, no hayas necesitado poner demasiado esfuerzo en ella. Si no estás seguro de por qué no fue aceptada, es completamente razonable preguntar al responsable por retroalimentación y esclarecimiento. De cualquier manera, al final debes aceptar que se trata de su decisión. No discutas ni adoptes una postura hostil. ¡Siempre serás bienvenido a hacer un fork y trabajar en tu propia versión si no estás de acuerdo!
+
+### 🎉 Tu contribución es aceptada.
+
+¡Hurra! ¡Hiciste una contribución al código abierto exitosamente!
+
+## ¡Lo hiciste!
+
+Si acabas de hacer tu primera contribución al código abierto, o si estás buscando nuevas formas de contribuir, esperamos que esté inspirado para continuar la acción. Si tu contribución no fue aceptada, no te olvides de dar las gracias cuando un responsable puso esfuerzo en ayudarte. El código abierto es llevado adelante por personas como tu: un problema, un pull request, un comentario o choca esos cinco por vez.
diff --git a/_articles/it/index.html b/_articles/it/index.html
new file mode 100644
index 00000000000..a7613bd2ed5
--- /dev/null
+++ b/_articles/it/index.html
@@ -0,0 +1,6 @@
+---
+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..db7c75c3eb0
--- /dev/null
+++ b/_articles/it/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: es
+title: Liderazgo y Gobierno
+description: Los proyectos de código abierto crecientes pueden beneficiarse de reglas formales para tomar decisiones.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## Entendiendo el gobierno de su proyecto en crecimiento
+
+Tu proyecto está creciendo, la gente está comprometida, y estás comprometido a mantener esto en marcha. En esta etapa, es posible que te preguntes cómo incorporar a los contribuyentes regulares de proyectos en su flujo de trabajo, ya sea para darle a alguien el compromiso de acceso o para resolver los debates de la comunidad. Si tiene preguntas, tenemos respuestas.
+
+## ¿Cuáles son ejemplos de roles formales utilizados en proyectos de código abierto?
+
+Muchos proyectos siguen estructuras similares para reconocer y asignar roles a los contribuyentes.
+
+El significado de estos roles queda a tu criterio. Aquí puedes encontrar algunos tipos de rol que quizás reconozcas:
+
+* **Mantenedor**
+* **Contribuyente**
+* **Committer**
+
+**Para algunos proyectos, los "mantenedores"** son las únicas personas en el proyecto con permisos de commit. En otros proyectos, son simplemente personas que están listadas en el archivo README.md como mantenedores.
+
+Un mantenedor no necesariamente tiene que ser alguien que escribe código para su proyecto. Podría ser alguien que ha hecho mucho trabajo evangelizando su proyecto, o documentación escrita que hizo el proyecto más accesible a los demás. Independientemente de lo que hacen día a día, un mantenedor es probablemente alguien que se siente responsable sobre la dirección del proyecto y se ha comprometido a mejorarlo.
+
+**Un "contribuyente" puede ser cualquiera** que comente en una issue o un pull request, personas que agreguen valor al proyecto (sin importar si sólo está clasificando issues, escribiendo código u organizando eventos), o cualquiera con un merged pull request (esta es la definición más estrecha de un contribuyente).
+
+
+
+**El término "committer"** podría utilizarse para distinguir entre el acceso a commit, que es un tipo específico de responsabilidad, de otras formas de contribución.
+
+Mientras que puedes definir tus roles de proyecto de cualquier forma que quieras te gustaría [considerar usar definiciones más amplias](../how-to-contribute/#qué-significa-contribuir) para fomentar más formas de contribución. Puedes utilizar funciones de liderazgo para reconocer formalmente a personas que han hecho contribuciones excepcionales a su proyecto, independientemente de su habilidad técnica.
+
+
+
+## ¿Cómo formalizo los roles de liderazgo?
+
+La formalización de tus funciones de liderazgo ayuda a las personas a sentirse propietarias y les dice a otros miembros de la comunidad a quién deben buscar para conseguir ayuda.
+
+Para un proyecto más pequeño, designar líderes puede ser tan simple como agregar sus nombres a su archivo de texto README o CONTRIBUTORS.
+
+Por un proyecto más grande, si tienes una página web, crea una página de equipo o lista tus líderes de proyecto allí. Por ejemplo, [PostgreSQL](https://github.com/postgres/postgres/) tiene una [página exhaustiva de equipo](https://www.postgresql.org/community/contributors/) con perfiles cortos para cada contribuyente.
+
+Si tu proyecto tiene una comunidad de contribuidores muy activa, puede formar un "equipo central" de mantenedores, o incluso subcomisiones de personas que se apropian de diferentes áreas temáticas (por ejemplo, seguridad, clasificación de temas o conducta comunitaria). Permite que la gente se auto-organice y se ofrezca como voluntaria para los papeles que más le entusiasman, en lugar de asignarlos.
+
+
+
+Los equipos de liderazgo pueden querer crear un canal designado (como en IRC) o reunirse regularmente para discutir el proyecto (como en Gitter o Google Hangout). Incluso puedes hacer públicas esas reuniones para que otras personas puedan escucharlas. [Cucumber-rubí](https://github.com/cucumber/cucumber-ruby), por ejemplo, [hospeda las horas de oficina cada semana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talk-with-other-devs).
+
+Una vez que haya establecido roles de liderazgo, ¡no olvides documentar cómo la gente puede alcanzarlos! Establece un proceso claro para que alguien pueda convertirse en un mantenedor o unirse a un subcomité en su proyecto y escribirlo en su GOVERNANCE.md.
+
+Herramientas como [Vossibility](https://github.com/icecrime/vossibility-stack) puede ayudarte a hacer un seguimiento público de quién (o no) está haciendo contribuciones al proyecto. Documentar esta información evita la percepción de la comunidad de que los mantenedores son un grupo que toma sus decisiones en privado.
+
+Por último, si su proyecto está en GitHub, considere la posibilidad de mover su proyecto de su cuenta personal a una organización y agregar al menos un administrador de copias de seguridad. [Las organizaciones GitHub](https://help.github.com/articles/creating-a-new-organization-account/) facilitan la administración de permisos y múltiples repositorios y protegen el legado de su proyecto mediante [la propiedad compartida](../building-community/#comparte-la-propiedad-de-tu-proyecto).
+
+## ¿Cuándo le puedo dar acceso a hacer commits a alguien?
+
+Algunas personas piensan que debe dar acceso de commits a todos los que hacen una contribución. Hacerlo podría alentar a más personas a sentirse dueñas de su proyecto.
+
+Por otro lado, especialmente para proyectos más grandes y complejos, es posible que desee dar sólo el acceso de commit a las personas que han demostrado su compromiso. No hay una manera correcta de hacerlo - ¡Haz lo que te parezca más cómodo!
+
+Si tu proyecto está en GitHub, podés utilizar [ramas protegidas](https://help.github.com/articles/about-protected-branches/) para administrar quién puede enviar a una rama en particular y bajo qué circunstancias.
+
+
+
+## ¿Cuáles son algunas de las estructuras de gobierno comunes para los proyectos de código abierto?
+
+Hay tres estructuras de gobierno comunes asociadas a los proyectos de código abierto.
+
+* **BDFL:** BDFL significa "Benevolent Dictator for Life" (en español, "Dictador benevolente para la vida"). Bajo esta estructura, una persona (generalmente el autor inicial del proyecto) tiene la palabra final en todas las decisiones importantes del proyecto. [Python](https://github.com/python) es un ejemplo clásico. Los proyectos más pequeños son probablemente BDFL por defecto, porque sólo hay uno o dos mantenedores. Un proyecto que se originó en una empresa también podría caer en la categoría BDFL.
+
+* **Meritocracia:** **(Nota: el término "meritocracia" tiene connotaciones negativas para algunas comunidades y tiene un [historia social y político compleja](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Bajo una meritocracia, a los contribuyentes activos del proyecto (aquellos que demuestran "mérito") se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la [Fundación Apache](https://www.apache.org/); [Todos los proyectos de Apache](https://www.apache.org/index.html#projects-list) son meritocracias. Las contribuciones sólo pueden ser hechas por individuos que se representan a sí mismos, no por una empresa.
+
+* **Contribución liberal:** Bajo un modelo de contribución liberal, las personas que hacen más trabajo son reconocidas como las más influyentes, pero esto se basa en el trabajo actual y no en contribuciones históricas. Las decisiones importantes del proyecto se toman sobre la base de un proceso de búsqueda de consenso (discutir quejas mayores) en lugar de voto puro, y tratar de incluir tantas perspectivas de la comunidad como sea posible. Ejemplos populares de proyectos que utilizan un modelo de contribución liberal incluyen [Node.js](https://foundation.nodejs.org/) y [Rust](https://www.rust-lang.org/).
+
+¿Cuál deberías usar? ¡Tú decides! Cada modelo tiene ventajas y compensaciones. Y aunque pueden parecer muy diferentes al principio, los tres modelos tienen más en común de lo que parece. Si estás interesado en adoptar uno de estos modelos, consulta estas plantillas:
+
+* [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)
+
+## ¿Necesito documentación de gobierno cuando lanzo mi proyecto?
+
+No hay momento adecuado para describir el gobierno de su proyecto, pero es mucho más fácil definirlo una vez que haya visto cómo se desarrolla la dinámica de su comunidad. ¡La mejor parte (y más difícil) sobre el gobierno de código abierto es que está conformado por la comunidad!
+
+Sin embargo, una cierta documentación temprana contribuirá inevitablemente al gobierno de su proyecto, así que empiece a escribir lo que pueda. Por ejemplo, puede definir expectativas claras de comportamiento o cómo funciona su proceso de contribución, incluso en el lanzamiento de su proyecto.
+
+Si usted es parte de una empresa lanzando un proyecto de código abierto, vale la pena tener una discusión interna antes del lanzamiento acerca de cómo su empresa espera mantener y tomar decisiones sobre el proyecto de seguir adelante. También es posible que desee explicar públicamente algo en particular sobre cómo su empresa (o no) participará en el proyecto.
+
+
+
+## ¿Qué pasa cuando los empleados de corporaciones comienzan a enviar contribuciones?
+
+Los proyectos exitosos de código abierto se utilizan por muchas personas y empresas, y algunas empresas pueden eventualmente tener flujos de ingresos generalmente vinculados al proyecto. Por ejemplo, una empresa puede utilizar el código del proyecto como un componente en una oferta de servicios comerciales.
+
+A medida que el proyecto se utiliza más ampliamente, las personas que tienen experiencia en ella comienzan a estar más demandados - ¡puedes ser uno de ellos! - y a veces se les paga por el trabajo que realizan en el proyecto.
+
+Es importante tratar la actividad comercial como algo normal y como otra fuente de energía de desarrollo. Por supuesto, los desarrolladores pagados no deben recibir un trato especial sobre los no pagados. Cada contribución debe ser evaluada por sus méritos técnicos. Sin embargo, la gente debe sentirse cómoda participando en la actividad comercial, y sentirse cómoda diciendo sus casos de uso al argumentar a favor de una mejora o característica en particular.
+
+"Comercial" es completamente compatible con "código abierto". "Comercial" sólo significa que existe dinero involucrado en alguna parte - que el software se utiliza en el comercio, que es cada vez más probable como un proyecto gana la adopción. (Cuando se utiliza software de código abierto como parte de un producto que no es de código abierto, el producto general sigue siendo un software "propietario", aunque, al igual que el código abierto, podría utilizarse con fines comerciales o no comerciales).
+
+Como cualquier otra persona, los desarrolladores con motivación comercial ganan influencia en el proyecto a través de la calidad y la cantidad de sus contribuciones. Obviamente, un desarrollador al cual se le paga por su tiempo, puede ser capaz de hacer algo más que alguien al que no se le paga, pero eso está bien: el pago es sólo uno de los muchos factores posibles que podrían afectar cuánto una persona hace. Manten los debates del proyecto centrados en las contribuciones, no en los factores externos que permiten a las personas a hacer esas contribuciones.
+
+## ¿Necesito una entidad legal para apoyar a mi proyecto?
+
+Usted no necesita una entidad legal para apoyar su proyecto de código abierto a menos que esté manejando dinero.
+
+Por ejemplo, si desea crear un negocio comercial, desee configurar una C Corp o LLC (si vives en los EE.UU.). Si está haciendo un trabajo de contrato relacionado con su proyecto de código abierto, puede aceptar dinero como propietario único, o establecer una LLC (si vives en los EE.UU.).
+
+Si quieres aceptar donaciones para tu proyecto de código abierto, podes configurar un botón de donación (mediante PayPal o Stripe, por ejemplo), pero el dinero no será deducible de impuestos a menos que sea una organización sin fines de lucro calificada (un 501c3, si estás en los EE.UU.).
+
+Muchos proyectos no desean pasar por la molestia de crear una organización sin fines de lucro, por lo que encuentran un patrocinador fiscal sin fines de lucro en su lugar. Un patrocinador fiscal acepta donaciones en su nombre, normalmente a cambio de un porcentaje de la donación. [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) y [Open Collective](https://opencollective.com/opensource) son ejemplos de organizaciones que sirven como patrocinadores fiscales para proyectos de código abierto.
+
+
+
+Si tu proyecto está estrechamente asociado con un determinado idioma o ecosistema, también puede haber un framework relacionado con el que pueda trabajar. Por ejemplo, la [Python Software Foundation](https://www.python.org/psf/) ayuda a [PyPI](https://pypi.org/), el gestor de paquetes de Python y el [Node.js Foundation](https://foundation.nodejs.org/) ayuda a apoyar [Express.js](https://expressjs.com/), un framework basado en nodos.
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
new file mode 100644
index 00000000000..9ca5e57f0cd
--- /dev/null
+++ b/_articles/it/legal.md
@@ -0,0 +1,165 @@
+---
+lang: es
+title: Aspectos legales del código abierto.
+description: Todo lo que te has preguntado sobre la parte legal de código abierto.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## Entendiendo las implicaciones legales del código abierto
+
+Compartir tu trabajo creativo con el mundo puede ser una experiencia excitante y gratificante. Esto también conlleva un conjunto de aspectos legales de los cuales debes ocuparte. Afortunadamente, no tienes que empezar desde cero. Nosotros tenemos cubiertas tus necesidades legales. (Antes de continuar, asegúrate de leer nuestro [aviso legal](/notices/).)
+
+## ¿Por qué la gente se preocupa tanto acerca de los aspectos legales del código abierto?
+
+¡Me alegro que lo preguntes! Cuando realizas trabajo creativo (como escritura, dibujo, o código), ese trabajo se encuentra bajo derechos de autor por defecto. Es decir, la ley asume que, como autor de tu trabajo, tienes poder de decisión sobre lo que los otros pueden o no hacer con ello.
+
+En general, esto significa que nadie más puede usar, copiar, distribuir, o modificar tu trabajo sin tener riesgo de sufrir bajas, ser investigado o demandado.
+
+Sin embargo, el código abierto es una circunstancia inusual debido a que el autor espera que otros usen, modifiquen, y compartan el trabajo. Pero, debido a que legalmente por defecto los derechos de autor son exclusivos, se necesita una licencia que enuncie explícitamente estos permisos.
+
+Si tú no aplicas una licencia de código abierto, todo aquel que contribuya a tu proyecto también tiene derechos de autor de su trabajo. Esto significa que nadie puede usar, copiar, distribuir, o modificar sus contribuciones – y ese "nadie" te incluye a ti.
+
+Finalmente, tu proyecto puede tener dependencias con requisitos de licencia que no conoces. La comunidad de tu proyecto, o tus políticas de empleador, pueden requerir que tu proyecto haga uso de una licencia de código abierto específica. Cubriremos estas situaciones a continuación.
+
+## ¿Son públicos los proyectos de código abierto de GitHub?
+
+Cuando tú [creas un nuevo proyecto](https://help.github.com/articles/creating-a-new-repository/) en GitHub, tienes la opción de hacerlo **privado** o **público**.
+
+
+
+**Hacer tu proyecto de GitHub público, no es lo mismo que licenciar tu proyecto.** Los proyectos públicos son cubiertos por [los Términos de Servicio de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.
+
+Si quieres que otros usen, copien, modifiquen, o contribuyan a tu proyecto, debes incluir una licencia de código abierto. Por ejemplo, nadie puede usar legalmente cualquier parte de tu proyecto de GitHub en su código, incluso si es público, a menos que explícitamente le concedas dicho derecho.
+
+## Solo dame un resumen acerca de lo que necesito para proteger mi proyecto.
+
+Tienes suerte, porque hoy, las licencias de código abierto están estandarizadas y son fáciles de usar. Puedes copiar-pegar una licencia existente directamente en tu proyecto.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), y [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) son las licencias de código abierto más populares, pero también tienes otras opciones para elegir. Puedes encontrar un texto completo sobre estas licencias, e instrucciones de uso de las mismas en [choosealicense.com](https://choosealicense.com/).
+
+Cuando crees un nuevo proyecto en GitHub, se te [pedirá que agregues una licencia](https://help.github.com/articles/open-source-licensing/).
+
+
+
+## ¿Cuál licencia de código abierto es apropiada para mi proyecto?
+
+Si estás comenzando desde cero, es difícil equivocarse al elegir la [Licencia MIT](https://choosealicense.com/licenses/mit/). Es corta, muy fácil de entender, y permite a cualquiera hacer lo que sea, siempre y cuando guarde una copia de la licencia, incluyendo tu aviso de derechos de autor. Tendrás la posibilidad de lanzar el proyecto bajo otra licencia si alguna vez así lo necesitas.
+
+Elegir la licencia de código abierto correcta para tu proyecto, depende de tus objetivos.
+
+Muy probablemente, tu proyecto tiene (o tendrá) **dependencias**. Por ejemplo, si es un proyecto de código abierto de Node.js, seguramente utilizarás librerías del Node Package Manager (npm). Cada una de esas librerías que utilizas, tendrán su propia licencia de código abierto. Si cada una de dichas licencias es "permisiva" (otorga permiso público de uso, modificación, y distribución, sin ninguna condición de bajada), puedes usar cualquier licencia que quieras. Las licencias permisivas más comunes son MIT, Apache 2.0, ISC, y BSD.
+
+Por otro lado, si cualquiera de las licencias de tus dependencias son copyleft "fuerte" (también brindan los mismos permisos, siempre y cuando se utilice la misma licencia consecuente), en este caso, tu proyecto deberá usar la misma licencia. Las licencias strong copyleft más comunes son GPLv2, GPLv3, and AGPLv3.
+
+Deberías considerar también a las **comunidades** qué esperas que usarán y contribuirán a tu proyecto:
+
+* **¿Quieres que tu proyecto sea usado como dependencia por otros proyectos?** Probablemente, la mejor opción sea usar la licencia más popular en tu comunidad. Por ejemplo, [MIT](https://choosealicense.com/licenses/mit/) es la licencia más popular para [npm libraries](https://libraries.io/search?platforms=NPM).
+* **¿Quieres que tu proyecto atraiga a grandes empresas?** Una gran empresa seguramente querrá una licencia de patente expresa por parte de todos los contribuyentes. En este caso, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) te tiene a ti (y a ellos) cubiertos.
+* **¿Quieres que tu proyecto atraiga a colaboradores los cuales no quieren que sus contribuciones sean usado en software de código cerrado?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (si tampoco quieren contribuir a servicios de código cerrado) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sería el más apropiado.
+
+Tu **empresa** puede que tenga requisitos específicos para licencias de proyectos de código abierto. Por ejemplo, tal vez requiera una licencia permisiva de modo que dicho proyecto pueda utilizarse en el producto de código cerrado de dicha empresa. O tu empresa puede requerir una licencia strong copyleft y un acuerdo de colaboradores adicional (leer más abajo) para que solo tu empresa, y nadie más, pueda usar tu proyecto en software de código cerrado. O tal vez, tu empresa tiene ciertas necesidades relacionadas con estándares, responsabilidad social, o transparencia; en tales casos requerirán una estrategia de licencia particular. Habla con el [departamento legal de tu empresa](#qué-necesita-saber-el-equipo-legal-de-mi-empresa).
+
+Cuando creas un Nuevo proyecto en GitHub, te son brindadas opciones para elegir una licencia. Incluir cualquiera de las licencias enunciadas anteriormente, harán de tu proyecto de GitHub, un proyecto de código abierto. Si quisieras considerar otras opciones, revisa [choosealicense.com](https://choosealicense.com) en donde encontrarás licencias adecuadas para tu proyecto, incluso si el mismo [no es software](https://choosealicense.com/non-software/).
+
+## Y si quieres cambiar la licencia de tu proyecto
+
+La mayoría de los proyectos no necesitan cambios de licencias. Pero ocasionalmente las circunstancias cambian.
+
+Por ejemplo, a medida que tu proyecto crezca se añadirán dependencias y usuarios, o tu empresa modifica estrategias, cualquiera de estos escenarios requerirán diferentes licencias. También, si te negaste a establecer una licencia a tu proyecto desde el comienzo, agregar una licencia es efectivamente lo mismo que cambiar las licencias. Hay tres aspectos fundamentales que debes considerar al añadir o cambiar la licencia de tu proyecto:
+
+**Es complicado.** Determinar la compatibilidad y conformidad de la licencia con quienes son propietarios de sus derechos de autor puede volverse complicado y confuso muy rápidamente. Cambiar a una nueva pero a una licencia compatible para nuevos lanzamientos y colaboradores es diferente a cambiar la licencia de todos los colaboradores ya existentes. Involucre a su equipo legal frente a cualquier deseo de cambiar licencias. Incluso si tú tienes o puedes obtener permiso de los titulares de derechos de autor de su proyecto para un cambio de licencia, considera el impacto de los cambios en los colaboradores y usuarios de tu proyecto. Imagina al cambio de licencia como un "evento de gobierno" para tu proyecto que probablemente marchará sin contratiempos mediante la comunicación y consultas claras con las partes interesadas en el proyecto. ¡Más razones para elegir y utilizar una licencia adecuada para su proyecto desde el comienzo!
+
+**La licencia existente de su proyecto.** Si la licencia existente de su proyecto es compatible con la licencia a la que quieres cambiar, puedes simplemente empezar a usar la nueva licencia. Esto sucede debido a que si la licencia A es compatible con la licencia B, vas a estar cumpliendo con los términos de A mientras cumples con los términos de B (pero no necesariamente viceversa). Así que, si estás utilizando una licencia permisiva (por ejemplo, MIT), puedes cambiar a una licencia con más condiciones, siempre y cuando mantengas una copia de la licencia MIT y cualquier aviso de derechos de autos asociado (esto implicaría, continuar cumpliendo con las condiciones mínimas de la licencia MIT). Pero si tu licencia actual no es permisiva (por ejemplo, copyleft, o si no tienes licencia) y no eres el único propietario de los derechos de autor, no podrías simplemente cambiar la licencia del proyecto a MIT. Esencialmente, con una licencia permisiva del proyecto, en la cual los propietarios de derechos de autor han dado permiso por adelantado de cambiar licencias.
+
+**Los propietarios de derechos de autor de tu proyecto.** Si eres el único contribuyente a tu proyecto, entonces tú o tu empresa es el único titular de los derechos de autor del proyecto. Puedes añadir o cambiar a cualquier licencia que tú o tu empresa deseen. En otros casos, podría haber propietarios de derechos de autor de los cuales necesitarías realizar un acuerdo para poder cambiar las licencias. ¿Quiénes? Personas que hayan realizado commits a tu proyecto es una buena forma de comenzar. Pero en algunos casos los derechos de autor estarán en propiedad de los empleadores de dichas personas. En algunos casos las personas solo habrán hecho _la menor parte_ de las contribuciones, pero no hay una regla rápida y firme que establezca a partir de que cantidad de líneas de código están o no sujetos a derechos de autor dichos colaboradores. Para proyectos jóvenes y pequeños, puede ser factible lograr que todos los colaboradores acepten un cambio de licencia en una issue o un pull request. Para proyectos largos y de larga vida, tendrás que buscar a muchos contribuyentes e incluso sus herederos. Mozilla tardó años (2001-2006) para cambiar de licencia a Firefox, Thunderbird, y software relacionado.
+
+De manera alternativa, puedes tener colaboradores que estén de acuerdo por adelantado (mediante un acuerdo adicional de colaboradores – ver más abajo) con cambios de licencia bajo ciertas condiciones, más allá de los permitidos por tu licencia de código abierto existente. Esto cambia la complejidad de cambiar la licencia. Necesitarás más ayuda por parte de tus abogados, y aun deberás comunicarte claramente con las partes interesadas en su proyecto al ejecutar un cambio de licencia.
+
+## ¿Necesita mi proyecto un acuerdo adicional de colaboradores?
+
+Probablemente no. En la mayoría de los proyectos de código abierto, una licencia de código abierto sirve implícitamente de licencia tanto para el interior (colaboradores) como para el exterior (a otros colaboradores y usuarios). Si tu proyecto se encuentra en GitHub, los Términos de Servicio de GitHub la hacen "entrante=saliente" la [explícita por defecto](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+
+Un acuerdo adicional de colaboradores – a menudo llamado Acuerdo de Licencia de colaboradores (en inglés, CLA) – puede crear trabajo administrativo para mantenedores de proyecto. La cantidad de trabajo que suma un acuerdo depende del proyecto y su implementación. Un acuerdo simple puede requerir que los colaboradores confirmen, con un clic, que tienen los derechos necesarios para contribuir bajo la licencia de código abierto del proyecto. Un acuerdo más complicado, requerirá revisión legal y la aprobación de los empleadores del contribuyente.
+
+También, al añadir "papeleo" que algunos consideran innecesario, difícil de entender, o injusto (cuando el beneficiario del acuerdo obtiene más derechos que los colaboradores o el público a través de la licencia de código abierto del proyecto), un acuerdo adicional de colaboradores puede ser percibido poco amigable a la comunidad del proyecto.
+
+
+
+Algunas situaciones en las cuales deberías considerar un acuerdo adicional de colaboradores pueden ser:
+
+* Tus abogados quieren que todos los colaboradores acepten expresamente (_firma_, online o offline) los términos de contribución, quizás porque sienten que una licencia de código abierto no es suficiente (incluso cuando lo sea!). Si esta es la única preocupación, un acuerdo adicional de colaboradores que afirme la licencia de código abierto del proyecto, debería ser suficiente. El [Acuerdo Adicional de colaboradores Individual de jQuery](https://contribute.jquery.org/CLA/) es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un [Certificado de Origen del Desarrollador](https://GitHub.com/probot/dco) puede ser una alternativa aún más simple.
+
+* Tu proyecto usa una licencia de código abierto que no incluye una concesión de patentes explicita (como MIT), y necesitas una concesión de patentes por parte de todos los colaboradores, algunos de los cuales quizás trabajen para empresas con grandes cantidades de patentes que podrían utilizarse para dirigirse a usted o a otros contribuyentes y usuarios del proyecto. El [Acuerdo Adicional de colaboradores Individual de Apache](https://www.apache.org/licenses/icla.pdf) es un acuerdo adicional de colaboradores que posee una concesión de patentes reflejando el que se encuentra en Apache License 2.0.
+
+* Tu proyecto está bajo una licencia copyleft, pero también necesitas distribuir una versión propietaria del proyecto. Necesitaras que cada colaborador te asigne sus derechos de autor o te garantice a ti (pero no al público) una licencia permisiva. El [Acuerdo de colaboradores MongoDB](https://www.mongodb.com/legal/contributor-agreement) es un ejemplo de este tipo de acuerdo.
+
+* Crees que el proyecto necesitará cambiar la licencia durante su tiempo de vida y quieres que los colaboradores acepten por adelantado esos cambios.
+
+Si necesitas usar un acuerdo adicional de colaboradores para tu proyecto, considere el uso de una integración como [CLA assistant](https://GitHub.com/cla-assistant/cla-assistant) para minimizar la distracción de los contribuyentes.
+
+## ¿Qué necesita saber el equipo legal de mi empresa?
+
+Si vas a lanzar un proyecto de código abierto como un empleado de una empresa, primero, tu equipo legal debería saber que estás por lanzar un proyecto de código abierto.
+
+Para mejor, o peor, considera comentarles incluso en el caso en que sea un proyecto personal.
+
+Probablemente tengas un "acuerdo IP de empleado" con tu empresa que les da cierto tipo de control sobre tus proyectos, especialmente si ellos están relacionados con el negocio de la empresa o si utilizan recursos de la empresa para desarrollar el proyecto. Tu empresa _debería_ brindarte fácilmente permisos, y tal vez ya cuentes con ellos a través de un acuerdo de IP amigable hacia los empleados o mediante políticas empresariales. Si no es el caso, puedes negociar (por ejemplo, explicar que su proyecto posee objetivos profesionales de aprendizaje y desarrollo de la empresa para ti), o evitar trabajar en proyectos hasta que encuentres una mejor empresa.
+
+**Si estás trabajando en un proyecto de código abierto para tu empresa** entonces definitivamente debes hacerles saber. Tu equipo legal seguramente ya cuenta con políticas para esa licencia de código abierto (y puede que también un acuerdo adicional de colaboradores) para usar basado en los requisitos y pericia del negocio de la empresa para asegurar que tu proyecto cumple con la licencia de sus dependencias. De lo contrario, tanto tú como ellos, están de suerte! tu equipo legal debería estar ansioso por trabajar con usted para acordar estas cosas. Algunos aspectos a considerar:
+
+* **Material de terceros** ¿tiene tu proyecto dependencias creadas por otros o bien incluye o usa códigos ajenos? Esto comienza con la elección de una licencia que funcione con las licencias de código abierto de terceros (ver arriba). Si su proyecto modifica o distribuye código abierto de terceros, su equipo legal también querrá saber si cumple con otras condiciones de las licencias de código abierto de terceros, como la retención de avisos de derechos de autor. Si tu proyecto utiliza código de otros que no tienen una licencia de código abierto, probablemente tendrás que pedirle a los mantenedores que [agreguen una licencia de código abierto](https://choosealicense.com/no-license/#for-users), y si no puedes conseguir una, deja de usar su código en tu proyecto.
+
+* **Secretos comerciales:** Considera si hay algo en el proyecto que la empresa no quiere poner a disposición del público en general. Si es así, puedes hacer de código abierto al resto del proyecto, después de extraer el material que desea mantener privado.
+
+* **Patentes:** ¿Está tu empresa solicitando una patente, cuya liberación del código fuente del proyecto implique una [revelación pública](https://en.wikipedia.org/wiki/Public_disclosure)? Tristemente, puede que te pidan que esperes (o tal vez, la empresa volverá a considerar la sabiduría de la aplicación). Si estás esperando contribuciones a tu proyecto de los empleados de empresas con cantidades grandes de patentes, tu equipo legal puede que desee que utilices una licencia con una concesión de patente expresa de los contribuyentes (como Apache 2.0 o GPLv3), o un acuerdo adicional de colaboradores (ver más arriba).
+
+* **Marca comercial** Verifica que el nombre de tu proyecto [no entre en conflicto con alguna marca existente](../starting-a-project/#evitando-conflictos-con-los-nombres). Si utilizas marcas comerciales de tu empresa en el proyecto, comprueba que no genere ningún conflicto. [FOSSmarks](http://fossmarks.org/) es una guía práctica para la comprensión de las marcas en el contexto de los proyectos de código libre y abierto.
+
+* **Privacidad** ¿Recolecta tu proyecto datos de sus usuarios? ¿Recopila su proyecto datos en los servidores de la empresa sin el consentimiento de los usuarios? Tu equipo legal puede ayudarte a cumplir con las políticas de la empresa y las regulaciones externas.
+
+Si estás lanzando el primer proyecto de código abierto de tu empresa, lo anterior es más que suficiente para conseguirlo.
+
+A largo plazo, tu equipo legal puede hacer más para ayudar a la empresa a obtener su participación en código abierto y mantenerse a salvo:
+
+* **Políticas de contribución de empleados:** Considera la posibilidad de desarrollar una política corporativa que especifique cómo sus empleados contribuyen a proyectos de código abierto. Una política clara reducirá la confusión entre sus empleados y los ayudará a contribuir a proyectos de código abierto de la empresa, ya sea como parte de su trabajo o en su tiempo libre. Un buen ejemplo es Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+
+
+
+* **Qué liberar:** [¿(casi) todo?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si tu equipo legal entiende e invierte en la estrategia de código abierto de su empresa, serán más capaces de ayudar en lugar de dificultar tus esfuerzos.
+
+* **Conformidad:** Incluso si tu empresa no libera ningún proyecto de código abierto, utiliza otro software de código abierto. La [conciencia y el proceso](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) puede prevenir dolores de cabeza, retrasos del producto, y demandas.
+
+
+
+* **Patentes:** Es posible que su empresa desee unirse a la [Red de Invención Abierta](http://www.openinventionnetwork.com/), Un conjunto de patentes defensivas compartido para proteger el uso de los miembros de los principales proyectos de código abierto, o explorar otras [licencias de patentes alternativas](https://www.eff.org/document/hacking-patent-system-2016).
+
+* **Gobernancia:** Especialmente si tiene sentido mover un proyecto a una [entidad jurídica ajena a la empresa](../leadership-and-governance/#necesito-una-entidad-legal-para-apoyar-a-mi-proyecto).
diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md
new file mode 100644
index 00000000000..970b4030785
--- /dev/null
+++ b/_articles/it/metrics.md
@@ -0,0 +1,126 @@
+---
+lang: es
+title: Métricas de código abierto
+description: Tomar decisiones informadas para ayudar a tu proyecto de código abierto a prosperar mediante la medición y el seguimiento de su éxito.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## ¿Para qué medir algo?
+
+Los datos, usados de forma sabia, pueden ayudarte a tomar mejores decisiones.
+
+Con más información puedes:
+
+* Entender cómo los usuarios responden a una nueva característica
+* Determinar de dónde provienen nuevos usuarios
+* Identificar y decidir si conviene brindar soporte a una parte separada de funcionalidad
+* Cuantificar la popularidad de tu proyecto
+* Entender cómo es usado tu proyecto
+* Obtener dinero a través de publicidad, donaciones, entre otros
+
+Por ejemplo, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) descubrió que Google Analytics los ayuda a priorizar el trabajo
+
+> Homebrew es gratuito y lo trabajan por completo voluntarios con algo de tiempo libre. Como resultado, no tenemos los recursos para obtener estudios detallados de usuarios, y así determinar cómo diseñar características y priorizar nuestro trabajo actual. Análisis de usuarios anónimos nos permiten priorizar arreglos y características basadas en cómo, dónde y cuándo las personas utilizan Homebrew.
+
+La popularidad no lo es todo. Todos se involucran en el Código Abierto por diferentes razones. Si tu meta como encargado de mantener un proyecto es mostrar tu trabajo, mantener transparente el código, o simplemente divertirte, las métricas quizás no sean tan importantes.
+
+Si tu _estás_ interesado en entender tu proyecto a un nivel más profundo, debes leer formas de analizar la actividad del mismo.
+
+## Descubrimiento
+
+Antes de que alguien pueda usar o contribuir a tu proyecto, quizás necesiten saber que el mismo existe. Debes preguntarte: _¿Las personas pueden encontrar el proyecto?_
+
+
+
+Si tu proyecto está hosteado en GitHub, [puedes ver](https://help.github.com/articles/about-repository-graphs/#traffic) cuántas personas lo visitan, y de dónde vienen. En la página de tu proyecto haz click en "Graphs", y luego "Traffic". En esta página puedes ver:
+
+* **Total de vistas:** Informa la cantidad de veces que tu página fue vista
+
+* **Total de visitantes únicos:** Te dice la cantidad de personas que vieron tu proyecto
+
+* **Sitios de referencia:** Te dice de dónde vienen las visitas. Puede ayudar a detectar el público al cual apuntar, o para determinar si tu publicidad está dando resultado.
+
+* **Contenido popular:** Te informa sobre las partes del proyecto que la gente más visita.
+
+[GitHub stars](https://help.github.com/articles/about-stars/) puede brindarte una línea base para medir popularidad. No necesariamente tiene que ver con uso o cantidad de descargas, si no más bien según la cantidad de notoriedad de tu proyecto.
+
+Quizás también quieras [rastrear la forma que te descubren desde lugares específicos](https://opensource.com/business/16/6/pirate-metrics): por ejemplo, Google PageRank, tráfico que hace referencia a tu página web del proyecto, o referencias desde otros proyectos.
+
+## Uso
+
+Las personas hallan tu proyecto en ese lugar salvaje y loco llamado Internet. Lo mejor sería que, cuando vean tu proyecto, se sientan obligados o atraídos a hacer algo. La segunda pregunta que queremos hacer es: _¿Las personas están usando tu proyecto?_
+
+Si usas un administrador de paquetes, como npm o Rubygems.org para distribuir tu proyecto, quizás quieras rastrear las descargas del mismo
+
+Cada administrador de paquetes usa diferentes definiciones de "descarga", y las descargas no están necesariamente relacionadas con la instalación o el uso, pero provee una línea base para la comparación. Trata de usar [Libraries.io](https://libraries.io/) para rastrear el uso de estadísticas a través de algunos de los administradores de paquetes más populares.
+
+Si tu proyecto está en GitHub, navega nuevamente a "Traffic". Puedes usar [clone graph](https://github.com/blog/1873-clone-graphs) para ver cuántas veces tu proyecto ha sido clonado en un día determinado.
+
+
+
+Si el uso es bajo comparado con el número de personas descubriendo tu proyecto, debes considerar que estás enfrentando uno de dos problemas:
+
+* Tu proyecto no está atrayendo exitosamente a la audiencia, o
+* estás atrayendo a la audiencia incorrecta
+
+Por ejemplo, si tu proyecto figura en la página principal de Hacker New, muy probablmente vas a ver un salto en "Traffic", pero una tasa de conversión baja, porque estás alcanzando a todos en Hacker News. En cambio, si tu proyecto en Ruby está siendo publicitado en una conferencia de Ruby, muy probablmente verás una tasa de conversión mayor.
+
+Trata de deducir de dónde proviene tu audiencia, y pide feedback a otros para saber cuál de los dos problemas estás enfrentando.
+
+Una vez que sepas que las personas usan tu proyecto, quizás quieras probar determinar qué es lo que hacen con él. ¿Lo usan para proyectos de investigación o negocios? ¿Realizan "fork" al mismo y están agregando nuevas características?
+
+## Retener
+
+La gente está hallando tu proyecto y lo están usando. La siguiente pregunta que debes hacerte es: _¿Las personas están contribuyendo al proyecto?_
+
+Nunca es demasiado temprano para comenzar a pensar en los contribuyentes. Sin otras personas te arriesgas a enfrentar una situación donde tu proyecto es _popular_ (muchas personas lo usan) pero no _soportado_ (no hay tiempo suficiente para mantener el proyecto y afrontar la demanda).
+
+Retener también requiere un [flujo de nuevos contribuyentes](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), debido a que contribuyentes activos pueden, en algún momento, continuar hacia en otros proyectos.
+
+Ejemplos de métricas de comunidad que quieres rastrear incluyen:
+
+* **El total de commits por contribuyente, y el número de ellos:** Te informa cuántos contribuyentes tienes y quién es más o menos activo. En GitHub, pudes ver esto debajo de "Graphs" -> "Contributors". Actualmente esté gráfico solo cuenta los contribuyentes que han hecho algún commit a la rama por defecto del repositorio.
+
+
+
+* **Contribuyentes nuevos, casuales y repetidos** Te ayuda a rastrear si estás obteniendo nuevos contribuyentes, y si vuelven. (Los casuales son aquellos con un número bajo de commits, elige tu criterio para definir dicho número). Sin nuevos contribuyentes, la comunidad de tu proyecto puede permanecer estancada.
+
+* **Número de issues y pull requests abiertos:** Si estos números se hacen muy grandes necesitarás ayuda para revisar el código.
+
+* **Número de issues y pull requests que _han sido abiertos_:** Los issues abiertos significan que alguien se preocupa lo suficiente por tu proyecto para abrir un issue. Si ese número incremente con el tiempo sugiere que las personas están interesadas en tu proyecto.
+
+* **Tipos de contribución:** Por ejemplo commits, arreglar typos, solucionar bugs o comentando en un issue.
+
+
+
+## Actividad de mantenimiento
+
+Finalmente, quizás quieras cerrar el ciclo de asegurarte si los encargados de mantener tu proyecto pueden manejar el volumen de contribuciones que se vayan a recibir. La última pregunta que quieres hacerte es: _¿Estoy/Estamos listo/s para responder a la comunidad?_
+
+Encargados de mantenimiento que no respondan pueden volverse un cuello de botella en tu proyecto. Si alguien hace una contribución pero no recibe noticia del encargado de mantenimiento, esta persona puede sentirse desmotivada y por ende abandonar el proyecto.
+
+[Investigación de Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) sugiere que la sensibilidad y respuesta de los encargados de mantenimiento es un factor crítico a la hora de motivar nuevas contribuciones.
+
+Considera rastrear cúanto te lleva a ti, o otro encargado, responder a contribuciones, ya sea in issue o un pull request. Responder no requiere realizar ninguna acción, puede ser tan simple cómo decir: _"Graacias por tu contribución, lo revisaré dentro de esta semana."_
+
+También puedes medir el tiempo que te lleva el moverte entre etapas del proceso de contribución, como por ejemplo:
+
+* Tiempo promedio en que un issue permanece abierto
+* Si los issues quedan cerrados por pull requests
+* Si los stale issues se cierran
+* Tiempo promedio de merge de un pull request
+
+## Usa 📊 para aprender acerca de las personas
+
+Entender métricas te ayudará a construir un proyecto activo y fructífero. Aunque no rastrees cada métrica en un dashboard, usa un framework que te permita enfocarte en el tipo de comportamiento que ayudará a tu proyecto a prosperar.
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
new file mode 100644
index 00000000000..8810fc58b07
--- /dev/null
+++ b/_articles/it/starting-a-project.md
@@ -0,0 +1,363 @@
+---
+lang: es
+title: Comenzando un proyecto de Código Abierto
+description: Aprende más acerca del mundo del Código Abierto y prepárate a lanzar tu propio proyecto.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## El cómo y el por qué del Código Abierto
+
+¿Estás pensando cómo comenzar un proyecto de c&oacut;digo abierto? ¡Felicitaciones! El mundo aprecia tu contribución. Hablemos sobre lo que es un proyecto de código abierto y porqué la gente lo lleva adelante
+
+### ¿Qué significa "Código Abierto"?
+
+Cuando un proyecto es de código abierto, significa que **cualquier persona puede ver, modificar, usar o distribuir tu proyecto para cualquier fin.** Estos permisos están reforzados a través de [una licencia de código abierto](https://opensource.org/licenses).
+
+"Código Abierto" es poderoso debido a que reduce las dificultades de adopción, permitiendo que las ideas se esparzan rápidamente.
+
+Para entender cómo funciona, imagina a un amigo que organiza una comida, te invita, y llevas una torta.
+
+* Todos prueban la torta (_usarlo_)
+* ¡La torta es un éxito! Te piden la receta, la cuál tú das. (_estudiarlo/verlo_)
+* Un amigo, Pedro, es cocinero, y te sugiere colocar menos azúcar (_modificarlo_)
+* Otro amigo, Juan, te pide permiso para usarlo en una cena que tendrá la próxima semana (_distribuirlo_)
+
+Realicemos una comparación: un proceso de código cerrado sería ir a un restaurante y pedir una porción de torta. Para ello tendrías que pagar por la misma, y el restaurante muy probablemente no te dará su receta. Si decidieras copiar su torta y venderla bajo otro nombre, el restaurante podría recurrir a acciones legales en contra.
+
+### ¿Por qué las personas utilizan el "Código Abierto"?
+
+
+
+[Hay muchas razones](https://ben.balter.com/2015/11/23/why-open-source/) por las cuales una persona u organización querrían involucrarse en un proyecto de código abierto. Algunos ejemplos son:
+
+* **Colaboración:** Los proyectos de código abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, una plataforma para ejercicios de programación con más de 350 colaboradores.
+
+* **Adopción y remezcla:** Los proyectos de código abierto pueden ser usados por cualquiera para casi cualquier própósito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://sourcecode.cio.gov/), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
+
+Código abierto no es solamente software. Uno puede "abrir" cualquier cosa, desde conjuntos de datos, hasta libros. Mira esto [GitHub Explore](https://github.com/explore) para tener otros ejemplos.
+
+### ¿"Código Abierto" significa gratis?
+
+Una de las cosas que causa confusión es el que el código abierto no cuesta dinero, es decir, es gratuito. Sin embargo, es un subproducto del valor general del "Código abierto".
+
+Esto es debido a que [una licencia open source requiere](https://opensource.org/osd-annotated) que cualquiera pueda usar, modificar, y compartir sus proyectos para casi cualquier propósito, y los proyectos en sí mismos suelen ser gratuitos. Si el uso del proyecto cuesta dinero, cualquiera puede legalmente hacer una copia del mismo y usar la versión gratuita en su lugar.
+
+El resultado es que la mayor parte de los proyectos de este tipo son gratuitos, pero "gratuito" no forma parte de la definición del "Código Abierto". Hay formas de cobrar por estos proyectos en forma indirecta a través de licencias duales o funcionalidad limitada, y al mismo tiempo cumplir con la definición oficial del "Código Abierto".
+
+## ¿Debería lanzar mi propio proyecto de Código Abierto?
+
+La respuesta corta es "Sí", debido a que, sin importar lo que suceda, lanzar tu propio proyecto es una buena forma de aprender acerca de cómo funciona el código abierto.
+
+Si nunca has utilizado este concepto en el pasado, probablemente estés preocupado de lo que otras personas digan, o que no digan nada. Si esto es así, debes saber que no estás solo.
+
+El código abierto funciona como cualquier otra actividad creativa, ya sea escribir o pintar. Puede dar miedo de compartir algo con el mundo, pero la única forma de mejorar es practicar (aún si no tienes una audiencia).
+
+Si no estás convencido todavía, toma un momento para pensar acerca de cuáles serán tus objetivos.
+
+### Definiendo tus objetivos
+
+Los objetivos pueden ayudarte a detectar puntos en los que continuar trabajando, a qué decirle que no, y a dónde recurrir por ayuda. Comienza preguntándote, _¿Por qué estoy haciendo "código abierto" a mi proyecto?_
+
+No hay nunca una respuesta correcta a esta pregunta. Puedes tener múltiples objetivos para un solo proyecto, o diferentes proyectos con diferentes objetivos.
+
+Si tu único objetivo es mostrar al mundo tu trabajo, quizás no necesites ni quieras contribución, y quizás digas eso en el README. Por otra parte, si quieres ayuda, invertirás tiempo en clarificar la documentación y en hacer sentir a los recién llegados bienvenidos.
+
+
+
+A medida que tu proyecto crezca, tu comunidad podrá llegar a necesitar más que solamente el código. Es decir, necesitará que respondas a issues, que revises el código, entre otras tareas importantes en un proyecto de esta clase.
+
+El tiempo que dediques a tareas ajenas a codificar dependerá del tamaño y alcance de tus proyectos, deberías estar preparado, como encargado de mantenimiento, a afrontarlas por tu cuenta o encontrar a alguien que pueda ayudarte.
+
+**Si eres parte de una compañia que quiere "abrir" el código de un proyecto,** debes asegurarte que el mismo tiene recursos internos que necesitan mejorar. Necesitarás identificar al responsable de mantener el proyecto una vez lanzado, y definir cómo vas a compartir esas tareas con tu comunidad.
+
+Si necesitas un presupuesto dedicado o personal para la promoción, operación y mantenimiento del proyecto, empieza esas conversaciones de forma temprana.
+
+
+
+### Contribuyendo en otros proyectos.
+
+Si tu meta es aprender cómo contribuir con otros o entender cómo funciona el "código abierto", considera contribuir en proyectos existentes. Comienza con proyectos que ya has estado usando y que te gustan. Contribuir a un proyecto puede ser tan simple como arreglar "typos" o actualizar documentación.
+
+Si no sabés como comenzar a contribuir, mira esta [Guía sobre cómo contribuir](../how-to-contribute/).
+
+## Lanzando tu propio proyecto de Código Abierto
+
+No hay momento perfecto para abrir el código de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso, o después de varios años de ser un proyecto cerrado.
+
+Generalmente, puedes abrir el código de tu proyecto cuando te sientas cómodo de que otras personas vean y te aconsejen sobre tu trabajo.
+
+No importa en qué etapa decidas hacerlo, cada proyecto debe incluir la siguiente documentación.
+
+* [Licencia de Código Abierto](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)
+* [Pautas para contribuir](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Código de conducta](../code-of-conduct/)
+
+Como encargado de mantenimiento, estos componentes ayudarán a comunicar tus deseos, manejar tus contribuciones y proteger los derechos legales de cada uno (incluyéndote). Incrementan significativamente tus posibilidades de tener una experiencia positiva.
+
+Si tu proyecto está en GitHub, colocar estos archivos en tu directorio raíz con las recomendaciones de nombrado de los mismos, te ayudará a que GitHub los reconozca automáticamente y muestre a tus lectores.
+
+### Eligiendo una licencia
+
+Una licencia de Código Abierto garantiza que otros puedan usar, copiar, modificar y contribuir en tu proyecto sin problemas. Además ayuda a protegerte de situaciones legales complejas. **Debes elegir una licencia cuando inicias tu proyecto!**
+
+El trabajo legal no es divertido. La buena noticia es que puedes copiar y pegar una licencia existente en tu repositorio. Solo llevará un minuto proteger tu trabajo.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), y [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) son las licencias más populares, pero [hay otras opciones](https://choosealicense.com) para elegir.
+
+Cuando creas un nuevo proyecto en GitHub, te dan la opción de seleccionar una licencia. Incluir una licencia de Código Abierto hará tu proyecto efectivamente de Código Abierto.
+
+
+
+Si tienes otras preguntas acerca del aspecto legal al manejar proyectos de este tipo, [te tenemos cubierto](../legal/).
+
+### Escribiendo un README
+
+Los README hacen más que explicar cómo usar tu proyecto, también explican por qué importa el mismo, y qué pueden hacer los usuarios con él.
+
+Trata de que tu README responda a las siguientes preguntas:
+
+* ¿Qué hace el proyecto?
+* ¿Por qué es útil?
+* ¿Cómo se debe comenzar?
+* ¿Dónde puedo buscar más información? (si es que la necesito)
+
+Puedes usarlo para responder otras preguntas: cómo manejo las contribuciones, cuáles son las metas del proyecto, e información acerca de licencias y atribuciones. Si no quieres aceptar contribuciones, o tu proyecto no está listo para producción, lo escribes.
+
+
+
+Algunas veces las personas evitan escribir el README debido a que sienten que su proyecto está incompleto, o qué no quiere contribuciones. Ambas son muy buenas razones para escribir uno...
+
+Para más inspiración, trata de usar @18F's ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) o @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) para escribir un README.
+
+Cuando incluyes un archivo de este tipo en tu directorio raíz, GitHub automáticamente lo mostrará en la página principal del repositorio.
+
+### Escribiendo las pautas para contribuir
+
+Un archivo CONTRIBUTING le da información a la audiencia acerca de cómo participar en el proyecto, por ejemplo:
+
+* Cómo archivar un reporte de bug (trata de usar [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Cómo sugerir una nueva funcionalidad/característica.
+* Cómo establecer tu entorno y correr pruebas.
+
+Además de detalles técnicos, este archivo es una oportunidad para comunicar tus expectativas, como:
+
+* Los tipos de contribución que esperas
+* Tu visión del proyecto (La hoja de ruta)
+* Cómo deberían comunicarse (o cómo no) los contribuyentes contigo.
+
+Usando un tono cálido y amigable, y ofreciendo sugerencias específicas para contribuciones puede ayudar a los iniciados a sentirse bienvenidos y ansiosos de participar.
+
+Por ejemplo, [Active Admin](https://github.com/activeadmin/activeadmin/) comienza [su guía de contribuciones](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con:
+
+> Primero, muchas gracias por considerar contribuir a Active Admin. Son personas como ustedes las que la hacen una gran herramienta.
+
+En las primeras etapas del proyecto, tu archivo CONTRIBUTING puede ser simple. Siempre debes explicar cómo reportar bugs o issues, y cualquier requerimiento técnico (como tests) para hacer una contribución.
+
+Con el tiempo, quizás debas agregar otras "preguntas frecuentes" a tu archivo. Escribir esta información significa que menos personas te preguntarán nuevamente la misma pregunta.
+
+Para más información sobre este tema, puedes acceder a @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) o @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+
+Vincula tu CONTRIBUTING desde tu README, así más personas pueden verlo.Si tu [colocas el archivo en tu repositorio](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub automáticamente lo vinculará cuando un contribuyente cree un issue o abra un pull request.
+
+
+
+### Estableciendo un código de conducta.
+
+
+
+Finalmente, un código de conducta ayuda a establecer reglas base de comportamiento para los participantes de tus proyectos. Esto es muy deseable si estás lanzando un nuevo proyecto de código abierto para una compañía o comunidad. Un código de conducta facilita un comportamiento en comunidad sano y constructivo, reduciendo tu estrés como encargado de mantenimiento.
+
+Para más información, entra a [Guía del Código de Conducta](../code-of-conduct/).
+
+Además de comunicar _cómo_ esperas que se comporten los participantes, un código de conducta tiende a describir a quién se aplican las expectativas, cuando apliquen, y qué hacer si una violación a las mismas ocurre.
+
+Como muchas licencias de código abierto, existen estándares emergentes para códigos de conducta para que no debas escribir uno propio. El [Contributor Covenant](https://www.contributor-covenant.org/) es un código de conducta usado por [más de 40000 proyectos de código abierto](https://www.contributor-covenant.org/adopters), incluyendo Kubernetes, Rails, and Swift. Debes estar preparado para redefinir el tuyo cuando sea necesario.
+
+Copia el texto directamente en el archivo CODE_OF_CONDUCT dentro de tu repositorio, en el directorio raíz, y vincúlalo desde tu README.
+
+## Dando un nombre y una marca a tu proyecto
+
+La marca es más que elegir un nombre atractivo y un buen logo. Es acerca de cómo hablar de tu proyecto y llegar a la gente.
+
+### Eligiendo el nombre correcto
+
+Debes elegir un nombre sencillo de recordar y que en lo posible de una idea de lo que el proyecto hace. Ejemplos son:
+
+* [Sentry](https://github.com/getsentry/sentry) monitorea apps
+* [Thin](https://github.com/macournoyer/thin) es un server de Ruby
+
+Si estás construyendo sobre un proyecto ya existente, usar su nombre como prefijo suele clarificar lo que el mismo hace (ejemplo: [node-fetch](https://github.com/bitinn/node-fetch) trae `window.fetch` a Node.js).
+
+Considera claridad por sobre todo. Los chismes son divertidos,pero recuerda que algunas bromas pueden no ser traducidas otros idiomas o llevadas a otras culturas, con gente que posee diferentes experiencias a las tuyas. Algunos de tus potenciales usuarios pueden ser empleados de la compañía: no debes hacerlos sentir incómodos cuando tienen que explicar tu proyecto en el trabajo!
+
+### Evitando conflictos con los nombres
+
+Busca proyectos con el mismo nombre, o similar, especialmente si compartes el mismo ecosistema o idioma. Si tu nombre coincide con algún otro proyecto popular, puede confundir a las personas.
+
+Si quieres una página web, manejo de Twitter, u otros ítems que representen tu proyecto, asegúrate de que puedas asignar el nombre que quieras. En lo posible, [reserva tu nombre ahora](https://instantdomainsearch.com/) para estar tranquilo, aunque aún no lo vayas a usar.
+
+Tu nombre no debe infringir ninguna marca (trademark), de ser así la compañía puede pedirte que des de baja a tu proyecto, o puede tomar acciones legales en tu contra. No vale el riesgo.
+
+Puedes verificar [WIPO](http://www.wipo.int/branddb/en/) para verificar conflictos de este tipo. Si estás en una compañía, ésta es una de las cosas con las cual tu [equipo legal puede ayudar](../legal/).
+
+Finalmente, haz una búsqueda rápida en Google: ¿Las personas podrán encontrar rápidamente el nombre? ¿En los resultados de búsqueda aparece algo que no quieres que ellos vean?
+
+### Cómo escribir y codificar afecta tu marca
+
+Durante el ciclo de vida de tu proyecto, escribirás una serie grande de documentos: README, tutoriales, issues, etc..
+
+Ya sea documentación oficial como casual (un email), tu estilo de redacción debe ser parte de la marca de tu proyecto. Considera cómo será visto por tu audiencia y si es o no adecuado.
+
+
+
+Usando un lenguaje inclusivo, puede ir lejos haciendo que tus proyectos reciban de forma más cálida a los nuevos participantes. Mantén un lenguaje simple.
+
+Luego de cómo expresarte, tu estilo a la hora de codificar puede ser importante también. [Angular](https://github.com/johnpapa/angular-styleguide) y [jQuery](https://contribute.jquery.org/style-guide/js/) son ejemplos de proyectos con un riguroso trato en este sentido.
+
+No es necesario escribir una "guía de estilo" para tus proyectos cuando recién estás comenzando, y quizás hasta descubras que disfrutas al incorporar distintos estilos de codificación en tu proyecto. Pero deberías anticiparte y definir cómo tu redacción y estilo de codificación puede atraer o no a distintos tipos de personas. Define esto al comienzo.
+
+## Tu checklist a armar previamente al lanzamiento del proyecto
+
+Estás listo para iniciar tu propio proyecto de Código Abierto. Aquí dejamos un checklist que puede ayudar. ¡Una vez marcadas todas las casillas estás listo para continuar! [Clickea "publish"](https://help.github.com/articles/making-a-private-repository-public/).
+
+**Documentación**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**Code**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**Personas**
+
+Si eres un individuo:
+
+
+
+
+
+
+Si eres una compañía u organización:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## ¡Lo has hecho!
+
+Felicitaciones por abrir el código de tu primer proyecto! Sin importar el devenir, trabajar en público es un regalo a la comunidad. Con cada commit, comentario y pull request, estás creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer.
diff --git a/_data/locales/it.yml b/_data/locales/it.yml
new file mode 100644
index 00000000000..da7670f339d
--- /dev/null
+++ b/_data/locales/it.yml
@@ -0,0 +1,31 @@
+en:
+ locale_name: Italiano
+ nav:
+ about: Circa
+ contribute: Contribuire
+ index:
+ lead: Il software open source è realizzato da persone come voi. Scoprite come lanciare e far crescere il vostro progetto.
+ opensourcefriday: È venerdì! Investite qualche ora per contribuire al software che usate e che amate.
+ article:
+ table_of_contents: Indice dei contenuti
+ back_to_all_guides: Torna a tutte le guide
+ related_guides: Guide correlate
+ footer:
+ contribute:
+ heading: Contribuire
+ description: Vuoi dare un suggerimento? Questo contenuto è open source. Aiutateci a migliorarlo.
+ button: Contribuire
+ subscribe:
+ heading: Rimanere in contatto
+ description: Siate i primi a conoscere gli ultimi suggerimenti e risorse open source di GitHub.
+ label: Indirizzo e-mail
+ button: Abbonarsi
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] con [love] di [github] e [friends]"
+ # Label for code octicon
+ code_label: codice
+ # Label for love octicon
+ love_label: amore
+ # Label for the contributors link
+ friends_label: amici
From ac0ae3e1e8b427419e60fda3e2296ee0b0d4bcb6 Mon Sep 17 00:00:00 2001
From: Zack Koppert
Date: Wed, 27 Sep 2023 11:45:55 -0700
Subject: [PATCH 2/3] remove extra blank line
---
_articles/it/best-practices.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md
index 5d089e5f089..944cb0daf25 100644
--- a/_articles/it/best-practices.md
+++ b/_articles/it/best-practices.md
@@ -69,4 +69,3 @@ Ecco alcune regole che potresti voler considerare:
### Mantenere la comunicazione pubblica
Non dimenticare di documentare anche le tue interazioni. Ovunque tu possa, mantieni la comunicazione sul tuo progetto pubblica. Se qualcuno cerca di contattarti in privato per discutere una richiesta di funzionalità o un bisogno di supporto, indirizzalo educatamente verso un canale di comunicazione pubblico, come una mailing list o un issue tracker.
-
From d3a70eab65ab4587b2b7350655590e12e90ffabe Mon Sep 17 00:00:00 2001
From: Zack Koppert
Date: Wed, 27 Sep 2023 11:46:33 -0700
Subject: [PATCH 3/3] remove extra blank line
---
_articles/it/building-community.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md
index 6973fd583cc..c35f569fed5 100644
--- a/_articles/it/building-community.md
+++ b/_articles/it/building-community.md
@@ -36,7 +36,6 @@ Una buona documentazione invita le persone a interagire con il tuo progetto. Eve
* **Mantieni una mentalità aperta riguardo ai tipi di contributi che accetterai.** Molti collaboratori iniziano segnalando un errore o con una piccola correzione. Ci sono [molti modi per contribuire](../how-to-contribute/#cosa-significa-contribuire) a un progetto. Permetti alle persone di aiutare nel modo in cui vogliono aiutare.
* **Se c'è qualche contributo con cui non sei d'accordo,** ringrazialo per la sua idea e [spiega perché](../best-practices/#imparando-a-dire-no) non si adatta all'ambito del progetto, collegando la documentazione pertinente se ne hai.
-