diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md new file mode 100644 index 00000000000..aa14948d79b --- /dev/null +++ b/_articles/it/best-practices.md @@ -0,0 +1,274 @@ +--- +lang: es +title: Buone pratiche per i manutentori del codice. +description: Semplificandoti la vita come manutentore open source, dal processo di documentazione per ottenere il massimo dalla community. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Cosa significa essere un manutentore del codice? +Se il tuo compito è mantenere un progetto open source utilizzato da molte persone, probabilmente avrai notato che dedichi più tempo a rispondere ai problemi di programmazione. + +Nelle prime fasi di un progetto, trascorri del tempo a sperimentare nuove idee e prendere decisioni in base a ciò che ti piace. Man mano che il tuo progetto cresce in popolarità, ti ritroverai a lavorare sempre di più con i tuoi utenti e collaboratori. + +La manutenzione di un progetto richiede più del semplice codice. Questi compiti sono spesso trascurati, ma sono altrettanto importanti per un progetto in crescita. Abbiamo messo insieme alcune idee che ti semplificheranno la vita, dal processo di documentazione per ottenere il massimo dalla community. + +## Documentare i tuoi processi + +Prendere nota delle procedure è una delle migliori pratiche che puoi fare come manutentore del codice. + +Documentare non solo chiarisce il tuo pensiero, ma aiuta anche gli altri a capire ciò di cui hai bisogno o ti aspetti, senza nemmeno dover chiedere. + +Prendere nota dei processi rende facile dire di no quando la proposta di qualcuno non si adatta al tuo contesto. Così oltre a rendere più facile per altre persone unirsi e aiutare. Non sai mai chi potrebbe leggere o utilizzare il tuo progetto. + +Anche se non sei il tipo da scrivere paragrafi interi, avere i punti chiave scritti è meglio di 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 VISION. Se ci sono altri artefatti che potrebbero aiutare, come una mappa del progetto, rendi pubblici anche quelli. + +Avere una visione chiara e documentata ti mantiene concentrato e aiuta a evitare fraintendimenti sull'ambito da parte di altri collaboratori. + +Ad esempio, ha scoperto @lord che avere la visione di un progetto lo ha aiutato. per realizzare quali richieste dare priorità. Come manutentore del codice alle prime armi, si è lamentato di non essere fedele allo scopo del progetto una volta ricevuto. la tua prima richiesta di funzionalità da parte di [Slate](https://github.com/lord/slate). + + + +### Comunica le tue aspettative + +A volte può essere difficile precisare le regole in modo che altre persone possano contribuire. Potresti sentirti come un poliziotto o rovinare il divertimento per gli altri. + +Ben scritte e applicate, tuttavia, le buone regole autorizzano i manutentori del codice. Ti impediscono di essere trascinato a fare cose che non vuoi fare. + +La maggior parte delle persone che si imbattono nel tuo progetto non sanno nulla di te o delle tue circostanze. Potrebbero presumere che tu venga pagato per lavorarci, specialmente se è qualcosa che usano regolarmente e da cui dipendono. Forse a un certo punto dedichi molto tempo al tuo progetto, ma ora sei impegnato con un nuovo lavoro o un membro della famiglia. + +È perfettamente bene! Assicurati solo che le persone lo sappiano. + +Se il mantenimento del tuo progetto è part-time o solo volontariato, sii onesto su quanto tempo hai a disposizione. Questo non è lo stesso di quanto tempo pensi che il progetto richiederà, o quanto tempo gli altri vogliono che tu spenda. + +Qui ci sono alcune regole degne di nota: + +* In che modo un contributo viene esaminato e accettato (_Devono essere testati? Qualche modello da utilizzare per i problemi?_) +* I tipi di contributi che accetterai (_Vuoi aiuto solo con una parte del codice?_) +* Quando è opportuno continuare (_es. "Puoi aspettarti una risposta da un responsabile della manutenzione del codice entro i prossimi 7 giorni. Se non hai sentito nulla per allora, sentiti libero di eseguire il ping del thread." _) +* Quanto tempo dedichi al progetto (_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. + +### Mantieni la comunicazione pubblica + +Non dimenticare di documentare anche le tue interazioni. Ovunque tu possa, mantieni la comunicazione sul tuo progetto pubblica. Se qualcuno tenta di contattarti in privato per discutere di una richiesta di funzionalità o di un'esigenza di supporto, indirizzalo educatamente a un canale di comunicazione pubblico, come una mailing list o un tracker di problemi. + +Se incontri altri manutentori o prendi decisioni importanti in privato, documenta pubblicamente queste conversazioni, anche se stai solo pubblicando i tuoi appunti. + +In questo modo, chiunque si unisca alla tua comunità avrà una possibilità. Hai accesso alle stesse informazioni di qualcuno che è stato lì. per anni. + +## Imparare a dire di no + +Hai scritto cose. Idealmente, tutti dovrebbero leggere la tua documentazione, ma in realtà dovrai ricordare agli altri che questa conoscenza esiste. + +Avere tutto scritto, tuttavia, aiuta a spersonalizzare le situazioni in cui è necessario far rispettare le proprie regole. + +Dire di no non è divertente, ma _"Il tuo contributo non corrisponde ai criteri di questo progetto"_ sembra meno personale di _"Non mi piace il tuo contributo"_. + +Dire di no si applica a molte situazioni che incontrerai come manutentore del codice: richieste di funzionalità che non rientrano nell'ambito, qualcuno che fa deragliare una discussione, facendo del lavoro non necessario per altri. + +### Mantieni la conversazione amichevole + +Uno dei posti più importanti in cui ti eserciterai a dire di no è nel tuo problema e nella coda delle richieste pull. In qualità di project manager, riceverai inevitabilmente suggerimenti che non vorrai accettare. + +Forse il contributo cambia la portata del tuo progetto o non corrisponde alla tua visione. Forse l'idea è buona, ma l'implementazione è pessima. + +Indipendentemente dal motivo, i contributi che non soddisfano gli standard del tuo progetto possono essere gestiti con tatto. + +Se ricevi un contributo che non vuoi accettare, la tua prima reazione potrebbe essere ignorarlo o fingere di non averlo visto. Ciò potrebbe ferire i sentimenti dell'altra persona e persino scoraggiare altri potenziali contributori nella tua comunità. + + + +Non lasciare un contributo indesiderato aperto perchè ti senti in colpa o vuoi essere gentile. Nel tempo, i tuoi problemi senza risposta e le tue PR andranno bene. Renderà il lavoro sul tuo progetto molto più stressante e intimidatorio. + +È meglio chiudere immediatamente i contributi che sai di non voler accettare. Se il tuo progetto soffre già di un grande arretrato o di un elenco di funzionalità da implementare, @steveklabnik ha suggerimenti su [come scegliere i problemi in modo efficiente](https://words.steveklabnik.com/how-to-be-an-open-source -giardiniere). + +In secondo luogo, ignorare i contributi invia un segnale negativo alla tua comunità. Contribuire a un progetto può intimidire, soprattutto se è la prima volta di qualcuno. Anche se non accetti il ​​loro contributo, riconosci la persona dietro e ringraziala per il suo interesse. È un grande complimento! + +Se non vuoi accettare un contributo: + +* **Ringraziali** per il loro contributo. +* **Dì loro perché. non rientra** nell'ambito del progetto e offre chiari suggerimenti per il miglioramento, se possibile. lo so gentile, ma fermo. +* **Condividi informazioni rilevanti**, se ce l'hai. Se noti richieste ripetute per cose che non vuoi accettare, aggiungile alla tua documentazione per evitare di spiegare sempre la stessa cosa. +* **Chiudi la richiesta** + +non dovresti aver bisogno di più di 1-2 frasi per rispondere. Ad esempio, quando un utente di [celery](https://github.com/celery/celery/) segnalato un errore relativo a Windows, @berkerpeksag [risposto insieme a](https://github.com/celery/celery/issues/3383): + +[celery screenshot](/assets/images/best-practices/celery.png) + +Se hai il terrore di dire di no, non sentirti solo. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/): + + +> Ho parlato con i manutentori del codice di molti diversi progetti open source, Mesos, Kubernetes, Chromium, e sono tutti d'accordo sul fatto che una delle parti più difficili dell'essere un manutentore è il codice è dire "No" alle patch che non si utilizzano volere. + +Non sentirti in colpa per non voler accettare il contributo di qualcuno. La prima regola dell'open source, [secondo](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No, è temporaneo; sì, è per sempre."_ Mentre l'empatia per l'entusiasmo di un'altra persona è una buona cosa, rifiutare un contributo non equivale a rifiutare la persona dietro di esso . + +In definitiva, se un contributo non è abbastanza buono, non sei tenuto ad accettarlo. lo so Sii amichevole e reattivo quando le persone contribuiscono al tuo progetto, ma accetta solo i cambiamenti che pensi davvero miglioreranno il tuo progetto. Più spesso ti eserciti a dire di no, più facile diventa. È una promessa. + +### Lo so proattivi + +Per ridurre il volume dei contributi indesiderati, in primo luogo, spiega il processo del tuo progetto per inviare e accettare contributi nella tua guida ai contributi. + +Se ricevi troppi contributi di bassa qualità, chiedi ai contributori di fare un po' di lavoro in anticipo, ad esempio: + +* Compila un modello o una lista di controllo per problemi o PR +* Aprire un problema prima di inviare un PR + +Se non seguono le tue regole, chiudi immediatamente il problema e indirizzalo alla tua documentazione. + +Sebbene all'inizio questo approccio possa sembrare scoraggiante, essere proattivi è in realtà positivo per entrambe le parti. Riduce la possibilità che qualcuno metta molte ore di lavoro sprecate in una richiesta pull che non accetterai. E semplifica la gestione del carico di lavoro. + + + +A volte, quando dici di no, il tuo potenziale collaboratore potrebbe essere sconvolto o critico nei confronti della tua decisione. Se il loro comportamento diventa ostile, [prendere provvedimenti per disinnescare la situazione](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) o addirittura rimuoverli dalla tua comunità, se lo sono non disposti a collaborare in modo costruttivo. + +### Abbraccia il tutoraggio + +Forse qualcuno nella tua comunità invia regolarmente contributi che non soddisfano gli standard del tuo progetto. Può essere frustrante per entrambe le parti passare ripetutamente attraverso il processo di rifiuto. + +Se vedi che qualcuno lo è Se sei entusiasta del tuo progetto, ma hai bisogno di un po' di pratica, sii paziente. Spiega chiaramente in ogni situazione perchè. i tuoi contributi non soddisfano le aspettative del progetto. Prova ad assegnargli un compito più semplice o meno ambiguo, ad esempio un problema contrassegnato con _"buona prima edizione",_ , per riscaldarli. Se hai tempo, prendi in considerazione l'idea di fare da mentore attraverso il tuo primo contributo o trova qualcun altro nella tua comunità che lo sia. disposto a guidarli. + +## Sfruttare la comunità + +Non devi fare tutto da solo. La tua community di progetti esiste per una ragione! Anche se non hai ancora una comunità attiva di contributori, se hai molti utenti, lavoraci sopra. + +### Condividi il carico di lavoro + +Se stai cercando altri a cui unirsi, inizia chiedendo in giro. + +Quando vedi nuovi contributori che fanno contributi ripetuti, dovresti riconoscere il loro lavoro offrendo loro maggiori responsabilità. Documenta come gli altri possono ottenere ruoli di leadership, se lo desiderano. + +Incoraggiare gli altri a [condividere la proprietà del progetto](../building-community/#share-ownership-of-your-project) può ridurre notevolmente il carico di lavoro, come ha scoperto @lmccart. nel tuo progetto, [p5.js](https://github.com/processing/p5.js). + + + +Se hai bisogno di allontanarti dal tuo progetto, temporaneamente o permanentemente, non c'è vergogna nel chiedere a qualcun altro di subentrare per te. + +Se altre persone sono entusiaste della direzione del progetto, dai loro il permesso di impegnarsi o affidare formalmente il controllo a qualcun altro. Se qualcuno ha fatto un fork del tuo progetto e lo è. mantenendo attivamente da qualche altra parte, considera di collegare il fork dal tuo progetto originale. È fantastico che così tante persone vogliano che il tuo progetto cresca! + +@progrium [ha scoperto che](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenta la tua visione del progetto, [Dokku](https://github.com/dokku/dokku), aiutato Ha incoraggiato quegli obiettivi a durare, anche dopo che se n'era andato. del progetto: + +> ho scritto Ho fornito una pagina wiki che descrive cosa volevo e perchè. lo volevo. Per qualche motivo sono rimasto sorpreso! Quindi i manutentori hanno iniziato a spostare il progetto in quella direzione! È successo? esattamente come lo faresti? Non sempre. Ma ancora si avvicinò Ha trasformato il progetto in ciò che voleva. + +### Consenti ad altri di creare le soluzioni di cui hanno bisogno + +Se un potenziale collaboratore ha un'opinione diversa su ciò che il tuo progetto dovrebbe fare, potrebbe essere necessario incoraggiarlo gentilmente a lavorare sul proprio fork. + +Non è necessario eseguire il fork di un progetto. essere una brutta cosa. Essere in grado di copiare e modificare i progetti è una delle cose migliori dell'essere open source. Incoraggiare i membri della tua comunità a lavorare sul proprio fork può fornire lo sbocco creativo di cui hanno bisogno, senza entrare in conflitto con la visione del tuo progetto. + + + +Lo stesso vale per un utente che desidera davvero una soluzione che semplicemente non ha lo scopo di creare. L'offerta di API e hook personalizzabili può aiutare gli altri a soddisfare le proprie esigenze, senza dover modificare direttamente la fonte. +@orta [trovato che](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) ha preso i plugin incoraggianti per CocoaPods ad "alcune delle idee più interessanti": + +> È quasi inevitabile che una volta che un progetto diventa grande, i manutentori debbano essere molto più prudenti su come introdurre nuovo codice. Diventi bravo a dire "no", ma molte persone hanno bisogni legittimi. Pertanto, finisci per trasformare il tuo strumento in una piattaforma. + +## Forza i robot + +Così Proprio come ci sono compiti in cui altre persone possono aiutarti, ci sono anche compiti che nessun essere umano dovrebbe svolgere. I robot sono tuoi amici. usali per semplificarti la vita come manutentore del codice. + +### Richiedi test e altri controlli per migliorare la qualità del tuo codice + +Uno dei modi più importanti per automatizzare il tuo progetto è testare. + +I test aiutano i contribuenti a sentirsi sicuri che non romperanno nulla. Consentono inoltre di rivedere e accettare rapidamente i contributi. Più sei ricettivo, più il tuo partner può essere impegnato. sii la tua comunità + +Imposta test automatici da eseguire su tutti i contributi in entrata e assicurati che possano essere eseguiti localmente dai contributori. Richiede che tutti i contributi di codice siano sottoposti a test prima che possano essere inviati. aiuterà stabilire uno standard minimo di qualità per tutte le applicazioni. +[Required Status Checks](https://help.github.com/articles/about-required-status-checks/) su GitHub può aiutare a garantire che nessuna modifica venga unita senza prima passare attraverso il test. + +Se aggiungi dei test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTING. + + + +### Utilizza gli strumenti per automatizzare le attività di manutenzione di base + +La buona notizia sul mantenimento di un progetto popolare è che altri manutentori hanno probabilmente affrontato problemi simili e hanno creato una soluzione per esso. + +Sono disponibili [varie strumenti](https://github.com/showcases/tools-for-open-source) per automatizzare alcuni aspetti del lavoro di manutenzione. Qualche esempio: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatizza i tuoi rilasci +* [mention-bot](https://github.com/facebook/mention-bot) cita possibili revisori per il rull requests +* [Danger](https://github.com/danger/danger) aiuta ad automatizzare la revisione del codice + +Per segnalazioni di bug e altri contributi comuni, GitHub ha [Issue and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), che puoi creare per velocizzare la comunicazione che ricevi. Possono anche configurare [filtri e-mail](https://github.com/blog/2203-email-updates-about-your-own-activity) per gestire le notifiche e-mail. + +Se vuoi diventare un po' più avanzato, le guide di stile possono standardizzare i contributi del progetto e renderli più facili da rivedere e accettare. + +Tuttavia, se i tuoi standard sono troppo complicati, possono aumentare le barriere al contributo. Assicurati di aggiungere solo regole per semplificare la vita di tutti. + +Se non sei sicuro di cosa strumenti da utilizzare, guarda cosa stanno facendo altri progetti popolari, specialmente quelli nel tuo ecosistema. Ad esempio, cosa Che aspetto ha il processo di contribuzione per altri moduli Node? Anche l'uso di strumenti e approcci simili farà il trucco. Rendi il tuo processo più familiare ai tuoi contribuenti target. + +## È ok pausa + +Il lavoro open source una volta ti ha portato gioia. Forse ora lo è. iniziando a farti sentire evitante o in colpa. + +Forse ti senti sopraffatto o con un crescente senso di terrore quando pensi ai tuoi progetti. E nel frattempo, i problemi e le richieste pull si stanno accumulando. + +Il burnout è un problema reale e pervasivo nel lavoro open source, specialmente tra i manutentori. In qualità di manutentore, la tua felicità è un requisito non negoziabile per la sopravvivenza di qualsiasi progetto open source. + +Anche se dovrebbe essere dato per scontato, prenditi una pausa! Non dovresti aspettare di sentirti esausto per prenderti una vacanza. @brettcannon, uno sviluppatore Python, ha deciso di farlo Ho preso [un mese di vacanza] (http://www.snarky.ca/why-i-took- October-off-from-oss-volunteering) dopo 14 anni di volontariato OSS. + +Proprio come qualsiasi altro tipo di lavoro, fare delle pause regolari ti terrà sulle spine. fresca, felice ed entusiasta del tuo lavoro. + + + +A volte può essere difficile prendersi una pausa dal lavoro open source quando senti che il mondo intero ha bisogno di te. Le persone potrebbero anche provare a farti sentire in colpa per esserti allontanato. + +Fai del tuo meglio per trovare supporto per i tuoi utenti e la community mentre sei lontano da un progetto. Se non riesci a trovare il supporto di cui hai bisogno, fai comunque una pausa. Assicurati di comunicare quando non sei disponibile in modo che le persone non siano confuse dalla tua mancanza di reattività. + +Le pause si applicano anche a qualcosa di più delle semplici vacanze. Se non vuoi lavorare open source nei fine settimana o durante l'orario di lavoro, comunica queste decisioni ad altri, in modo che sappiano che non ti daranno fastidio. + +## Prenditi cura prima di te! + +Mantenere un progetto popolare richiede competenze diverse rispetto alle prime fasi di crescita, ma non è meno gratificante. Come manutentore, eserciterai la leadership e le abilità personali a un livello che poche persone possono sperimentare. Anche se non è sempre facile da gestire, stabilire confini chiari e prendere solo ciò che ti fa sentire a tuo agio aiuterà. mantieniti felice, aggiornato e produttivo. diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md new file mode 100644 index 00000000000..dfde0450769 --- /dev/null +++ b/_articles/it/building-community.md @@ -0,0 +1,278 @@ +--- +lang: es +title: Construyendo Comunidades de Bienvenida +description: Construyendo una comunidad que anime a al gente a usar, contribuir y educar con su proyecto +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Configurando tu proyecto para el éxito + +Acabas de lanzar tu proyecto, estás pasando la voz, y la gente lo está siguiendo. ¡Genial! Ahora, ¿cómo haces que se queden? + +Una comunidad de bienvenida es una inversión a futuro a tu proyecto y a tu reputación. Si tu proyecto está recién comenzando a ver sus primeras contribuciones, comienza por dar a los primeros colaboradores una experiencia positiva, y facilítales continuar regresando. + +### Haz que la gente se sienta bienvenida + +Una manera de pensar acerca de la comunidad del proyecto es a través de lo que @MikeMcQuaid llama [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +A medida que construyes tu comunidad, considera cómo alguien que se encuentra en la parte superior del embudo (un usuario potencial) puede teóricamente hacer su camino hacia abajo (un mantenedor activo). Tu objetivo es reducir la fricción en cada etapa de la experiencia del colaborador. Cuando las personas obtienen victorias fáciles, se sentirán incentivadas a hacer más. + +Comienza con tu documentación: + +* **Hazlo sencillo para quienes tienen que utilizar el proyecto.** [Un documento README amigable](../starting-a-project/#escribiendo-un-readme) y códigos de ejemplo claros harán más fácil el comienzo para cualquiera que aterrice en tu proyecto. +* **Explica claramente cómo contribuir**, utilizando [un archivo CONTRIBUTING](../starting-a-project/#escribiendo-las-pautas-para-contribuir) y manteniendo tus problemas al día. + +Una buena documentación invita a las personas a interactuar con tu proyecto. Eventualmente, alguien abrirá un problema o un pull request. + +* **¡Cuando alguien nuevo aterrice en tu proyecto, agradécele por su interés!** Es suficiente una sola experiencia negativa para que alguien no quiera regresar. +* **Compórtate de manera sensible.** Si no respondes a sus problemas por un mes, lo más probable es que ya se hayan olvidado de tu proyecto. +* **Tener la mente abierta acerca de los tipos de contribuciones que aceptará.** Muchos colaboradores comienzan reportando un error o con un arreglo pequeño. Hay [muchas maneras de contribuir](../how-to-contribute/#qué-significa-contribuir) con un proyecto. Permite que las personas ayuden de la manera que ellos quieran ayudar. +* **Si existe alguna contribución con la que estás en desacuerdo,** agradécele por su idea y [explícale porqué](../best-practices/#aprendiendo-a-decir-no) no encaja en la incumbencia del proyecto, enlazando con documentación relevante si la tienes. + + + +La mayoría de los colaboradores con el código 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 más sencillo para ellos contribuir. + +Animar a otros colaboradores es también invertir en tí mismo . Cuando brinda poder a sus más grandes seguidores paraa continuar con el trabajo que los mantiene entusiasmados, hay menos presión que si lo hicieras tu mismo. + +### Documenta todo + + + +Cuando comienzas un proyecto, mantener tu trabajo en privado puede sentirse natural. Pero los proyectos de código abierto avanzan mucho más cuando procesas tu documento en público. + +Cuando escribes las cosas, más personas pueden participar en cada paso del camino. Puedes necesitar ayuda o algo que todavía no sabes que necesitas. + +Escribir las cosas significa mucho más que documentación técnica. Cada vez que sientas la necesidad de escribir algo o de discutir tu proyecto de manera privada, pregúntate si puedes hacerlo públicamente. + +Mantente transparente acerca de la hoja de ruta de tu proyecto, los tipos de contribuciones que estás buscando, cómo se revisa el trabajo de quienes contribuyan o porqué tomas determinadas decisiones. + +Si ves que varios usuarios están trabajando en el mismo problema, documenta sus respuestas en el README. + +Para las reuniones, considera publicar tus notas o carteles en un asunto relevante. La retroalimentación que obtendrás de este nivel de transparencia te sorprenderá + +Documentar todo también se aplica al trabajo que tu haces. Si estás trabajando en una actualización sustancial de tu proyecto, ponlo en un pull request y márcalo como trabajo en proceso (WIP, work in progress por sus siglas en inglés). De esa manera, otras personas se pueden sentir involucradas en el proceso desde temprano + +### Compórtate de manera sensible + +A medida que [promocionas tu proyecto](../finding-users),las personas te harán llegar sus comentarios. Pueden tener preguntas acerca de cómo funcionan las cosas, o necesitar ayuda para comenzar. + +Trata de responder cuando álguien presenta un problema, envía un pull request o realiza una pregunta acerca de tu proyecto. Cuando respondes rápidamente, logras que las personas se sientan parte del diálogo, y estarán más entusiasmadas de participar. + +Incluso si no puedes revisar su solicitud inmediatamente, con solo agradecer su temprana ayuda incrementará su compromiso. Así es como @tdreyno respondió a un pull request en [Middleman](https://github.com/middleman/middleman/pull/1466): + +![middleman pull request](/assets/images/building-community/middleman_pr.png) + +Un [estudio de Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) encontró que los colaboradores que reciben una revisión de su código dentro de las 48 horas tienen una significativa mayor tasa de retornar y de repetir alguna contribución. + +Las conversaciones acerca de tu proyecto pueden también ocurrir en otros lugares a lo largo de la internet, como en Stack Overflow, Twitter o reddit. Puedes configurar tus notificaciones en cualquiera de esos tres lugares de manera de ser alertado cuando álguien mencione tu proyecto. + +### Brinda a tu comunidad un lugar para congregarse + +Existen dos razones para brindar a tu comunidad un lugar para congregarse. + +La primera razón es para ellos. Ayuda a las personas a conocerse. Las personas con intereses comunes querrán inevitablemente un lugar para hablar de ello. Y cuando la comunicación es pública y accesible, cualquiera puede leer los archivos pasados para ponerse al día y participar. + +La segunda razón es para tí. Si no brindas a las personas un lugar público para conversar acerca de tu proyecto, probablemente te contactarán directamente. Al comienzo puede no parecer demasiado responder a mensajes privados "sólo por esta vez". Pero con el tiempo, especialmente si tu proyecto se hace conocido, te sentirás agotado. Evita la tentación de comunicarte con las personas acerca de tu proyecto en privado. En su lugar, dirígelos al canal público designado. + +La comunicación pública puede ser tan simple como dirigir a las personas a abrir un tema en lugar de enviarle un correo electrónico a usted directamente o comentar en su blog. Podrías incluso configurar una lista de correos electrónicos, o crear una cuenta en Twitter, Slack o un canal IRC para que las personas puedan comentar sobre tu proyecto. ¡O prueba todo lo anterior! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) tiene tiempo reservado de las horas de oficina para ayudar a los miembros de la comunidad cada dos semanas : + +> Kops también tiene tiempo reservado cada dos semanas para ofrecer ayuda y guía a la comunidad. Los mantenedores de Kops han acordado reservar tiempo dedicado específicamente a trabajar con los recién llegados, ayudando con PRs y discutiendo nuevas características. + +Las excepciones notables a la comunicación pública son: 1) cuestiones de seguridad y 2) infracciones sensibles al código de conducta. Siempre deberías encontrar la manera para que las personas reporten estos aspectos de manera privada. Si no quieres utilizar tu correo electrónico privado, configura una cuenta de correo electrónico dedicada. + +## Haciendo crecer tu comunidad + +Las comunidades son extremadamente poderosas. Ese poder puede ser una bendición o una maldición, dependiendo de cómo lo maneje. A medida que la comunidad de tu proyecto crece, existen maneras para ayudar a que se convierta en una fuerza de construcción, no de destrucción. + +### No toleres a los malos actores + +Cualquier proyecto popular inevitablemente atraerá a personas que perjudican a tu comunidad, en lugar de ayudarla. Pueden comenzar discusiones innecesarias, discutir sobre rasgos triviales o burlarse de otros. + +Haz todo lo posible para adoptar una política de tolerancia cero hacia este tipo de personas. Si no se controla, las personas negativas harán que otras personas de tu comunidad se sientan incómodas. Incluso pueden irse. + + + +Los debates regulares sobre aspectos triviales de tu proyecto distrae a otros, incluyéndote también a tí, de enfocarte en tareas importantes. Las nuevas personas que llegan a tu proyecto pueden ver estas conversaciones y pueden o no querer participar. + +Cuando ves que ocurre algún comportamiento negativo, haz la observación correspondiente de manera pública. Explícale, en un tono amable, porqué dicho comportamiento no es aceptable. Si el problema persiste, puedes necesitar [solicitarle que se retire](../code-of-conduct/#aplicando-tu-código-de-conducta). Tu [código de conducta](../code-of-conduct/) puede ser una guía constructiva para estas conversaciones. + +### Reúnete con los colaboradores donde ellos están + +La buena documentación solo se vuelve importante a medida que tu comunidad crece. Los colaboradores casuales, quienes no estarían familiarizados con tu proyecto de otra manera, leen tu documentación para entender rápidamente el contexto de lo que necesitas. + +En tu archivo CONTRIBUTING, indica de manera explícita a los nuevos colaboradores cómo pueden comenzar. Tal vez quieras dedicar incluso una sección para tal propósito. [Django](https://github.com/django/django), por ejemplo, tiene una página especial para dar la bienvenida a los nuevos colaboradores. + +![django new contributors page](/assets/images/building-community/django_new_contributors.png) + +En tu cola de asuntos, etiqueta errores que son convenientes para diferentes tipos de colaboradores: por ejemplo, [_"solo principiantes"_](https://kentcdodds.com/blog/first-timers-only), "conveniente para quienes resuelven su primer bug", o "documentación". [Estas etiquetas](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) hacen que sea más fácil buscar problemas a resolver para alguien nuevo en el proyecto y así poder comenzar. + +Finalmente, utiliza tu documentación para hacer que las personas se sientan bienvenidas en cada etapa del camino. + +Nunca vas a interactuar con la mayoría de las personas que se acercan a tu proyecto. Puede haber colaboradores que no recibiste porque álguien se sintió intimidado o no supo cómo comenzar. Incluso algunas palabras amables pueden evitar que esas personas abandonen tu proyecto por verse frustradas + +Por ejemplo, así es como [Rubinius](https://github.com/rubinius/rubinius/) comienza su [guía de contribuciones](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):/ + +> Queremos comenzar agradeciendo por utilizar Rubinius. Este proyecto es un trabajo de amor, y apreciamos a todos los usuarios que detectan errores, hacen mejoras al rendimiento, y ayudan con su documentación. Cada contribución es significativa, así que gracias por participar. Dicho esto, aquí dejamos algunas pautas que pedimos que sigan para que podamos abordar con éxito su problema. + +### Comparte la propiedad de tu proyecto + + + +Las personas se entusiasman por contribuir con proyectos cuando perciben un sentido de pertenencia. Eso no significa que tengas que cambiar la visión de tu proyecto o aceptar contribuciones que no quieres. Pero cuanto más crédito les des a los otros, más se quedarán. + +Observa si puedes encontrar maneras de compartir la propiedad de tu comunidad tanto como te sea posible. Aquí hay algunas ideas: + +* **Evita corregir errores sencillos (no críticos).** En su lugar, utilizalos como oportunidades para reclutar nuevos colaboradores, o mentorear a alguien que quiere contribuir. Puede parecer antinatural al principio, pero tu inversión se verá compensada en el tiempo. Por ejemplo, @michaeljoseph le pidió a un colaborador que enviara un pull request de un problema detallado a continuación [Cookiecutter](https://github.com/audreyr/cookiecutter) en lugar de arreglarlo él mismo. + +![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Inicia un archivo de COLABORADORES o AUTORES en tu proyecto** que liste a todos los que colaboraron con tu proyecto, como lo hace [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Si tienes una comunidad considerable, **envía un boletín o escribe un post en un blog** agradeciendo a los colaboradores. Rust's [This Week in Rust](https://this-week-in-rust.org/) y Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) son dos buenos ejemplos. + +* **Da a cada colaborador permiso para hacer commit.** @felixge encontró con esto que las personas [se entusiasmaran por pulir sus parches](https://felixge.de/2013/03/11/the-pull-request-hack.html), e incluso encontró nuevas personas para mantener proyectos en los que no había trabajado hace tiempo. + + +* Si tu proyecto está alojado en GitHub, **mueve tu proyecto desde tu cuenta personal hacia una [Organización](https://help.github.com/articles/creating-a-new-organization-account/)** y agrega al menos un administrador de respaldo. Las Organizaciones hacen que sea más fácil trabajar en proyectos con colaboradores externos. + +La realidad es que [la mayoría de los proyectos solo tienen](https://peerj.com/preprints/1233/) una o dos personas que lo mantengan y que hacen la mayoría del trabajo. Mientras más grande sea tu proyecto, y mientras más grande sea tu comunidad, más fácil es encontrar ayuda. + +Aunque no siempre encuentres quien responda tu pedido, poner una señal por fuera incrementa las probabilidades de que otras personas se presenten. Y mientras más temprano comiences, más pronto las personas podrán ayudar. + + + +## Resolviendo conflictos + +En las primeras etapas de tu proyecto, es bastante fácil tomar decisiones importantes. Cuando quieres hacer algo, simplemente lo haces. + +A medida que tu proyecto se hace más conocido, más personas tendrán interés en las decisiones que tomes. Incluso si no tienes una gran comunidad de colaboradores, si tu proyecto tiene muchos usuarios, encontrarás personas que pesan en las decisiones o plantean cuestiones propias. + +En su mayor parte, si has cultivado una comunidad amistosa y que se maneja con respeto y has documentado tu proceso de manera abierta, tu propia comunidad debería tener la habilidad para encontrar una solución. Pero algunas veces te encontrarás con problemas un poco más difíciles de abordar. + +### Fijando la vara para la amabilidad + +Cuando tu comunidad se encuentre lidiando con una cuestión difícil, los ánimos pueden subir. Las personas pueden enojarse o verse frustradas y tomar las críticas como algo personal, incluso provenientes de tí. + +Tu trabajo como encargado es evitar que estas situaciones escalen. Incluso si tienes una fuerte opinión sobre un tema, trata de mantener una posición de moderador o de facilitador, en lugar de ir a la lucha y empujar tus propios puntos de vista. Si alguien está comportándose de manera poco educada o monopolizando la conversación, [actúa inmediatamente](../building-community/#no-toleres-a-los-malos-actores) para mantener una discusión civilizada y productiva. + + + +Otras personas te mirarán como un guía. Da un buen ejemplo. Todavía puedes expresar desacuerdo, tristeza o preocupación, pero de manera calmada. + +Mantener la calma no es fácil, pero demostrar liderazgo mejora la salud de tu comunidad. Internet te agradece. + +### Trata a tu README como una constitución + +Tu README es [más que un conjunto de instrucciones](../starting-a-project/#escribiendo-un-readme). También es un lugar para hablar acerca de tus objetivos, visión del producto, y un mapa de ruta. Si las personas están muy centradas en debatir el mérito de un aspecto en particular, puede revisar el README y conversar de una visión más alta de tu proyecto. Centrarse en el README también despersonaliza la conversación, para tener una discusión más constructiva. + +### Enfócate en el viaje, no en el destino + +Algunos proyectos utilizan un proceso de votación para tomar decisiones importantes. Si bien parece sensato a primera vista, la votación pone hincapié en una "respuesta", más que en escuchar y tratar las preocupaciones de cada uno. + +La votación se puede volver política, cuando los miembros de la comunidad se sienten presionados para hacerse favores entre ellos o a votar de determinada manera. No todos votan, si existe una [mayoría silenciosa](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) en tu comunidad, o existen usuarios que no se enteraron que se estaba llevando a cabo una votación. + +Algunas veces, la votación se vuelve un desempate necesario. La mayoría de las veces, sin embargo, pone énfasis en la ["búsqueda de concenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) más que en concensuar. + +Bajo un proceso de búsqueda de concenso, los miembros de la comunidad discuten las principales preocupaciones hasta que sienten que fueron escuchadas adecuadamente. Cuando solo quedan preocupaciones menores, la comunidad avanza. La "Búsqueda de Concenso" reconoce que una comunidad puede no ser capaz de alcanzar una respuesta perfecta. En su lugar prioriza el escuchar y la discusión. + + + +Incluso si no adopta un proceso de búsqueda de consenso, como responsable del proyecto, es importante que las personas sepan que estás escuchando. Hacer que las personas se sientan escuchadas y comprometerte a resolver sus preocupaciones, facilita gran parte del camino para resolver situaciones delicadas. Luego, continúa tus palabras con acciones. + +No te apresures a tomar una decisión por el bien de tener una solución. Asegúrate de que todos se sientan escuchados y que toda la información se ha hecho pública antes de avanzar hacia una solución. + +### Mantén la conversación centrada en la acción + +La discusión es importante, pero hay una diferencia entre conversaciones productivas e improductivas. + +Fomenta la discusión siempre y cuando se mueva hacia una solución. Si está claro que la conversación se está extinguiendo o yéndose por las ramas, que las cosas se están haciendo personales o que están discutiendo sobre detalles menores, es tiempo de cerrarla. + +Permitir que continúen estas conversaciones no solo es malo para un tema en cuestión, sino también para la salud de la comunidad. Esto envía el mensaje que este tipo de conversaciones están permitidas e incluso fomentadas, y puede desalentar a las personas a plantear o resolver problemas futuros. + +Con cada aspecto que hayas hecho o que hayan hecho otros, pregúntate, _"¿Cómo nos acerca ésto a una solución?"_ + +Si la conversación comienza a desenredarse, pregunta al grupo, _"¿Qué pasos deberíamos tomar?"_ para reorientar la conversación. + +Si la conversación claramente no va a ningún lado, no existen acciones claras para tomar, o las acciones correctas ya se llevaron adelante, cierra el tema y explica porqué lo cerraste. + + + +### Elige tus batallas sabiamente + +El contexto es importante. Considera quién está involucrado en una discusión y cómo representa esta al resto de la comunidad. + +¿Están todos en la comunidad molestos, o incluso involucrados en un problema? ¿O es un provocador solitario? No te olvides de considerar a los miembros silenciosos de la comunidad, no solo a las voces activas. + +Si el problema no representa las necesidades más amplias de tu comunidad, tal vez solo necesites agradecer las preocupaciones de algunas personas. Si se trata de un problema recurrente sin una solución clara, dirige el foco a discusiones previas y cierra el hilo de discusión. + +### Identifica a un decisor de la comunidad + +Con una buena actitud y una clara comunicación, es posible resolver la mayoría de las situaciones difíciles. Sin embargo, incluso en una discusión productiva, simplemente pueden haber diferencias de opinión sobre cómo proceder. En esos casos, identifica un individuo o un grupo de personas que puedan actuar como decisivas. + +Un decisor puede ser un responsable primario del proyecto, o podría ser un pequeño grupo de personas que toman una decisión en base a votación. Idealmente, habrás identificado un decisor y el proceso asociado en un archivo llamado GOVERNANCE antes de que necesites utilizarlo. + +Tu decisor debería ser tu último recurso. Los temas que dividen son una oportunidad de crecer y aprender para tu comunidad. Aprovecha esas oportunidades y utiliza un proceso colaborativo para moverte hacia una solución cada vez que sea posible. + +## La comunidad es el ❤️ del código abierto + +Las comunidades sanas y prósperas alimentan las miles de horas que se producen cada semana de código abierto. Muchos colaboradores señalan a otras personas como la razón para trabajar -o para no trabajar- en código abierto. Al aprender a aprovechar ese poder de manera constructiva, ayudarás a que álguien tenga una inolvidable experiencia con el código abierto. diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md new file mode 100644 index 00000000000..e6b1b908a79 --- /dev/null +++ b/_articles/it/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: es +title: Tu Código de Conducta +description: Facilita el comportamiento sano y constructivo, adoptando y aplicando un código de conducta. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Por qué es necesario un código de conducta + +Un código de conducta es un documento que establece expectativas de comportamiento para los participantes de tu proyecto. Adoptar, y aplicar, un código de conducta, ayuda a crear una atmosfera social positiva para la comunidad. + +Los códigos de conducta ayudan a proteger no solo a tus participantes, sino también a ti mismo. Si mantienes un proyecto, sabrás que las actitudes improductivas de otros participantes pueden hacerte sentir sin energía o infeliz acerca de tu trabajo. + +Un código de conducta te alienta a facilitar un comportamiento saludable y constructivo por parte de la comunidad. Ser proactivo reduce la probabilidad de que tanto tú, como otros, se sientan fatigados con el proyecto, y te ayuda a tomar acción cuando alguien hace algo con lo que no concuerdas. + +## Estableciendo un código de conducta + +Intenta establecer un código de conducta tan tempranamente como sea posible: idealmente, cuando crees tú proyecto. + +Además de comunicar tus expectativas, un código de conducta describe lo siguiente: + +* Donde el código de conducta toma efecto _(¿solamente en las issues y pull requests, o en actividades de la comunidad como eventos?)_ +* A quien o quienes aplica el código de conducta _(miembros de la comunidad y responsables de mantenimiento, pero ¿Qué hay acerca de los sponsors?)_ +* Que sucede si alguien viola el código de conducta +* De qué manera alguien puede reportar una violación + +Siempre que sea posible, haga uso del art. El [Contributor Covenant](https://www.contributor-covenant.org/) es un código de conducta usado por más de 40,000 proyectos de software libre, incluyendo Kubernetes, Rails y Swift. + +El [Django Code of Conduct](https://www.djangoproject.com/conduct/) y el [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) son también dos ejemplos de buenos códigos de conducta. + +Ubica un archivo CODIGO_DE_CONDUCTA en el directorio raíz de tu proyecto, y enlázalo desde tu LEEME, así el mismo se encuentra visible a tu comunidad. + +## Decidiendo de qué manera vas a aplicar tu código de conducta + + + +Deberías explicar de qué manera tu código de conducta va a ser aplicado **_antes_** de que una violación ocurra. Hay varios motivos para ello: + +* Esto demuestra que eres serio acerca de tomar acciones cuando sea necesario. + +* Tu comunidad se sentirá más segura de que sus reclamos son realmente revisados. + +* Brindarás a tu comunidad la seguridad de que el proceso de revisión es justo y transparente, en el caso en que se encuentren siendo investigados por una violación. + +Deberías brindar a las personas, una manera privada (por ejemplo, mediante una dirección de correo electrónico) de reportar una violación al código de conducta y explicar quién recibe dicho reporte. Puede ser un responsable de mantenimiento, un grupo de tales responsables, o un grupo de trabajo de código de conducta. + +Recuerda que alguien puede que desee reportar una violación acerca de la persona que recibe dichos reportes. En tal caso, bríndales la posibilidad de que dichos reportes, sean revisados por alguien más. Por ejemplo, @ctb y @mr-c [explican en su proyecto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Instancias de abuso, acoso o similares comportamientos inaceptables pueden ser reportados mandando un correo electrónico a **khmer-project@idyll.org** el cual solamente se dirigirá a C. Titus Brown y Michael R. Crusoe. Para reportar una cuestión que involucra a ambos, por favor envía un correo electrónico a **Judi Brown Clarke, Ph.D.** el Director de Diversidad en el BEACON Center for the Study of Evolution in Action, un centro de la Fundación de Ciencia Nacional para la Ciencia y Tecnologia.* + +Para inspirarte, mira el [manual de ejecución de Django](https://www.djangoproject.com/conduct/enforcement-manual/) (aunque quizás no necesites algo tan amplio, dependiendo del tamaño de tu proyecto). + +## Aplicando tu código de conducta + +En ocasiones, a pesar de tus mayores esfuerzos, alguien hará algo que violará este código. Existen diferentes maneras de abordar el comportamiento negativo o dañino en la práctica. + +### Recolectar información acerca de la situación + +Otórgale la importancia a lo que cada miembro de la comunidad tiene para decir como se la darías a lo que tú tienes para decir. Si recibes un reporte de que alguien ha violado el código de conducta, tómatelo seriamente e investiga el asunto, incluso si no condice con tu experiencia con dicha persona. De esta manera, demuestras a tu comunidad que valoras su perspectiva y confías en su juicio. + +El miembro de la comunidad puede ser un reincidente quien constantemente hace sentir incómodos a los demás o puede haber hecho o dicho algo por única vez. En ambas situaciones podemos tomar acciones, dependiendo del contexto. + +Antes de que respondas, tómate tu tiempo para entender lo que sucedió. Lee los comentarios y conversaciones pasados de la persona para entender mejor quienes son y por qué podrían haber actuado de tal manera. Intenta recolectar perspectivas de otros acerca de dicha persona y su comportamiento. + + + +### Toma acciones apropiadas + +Luego de recolectar y procesar suficiente información, necesitaras decidirte que hacer. Mientras consideras tus siguientes pasos, recuerda que tu objetivo como moderador es fomentar un ambiente seguro, respetuoso y colaborativo. Considera no solamente como tratar la situación en cuestión, sino también como tu respuesta afectará al comportamiento y expectativas del resto de tu comunidad. + +Cuando alguien reporta una violación al código de conducta, es tu trabajo ocuparte de ella, y no de otra persona. A veces, quien reporta está revelando la información con gran riesgo para su carrera, reputación o integridad física. Forzarlos a confrontar a su acosador puede poner en una posición comprometedora a quien reporta. Debes comunicarte de manera directa con la persona en cuestión, a menos que quien reporta explícitamente solicite lo contrario. + +Existen varias maneras de responder a una violación del código de conducta: + +* **Dar a la persona en cuestión una advertencia pública** y explicarle de que manera su comportamiento ha impactado negativamente en los demás, preferiblemente en el canal en donde ocurrió. Siempre que sea posible, la comunicación pública transmite a la comunidad la seriedad con la que consideras al código de conducta. Sé amable, pero firme, en la manera en que te comunicas. + +* **Acercarse de forma privada a la persona** en cuestión para explicarle de que manera su comportamiento impacto negativamente en los demás. Puedes usar un canal de comunicación privado si la situación involucra información personal. Si te comunicas de manera privada con alguien, es una buena idea realizar una copia carbón a los primeros que hayan reportado la situación, de esta manera sabrán que tomaste acciones. Pídele consentimiento a quien reporta antes de enviarle una copia carbón. + +En ocasiones, no es posible lograr una solución. La persona en cuestión puede volverse agresiva y hostil cuando sea confrontada o puede que no cambie su comportamiento. Frente a esta situación, deberías considerar tener en cuenta medidas más fuertes. Por ejemplo: + +* **Suspender a la persona** en cuestión del proyecto, aplicando una prohibición en la participación en todo aspecto del proyecto. + +* **Expulsar permanentemente** a la persona del proyecto. + +La expulsión de miembros no debe ser tomado a la ligera y representa una permanente e irreconciliable diferencia de perspectiva. Deberías tomar estas medidas solamente cuando es evidente que no puede llegarse a una solución. + +## Tus responsabilidades como responsable de mantenimiento + +Un código de conducta no es una ley aplicada arbitrariamente. Tú eres quien aplica el código de conducta y es tu responsabilidad seguir las reglas que el código de conducta establece. + +Como encargado de mantenimiento, tú estableces las directrices de tu comunidad y las aplicas de acuerdo a las reglas establecidas en tu código de conducta. Esto implica considerar seriamente a cualquier violación al código de conducta. Quien reporta merece una justa y total revisión de su reclamo. Si determinas que el comportamiento reportado no es una violación, comunícate de manera clara con ellos y explícales por qué no tomarás ninguna acción. Lo que hacen con eso depende de ellos: tolerar el comportamiento con el cual tenían un problema, o dejar de participar en la comunidad. + +Un reporte de comportamiento que _técnicamente_ no viola el código de conducta puede indicar que hay un problema en tu comunidad, y deberías investigar este problema potencial y actuar acorde. Esto puede incluir revisar tu código de conducta para clarificar comportamientos aceptables y/o hablar con la persona cuyo comportamiento fue reportado y explicarles que si bien no han violado el código de conducta, están rozando el borde de lo que se espera y están haciendo sentir incómodos a ciertos participantes. + +Finalmente, como responsable de mantenimiento, tú estableces y aplicas los estándares de comportamiento aceptable. Tienes la habilidad para moldear los valores de la comunidad del proyecto, y los participantes cuentan con que apliques dichos valores de manera justa e imparcial. + +## Promover el comportamiento que quieres ver en el mundo 🌎 + +Cuando un proyecto parece hostil y poco acogedor, incluso cuando se trata solamente de una persona cuyo comportamiento es tolerado por los demás, te arriesgas a perder mucho más contribuidores, algunos de los cuales quizás no conozcas jamás. No siempre es fácil adoptar o aplicar un código de conducta, pero fomentar un ambiente acogedor ayudará a que tu comunidad crezca. diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md new file mode 100644 index 00000000000..3b204056e2e --- /dev/null +++ b/_articles/it/finding-users.md @@ -0,0 +1,157 @@ +--- +lang: es +title: Encontrando Usuarios Para Tu Proyecto +description: Ayuda a tu proyecto de código abierto a crecer ponióndolo en manos de usuarios satisfechos. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Pasando la voz + +No existe ninguna regla que diga que debes fomentar un proyecto de código abierto cuando lo comienzas. Existen muchas razones satisfactorias para trabajar en código abierto que no tienen nada relacionado con la popularidad. Si esperas que otros encuentren y usen tu proyecto de código abierto, sin embargo, ¡es momento para decirles a todos acerca de tu arduo trabajo! + +## Pensando tu mensaje + +Antes de comenzar el verdadero trabajo de promover tu proyecto, deberías ser capaz de explicar qué es lo que hace, y porqué importa. + +¿Qué hace a tu proyecto diferente o interesante? ¿Porqué lo creaste? Respondiendo estas preguntas para tí mismo hará más fácil convencer a los demás. + +Recuerda que las personas se involucran como usuarios, y eventualmente como contribuyentes, porque resuelve un problema para ellos. Mientras piensas sobre el mensaje para tu proyecto y su valor, trata de verlo a través de los ojos de qué_es_lo_que_ellos_querrían. + +Por ejemplo, @robb utiliza códigos de ejemplo para comunicar claramente porqué su proyecto, [Cartography](https://github.com/robb/Cartography), es útil: + +![cartography readme](/assets/images/finding-users/cartography.jpg) + +Para una vista más profunda sobre cómo comunicar tu mensaje, puedes ver el ejercicio en Mozilla ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) para el desarrollo de personas usuario. + +## Ayuda a las personas a encontrar y seguir tu proyecto + + + +Ayuda a las personas a encontrar y recordar tu proyecto indicándoles un solo espacio de nombres. + +**Consigue un gestor claro para promover tu trabajo.** Un usuario de Twitter, una URL de GitHub o un canal de IRC son maneras fáciles de indicar a las personas sobre tu proyecto. También le da a la creciente comunidad de tu proyecto un lugar donde reunirse. + +Si todavía no deseas establecer estos canales para tu proyecto, promociona en tu usuario personal de Twitter o tu cuenta personal de GitHub todo lo que hagas. Por ejemplo, asegúrate que esté incluído en tu biografía o tus diapositivas si te toca disertar en una reunión o evento. De esa manera, las personas sabrán cómo llegar hasta ti o seguir tu trabajo. + + + +**Considera crear un sitio web para tu proyecto.** Un sitio web hace más amigable a tu proyecto y más fácil de navegar, especialmente cuando se acompaña de documentación clara y de tutoriales. También sugiere que tu proyecto está activo, lo que hará que su audiencia se sienta más confortable usándolo. Utiliza ejemplos para dar a las personas ideas de cómo usar tu proyecto. +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creador of Django, dijo que un sitio web fue _"por lejos lo mejor que hicimos con Django en los primeros días"_. + +Si el proyecto está alojado en GitHub, puedes utilizar [GitHub Pages](https://pages.github.com/) para construir un sitio web facilmente. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), y [Middleman](https://middlemanapp.com/) son [algunos ejemplos](https://github.com/showcases/github-pages-examples) de excelentes y completos sitios web. + +![vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Ahora que ya tienes un mensaje para tu proyecto, y una manera sencilla para que las personas encuentren su proyecto, ¡ve a hablar con tu audiencia! + +## Ve donde está la audiencia de tu proyecto (en línea) + +El alcance en línea es una gran manera de compartir y diseminar la palabra rápidamente + +Saca ventaja de las comunidades en línea existentes y sus plataformas para alcanzar tu audiencia. Si tu proyecto es de código abierto es un proyecto de software, probablemente puedas encontrar tu audiencia en [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), o [Quora](https://www.quora.com/). Encuentra los canales donde pienses que las personas obtendrán los mayores beneficios o se sentirán más entusiasmadas acerca de tu trabajo. + + + +Ve si puedes encontrar formas de compartir tu proyecto en maneras relevantes: + +* **Conoce proyectos de código abierto relevantes y comunidades.** Algunas veces, no necesitas promocionar tu proyecto directamente. Si tu proyecto es de interés para científicos de datos que utilizan Python, conoce a la comunidad de científicos de datos de Python. A medida que las personas lo conozcan, llegarán oportunidades de conversar y de compartir tu trabajo de manera natural. +* **Encuentra personas que estén experimentando problemas como el que resuelve tu proyecto.** Busca en foros relacionados con personas que caen en la audiencia de tu proyecto. Responde sus preguntas y encuentra una forma diplomática, cuando sea apropiado, de sugerir tu proyecto como una solución. +* **Pide comentarios.** Preséntate y presenta tu trabajo a una audiencia que lo encuentre relevante e interesante. Se específico acerca de quiénes crees que se beneficiarán de tu proyecto. Trata de finalizar la oración: _"Creo que mi proyecto realmente ayudará a X, quien está tratando de hacer Y_". Escucha y responde los comentarios, en lugar de simplemente promover tu trabajo. + +En términos generales, enfócate en ayudar a los demás antes de solicitar cosas a cambio. Ya que es sencillo para cualquiera promover un proyecto en línea. habrá mucho ruido. Da a las personas el contexto de lo que eres, no solo de lo que quieres, para destacarte entre la multitud. + +Si nadie presta atención o responde a tu alcance inicial, ¡no te desanimes! La mayoría de los lanzamientos de proyectos son un proceso iterativo que puede llevar meses o años. Si no consigues una respuesta la primera vez, prueba con una táctica diferente, o busqua maneras de agregar valor al trabajo de los demás primero. Estas cosas llevan tiempo y dedicación. + +## Ve donde está la audiencia de tu proyecto (fuera de línea) + +![public speaking](/assets/images/finding-users/public_speaking.jpg) + +Los eventos fuera de línea son una manera popular de promocionar nuevos proyectos. Es una gran manera de alcanzar una audiencia comprometida y de construir conexiones personales más profundas, especialmente si estás interesado en llegar a los desarrolladores. + +Si no tienes [experiencia para hablar en público](https://speaking.io/), comienza por encontrar una comunidad local de personas que estén relacionados con el lenguaje o ecosistema de tu proyecto. + + + +Si nunca hablaste en un evento anteriormente, es perfectamente normal sentirte nervioso. Recuerda que tu audiencia está allí porque genuinamente quieren escuchar acerca de tu trabajo. + +Mientras escribes tu charla, enfócate en lo que el público pueda encontrar interesante y valioso. Mantén tu lenguaje amigable y accesible. Sonríe, respira y diviértete. + + + +Cuando te sientas listo/a, considera dar una charla en una conferencia para promover tu proyecto. Las conferencias pueden ayudar a alcanzar a más personas, algunas veces de todo el mundo. + +Busca conferencias que sean específicas de tu lenguaje o ecosistema. Antes que enviar tu charla, investiga la conferencia de antemano, para adaptar tu charla a sus asistentes e incrementar tus oportunidades de ser aceptado. A menudo puedes tener una idea de la audiencia de una conferencia mirando a sus disertantes. + + + +## Construye una reputación + +Además de las estrategias mencionadas anteriormente, la mejor forma de invitar a las personas a compartir y contribuir con tu proyecto es compartir y contribuir con sus proyectos. + +Ayudar a los recién llegados, compartir recursos y hacer contribuciones meditadas al trabajo de los demás ayudará a que construyas una reputación positiva. Entonces, la gente tendrá contexto para su trabajo y será más probable que preste atención y comparta lo que tu estás haciendo. + +Algunas veces, esas relaciones pueden llevar incluso a asociaciones oficiales con el ecosistema más amplio. + + + +Nunca es demasiado temprano, o muy tarde, para comenzar a construir tu reputación. Incluso si ya lanzaste tu propio proyecto, continúa buscando las formas de ayudar a los demás. + +No hay una solución para construir una audiencia en una noche. Ganarse la confianza y el respeto de los demás lleva tiempo, y el trabajo de construir la reputación no termina nunca. + + + +## Síguelo! + +Algunas veces, lleva mucho tiempo antes de que la gente note tu proyecto de código abierto. ¡Está bien! Algunos de los proyectos más populares de hoy en día, tardaron años en alcanzar altos niveles de actividad. Enfócate en construir relaciones en lugar de una bala mágica. Sé paciente, y continúa compartiendo tu trabajo con aquellos que lo aprecian. diff --git a/_articles/it/getting-paid.md b/_articles/it/getting-paid.md new file mode 100644 index 00000000000..deb595bded9 --- /dev/null +++ b/_articles/it/getting-paid.md @@ -0,0 +1,184 @@ +--- +lang: es +title: Recibir Pagos por Trabajos en Código Abierto +description: Mantén tu trabajo de código abierto al encontrar apoyo financiero por tu tiempo o tu proyecto. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## ¿Por qué algunas personas buscan apoyo financiero? + +La mayor parte del trabajo realizado en proyectos de código abierto es voluntario. Por ejemplo, alguien puede encontrarse con un error en un proyecto que usan y aplican una corrección rápida, o simplemente les puede gustar corregir proyectos de código abierto en su tiempo libre. + + + +Hay muchas razones por las cuales a una persona no le gustaría que le pagaran por su trabajo en código abierto. + +* **Ellos pueden llegar a tener ya un trabajo de tiempo completo que disfruten**, que los habilite a contribuir al código abierto en su tiempo libre. +* **Les gusta contribuir a los proyectos de código abierto como un hobby** o escape creativo y no quieren sentirse financieramente obligados a trabajar. +* **Reciben otros beneficios al contribuir al código abierto,** como construir su portfolio de reputación, obtener nuevas habilidades, o sentirse cercanos a una comunidad. + + + +Para otros, especialmente cuando las contribuciones están en proceso o requieren tiempo significativo, recibir dinero al contribuir al código abierto es la única manera en la que pueden participar. Porque el proyecto lo requiera o por razones personales. + +Mantener proyectos populares puede ser una responsabilidad significativa, tomando de 10 a 20 horas por semana en vez de un par de horas por mes. + + + +El trabajo pagado también habilita a todo tipo de personas a aportar significativamente. Algunas no pueden afrontar un trabajo ad-honorem (trabajo gratis) en proyectos de código abierto, ya sea por su posición financiera, deudas, familia u otras responsabilidades. Eso significa que el mundo nunca ve contribuciones de personas talentosas que no pueden donar horas de trabajo. Estas implicaciones éticas como @ashedryden [ha descrito](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), desde que el trabajo hecho es parcialmente en favor de las personas que tienen ventajas en su vida, quienes de vuelta ganan ventajas adicionales basadas en sus contribuciones voluntarias, mientras que otros que no pueden ofrecerse voluntariamente no obtiene nuevas oportunidades, lo cual refuerza la actual falta de diversidad en la comunidad de código abierto. + + + +Si tu estás buscando apoyo financiero, hay dos posibles caminos a seguir: puedes pagar por tu propio tiempo como contribuyente, o puedes encontrar organizaciones que aporten a tu proyecto. + +## Financiando tu propio tiempo + +Hoy en día, muchas personas reciben pagos por trabajos a tiempo parcial o tiempo completo en código abierto. El modo más común de recibir una paga por tu tiempo es hablar con tu empleador. + +Es más fácil establecer un trabajo en código abierto si tu empleador usa el proyecto, pero ponte creativo. Puede que tu empleador no use el proyecto, pero usa Python, y mantener un proyecto popular de Python puede atraer nuevos desarrolladores de Python. También puede que haga que tu empleador se vea más desarrollador-amigable en general. + + + +Si tu no tienes un excitante proyecto de código abierto en el que quisieras trabajar, pero te gustaría que tu actual trabajo genere aportes al código abierto, establece un acuerdo con tu empleador para aportar algo del software interno de la organización a la comunidad de código abierto. + +Muchas empresas están desarrollando programas de código abierto para construir su marca y reclutar talentos de calidad. + +@hueniverse, por ejemplo, encontró que había razones financieras para justificar [la inversión de Walmart al código abierto](http://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Y @jamesgpearce descubrió que el programa de código abierto de Facebook [hizo la diferencia](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) en el reclutamiento: + +> Está alineado con nuestra cultura hacker, y cómo nuestra organizacion era percibida. Le preguntamos a nuestros empleados, "¿Sabías del programa de software de código abierto de Facebook?. Dos tercios dijeron "Sí". Una mitad dijo que el programa contribuía positivamente en la decisión de trabajar para nosotros. Estos no son números marginales, y, espero, que la moda continúe. + +Si tu empresa va por esta ruta, es importante mantener clara la relación entre la comunidad y la actividad corporativa. últimamente, el código abierto se mantiene a sí mismo a través de contribuciones de personas de todo el mundo, y eso es más importante que la empresa o la ubicación de la misma. + + + +Si no pueden convencer a tu actual empleador de priorizar un trabajo de código abierto, considera encontrar un nuevo empleador que motive a los empleados a contribuir. Busca empresas que hagan su dedicación al código abierto explícita. Por ejemplo: + +* Algunas empresas, como [Netflix](https://netflix.github.io/) o [PayPal](https://paypal.github.io/), tienen páginas web que resaltan su participación en el código abierto. +* [Zalando](https://opensource.zalando.com) publicó su [políticas de contribución al código abierto](https://opensource.zalando.com/docs/using/contributing/) para empleados. + +Proyectos que se originaron en una empresa grande, como [Go](https://github.com/golang) o [React](https://github.com/facebook/react), serán susceptibles a contratar personas que trabajen en código abierto. + +Finalmente, dependiendo de tus circunstancias personales, puedes probar generar dinero de forma independiente para financiar tu trabajo de código abierto. Por ejemplo: + +* @Homebrew (y [varios mantenedores y organizaciones](https://github.com/sponsors/community)) financian su trabajo a través de [GitHub Sponsors](https://github.com/sponsors) +* @gaearon financió su propio trabajo [Redux](https://github.com/reactjs/redux) a través de [Patreon crowdfunding campaign](https://redux.js.org/) +* @andrewgodwin financió su trabajo de migración de esquemas de Django [a través de una campaña kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +## Encontrando financiación para tu proyecto. + +Más allá de los arreglos con contribuyentes individuales, a veces los proyectos generan dinero de empresas, individuos, u otras para financiar trabajos en proceso. + +La financiación organizacional podría ir a favor de pagar a los contribuyentes, cubriendo los costos de correr los proyectos (como los costos de hosting), o investigando nuevas funcionalidades o ideas. + +Mientras aumenta la popularidad de código abierto, encontrar financiación para proyectos sigue siendo experimental, pero hay algunas opciones que comunmente estan disponibles. + +### Genera dinero para trabajo a través de campañas de crowdfunding o sponsors. + +Encontrar sponsors funciona si tienes una fuerte audiencia o reputación ya establecida, o tu proyecto es muy popular. +Algunos ejemplos comunes de proyectos sponsoreados incluyen: + +* **[webpack](https://github.com/webpack)** genera dinero de empresas e individuos [a través de OpenCollective](https://opencollective.com/webpack) +* **[Vue](https://github.com/vuejs/vue)** es [financiado a través de Patreon](https://github.com/open-source/stories/yyx990803) +* **[Ruby Together](https://rubytogether.org/),** una organización sin fines de lucro que paga por el trabajo en [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), y otros proyectos de la infraestructura de Ruby. + +### Crea un flujo de ingresos. + +Dependiendo de tu proyecto, puede que seas capaz de cobrar por soporte comercial o funciones adicionales. Algunos ejemplos incluyen: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** ofrecen versiones pagas por soporte adicional. +* **[Travis CI](https://github.com/travis-ci)** ofrece versiones pagas de su producto. +* **[Ghost](https://github.com/TryGhost/Ghost)** es sin fines de lucro con una gestión de servicio paga. + +Algunos proyectos populares, como [npm](https://github.com/npm/cli) y [Docker](https://github.com/docker/docker), generan capital de riesgo para soportar el crecimiento de su negocio. + +### Suscríbete a subvenciones + +Algunas fundaciones de software y compañias ofrecen subvenciones por trabajo en código abierto. A veces, las subvenciones puede ser pagadas a individuos sin establecer una entidad legal para el proyecto. + +* **[Lee los documentos](https://github.com/rtfd/readthedocs.org)** recibe una subvención del [Soporte al código abierto de Mozilla](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** fue financiado por [un retiro de Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** recibió una subvención de [Sloan Foundation](https://sloan.org/programs/digital-technology) +* La **[fundación de software de Python](https://www.python.org/psf/grants/)** ofrece subvenciones a trabajos relacionados con Python. + +Por más opciones y casos de estudio, @nayafia [escribió una guía](https://github.com/nayafia/lemonade-stand) para recibir pagos por trabajos en proyectos de código abierto. Diferentes tipos de financiación requieren diferentes tipos de habilidades, entonces considera tus fortalezas para descubrir que opciones funcionan mejor para ti. + +## Creando un caso de apoyo financiero + +Sin importar si tu proyecto es una nueva idea, o estuvo dando vueltas por años, deberías preveer que tendrás que ponerle mucho esfuerzo en identificar a tu financiador objetivo y construir un caso acorde. + +Sin importar si estás buscando pagar por tu propio tiempo, o invertir/generar en un proyecto, deberías poder responderte las siguientes preguntas: + +### Impacto + +¿Por qué es útil este proyecto? ¿Por qué nuestros usuarios, o potenciales usuarios, les gusta tanto? ¿Dónde se encontrará dentro de cinco años? + +### Atracción + +Intenta recolectar evidencia de que tu proyecto importa, sin importar las métricas, anécdotas, o testimonios. ¿Hay alguna compañía o algún grupo notorio de personas usando tu proyecto ahora mismo? Si no, ¿Hubo alguna persona prominente que lo aprobó? + +### Valor para el financiador + +Los financiadores, sin importar si tu empleador o tu fundación generadora de subvenciones, son frecuentemente ofertados con oportunidades. ¿Porqué deberían apoyar tu proyecto por sobre toda otra oportunidad? ¿Como se benefician ellos personalmente? + +### Uso de la financiación + +¿Qué exactamente lograrás con la financiación propuesta? Concéntrate en hitos de proyectos o imprevistos en vez de los pagos de salario. + +### Como recibirás la financiación. + +¿El financiador tiene algun requisito de como recibirás el dinero? Por ejemplo, puede que necesites ser un sponsor o tener un sponsor fiscal sin fines de lucro. O tal vez la financiación debe ser entregada a un contratador individual en vez de a una organización. Estos requisitos varían entre los financiadores, así que asegurate de hacer averiguaciones de antemano. + + + +## Experimenta y no te rindas + +Recaudar dinero no es fácil, ya sea un proyecto de código abierto, una organización sin fines de lucro, o un emprendimiento de software, y la mayoría de los casos requieren que seas creativo. Debes identificar cómo quieres que te paguen, debes investigar y debes ponerte en el lugar de tu financiador, de esta manera podrás construir un caso convicente para que te financien. diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md new file mode 100644 index 00000000000..36d37673e05 --- /dev/null +++ b/_articles/it/how-to-contribute.md @@ -0,0 +1,522 @@ +--- +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..627d4f8ebb0 --- /dev/null +++ b/_articles/it/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Guías de código abierto +lang: es +permalink: /es/ +--- 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..01815bf90be --- /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**. + +![crear repositorio](/assets/images/legal/repo-create-name.png) + +**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/22/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/2015/06/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?_ + +![traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +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. + +![clone graph](/assets/images/metrics/clone_graph.png) + +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. + +![contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **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. + +![¡Debes elegir una licencia!](/assets/images/starting-a-project/repository-license-picker.png) + +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. + +![Pautas para contribuir](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### 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..c8d66340567 --- /dev/null +++ b/_data/locales/it.yml @@ -0,0 +1,31 @@ +es: + locale_name: Italiano + nav: + about: Circa + contribute: Contribuire + index: + lead: Il software open source è sviluppato da persone come te, impara come creare e far crescere il tuo progetto. + opensourcefriday: È venerdì! Investi qualche ora per contribuire al software che usi e ami + article: + table_of_contents: Tabella dei contenuti + back_to_all_guides: Torna a tutte le guide + related_guides: Guíde correlate + footer: + contribute: + heading: Contribuire + description: Hai qualche suggerimento? Questo contenuto è open source. Aiutaci a migliorarlo. + button: Contribuire + subscribe: + heading: Iscriviti per le notizie. + description: Sii il primo a conoscere gli ultimi suggerimenti e risorse open source di GitHub. + label: Indirizzo e-mail + button: Sottoscrivere + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] con [love] fatto da [github] e [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: amici