[Distutils] Improving Communication
Nick Coghlan
ncoghlan at gmail.com
Sat Apr 21 23:50:15 EDT 2018
On 22 April 2018 at 11:04, James Bennett <ubernostrum at gmail.com> 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 | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG
mailing list