search

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.
53 stars 44 forks source link

Update of ProjectStructureAndRoles to allow Sub Projects (API families) with multiple API repositories #146

Closed hdamker closed 2 days ago

hdamker commented 2 weeks ago

What type of PR is this?

What this PR does / why we need it:

Update of ProjectStructureAndRoles.md according to the proposal in #142, specifically https://github.com/camaraproject/Governance/issues/142#issuecomment-2175408112.

Minor update of ProjectCharter with addition of definition "Repository" and reflecting that Sub Projects and Working Groups can have multiple repositories.

Which issue(s) this PR fixes:

Fixes #142

Special notes for reviewers:

As there are major changes of the "Sub Project" chapter, the diff does not work properly. In addition some sentences are moved into the "Repositories" chapter.

Additional documentation

This section can be blank.

MarkusKuemmerle commented 1 week ago

We should add also a section for IdentityAndConsentManagement, this working group is missing

MarkusKuemmerle commented 1 week ago

Do TSC want do decide only on Sub Projects and Working Groups or on repositories as well? Then the description of the TSC repsonsibilities in the Project Charter has to be adapted too.

hdamker commented 1 week ago

We should add also a section for IdentityAndConsentManagement, this working group is missing

That isn't in scope of this issue/PR - but thanks for the hint.

Edit: created https://github.com/camaraproject/Governance/issues/147 for this point

hdamker commented 1 week ago

@MarkusKuemmerle

Do TSC want do decide only on Sub Projects and Working Groups or on repositories as well? Then the description of the TSC repsonsibilities in the Project Charter has to be adapted too.

That is already covered within the ProjectCharter, at least for the case where a new API repository does change the scope of a Sub Project:

  • approving Sub Project proposals (including, but not limited to, incubation, deprecation, and changes to a Sub Project’s scope)

And the description of the API Backlog working group here in the document addresses that as well:

The responsibility of the Working Group is to coordinate and prepare all the material needed to evaluate a proposal for a new Sub Project (consisting of one or more related APIs), or scope change of an existing Sub Project (including adding additional APIs to that Sub Project)

Adding a repository to a Sub Project for technical reasons without a scope change does not need the approval of the TSC - at least that is my view.

hdamker commented 2 days ago

As decided within last TSC call we are ready to merge here.