Adding SIG Apps Charter

[mattfarina]

/cc @prydonius @kow3ns

cc @kubernetes/steering-committee

This pull request contains the sig apps charter we've discussed in the past few meetings.

[mattfarina]

FYI, the development work was started in a google doc over at https://docs.google.com/document/d/1hpwSnzbcgSSEsoH9icjz-9KCvogwWI_X0h8ITQ6oJlI/edit

[r2d4]

This language leaves the charter open to scope creep. I think its worth being explicit here, and expanding the charter with additional PRs if needed.

[mhausenblas]

I can see where @r2d4 is coming from but I also fail to understand what exactly is wrong with this wording. Methinks it would help tremendously if a concrete alternative wording would be PRed here rather than just pointing out that we have scope creep with the current wording. Don't get me wrong, I also do worry about scope creep, however I can't think of a crisper way to state it.

[mattfarina]

The reason behind this language is the scope is:

SIG Apps Covers deploying and operating applications in Kubernetes with a focus on the application developer and application operator experience.

What if something comes up that's not on the list but within the broader scope definition? It would be easy to start niting due to the list. I'll update the language to be friendlier.

[r2d4]

Wouldn't testing environments be SIG Testing?

[prydonius]

I believe this refers to testing applications (CI/CD) and not testing Kubernetes itself. Perhaps this should be reworded to application testing environments to make that more clear.

[mattfarina]

We might be getting into grammar questions here. In the long form it would be application development, application testing environments, and applications in production. I can expand the language.

[kow3ns]

@r2d4 SIG testing deals with testing Kubernetes not testing applications that run on Kubernetes.

[r2d4]

Controllers is not all controllers, just the Replication Controller, correct?

There is a proposal to own SDKs in the potential SIG Platform-Dev. Does this conflict with their proposal?

It might also be explicit to state that the APIs in question are apps/v1 and not all APIs.

[prydonius]

SIG Apps owns all the controllers for the apps and batch api groups. Agree that we should explicitly mention the API groups SIG Apps here. We previously had discussions around third-party APIs, controllers, SDKs but more in-depth discussions around these will move to SIG Platform-Dev. There will continue to be cross-collaboration on these fronts as defined in their proposal: https://groups.google.com/forum/#!topic/kubernetes-users/uVFndwjYGgo. I'm not sure how best to word this to reflect all of that.

[mattfarina]

The code that SIGs own is recorded elsewhere and open to change over time. I'm not sure we could couple the scope of the charter with the code and API a SIG owns. For reference, the code is considered to be a subproject and that's recorded in the sigs.yaml file.

For example, SIG Apps has the ability to add a new subproject per processes in the charter. That can be recorded in the sigs.yaml file. The charter shouldn't need to change to add a subproject.

I defer to the @kubernetes/steering-committee on this one. cc @michelleN @jbeda

[mattfarina]

/cc @bgrant0607 @smarterclayton

[r2d4]

Do you anticipate SIG Apps owning more core API groups and controllers often? An amendment to the core APIs or Controllers that SIG Apps owns has never happened, so I think that would constitute a charter amendment.

[mattfarina]

Its unclear what the purpose of the charter is other than to specifically answer these types of questions.

@r2d4 That's a good question.

When SIG Apps was formed, a couple years ago, like other SIGs it had to have a scope.

At the last contributor summit, with KubeCon in December, there were a number of conversations on governance. Questions came up such as, who is a member of a SIG? Are the processes they use documented? These are all part of a broader effort, by the steering committee, to clarify and document the kubernetes governance.

Recently, the steering committee put a task to the SIGs to clarify these elements in a charter. The template they provided to the SIGs, which this document used as a starting point, didn't include the scope. SIGs have been adding their existing scope to the charter because scope is typically part of a charter.

From what I can tell, this effort is not around re-defining the scope of SIGs. It's an effort to document processes within a SIG.

[r2d4]

The governance.md document at the root of this repository clearly states the purpose of this document is to define scope.

Each SIG must have a charter that specifies its scope (topics,
subsystems, code repos and directories), responsibilities, areas of
authority, how members and roles of authority/leadership are
selected/granted, how decisions are made, and how conflicts are
resolved.

https://github.com/kubernetes/community/blame/master/governance.md#L64-L68

[bgrant0607]

SIG Apps owns workload APIs and their controllers. "Workloads" are categories of applications, such as stateless, stateful, and batch, rather than specific applications, such as MySQL. If we need new kinds of workload APIs and controllers in the future, SIG Apps would own them. They might fit into existing API groups or require new ones. But the bar for adding new APIs, especially built-in ones, will be fairly high. I believe the current controllers are general enough to cover a wide variety of applications.

