API approval process - Githubissues

camaraproject / Governance

Telco network capabilities exposed through APIs provide a large benefit for customers. By simplifying telco network complexity with APIs and making the APIs available across telco networks and countries, CAMARA enables easy and seamless access.

55 stars 44 forks source link

API approval process #43

Closed Bart-Ericsson closed 2 years ago

Bart-Ericsson commented 2 years ago

The ProjectStructureAndRoles defines that maintainers need to make and approve technical design decisions but the process to review, approve and commit is not defined

suggested addition is to approve by majority vote between maintainers NOTE: there is also a role of committer to the projectStructure, although it is not clear how this role is assigned and how many there can be
Changes are currently done to the master branch, proposal to do changes to a sub branch and merge when approved by majority vote

The API workgroup needs to decide if an API is stable for release. A release shall change the version in the swagger in a master branch.

Proposal is a majority vote by maintainers

Bart-Ericsson commented 2 years ago

I put it here since it implies a clarification to the ProjectStructureAndRoles.md document, I think this needs to be agreed and the added to that document. I raised another related issue in the commonalities workgroup

MarkusKuemmerle commented 2 years ago

Good points, thx Bart!

I would like to wait until the next steering committee to give the others the chance to review the documents and also provide feedback, and then work out the necessary changes in a pull request to the documents and decide that changes in the steering committee.

MarkusKuemmerle commented 2 years ago

In the ProjectCharter it is stated that: "Technical decisions that only affect a single Sub Project are made informally by the maintainers of this Sub Project, and lazy consensus is assumed." I would add a sentence "If no consensus can be reached, the matter may be resolved by majority vote." to reflect your first point.

The decision to use a branch or not I would keep open. The maintainers should decide what's the best way.

And for the release number I totally agree, I would add a sentence "A release shall change the version in the API definition and documentation files in the master branch."

MarkusKuemmerle commented 2 years ago

First point inlcuded in Project charter. Second point will be considered in the regulations for branching / document status and will be included in ProjectStructureAndRoles.md. Third point will be considered in the versioning guideline currently in progress within commonalities working group