Re: ASF Slack for community?

[Austin Bennett <wh...@gmail.com>]

Dear Infra:

Can you please confirm we would not be terrible community members by using
the slack for our stated and intended purpose?

Since this is an event to grow the community, we need to ensure the uptime
of s.apache.org/slack-invite throughout, so verifying we are playing nicely
to avoid issues (for pettier individuals or if viewed as not playing nice,
I would be very concerned about that uptime, because downtime during the
event would have negative consequences for growing the Beam [and by
relation, collaboration] the Apache community.  Also, ASF is also a
"community partner" for the event, for whatever that is worth.


Furthermore, letting this start a kickoff for discussion if useful to
establish up an additional link or method to track, ex:
s.apache.org/beam-summit-slack-invite - if we are worried about [desire
for] attributing signups.  I suspect that's overkill (and would rather
not), but am willing to code that up for the foundation, if that helps this
get done.

Thanks,
Austin




P.S.  Thanks, Roy.




On Mon, Jul 27, 2020 at 10:31 AM Roy Lenferink <rl...@apache.org>
wrote:

> Also keep in mind that Slack uses a Fair Billing Policy [1]. You won't be
> billed for inactive members (inactive being if a member didn't use its
> Slack account in over 14 days).
> Having a certain number of users join during/after a conference they
> probably all have useful input for the Beam community (code, documentation,
> presentation or as a potential Beam user).
> In the first couple of weeks after the conference most of that input will
> probably be collected (the yay factor for new projects). And if not they
> will probably go inactive and you won't be billed for them.
>
> So I agree with Austin here, does the cost of adding the users outweigh
> the addition of potential new contributors.
>
> Also, if the cost of Slack is becoming too much for the ASF (don't know if
> we have a sponsored instance?), how about e.g. Mattermost [2][3] as a
> self-hosted alternative (or only for conferences) ? Just throwing some
> ideas out there..
>
> - Roy
>
> [1]
> https://slack.com/intl/en-nl/help/articles/218915077-Fair-Billing-Policy
> [2] https://github.com/mattermost/mattermost-server
> [3] https://mattermost.com/
>
> Op ma 27 jul. 2020 om 18:31 schreef Austin Bennett <
> whatwouldaustindo@gmail.com>:
>
>> Hi All,
>>
>> My intent would be to use this ASF Resource for communication of
>> potential newcomers to the Beam community (and with the hope that they
>> become involved with the foundation overall), looking to state that
>> clearly.
>>
>> Cost is a reasonable argument -- but I need to question whether the
>> financial costs outweigh the potential benefits, and therefore looking to
>> make explicit the purpose of the Slack Community, if this is something we
>> are going to be told not to do.
>>
>>
>> As a thought exercise/perspective; please bear with the following -->
>>
>> * I have been in the ASF Slack long before I was a committer on the
>> project.
>> * There is lots of activity in the ASF Slack Beam channels from
>> non-committers (and a way to identify future committers, based on positive
>> interactions with the community).
>> * I lead workshops (in most cases personal free/volunteer time) on
>> getting involved with contributing to OpenSource/ASF/Beam, and I certainly
>> point all attendees to the training to ASF Slack channel (as well as
>> mailing lists) -- should I not be doing that?
>>
>> One potentially useful, but not great analogy would be traditional
>> funnels and conversion rates -- would like to build a funnel and community
>> for Beam (and serving ASF more generally), people that are
>> interested/curious, some of which will convert to maintaining activity ->
>> learning more -> chatting with others -> contributing
>> docs/use-case/bugs/code -> becoming committers -> etc...  In that light,
>> you can see how there are benefits for this to be the start of an
>> interaction and journey for people to get involved with the foundation?
>> That is at least my goal/motivation.
>>
>> How do we distinguish users in this case (say anyone I point to the Slack
>> channels as a way to start following a community and getting involved in
>> discussions), from a broader conference attendee (in the cases, such
>> workshops are often at conferences)?  Why would we exclude people/purpose?
>>
>> Do my aims make sense?  Is growing the ASF community in this manner not
>> supported by the infrastructure?  If Slack is not a useful common tool that
>> we can point anyone to, should we be using it?  Or, at least can someone
>> provide clear bounds on what is OK and not OK to be doing with it?
>>
>> Proposal: we use this slack channel for the BeamSummit, and learn how it
>> goes.
>> If concerned about persisting user accounts, perhaps can we configure an
>> alternate link (if given permissions, I am willing) and we can track the
>> signups through that link [ s.apache.org/
>> <http://s.apache.org/slack-invite>temp-slack-invite ] - and
>> auto-expire/delete their account after 30 days (or some interval) without
>> some additional requirements to keep them as users.  It seems the fear is
>> around accounts getting created that are not used and costing money.  I
>> suspect (a) there are alot of inactive accounts, and (b) that we should be
>> supporting the growing community in the same place.
>>
>> Thanks for bearing with this long message.
>> Austin
>>
>> On Tue, Jul 21, 2020 at 12:15 PM Chris Thistlethwaite <ch...@apache.org>
>> wrote:
>>
>>> Infra discussed this at our last team meeting. Currently the way Slack
>>> invites work via s.apache.org/slack-invite sends out an invite to
>>> become
>>> a full member of the-asf.slack.com. You can read a bit more about this
>>> at https://infra.apache.org/slack.html. The issue with that is members
>>> (Slack Members NOT ASF Members) then cost money for the ASF, which will
>>> be hard to track and forecast if every project starts using the-asf
>>> workspace as a conference meet-up area. There's not an official way to
>>> invite someone as a Single Channel Guest to Slack without their email
>>> address. There's no URL they can visit to get an invite. There are
>>> products out there that use a deprecated Slack API, but they aren't well
>>> maintained and Slack can turn off the API whenever they want. So as of
>>> this writing, we're recommending against using the-asf.slack.com for
>>> mass conference invites.
>>>
>>> We tried a workaround of sharing a channel with apachecon.slack.com,
>>> however you can't share a channel from a paid Slack instance to a free
>>> instance.
>>>
>>> I'm just throwing out ideas, but if you had a list of email addresses
>>> for attendees, you could bulk invite everyone as a Single Channel Guest
>>> (they'd just have access to #beam). Then they get the added bonus of
>>> being apart of the official Slack instance, can talk in the #beam
>>> channel as needed and if they become a committer to Beam then they could
>>> be "upgraded" to a full member account. Again, I'm just throwing it out
>>> there as no one has ever really talked about the process/workflow of a
>>> large group being dumped into Slack.
>>>
>>> -Chris T.
>>> #asfinfra
>>>
>>> On 7/18/20 8:01 AM, Matthias Baetens wrote:
>>> > Thanks for bringing this to the ComDev mailing list, Austin. As part
>>> > of the Beam Summit org team, I am in strong favour of making this part
>>> > of the ASF Slack with the goal of growing the Beam community there and
>>> > expose people to the ASF overall, over splintering the community over
>>> > different Slack channels - this with the assumption in mind that it is
>>> > ok from an infrastructure POV. As community events grow (and hopefully
>>> > budget with it), I'd even propose we try and share burden of cost in
>>> > that direction in the future.
>>> >
>>> > On Fri, 17 Jul 2020 at 15:49, Austin Bennett
>>> > <whatwouldaustindo@gmail.com <ma...@gmail.com>>
>>> wrote:
>>> >
>>> >     Thanks, Julian,
>>> >
>>> >     Ultimately, my question comes down to: is it OK to point people
>>> >     interested
>>> >     in events for specific (in this case Beam) events to the
>>> communication
>>> >     platform used by the wider asf community.  I figure it is ideal to
>>> >     expand
>>> >     the overall Apache tent/community.  Though there are certainly
>>> >     tradeoffs.
>>> >
>>> >     Unless needed, the question of which platform for the foundation
>>> >     to use
>>> >     seems a separate discussion.
>>> >
>>> >     Cheers,
>>> >     Austin
>>> >
>>> >
>>> >
>>> >
>>> >     On Thu, Jul 16, 2020 at 9:03 AM Julian Foad <julianfoad@apache.org
>>> >     <ma...@apache.org>> wrote:
>>> >
>>> >     > On behalf of FOSS fans everywhere: please seriously consider
>>> using
>>> >     > [Matrix], the Open federated standard system.  It's perfect for
>>> this
>>> >     > sort of community, with bridges to Slack and IRC and many other
>>> >     systems.
>>> >     >   In the last two years Matrix has leapt ahead of other
>>> >     contenders like
>>> >     > XMPP and is becoming the Open system of choice adopted by
>>> >     organisations
>>> >     > from Mozilla to universities and governments.
>>> >     >
>>> >     > It's a great platform for integrating the chat side, and even the
>>> >     > presentation side through Jitsi, of online events.  The matrix
>>> >     devs do
>>> >     > it and wrote a blog post describing how:
>>> >     > https://matrix.org/docs/guides/running-online-events
>>> >     >
>>> >     > Before any of us risks pushing another FOSS community into the
>>> >     > proprietary silo trap, let's pause and consider how we all would
>>> >     in fact
>>> >     > be paying for it if it's "free as in beer".  I've been watching
>>> this
>>> >     > space since five years ago when the FOSS alternatives were weak,
>>> >     and now
>>> >     > I'm really excited to see that, with the overwhelming global
>>> >     need for
>>> >     > such a thing, Matrix has grown strong and is accelerating
>>> rapidly.
>>> >     >
>>> >     > I would strongly encourage the ASF membership to deploy their
>>> >     own Matrix
>>> >     > server ASAP as it's the perfect fit for this sort of
>>> >     organization.  I
>>> >     > run a personal Matrix server and benefit from modern multi-device
>>> >     > single-app access to all my IRC messaging (via a public bridge),
>>> >     all my
>>> >     > WhatsApp messaging (via a private bridge), some private notes
>>> like
>>> >     > diaries, as well as federated native Matrix messaging.
>>> >     >
>>> >     > I can give more detailed advice and put you in touch with
>>> specific
>>> >     > contacts.
>>> >     >
>>> >     > - Julian
>>> >     >
>>> >     >
>>> >     > See:
>>> >     >
>>> >     > * https://matrix.org -- for an introduction to Matrix
>>> >     >
>>> >     > * https://matrix.org/docs/guides/running-online-events -- see
>>> above
>>> >     >
>>> >     > * https://element.io/blog/welcome-to-element/ -- for an
>>> >     introduction to
>>> >     > the top company/brand of Matrix services and apps (a bit like
>>> >     how Redhat
>>> >     > is to Linux)
>>> >     >
>>> >     > * https://sifted.eu/articles/element-germany-deal/ -- news
>>> about big
>>> >     > government deployments of Matrix
>>> >     >
>>> >     >
>>> >
>>>  ---------------------------------------------------------------------
>>> >     > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>>> >     <ma...@community.apache.org>
>>> >     > For additional commands, e-mail: dev-help@community.apache.org
>>> >     <ma...@community.apache.org>
>>> >     >
>>> >     >
>>> >
>>>
>>>