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 <chr...@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 > > <whatwouldausti...@gmail.com <mailto:whatwouldausti...@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 <julianf...@apache.org > > <mailto:julianf...@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-unsubscr...@community.apache.org > > <mailto:dev-unsubscr...@community.apache.org> > > > For additional commands, e-mail: dev-h...@community.apache.org > > <mailto:dev-h...@community.apache.org> > > > > > > > > > >
