...
This page describes the initial proposal (pending review) for the Way of Working (WoW) specific to the Dedicated Networks Sub project.
...
| Expand | ||
|---|---|---|
| ||
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
...
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.
...
Name | Organization | Github username | |||
|---|---|---|---|---|---|
| 1 | Rajat Kandoi | Ericsson | @rkandoi | ||
| 2 | Hubert Przybysz | Ericsson | |||
| 3 | Barath K | Ericsson | |||
| 4 | Tanja de Groot | Nokia | |||
| 35 | Stefano Brivio | Vodafone | 4 | Barath K | |
Ericsson | 5 | 6 | Masaharu Hattori | KDDI | |
| 67 | Surajj Jaggernath | Vodacom | |||
| 78 | Fadime Demirer | Vodafone? | |||
| 89 | Ali Iqbal | X Flow Software Technology LLC |
...