Slack invite duties

[starbelly]

The initial influx of invites is done and it's now down to 1 a day at best, but usually 1 every few days, and I expect that to decline.

Our current system for processing slack invites isn't great, but it works, we have a ticket for making it better but this isn't a priority either. However, what we need to sort out devoid of the system is who is on call and when. I think between myself and the rest of infrastructure we can cover all the gaps.

Specifically, I would like to figure how a schedule for us as to who is responsible for slack invites during a certain time slot (i.e., Bryan processes invites from hours 11am to 4pm, Benoit processes invites from 4pm to 9pm, etc.).

I'm not sure what level of granurality we need and also don't want to over think this. Perhaps a doodle poll is in order to sort this out. Thoughts?

Regardless, soon I will be adding other members of the infra group back to the email alias slack invites go to.

[benoitc]

I have no time to process such invitations. I would rather find a way to automate it or replace slack. I am still wondering why we still want to use such a closed system. On the other hand would paying for it offer more flexibility? Can it be automated if users are using a specific email address?

[starbelly]

@benoitc no, it can not be automated, not without a lot of effort. It can only be automated if we pay for enterprise grid. The only reason we can automate this for erlanger and lfe is they had existing "legacy tokens", but even those will be hard deprecated at some point.

I'm not terribly interested in talking about slack vs other things within the scope of this issue, that's a separate issue IMO.

Edit:

I should also note again, we're seeing maybe one slack invite every few days now. I haven't got one in a day and some change at this point, thus this isn't a huge responsibility, but it can't be one person's responsibility.

[benoitc]

@starbelly Regardless to that I don't think it is ok to say " soon I will be adding other members of the infra group back to the email alias slack invites go to". Threatening (unpaid) people to add them to a mailing-list without their agreement is not helpful.

Anyway if it's only once a day, I and others may have the time to look at a queue to not read all mails around and decide what have been answered or not. That would certainly help to have a sheet somewhere that can be sorted. Is there a doc somewhere describing what need to be done to invite and what happen when the user is invited. What is the current workflow?

[peerst]

@starbelly I can be quite responsive but definitely not by email. If this would show up in a Slack channel I can cover a lot of ground.

Emails will be just ignored for days if not weeks.

@benoitc it would be cool if not every topic around Slack would contain your ceterum censeo that you dislike it and want it replaced. The people who dislike Slack are a small minority compared to those who like it. But they are a very loud minority and I don’t have bandwith for that anymore

[peerst]

@starbelly Lets just make a channel

https://slack.com/intl/en-de/help/articles/206819278-Send-emails-to-Slack

And whoever volunteers and prefers emails can be added to the alias

[peerst]

I assume these emails are coming from our website and only vetted members can generate them?

[davydog187]

Adding a channel sounds good to me 👍

[benoitc]

@benoitc it would be cool if not every topic around Slack would contain your ceterum censeo that you dislike it and want it replaced. The people who dislike Slack are a small minority compared to those who like it. But they are a very loud minority and I don’t have bandwith for that anymore

I am not sure what you mean. I feel it’s a concern if we don’t look at other alternatives, if they can bring less constraints and less dependencies while keeping the UX ok. Like other corporations that not always choose Slack do. It is not about liking or not but to consider there are others options to use . Even paying for a business plan as I mentioned.

If the solution about maintaining the invitations manually should last, we should really start to think about and plan for it. This is all I’m saying.

[peerst]

The concern is that the communities live in these Slacks now and are being productive. This manual invites are no big concern (or if they are its a luxury problem for EEF because we the we would have members coming in in troves). Even if we provide a alternative people need to adopt them and then there is a phase where the community is split between tools etc. etc. Normally I'm a friend of being proactive but i this case I think the way to go is reactive (e.g. the Erlang and Elixir Slacks get quiet and people are mainly elsewhere).

If it works well enough for us, why fix it? e.g. whenever a credit card of a member doesn't go through I have to hunt them down manually also.

https://xkcd.com/1205/ so daily and 1 minute saved we can only spend 1 person day fixing this one way or another

[starbelly]

@starbelly Lets just make a channel

https://slack.com/intl/en-de/help/articles/206819278-Send-emails-to-Slack

And whoever volunteers and prefers emails can be added to the alias

I like that idea.

[starbelly]

Closing this as resolved per https://github.com/erlef/website/pull/290 and https://github.com/erlef/website/pull/291

[paulo-ferraz-oliveira]

Even if we provide a alternative people need to adopt them and then there is a phase where the community is split between tools etc. etc.

This is good food for thought, and I believe touches the central point why moving should be done slowly and carefully. We are already split between two different Slacks (and several members have already expressed worry about this), let alone split between different tools 😄

Should I create an issue to follow-up on progressively moving everything EEF to its proper Slack? i.e. warn and progressively drop the Erlanger-Slack-based EEF-related channels?

Example:

• Erlang Slack < eef-build-package-wg
• Erlang Ecosystem Foundation Slack < build-and-packaging

(I would've done it already, except I'm not sure if it's the infra-wg than manages Slack)

[paulo-ferraz-oliveira]

These are some of the channels to consider in the "move":

Erlang	Erlang Ecosystem Foundation
beam	no counterpart (not sure it needs to be moved)
beam-langs	no counterpart (not sure it needs to be moved)
eef	general
eef-build-package-wg	build-and-packaging
eef-documentation-wg	I don't think this exists anymore (probably can be archived)
eef-observability-wg	observability
eef-security-wg	security

[peerst]

I think this should be left to the respective WGs and not being imposed on them. Suggesting it is fine though

[paulo-ferraz-oliveira]

I think this should be left to the respective WGs and not being imposed on them. Suggesting it is fine though

Agree. 👍