You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: book/es/toc.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,7 @@ Instead edit toc_template.md
19
19
20
20
## Patrones <aid="p"></a>
21
21
22
-
*[Casos de Uso del Issue Tracker](../../translation/es/patterns/issue-tracker.md) - El equipo anfitrión de InnerSource no logra hacer transparentes no solo los planes y el progreso sino también el contexto de los cambios. Esto se resuelve aumentando los casos de uso del issue tracker del proyecto para también servir en lluvia de ideas, discusión de implementación y diseño de funcionalidades.
22
+
*[Casos de Uso del Gestor de Tareas](../../translation/es/patterns/issue-tracker.md) - El equipo anfitrión de InnerSource no logra hacer transparentes no solo los planes y el progreso sino también el contexto de los cambios. Esto se resuelve aumentando los casos de uso del gestor de tareas (issue tracker) del proyecto para también servir en lluvia de ideas, discusión de implementación y diseño de funcionalidades.
23
23
*[Colaborador Contratado](../../translation/es/patterns/contracted-contributor.md) - Los colaboradores que desean contribuir a InnerSource son desalentados por su gerencia directa. La solución se proporciona mediante contratos y acuerdos formales.
24
24
*[Comenzar como Experimento](../../translation/es/patterns/start-as-experiment.md) - Inicia tu iniciativa InnerSource como un experimento con tiempo limitado para facilitar que los gerentes no familiarizados con InnerSource respalden y apoyen la iniciativa.
25
25
*[Comité de Revisión](../../translation/es/patterns/review-committee.md) - El modelo de trabajo InnerSource es un cambio radical respecto a los enfoques más tradicionales, tanto para desarrolladores como para gerentes. Al establecer un comité de revisión como interfaz entre la iniciativa InnerSource y todos los gerentes senior de las unidades de negocio participantes, es más probable que estos últimos se familiaricen con la iniciativa y la apoyen, ya que les proporciona cierto nivel de supervisión y control sin fomentar la microgestión.
@@ -42,7 +42,7 @@ Instead edit toc_template.md
42
42
*[Grupo de Soporte](../../translation/es/patterns/group-support.md) - ¿Qué sucede si un equipo o individuo deja de mantener un proyecto InnerSource? Mantén el proyecto activo formando un grupo de personas interesadas.
43
43
*[Toma de Decisiones Transparente Entre Equipos usando RFCs](../../translation/es/patterns/transparent-cross-team-decision-making-using-rfcs.md) - Los proyectos InnerSource que buscan alcanzar altas tasas de participación y tomar las mejores decisiones posibles para todos los involucrados necesitan encontrar formas de crear sistemas participativos a lo largo de todo el ciclo de vida del software. La publicación de documentos internos de Solicitud de Comentarios (RFC) permite discusiones desde el inicio del proceso de diseño y aumenta las probabilidades de construir soluciones con un alto grado de compromiso de todas las partes involucradas.
44
44
*[Trusted Committer](../../translation/es/patterns/trusted-committer.md) - Muchos proyectos InnerSource se encontrarán en una situación donde reciben constantemente retroalimentación, funcionalidades y correcciones de errores de los contribuidores. En estas situaciones, los mantenedores del proyecto buscan formas de reconocer y recompensar el trabajo del contribuidor más allá de las contribuciones individuales.
45
-
*[Valoración de Proyectos Cross-Team](../../translation/es/patterns/crossteam-project-valuation.md) - Es difícil vender el valor de los proyectos InnerSource cross-team que no proporcionan un impacto directo en los ingresos de la empresa. Aquí hay una forma basada en datos para representar tu proyecto que articula y amplifica su valor.
45
+
*[Valoración de Proyectos Transversales](../../translation/es/patterns/crossteam-project-valuation.md) - Es difícil vender el valor de los proyectos InnerSource cross-team que no proporcionan un impacto directo en los ingresos de la empresa. Aquí hay una forma basada en datos para representar tu proyecto que articula y amplifica su valor.
Copy file name to clipboardExpand all lines: translation/es/patterns/base-documentation.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,7 +39,7 @@ Si tu proyecto aún no tiene un README.md, créalo e incluye lo siguiente:
39
39
* Documentación más profunda para los usuarios del proyecto, o un enlace a ella.
40
40
* Documentación necesaria para hacer modificaciones al proyecto, o un enlace a ella.
41
41
* Documentación sobre cómo contribuir al proyecto, o un enlace a ella.
42
-
* Una sección de "Participar" que explique qué canales de comunicación públicos, archivados y enlazables utiliza el proyecto. Esto debe incluir un enlace al rastreador de problemas del proyecto, pero también a cualquier otro medio de discusión utilizado.
42
+
* Una sección de "Participar" que explique qué canales de comunicación públicos, archivados y enlazables utiliza el proyecto. Esto debe incluir un enlace al gestor de tareas (issue tracker) del proyecto, pero también a cualquier otro medio de discusión utilizado.
43
43
* Una sección de "Quiénes somos" que explique quiénes son los [Trusted Committers](trusted-committer.md) detrás del proyecto, con una explicación de que en lugar de contactar a estas personas en privado, se deben utilizar los canales de comunicación públicos mencionados anteriormente.
44
44
* Una explicación de cuáles son los criterios para que el proyecto convierta a los contribuidores en Trusted Committers, si ese camino existe.
Copy file name to clipboardExpand all lines: translation/es/patterns/communication-tooling.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,9 +30,9 @@ El objetivo al optimizar los canales de comunicación para proyectos InnerSource
30
30
31
31
Un proyecto debe establecer las siguientes herramientas de comunicación:
32
32
33
-
1.**Issue Tracker dedicado** donde la comunicación estructurada, la toma de decisiones y el seguimiento del progreso pueden ocurrir de manera transparente para todos los miembros del equipo anfitrión y también para los usuarios y contribuyentes posteriores. Para más aplicaciones del gestor de problemas, ver [Casos de Uso del Gestor de Problemas](./issue-tracker.md).
34
-
2.**canales de discusión públicos** que tienen una estructura menos rígida. Típicamente, serán listas de correo, foros en línea, sistemas de preguntas y respuestas o incluso canales de chat archivados. Usualmente es suficiente comenzar con solo un canal para el proyecto. Si el tráfico aumenta demasiado, es útil separar las discusiones sobre el uso del proyecto de las discusiones sobre el desarrollo del proyecto.
35
-
3.**un canal privado** donde la comunicación sobre temas sensibles puede ocurrir entre [Trusted Committers](./trusted-committer.md) - por ejemplo, agregar más Trusted Committers al equipo anfitrión. Este canal debe usarse con mucho cuidado para que la comunicación por defecto sea abierta y se mantenga privada solo en circunstancias muy raras.
33
+
1.**Gestor de tareas dedicado** donde la comunicación estructurada, la toma de decisiones y el seguimiento del progreso pueden ocurrir de manera transparente para todos los miembros del equipo anfitrión y también para los usuarios y contribuyentes posteriores. Para más aplicaciones del gestor de problemas, ver [Casos de Uso del Gestor de Problemas](./issue-tracker.md).
34
+
2.**Canales de discusión públicos** que tienen una estructura menos rígida. Típicamente, serán listas de correo, foros en línea, sistemas de preguntas y respuestas o incluso canales de chat archivados. Usualmente es suficiente comenzar con solo un canal para el proyecto. Si el tráfico aumenta demasiado, es útil separar las discusiones sobre el uso del proyecto de las discusiones sobre el desarrollo del proyecto.
35
+
3.**Un canal privado** donde la comunicación sobre temas sensibles puede ocurrir entre [Trusted Committers](./trusted-committer.md) - por ejemplo, agregar más Trusted Committers al equipo anfitrión. Este canal debe usarse con mucho cuidado para que la comunicación por defecto sea abierta y se mantenga privada solo en circunstancias muy raras.
36
36
37
37
Aunque la comunicación puede ocurrir fuera de estos canales escritos, se debe traer la mayor cantidad de información posible a los canales asincrónicos.
Copy file name to clipboardExpand all lines: translation/es/patterns/issue-tracker.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,18 @@
1
1
## Title
2
2
3
-
Casos de Uso del Issue Tracker
3
+
Casos de uso del Gestor de Tareas (Issue Tracker)
4
4
5
5
## Patlet
6
6
7
-
El equipo anfitrión de InnerSource no logra hacer transparentes no solo los planes y el progreso sino también el contexto de los cambios. Esto se resuelve aumentando los casos de uso del issue tracker del proyecto para también servir como herramienta de lluvia de ideas, discusión de implementación y diseño de funcionalidades.
7
+
El equipo anfitrión de InnerSource no logra hacer transparentes no solo los planes y el progreso sino también el contexto de los cambios. Esto se resuelve aumentando los casos de uso del gestor de tareas del proyecto para también servir como herramienta de lluvia de ideas, discusión de implementación y diseño de funcionalidades.
8
8
9
9
## Problema
10
10
11
-
Un equipo desarrolla un componente del que dependen muchos equipos en la organización. Utiliza un issue tracker estándar para rastrear errores abiertos y solicitudes de características. Sin embargo, el contexto en cada entrada es muy limitado. Como resultado, los posibles contribuyentes no tienen forma de saber de qué cambio exactamente está hablando cada issue.
11
+
Un equipo desarrolla un componente del que dependen muchos equipos en la organización. Utiliza un gestor de tareas (issue tracker) estándar para rastrear errores abiertos y solicitudes de características. Sin embargo, el contexto en cada entrada es muy limitado. Como resultado, los posibles contribuyentes no tienen forma de saber de qué cambio exactamente está hablando cada issue.
12
12
13
13
## Contexto
14
14
15
-
El tooling del proyecto InnerSource está todo configurado. Sin embargo, el issue tracker del proyecto se utiliza principalmente para compartir el progreso. En los proyectos de InnerSource hay muchos más casos de uso que un issue tracker puede utilizar para facilitar la comunicación remota y asincrónica.
15
+
El tooling del proyecto InnerSource está todo configurado. Sin embargo, el gestor de tareas del proyecto se utiliza principalmente para compartir el progreso. En los proyectos de InnerSource hay muchos más casos de uso que un gestor de tareas puede utilizar para facilitar la comunicación remota y asincrónica.
16
16
17
17
## Resistencias
18
18
@@ -26,22 +26,22 @@ El tooling del proyecto InnerSource está todo configurado. Sin embargo, el issu
26
26
Adopte la filosofía de 'priorizar lo escrito sobre lo verbal' no solo en el desarrollo de software, sino también durante la fase de planificación de nuevas características:
27
27
28
28
- Para errores, características planificadas e ideas de características, cree problemas separados. En cada uno de ellos, incluya tanta información como sea posible para que los posibles contribuyentes externos puedan entender el contexto. Idealmente, en particular para cambios más fáciles, incluya suficiente información para que los contribuyentes externos apoyen al equipo anfitrión implementando la funcionalidad en cuestión.
29
-
- Potencialmente use el issue tracker como un canal para hacer preguntas. Esto es particularmente útil si carece de otras fuentes de comunicación para abordar las preguntas de los usuarios.
29
+
- Potencialmente use el gestor de tareas como un canal para hacer preguntas. Esto es particularmente útil si carece de otras fuentes de comunicación para abordar las preguntas de los usuarios.
30
30
- Haga uso de etiquetas y categorías para distinguir problemas utilizados para diferentes propósitos.
31
31
- Para iniciar una sesión de lluvia de ideas de manera asincrónica, abra un issue para recopilar ideas. Cuando la discusión comience a calmarse, resuma los puntos identificados en este issue en un documento separado. Publíquelo para revisión como un pull request para profundizar en los puntos individuales que aún necesitan aclaración. El documento resultante se puede utilizar para publicar los resultados en otros canales apropiados, así como para referencia futura.
32
-
- La mayoría de las implementaciones de issue tracker permiten plantillas de problemas. Utilice estas no solo para recopilar información comúnmente necesaria para informes de errores, sino también incluya pistas sobre qué tipo de información se necesita para los otros tipos de uso.
32
+
- La mayoría de las implementaciones de gestor de tareas permiten plantillas de problemas. Utilice estas no solo para recopilar información comúnmente necesaria para informes de errores, sino también incluya pistas sobre qué tipo de información se necesita para los otros tipos de uso.
33
33
34
34
## Contexto Resultante
35
35
36
-
- Hacer más uso del issue tracker del proyecto para la comunicación permite a los contribuyentes externos seguir y tomar mejores decisiones sobre qué contribuir.
36
+
- Hacer más uso del gestor de tareas del proyecto para la comunicación permite a los contribuyentes externos seguir y tomar mejores decisiones sobre qué contribuir.
37
37
- Un enfoque en la comunicación escrita estructurada permite a los miembros del equipo anfitrión participar de forma remota.
38
38
- Comunicarse de manera consistente por escrito significa que la documentación pasiva sobre decisiones del proyecto se acumula como un subproducto en lugar de necesitar atención adicional.
39
39
- Utilizar consistentemente canales de comunicación públicos lleva a que más personas sigan una discusión. Esto significa que hay más personas conocedoras que pueden responder preguntas, opinar sobre problemas abiertos o señalar fallos en características planificadas que de otro modo se encontrarían mucho más tarde.
40
40
- Mover las discusiones a un medio de discusión público crea una oportunidad para que los posibles futuros contribuyentes observen, sigan, se sientan cómodos y aprendan las formas del proyecto mucho antes de que tengan la primera necesidad de involucrarse.
41
41
42
42
## Instancias Conocidas
43
43
44
-
* Europace AG - Ver publicación en el blog [Casos de Uso del Issue Tracker](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
44
+
* Europace AG - Ver publicación en el blog [Casos de Uso del Gestor de tareas](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
0 commit comments