Re: [Distutils] Improving Communication

[Steve Piercy - Website Builder]

My first impression of Zulip was "this feels like Slack".  It is 
visually busier than Discourse, and I had a harder time 
understanding context.  I had to step up the font twice to read 
it.  I couldn't find how to hide the user list.  I felt lost.  
Based on my first impressions, I probably wouldn't engage via Zulip.


I had a negative first impression with Discourse, too, as "yet 
another forum software", but it grew on me.  Dozens of UX 
details were done just right, like "I wonder how I can do this 
thing... oh, there it is!".  Or it could have been the Plone 
community is engaging, or a wealth of information already 
existed by the time I joined.


--steve


On 4/22/18 at 1:19 PM, w...@stevepiercy.com (Steve Piercy - 
Website Builder) pronounced:


I am an email and IRC recidivist.  I have to admit that ever 
since I joined the Plone community forum which uses Discourse, 
I have been more engaged with that community than I would have 
otherwise.  I can choose which topics interest me, forget the 
rest, and explore things that might interest me at some point 
in the future.  It also has a wealth of information easily 
searchable and accessible.


I noticed that my wireless carrier uses Discourse as well, and 
I've found it exceptionally helpful to solve my phone problems 
quickly, compared to the phone manufacturer's craptastic help experience.


I haven't tried Zulip yet, but I just signed up to compare it to Discourse.

I don't know what challenges might be for self-hosting.  
Perhaps those who have experience with self-hosting either 
Discourse or Zulip could share?


--steve


On 4/21/18 at 11:51 PM, br...@python.org (Brett Cannon) pronounced:


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.


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy  Website Builder  Eugene, OR
   


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy  Website Builder  Eugene, OR
   

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[Steve Piercy - Website Builder]

I am an email and IRC recidivist.  I have to admit that ever 
since I joined the Plone community forum which uses Discourse, I 
have been more engaged with that community than I would have 
otherwise.  I can choose which topics interest me, forget the 
rest, and explore things that might interest me at some point in 
the future.  It also has a wealth of information easily 
searchable and accessible.


I noticed that my wireless carrier uses Discourse as well, and 
I've found it exceptionally helpful to solve my phone problems 
quickly, compared to the phone manufacturer's craptastic help experience.


I haven't tried Zulip yet, but I just signed up to compare it to Discourse.

I don't know what challenges might be for self-hosting.  Perhaps 
those who have experience with self-hosting either Discourse or 
Zulip could share?


--steve


On 4/21/18 at 11:51 PM, br...@python.org (Brett Cannon) pronounced:


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.


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy  Website Builder  Eugene, OR
   

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[Nick Coghlan]

On 22 April 2018 at 11:04, James Bennett  wrote:
> Pulling in a sort-of success story from another large project, I like the
> general way things happen in Django.
>
> For developers proposing an idea or fixing a bug:
>
> * There's IRC (#django-dev) for quick, synchronous-ish discussion, useful
> for someone to find a sounding board for an idea
> * There's a dev mailing list where proposals can be discussed a bit more
> formally
> * There's the public ticket tracker as a place to follow work being done
>
> And for users seeking help or general discussion:
>
> * There's IRC (#django) and a users mailing list
> * There's an official-ish subreddit moderated by committers
> * And there's the rest of the internet, including Stack Overflow, which we
> can't moderate but which many experienced people in the community do pay
> attention to
>
> We've avoided using GitHub issues for Django, preferring the workflow tools
> we get from our own customized Trac instance.

Right, and this is pretty similar to the way CPython works as well
(just with Roundup in place of Trac, and without any form of official
subreddit).

The challenge for PyPA is that it's not a single project with a single
coordinated release cycle, and instead a fairly sprawling federation
of projects that we stick a single label on to indicate that we're all
working together to advance the state of the art in the Python
packaging ecosystem.

Much of that organisational complexity then gets exposed directly to
end users, since we're deliberately aiming for a model where "X is the
obvious default option, but also not your only option" across the
different parts of the stack (e.g. "X" is "pip" for package
installation, "pipenv" for application dependency management, "devpi"
for dependency caching, "twine" for artifact publication,
"setuptools-but-we're-actively-seeking-to-change-that" for artifact
creation, etc).

Something I suggested to Donald in a related discussion is that trying
to solve this kind of problem for "the PyPA" as a whole may be trying
to tackle too much complexity at once, and it may be better to instead
focus specifically on deliberately designing new communication
channels for PyPI/Warehouse.

My rationale for that suggestion was based on a few different points:

* as a production web service designed primarily for the needs of a
single instance, PyPI/Warehouse is the *least* well served of all of
PyPA's projects when it comes to the status quo (other PyPA projects
at least share the notion of "releases" and "redistributors" with
CPython)
* as a production web service, PyPI is *best* positioned of all of
PyPA's projects to guide new users to the appropriate communication
channels (now that pypi.python.org redirects to pypi.org)
* PyPI has backend web service administrators actively involved in
maintaining it, which means they're well-positioned to evaluate
options that involve running extra PSF-hosted systems or integrating
with additional external services
* Warehouse is relatively young by the standards of other components
of the ecosystem (especially relative to CPython itself), so it has
less internal community inertia to overcome (the inertia mostly exists
at the points where Warehouse interfaces with the wider Python
community, such as distutils-sig and the PEP process)

So I think if we explicitly say that we consider the Warehouse project
completely free to define communications and design processes that
work well for Warehouse *contributors*, then adopting those new
approaches can also be considered for the upcoming "PyPI download API
2.0" and "PyPI upload API 2.0" discussions, rather than requiring that
those latter discussions take place on distutils-sig. The onus would
then be on those of us that wanted to participate in the API 2.0
design discussions to adapt to the Warehouse community's chosen
toolset, rather than requiring that those discussions be restricted to
the existing toolset.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[Wes Turner]

On Saturday, April 21, 2018, James Bennett  wrote:

> Pulling in a sort-of success story from another large project, I like the
> general way things happen in Django.
>
> For developers proposing an idea or fixing a bug:
>
> * There's IRC (#django-dev) for quick, synchronous-ish discussion, useful
> for someone to find a sounding board for an idea
>

#pypa (Freenode manages these)


> * There's a dev mailing list where proposals can be discussed a bit more
> formally
>

https://mail.python.org/mailman/listinfo/distutils-sig (still not sure who
volunteered to manage these)

https://groups.google.com/forum/m/#!forum/pypa-dev (or this)


> * There's the public ticket tracker as a place to follow work being done
>

https://github.com/pypa/setuptools/issues
https://github.com/pypa/pip/issues
https://github.com/pypa/warehouse/issues
https://github.com/pypa/twine/issues
https://github.com/pypa/virtualenv/issues

https://github.com/pypa/packaging-problems/issues



>
> And for users seeking help or general discussion:
>
> * There's IRC (#django) and a users mailing list
>

GitHub.com/pypa//new
  label: Question

#pypa
distutils-sig


> * There's an official-ish subreddit moderated by committers
> * And there's the rest of the internet, including Stack Overflow, which we
> can't moderate but which many experienced people in the community do pay
> attention to
>

https://stackoverflow.com/questions/tagged/pip
https://stackoverflow.com/questions/tagged/pypi
https://stackoverflow.com/questions/tagged/virtualenv
https://stackoverflow.com/questions/tagged/python-packaging

Thanks to the people who host and handle these questions.


> We've avoided using GitHub issues for Django, preferring the workflow
> tools we get from our own customized Trac instance.
>
> I wonder whether something similar -- a real-time chat for
> discussion/sounding board/etc., mailing list to bring things to once
> they've been thought about a bit, public tracker for following
> work/archival purposes -- would work for packaging.
>

Should there, in addition to #pypa IRC and gitter, be a zulip topic (?) for
pypa?

AFAIU, Zulip started at Dropbox, is written in Python, supports boots, and
is functionally similar to Slack, Gitter, and MatterMost?


>
> (I am also wary of too much "process"; Django has a fair bit, and more
> than I'd ideally like, but my experience has been that process and
> participation are generally inversely correlated)
>

Better yet, fork and send a pull request (PR)?
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[James Bennett]

Pulling in a sort-of success story from another large project, I like the
general way things happen in Django.

For developers proposing an idea or fixing a bug:

* There's IRC (#django-dev) for quick, synchronous-ish discussion, useful
for someone to find a sounding board for an idea
* There's a dev mailing list where proposals can be discussed a bit more
formally
* There's the public ticket tracker as a place to follow work being done

