[Complete] Record report/block acceptance
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Área
- documentation, testing
Línea de trabajo
Start with docs/operations/acceptance.md, extending the section that #126 adds, and use docs/guides/testing.md as the starting example. Record each report and block step with its action, expected result, observed result, pass/fail and a source link, using the approved test environment for live checks. Done when the document holds those rows, each failure links to its own follow-up issue, and the evidence stays even where a later check passes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What to build
Record the completed report and block journeys using the approved test environment. Link the observed results and any remaining failures rather than treating deployment alone as acceptance.
Files
docs/operations/acceptance.md(extend the prerequisite’s file)- Starting example: docs/guides/testing.md
Steps
- Add a section for the journey described above in the listed document. Follow the completed feature issues’ examples and their supplied test inputs.
- Record the action, expected result, observed result, pass/fail and a link to the test or screenshot. Use the approved test environment for live checks.
- Link one focused follow-up issue for each failure. Keep the evidence even when a later check passes.
Example
Reference supplied live moderation/block evidence and unavailable UI checks; no broad new server test design.
Check it works
Record the expected and observed result in the named document, with source links and any follow-up issues.
Before starting
- #126 — Record session/discovery acceptance
References
Assign yourself before starting, or comment to claim the issue. Project setup.
- Lenguaje dominante
- PLpgSQL
- Estrellas
- 0
- Forks
- 0
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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 DevDogsUGA/DogPack
-
polish
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DevDogsUGA/DogPack#131 ·
-
polish
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
DevDogsUGA/DogPack#130 ·
-
moderation
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
DevDogsUGA/DogPack#119 ·
-
moderation
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
DevDogsUGA/DogPack#113 ·
-
discover
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
DevDogsUGA/DogPack#106 ·
Todos los issues de DevDogsUGA/DogPack
Issues similares
-
documentation glm5 llm-model
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
vllm-project/vllm-ascend#19062 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
tursodatabase/turso#10052 ·
Los mantenedores suelen responder en 1 día
-
Mac mini M6 (16 GB): Q2_0 streaming works - measured 11.7->27.2 tok/s + arena fix for sub-32 GB MacsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
enhancement needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
elastic/docs-builder#4495 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
cellrishi-code/claude-skills-atlas#165 ·
Los mantenedores suelen responder en 1 día