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

Update SIG Architecture charter.md #2074

Closed
wants to merge 1 commit into
base: master
from

Conversation

@jdumars
Member

jdumars commented Apr 25, 2018

@jdumars jdumars requested a review from bgrant0607 Apr 25, 2018

@k8s-ci-robot k8s-ci-robot requested a review from calebamiles Apr 25, 2018

@jdumars jdumars requested review from cblecker and removed request for calebamiles Apr 25, 2018

@jdumars

This comment has been minimized.

Member

jdumars commented Apr 25, 2018

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.

@bgrant0607

This comment has been minimized.

Member

bgrant0607 commented Apr 26, 2018

* Defined in[ sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454)
* SIG Technical Leads

This comment has been minimized.

@smarterclayton

smarterclayton Apr 26, 2018

Contributor

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

This comment has been minimized.

@smarterclayton

smarterclayton Apr 26, 2018

Contributor

Arbitration might be something to pull up, since arguably that's the entire point is to help mediate at a deeper level.

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

+1 - See also above.

@bgrant0607

Added notes from SIG Arch meeting

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.

This comment has been minimized.

@bgrant0607

bgrant0607 Apr 26, 2018

Member

TODO: collapse into fewer subprojects

* Defined in[ sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454)
* SIG Technical Leads

This comment has been minimized.

@bgrant0607

bgrant0607 Apr 26, 2018

Member

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

This comment has been minimized.

@mattfarina

mattfarina Apr 26, 2018

Member

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?

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

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.

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

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.

This comment has been minimized.

@brendandburns

brendandburns Apr 27, 2018

Contributor

I would also add something about decision making when there are technical/design conflicts inside of or between SIGs.

This comment has been minimized.

@quinton-hoole-2
SIG Architecture’s subprojects are as follows. [sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml) contains links to their OWNERS.
<table>

This comment has been minimized.

@brendandburns

brendandburns Apr 27, 2018

Contributor

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.

This comment has been minimized.

@philips

philips Jul 3, 2018

Contributor

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

This comment has been minimized.

@brendandburns

brendandburns Apr 27, 2018

Contributor

I think we should just say "3" that way we don't have ties.

This comment has been minimized.

@quinton-hoole-2
* 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.

This comment has been minimized.

@brendandburns

brendandburns Apr 27, 2018

Contributor

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.

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

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

This comment has been minimized.

@brendandburns

brendandburns Apr 27, 2018

Contributor

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

This comment has been minimized.

@brendandburns

brendandburns Apr 27, 2018

Contributor

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

This comment has been minimized.

@brendandburns

brendandburns Apr 27, 2018

Contributor

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.

This comment has been minimized.

@quinton-hoole-2

@bgrant0607 bgrant0607 changed the title from Update charter.md to Update SIG Architecture charter.md May 18, 2018

@cblecker cblecker removed their request for review May 20, 2018

@jdumars jdumars referenced this pull request Jun 24, 2018

Open

Charters Meta-issue #31

@bgrant0607

This comment has been minimized.

Member

bgrant0607 commented Aug 7, 2018

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.

@bgrant0607 bgrant0607 closed this Aug 7, 2018

* **Chair**
* Number: 2-3

This comment has been minimized.

@quinton-hoole-2
* 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.

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

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.

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

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

  1. 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.
  2. 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.
  3. 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.

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

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

This comment has been minimized.

@quinton-hoole-2

quinton-hoole-2 Oct 11, 2018

No objection to this, but it seems like it belongs in the overall project governance charter (sttering committee) than in a specific sig charter.

@quinton-hoole-2

This comment has been minimized.

quinton-hoole-2 commented Oct 11, 2018

Can we /reopen this and get it done?

@jdumars

This comment has been minimized.

Member

jdumars commented Oct 11, 2018

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.

@quinton-hoole-2

This comment has been minimized.

quinton-hoole-2 commented Oct 11, 2018

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.

@quinton-hoole-2

This comment has been minimized.

quinton-hoole-2 commented Oct 11, 2018

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.

@cblecker cblecker reopened this Oct 15, 2018

@cblecker cblecker closed this Oct 15, 2018

@k8s-ci-robot

This comment has been minimized.

Contributor

k8s-ci-robot commented Oct 15, 2018

[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: jdumars

If they are not already assigned, you can assign the PR to them by writing /assign @jdumars 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:

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

@cblecker

This comment has been minimized.

Member

cblecker commented Oct 15, 2018

Sorry for noise. Fiddling with this to delete stale upstream branch.

@cblecker cblecker deleted the sig-arch-charter branch Oct 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment