Redacta notas de versión a partir de solicitudes de extracción sin publicar información interna
Pide a Beeuni que lea un repositorio de GitHub conectado, compruebe el intervalo de versiones y redacte notas para los usuarios con referencias a los cambios.
Una solicitud de extracción titulada «Refactorizar el proceso de exportación» indica a quien revisa dónde buscar. A un cliente le dice muy poco. Las notas de versión deben explicar qué cambió en el producto, a quién afecta y si está disponible en esta versión.
Determina qué incluye realmente la versión
Dale al agente acceso al repositorio mediante la conexión de GitHub que tengas configurada. Pídele que encuentre las etiquetas anterior y actual, compare sus confirmaciones e inspeccione las solicitudes de extracción asociadas. Si hay varias versiones en curso, indica tú el repositorio y las etiquetas.
Read the connected repository and compare v1.4.0 with v1.5.0.
Draft release notes for users, grouped into features and fixes.
Inspect the linked PRs and diffs rather than relying on titles alone.
Keep a separate list of internal changes, reversions, and uncertain availability.
Save the draft with PR references. Do not publish a release.Que una solicitud de extracción se haya integrado no significa necesariamente que se haya desplegado; además, un cambio integrado esa misma semana podría corresponder a una versión posterior. Comparar las etiquetas permite determinar qué código está incluido. Aun así, es posible que debas confirmar con el equipo los indicadores de funcionalidad y el estado del despliegue gradual.
Pídele al agente que prepare una lista de trabajo privada con la solicitud de extracción de origen, el comportamiento modificado, los usuarios afectados y si el cambio está incluido en la versión. Comprueba si se revirtieron cambios y si hay funciones que siguen desactivadas. No incluyas en el borrador público las entradas dudosas hasta que alguien las confirme.
De los detalles de implementación a los cambios que importan a los usuarios
Estas notas ilustrativas de solicitudes de extracción muestran algunas decisiones de edición habituales:
| Nota de trabajo | Borrador de las notas de versión | Decisión editorial |
|---|---|---|
| Guardar los filtros seleccionados en los parámetros de la URL | Las vistas filtradas ahora conservan los filtros cuando compartes el enlace. | Describe el comportamiento visible |
| Evitar envíos duplicados al hacer doble clic | Se corrigió un problema que podía crear solicitudes duplicadas al hacer clic dos veces en «Enviar». | Indica qué acción provoca el problema y qué efecto tiene |
| Reorganizar las utilidades de prueba | Omitir de las notas públicas | Mantén los cambios de mantenimiento en el registro interno |
| Añadir la exportación detrás de un indicador de funcionalidad desactivado | Esperar hasta que la exportación esté disponible | Confirma que la función esté disponible antes de anunciarla |
Organiza las notas según lo que los lectores necesitan saber
Usa secciones como novedades, mejoras y correcciones cuando la versión lo requiera. Omite los encabezados que queden vacíos. Agrupa en una sola entrada varias solicitudes de extracción que formen parte de una misma función. Mantén separadas las correcciones distintas cuando afecten a acciones diferentes.
No escondas acciones necesarias dentro de una lista general de mejoras. Si cambia un campo de la API, indica el formato anterior y el nuevo, y enlaza las instrucciones de migración. Si el cambio de comportamiento solo afecta a ciertas cuentas o clientes, especifica a quiénes. Pide al responsable de la función que confirme esos detalles.
Mantén el borrador vinculado a sus fuentes
- Conserva las referencias a solicitudes de extracción o commits en la copia de revisión, aunque luego las elimines de las notas públicas.
- Comprueba que todas las funciones anunciadas estén disponibles en la versión descrita.
- Elimina los nombres de host internos, las credenciales, los datos de clientes y el contenido de incidencias aún no publicado.
- Sustituye afirmaciones como «más rápido» por una descripción precisa del comportamiento, a menos que puedas citar una medición.
Pide dos archivos: el borrador público y la lista de trabajo, que muestre las entradas incluidas, excluidas y sin resolver. Tras la revisión, puedes pedirle al agente que actualice el borrador en el repositorio, si la conexión permite escribir. Publicar la versión es una instrucción aparte. Si las notas indican que se corrigió un error del formulario, la guía de pruebas del sitio web describe el registro de reproducción que puedes usar para comprobarlo.
Más artículos
Infraestructura para la investigación sobre RSI: ejecutar y evaluar agentes que se mejoran a sí mismos
Cómo ayuda Beeuni a repetir experimentos de mejora de agentes: editar código e instrucciones, ejecutar pruebas, investigar fallos y comparar versiones.
Usa Beeuni para ejecutar y evaluar un experimento de ajuste fino de un modelo
Pide a un agente que prepare los datos de entrenamiento, ejecute un trabajo de ajuste fino en el ordenador de entrenamiento conectado, investigue los fallos y compare las salidas del modelo.