I'm inclined to add additional subproject information, such as subproject descriptions, to sigs.yaml rather than into charters. General scope, categories of subprojects, and key example subprojects should be covered in the charter.

[bgrant0607]

governance.md needs to be reconciled with the new charter requirements and template.

Lots of work to do.

[bgrant0607]

With respect to "Discuss..."

This SIG should own the responsibility of ensuring that the most important categories of workloads run well and are easily managed on Kubernetes, while allowing a diverse variety of application topologies and deployment tools and workflows.

[r2d4]

What does the Kubernetes project gain by continuing to govern these projects? Arguably these projects did not belong in Kubernetes in the first place, and it seems that the authors agree by not accepting any new tools. This charter might be a good opportunity to make this split as Helm and charts seems to be self-sufficient to continue on their own.

• Does Helm v3 get "grandfathered in" if it is a complete rewrite of Helm v2?
• This is not the full list of sub-projects, does this mean SIG Apps is divesting the ones not listed here?

chart-testing
chartmuseum
charts (listed)
helm (listed)
kompose (listed)
monocular
rudder-federation

By being under SIG Apps governance, these tools are official tool recommendations of Kubernetes which runs counter to the non-goal of "endorsing a particular ecosystem tool"

[mhausenblas]

I agree with @r2d4 that we should have a clean separation here in terms of projects exactly because of the non-endorsing principle and that now, with this charter, it is the most appropriate point in time to implement it.

[mattfarina]

This is a complicated space to discuss and conversations around this have been happening for months. Here are some of the details from those other conversations:

• Any change to the ownership of these subprojects is a steering committee decision. They have been talking about it and will continue to talk about it. The steering committee has a list of priorities and different elements relating to this have come up and will come up.
• Per the steering committee, all code must be owned by a SIG and have that recorded. That means that as long as Kubernetes owns these a SIG has to be responsible for them. SIG Apps is the current owner. This chartering process isn't attempting to change that.
• The Kubernetes project, which is part of the CNCF, which is part of the Linux Foundation owns these codebases. They are responsible for them and the health of them. They have a responsibility to figure out the healthy and appropriate path forward for them.
• Kubernetes is becoming more focused on the core. The things around the core could all be open to general change policies and there's debate on that. For example, in a general change policy what happens to minikube and dashboard which are not part of the core? A general change that affects Helm and Kompose would also look like it could apply to them as well. So, care is being taken in how any of this is handled.

From a practical standpoint, even though SIG Apps owns these we rarely talk about them in the primary meeting. We attempt to treat them like other ecosystem projects. The development of these projects isn't discussed in the main meeting or mailing list in a way that's different from the development of other ecosystem projects. They have their own meetings and lists to discuss their development.

I expect changes to come. I think there are better ways than what we do today. I'm actively working on some of that. When changes are ready, and have been worked out in the appropriate places, I expect we and others will be amending charters.

[r2d4]

Since these projects are rarely talked about in SIG Apps, then it would have little impact to remove them from the SIG Apps charter.

They can remain CNCF projects without being governed by SIG Apps, so legal ownership is not affected.

[richarddli]

While SIG Apps may not talk about Helm, Kompose, and Charts in the meeting, there is a very practical effect of them being part of SIG Apps charter: namely, people who are new to Kubernetes will automatically try/adopt these tools first. This seems to be in opposition to the "do not endorse one particular ecosystem tool" goal.

I'd also add that these three tools also are not fully representative of the scope of the SIG Apps charter (e.g., they don't do much for developing bespoke services). Including them as the only software projects hosted by SIG Apps creates the appearance of a skew in SIG Apps towards the app operator persona.

I appreciate the challenges of untangling, but I think the effort is very worthwhile if we want the SIG Apps to encompass all app dev stakeholders.

[kow3ns]

That is a good question, but afaik there is no effort underway to move existing projects out of kubernetes. We should not disrupt current projects because we find the timing to be expedient. You could raise a larger issue with SIG governance if you feel there is value in taking inventory of what is currently part of currently governed and reducing that scope.

[mattfarina]

A subproject of Kubernetes MUST be owned by a SIG. For something to shift out of Kubernetes, not needing to be owned by a SIG, but still be in the CNCF requires other governance processes occur. That's not the scope of this current PR and ask of the SIG which is to have a charter.

