git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Concerns about the Arrow Slack channel


Not to jump in too randomly, but for jupyter-widgets/bqplot
<https://github.com/bloomberg/bqplot> - we haven't found an optimal
solution to this.

- The dev mailing list is often considered to be intrusive
- GitHub issues arent really used for simple questions or non-bug fixes
- Gitter remains our most popular source of questions, which suffers a lot
of the problems of Slack outlined in Wes' email

We're considering discuss forums, specially after the large success of the
PyTorch <https://discuss.pytorch.org> and MXNet <https://discuss.mxnet.io>
forums for building community, allowing comfort in asking simple questions
and being stored/googleable

Dhruv

On Thu, Jun 21, 2018 at 4:25 AM, Wes McKinney <wesmckinn@xxxxxxxxx> wrote:

> hi all,
>
> I wanted to bring up some concerns I have about the Slack room hosted
> at http://apachearrow.slack.com.
>
> Corporate communications have changed a lot in recent years with the
> new wave of IRC-like chat systems such as HipChat and Slack. In many
> companies, Slack has become a preferred form of communication over
> e-mail or other asynchronous messaging tools. This trend is negatively
> impacting Apache Arrow in some ways that I will explain.
>
> Initially we created the Arrow Slack channel as a means of secondary
> communication, to facilitate real-time discussions and help build the
> community. So people, particularly newcomers, are coming to the
> project and seeing 4 ways to communicate:
>
> * dev@ Mailing list
> * JIRA
> * GitHub
> * Slack
>
> As a result of broader trends in the world, they are electing to use
> Slack as their first, primary channel to interact with the project.
> This is bad for many reasons:
>
> * Slack is essentially private. While anyone can join Slack, chats are
> not archived in any public place, nor are they searchable through
> internet search portals. I do not think it meets the public
> communication requirements of Apache projects in general
> * We've exceeded the message limit for free Slack channels; upgrading
> to a paid Slack plan for Apache Arrow, with 650+ members, would be
> very expensive
> * Only 3 out of the top 20 Arrow contributors (by # of commits) are
> regularly on the Slack channel. I don't use Slack, for example, and I
> would rather not be expected to
> * We are geo-distributed in many time zones; even if we all used
> Slack, synchronous/real-time chat to discuss the project is frequently
> impractical
>
> Because of the "real-time" nature of IRC-like systems, people's
> discussions and questions get intermingled, so keeping track of
> longer-running discussions may be difficult. It's hard to know when
> someone's question has been answered or whether people have
> sufficiently discussed a particular topic.
>
> Many discussions or questions are by their nature asynchronous, and it
> may take 24-72 hours or more for Arrow contributors to make a
> thoughtful reply.
>
> As a result of all of this, we are missing opportunities to have
> deeper discussions, develop the Arrow roadmap, create new JIRAs to
> capture bug reports or feature requests, and other activities of
> healthy open source communities. Additionally, the private nature of
> Slack is causing organizational knowledge (particularly Q&A / FAQs) to
> essentially be lost. Users with questions won't stumble on answers by
> searching on Google (as they would with a mailing list or
> StackOverflow).
>
> I don't think Slack is necessarily bad for users in a corporate
> environment; in many companies it is expected that all people will
> have the Slack client open at all times. This isn't the case here,
> though.
>
> My strong preference in light of the activity I have been observing on
> Slack (which I encourage you to explore yourselves) would be to close
> the channel and direct discussions or questions take place on the
> mailing list, JIRA, or GitHub (all of which are archived on one or
> more ASF mailing lists). Since migrating to Gitbox, we have enabled
> GitHub issues on the repository, which has helped lower the barrier
> for newcomers, but a large percentage of the time GitHub issues would
> be better as JIRA issues or e-mails (which is what the GitHub issue
> template says, alas).
>
> Interested to hear the thoughts of others on this.
>
> Thanks,
> Wes
>