-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Governance update for Sandbox/Incubated/Graduated approach #161
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The section
A Sandbox API Repository must have at least one Codeowner and one Maintainer (could be the same person). If branch protection rules are activated (on request of the Maintainers) within the repository it must have at least two Codeowners. Branch protection rules must be get activated at latest when the first public release is created.
is wrong, as sandbox API repos don't have maintainers
Please check the section about Release Management. Do Sandbox API repos also have to comply with the work in the commonalities Working Group?
Each Sub Project and each Sandbox API repository shall have a release management. ?
Please check the sections "Maintainers" and "Changes in maintainership". Maintainers are also relevant for Working Groups. The sentence
changing the MAINTAINERS.MD file of the respective Sub Project.
is wrong, Sub Projects don't have MAINTAINER files.
I'll create a separate issue for the clean up of "Project participants", "contributors" and the relation to PARTICIPANTS.MD.
ProjectStructureAndRoles.md
Outdated
A Sub Project should have at least one Maintainer. Ideally a Sub Project is managed by two or more Maintainers, depending on the size and scope of the Sub Project. The Maintainers of a Sub Project are defined by the union of the Maintainers listed within the MAINTAINERS.md files of the API Repositories which are belonging to the Sub Project. It is recommended that there is an overlap between the Maintainers of the API Repositories of the Sub Project, but it is not mandated that all Maintainers of the Sub Project take responsibility for all APIs in the Sub Project. | ||
The purpose of an API Repository is the definition and documentation of one or multiple (very closely related) APIs which will be always released together. | ||
|
||
An API Repository should have at least one Maintainer. Ideally an API Repository is managed by two or more Maintainers, depending on the size and scope of the API. Here, the responsibilities must be clearly agreed upon between all of the Maintainers. This includes coordinating who is responsible for which issues and pull requests. The Contributors to an API Repository are recorded by the mechanisms of GitHub in the Sub Project’s repositories. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As concrete rules for Maintainers for incubated and sandbox repo are specified below, could we refer them here? Else, this can be look inconsistent. Or we can choose to remove this maintainer specific statement from here completely, as it's anyway covered below
@@ -48,7 +101,7 @@ In the Project the “Fork and pull model” is used. Changes and contributions | |||
|
|||
2 Either the issue creator or one of the Sub Project Maintainers then shall assign the issue to one of the Contributors of the Sub Project. | |||
|
|||
3 This Contributor shall create a fork (if necessary), shall create a new branch, and shall copy the branch link into the issue. For the naming of the branch a clear and concrete description shall be used. | |||
3 This Contributor shall create a fork (if not yet done before), shall create a new branch within the fork, and shall copy the branch link into the issue. For the naming of the branch a clear and concrete description shall be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would copying the link in the issue be necessary? If we use the PR template and the #fixes tag, then this copying step is not needed. Probably not relevant for this PR but added this as this statement was part of the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, by using the "fixes" logic of GitHub, the PR will get automatically copied into the issue. But it is also possible to link the branch already earlier (there is a field within a GitHub issue for that, which is e.g. filled if the branch will be created out of the issue). Making this optional could be the scope of a separate PR.
Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com>
Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com>
Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com>
Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com>
Co-authored-by: Kevin Smith <Kevsy@users.noreply.github.com>
Co-authored-by: Kevin Smith <Kevsy@users.noreply.github.com>
Update Release management with clarifications.
@MarkusKuemmerle Thanks for your review!
I did changes to make maintainers for Sandbox API Repositories optional within 680d7cf But we have to differentiate here between two cases:
I tried to clarify this in 197a6a6 and 680d7cf mainly by the sentence within the definition of the Release Management working group: "All API and Working Group Repositories must comply with the work in the Release Management Working Group for releases and pre-releases."
Addressed within 680d7cf and c58a241 by replacing "Sub Projects" by "Sub Projects and Working Groups" wherever appropriate, correcting the sentence and adding the clarification that changes of maintainership of Working Groups are the responsibility of the TSC. I might still have missed some instances, please check and suggest needed changes.
Thanks! |
Opening the PR for review, as the initial comments are (hopefully) addressed. |
**Sub Projects** | ||
|
||
The CAMARA Project is organized primarily into Sub Projects. Each Sub Project is composed of Project participants from multiple companies and organizations, with a common purpose of advancing the Sub Project with respect to a specific Service API topic, for example ‘quality on demand’ or ‘localization’. Our goal is to enable distributed decision making and code ownership. This will be done by providing focused forums for getting work done, making decisions, and onboarding new Contributors. | ||
Sub Projects are the primary structure of the CAMARA Project. Each Sub Project is composed of Project participants from multiple companies and organizations, with a common purpose of advancing the Sub Project with respect to a specific Service API topic, for example ‘quality on demand’ or ‘localization’. Our goal is to enable distributed decision making and code ownership. This will be done by providing focused forums for getting work done, making decisions, and onboarding new Contributors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we include here the term family? As it has evolved from its creation, right now families are mostly parallelizing the subgroup concept, a group of APIs with a relation among them but separated in different repositories to ensure that there is not cross-dependancy in the specification. Location, qod... are good examples for API families.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit skeptical to re introduce the family term. We had discussion on the past but is was difficult to define and we get ride of it. Sub project term is just go enough for me.
|
||
Working Groups are documented in a separate section of [wiki.camaraproject.org](https://wiki.camaraproject.org) and can have one or multiple GitHub repositories following the API Repository template (the rules for API Repositories apply). In the Readme.md file the repositories of Working Groups are marked with a "Working Group" badge. | ||
A Sandbox API Repository can belong to a CAMARA Sub Project or exist initially independent as an independent API Repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicated information with line 45
As mentioned before the contributions to the Sub Projects were documented in the respective GitHub repositories of the Sub Projects, and the contributions to Working Groups were documented in the GitHub repositories of the Working Groups. All contributions beyond that, esp. contributions to the Project itself or the TSC are documented in the GitHub repository “Governance”. Additional repositories can be created for project administration purposes. | ||
* An independent Sandbox API Repository which is not part of an existing Sub Project will get a page in a separate section of the [CAMARA wiki](https://lf-camaraproject.atlassian.net/), a preliminary mailing list, a Slack channel, and (on request) a Zoom meeting to be able to communicate with the community and attract contributors. The MAINTAINERS.md file of an Independent Sub Project may already list contributors who are committed to the support the API Repository as Maintainers. But they are yet Maintainers of a Sub Project in the sense of the Project Charter. | ||
|
||
A Sandbox API Repository must have at least one Codeowner. If branch protection rules are activated within the repository it must have at least two Codeowners. Branch protection rules must get activated at latest when the first public release is created. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd delete the branch protection description here, since it's agreed that this not applies to sandbox repos.
For ease of use there are templates for the two types of Sub Project repositories (API and Provider Implementation Repositories), containing all necessary files which can be cloned and adapted. When cloning it has to be ensured that also the branch protection rules are active in the new repositories. For Working Group repositories the API Repository template should be used and adapted. | ||
An Incubated API Repository has the same structure as a Sandbox API Repository, with the following additional requirements: | ||
* An Incubated API Repository must belong to a CAMARA Sub Project (either an existing one or a new Sub Project created as part of the Incubation process). | ||
* The repository should have at least three Maintainers (out of the group of Maintainers of the Sub Project it belongs to). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it necessary to specify if the maintainers need to belong to different companies here? we discussed about this in the draft, both for maintainers support and market adoption rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @jgarciahospital that this point should be added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look globally good to me. Share small comment that Jorge about indication that maintainers for incubated projects should be from at least 2 distinct companies.
For ease of use there are templates for the two types of Sub Project repositories (API and Provider Implementation Repositories), containing all necessary files which can be cloned and adapted. When cloning it has to be ensured that also the branch protection rules are active in the new repositories. For Working Group repositories the API Repository template should be used and adapted. | ||
An Incubated API Repository has the same structure as a Sandbox API Repository, with the following additional requirements: | ||
* An Incubated API Repository must belong to a CAMARA Sub Project (either an existing one or a new Sub Project created as part of the Incubation process). | ||
* The repository should have at least three Maintainers (out of the group of Maintainers of the Sub Project it belongs to). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @jgarciahospital that this point should be added.
**Sub Projects** | ||
|
||
The CAMARA Project is organized primarily into Sub Projects. Each Sub Project is composed of Project participants from multiple companies and organizations, with a common purpose of advancing the Sub Project with respect to a specific Service API topic, for example ‘quality on demand’ or ‘localization’. Our goal is to enable distributed decision making and code ownership. This will be done by providing focused forums for getting work done, making decisions, and onboarding new Contributors. | ||
Sub Projects are the primary structure of the CAMARA Project. Each Sub Project is composed of Project participants from multiple companies and organizations, with a common purpose of advancing the Sub Project with respect to a specific Service API topic, for example ‘quality on demand’ or ‘localization’. Our goal is to enable distributed decision making and code ownership. This will be done by providing focused forums for getting work done, making decisions, and onboarding new Contributors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit skeptical to re introduce the family term. We had discussion on the past but is was difficult to define and we get ride of it. Sub project term is just go enough for me.
What type of PR is this?
What this PR does / why we need it:
To establish the approach described within #159 and discussed on this wiki page there are changes to Governance documents of CAMARA necessary.
This PR changes the ProjectCharter and the ProjectStructureAndRoles:
To be done in separate PRs:
Out of scope of this PR:
Which issue(s) this PR fixes:
Fixes #
Special notes for reviewers:
Additional documentation
This section can be blank.