I am in favor of subprojects such as minikube, helm, and others that are not part of kubernetes core deliverable shifting around organizationally and in the CNCFs overall governance.

Because the process scope for this PR is for SIG Apps to get a charter and making changes to how subprojects associate with Kubernetes and the CNCF is both a different scope and one with other processes along with it requiring a whole lot more conversations and time I would suggest we don't block on that.

If you're not familiar, the relationship of subprojects not part of core Kubernetes and how they fit in the governance both now and long term has had hours of discussions by numerous people including the steering committee. If this blocks on that issue it will block SIG Apps, and possibly other SIGs, from getting a charter for some time.

Open source governance, especially at the scale of Kubernetes with people and vendors, is complicated and can take time to get setup well. The steering committee has a lot to do and part of that is even navigating priorities of what to do. While this isn't a low priority it doesn't appear to be their highest priority right now. That's ok and we can be a little patient. There are also pragmatic things, outside the current governance asks we have right now, that can be worked on and in some cases already are.

If anyone wants to discuss this in further detail I'm happy to.

[r2d4]

Subproject creation and removal is indeed part of this charter

https://github.com/mattfarina/community/blob/a5876519d816b84ca2dc65d0c49c6d0f17cdd74b/sig-apps/Charter.md#project-management

If this isn't actually a SIG Apps decision, then that governance should be moved into a higher level document and not this document.

Otherwise it follows that sub-project addition and removal is within the power of the governing SIG.

I am in favor of subprojects such as minikube, helm, and others that are not part of kubernetes core deliverable shifting around organizationally and in the CNCFs overall governance.

It seems like the co-chairs of SIG Apps also favor the removal of these projects, and it is well within their governing power to do so. I don't see any blockers for this to proceed.

[bgrant0607]

@r2d4 @mhausenblas @richarddli

Please table this here and now. It is not in the purview of SIG Apps to consider whether these subprojects belong within the Kubernetes project. Their current status is that they are, and SIG Apps has been asked to own them.

However, if the charter is going to provide a list of subprojects, I agree it should be exhaustive.

Thanks to @mattfarina for explaining the situation in some detail.

[r2d4]

Thats fair, thanks for the clarification. I'll consider my comments resolved.

[r2d4]

e.g. should be i.e.

[mattfarina]

@r2d4 In this case it's for example (e.g.) rather than that is (i.e.). Jobs is something else SIG Apps owns. There's also the application crd/controller which is being developed under SIG Apps for interoperability purposes.

[kow3ns]

We also own PDB in the policy group. We may own other portions of the API, where appropriate, in the future. We do expect that most development of primitives will now occur as extensions, but as with DeployConfig -> Deployment, when there is universal consensus to move a primitive into a core API type, we may do so.

[r2d4]

Can CRDs be owned by SIG Apps? By definition they are not part of core.

I could see the argument that they can be useful in experimenting with potential core API changes, but I'm not sure how we guarantee that those experiments are short-lived and do not carry on as opinionated tools. Imagine a scenario where SIG Apps maintained a set of CRDs that were highly opinionated and tied to a specific ecosystem tool. These APIs would never have to go through a full community and API review, but would be "official" recommendations of Kubernetes.

Should those experiments instead happen with core alpha APIs that go through full API reviews?

[mattfarina]

Should those experiments instead happen with core alpha APIs that go through full API reviews?

This question went before SIG Architecture for a case similar to what you're describing. It was for an object to describe applications and started as a KEP for a new core API. The idea, and even a CRD, came out of the App Def WG. WGs don't own code so it fell to SIG Apps to own this development.

The process used to be for a core API to start out, go through alphas and betas, and then get to GA. That process is changing as part of the goal to have k8s be slower moving "boring" infrastructure. The direction from SIG Architecture was for this to start outside the core, prove itself, and if it makes sense to later revisit it going into Kubernetes.

The Application object hasn't been the only example of this direction over the past several months.

The App Def WG wanted this in the name of application and tool compatibility. For example, one could deploy two apps. One with Helm and one with ksonnet. Those apps could be viewed with Kubernetes Dashboard and Tectonic's console.

When a SIG wants to rally around projects like this there is a process for them to create and maintain repos.

Because this was in the apps space and had people working on various tools – sometimes from competing companies – SIG Apps chose to work on this problem in the name of tooling compatibility. If it works out well it may end up in the core of Kubernetes long term. Instead of going through the previous alpha/beta phases it's a CRD and controller maintained by the SIG.