And for users seeking help or general discussion:

* There's IRC (#django) and a users mailing list
* There's an official-ish subreddit moderated by committers
* And there's the rest of the internet, including Stack Overflow, which we
can't moderate but which many experienced people in the community do pay
attention to

We've avoided using GitHub issues for Django, preferring the workflow tools
we get from our own customized Trac instance.

I wonder whether something similar -- a real-time chat for
discussion/sounding board/etc., mailing list to bring things to once
they've been thought about a bit, public tracker for following
work/archival purposes -- would work for packaging.

(I am also wary of too much "process"; Django has a fair bit, and more than
I'd ideally like, but my experience has been that process and participation
are generally inversely correlated)
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[Ben Finney]

Wes Turner  writes:

> On Friday, April 20, 2018, Donald Stufft  wrote:
>
> > Currently in the packaging space, we have a number of avenues for
> > communication […]
>
> GitHub Team Discussions [1]
> […]
> - Unfortunately, they're not real time like IRC/Gitter

Another unfortunate thing about GitHub as a forum is that it's
centralised, not community-owned, and is closed for those who don't want
to have that specific gatekeeper corporation mediating their
communication with the community.

Feeding data silos is something we should be discouraging (i.e. make
effort to not go further along that path) for community-owned projects
like Python.

So, while we currently have some commitment to that particular data
silo, we should IMO not increase that and instead should move to
decentralised, community-owned platforms for community discussion.

-- 
 \   “Facts are meaningless. You could use facts to prove anything |
  `\that's even remotely true!” —Homer, _The Simpsons_ |
_o__)  |
Ben Finney

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[Brett Cannon]

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,  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 

Re: [Distutils] Improving Communication

[Wes Turner]

On Saturday, April 21, 2018, Wayne Werner  wrote:

>
>
> On Fri, Apr 20, 2018, 9:54 PM Wes Turner  wrote:
>
>>
>>
>> On Friday, April 20, 2018, Donald Stufft  wrote:
>>
>>>
>>>
>>> * 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).
>>
>>
>> Issues, Pull Requests, Wikis, and Team Discussions are all editable.
>>
>
> Though one thing I've noticed is that a lot of issues get created and
> responded to via email clients that hide the existing message so someone
> will say "I agree" or worse, +1, and then there's 400 line of email. I
> don't know if GH has fixed the display on those things yet.
>
> FWIW.
>

There's now mobile reaction support; so you can click 'view on github' in
the email footer and thumbs up/down a message.

GitHub just added Hide and Edit comment options for maintainers:

https://blog.github.com/2018-04-18-new-tools-for-open-source-maintainers/#minimized-comments

Trimming replies is a lot of work on a mobile device:
- With a keyboard, shift- selects complete lines
- You can also , + to select text

Generally, I try and follow up and clean up formatting and remove any email
signature footer after email-replying to add a comment to a GitHub issue.

There are mobile GitHub apps; though sometimes not replying until I have a
real keyboard is the better option... Far preferable to it.


>
> -W
>
>>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[Wayne Werner]

On Fri, Apr 20, 2018, 9:54 PM Wes Turner  wrote:

>
>
> On Friday, April 20, 2018, Donald Stufft  wrote:
>
>>
>>
>> * 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).
>
>
> Issues, Pull Requests, Wikis, and Team Discussions are all editable.
>

Though one thing I've noticed is that a lot of issues get created and
responded to via email clients that hide the existing message so someone
will say "I agree" or worse, +1, and then there's 400 line of email. I
don't know if GH has fixed the display on those things yet.

FWIW.

-W

>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

[Nick Coghlan]

On 21 April 2018 at 12:53, Wes Turner  wrote:
[Donald wrote]
>> * 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).
>
> IDK how many times we've discussed upgrading mailman to add per message
> footer links to relayed messages. Google Groups has this feature on by
> default.

While it's only a small piece of the larger puzzle, I've finally
written to distutils-sig-owner about initiating an upgrade to MM3 for
the list. That's far from solving the fractured communications
problem, but it will at least give distutils-sig itself an integrated
web gateway.

I also filed https://github.com/pypa/packaging-problems/issues/141 to
note that it's currently really unclear who's actually handling the
list admin responsibilities for distutils-sig.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig