On 22 April 2018 at 11:04, James Bennett ubernostrum@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@gmail.com | Brisbane, Australia