This new process of CRD/controllers from the outside going into Kubernetes is new enough we've talked about some of the gaps and unknowns that will need to be overcome.

This is an example of processes on Kubernetes changing a little bit. We've talked about this in SIG Apps to try and communicate it over the past several months.

[bgrant0607]

CRD is a mechanism for building APIs. It is likely that an increasing number of new APIs will be built using that mechanism, and that even current APIs will eventually be migrated to it.

[r2d4]

Do you anticipate SIG Apps owning more core API groups and controllers often? An amendment to the core APIs or Controllers that SIG Apps owns has never happened, so I think that would constitute a charter amendment.

[r2d4]

Sorry for nitpicking, but I actually want this to be as unambiguous of a charter as possible, to clearly demarcate responsibility within the community.

The charter, as an "official" governing document, should clearly lay out what the scope and terms of the charter are.

My suggestion is to remove "For example", since this is logically equivalent to being an incomprehensive list.

[mattfarina]

I think intent is important here. The intent here is not to be a comprehensive list because:

• The apps space is evolving and changing. As that happens and different areas need a different focus SIG Apps needs to be able to shift or shine a light on something. Other SIGs, suck as docs and auth, need to flex a little as well.
• Members of the steering committee, and even beyond that, have expressed a desire to stop the growth in number of SIGs unless there is a good reason. Some have expressed a desire to shrink the number of SIGs. Rigid boundaries provide an easy way to justify more SIGs rather than do work in an existing SIG. This could easily lead to organizational growth.

We can either leave the examples up or remove the section all together. If the examples are removed from the charter we should put them on the Readme to provide some good communication to people.

[richarddli]

How about:

• Discussion of how to define, develop, and run applications in Kubernetes

