Skip to content
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

Amend Slack policy to drop support for commercial channels #3771

Open
wants to merge 1 commit into
base: master
from

Conversation

@cblecker
Copy link
Member

commented Jun 4, 2019

Spell out that the open source community Slack should focus on the open source community, and not serve as a support forum for commercial products.

cc: @castrojo @jeefy @mrbobbytables @alejandrox1 @Katharine @jdumars @parispittman @coderanger @idvoretskyi @idealhack

/hold
for discussion

@Katharine

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

I disagree strongly with this - there is absolutely no value to us in dropping these channels, and we lose value to the community in doing so.

We're already too restrictive in creating channels, I have no desire to be more so.

@dims

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

Slightly different thought ... which channels that we currently have that do not fit into this new guideline? (channels that we will have to shut down essentially)

@cblecker

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2019

@Katharine The value of this is, as I see it:

  • Maintaining a manageable scope for the things we support
  • Maintaining upstream neutrality
  • Ensuring that community resources are benefiting the community

As I understand it, Slack is providing a paid instance to us free of charge because we are under the CNCF and a non-profit. It's disingenuous for us to then turn around and provide services on behalf of for-profit entities with those donated resources.

We also don't want to create multiple tiers of services.. such as I go and create the closed source CKS (Christoph Kubernetes Service), but I'm not a "cloud provider" as we've currently determined, so I don't get a channel where as businesses of a certain size do.

If #aks, #gke, #eks, etc want Slack channels for their communities, let them pay for, staff, and moderate them on their own. They don't need the CNCF/Kubernetes project to do that.

@jeefy

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

In the case of the AKS channel: We currently have an EKS and GKE channel in our slack. Suddenly amending policy to disallow that also means we have to shut down and archive the EKS, GKE, and (likely) other channels (@dims beat me to that comment lol)

If we truly want to remove all commercial channels in Slack this requires more than just discussion in a PR, and probably an agenda item on steering as this will be a large user facing change that has wide-ranging implications.

I'm torn on the issue. I fundamentally disagree with the idea that the K8s slack is used for commercial benefit, but I also see restricting channel creation as a step backwards in maintaining an open and welcoming community. If a user wants there to be a channel to talk about , and there are others that want to talk about , why say no unless it breaks the CNCF COC?

I agree w/ @cblecker about getting cloud providers to chip in support for their communities, but I also don't like the idea of forcing the issue at the expense of our users.

@Katharine

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

I don't see the existence of a space for people to discuss things that happen to be commercial as "providing them the company with a service". A channel provides the Kubernetes community with a space to discuss things, and as long as those things are Kubernetes-related I see little reason to constrain what those things would be. As for CKS, we probably wouldn't let you have it if it were open source either because we're arbitrarily restrictive like that (a feature I do not care for). If I personally wanted to update the policy for more fairness, I would just remove the cloud provider constraint.

The cost to us of hosting a Slack channel is zero - there is no limit to the number of slack channels we can have (even if we were on the free tier), there is no cost associated with a slack channel (even if we were paying), and the moderation overhead is negligible.

@jeefy

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

That's the blurred line that needs to be drawn IMO. If it's a channel to talk about Kubernetes on GKE, AKS, etc.... why not create the channel?

These channels might provide some marginal commercial benefit but ultimately it's about the users connecting with each other and maybe there are some employees that can answer questions. The channels, from what chatter I've ever seen, have been more about collaboration and answering questions than any real commercial pushing or benefit.

@cblecker

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2019

I don't see the existence of a space for people to discuss things that happen to be commercial as "providing them with a service".

I'm sure Slack, who normally charges for the tier of service we are on, would disagree with you. If the cloud providers want to provide a free tier, then as I said, let them create/staff/moderate their own.

This also has wider ranging implications for upstream neutrality, as well as optics on how we use upstream resources. If I donate resources of any type to a non-profit, I would expect them to be used by that non-profit.. not for the benefit of a commercial, for-profit entity.

If we truly want to remove all commercial channels in Slack this requires more than just discussion in a PR, and probably an agenda item on steering as this will be a large user facing change that has wide-ranging implications.

This PR was meant to serve as step one in a discussion. Slack is currently exclusively under the purview of contribex. We have the first right to make decisions. However, if we can't reach a consensus, then involving steering is entirely appropriate.

@cblecker

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2019

@dims The ones I see right now looking at the slack config are:

  • aks
  • digitalocean-k8s
  • eks
  • gke
  • linode
  • rancher
@Katharine

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

I'm sure Slack, who normally charges for the tier of service we are on, would disagree with you. If the cloud providers want to provide a free tier, then as I said, let them create/staff/moderate their own.

This feels like something of a leap, given that we have had these channels for literally the entire existence of the slack workspace.

I see no harm whatsoever in permitting people to discuss things that happen to be commercial. I think it's also significantly stretching to describe that as us providing them with support.

@castrojo

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

We've been having this discussion for a while now and are working with CNCF via steering specifically so that we would not need to drastically change the k8s slack from how it is being run today.

@coderanger

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2019

I think we should separate some of these concerns. Part one is the drum both Jorge and I have been banging for a while that we should explicitly remove non-contributor-related channels from the auspices of contribex. They would still be under the management of the Slack admin team, which is currently under contribex but with a very different mission :) Part the second, we should be clear that commercial entities should not use Slack as an official place to conduct business. Read: Our Slack should not replace them having ZenDesk or whatever for official user support. Part III, providing a place for users of commercial products to gather and support each other is definitely within our overall scope and mission for Slack as it exists today (again, the original scope under contribex was different but that ship has pretty sailed). And if representatives from those vendors are here to help out as user-to-user communication, they are as welcome as anyone else.

A corollary of part one is figuring out better ways to keep the vendor community involved in the spaces that indirectly benefit them. But between Katharine's (💯) tools and having a less burnt-out Slack admin team I think moderation is at least a stable issue, even if I would like to see it improve.

As for existing channels, it all gets really fuzzy. Is the #traefik channel against this rule? It's both an open source project and a commercial product. Ditto on Rancher for that matter. And re: AKS in particular, large portions of it are open via aks-engine. So even if we are blocking 100% proprietary (which I disagree with), I think they might still have a case.

@mrbobbytables

This comment has been minimized.

Copy link
Member

commented Jun 5, 2019

Thanks for summarizing everything so well @coderanger. I agree that as it stands today, there is still a place for them as long as they remain user-to-user focused and it is clear that it is not an official support channel. I'd refrain from changing the current policies too much till things shake out with the "end user group/community experience" thing proposal with SC.

@jaypipes
Copy link
Contributor

left a comment

++

- Private channels with the exception of: code of conduct matters, mentoring,
security/vulnerabilities, github management, or steering committee.
security/vulnerabilities, GitHub management, or steering committee.

This comment has been minimized.

Copy link
@jaypipes

jaypipes Jun 6, 2019

Contributor

Just curious, but what's the reasoning behind having the steering committee channel be private? Or is this just stating that some steering committee conversations may be private due to discussions around licensing, legal, etc?

This comment has been minimized.

Copy link
@castrojo

castrojo Jun 6, 2019

Contributor

I think it's just a realtime extension of the steering-private list, which is used when people need to bring up sensitive topics to steering: https://github.com/kubernetes/steering/blob/master/CONTRIBUTING.md#non-members

This comment has been minimized.

Copy link
@jaypipes

jaypipes Jun 6, 2019

Contributor

ack, that's what I figured... thanks @castrojo! :)

Channels should not be focused on a single company, commercial product, or
commercial service. Community members seeking support for these products should
contact the company offering the product or service through their regular
support channels.

This comment has been minimized.

Copy link
@jaypipes

jaypipes Jun 6, 2019

Contributor

👍

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cblecker, jaypipes

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

@jaypipes

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

This also has wider ranging implications for upstream neutrality

☝️ this is what it's all about for me, personally. But I agree it's a grey area.

I see the point that @Katharine is making.

Another thing to think about: if the #eks channel is dropped, would users simply ask support-related questions on #sig-aws? If the #aks channel dropped, would users just ask on #sig-azure, etc.

Going to remove my approval since I'm more on the fence about this than I originally thought ;)

@jaypipes
Copy link
Contributor

left a comment

finer line than I originally thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.