Dedicated Networks Sub Project Way of Working

This page describes the initial proposal (pending review) for the Way of Working (WoW) specific to the Dedicated Networks Sub project.

This WoW is fully aligned with the CAMARA Governance process but adds additional details to streamline the work.

The WoW described by CAMARA is documented here

https://github.com/camaraproject/Governance/blob/main/ProjectStructureAndRoles.md#changes-and-contributions-to-camara

The most relevant ones to understand are Steps 4 and 5. Highlighted in bold.

4 The Contributor now shall invite other Sub Project Contributors to review the pull request. The Contributor shall invite at least 2 Maintainers, ideally from different companies and all Codeowners of the repository. As default all Maintainers and all Codeowners of the repository shall be invited as reviewers. Only the initial Contributor should edit a pull request in review (the Contributor is responsible to react on comments) or allow other Contributors explicitly to commit into the pull request.

5 The pull request shall be approved by all Contributors included in the review within a 2 weeks period. If a Contributor doesn't perform a review within that time frame the Contributor automatically accepts the pull request. For conflicting cases rules will be defined later. A two days cool off period after the approval shall be kept. A pull request review in certain cases might lead to a pull request not being approved. In this case, the Codeowner shall close the pull request (and the branch, and the issue) with the appropriate comments and the contribution shall not get merged into the main branch.

6 Finally one of the Codeowners of the repository shall merge the pull request into the main branch. By that the Codeowner closes the pull request. The Codeowner also shall close the branch and the issue (if not already automatically done). Deliverables of the Sub Project are all artifacts in the main branch of its repositories.

(NOTE: There is an issue with the CAMARA wording in the sentence - “the Contributor automatically accepts the pull request”. The Contributor can accept the PR but has no rights or permissions to merge. So in that sense, accepting doesn’t lead to anything. It is the Code owner and Maintainers who should accept)

The decision process in CAMARA is described here

https://github.com/camaraproject/Governance/blob/main/ProjectCharter.md#decision-making

The default decision making mechanism for the CAMARA Project is lazy consensus. This means that any decision on technical issues is considered supported by the team as long as nobody objects based on substantiated technical grounds.

Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. Decisions may, but do not need to be called out and put up for decision on the appropriate mailing list at any time and by anyone.

Consensus decisions can never override or go against the spirit of an earlier explicit vote.

If any Project participant raises objections, the Project participants work together towards a solution that all involved can accept. This solution is again subject to lazy consensus.

In case no consensus can be found, but a decision one way or the other must be made, any Project participant may call a formal majority vote.

WoW for Dedicated Networks:

In Dedicated Networks, we will apply the “lazy consensus” approach with a “2 week limit” rigorously to keep things moving.
It is expected that every PR mentioned in the bi-weekly meetings is merged in the next bi-weekly meeting.
It is a rule of thumb but does not apply to every scenario. It is perfectly okay to ask for more time to review, especially in case of large changes (but not an unreasonable number of times)
Contributors are requested to add comments. But if there are no comments, it is expected that Contributors explicitly approve PRs.

Rest of the page documents the Code Owners, Maintainers, and active Contributors to the Dedicated Network API. This is to make it easier to add relevant people in the reviews.

It is also expected that members represent their organization and co-ordinate between other roles of their organization.

Code Owners

	Name	Organization	Github username

	Name	Organization	Github username
1	Thorsten Lohmar	Ericsson	@tlohmar
2	Alejandro Palmier	Telefonica	@alejandropalmier
3	Peter Kovacs	Nokia	@PeterKovacs2
4	Eric Murray	Vodafone

Maintainers

	Name	Organization	Github username

	Name	Organization	Github username
1	Thorsten Lohmar	Ericsson	@tlohmar
2	Alejandro Palmier	Telefonica	@alejandropalmier
3	Peter Kovacs	Nokia	@PeterKovacs2
4	Steve Vickers	Vodafone	@SteveV-Vodafone

Active Contributors (who are not Code owners or Maintainers)

NOTE: This is an initial list and needs to be discussed / approved during the next DN meeting

	Name	Organization	Github username

	Name	Organization	Github username
1	Rajat Kandoi	Ericsson	@rkandoi
2	Hubert Przybysz	Ericsson
3	Barath K	Ericsson
4	Tanja de Groot	Nokia
5	Stefano Brivio	Vodafone
6	Masaharu Hattori	KDDI
7	Surajj Jaggernath	Vodacom
8	Fadime Demirer	Vodafone?
9	Ali Iqbal	X Flow Software Technology LLC