AWS - bans customers when criticized

[ghost]

AWS - bans customers when criticized

I work for and represent an AWS customer (at least until we migrate our spend elsewhere). On Tuesday August 15th I posted an issue to the EFS CSI Driver repo complaining about a lack of attention from AWS, the 'semi-official' maintainers.

I won't tell you that I was nice in this issue, but it did not contain any personal attacks, harassment, or (in my opinion) otherwise violate the Kubernetes Code of Conduct.

Kubernetes has an official Code of Conduct Committee that is responsible for enforcing the CoC. While I did not break the CoC, if AWS felt that I had broken it the appropriate path of action would be to report the issue to the Code of Conduct Committee for their judgement.

Unfortunately AWS employee @dims could not deal with the fact that I correctly and publicly stated the fact that his company contributes so little to the EFS CSI Driver they have only merged 3 PRs this entire year, despite the fact there are 34 PRs waiting for review. Even when external contributors stepped up to make up for AWS's lack of contribution they couldn't even be bothered to click "Merge".

Instead of trying to address this lack of contribution, @dims decided to slander me on the Kubernetes slack, calling me a "bot" (obvious lie) to get my account banned from the Kubernetes GitHub organization: https://kubernetes.slack.com/archives/C01672LSZL0/p1692205708101969

Kubernetes Code of Conduct Committee is a lie - Kubernetes GitHub admins will ban you just because somebody at AWS doesn't like you

AWS would rather spend their time getting customers banned than merging PRs that have been open for over a year

[ghost]

AWS - bans customers when criticized

I work for and represent an AWS customer (at least until we migrate our spend elsewhere). On Tuesday August 15th I posted an issue to the EFS CSI Driver repo complaining about a lack of attention from AWS, the 'semi-official' maintainers.

I won't tell you that I was nice in this issue, but it did not contain any personal attacks, harassment, or (in my opinion) otherwise violate the Kubernetes Code of Conduct.

Kubernetes has an official Code of Conduct Committee that is responsible for enforcing the CoC. While I did not break the CoC, if AWS felt that I had broken it the appropriate path of action would be to report the issue to the Code of Conduct Committee for their judgement.

Unfortunately AWS employee @dims could not deal with the fact that I correctly and publicly stated the fact that his company contributes so little to the EFS CSI Driver they have only merged 3 PRs this entire year, despite the fact there are 34 PRs waiting for review. Even when external contributors stepped up to make up for AWS's lack of contribution they couldn't even be bothered to click "Merge".

Instead of trying to address this lack of contribution, @dims decided to slander me on the Kubernetes slack, calling me a "bot" (obvious lie) to get my account banned from the Kubernetes GitHub organization: https://kubernetes.slack.com/archives/C01672LSZL0/p1692205708101969

Kubernetes Code of Conduct Committee is a lie - Kubernetes GitHub admins will ban you just because somebody at AWS doesn't like you

AWS would rather spend their time getting customers banned than merging PRs that have been open for over a year

[torredil]

Hey @murphypuppy, thanks for reaching out.

Our team strives to deliver the latest CSI driver improvements and security fixes to the community as soon as possible. That’s why we have two release pipelines for the CSI driver: self-managed for security conscious customers, and the EKS managed add-on for those who place a premium on ease-of-use. Unfortunately, the EKS managed add-on requires additional validation, which sometimes delays its availability.

That said, we continue to look for ways to make the gap between these two releases both shorter and more predictable. As always, thanks for the feedback. We really do appreciate you pushing us to keep raising the bar. Sorry for the inconvenience (again).

[ghost]

AWS - bans customers when criticized

I work for and represent an AWS customer (at least until we migrate our spend elsewhere). On Tuesday August 15th I posted an issue to the EFS CSI Driver repo complaining about a lack of attention from AWS, the 'semi-official' maintainers.

I won't tell you that I was nice in this issue, but it did not contain any personal attacks, harassment, or (in my opinion) otherwise violate the Kubernetes Code of Conduct.

Kubernetes has an official Code of Conduct Committee that is responsible for enforcing the CoC. While I did not break the CoC, if AWS felt that I had broken it the appropriate path of action would be to report the issue to the Code of Conduct Committee for their judgement.

Unfortunately AWS employee @dims could not deal with the fact that I correctly and publicly stated the fact that his company contributes so little to the EFS CSI Driver they have only merged 3 PRs this entire year, despite the fact there are 34 PRs waiting for review. Even when external contributors stepped up to make up for AWS's lack of contribution they couldn't even be bothered to click "Merge".

Instead of trying to address this lack of contribution, @dims decided to slander me on the Kubernetes slack, calling me a "bot" (obvious lie) to get my account banned from the Kubernetes GitHub organization: https://kubernetes.slack.com/archives/C01672LSZL0/p1692205708101969

Kubernetes Code of Conduct Committee is a lie - Kubernetes GitHub admins will ban you just because somebody at AWS doesn't like you

AWS would rather spend their time getting customers banned than merging PRs that have been open for over a year

[mikestef9]

Clarifying the position here. This 100% unrelated to security. In fact, security is one of the core value propositions of EKS add-ons, where all software installed through EKS add-ons is known to be tested and validated by AWS. This ultimately comes down to internal issues that slow down the release process from GitHub to EKS add-ons. It is a top priority to reduce this gap (shorter term to 3 business days, longer term to zero gap).

We'll leave this issue open to track progress on these improvements.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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.