[Distutils] Improving Communication

Brett Cannon brett at python.org
Sat Apr 21 19:51:23 EDT 2018

I know this is no shock to Donald, but I agree with what he brings up
below. One of motivators for trying out python.zulipchat.com is to see if
it's real-time nature on top of topic-based discussion could act as a
cross-section for email and IRC.

For me, either something like Zulip or Discourse takes care of a lot of the
issues raised. They provide modern tooling, allow for a central place to
communicate, and allow for sectioning things into streams/sections to
prevent overwhelming e.g. a single mailing list.

On Fri, Apr 20, 2018, 19:08 Donald Stufft, <donald at stufft.io> wrote:

> Currently in the packaging space, we have a number of avenues for
> communication, which are:
> - distutils-sig
> - pypa-dev
> - virtualenv-users
> - Other project specific mailing lists
> - IRC
> - gitter
> - Various issue trackers spread across multiple platforms.
> - Probably more places I’m not remembering.
> The result of this is that all discussion ends up being super fractured
> amongst the various places. Sometimes that is exactly what you want (for
> instance, someone who is working on the wheel specs probably doesn’t care
> about deprecation policy and internal module renaming in pip) and sometimes
> that ends up being the opposite of what you want (for instance, when you’re
> describing something that touches PyPI, setuptools, flit, pip, etc all at
> once).
> Theoretically the idea is that distutils-sig is where cross project
> reaching stuff goes, IRC/gitter is where real time discussion goes, and the
> various project mailing lists and issue trackers are where the project
> specific bits go. The problem is that often times doesn’t actually happen
> in practice except for the largest and most obvious of changes.
> I think our current “communications stack” kind of sucks, and I’d love to
> figure out a better way for us to handle this that solves the sort of weird
> “independent but related” set of projects we have here.
> From my POV, a list of our major problems are:
> * Discussion gets fractured across a variety of platforms and locations,
> which can make it difficult to actually keep up with what’s going on but
> also to know how to loop in someone relevant if their input would be
> valuable. You have to more or less simultaneously know someone’s email,
> Github username, IRC nick, bitbucket username, etc to be able to bring
> threads of discussion to people’s attention.
> * It’s not always clear to users where a discussion should go, often times
> they’ll come to one location and need to get redirected to another
> location. If any discussion did happen in the incorrect location, it tends
> to need to get restarted in the new location (and depending on the specific
> platform, it may be impossible to actually redirect everyone over to the
> proper location, so you again, end up fractured with the discussion
> happening in two places).
> * A lot of the technology in this stack is particularly old, and lacks a
> lot of the modern day affordances that newer things have. An example is
> being able to edit a discussion post to fix typos that can hinder the
> ability of others to actually understand whats being talked about. In your
> typical mailing list or IRC there’s no mechanism by which you can edit an
> already sent message, so your only option is to either let the problem ride
> and hope it doesn’t trip up too many people, or send an additional message
> to correct the error. However these show up as additional, later messages
> which someone might not even see until they’ve already been thoroughly
> confused by the first message (since people tend to read email/IRC in a
> linear fashion).
>   - There is a lot of things in this one, other things are things like
> being able to control in a more fine grained manner what email you’re going
> to get.
>   - Holy crap, formatting and typography to make things actually readable
> and not a big block of plaintext.
> * We don’t have a clear way for users to get help, leaving users to treat
> random issues, discussion areas, etc as a support forum, rather than some
> place that’s actually optimized for that. Some of this ties back into some
> of the earlier things too, where it’s hard to actually redirect discussions
> These aren’t *new* problems, and often times the existing members of a
> community are the least effected becasue they’ve already spent effort
> learning the ins and outs and also curating a (typically custom) workflow
> that they’ve grown accustomed too. The problem with that is that often
> times that means that new users are left out, and the community gets
> smaller and smaller as time goes on as people leave and aren’t replaced
> with new blood, because they’re driven off but the issues with the stack.
> A big part of the place this is coming from, is me sitting back and
> realizing that I tend to be drawn towards pulling discussions into Github
> issues rather than onto the varying mailing lists, not because that’s
> always the most appropriate place for it, but because it’s the least
> painful place in terms of features and functionality. I figure if I’m doing
> that, when I already have a significant investment in setting up tooling
> and being involved here, that others (and particularly new users) are
> likely feeling the same way.
> - Donald
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180421/1c219d68/attachment-0001.html>

More information about the Distutils-SIG mailing list