Add to model ability to point to config file(s) which resulted in that record
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- backend-api-design
Línea de trabajo
No se nombran archivos del repositorio, pruebas ni puntos de entrada de la implementación. Comienza revisando el ejemplo de ValidationOrigin y las referencias enlazadas bids-validator y OpenNeuro; después, aclara el modelo de procedencia y su comportamiento esperado al informar antes de la implementación.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
thinking about bids-validator config file which could change level of a specific type of a result. While reporting to the user it might be useful to instruct why any given record got to be like it is
in dandi-cli we associate each result with a singular
class ValidationOrigin:
name: str
version: str
bids_version: str | None = None
(I recall us working on refactoring to have standard and standard_version). So likely we would like to either add some explicit List[ConfigurationOrigin] construct depicting origin of the configuration (file, env var, ...) and then tools being able to annotating results with information about specific configuration file which effected that result. Thinking of the case where e.g. for openneuro there could be validator config provided by the dataset and then the one with overloads from openneuro.
User of the website then ATM just provided with a list of errors or warnings but there would be no specific description that e.g. error of having no subjects is specific to openneuro (its configuration for bids-validator, ref: https://github.com/OpenNeuroOrg/openneuro/pull/3184), and not of dataset itself or the original standard.
ref:
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 1
- Forks
- 1
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 con/validation
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
con/validation#2 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
con/validation#1 · 20 comentarios ·
Todos los issues de con/validation
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
cameri/nostream#811 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
bug p3 triaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
bug javascript P2-medium python release:v3.1
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
adrirubio/claude-deck#546 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 6 días