Output Flexibility & Contributor Formatting (v1.6.0)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- github-actions, python
- Área
- documentation, release
Línea de trabajo
Comienza con las tres subtareas vinculadas, #77, #56 y #97, y revisa los fundamentos del formato para contribuidores en #76. Considera el epic completo cuando se admitan las ubicaciones de salida de las notas de versión, el formato de las líneas de capítulo de los contribuidores y la sustitución de alias de usuario, con documentación y ejemplos que cubran cada modo de salida.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Background
Users need more control over where the generated release notes are written and how contributors are identified and displayed. Currently, the output location is fixed and contributor names are raw GitHub logins, which may not match team conventions or real names.
This epic introduces configurable output locations, contributor chapter-line formatting, and a user-alias replacement map so teams can fully tailor the presentation of their release notes.
Goals
- Support configurable output locations for generated release notes (e.g. wiki, file, PR comment) (#77)
- Enable customisable chapter line formatting for contributor sections (#56)
- Provide a configurable map for replacing GitHub usernames with display names or aliases (#97)
- Ensure all output location modes are documented with examples
Subtasks
- #77 Provide support for different locations of release notes
- #56 Chapter line formatting - contributors
- #97 Map of user replacements
Related / References
- Depends on contributor formatting groundwork from Epic 1 (#76 — contributor placeholder)
- #97 (user replacement map) feeds directly into #56 (contributor formatting)
- Lenguaje dominante
- Python
- Estrellas
- 13
- Forks
- 0
- Merge medio
- 1 min
- PR fusionados (30 d)
- 4
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de AbsaOSS/generate-release-notes
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 70/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 50/100
-
Introduce ruff and make qaAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
epic
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Todos los issues de AbsaOSS/generate-release-notes
Issues similares
-
Examples say cnxAbiertodocumentation embedded
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Alishahryar1/free-claude-code#2111 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
namespace operations
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
EclipseFdn/open-vsx.org#14373 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día