Project structure and Roles, handling of repositories

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

Project structure and Roles, handling of repositories #47

Closed Bart-Ericsson closed 2 years ago

Bart-Ericsson commented 2 years ago

In the repositories it is not possible to differentiate between: ◦ “a contribution” to a WG, which is not yet discussed; ◦ “a contribution” to a WG, for which the WG has discussed, agreed and endorsed; and ◦ “a deliverable of the WG” We need a standard structure to deal with this, since today the documents are a mix of the above, and connected to this, who is allowed to move contributions from one stage to another?

Should there be a higher level for deliverable approval? e.g. the steering group?

Perhaps we can learn from other project setups, e.g. 3GPP but apply it to their github way of working. See: https://www.3gpp.org/DynaReport/21900.htm but I'm sure this is also dealt with in other open source projects

MarkusKuemmerle commented 2 years ago

Additional information from Bart: An example of this you can find in the Commonalities WG folder, in the “deliverables” subfolder, there are documents on the Reference architecture, AuthN-AuthZ-concept, etc, which I believe are not deliverables, but “contributions”. They could eventually become deliverables, if agreed and approved, but since there is no process, it is hard to distinguish.

MarkusKuemmerle commented 2 years ago

Agree. We should have 4 subfolders (contributions, working, deliverables, supporting documents) and describe the process in the ProjectStructureAndRoles file:

All contributions have to be made only in the contributions subfolder
Work in progress has to be done only in the working subfolder
If decided by the maintainers that a new release can be published then the files can be moved to the subfolder deliverables
documents from outside which are needed for the work have to be saved in the supporting documents subfolder

Anything to add?

Bart-Ericsson commented 2 years ago

I think it is good structure, but on which level should this exist, should it be part of documentation and code? Or should approved API code also be moved in deliverables?

MarkusKuemmerle commented 2 years ago

I would create the subfolders on top level of each sub project or working group, having documentation, API_code and API_definitions below. In this way it is easier to manage releases and publish it.

I'll create a slide for approval of this change in the next steering committee meeting.

MarkusKuemmerle commented 2 years ago

Steering Committee voted to use branches instead of different sub directories. New section will be added to ProjectStructureAndRoles.md with a description how branches shall be used to reflect the status of an artefact.