Request: Add ehashman as SIG Node approver

[ehashman]

What type of PR is this?

/kind cleanup
/sig node

What this PR does / why we need it:

Adds ehashman as a SIG Node approver, and cleans up a bunch of node OWNERS files to user the approver alias rather than adding myself to them manually. (no longer necessary)

We need more SIG Node approvers!

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

• Reviewer of the codebase for at least 3 months
  • Since January 2021: Request: Add ehashman as sig-node-reviewer #98036
• Primary reviewer for at least 10 substantial PRs to the codebase
• Reviewed or merged at least 30 PRs to the codebase
  • As of writing I have commented on over 500 SIG Node PRs: https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+commenter%3Aehashman+label%3Asig%2Fnode
• Nominated by a subproject owner: @derekwaynecarr
  • With no objections from other subproject owners
  • @Random-Liu
  • @dchen1107
  • @derekwaynecarr
  • @yujuhong
  • @sjenning
  • @mrunalp
  • @klueska
  • Done through PR to update the top-level OWNERS file: this PR

/cc @Random-Liu @yujuhong @sjenning @mrunalp @klueska
/assign @dchen1107 @derekwaynecarr

/assign @tallclair
I removed you from some OWNERS files as an approver per discussion on Slack.

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

@ehashman: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[sjenning]

+1 from me

[mrunalp]

👍

[derekwaynecarr]

+1

look forward to your continued collaboration in SIG.

[dims]

+1 from me (non-binding!)

[haircommander]

big +1, very well deserved (non-binding)

[xiaoxubeii]

👍

[klueska]

+1 (binding)

[odinuge]

+1 (non-binding)

[tallclair]

lgtm for owners changes. Thanks!

[rphillips]

+1 (non-binding)

/lgtm

[wzshiming]

/remove-lifecycle stale

[gjkim42]

+1 from me (non-binding)

[dims]

Assigning to @Random-Liu @yujuhong @dchen1107 as they haven't chimed in yet. This has been a while, can you please leave a note here one way or another?

[dchen1107]

Sorry for not updating the PR with the latest status here.

We discussed this at SIG Node meeting several times in year 2021 (1 ,2 3), and the community felt that we don't have a clear criteria written in doc for SIG Node reviewers and approvers.

Several approvers also felt both K8s level criteria and SIG Node previous criteria might not apply to today's SIG Node community. The former one is too abstract given the complexity which SIG Node managed, and the community rejected several requests based on SIG Node's previous criteria in the past; the later one is too strict and staled which requires driving several features / projects from end-to-end given today's node components' maturities. We agreed to update criteria based on today's situation, and most of the important is writing them down so that we can apply the same criteria to all applicants. We had a draft written, which is currently under the final review by @derekwaynecarr. I believe Derek did update all those changes with Elana. Please correct me if I were wrong there, Derek.

Because missing that newly written criteria being published, this request wasn't merged. But the request didn't completely halt. At sig Node, we also agreed that the top level node approval might be too hard and too powerful given the complexity of the system, we decided to break it down to subprojects. Given the big contributions to SIG Node community, @ehashman and @SergeyKanzhelev are the subprojects' approvers.

All above I said doesn't imply Elana didn't meet the SIG Node's new bar. IMO I think she already did if I remembered the new changes correctly. But we need to publish that criteria first, and Elana need to update this request against the new ones to move forward.

[dims]

@derekwaynecarr @dchen1107 +1 to publishing the criteria. Please let me know how i can help get it out quickly.

@dchen1107 thanks for the full context which was missing before! definitely appreciate that.

[249043822]

+1 from me (non-binding)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[justaugustus]

/remove-lifecycle stale

@derekwaynecarr @dchen1107 +1 to publishing the criteria. Please let me know how i can help get it out quickly.

@derekwaynecarr @dchen1107 -- Do we have an update on publishing SIG Node approver criteria?

This PR has been opened for almost a year and I don't think that's fair to @ehashman.
cc: @kubernetes/steering-committee

[endocrimes]

xref kubernetes/community#6612

I've also asked for a final review of the draft document again this week.

[derekwaynecarr]

@endocrimes see kubernetes/community#6725

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ehashman]

/remove-lifecycle stale

[ehashman]

I've reviewed the new SIG Node Contributor Ladder guidelines. I believe that I qualified for approver under these guidelines prior to their drafting and adoption, at the time of my application, and that I continue to qualify.

As I attempted to fill out each bullet point, detailing my contributions to the SIG, I found it increasingly difficult to feel excited about working in a SIG with a contributor ladder whose bar was repeatedly moved shortly after my approver application was submitted. I do not feel that the SIG leadership blocking my application has clearly communicated to me, in public or private, what I needed to do for my application to move forward, and perhaps that is by design. Per the Node Contributor Ladder Guidelines, "No amount of documentation can formalize how this trust is established." (kubernetes/community/sig-node/sig-node-contributor-ladder.md)

After taking a period of extended leave from all Kubernetes contributions, I find myself wanting to prioritize work on areas of the project that are open to welcoming new contributors, encouraging their growth, and accepting new leaders.

From the bottom of my heart, I thank everyone in SIG Node and the wider community that supported my application and hope to work with you in other areas of the project!