From 8d3b020c08879238f0d0172d9e3ceea7b2ec34e4 Mon Sep 17 00:00:00 2001 From: Jorge Lama Date: Thu, 11 Apr 2024 22:48:41 +0200 Subject: [PATCH] Grammatical modifications added to the Galician translation in the texts of the corresponding .md files (#680) * Grammatical corrections in several patterns of Galician translation (translation/gl/patterns) * Grammatical corrections in several templates (translation/gl/templates) and book introduction (book/gl/introduction.md) --- book/gl/introduction.md | 20 ++++++------- translation/gl/patterns/30-day-warranty.md | 2 +- translation/gl/patterns/base-documentation.md | 14 ++++----- .../gl/patterns/common-requirements.md | 2 +- .../gl/patterns/communication-tooling.md | 2 +- .../gl/patterns/contracted-contributor.md | 2 +- translation/gl/patterns/core-team.md | 2 +- .../patterns/crossteam-project-valuation.md | 30 +++++++++---------- .../gl/patterns/dedicated-community-leader.md | 28 ++++++++--------- .../document-your-guiding-principles.md | 2 +- .../extensions-for-sustainable-growth.md | 2 +- translation/gl/patterns/gig-marketplace.md | 2 +- translation/gl/patterns/group-support.md | 2 +- .../gl/patterns/innersource-license.md | 18 +++++------ translation/gl/patterns/innersource-portal.md | 26 ++++++++-------- translation/gl/patterns/issue-tracker.md | 2 +- translation/gl/patterns/maturity-model.md | 2 +- .../gl/patterns/repository-activity-score.md | 2 +- translation/gl/patterns/review-committee.md | 2 +- translation/gl/patterns/service-vs-library.md | 2 +- .../gl/patterns/start-as-experiment.md | 18 +++++------ ...t-cross-team-decision-making-using-rfcs.md | 2 +- translation/gl/patterns/trusted-committer.md | 9 +++--- .../gl/templates/CONTRIBUTING-template.md | 6 ++-- translation/gl/templates/README-template.md | 12 ++++---- translation/gl/templates/pattern-template.md | 8 ++--- 26 files changed, 109 insertions(+), 110 deletions(-) diff --git a/book/gl/introduction.md b/book/gl/introduction.md index 570924641..7e52df595 100644 --- a/book/gl/introduction.md +++ b/book/gl/introduction.md @@ -3,7 +3,7 @@ ![Modelos InnerSource](innersource-patterns-book-cover.png) {% hint style="info" %} -Vostede está a ler unha versión preliminar do libro *Modelos InnerSource: Guía das mellores prácticas por casos: Fáciles de entender, avaliar e aplicar*, polo que é posible que algunhas ligazóns non funcionen, ou atope algún erro. Pode axudarnos a corrixilos e así poder ofrecer o mellor libro posible, se escolle facer [contribucións](contribute.md) a este libro. +Vostede está a ler unha versión preliminar do libro *Modelos InnerSource: Guía das mellores prácticas por casos: Fáciles de entender, avaliar e aplicar*, polo que é posible que algunhas ligazóns non funcionen, ou atope algún erro. Pode axudarnos a corrixilos, e así poder ofrecer o mellor libro posible, se escolle facer [contribucións](contribute.md) a este libro. {% endhint %} Benvido ao libro **Modelos de InnerSource**. @@ -14,7 +14,7 @@ Este libro contén as mellores prácticas de InnerSource debulladas nun formato Nesta introdución explicamos [que é InnerSource](#que-é-innersource), [que é un modelo](#que-son-os-modelos-innersource) e [como empregar eses modelos](#como-pode-empregar-os-modelos-innersource) na súa organización. -Se xa está a empregar InnerSource na súa empresa e quere contribuír aportando experiencias a este libro, encantaríanos [recibir as súas contribucións](./contribute.md) +Se xa está a empregar InnerSource na súa empresa e quere contribuír achegando experiencias a este libro, encantaríanos [recibir as súas contribucións](./contribute.md) ## Que é InnerSource? @@ -28,34 +28,34 @@ Para as empresas que crean na súa meirande parte software de código pechado, I ## Que son os modelos InnerSource? -Os modelos son unha forma de describir unha solución probada e repetible para un problema nun contexto concreto. Os modelos empregan un formato sinxelo co que, na propia aplicación da solución, axudan a comprender as limitacións do problema, os aspectos que mellorar e o contexto resultante; é dicir, a nova situación xerada trala aplicación desta solución. +Os modelos son unha forma de describir unha solución probada e repetible para un problema nun contexto concreto. Os modelos empregan un formato sinxelo co que, na propia aplicación da solución, axudan a comprender as limitacións do problema, os aspectos que mellorar e o contexto resultante; é dicir, a nova situación xerada tras a aplicación desta solución. Os modelos poden proporcionar aos/ás participantes de InnerSource Commons un medio polo que compartir información de xeito conciso, para mellorar a práctica InnerSource. Algunhas das seccións principais destes modelos son: Título, Problema, Contexto, Aspectos que mellorar e Solucións. -* [Vídeos de Youtube sobre que son os modelos](http://bit.ly/innersource_patterns_videos): Visualice esta serie de vídeos de YouTube de entre 2 e 5 minutos, na que se explican os modelos InnerSource. -* [Webinario sobre os modelos](https://youtu.be/i-0IVhfRVFU): O 16 de marzo de 2017 levouse a cabo este webinario no que se debateu en vivo un modelo donut (minuto 24:30). É un exemplo do proceso de revisión que seguimos. Tamén pode consultar o [webinario sobre modelos InnerSource de O’Reilly do 1 de xuño de 2017](http://www.oreilly.com/pub/e/3884). -* [Prototipo de modelo](../../translation/gl/templates/pattern-template.md): Observe a estrutura dun modelo InnerSource para ter unha idea do que acontece nun modelo novo. +* [Vídeos de Youtube sobre que son os modelos](http://bit.ly/innersource_patterns_videos): visualice esta serie de vídeos de YouTube de entre 2 e 5 minutos, na que se explican os modelos InnerSource. +* [Webinario sobre os modelos](https://youtu.be/i-0IVhfRVFU): o16 de marzo de 2017 levouse a cabo este webinario no que se debateu en vivo un modelo donut (minuto 24:30). É un exemplo do proceso de revisión que seguimos. Tamén pode consultar o [webinario sobre modelos InnerSource de O’Reilly do 1 de xuño de 2017](http://www.oreilly.com/pub/e/3884). +* [Prototipo de modelo](../../translation/gl/templates/pattern-template.md): observe a estrutura dun modelo InnerSource para ter unha idea do que acontece nun modelo novo. * [Introdución aos modelos InnerSource (presentación en inglés do cumio de outono de 2016)](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc), de Tim Yao e Padma Sudarsan (PDF). Expón os antecedentes e algúns exemplos de modelos, e permitiralle comprender en detalle os motivos polos que facer uso dos nosos modelos e como facelo. Consulte tamén a [Introdución aos modelos InnerSource (do cume de outono de 2017)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) de Tim Yao e Bob Hanmer (PDF). ## Como pode empregar os modelos InnerSource? Os modelos deben empregarse coidadosamente. Non poden aplicarse de xeito indiscriminado. Na maioría dos casos, vostede necesitará adaptar unha solución á súa situación particular; mais a información proporcionada no modelo, que define o contexto (os límites inamovibles) e os aspectos que mellorar (os límites que poden cambiar e equilibrarse entre si), debería servir de axuda para poñela en práctica. Teña en conta que tamén deberá determinar se existen limitacións adicionais (o contexto e os aspectos que queira mellorar a empresa) que se apliquen á súa compañía/organización en particular e deban engadirse ao modelo (como se fose unha especie de filtro). Estas limitacións adicionais poden chegar a requirir pasos adicionais para chegar a unha solución. -O impreso do modelo é útil para describir solucións probadas, pero tamén se pode empregar para xerar ideas sobre novas solucións onde aínda non se estableceron modelos. Isto débese a que a anatomía dun modelo proporciona un marco de traballo para pensar sobre un problema dun xeito estruturado. Vostede tamén pode crear un *modelo de donut* (completando os campos de problema, contexto, aspectos que mellorar e contexto resultante; pero deixando a solución en branco) como unha forma de pedir axuda á comunidade InnerSource Commons (para encontrar unha solución comprobada ou para aportar ideas sobre que cousas probar). +O impreso do modelo é útil para describir solucións probadas, pero tamén se pode empregar para xerar ideas sobre novas solucións onde aínda non se estableceron modelos. Isto débese a que a anatomía dun modelo proporciona un marco de traballo para pensar sobre un problema dun xeito estruturado. Vostede tamén pode crear un *modelo de donut* (completando os campos de problema, contexto, aspectos que mellorar e contexto resultante; pero deixando a solución en branco) como unha forma de pedir axuda á comunidade InnerSource Commons (para encontrar unha solución comprobada ou para achegar ideas sobre que cousas probar). ## Como contribuír? -Consulte: [Como contribuír a este libro](./contribute.md). +Consulte: [como contribuír a este libro](./contribute.md). ## Créditos -Este libro é o resultado de moitos anos de traballo de incontables [contribuidores/as de software libre](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors) de todo o mundo. A súa vontade de compartir abertamente os desafíos que afrontaron as súas empresas e o xeito no que InnerSource lles axudou a abordar eses desafíos, fan deste libro un recurso valioso para calquera que inicie o seu percorrido InnerSource. +Este libro é o resultado de moitos anos de traballo de incontables [contribuidores/as de software libre](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors) de todo o mundo. A súa vontade de compartir abertamente os desafíos que afrontaron as súas empresas e o xeito no que InnerSource os axudou a abordar eses desafíos, fan deste libro un recurso valioso para calquera que inicie o seu percorrido InnerSource. Queremos facer unha mención especial ao InnerSource Patterns Working Group, que nutriu a calidade dos modelos e axudou a outros/as a facer contribucións. E tamén compilou a selección de modelos dispoñibles neste libro. A imaxe do título do libro foi creada por [Sebastian Spier](https://spier.hu) e adaptada dunha imaxe de [Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/), dispoñible baixo a licenza [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/). -**Moitas grazas a tódolos/as contribuidores/as! E feliz día InnerSource. :)** +**Moitas grazas a todos os/as contribuidores/as! E feliz día InnerSource. :)** ## Licenza diff --git a/translation/gl/patterns/30-day-warranty.md b/translation/gl/patterns/30-day-warranty.md index d2082290b..1bf6c9594 100644 --- a/translation/gl/patterns/30-day-warranty.md +++ b/translation/gl/patterns/30-day-warranty.md @@ -4,7 +4,7 @@ Garantía de 30 días ## Patlet -Cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos equipos e fará que sexa máis probable que se acepten as contribucións. +cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos os equipos e fará que sexa máis probable que se acepten as contribucións. ## Problema diff --git a/translation/gl/patterns/base-documentation.md b/translation/gl/patterns/base-documentation.md index 1edbe00ce..928ccdde5 100644 --- a/translation/gl/patterns/base-documentation.md +++ b/translation/gl/patterns/base-documentation.md @@ -4,7 +4,7 @@ Documentación base estándar ## Patlet -Os/As novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como `README.md`/`CONTRIBUTING.md` permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns. +ós/ás novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como README.md/CONTRIBUTING.md permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns. ## Problema @@ -20,7 +20,7 @@ O proxecto debe compartirse con outros/as contribuidores/as como proxecto InnerS - O proxecto creouse como unha iniciativa InnerSource fai pouco. Con todo, o equipo anfitrión carece da experiencia con InnerSource. Como consecuencia, este necesita orientación para saber que información incluír na súa documentación, onde colocar esa documentación do código para que outros/as poidan atopala, ademais de entender como dirixirse ás persoas que despois van a ler esa documentación de código. - O proxecto converteuse nun proxecto InnerSource recentemente, o equipo anfitrión ten experiencia limitada con InnerSource. Como resultado, a documentación de código existente aborda moitos aspectos técnicos. Así a todo, non se aborda a comunicación, a coordinación ou a información necesaria para facilitar unha planificación transparente. - O proxecto converteuse nun proxecto InnerSource recentemente. Como resultado, a meirande parte do coñecemento implícito que existe dentro do equipo non está escrito, polo que non é visible para os/as contribuidores/as. -- A falta de documentación de código fai que os/as posibles contribuíntes tarden moito tempo en distribuírse e comezar. Elaborar documentación de código (e mantela actualizada) require unha inversión de tempo. Incluso se o equipo anfitrión confía nos/as contribuidores/as para que lle axuden coa documentación de código que falta, esta aínda precisa dun tempo para revisarse. +- A falta de documentación de código fai que os/as posibles contribuíntes tarden moito tempo en distribuírse e comezar. Elaborar documentación de código (e mantela actualizada) require un investimento de tempo. Incluso se o equipo anfitrión confía nos/nas contribuidores/as para que o axuden coa documentación de código que falta, esta aínda precisa dun tempo para revisarse. - Os membros do proxecto pasan moito tempo respondendo a preguntas con respecto á posta en marcha do devandito proxecto. Porén, manter unha base de datos exhaustiva cunha especie de preguntas de asistencia, require moito tempo e esforzo. - Os distintos equipos da empresa teñen estándares diverxentes respecto a como formatar o código fonte e que modelos de software empregar. Por conseguinte, a miúdo a maior parte de contribucións teñen que reescribirse ata incluso na súa totalidade. Estandarizar estes aspectos e facer que se cumpra a norma adoita requirir de moito tempo e traballo. - O traballo adicional resultado das explicacións repetidas e as reescrituras diminúe a utilidade do enfoque InnerSource. @@ -36,11 +36,11 @@ Se aínda non o fixo, cree un arquivo `README.md` para o seu proxecto que conte - [A misión do proxecto](https://producingoss.com/en/producingoss.html#mission-statement) no formato máis conciso posible. Debe dar resposta ao propósito do proxecto e permitir que os/as contribuidores/as se fagan unha idea inicial de se é probable que a posta en marcha da funcionalidade suxerida estea dentro do alcance do proxecto ou non. - Unha sección de «Comezo» para os/as usuarios/as intermedios/as do proxecto. Esta sección debe explicar como configurar/integrar os dispositivos do proxecto, así como tamén ha de incluír unha explicación dalgúns dos primeiros pasos habituais para os/as usuarios/as recentemente incorporados/as. -- Documentación máis detallada para os/as usuarios/as do proxecto ou unha ligazón á mesma. -- Documentación necesaria para realizar modificacións no proxecto ou unha ligazón á mesma. +- Documentación máis detallada para os/as usuarios/as do proxecto ou unha ligazón a ela. +- Documentación necesaria para realizar modificacións no proxecto ou unha ligazón a ela. - Documentación sobre como contribuír ao proxecto ou unha ligazón á mesma. - Unha sección de «Comezo» que explique que canles de comunicación públicas, arquivadas e asociadas se empregan no proxecto. Isto debe incluír unha ligazón ao sistema de seguimento de incidencias do proxecto, pero tamén a calquera outro medio de discusión utilizado. -- Unha sección de «Quen somos?» na que se explica quen son os/as [*trusted committers*](./trusted-committer.md) que están detrás do proxecto, cunha explicación na que se especifica que, na contra de contactar a estas persoas en privado, débense empregar as canles de comunicación públicas mencionadas anteriormente. +- Unha sección de «Quen somos?» na que se explica quen son os/as [*trusted committers*](./trusted-committer.md) que están detrás do proxecto, cunha explicación na que se especifica que, na contra de contactar estas persoas en privado, se deben empregar as canles de comunicación públicas mencionadas anteriormente. - Unha explicación que expoña os criterios do proxecto polos que os/as contribuidores/as pasan a ser *trusted committers*, no caso de que exista esa posibilidade. ![README.md](../../../assets/img/gl/README-for-users.png) @@ -58,14 +58,14 @@ Se a guía dos pasos para facer unha contribución é demasiado complicada, cree ![CONTRIBUTING.md](../../../assets/img/gl/CONTRIBUTING-for-contributors.png) -Existen moitos e moi bos exemplos de como escribir a un `README.md`, así como do tipo de información que incluír nun arquivo `CONTRIBUTING.md` en varios proxectos de software libre. Páxinas como [*How to write a readme that rocks*](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a) [Como escribir un README que sexa un éxito], [*Open Source Guide from GitHub*](https://opensource.guide/) [Guía de software libre en Github], así como o libro [*Producing Open Source*](https://producingoss.com/en/producingoss.html) [A creación do software libre] conteñen información valiosa sobre o tipo de información que precisa proporcionar aos/ás contribuidores/as. Posto que *Producing Open Source* non contén un capítulo sobre como escribir un bo README *per se*, o capítulo «[Getting Started](https://producingoss.com/en/producingoss.html#starting-from-what-you-have)» [Comezo] proporciona unha listaxe bastante extensa de cousas que necesitarán os membros do *host team*, os/as usuarios/as e os/as contribuidores/as. É probable que os proxectos InnerSource non cubran todos eses aspectos desde o comezo, pero a listaxe en si é útil a modo inspiración que serve para determinar aquelas áreas que se poderían incluír. +Existen moitos e moi bos exemplos de como escribir a un `README.md`, así como do tipo de información que incluír nun arquivo `CONTRIBUTING.md` en varios proxectos de software libre. Páxinas como [*How to write a readme that rocks*](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a) [Como escribir un README que sexa un éxito], [*Open Source Guide from GitHub*](https://opensource.guide/) [Guía de software libre en Github], así como o libro [*Producing Open Source*](https://producingoss.com/en/producingoss.html) [A creación do software libre] conteñen información valiosa sobre o tipo de información que precisa proporcionar aos/ás contribuidores/as. Posto que *Producing Open Source* non contén un capítulo sobre como escribir un bo README *per se*, o capítulo «[Getting Started](https://producingoss.com/en/producingoss.html#starting-from-what-you-have)» [Comezo] proporciona unha listaxe bastante extensa de cousas que necesitarán os membros do *host team*, os/as usuarios/as e os/as contribuidores/as. É probable que os proxectos InnerSource non cubran todos eses aspectos desde o comezo, pero a listaxe en si é útil a modo de inspiración que serve para determinar aquelas áreas que se poderían incluír. Ademais, este modelo contén dous exemplos moi básicos para que poida iniciarse de inmediato: [README-template.md](../templates/README-template.md) e [CONTRIBUTING-template.md](../templates/CONTRIBUTING-template.md) ## Contexto resultante - O tempo que tardan os/as contribuidores/as en poñerse ao día redúcese de xeito significativo. -- Redúcese de xeito considerable o tempo dedicado a responder ás preguntas iniciais dos/as [*trusted committers*](./trusted-committer.md), o que lles permite ter máis tempo para traballar noutras tarefas. +- Redúcese de xeito considerable o tempo dedicado a responder ás preguntas iniciais dos/das [*trusted committers*](./trusted-committer.md), o que lles permite ter máis tempo para traballar noutras tarefas. - As escaladas por mor de malentendidos e discordancias redúcense de xeito significativo. ## Exemplos coñecidos diff --git a/translation/gl/patterns/common-requirements.md b/translation/gl/patterns/common-requirements.md index ab9d7d435..bad56c037 100644 --- a/translation/gl/patterns/common-requirements.md +++ b/translation/gl/patterns/common-requirements.md @@ -4,7 +4,7 @@ Requisitos comúns ## Patlet -O código común dun repositorio compartido non satisfai as necesidades de tódolos equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización. +o código común dun repositorio compartido non satisfai as necesidades de todos os equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización. ## Problema diff --git a/translation/gl/patterns/communication-tooling.md b/translation/gl/patterns/communication-tooling.md index 92e80e4f3..bca7c5a25 100644 --- a/translation/gl/patterns/communication-tooling.md +++ b/translation/gl/patterns/communication-tooling.md @@ -4,7 +4,7 @@ Ferramentas de comunicación ## Patlet -Os/As usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co *host team*. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as. +os/as usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co host team. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as. ## Problema diff --git a/translation/gl/patterns/contracted-contributor.md b/translation/gl/patterns/contracted-contributor.md index e3ae04824..7ae509c30 100644 --- a/translation/gl/patterns/contracted-contributor.md +++ b/translation/gl/patterns/contracted-contributor.md @@ -4,7 +4,7 @@ ## Patlet -Os/As socios/as que desexen contribuír a InnerSource son disuadidos/as de facelo polos/as seus/súas superiores/as. Os contratos e acordos formais son un alivio. +os/as socios/as que desexen contribuír a InnerSource son disuadidos/as de facelo polos/as seus/súas superiores/as. Os contratos e acordos formais son un alivio. ## Problema diff --git a/translation/gl/patterns/core-team.md b/translation/gl/patterns/core-team.md index 80b65c711..d630dafdb 100644 --- a/translation/gl/patterns/core-team.md +++ b/translation/gl/patterns/core-team.md @@ -4,7 +4,7 @@ ## Patlet -Incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un *core team* que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do *core team* permite aos/ás contribuidores/as engadir e empregar as funcionalidades que aportan valor aos seus escenarios. +incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un core team que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do core team permítelle aos/ás contribuidores/as engadir e empregar as funcionalidades que achegan valor aos seus escenarios. ## Problema diff --git a/translation/gl/patterns/crossteam-project-valuation.md b/translation/gl/patterns/crossteam-project-valuation.md index 0f8f6e862..4a904499b 100644 --- a/translation/gl/patterns/crossteam-project-valuation.md +++ b/translation/gl/patterns/crossteam-project-valuation.md @@ -4,16 +4,16 @@ Valoración de proxectos entre equipos ## Patlet -É difícil convencer acerca do valor dos proxectos InnerSource desenvolvidos entre equipos que non teñen un impacto directo nos ingresos da empresa. Velaquí unha forma de representar o seu proxecto baseada en datos, que articula o seu valor e amplifícao. +é difícil convencer acerca do valor dos proxectos InnerSource desenvolvidos entre equipos que non teñen un impacto directo nos ingresos da empresa. Velaquí unha forma de representar o seu proxecto baseada en datos, que articula o seu valor e amplifícao. ## Contexto - Vostede é responsable da colaboración entre equipos que serve de plataforma para outros/as traballadores/as da empresa. -- O proxecto de colaboración entre equipos non aporta ningún valor directo aos ingresos da empresa. +- O proxecto de colaboración entre equipos non achega ningún valor directo aos ingresos da empresa. ## Problema -Os proxectos de colaboración entre equipos poden ter un grande impacto na empresa, pero son difíciles de representar mediante datos. En consecuencia, é doado e habitual seguir adiante con proxectos que non aportan valor real ou non inverter suficiente diñeiro, o que, en caso contrario, si aportaría un gran valor. +Os proxectos de colaboración entre equipos poden ter un grande impacto na empresa, pero son difíciles de representar mediante datos. En consecuencia, é doado e habitual seguir adiante con proxectos que non achegan valor real ou non inverter suficiente diñeiro, o que, en caso contrario, si achegaría un gran valor. ## Aspectos que mellorar @@ -29,7 +29,7 @@ O núcleo do valor de todo proxecto de colaboración entre equipos é a idea de ### Explicación -Reúna a un pequeno equipo de expertos/as na materia do seu ámbito. Empregando ese equipo de expertos/as, estime catro aspectos sobre cada consumidor/a da produción do seu proxecto: +Reúna un pequeno equipo de expertos/as na materia do seu ámbito. Empregando ese equipo de expertos/as, estime catro aspectos sobre cada consumidor/a da produción do seu proxecto: - Canto tempo lles leva consumir a produción do seu proxecto? - Canto tempo lles levaría, pola contra, calcular o valor da produción do seu proxecto por si mesmos/as? @@ -38,9 +38,9 @@ Reúna a un pequeno equipo de expertos/as na materia do seu ámbito. Empregando Á hora de facer estas estimacións, é imposible saber con gran precisión canto tempo leva cada actividade. Ese non é o seu obxectivo. En lugar da exactitude, debe esforzarse en ***establecer un límite para delimitar o peor escenario posible*** destas estimacións. -A idea é que o grupo de expertos/as poida dicirse uns/unhas a outros/as: «Non sabemos exactamente canto tempo nos levaría, pero todos/as estamos de acordo en que, *polo menos*, levaríanos este tempo.». Concretamente, debe estimar un tempo *máximo* razoable e tempos *mínimos* razoables para que os/as consumidores/as poidan, por outra parte, improvisar e aplicar as súas propias solucións. +A idea é que no grupo de expertos/as poidan dicirse uns/unhas a outros/as: «Non sabemos exactamente canto tempo nos levaría, pero todos/as estamos de acordo en que, *polo menos* nos levaría este tempo». Concretamente, debe estimar un tempo *máximo* razoable e tempos *mínimos* razoables para que os/as consumidores/as poidan, por outra parte, improvisar e aplicar as súas propias solucións. -Un apunte sobre o custo de idear unha «solución caseira propia»; o custo de pór en marcha unha solución caseira NON é necesariamente (de feito, é moi pouco probable) o mesmo que o de crear unha solución común. A miúdo, para a mesma funcionalidade, a modularidade e a calidade involucradas na creación dunha solución mediante a colaboración entre equipos, fai que sexa unha inversión notablemente maior que unha aplicación rápida e codificada que se emprega só unha vez. +Un apunte sobre o custo de idear unha «solución caseira propia»; o custo de pór en marcha unha solución caseira NON é necesariamente (de feito, é moi pouco probable) o mesmo que o de crear unha solución común. A miúdo, para a mesma funcionalidade, a modularidade e a calidade involucradas na creación dunha solución mediante a colaboración entre equipos, fai que sexa un investimento notablemente maior que unha aplicación rápida e codificada que se emprega só unha vez. ### Fórmula @@ -58,24 +58,24 @@ Unha vez que teña os límites do peor escenario posible, pode valorar o resulta A pesar do seu rigor, este proceso non produce unha forma exacta para medir o resultado nun proxecto de colaboración entre equipos. Na práctica, con todo, brinda un marco mediante o cal pode tomar unha decisión acertada para financiar este traballo. Tras dispor de datos fiables e razoables, de acordo coa explicación anterior, debe financiar as horas de desenvolvemento dedicadas a executar o proxecto ata, **polo menos**, chegar ao nivel máis baixo destes tres niveis seguintes: -1. As horas brutas que se aforraron mediante a fórmula anterior. Posto que todos/as estamos seguros/as de que a fórmula devolveranos unha cifra inferior ao número real de horas aforradas, pode estar seguro/a de que financiar o proxecto é unha vitoria asegurada. -2. A cantidade de tempo que se necesita para apoiar as contribucións InnerSource a proxectos de colaboración entre equipos. Posto que o/a contribuidor/a probablemente tería feito o traballo de tódolos xeitos puntualmente, merece a pena financiar o tempo que se necesita para facilitar que o seu traballo pase a estar nunha arquitectura de información compartida. -3. O que a vostede lle pareza mellor. Un efecto secundario intencionado de dispor dunha fórmula de valoración é que, naturalmente, obriga a medir puntos chave que aportan valor aos/ás consumidores/as. +1. As horas brutas que se aforraron mediante a fórmula anterior. Posto que todos/as estamos seguros/as de que a fórmula nos devolverá unha cifra inferior ao número real de horas aforradas, pode estar seguro/a de que financiar o proxecto é unha vitoria asegurada. +2. A cantidade de tempo que se necesita para apoiar as contribucións InnerSource a proxectos de colaboración entre equipos. Posto que o/a contribuidor/a probablemente tería feito o traballo de todos os xeitos puntualmente, merece a pena financiar o tempo que se necesita para facilitar que o seu traballo pase a estar nunha arquitectura de información compartida. +3. O que a vostede lle pareza mellor. Un efecto secundario intencionado de dispor dunha fórmula de valoración é que, naturalmente, obriga a medir puntos chave que dan valor aos/ás consumidores/as. Esas medicións poden entenderse e consumirse na súa forma bruta para que vostede poida intuír a valía deste proxecto: -Pode que a algúns/algunhas lles preocupe a falta de precisión deste método de valoración. Está ben que este proceso non teña un resultado de medición exacta. Só ten que ser o suficientemente preciso para cumprimentar dous obxectivos: +Pode que a algúns/algunhas lles preocupe a falta de precisión deste método de valoración. Está ben que este proceso non teña un resultado de medición exacta. Só ten que ser o suficientemente preciso para cumprir dous obxectivos: 1. Ofrecer un medio para representar o valor do que está acontecendo a quen organiza e financia o esforzo dos equipos. -2. Axudar aos/ás implicados/as a saber que áreas dos esforzos entre os equipos son máis prioritarias en función do seu valor. +2. Axudar os/as implicados/as a saber que áreas dos esforzos entre os equipos son máis prioritarias en función do seu valor. -Na práctica, sempre que estas valoracións se atopen dentro dunha orde de magnitude da realidade e entre si, son suficientemente precisas para cumprimentar con estes fins. Mellorarán con creces os resultados obtidos respecto das valoracións *ad hoc* (e dos efectos resultantes) descritas na sección **Problema** ao comezo deste documento. +Na práctica, sempre que estas valoracións se atopen dentro dunha orde de magnitude da realidade e entre si, son suficientemente precisas para cumprir con estes fins. Mellorarán de sobra os resultados obtidos respecto das valoracións *ad hoc* (e dos efectos resultantes) descritas na sección **Problema** ao comezo deste documento. ## Contexto resultante -- Medios baseados en datos para debater o valor e a financiación do proxecto de colaboración entre equipos mediante o liderado. +- Medios baseados en datos para debater o valor e financiamento do proxecto de colaboración entre equipos mediante o liderado. - Métricas clave arredor do proxecto de colaboración entre equipos instrumentados en bruto. -- Definir a forma na que o proxecto de colaboración entre equipos aporta valor e como iso adoita producir un maior valor para a empresa. +- Definir a forma na que o proxecto de colaboración entre equipos achegar valor e como iso adoita producir un maior valor para a empresa. - Éxito xeral do proxecto e axitación ao seu redor. ## Exemplos coñecidos @@ -93,7 +93,7 @@ Na práctica, sempre que estas valoracións se atopen dentro dunha orde de magni ## Recoñecementos -- Jeremiah Wright, por ensinarme a considerar os proxectos de colaboración entre equipos como un negocio interno no que a moeda é o tempo dos/as desenvolvedores/as. +- Jeremiah Wright, por ensinarme a considerar os proxectos de colaboración entre equipos como un negocio interno no que a moeda é o tempo dos desenvolvedores/as. ## Tradución diff --git a/translation/gl/patterns/dedicated-community-leader.md b/translation/gl/patterns/dedicated-community-leader.md index 67f4a20c9..d418a78f8 100644 --- a/translation/gl/patterns/dedicated-community-leader.md +++ b/translation/gl/patterns/dedicated-community-leader.md @@ -4,61 +4,61 @@ Líder da comunidade experto/a en InnerSource ## Patlet -Seleccione persoas con habilidades técnicas e de comunicación para liderar as comunidades e garantir o éxito no inicio dunha iniciativa InnerSource +seleccione persoas con habilidades técnicas e de comunicación para liderar as comunidades e garantir o éxito no inicio dunha iniciativa InnerSource ## Problema -Como asegura que a nova iniciativa InnerSource ten ao/á [líder da comunidade](http://www.artofcommunityonline.org/) axeitado/a para que o impacto poida ser maior? +Como asegura que a nova iniciativa InnerSource ten o [líder da comunidade](http://www.artofcommunityonline.org/) axeitado/a para que o impacto poida ser maior? -Ao seleccionar ás persoas coas habilidades erróneas e/ou non proporcionarlles a capacitación suficiente arríscase a desperdiciar esforzos e, en última instancia, a que a nova iniciativa InnerSource fracase. +Ao seleccionar a persoas coas habilidades erróneas e/ou non proporcionarlles a capacitación suficiente, arríscase a desperdiciar esforzos e, en última instancia, a que a nova iniciativa InnerSource fracase. ## Historia -Considere o seguinte escenario. Unha empresa quere comezar unha iniciativa InnerSource para fomentar a colaboración fóra dos límites da organización. A empresa decidiu comezar cunha fase experimental de alcance limitado. O persoal directivo foi escollendo un tema piloto axeitado para a primeira comunidade InnerSource e espera contribucións de moitas áreas de negocio de toda a organización. A empresa nomeou a un/unha novo/a traballador/a para dirixir a comunidade durante o 50 % do seu tempo de traballo, porque aínda non estaba planificado ao 100 %. Despois de seis meses, a comunidade recibiu só unhas poucas contribucións, a maioría das cales proveñen só dunha unidade de negocio. A empresa substitúe ao/á seu/súa líder da comunidade por alguén cunha maior traxectoria na empresa, esta vez só durante un 30 % do seu tempo. Ao cabo doutros seis meses, o número de contribucións aumenta só lixeiramente. +Considere o seguinte escenario. Unha empresa quere comezar unha iniciativa InnerSource para fomentar a colaboración fóra dos límites da organización. A empresa decidiu comezar cunha fase experimental de alcance limitado. O persoal directivo foi escollendo un tema piloto axeitado para a primeira comunidade InnerSource e espera contribucións de moitas áreas de negocio de toda a organización. A empresa nomeou un/unha novo/a traballador/a para dirixir a comunidade durante o 50 % do seu tempo de traballo, porque aínda non estaba planificado ao 100 %. Despois de seis meses, a comunidade recibiu só unhas poucas contribucións, a maioría das cales proveñen só dunha unidade de negocio. A empresa substitúe o seu/súa líder da comunidade por alguén cunha maior traxectoria na empresa, esta vez só durante un 30 % do seu tempo. Ao cabo doutros seis meses, o número de contribucións aumenta só lixeiramente. ## Contexto - A empresa é grande e antiga. Non ten experiencia previa en software libre ou outros modelos de traballo colaborativo. A cultura da empresa caracterízase por un estilo de xestión clásico de arriba cara abaixo: xeralmente está en desacordo coa cultura da comunidade. - Aínda que hai paritarios/as e un/unha patrocinador/a no alto cargo, aos/ás responsables de área da empresa non lles entusiasma InnerSource. -- Non se conseguiu convencer á dirección para que aportase máis ca un presuposto limitado para financiar unicamente a un/unha líder da comunidade a tempo parcial. +- Non se conseguiu convencer a dirección para que achegase máis ca un presuposto limitado para financiar unicamente un/unha líder da comunidade a tempo parcial. - O/A líder da comunidade seleccionado/a inicialmente ten pouca ou ningunha experiencia previa co modelo de traballo de software libre. - O/A desenvolvedor/a seleccionado/a como líder da comunidade inicialmente non conta cunha ampla rede de contactos dentro da empresa. ## Aspectos que mellorar -Se unha empresa non inverte de xeito significativo na comunidade inicial de InnerSource en termos de presuposto e de capacitación, a credibilidade do seu compromiso coa iniciativa podería parecer cuestionable. O impulso común dunha empresa cunha cultura de xestión tradicional ante un proxecto ou iniciativa que non funciona como se esperaba, será a de substituír ao/á seu/súa líder. Facer isto sen involucrar á comunidade e sen seguir os principios meritocráticos, socavará aínda máis o compromiso da empresa con InnerSource ao pór de manifesto a fricción existente entre a cultura actual da empresa e a cultura obxectivo: a cultura comunitaria. +Se unha empresa non inviste de xeito significativo na comunidade inicial de InnerSource en termos de presuposto e de capacitación, a credibilidade do seu compromiso coa iniciativa podería parecer cuestionable. O impulso común dunha empresa cunha cultura de xestión tradicional ante un proxecto ou iniciativa que non funciona como se esperaba, será a de substituír o seu/súa líder. Facer isto sen involucrar a comunidade e sen seguir os principios meritocráticos, socavará aínda máis o compromiso da empresa con InnerSource ao pór de manifesto a fricción existente entre a cultura actual da empresa e a cultura obxectivo: a cultura comunitaria. -A aportación do valor dos proxectos InnerSource non resultará evidente para o persoal directivo que está inmerso nos métodos tradicionais de xestión de proxectos. É menos probable que o persoal directivo asigne a unha persoa de alto cargo, que xeralmente ten unha gran demanda de proxectos que non son InnerSource, a un proxecto InnerSource que ocuparía unha parte significativa da súa xornada de traballo. +A achega de do valor dos proxectos InnerSource non resultará evidente para o persoal directivo que está inmerso nos métodos tradicionais de xestión de proxectos. É menos probable que o persoal directivo lle asigne a unha persoa de alto cargo, que xeralmente ten unha gran demanda de proxectos que non son InnerSource, a un proxecto InnerSource que ocuparía unha parte significativa da súa xornada de traballo. A meirande parte do traballo diario dun/dunha líder da comunidade ocúpao na comunicación. Do mesmo xeito, é probable que tamén teña que encabezar un desenvolvemento inicial. Ante a capacidade limitada, os/as líderes sen experiencia tenderán a centrarse no desenvolvemento e descoidar a comunicación. A barreira para que os/as posibles contribuidores/as fagan a súa primeira contribución e se comprometan coa comunidade será moito maior se non é doado contactar co/coa líder da comunidade ou se tarda en dar retroalimentación e responder a preguntas por falta de tempo. Ademais, os/as líderes inexpertos/as no ámbito técnico probablemente terán máis dificultades para atraer e reter contribuidores/as con moita experiencia, das que tería un/unha líder cun alto desempeño e grao de visibilidade dentro da empresa. Se unha comunidade non pode crecer o suficientemente rápido e alcanzar a velocidade suficiente, é probable que non poida demostrar de maneira convincente o potencial de InnerSource. -Se a empresa selecciona a un/unha responsable de área con experiencia que está empapado/a dos métodos de xestión tradicionais para que sexa o/a líder da comunidade, é probable que este/a se centre en temas de xestión tradicionais como a asignación de recursos, a provisión dunha estrutura e as canles de información; na contra de liderar co exemplo a través de principios meritocráticos. Isto socavaría a credibilidade da iniciativa InnerSource aos ollos dos/as desenvolvedores/as. +Se a empresa selecciona un/unha responsable de área con experiencia que está empapado/a dos métodos de xestión tradicionais para que sexa o/a líder da comunidade, é probable que este/a se centre en temas de xestión tradicionais como a asignación de recursos, a provisión dunha estrutura e as canles de información; na contra de liderar co exemplo a través de principios meritocráticos. Isto socavaría a credibilidade da iniciativa InnerSource aos ollos dos desenvolvedores/as. ## Solución -Seleccione a un/unha líder da comunidade que: +Seleccione un/unha líder da comunidade que: - Teña experiencia no modelo de traballo de software libre ou modelos de traballo baseados na comunidade que sexan similares. -- Que teña habilidades brandas necesarias para actuar coma un/unha auténtico/a líder. +- Que teña habilidades brandas necesarias para actuar como un/unha auténtico/a líder. - Que predique co exemplo e así xustifique a súa posición na meritocracia comunitaria. - Que sexa un/unha excelente *networker*. -- Que inspire aos membros da comunidade. +- Que inspire os membros da comunidade. - Que poida comunicarse de maneira efectiva tanto coa xerencia executiva como cos/coas desenvolvedores/as. - Que sexa capaz de xestionar aspectos administrativos do traballo colaborativo. -Apoderar ao/á líder da comunidade para que dedique o 100 % do seu tempo ao traballo comunitario, incluíndo a comunicación e o desenvolvemento. Informar á xerencia sobre a necesidade de ter en conta os puntos de vista da comunidade ao xerar un cambio na xestión comunitaria. No mellor dos casos, apoderar á comunidade para que eles/as mesmos/as nomeen a un/unha líder da comunidade. +Apoderar o/a líder da comunidade para que dedique o 100 % do seu tempo ao traballo comunitario, incluíndo a comunicación e o desenvolvemento. Informar a xerencia sobre a necesidade de ter en conta os puntos de vista da comunidade ao xerar un cambio na xestión comunitaria. No mellor dos casos, apoderar a comunidade para que eles/as mesmos/as nomeen un/unha líder da comunidade. ## Contexto resultante -Un/Unha líder da comunidade coas prioridades descritas anteriormente dará a cara e encarnará o compromiso da empresa con InnerSource. Así será máis probable que outros/as socios/as da súa rede sigan o seu exemplo e contribúan a InnerSource. Co tempo, o/a líder da comunidade poderá crear un *core team* estable de desenvolvedores/as e, por tanto, aumentar as posibilidades de éxito do proxecto InnerSource. Ao convencer a un público o suficientemente amplo dentro da súa empresa do potencial de InnerSource, contribuirá a cambiar a cultura da empresa vixente por unha cultura comunitaria. +Un/unha líder da comunidade coas prioridades descritas anteriormente dará a cara e encarnará o compromiso da empresa con InnerSource. Así será máis probable que outros/as socios/as da súa rede sigan o seu exemplo e contribúan a InnerSource. Co tempo, o/a líder da comunidade poderá crear un *core team* estable de desenvolvedores/as e, por tanto, aumentar as posibilidades de éxito do proxecto InnerSource. Ao convencer un público o suficientemente amplo dentro da súa empresa do potencial de InnerSource, contribuirá a cambiar a cultura da empresa vixente por unha cultura comunitaria. Contar con excelentes líderes da comunidade especializados/as é unha condición previa para o éxito de InnerSource. Con todo, non é unha solución milagrosa. InnerSource abrangue moitos retos que superan o que un/unha líder da comunidade pode abordar, como son os retos presupostarios, xurídicos, fiscais e outros retos organizativos. ## Exemplos coñecidos -- BIOS en Robert Bosch GmbH: Teña en conta que InnerSource en Bosch estivo dirixido maioritariamente a aumentar a innovación de gran magnitude ao encargarse de produtos de revestimento interno. Actualmente, este modelo non se está a empregar en Bosch por mor da falta de financiación. +- BIOS en Robert Bosch GmbH: Teña en conta que InnerSource en Bosch estivo dirixido maioritariamente a aumentar a innovación de gran magnitude ao encargarse de produtos de revestimento interno. Actualmente, este modelo non se está a empregar en Bosch por mor da falta de financiamento. ## Título alternativo diff --git a/translation/gl/patterns/document-your-guiding-principles.md b/translation/gl/patterns/document-your-guiding-principles.md index a322c78f0..e7ba0946d 100644 --- a/translation/gl/patterns/document-your-guiding-principles.md +++ b/translation/gl/patterns/document-your-guiding-principles.md @@ -4,7 +4,7 @@ Documente os seus principios reitores ## Patlet -A explicación habitual de InnerSource baseada en «aplicar as mellores prácticas de software libre dentro dunha organización» non funciona correctamente coas persoas que carecen de experiencia con software libre. Como solución, os principios InnerSource máis importantes documéntanse e publícanse de maneira aberta. +a explicación habitual de InnerSource baseada en «aplicar as mellores prácticas de software libre dentro dunha organización» non funciona correctamente coas persoas que carecen de experiencia con software libre. Como solución, os principios InnerSource máis importantes documéntanse e publícanse de maneira aberta. ## Problema diff --git a/translation/gl/patterns/extensions-for-sustainable-growth.md b/translation/gl/patterns/extensions-for-sustainable-growth.md index bb6c7180f..6184755d2 100644 --- a/translation/gl/patterns/extensions-for-sustainable-growth.md +++ b/translation/gl/patterns/extensions-for-sustainable-growth.md @@ -4,7 +4,7 @@ Extensións para o crecemento sostible ## Patlet -Un proxecto InnerSource está a recibir demasiadas contribucións, o que dificulta o seu mantemento. Os/As responsables ofrecen un mecanismo de extensión fóra do proxecto principal, que permite escalar as capacidades do proxecto cun custo e gastos xerais de mantemento mínimos. +un proxecto InnerSource está a recibir demasiadas contribucións, o que dificulta o seu mantemento. Os/As responsables ofrecen un mecanismo de extensión fóra do proxecto principal, que permite escalar as capacidades do proxecto cun custo e gastos xerais de mantemento mínimos. ## Problema diff --git a/translation/gl/patterns/gig-marketplace.md b/translation/gl/patterns/gig-marketplace.md index c50a15a3b..20420de6b 100644 --- a/translation/gl/patterns/gig-marketplace.md +++ b/translation/gl/patterns/gig-marketplace.md @@ -4,7 +4,7 @@ ## Patlet -Establécese un *marketplace* mediante a creacion dunha intranet que enumere as necesidades específicas do proxecto InnerSource como «*Gigs*», con requisitos explícitos de tempo e habilidades. Isto permitirá ao personal directivo comprender mellor o compromiso no tempo e os beneficios profesionais dos/as seus/súas traballadores/as, o que aumentará a probabilidade de obter a aprobación para realizar contribucións InnerSource. +establécese un marketplace mediante a creacion dunha intranet que enumere as necesidades específicas do proxecto InnerSource como «Gigs», con requisitos explícitos de tempo e habilidades. Isto permitiralle ao personal directivo comprender mellor o compromiso no tempo e os beneficios profesionais dos seus/súas traballadores/as, o que aumentará a probabilidade de obter a aprobación para realizar contribucións InnerSource. ## Problema diff --git a/translation/gl/patterns/group-support.md b/translation/gl/patterns/group-support.md index e2970c165..d5df6c20b 100644 --- a/translation/gl/patterns/group-support.md +++ b/translation/gl/patterns/group-support.md @@ -4,7 +4,7 @@ Soporte grupal ## Patlet -Que acontece se un equipo ou unha persoa abandona un proxecto InnerSource? Para manter vivo o proxecto fórmase un novo grupo de colaboradores/as interesados/as. +que acontece se un equipo ou unha persoa abandona un proxecto InnerSource? Para manter vivo o proxecto fórmase un novo grupo de colaboradores/as interesados/as. ## Problema diff --git a/translation/gl/patterns/innersource-license.md b/translation/gl/patterns/innersource-license.md index 2e49e6f75..3a13891a2 100644 --- a/translation/gl/patterns/innersource-license.md +++ b/translation/gl/patterns/innersource-license.md @@ -4,13 +4,13 @@ Licenza InnerSource ## Patlet -Dúas entidades xurídicas que pertencen á mesma organización queren compartir o código fonte do software entre elas, mais preocúpanlles as implicacións en termos de responsabilidades legais ou de contabilidade entre as empresas. +dúas entidades xurídicas que pertencen á mesma organización queren compartir o código fonte do software entre elas, mais preocúpanlles as implicacións en termos de responsabilidades legais ou de contabilidade entre as empresas. -Unha **licenza InnerSource** proporciona un marco legal reutilizable para compartir o código fonte dentro da organización. Isto abre novas opcións de colaboración e fai explícitos os dereitos e obrigas das persoas xurídicas implicadas. +Unha **licenza InnerSource** proporciona un marco legal reutilizable para compartir o código fonte dentro da organización. Isto abre novas opcións de colaboración e fai explícitos os dereitos e as obrigas das persoas xurídicas implicadas. ## Problema -Cando dúas ou máis entidades xurídicas dentro dunha organización queren compartir código entre elas, necesitan un acordo sobre os termos e moitas veces un contrato legal. Crear tales acordos en base ao proxecto require esforzo e xera unha barreira para compartir; isto é, un equipo dunha entidade xurídica pode decidir non compartir o seu código fonte con outra entidade xurídica da organización por parecer complicado. +Cando dúas ou máis entidades xurídicas dentro dunha organización queren compartir código entre elas, necesitan un acordo sobre os termos e moitas veces un contrato legal. Crear tales acordos con base no proxecto require esforzo e xera unha barreira para compartir; isto é, un equipo dunha entidade xurídica pode decidir non compartir o seu código fonte con outra entidade xurídica da organización por parecer complicado. As barreiras para compartir poden levar a silos e duplicación de esforzos na reconstrución de solucións similares en varias partes da organización. @@ -20,7 +20,7 @@ No momento de compartir o código fonte, non se pode prever de forma fiable cal - Cando unha grande organización con moitas entidades xurídicas (filiais) crece, o valor do modelo en que estas queren compartir código aumenta. - Por definición, as entidades xurídicas teñen os seus propios dereitos e obrigas legais. -- Varias destas entidades xurídicas están a desenvolver software e empregan os servizos doutras entidades xurídicas. De xeito que existe unha motivación para contribuír ao código fonte do/a outro/a. +- Varias destas entidades xurídicas están a desenvolver software e empregan os servizos doutras entidades xurídicas. De xeito que existe unha motivación para contribuír ao código fonte do/da outro/a. - Suficiente complexidade da organización e da súa estrutura. ## Aspectos que mellorar @@ -28,7 +28,7 @@ No momento de compartir o código fonte, non se pode prever de forma fiable cal - **Nivel de esforzo.** Necesario para redactar acordos formais, especialmente se teñen que ter en conta perspectivas técnicas, legais e empresariais. - **Regulacións internas.** Unha organización grande (formada por moitas entidades xurídicas) ten moitas regulacións internas. Calquera acordo novo terá que cumprir as normativas de, por exemplo, seguridade, privacidade, procesos de contratación etc. O volume das regulacións pode dificultar a valoración de se o uso compartido de software entre dúas entidades xurídicas cumpre coa normativa, especialmente cando non existe un procedemento normalizado. - **Modelo de negocio.** Deberase discernir se algunha das entidades xurídicas da organización ten un modelo de negocio que depende do código propietario e da contabilidade dos custos de licenza dentro da organización. -- **Cultura da empresa.** Non acostuma a colaborar e compartir código de InnerSource. Isto provoca incerteza sobre os dereitos e obrigas cando se emprega código compartido. +- **Cultura da empresa.** Non acostuma a colaborar e compartir código de InnerSource. Isto provoca incerteza sobre os dereitos e as obrigas cando se emprega código compartido. - A liberdade de usar o software leva á competencia e á difusión da propiedade. - Existen contratos legais para cubrir o feito de compartir o código fonte. Estes contratos non están estandarizados, polo que crean un esforzo adicional na negociación e comprensión de cada proxecto. Os contratos existentes tamén poderían non permitir compartir o código fonte nun sentido o suficientemente aberto como para apoiar un verdadeiro enfoque InnerSource. - Alternativamente, non hai contratos legais en vigor, pero o código fonte compártese de forma informal. Isto pode xerar incerteza nos casos en que se precisa claridade sobre a propiedade e os dereitos e obrigas. @@ -45,9 +45,9 @@ A licenza está escrita como un documento legal formal e pódese utilizar como p Coa licenza InnerSource temos unha ferramenta para compartir código entre entidades xurídicas dentro da nosa organización. -A licenza simplifica as conversas dentro da organización sobre o feito de compartir o código fonte, e xa está a motivar ás primeiras entidades xurídicas a facelo. +A licenza simplifica as conversas dentro da organización sobre o feito de compartir o código fonte, e xa está a motivar as primeiras entidades xurídicas a facelo. -**Nota**: O experimento descrito nos **Exemplos coñecidos** atópase nunha fase inicial. Polo tanto, aínda non se formou un **Contexto resultante** firme. Nun par de meses, con efectos máis claros da licenza InnerSource neste espazo problemático, poderase actualizar. +**Nota**: o experimento descrito nos **Exemplos coñecidos** atópase nunha fase inicial. Polo tanto, aínda non se formou un **Contexto resultante** firme. Nun par de meses, con efectos máis claros da licenza InnerSource neste espazo problemático, poderase actualizar. ## Exemplos coñecidos @@ -84,8 +84,8 @@ Paga a pena mencionar que, ata agora, o software compartido baixo esta licenza I ## Glosario -- **Organización**: Un paraugas para varias entidades xurídicas. (Sinónimos: grupo, empresa. Por exemplo, Lufthansa.). -- **Entidade xurídica**: Unha entidade que ten os seus propios dereitos e obrigas legais. (Sinónimos: empresa, filial. Por exemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH etc). +- **Organización**: un paraugas para varias entidades xurídicas. (Sinónimos: grupo, empresa. Por exemplo, Lufthansa.). +- **Entidade xurídica**: unha entidade que ten os seus propios dereitos e obrigas legais. (Sinónimos: empresa, filial. Por exemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH etc). ## Tradución diff --git a/translation/gl/patterns/innersource-portal.md b/translation/gl/patterns/innersource-portal.md index 922ce5dc4..a503d3cd7 100644 --- a/translation/gl/patterns/innersource-portal.md +++ b/translation/gl/patterns/innersource-portal.md @@ -4,7 +4,7 @@ Portal InnerSource ## Patlet -Os/As contribuidores/as potenciais non poden descubrir dun xeito sinxelo os proxectos InnerSource nos que están interesados/as. Ao crear unha intranet que indexe toda a información dispoñible do proxecto InnerSource, permítese que os/as contribuidores/as coñezan os proxectos que lles poderían interesar; do mesmo xeito que lles serve aos/ás *project owners* de InnerSource para atraer a un público externo. +os/as contribuidores/as potenciais non poden descubrir dun xeito sinxelo os proxectos InnerSource nos que están interesados/as. Ao crear unha intranet que indexe toda a información dispoñible do proxecto InnerSource, permítese que os/as contribuidores/as coñezan os proxectos que lles poderían interesar; do mesmo xeito que lles serve aos/ás project owners de InnerSource para atraer a un público externo. ## Problema @@ -14,11 +14,11 @@ Os proxectos InnerSource da súa organización están en aumento, pero os/as pos ## Historia -Está tentando establecer unha práctica InnerSource dentro da súa organización. Coñece algúns proxectos que se executan mediante un modelo InnerSource, pero a súa existencia só se comunica a través do boca en boca, o correo electrónico ou conversas privadas con outros/as empregados/as. Como resultado, os/as *project owners* de InnerSource teñen dificultades para atraer aos/ás contribuidores/as. +Está tentando establecer unha práctica InnerSource dentro da súa organización. Coñece algúns proxectos que se executan mediante un modelo InnerSource, pero a súa existencia só se comunica a través do boca en boca, o correo electrónico ou conversas privadas con outros/as empregados/as. Como resultado, os/as *project owners* de InnerSource teñen dificultades para atraer os/as contribuidores/as. -Non hai un recurso de acceso único e compartido para os/as empregados/as de toda a organización que lles permita descubrir facilmente tódolos proxectos InnerSource en curso. Isto está a limitar dun xeito importante o potencial de crecemento de cada proxecto InnerSource. +Non hai un recurso de acceso único e compartido para os/as empregados/as de toda a organización que lles permita descubrir facilmente todos os proxectos InnerSource en curso. Isto está a limitar dun xeito importante o potencial de crecemento de cada proxecto InnerSource. -Que se pode facer para axudar a que tódolos proxectos de InnerSource eleven a súa visibilidade a un público tan grande como sexa posible e poidan atraer contribuidores/as de toda a organización? +Que se pode facer para axudar a que todos os proxectos de InnerSource eleven a súa visibilidade a un público tan grande como sexa posible e poidan atraer contribuidores/as de toda a organización? ## Contexto @@ -37,7 +37,7 @@ Que se pode facer para axudar a que tódolos proxectos de InnerSource eleven a s * Non se está a conseguir todo o potencial de equipos separados de enxeñaría para colaborar en desafíos compartidos. * É difícil que os individuos descubran que proxectos InnerSource existen. -* É difícil para os/as *project owners* de InnerSource atraer a un público de contribuidores/as externos/as. +* É difícil para os/as *project owners* de InnerSource atraer un público de contribuidores/as externos/as. ## Solucións @@ -45,22 +45,22 @@ Que se pode facer para axudar a que tódolos proxectos de InnerSource eleven a s As propiedades chave do portal poden ser: -* As persoas visitantes do portal InnerSource deberían poder ver tódolos proxectos dispoñibles e buscar proxectos específicos en función de varios criterios, como o nome do proxecto, as tecnoloxías en uso, os nomes dos/as contribuidores/as, a área empresarial patrocinadora etc. -* A información que se mostra a través do portal InnerSource debe estar baixo o control total dos/as *project owners* de InnerSource en todo momento. E, preferiblemente, esta información obterase directamente dun ficheiro de datos específico ou metadatos almacenados no propio repositorio do proxecto. -* Os/As *project owners* deben incluír toda a información relevante sobre os seus proxectos nos ficheiros de datos; e engadir o nome do proxecto, os nomes dos/as *trusted contributors*, unha breve descrición e ligazóns ao repositorio de código ou calquera documentación do soporte. -* (Opcional) Aínda que a meirande parte das organizacións escollerán facer o seu portal dispoñible só na súa intranet, algunhas outras optaron por deixalo dispoñible na internet pública. Esta última opción pode ser interesante para as organizacións que queiran mostrar información adicional sobre o seu enfoque InnerSource no seu portal; por exemplo, con fins corporativos e de contratación. +* As persoas visitantes do portal InnerSource deberían poder ver todos os proxectos dispoñibles e buscar proxectos específicos en función de varios criterios, como o nome do proxecto, as tecnoloxías en uso, os nomes dos contribuidores/as, a área empresarial patrocinadora etc. +* A información que se mostra a través do portal InnerSource debe estar baixo o control total dos *project owners* de InnerSource en todo momento. E, preferiblemente, esta información obterase directamente dun ficheiro de datos específico ou de metadatos almacenados no propio repositorio do proxecto. +* Os/As *project owners* deben incluír toda a información relevante sobre os seus proxectos nos ficheiros de datos; e engadir o nome do proxecto, os nomes dos *trusted contributors*, unha breve descrición e ligazóns ao repositorio de código ou calquera documentación do soporte. +* (Opcional) Aínda que a meirande parte das organizacións escollerá facer o seu portal dispoñible só na súa intranet, algunhas outras optaron por deixalo dispoñible na internet pública. Esta última opción pode ser interesante para as organizacións que queiran mostrar información adicional sobre o seu enfoque InnerSource no seu portal; por exemplo, con fins corporativos e de contratación. No lanzamento do portal debe terse en consideración unha campaña de comunicación que promova a suma de ficheiros InnerSource de datos ou metadatos aos repositorios de código, para reforzar o número de proxectos que se mostran no portal. -Unha [implantación de referencia](https://github.com/SAP/project-portal-for-innersource) dun portal InnerSource está dispoñible en GitHub e aberta ás contribucións. Enumera tódolos proxectos InnerSource dunha organización dun xeito interactivo e fácil de usar. Os proxectos poden autorrexistrarse a partir dun tema dedicado de GitHub e proporcionar metadatos adicionais. +Unha [implantación de referencia](https://github.com/SAP/project-portal-for-innersource) dun portal InnerSource está dispoñible en GitHub e aberta ás contribucións. Enumera todos os proxectos InnerSource dunha organización dun xeito interactivo e fácil de usar. Os proxectos poden autorrexistrarse a partir dun tema dedicado de GitHub e proporcionar metadatos adicionais. ![Exemplo de portal InnerSource](../../../assets/img/portal-overview.png "Exemplo de portal InnerSource") ## Contexto resultante -* O portal InnerSource permitiu aos/ás *project owners* anunciar os seus proxectos a toda a organización. Debido a esta maior visibilidade, están a atraer comunidades de contribuidores/as moito máis grandes que nunca antes. -* Para aqueles/as que buscan involucrarse en proxectos InnerSource, o portal InnerSource permitiulles descubrir exactamente o tipo de oportunidades que lles interesan ou poder buscar de maneira simultánea entre tódolos proxectos InnerSource dispoñibles, en función dos seus criterios específicos. -* Satisfacer as necesidades destes dous tipos de audiencia axudou a establecer InnerSource como unha opción viable e atractiva para que tódalas áreas da organización poidan chegar a logros comúns que non poderían alcanzar por separado. +* O portal InnerSource permitiulles aos/ás *project owners* anunciar os seus proxectos a toda a organización. Debido a esta maior visibilidade, están a atraer comunidades de contribuidores/as moito máis grandes que nunca antes. +* Para aqueles/as que buscan involucrarse en proxectos InnerSource, o portal InnerSource permitiulles descubrir exactamente o tipo de oportunidades que lles interesan ou poder buscar de maneira simultánea entre todos os proxectos InnerSource dispoñibles, en función dos seus criterios específicos. +* Satisfacer as necesidades destes dous tipos de audiencia axudou a establecer InnerSource como unha opción viable e atractiva para que todas as áreas da organización poidan chegar a logros comúns que non poderían alcanzar por separado. ## Exemplos coñecidos diff --git a/translation/gl/patterns/issue-tracker.md b/translation/gl/patterns/issue-tracker.md index f605d6b23..350234385 100644 --- a/translation/gl/patterns/issue-tracker.md +++ b/translation/gl/patterns/issue-tracker.md @@ -4,7 +4,7 @@ Casos de uso cun sistema de seguimento de incidencias ## Patlet -O *host team* de InnerSource non logra ter transparencia nos plans nin no progreso, e tampouco no contexto para os cambios. Isto resólvese aumentando os casos de uso co sistema de seguimento de incidencias do proxecto para que tamén favoreza o intercambio de ideas, o debate sobre estas e o deseño de funcionalidades. +o host team de InnerSource non logra ter transparencia nos plans nin no progreso, e tampouco no contexto para os cambios. Isto resólvese aumentando os casos de uso co sistema de seguimento de incidencias do proxecto para que tamén favoreza o intercambio de ideas, o debate sobre estas e o deseño de funcionalidades. ## Problema diff --git a/translation/gl/patterns/maturity-model.md b/translation/gl/patterns/maturity-model.md index 420cc3423..0d7f3d504 100644 --- a/translation/gl/patterns/maturity-model.md +++ b/translation/gl/patterns/maturity-model.md @@ -4,7 +4,7 @@ Modelo de madurez ## Patlet -Os equipos comezaron a adoptar InnerSource e a práctica estase estendendo a varios departamentos. Con todo, a comprensión do que constitúe un proxecto InnerSource varía. A solución consiste en proporcionar un modelo de madurez que permita aos equipos realizar unha autoavaliación e descubrir modelos e prácticas que aínda non coñecían. +os equipos comezaron a adoptar InnerSource e a práctica estase estendendo a varios departamentos. Con todo, a comprensión do que constitúe un proxecto InnerSource varía. A solución consiste en proporcionar un modelo de madurez que lles permita aos equipos realizar unha autoavaliación e descubrir modelos e prácticas que aínda non coñecían. ## Problema diff --git a/translation/gl/patterns/repository-activity-score.md b/translation/gl/patterns/repository-activity-score.md index 97775291f..6deea9349 100644 --- a/translation/gl/patterns/repository-activity-score.md +++ b/translation/gl/patterns/repository-activity-score.md @@ -4,7 +4,7 @@ Cualificación da actividade do repositorio ## Patlet -Os/As potenciais contribuidores/as queren atopar proxectos InnerSource activos que precisen da súa participación. Ao calcular a cualificación da actividade do repositorio para cada proxecto, pódese crear unha listaxe clasificada de proxectos (por exemplo, no [portal InnerSource](./innersource-portal.md)) para que os/as posibles contribuidores/as poidan determinar dun xeito máis doado en que proxecto desexan colaborar. +os/as potenciais contribuidores/as queren atopar proxectos InnerSource activos que precisen da súa participación. Ao calcular a cualificación da actividade do repositorio para cada proxecto, pódese crear unha listaxe clasificada de proxectos (por exemplo, no portal InnerSource) para que os/as posibles contribuidores/as poidan determinar dun xeito máis doado en que proxecto desexan colaborar. ## Problema diff --git a/translation/gl/patterns/review-committee.md b/translation/gl/patterns/review-committee.md index 993978f6e..136806170 100644 --- a/translation/gl/patterns/review-committee.md +++ b/translation/gl/patterns/review-committee.md @@ -4,7 +4,7 @@ Comité de revisión ## Patlet -O modelo de traballo InnerSource é un afastamento radical dos enfoques máis tradicionais, tanto para os/as desenvolvedores/as como para os/as seus/súas superiores/as. Ao establecer un comité de revisión como interface entre a iniciativa InnerSource e tódolos altos cargos das áreas empresariais que participan nela, é máis probable que estes últimos se familiaricen coa iniciativa e a apoien; xa que lles brinda un certo nivel de supervisión e control, sen fomentar a microxestión. +o modelo de traballo InnerSource é un afastamento radical dos enfoques máis tradicionais, tanto para os/as desenvolvedores/as como para os/as seus/súas superiores/as. Ao establecer un comité de revisión como interface entre a iniciativa InnerSource e todos os altos cargos das áreas empresariais que participan nela, é máis probable que estes últimos se familiaricen coa iniciativa e a apoien; xa que lles brinda un certo nivel de supervisión e control, sen fomentar a microxestión. ## Problema diff --git a/translation/gl/patterns/service-vs-library.md b/translation/gl/patterns/service-vs-library.md index a9d27ad05..961f325a7 100644 --- a/translation/gl/patterns/service-vs-library.md +++ b/translation/gl/patterns/service-vs-library.md @@ -4,7 +4,7 @@ Servizo vs. libraría ## Patlet -Os equipos DevOps poden ser reticentes a traballar máis alá dos límites do equipo, en bases de código comúns; posto que non está definido quen sería a persoa responsable de responder ante unha situación de inactividade do servizo. Con frecuencia, a solución pode ser implantar o mesmo servizo en contextos independentes con cadeas de escalada separadas, en caso de caída do servizo ou de factorización dunha gran cantidade de código compartido nunha libraría na que se poidan facer colaboracións. +os equipos DevOps poden ser reticentes a traballar máis alá dos límites do equipo, en bases de código comúns; posto que non está definido quen sería a persoa responsable de responder ante unha situación de inactividade do servizo. Con frecuencia, a solución pode ser implantar o mesmo servizo en contextos independentes con cadeas de escalada separadas, en caso de caída do servizo ou de factorización dunha gran cantidade de código compartido nunha libraría na que se poidan facer colaboracións. ## Problema diff --git a/translation/gl/patterns/start-as-experiment.md b/translation/gl/patterns/start-as-experiment.md index 5a69accf0..e1e39fc11 100644 --- a/translation/gl/patterns/start-as-experiment.md +++ b/translation/gl/patterns/start-as-experiment.md @@ -4,21 +4,21 @@ Comece como un experimento ## Patlet -Comece a súa iniciativa InnerSource como un experimento de tempo limitado para facilitar que o persoal directivo, que non estea familiarizado con InnerSource, secunde e apoie a iniciativa. +comece a súa iniciativa InnerSource como un experimento de tempo limitado para facilitar que o persoal directivo, que non estea familiarizado con InnerSource, secunde e apoie a iniciativa. ## Problema -A empresa considera adoptar unha iniciativa InnerSource pero non se pon en marcha porque a dirección non está segura do seu resultado e, polo tanto, non está disposta a comprometerse cunha inversión. +A empresa considera adoptar unha iniciativa InnerSource pero non se pon en marcha porque a dirección non está segura do seu resultado e, polo tanto, non está disposta a comprometerse cun investimento. ## Contexto -A empresa está a considerar a aplicación de InnerSource para aumentar a eficiencia da colaboración nos proxectos de software. Porén, a maioría do persoal directivo non está familiarizado co modelo de traballo do Sistema de software libre e, en cambio, están acostumados a unha xestión xerárquica de arriba cara abaixo. A iniciativa InnerSource é moi popular entre os/as desenvolvedores/as de software da empresa, sobre todo porque moitos/as deles/as xa a están a empregar ou porque están a desenvolver de maneira activa o software libre. +A empresa está a considerar a aplicación de InnerSource para aumentar a eficiencia da colaboración nos proxectos de software. Porén, a maioría do persoal directivo non está familiarizado co modelo de traballo do sistema de software libre e, en cambio, están acostumados a unha xestión xerárquica de arriba cara abaixo. A iniciativa InnerSource é moi popular entre os/as desenvolvedores/as de software da empresa, sobre todo porque moitos/as deles/as xa a están a empregar ou porque están a desenvolver de maneira activa o software libre. ## Aspectos que mellorar -- A dirección procurará verificar as afirmacións arredor das melloras na colaboración mediante InnerSource antes de realizar unha inversión a longo prazo. Isto, xeralmente, implica medir as melloras. -- No caso de que sexa probable que a iniciativa InnerSource teña unha grande aceptación entre os/as desenvolvedores/as e que moitos proxectos dependan dela, a decisión de eliminala tería mala acollida e, polo tanto, sería unha decisión difícil de tomar. A percepción de perda de control resultante podería disuadir a algún/algunha directivo/a de tan sequera comezar a implantar InnerSource. -- A implantación de modelos de traballo ao estilo InnerSource adoitan supor un cambio radical con respecto aos modelos de traballo que se empregaban anteriormente. Polo tanto, é probable que os procesos obrigatorios existentes xa non sexan aplicables e que os procesos de goberno tampouco sexan apropiados. O resultado podería ser que a empresa teña que operar cun regulamento que se atope en terra de ninguén desde o punto de vista xurídico. Como, por exemplo, no caso das regulacións relacionadas co control de taxas e exportacións en grandes corporacións con múltiples entidades xurídicas en múltiples países. +- A dirección procurará verificar as afirmacións arredor das melloras na colaboración mediante InnerSource antes de realizar un investimento a longo prazo. Isto, xeralmente, implica medir as melloras. +- No caso de que sexa probable que a iniciativa InnerSource teña unha grande aceptación entre os/as desenvolvedores/as e que moitos proxectos dependan dela, a decisión de eliminala tería mala acollida e, polo tanto, sería unha decisión difícil de tomar. A percepción de perda de control resultante podería disuadir algún/algunha directivo/a de tan sequera comezar a implantar InnerSource. +- A implantación de modelos de traballo ao estilo InnerSource adoita supor un cambio radical con respecto aos modelos de traballo que se empregaban anteriormente. Polo tanto, é probable que os procesos obrigatorios existentes xa non sexan aplicables e que os procesos de goberno tampouco sexan apropiados. O resultado podería ser que a empresa teña que operar cun regulamento que se atope en terra de ninguén desde o punto de vista xurídico. Como, por exemplo, no caso das regulacións relacionadas co control de taxas e exportacións en grandes corporacións con múltiples entidades xurídicas en múltiples países. ## Solución @@ -26,13 +26,13 @@ Declare a iniciativa InnerSource como un experimento cun tempo limitado. Defina Exemplos de tales criterios son: -- Axeitada distribución xeográfica dos/as desenvolvedores/as. +- Axeitada distribución xeográfica dos/das desenvolvedores/as. - Axeitada mestura de departamentos nos que se atopan os/as desenvolvedores/as. - Apertura da comunicación na comunidade. - Traxectoria profesional baseada nos méritos acadados nesa comunidade. - Toma de decisións democrática na comunidade. -Considere a posibilidade de designar o final do experimento como o punto a partir do cal facer un cambio ou pausa para a reavaliación. Considere tamén establecer un [Comité de revisión](./review-committee.md) para aumentar as probabilidades de que a dirección se implique a través da participación. Dependendo da cultura da empresa, podería ser útil acompañar o experimento con métricas axeitadas como en [Primeiros pasos coas métricas](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/introducing-metrics-in-innersource.md). Se os proxectos no experimento non brindan un impacto directo nos ingresos da empresa, considere presentarllos a unha [avaliación entre equipos](./crossteam-project-valuation.md) e para resaltar as súas contribucións de valor. +Considere a posibilidade de designar o final do experimento como o punto a partir do cal facer un cambio ou pausa para a reavaliación. Considere tamén establecer un [comité de revisión](./review-committee.md) para aumentar as probabilidades de que a dirección se implique a través da participación. Dependendo da cultura da empresa, podería ser útil acompañar o experimento con métricas axeitadas como en [Primeiros pasos coas métricas](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/introducing-metrics-in-innersource.md). Se os proxectos no experimento non brindan un impacto directo nos ingresos da empresa, considere presentalos a unha [avaliación entre equipos](./crossteam-project-valuation.md) e para resaltar as súas contribucións de valor. ## Contexto resultante @@ -43,7 +43,7 @@ O persoal directivo pode pór en marcha InnerSource polas seguintes razóns: - Incluso no caso de fracasar, a configuración garante que a empresa aprenderá do experimento. - En caso de éxito, os datos recollidos durante o experimento permitirán que o persoal directivo se comprometa a longo prazo con InnerSource. -As persoas participantes no experimento InnerSource son agora conscientes de que teñen que demostrarlle ao persoal directivo que InnerSource produce os beneficios prometidos. Polo tanto, será útil centrar o traballo naquelas actividades que aporten un valor máis demostrable, aumentando así as posibilidades de éxito. +As persoas participantes no experimento InnerSource son agora conscientes de que teñen que demostrarlle ao persoal directivo que InnerSource produce os beneficios prometidos. Polo tanto, será útil centrar o traballo naquelas actividades que acheguen un valor máis demostrable, aumentando así as posibilidades de éxito. Finalmente, comezar cunha práctica a modo experimento, fai que sexa moito máis fácil eludir as normativas e os impedimentos tales como as políticas de ferramentas e os procesos, que poderían diminuír as posibilidades de éxito. diff --git a/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md b/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md index c9cea0d6f..865729877 100644 --- a/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md +++ b/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md @@ -4,7 +4,7 @@ Toma de decisións transparente entre equipos mediante RFC ## Patlet -Os proxectos InnerSource que desexan lograr un alto índice de participación e tomar as mellores decisións posibles para tódalas persoas involucradas, necesitan atopar formas de crear sistemas participativos durante todo o ciclo de vida do software. A publicación de documentos internos con peticións de comentarios (RFC) permite manter debates desde o comezo do proceso de deseño. Tamén aumenta as posibilidades de idear solucións cun alto grao de compromiso por parte de tódalas partes implicadas. +os proxectos InnerSource que desexan lograr un alto índice de participación e tomar as mellores decisións posibles para todas as persoas involucradas, necesitan atopar formas de crear sistemas participativos durante todo o ciclo de vida do software. A publicación de documentos internos con peticións de comentarios (RFC) permite manter debates desde o comezo do proceso de deseño. Tamén aumenta as posibilidades de idear solucións cun alto grao de compromiso por parte de tódalas partes implicadas. ## Problema diff --git a/translation/gl/patterns/trusted-committer.md b/translation/gl/patterns/trusted-committer.md index 61aea9b64..251f0ada5 100644 --- a/translation/gl/patterns/trusted-committer.md +++ b/translation/gl/patterns/trusted-committer.md @@ -4,8 +4,7 @@ ## Patlet -Moitos proxectos InnerSource recibirán valoracións constantemente ou requirirán a posta en marcha de novas funcionalidades e a corrección de erros por parte dos/as contribuidores/as. -Nestas situacións, as persoas encargadas do mantemento do proxecto buscan formas de recoñecer e recompensar o traballo do/a contribuidor/a máis alá das contribucións individuais. +moitos proxectos InnerSource recibirán valoracións constantemente ou requirirán a posta en marcha de novas funcionalidades e a corrección de erros por parte dos contribuidores/as. Nestas situacións, as persoas encargadas do mantemento do proxecto buscan formas de recoñecer e recompensar o traballo do contribuidor/a máis alá das contribucións individuais. ## Problema @@ -90,9 +89,9 @@ Acadar o *status* de *trusted committer* nun proxecto demostra iniciativa á hor ### Para os/as mantedores/as -A medida que un proxecto madura, as persoas encargadas do mantemento poden familiarizarse menos cos aspectos chave dun proxecto. Os/As *trusted committers* enchen estes ocos baleiros, asegurando que tódolos aspectos do proxecto sexan atendidos mellor co tempo. +Á medida que un proxecto madura, as persoas encargadas do mantemento poden familiarizarse menos cos aspectos chave dun proxecto. Os/As *trusted committers* enchen estes ocos baleiros, asegurando que todos os aspectos do proxecto sexan atendidos mellor co tempo. -Contar cun conxunto robusto de *trusted committers* asegura que, se o persoal encargado do mantemento do proxecto segue adiante, sempre existirá un plan para a administración responsable. +Contar cun conxunto robusto de *trusted committers* asegura que, se o persoal encargado do mantemento do proxecto segue adiante, sempre existirá un plan para a Administración responsable. ## Exemplos coñecidos @@ -101,7 +100,7 @@ Esta iniciativa foi levada a cabo con éxito en: - Nike - Paypal - Mercado Libre: Engadindo unha sección no arquivo `CONTRIBUTING.md` para informar de quen son os/as *trusted committers*. -- Robert Bosch GmbH: Non se designou co nome de «*trusted committer*», pero si se implantou este rol ao comezo da implantación de InnerSource. Os/As *trusted committers* recibiron financiación para o 100 % do seu tempo laboral co obxectivo de que puidesen centrarse neste papel. +- Robert Bosch GmbH: non se designou co nome de «*trusted committer*», pero si se implantou este rol ao comezo da implantación de InnerSource. Os/As *trusted committers* recibiron financiación para o 100 % do seu tempo laboral co obxectivo de que puidesen centrarse neste papel. ![Sección dos/as *trusted committers* en CONTRIBUTING.md de Mercado Libre](../../../assets/img/mercadolibre-trusted-committers.png) diff --git a/translation/gl/templates/CONTRIBUTING-template.md b/translation/gl/templates/CONTRIBUTING-template.md index 50b1daaab..3c023d7bf 100644 --- a/translation/gl/templates/CONTRIBUTING-template.md +++ b/translation/gl/templates/CONTRIBUTING-template.md @@ -2,7 +2,7 @@ ## Tipos de contribucións -Nesta sección proporcione información sobre o tipo de contribucións que está a procurar o seu proxecto. Por exemplo, poden ser informes de erros, axuda para responder preguntas dos/as usuarios/as, melloras da documentación, corrixir erros e a posta en marcha de funcionalidades. +Nesta sección proporcione información sobre o tipo de contribucións que está a procurar o seu proxecto. Por exemplo, poden ser informes de erros, axuda para responder preguntas dos/das usuarios/as, melloras da documentación, corrixir erros e a posta en marcha de funcionalidades. ## Informes de erros @@ -12,7 +12,7 @@ Ademais, deberá incluír información sobre o que os/as contribuidores/as poden ## Peticións de funcionalidades -Engada información sobre como enviar *feature requests*. Do mesmo xeito, tamén debería incluír neste apartado a información sobre o que cabe esperar por parte dos/as contribuidores/as, en termos do tempo da primeira resposta e do proceso posterior. +Engada información sobre como enviar *feature requests*. Do mesmo xeito, tamén debería incluír neste apartado a información sobre o que cabe esperar por parte dos/das contribuidores/as, en termos do tempo da primeira resposta e do proceso posterior. ## Contribucións de documentación @@ -32,6 +32,6 @@ Esta sección debería conter información sobre: Esta sección debe facer explícito o proceso para converterse nun/nunha *trusted committer* se esa ruta está aberta aos/ás contribuidores/as. -## Como nomear ao/á *trusted committer* +## Como nomear o/a *trusted committer* Esta sección serve a modo de recordatorio para os/as *trusted committers* existentes e como explicación para os/as novos/as. Nela detállase como engadir a outras persoas ao *host team*. Deste xeito, o ideal é que esta información sexa idéntica para tódolos proxectos da organización, de modo que a información máis relevante se poida vincular desde aquí. diff --git a/translation/gl/templates/README-template.md b/translation/gl/templates/README-template.md index 2bc1da0d6..7b4560cc7 100644 --- a/translation/gl/templates/README-template.md +++ b/translation/gl/templates/README-template.md @@ -2,7 +2,7 @@ ## Misión -Esta sección debe conter unha descrición breve (de entre tres e cinco liñas) na que se describe a misión do seu proxecto. O obxectivo é indicar en que planea traballar e axudar aos/ás contribuidores/as externos/as a comprender que tipos de funcionalidades serán benvidas neste proxecto. +Esta sección debe conter unha descrición breve (de entre tres e cinco liñas) na que se describe a misión do seu proxecto. O obxectivo é indicar en que planea traballar e axudar os/as contribuidores/as externos/as a comprender que tipos de funcionalidades serán benvidas neste proxecto. Véxase tamén o capítulo de definición da [misión](https://producingoss.com/en/producingoss.html#mission-statement) en produción de software libre. @@ -21,7 +21,7 @@ Esta sección pode enumerar calquera ou cada un dos seguintes aspectos: ## Axuda -Esta sección debe conter unha breve documentación sobre a maneira de obter axuda para o proxecto como persoa usuario/a. Isto podería ser tan simple como dirixir ás persoas aos/ás usuarios/as ao sistema de seguimento de incidencias se así é como lle gustaría responder ás preguntas relativas ao proxecto. Tamén podería indicar unha canle de chat arquivada na que se poidan realizar buscas, algunha listaxe de correo arquivada na que se poidan realizar buscas ou algún foro de usuarios/as en liña. +Esta sección debe conter unha breve documentación sobre a maneira de obter axuda para o proxecto como persoa usuario/a. Isto podería ser tan simple como dirixir ás persoas aos/ás usuarios/as ao sistema de seguimento de incidencias se así é como lle gustaría responder as preguntas relativas ao proxecto. Tamén podería indicar unha canle de chat arquivada na que se poidan realizar buscas, algunha listaxe de correo arquivada na que se poidan realizar buscas ou algún foro de usuarios/as en liña. ## Familiarización @@ -31,11 +31,11 @@ Esta sección debe incluír información breve sobre como entrar en contacto co Este é un bo lugar para dar crédito aos/ás *trusted committers* do proxecto. -Tamén é a sección na que incluír información sobre o que significa ser un/unha *trusted committer* no proxecto, aínda que o ideal é que tódolos proxectos dunha organización empreguen a mesma definición, á cal pode acceder só mediante unha ligazón neste apartado. A razón de poñer aquí a ligazón é que, deste xeito, os/as compañeiros/as que teñen pouca ou ningunha experiencia traballando ou contribuíndo en proxectos InnerSource contan cunha canle directa á información dos proxectos tecnolóxicos da empresa que precisan para o seu traballo diario. +Tamén é a sección na que incluír información sobre o que significa ser un/unha *trusted committer* no proxecto, aínda que o ideal é que todos os proxectos dunha organización empreguen a mesma definición, á cal pode acceder só mediante unha ligazón neste apartado. A razón de poñer aquí a ligazón é que, deste xeito, os/as compañeiros/as que teñen pouca ou ningunha experiencia traballando ou contribuíndo en proxectos InnerSource contan cunha canle directa á información dos proxectos tecnolóxicos da empresa que precisan para o seu traballo diario. ## Contribucións -Nesta sección debe documentar (ou incluír unha ligazón á documentación) aqueles aspectos que calquera novo/a contribuidor/a precisa saber para comezar. Polo xeral, non se cubrirán tódolos temas seguintes. Céntrese naquilo que difire no seu proxecto respecto da configuración estándar, así como naquilo que lles resultou difícil de entender aos/ás contribuidores/as anteriores. +Nesta sección debe documentar (ou incluír unha ligazón á documentación) aqueles aspectos que calquera novo/a contribuidor/a precisa saber para comezar. Polo xeral, non se cubrirán todos os temas seguintes. Céntrese naquilo que difire no seu proxecto respecto da configuración estándar, así como naquilo que lles resultou difícil de entender aos/ás contribuidores/as anteriores. - Atopar o código fonte. - Atopar unha listaxe de incidencias coas que o seu proxecto precisa axuda que pode ser técnica ou non. Polo xeral, os/as contribuidores/as poden acceder a través dun sistema de seguimento de incidencias. @@ -43,8 +43,8 @@ Nesta sección debe documentar (ou incluír unha ligazón á documentación) aqu - Para contribucións técnicas: Facer cambios, construír o proxecto e probar os cambios. - Enviar os cambios ao proxecto. -Tamén incluirá información sobre como é o proceso preferente para os cambios no proxecto: Os/As contribuidores/as deberían primeiro abrir unha incidencia e enviar unha proposta, ou son benvidos/as a enviar os cambios directamente? Que é importante para vostede á hora de revisar as contribucións? +Tamén incluirá información sobre como é o proceso preferente para os cambios no proxecto: os/as contribuidores/as deberían primeiro abrir unha incidencia e enviar unha proposta, ou son benvidos/as a enviar os cambios directamente? Que é importante para vostede á hora de revisar as contribucións? -Ademais, debe describir os valores de deseño que desexa seguir no proxecto. Facelos explícitos adoita axudar a resolver as contradicións con maior rapidez e facilidade. Ademais, axuda a facer transparentes os cambios en supostos que, doutro xeito, estarían implícitos. +Ademais, debe describir os valores de deseño que desexa seguir no proxecto. Facelos explícitos adoita axudar a resolver as contradicións con maior rapidez e facilidade. Ademais, axuda a facer transparentes os cambios en supostos, que doutro xeito, estarían implícitos. Co tempo notará que esta sección crece substancialmente. Nese caso, pense en trasladar a información a arquivos separados, por exemplo, a `CONTRIBUTING.md` e `TESTING.md`. diff --git a/translation/gl/templates/pattern-template.md b/translation/gl/templates/pattern-template.md index 80459d9ea..d4591a54b 100644 --- a/translation/gl/templates/pattern-template.md +++ b/translation/gl/templates/pattern-template.md @@ -24,7 +24,7 @@ Onde está o problema? Cales son as circunstancias previas? É importante descri ### Aspectos que mellorar -Que dificulta o problema? Cales son os sacrificios? Neste apartado, abórdanse as limitacións que **poden cambiar** a un certo custo. A solución podería mudar un ou máis destes impedimentos co obxectivo de resolver o problema, o cal tamén afecta ao contexto. +Que dificulta o problema? Cales son os sacrificios? Neste apartado, abórdanse as limitacións que **poden cambiar** a un certo custo. A solución podería mudar un ou máis destes impedimentos co obxectivo de resolver o problema, o cal tamén afecta o contexto. ### Exemplo ilustrativo (opcional) @@ -53,17 +53,17 @@ Pode facer referencia a: ### Estado (opcional ata a integración) -O estado xeral do modelo almacénase no sistema de etiquetado de GitHub; consulte aquí calquera *pull request*. Teña en conta que o sistema de etiquetado de GitHub faise menos visible unha vez que o modelo se remata e se integra, polo que é útil contar con información neste eido. +O estado xeral do modelo almacénase no sistema de etiquetaxe de GitHub; consulte aquí calquera *pull request*. Teña en conta que o sistema de etiquetaxe de GitHub se fai menos visible unha vez que o modelo se remata e se integra, polo que é útil contar con información neste eido. Tamén pode almacenar outra información de interese neste apartado, como un historial de revisión, por exemplo: «Tres de nós revisamos isto o 5/2/17 e precísase dos coñecementos especializados de John antes de que se poida continuar». ### Autoría (opcional) -En moitos casos, vostede mesmo/a pode formar parte da autoría. Se é necesario, procure a alguén en InnerSource Commons para que sexa o/a autor/a nominal (tal e como se explicou anteriormente). Tamén podería manter o anonimato no caso de que non queira asumir a autoría (algo común cando se emprega un *donut* para procurar unha solución). +En moitos casos, vostede mesmo/a pode formar parte da autoría. Se é necesario, procure alguén en InnerSource Commons para que sexa o/a autor/a nominal (tal e como se explicou anteriormente). Tamén podería manter o anonimato no caso de que non queira asumir a autoría (algo común cando se emprega un *donut* para procurar unha solución). ### Recoñecementos (opcional) -Inclúa a aquelas persoas que axudaron a desenvolver este modelo; tanto para a atribución como para un posible seguimento futuro. Aínda que é opcional, a maioría dos modelos deben citar ás persoas que contribuíron na súa creación. +Inclúa aquelas persoas que axudaron a desenvolver este modelo; tanto para a atribución como para un posible seguimento futuro. Aínda que é opcional, a maioría dos modelos deben citar as persoas que contribuíron na súa creación. ### Título alternativo (opcional)