Separate process and design principles
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
Línea de trabajo
Comienza en la sección Principles y revisa la entrada «API as a Product» junto con el razonamiento del issue sobre los procesos de desarrollo y los principios de diseño. Reformula o elimina la redacción específica del proceso y, después, confirma que el principio resultante siga siendo aplicable más allá de Scrum.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Thanks for this! I have a comment.
In the Principles section I read the following:
API as a Product : apply the product owner role to API's
I think that development processes should be separated from design principles. Having a principle that implies that there should be a Product Owner looking at the API as a product excludes other Agile and traditional software development frameworks where there is no such roles. Consequently, it limits this principles to the Scrum framework. I don't think that design principles should be mixed with specific development processes. I would recommend to remove or rephrase the one mentioned above.
In a related note, in the Agile front, a self-organizing team can use the design principles to create high quality APIs, but the Product Owner should not need to have the technical background to understand them and prescribing them as backlog items. Product Owner focus more on vertical slices of functionality that deliver value to users. Product Owners should not need to focus on individual components of a solution.
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 34
- Forks
- 10
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin 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 bcgov/api-guidelines
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
bcgov/api-guidelines#34 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 25/100
bcgov/api-guidelines#33 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 55/100
bcgov/api-guidelines#32 ·
-
Devhub Issue: BC Government API Guidelines [API creation with the focus on security by design]Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
bcgov/api-guidelines#31 ·
-
It's Been a While Since This Repository has Been UpdatedQuizá libre de nuevo @jeff-card la tomó hace 1558 días y no hay ningún pull request abierto. Abierto
bcgov/api-guidelines#28 · 3 comentarios · 2 asignados ·
Todos los issues de bcgov/api-guidelines
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
microsoft/playwright#43327 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
microsoft/TypeScript#64758 ·
Los mantenedores suelen responder en 1 día
-
Liveness marks block-included attesters live in the block's epoch instead of the attestation's epochAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
p:3-mid pydanty:bug pydanty:is-working
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
pydantic/pydantic-ai#10153 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
status: needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
a2ui-project/a2ui#3158 ·
Los mantenedores suelen responder en 2 días