Pŕactico 5: Template para ejercicio de reproducibilidad

Correspondiente a la sesión del jueves, 23 de abril de 2026

Objetivo de la sesión

El objetivo de esta sesión es presentar la plantilla (template) para el ejercicio de reproducibilidad que deberán realizar como parte de la primera evaluación del curso. Este template está diseñado para orientar a l_s estudiantes en la construcción del informe, proporcionando un formato base para el desarrollo del ejercicio.

Aquí pueden encontrar el repositorio del template para seguir paso a paso el práctico.

1 Cómo alojar el template en nuestra cuenta

Copia del template en nuestra cuenta

Una vez tenemos el template en un repositorio propio, debemos clonarlo en nuestro local. Para esto, abrimos VSCode, vamos a la sección de control de código fuente (Ctrl + Shift + P) y seleccionamos “Git: Clone” -> “Clone from GitHub” y elegimos el repositorio del template alojado en nuestra cuenta.

2 Presentación del template

0) Metadatos del documento

Se encuentran en el YAML del archivo .qmd

1) Selección del artículo/reporte

Detalles del documento seleccionado y justificación de su elección.

2) Evaluación de reproducibilidad

Análisis de la disponibilidad de los datos, código, documentación y transparencia de la investigación

3) Análisis reproducible

Proceso de reproducibilidad de la figura seleccionada

4) Conclusiones

Conclusiones sobre el nivel de reproducibilidad de la figura seleccionada

5) Recomendaciones

Recomendaciones para mejorar la reproducibilidad del artículo, si es necesario.

6) Referencias

3 Cómo utilizar el template

Al abrir el archivo index.qmd lo primero que veremos será el YAML. En la opción format se despliegan dos salidas: html y pdf. Para que el renderizado a pdf funcione, debemos installar un paquete llamado tinytex. Copien y ejecuten este código en sus terminales de R antes de cualquier intento de renderizado: install.packages("tinytex").

3.1 Metadatos

El template se encuentra en formato .qmd, una estructura de documento con la cual ya estamos familiarizados. En primer lugar, debemos modificar los metadatos del documento (YAML), como el título, fecha y autoría. Luego, podemos ir editando las demás secciones con el contenido correspondiente.

Al renderizar el documento, esta es la información que cambiará:

3.2 Referencias en la escritura del reporte

Para integrar referencias en el documento, debemos considerar tres elementos fundamentales: el archivo de referencias (.bib), el estilo de citación (.csl) y la sintaxis para citar en el texto (citation keys).

Ejemplo: tenemos una carpeta en Zotero con nuestras referencias, la cual exportamos como cienciabierta.bib y la guardamos en la carpeta input de nuestro proyecto. Luego, para que Quarto pueda reconocer este archivo, debemos especificar su ubicación en el YAML del documento.

El template ya trae la opción de integrar bibliografía, pero está escrito como comentario. Solamente debemos eliminar el # al inicio de bibliography para que Quarto reconozca la opción, y luego escribimos el nombre del archivo, respetando su ubicación. Para el .csl debemos seguir el mismo procedimiento. Entonces, si nuestro archivo .csl se llama apa.csl, el YAML debería verse así:

---
bibliography: "input/cienciabierta.bib"
csl: "input/apa.csl"
---

Una vez que tenemos esto configurado, podemos citar en el texto utilizando las citation keys. Por ejemplo, si queremos citar un artículo cuya citation key es harvey_brief_2005, escribimos @harvey_brief_2005 en el texto, y al renderizar el documento, esta referencia se integrará automáticamente con el formato definido por el archivo .csl.

Nota

Si tienen dudas respecto a referencias en texto plano, pueden revisitar el Práctico 02

3.3 Datos y código

Todo el análisis de código se realizará en el apartado de Análisis reproducible. Recordemos que para incluir datos y código en nuestro documento, debemos utilizar los chunks de Quarto. Por ejemplo, queremos reproducir la siguiente figura:

Considerando esto, nuestro código debería verse algo así:

Código
# Cargar librerías necesarias
library(ggplot2)
library(dplyr)

# Crear datos ficticios
set.seed(123)  # Para reproducibilidad
datos_ejemplo <- data.frame(
  categoria = rep(c("Grupo A", "Grupo B", "Grupo C", "Grupo D"), each = 50),
  valor_x = rnorm(200, mean = 50, sd = 10),
  valor_y = rnorm(200, mean = 30, sd = 8),
  satisfaccion = sample(1:10, 200, replace = TRUE)
)

# Crear el gráfico
ggplot(datos_ejemplo, aes(x = valor_x, y = valor_y, color = categoria)) +
  geom_point(aes(size = satisfaccion), alpha = 0.7) +
  geom_smooth(method = "lm", se = FALSE) +
  labs(
    x = "Variable X",
    y = "Variable Y",
    color = "Categoría",
    size = "Satisfacción (1-10)"
  ) +
  theme_minimal() 
Figura 1: Gráfico de ejemplo con datos ficticios

Al renderizarlo, obtendremos la figura reproducida en nuestro documento

Este ejemplo cumple con ilustrar cómo incluir código y datos en nuestro documento a partir de datos generados en el mismo chunk. En el caso de sus trabajos, deberán cargar los datos desde la carpeta input, o bien, con la url que dirija a la base de datos. Luego, reproducen la figura seleccionada utilizando el código proporcionado por los autores del artículo o reporte, en caso de que lo tengan a disposición.

Nota

Si tienen dudas respecto a la escritura en texto plano, pueden revisitar el Práctico 03

4 Actividad práctica

1) Trabajen en el template colaborativamente siguiendo los siguientes pasos:

  • Entre los integrantes de sus respectivos grupos, elijan el repositorio de una persona que contenga el template, el cuál será su espacio de trabajo para la evaluación n°1.

  • Luego, cada integrante debe clonar el repositorio en su local.

  • Finalmente, cada integrante del grupo debe generar un commit con su nombre y apellido, aplicando los cambios que estimen necesarios.

  • Recuerden que el template es solamente una guía, por lo que pueden modificarlo a su conveniencia, siempre y cuando se mantenga la estructura general del informe.

Nota

Recuerden que, cada vez alguna persona del grupo realice un commit, l_s demás deben hacer un pull para actualizar su local con los cambios realizados por sus compañer_s, y así evitar conflictos a la hora de hacer commits posteriores.