Separate process and design principles
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- backend-api-design, documentation
Research direction
Start in the Principles section and review the “API as a Product” entry alongside the issue’s reasoning about development processes and design principles. Rephrase or remove the process-specific wording, then confirm that the resulting principle remains applicable beyond Scrum.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- No language data
- Stars
- 34
- Forks
- 10
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bcgov/api-guidelines
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bcgov/api-guidelines#34 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 25/100
bcgov/api-guidelines#33 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
bcgov/api-guidelines#32 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
bcgov/api-guidelines#31 ·
-
It's Been a While Since This Repository has Been UpdatedMay be free again @jeff-card claimed this 1557 days ago, and no pull request is open. Open
bcgov/api-guidelines#28 · 3 comments · 2 assignees ·
All issues in bcgov/api-guidelines
Similar issues
-
area:deploy task
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
wilanis/wilanis-js#1017 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
eclipse-opensovd/classic-diagnostic-adapter#616 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
nixos/hyprland: wrapper source is a bash script and fails the ensure-wrapper-integrity ELF checkOpen0.kind: bug 6.topic: nixos
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
vllm-project/vllm#61131 ·
Maintainers usually reply within 1 day