(Or maybe breaking this out into a separate line. As I read this charter, it seems that discussing the actual development workflow(s) for building apps isn't explicit. To me, the actual development of applications (not just the definition and how to run them) is what spawned some of the current charter conversation.)

[prydonius]

+1

[r2d4]

Subprojects that are part of SIG Apps can have their own governance outside of SIG Apps? What value is SIG Apps providing here?

[mattfarina]

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?

[r2d4]

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

[bgrant0607]

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.

[r2d4]

Is CI/CD in scope for SIG Apps?

[bhack]

/cc @jstrachan

[bhack]

(We need to change soon or later cc bot pattern matching cause is the semi-official mention of github)

[mattfarina]

Is CI/CD in scope for SIG Apps?

Yes. We've talked about CI/CD in the past including demos.

[r2d4]

This is my understanding of the exhaustive scope of SIG Apps. Please correct me if something is out of scope or I missed a category.

Non-core scope

• CI/CD
• SDKs, Platform Development
• Template renderers/expanders
• Dockerfile/Kubernetes manifest generation
• Package management
• Dependency management
• IDE integrations, linters
• Extension controllers
• Application registries / artifact serving
• Workflow tools
• Development/Debugging tools
• Application probes / health checks
• Revision manager with lifecycle hooks
• Image build tools
• Application Definition
• Application "visualization" (monocular)
• Federation (rudder-federation)

Core scope

• Workloads API
• PodDisruptionBudget
• Batch and Apps Controller

[AkihiroSuda]

@r2d4 @kimsterv

Image build tools

Is it going to be covered by Developers Tools WG ? https://groups.google.com/forum/#!topic/kubernetes-sig-apps/PSxfoxhbY2U

If not, can we have a separate SIG/WG for building tools?

[bgrant0607]

I think we need to distinguish between areas owned by SIG Apps that are within scope for the Kubernetes project, like the workload APIs, from things that are discussed within SIG Apps in order to share knowledge, foster interoperability, and provide feedback and generate requirements for areas in scope for Kubernetes. The first sentence specifies "deploying and operating applications in Kubernetes". Building applications and container images, for instance, are not within that scope.

Of the list above, SDKs, Platform Development, and extension controllers likely will be discussed elsewhere.

Container-level probes are a Kubelet feature. I assume this is referring to an aggregate or end-to-end check as discussed in the Application KEP.

Federation is a confusing term to use outside the context of the multi-cluster SIG.

[k8s-ci-robot]

@bhack: GitHub didn't allow me to request PR reviews from the following users: jstrachan.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @jstrachan

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[bgrant0607]

Great start!

[bgrant0607]

I think we need to distinguish between areas owned by SIG Apps that are within scope for the Kubernetes project, like the workload APIs, from things that are discussed within SIG Apps in order to share knowledge, foster interoperability, and provide feedback and generate requirements for areas in scope for Kubernetes. The first sentence specifies "deploying and operating applications in Kubernetes". Building applications and container images, for instance, are not within that scope.

Of the list above, SDKs, Platform Development, and extension controllers likely will be discussed elsewhere.

Container-level probes are a Kubelet feature. I assume this is referring to an aggregate or end-to-end check as discussed in the Application KEP.

Federation is a confusing term to use outside the context of the multi-cluster SIG.

[bgrant0607]

"Demos" isn't an area of responsibility. Describe in terms of the end goal?

[bgrant0607]

CRD is a mechanism for building APIs. It is likely that an increasing number of new APIs will be built using that mechanism, and that even current APIs will eventually be migrated to it.

[bgrant0607]

@r2d4 @mhausenblas @richarddli

Please table this here and now. It is not in the purview of SIG Apps to consider whether these subprojects belong within the Kubernetes project. Their current status is that they are, and SIG Apps has been asked to own them.

However, if the charter is going to provide a list of subprojects, I agree it should be exhaustive.

Thanks to @mattfarina for explaining the situation in some detail.

[bgrant0607]

SIG Apps owns workload APIs and their controllers. "Workloads" are categories of applications, such as stateless, stateful, and batch, rather than specific applications, such as MySQL. If we need new kinds of workload APIs and controllers in the future, SIG Apps would own them. They might fit into existing API groups or require new ones. But the bar for adding new APIs, especially built-in ones, will be fairly high. I believe the current controllers are general enough to cover a wide variety of applications.

I'm inclined to add additional subproject information, such as subproject descriptions, to sigs.yaml rather than into charters. General scope, categories of subprojects, and key example subprojects should be covered in the charter.

[bgrant0607]

Is there a CONTRIBUTING.md doc?

[mattfarina]

There is. You can read it here. Credit @parispittman for getting us to have one.

[bgrant0607]

s/cased/based/

[mattfarina]

fixed

[bgrant0607]

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.

[bgrant0607]

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.

[mattfarina]

We deviate from the template a little here but let me start with the situation.

• We've not had to mediate between sub-projects at the SIG Apps level.
• SIG Apps covers a vast area. The same technical leads for the Workloads API wouldn't make sense to lead Kompose who wouldn't make sense to lead Helm.
• There have never been tech leads at the SIG level over all the SIG things. It would be artificial to add them now and we would be using top down authority to add a power position rather then trying to fill a need.
• There are currently over 30 sub-project owners for SIG Apps. It's hard to have a committee of that size.

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:

Issues impacting multiple subprojects in the SIG should be resolved by SIG Chairs

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.

[smarterclayton]

I think this makes sense, and actually helps in a sense to foster the diversity of ecosystem. I'd be ok with revisiting later.

[derekwaynecarr]

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.

[derekwaynecarr]

ignore above, i see the role is delegated to SIG chairs below.

[bgrant0607]

So SIG Chairs would be the designated approvers of the KEP?

[mattfarina]

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.

[pwittrock]

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?

[mattfarina]

Is any open source tool, library, application for running apps on Kubernetes a candidate?

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

[mattfarina]

@bgrant0607 I updated the goals to try and add clarity about the scope and intent of discussions and where that crosses into action. Can you take a look at the revisions?

/cc @michelleN @prydonius @kow3ns

[smarterclayton]

nit: capitalization on covers

[mattfarina]

Thanks for catching that.

[smarterclayton]

nit: in order to

[mattfarina]

Thanks for catching that one, too

[smarterclayton]

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.

[smarterclayton]

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.

[mattfarina]

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

[pwittrock]

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?

[mattfarina]

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

[bgrant0607]

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.

[mattfarina]

@bgrant0607 That is literally right out of the template. How should we proceed?

I'm not sure what the next steps are. Any guidance?

[philips]

suggested a chair removal process here: #2336

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: philips

Assign the PR to them by writing /assign @philips in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[philips]

Thank you for your patience as we work to your SIG charter merged.

Through the process of reviewing the first 11 charters the Steering Committee (SC) found a lot of copy/paste language caused by our poorly designed initial charter template. To fix this there is a new SIG charter template which focuses on the main things we want to see in charters: scope and responsibilities.

Please consider updating to this charter template and putting focus into the scope and responsibilities. SC members will focus more on a deep review of scope more than anything else and using this template will help with that focus.

[philips]

What is the next step with this charter? Can someone please move it to the new template?

[mattfarina]

To follow the new template I started #2881. Closing this in light of that one.