Adding SIG Apps Charter #2040
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,136 @@ | ||
| # SIG Apps Charter | ||
|
|
||
| ## Scope | ||
|
|
||
| SIG Apps covers developing, deploying, and operating applications on Kubernetes with a focus on the application developer and application operator experience. | ||
|
|
||
| ### Goals | ||
|
|
||
| * Discussion of how to define, develop, and run applications in Kubernetes. This is in order to better understand needs, improve on Kubernetes solutions, and share lessons to grow the number of applications running on Kubernetes | ||
| * Foster an ecosystem of tools to aid in developing, deploying, and operating applications on Kubernetes | ||
| * Be the voice of the people running applications in Kubernetes. This includes providing input on Kuberentes features, suggesting new features, and sharing the perspective of application developers and operators in the development of Kubernetes | ||
| * Enable varying workloads (e.g., databases, web services, machine learning) to run on Kubernetes through development of the Workloads API | ||
| * Develop subprojects that foster interoperability between tools used to develop, deploy, and operate applications | ||
| * Create documentation to enable application developers, application operators, and supporting tool developers to leverage Kubernetes | ||
| * Develop and maintain Kubernetes subprojects that aid in the development, deployment, and operation of applications on Kubernetes | ||
|
|
||
| ### Non-goals | ||
|
|
||
| * Do not endorse one particular ecosystem tool | ||
| * Do not pick which apps to run on top of Kubernetes | ||
| * Do not recommend one way to do things (e.g., picking a template language) | ||
|
|
||
| ## Roles | ||
|
There was a problem hiding this comment. You deliberately decided not to suggest any SIG-level technical decision-making entity, either SIG TLs or committee of subproject owners? That would mean, among other things, that the highest escalation point (within the SIG) of a subproject would be the subproject owners. I'll comment on the subproject creation process below. There was a problem hiding this comment. We deviate from the template a little here but let me start with the situation.
Technical leads over all the things doesn't really make sense here as things sit today. A committee would be hard. When it comes to mediating between sub-projects:
This is a deviation from the template. I don't expect we'll need to use it. The sub-project owners have always done a great job trying to work together. Any issues were typically outside of SIG Apps and have escalation points elsewhere. We should revisit this in 6 months and see if it's working. SIG Apps has been a changing thing. When it started it owned no code. Over time that changed to have a number of sub-projects and a lot of activity. I can't predict what will come next. This was laid out because we think it will work for what we have now. There was a problem hiding this comment. I think this makes sense, and actually helps in a sense to foster the diversity of ecosystem. I'd be ok with revisiting later. There was a problem hiding this comment. If the SIG does not have TLs, who approves the formation or retirement of subprojects? Its not clear to me in the current charter how a new subproject is accepted by the SIG. There was a problem hiding this comment. ignore above, i see the role is delegated to SIG chairs below. |
||
|
|
||
| Membership for roles tracked in: [sigs.yaml] | ||
|
|
||
| - Chair | ||
| - Run operations and processes governing the SIG | ||
| - Seed members established at SIG founding | ||
| - Chairs *MAY* decide to step down at anytime and propose a replacement. Use lazy consensus amongst | ||
| chairs with fallback on majority vote to accept proposal. This *SHOULD* be supported by a majority of | ||
| SIG Members. | ||
| - Chairs *MAY* select additional chairs through a [super-majority] vote amongst chairs. This | ||
| *SHOULD* be supported by a majority of SIG Members. | ||
| - Chairs *MUST* remain active in the role and are automatically removed from the position if they are | ||
|
There was a problem hiding this comment. May be removed how? Super-majority vote? |
||
| unresponsive for > 3 months and *MAY* be removed if not proactively working with other chairs to fulfill | ||
|
There was a problem hiding this comment. How would unresponsive chairs be removed? If there are only 2-3, it not clear there would be a good mechanism to do that. One possibility would be a consensus of other chairs and subproject owners. There was a problem hiding this comment. @bgrant0607 That is literally right out of the template. How should we proceed? I'm not sure what the next steps are. Any guidance? There was a problem hiding this comment. suggested a chair removal process here: #2336 |
||
| responsibilities. | ||
| - Number: 2-3 | ||
| - Defined in [sigs.yaml] | ||
|
|
||
| - Subproject Owners | ||
| - Scoped to a subproject defined in [sigs.yaml] | ||
| - Seed members established at subproject founding | ||
| - *MUST* be an escalation point for technical discussions and decisions in the subproject | ||
|
There was a problem hiding this comment. Given that the subproject has no higher technical appeal within the sig, I would capture here that the sig prefers technical decisions to remain within the subproject. There was a problem hiding this comment. The only one i'm concerned about are workload controllers - I'd like to see some detail about that subproject called out since that today owns a critical part of k/k code. There was a problem hiding this comment. @smarterclayton The workload controllers do have one higher level of appear and that's via SIG Architecture. It's not for everything but is for the things SIG Architecture owns. Same applies to everything else in core. What other sorts of details are you looking to see called out? Since I'm not sure what you're looking for I'm not sure how to craft it. There was a problem hiding this comment. Typically the SIG is point of contact for cross cutting issues such as - giving community updates, ensuring tests are passing before release, triaging release blocking issues, writing release notes, updating documentation, etc. Should these responsibilities fall on the workloads Controllers subproject directly? Does the WL Controllers subproject directly assume all responsibilities for being in kubernetes/kubernetes? There was a problem hiding this comment. @pwittrock Because SIG Apps doesn't have technical leads the owners of the code are the technical leads for their areas. Since we have a few concerns this lets people who own different concerns make technical decisions as appropriate fore there. Release notes, community updates, and some of these other things have fallen on SIG Apps rather than a sub-project in the past. |
||
| - *MUST* set milestone priorities or delegate this responsibility | ||
| - *MUST* remain active in the role and are automatically removed from the position if they are unresponsive | ||
| for > 3 months. | ||
| - *MAY* be removed if not proactively working with other Subproject Owners to fulfill responsibilities. | ||
| - *MAY* decide to step down at anytime and propose a replacement. Use [lazy-consensus] amongst subproject owners | ||
| with fallback on majority vote to accept proposal. This *SHOULD* be supported by a majority of subproject | ||
| contributors (those having some role in the subproject). | ||
| - *MAY* select additional subproject owners through a [super-majority] vote amongst subproject owners. This | ||
| *SHOULD* be supported by a majority of subproject contributors (through [lazy-consensus] with fallback on voting). | ||
| - Number: Minimum of 3 | ||
| - Defined in [sigs.yaml] [OWNERS] files | ||
|
|
||
| - Members | ||
| - *MUST* maintain health of at least one subproject or the health of the SIG | ||
| - *MUST* show sustained contributions to at least one subproject or to the SIG | ||
| - *SHOULD* hold some documented role or responsibility in the SIG and / or at least one subproject | ||
| (e.g. reviewer, approver, etc) | ||
| - *MAY* build new functionality for subprojects | ||
| - *MAY* participate in decision making for the subprojects they hold roles in | ||
| - Includes all reviewers and approvers in [OWNERS] files for subprojects | ||
|
|
||
| - Security Contact | ||
| - *MUST* be a contact point for the Product Security Team to reach out to for | ||
| triaging and handling of incoming issues | ||
| - *MUST* accept the [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy) | ||
| - Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file in | ||
| the repository, there is a template | ||
| [here](https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS) | ||
|
|
||
| ## Organizational management | ||
|
|
||
| - SIG meets weekly on zoom with agenda in meeting notes | ||
| - *SHOULD* be facilitated by chairs unless delegated to specific Members | ||
| - SIG overview and deep-dive sessions organized for Kubecon | ||
| - *SHOULD* be organized by chairs unless delegated to specific Members | ||
|
|
||
| - Contributing instructions defined in the SIG CONTRIBUTING.md | ||
|
There was a problem hiding this comment. Is there a CONTRIBUTING.md doc? There was a problem hiding this comment. There is. You can read it here. Credit @parispittman for getting us to have one. |
||
|
|
||
| ### Project management | ||
|
|
||
| #### Subproject creation | ||
|
|
||
| Subprojects may be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of | ||
|
There was a problem hiding this comment. So SIG Chairs would be the designated approvers of the KEP? There was a problem hiding this comment. I believe so. They are the ones who would make sure the lazy consensus or majority vote occurred and could carry those results to the KEP. I would consider this more of a logistical task of the chair. There was a problem hiding this comment. Is there guidance for what qualifies as a subproject of SIG Apps. The charter of the SIG itself is relatively broad - define, develop, and run applications in Kubernetes. Is any open source tool, library, application for running apps on Kubernetes a candidate? There was a problem hiding this comment.
@pwittrock No. There has been discussion in a few places on that point. k8s, as a project, doesn't want to take on ecosystem projects. If there is something that could aide with interoperability between projects we will look at that. @brendanburns or @bgrant0607 might be able to explain this better if you need it. When it comes to things like kubebuilder and metacontroller we've talked about where they come to that line of ecosystem enabler vs something that belongs in the ecosystem. |
||
| SIG Chairs. The result *SHOULD* be supported by the majority of SIG members. | ||
| - KEP *MUST* establish subproject owners | ||
| - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject owners | ||
| - Where subprojects processes differ from the SIG governance, they must document how | ||
| - e.g. if subprojects release separately - they must document how release and planning is performed | ||
|
|
||
| Subprojects must define how releases are performed and milestones are set. Example: | ||
|
|
||
| > - Release milestones | ||
| > - Follows the kubernetes/kubernetes release milestones and schedule | ||
| > - Priorities for upcoming release are discussed during the SIG meeting following the preceding release and | ||
| > shared through a PR. Priorities are finalized before feature freeze. | ||
| > - Code and artifacts are published as part of the kubernetes/kubernetes release | ||
|
|
||
| #### Subproject retirement | ||
|
|
||
| Subprojects may be retired, where they are archived to the GitHub kubernetes-retired organization, when they are | ||
| no longer supported based on the following criteria. | ||
|
|
||
| - A subproject is no longer supported when there are no active owners with activity on the project for the following time: | ||
| - Subprojects with no known users can be retired after being unsupported for > 3 months | ||
| - Subprojects with known users may be retired after providing at least 6 months notification of retirement | ||
| - Use [lazy-consensus] amongst chairs with fallback on majority vote to decide to retire. This *SHOULD* be | ||
| supported by a majority of SIG Members. | ||
|
|
||
| ### Technical processes | ||
|
|
||
| Subprojects of the SIG *MUST* use the following processes unless explicitly following alternatives | ||
| they have defined. | ||
|
|
||
| - Proposing and making decisions | ||
| - Proposals against sub-projects, not part of core Kubernetes, will have issues filed against their repositories | ||
| - When issues are used for Proposals sub-project will have their own decision making process | ||
|
There was a problem hiding this comment. Subprojects that are part of SIG Apps can have their own governance outside of SIG Apps? What value is SIG Apps providing here? There was a problem hiding this comment. This is a great question. It comes back to two things and intent. KEPs and the core/non-core subprojects. KEPs, the process owned by SIG Architecture, is primarily targeted at core but non-core projects are encouraged to use them as well. In the move for core kubernetes to become stable "boring" infrastructure people can rely on there is a move to well justified changes that are thought out and communicated in detail. This is slow and that's good for core and the stability of the project. Some subprojects need to move fast. For example the application crd/controller. They need to iterate and experiment. They aren't part of core but instead a sig owned repo. KEPs don't always fit well here. This is attempting to give subprojects like this some room to move fast while experimenting. The application crd/controller makes sense to be owned by SIG Apps because SIG Apps members are collaborating on an interoperability issue that affects numerous open source projects and vendor products. It's a place we can come together on that issue. Does that help explain it? There was a problem hiding this comment. If non-core subprojects need to move fast and are unwilling to go through the KEP process, do they belong under SIG governance? To me, this seems like a backdoor to bypassing official processes for official projects. My proposition: These developers are free to experiment and move fast on non-core projects on their own time, but it must not be an official sponsored SIG subproject or take up SIG resources (repos, meetings, upstream CI, etc.) There was a problem hiding this comment. I agree with @mattfarina. The value of having every subproject owned by some SIG is visibility, accountability, and consistency. Again, let's table the topic of "non-core" subprojects here. |
||
| - Proposals against core Kubernetes sent as [KEP] PRs and published to kubernetes-sig-apps as announcement | ||
| - When KEPs are used follow [KEP] decision making process | ||
|
|
||
| - Test health | ||
| - Canonical health of code published to a dashboard. | ||
| - Consistently broken tests automatically send an alert to a mailing list for the subproject maintainers. | ||
| - SIG members are responsible for responding to broken tests alert. PRs that break tests should be rolled back | ||
| if not fixed within 24 hours (business hours). | ||
|
|
||
| Issues impacting multiple subprojects in the SIG should be resolved by SIG Chairs | ||
|
|
||
| [lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus | ||
| [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote | ||
| [KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md | ||
| [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 | ||
| [OWNERS]: contributors/devel/owners.md | ||
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.
"do things" is pretty non-specific.
Workflows and tools?
Configure and deploy applications?
Dynamically manage applications (e.g., using Operators)?