Update SIG Architecture charter.md #2074
Conversation
k8s-ci-robot
added
size/L
jdumars
added
committee/steering
|
I want to note that there is some contention around the wording for company representation in the Technical Leads role description. That conversation was not brought forward in the PR. At issue is whether technical leads are limited to only one per company. |
|
|
||
| * Defined in[ sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454) | ||
|
|
||
| * SIG Technical Leads |
There was a problem hiding this comment.
Scope of jurisdiction could be qualified (as discussed in SIG call)
|
|
||
| * The initial set of technical leads is a subset of the long-standing group of API approvers: Clayton Coleman, Tim Hockin, and Brian Grant | ||
|
|
||
| * Technical leads MUST have a demonstrated mastery, proficiency, and review history in the project sufficient to assess their ability to arbitrate highly technical and project-wide decisions |
There was a problem hiding this comment.
Arbitration might be something to pull up, since arguably that's the entire point is to help mediate at a deeper level.
There was a problem hiding this comment.
+1 - See also above.
|
|
||
| Issues specific to a particular component or functional area, which would be the purview of some other single SIG, are out of scope for SIG Architecture, except where they deviate from project-wide principles and conventions, or are not yet being addressed, as discussed above. | ||
|
|
||
| SIG Architecture’s subprojects are as follows. [sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml) contains links to their OWNERS. |
There was a problem hiding this comment.
TODO: collapse into fewer subprojects
|
|
||
| * Defined in[ sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454) | ||
|
|
||
| * SIG Technical Leads |
There was a problem hiding this comment.
TODO: Reevaluate role name and responsibilities
|
|
||
| * Technical leads *MAY* decide to step down at anytime and propose a replacement, who must be approved by all of the other technical leads | ||
|
|
||
| * All technical leads cannot be from a single company |
There was a problem hiding this comment.
The notion of a majority not being from a single company was in the Google doc and something not resolved. It does tie into the scope and naming TODOs. Once those are resolved could we revisit the affiliation of the position?
There was a problem hiding this comment.
Yes, I was the one who raised the request for no single-company super-majority (which is what's in the proposal as it stands). The details of the motivation are in the relevant comments in the doc. I'd like to re-raise that issue here.
There was a problem hiding this comment.
I added more detail in the comment above.
| * Document who owns conformance definition, profiles, etc. | ||
| ## Mission | ||
|
|
||
| The Architecture SIG maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time. |
There was a problem hiding this comment.
I would also add something about decision making when there are technical/design conflicts inside of or between SIGs.
There was a problem hiding this comment.
|
|
||
| SIG Architecture’s subprojects are as follows. [sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml) contains links to their OWNERS. | ||
|
|
||
| <table> |
There was a problem hiding this comment.
You can do table's in markdown:
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#tables
Let's avoid HTML if at all possible.
There was a problem hiding this comment.
Can we just expand the sigs.yaml schema to generate these tables?
Sigs.yaml is already generating https://github.com/kubernetes/community/tree/master/sig-architecture#subprojects
|
|
||
| * **Chair** | ||
|
|
||
| * Number: 2-3 |
There was a problem hiding this comment.
I think we should just say "3" that way we don't have ties.
|
|
||
| * Chairs *MUST* remain active in the role and are automatically removed from the position if they are unresponsive for > 3 months and *MAY* be removed by consensus of the other Chairs and all of the Technical leads if not proactively working with other Chairs to fulfill responsibilities. | ||
|
|
||
| * A majority of chairs cannot be from a single company. If a chair’s change of company affiliation causes this threshold to be exceeded, one of the chairs must step down and propose a replacement, as per the procedure above. |
There was a problem hiding this comment.
I think we should say "you can not have more than one chair from any one company"
Given 2 or 3 chairs that's implicitly true anyway.
There was a problem hiding this comment.
I'm fine with that. "A majority of chairs" was my wording, and intended to be more future-proof, and resilient to changes in the number of chairs.
|
|
||
| * The initial set of technical leads is a subset of the long-standing group of API approvers: Clayton Coleman, Tim Hockin, and Brian Grant | ||
|
|
||
| * Technical leads MUST have a demonstrated mastery, proficiency, and review history in the project sufficient to assess their ability to arbitrate highly technical and project-wide decisions |
There was a problem hiding this comment.
I think we need better specificity/clarity on how they demonstrate this. The statement is fairly vague and could be used to exclude people.
|
|
||
| * Technical leads MUST have a demonstrated mastery, proficiency, and review history in the project sufficient to assess their ability to arbitrate highly technical and project-wide decisions | ||
|
|
||
| * Technical leads *MUST* remain active in the role and are automatically removed from the position if they are unresponsive for > 3 months |
There was a problem hiding this comment.
More clarity on what "unresponsive" means. As written, simply replying to an email might count as "responsive" but I don't think that's what we want/mean.
|
|
||
| * Technical leads *MAY* decide to step down at anytime and propose a replacement, who must be approved by all of the other technical leads | ||
|
|
||
| * All technical leads cannot be from a single company |
There was a problem hiding this comment.
As with chairs I think we should say: "Each tech. lead must be from a different company"
Given the importance of the position and it's cross-cutting impact, I think diversity of opinion is critical here.
|
As discussed in the last SIG Arch meeting, closing for now. Will reopen after subproject and role discussions, with an update to the new charter template. |
|
|
||
| * **Chair** | ||
|
|
||
| * Number: 2-3 |
|
|
||
| * Resolve cross-subproject technical issues and decisions, and escalations from subprojects | ||
|
|
||
| * Decision-making MUST be by consensus. It’s particularly important for the technical leads to provide cohesive technical guidance for the project as a whole. |
There was a problem hiding this comment.
It's important to have a fallback plan when consensus cannot be reached within a reasonable time, to prevent granting implicit veto rights to any tech lead. I propose 2/3 majority vote as that fallback.
There was a problem hiding this comment.
More comprehensive discussion here: https://docs.google.com/document/d/1p4quG5qzIllQ52eKIb7mGrgaiRgQeiu70iJi9MZ9C8c/edit?disco=AAAAB7Yujow
Here are the most pertinent points, repeated:
Quinton: I'd be fully in support of language seeking diversity in general, and company diversity in particular. A few other points to add (most of which I raised at the meeting):
- The number stated above is three. My strong suggestion of avoiding single-company majority was made primarily in that context, although it works well for other numbers too (i.e. it conveys what I was explicitly intending to convey), e.g. 1 of 2 is not a majority, 2 of 3 is both a majority and a super-majority, 2 of 4 is not a majority, etc.
- I feel quite strongly that we need to set an example amongst SIG's by not having a single company hold a majority (or super-majority) of Chair or Tech Lead seats. As currently stated, a super-majority would give a single company the ability select additional chairs, make majority decisions amongst chairs, and disproportionately drive conversations. I don't think we want any of these.
- I realize that currently Jaice and Brian are the chairs of this SIG, and both work for Google, and therefore one of the two would need to be replaced by a non-Googler in order to achieve the stated goal of non-majority. This may be uncomfortable, but I think it's worth the discomfort in order to set a good example.
Jaice, could you explain your rationale for wanting to keep the wording as is?
Jaice:
Quinton, thank you for your continued concern here. In short I believe any of the hegemony concerns can be allayed through requiring consensus on decisions. This would give any company veto power on decisions, regardless of who has the majority of membership. Also, I would argue that if the chair position is "powerful" then we have done this incorrectly. People should not be seeking the position to have control or bragging rights, and we need to disincentivize that in any way possible, or we are walking into a known anti-pattern. The chair is a servant leadership position that handles SIG-related administrivia. Even the agenda document has no write restrictions, so the only privileged access a chair has is to the Zoom account and lead-related mailing lists. I would welcome more voices and opinions here.
Quinton:
s the wording stands right now, fallback in the case of lack of (lazy) consensus is a majority (or supermajority) vote by chairs. I think that's the right approach and preferable to vetos. I would just like to ensure that the majority or supermajority vote cannot be carried by a single company, against all others. That's why I want "a majority of chairs cannot be held by a single company".
I still do not understand the argument against that. Sure we could cling to the idea of allowing a single company to hold the supermajority of chair positions, and adjust all the other rules to accommodate that (e.g. allowing vetos or requiring consensus). But that's far more fraught with problems, IMO.
Jaice:
Quinton, I gave this a lot of thought and I am willing to withdraw my objections based on our intent to do a 6 month refresh of this document. I understand the implication on the current structure will mean either Brian or myself stepping down. I want for us to work on making this position servant leadership, with no privileges attached. I concede that in the current implementation that is not as true as I wished it was. We can discuss this in greater detail at the next SIG meeting.
|
|
||
| * Chairs *MUST* remain active in the role and are automatically removed from the position if they are unresponsive for > 3 months and *MAY* be removed by consensus of the other Chairs and all of the Technical leads if not proactively working with other Chairs to fulfill responsibilities. | ||
|
|
||
| * A majority of chairs cannot be from a single company. If a chair’s change of company affiliation causes this threshold to be exceeded, one of the chairs must step down and propose a replacement, as per the procedure above. |
There was a problem hiding this comment.
I'm fine with that. "A majority of chairs" was my wording, and intended to be more future-proof, and resilient to changes in the number of chairs.
|
|
||
| * *SHOULD* be facilitated by chairs unless delegated to specific Members | ||
|
|
||
| * TODO: The SIG MUST make a best effort to provide leadership opportunities to individuals who represent different races, national origins, ethnicities, genders, abilities, sexual preferences, ages, backgrounds, levels of educational achievement, and socioeconomic statuses |
There was a problem hiding this comment.
No objection to this, but it seems like it belongs in the overall project governance charter (sttering committee) than in a specific sig charter.
|
Can we /reopen this and get it done? |
|
This is in the wrong format and needs to be completely redone. There was agreement that we needed to better understand what it is we actually do before codifying it as well. I can start working on the new charter format, and porting things over to it. |
|
OK, thanks. There's been a lot of valuable input on both this PR, and on the original word doc, some of which has been lost along the way. Lets please make sure that it doesn't get lost again if we move it to a third location. |
|
Perhaps a better approach would be to get this PR merged (I think we're almost there), and then work on a followup PR, just to change the formatting. We've been working on this for >6 months. It would be good to get something agreed upon and merged, and then iterate on relatively more minor formatting changes. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: If they are not already assigned, you can assign the PR to them by writing 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:
Approvers can indicate their approval by writing |
|
Sorry for noise. Fiddling with this to delete stale upstream branch. |
This is content drawn from the pre-draft at https://docs.google.com/document/d/1p4quG5qzIllQ52eKIb7mGrgaiRgQeiu70iJi9MZ9C8c/edit#heading=h.wdtj408qqhsx