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.

Dedicated Networks Sub Project 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. Code owner and Maintainers need to approve the PR.

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”. Code owners and Maintainers are responsible for this.
- A PR discussed in the bi-weekly meetings should be merged in the next bi-weekly meeting. If there are no comments (in meetings or in offline discussions), the PR is considered accepted.
- The above 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).
- In cases where the Code owner is also the contributor, the code owner cannot approve the PR. At least one other code owner needs to approve. This is an open question.
In Dedicated Networks, all Contributors are requested to add comments or explicitly approve PRs in case of no comments.
In Dedicated Networks, all Contributors are requested to add all names in the list below to PRs for reviews.

List of Code Owners, Maintainers, and active Contributors

The 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.

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

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	@hubertp-ericsson
3	Barath K	Ericsson
4	Tanja de Groot	Nokia
5	Stefano Brivio	Vodafone
6	Masaharu Hattori	KDDI	@Masa8106
7	Surajj Jaggernath	Vodacom
8	Fadime Demirer Ulgen	Vodafone	@demirerf
9	Ali Iqbal	X Flow Software Technology LLC

Dedicated Networks Sub Project Way of Working

Related content