Sumana Harihareswara
2018-01-16 19:29:32 UTC
TL;DR: what should we fix or set up to make it easier for you to hack on
Warehouse, especially with a goal of a Warehouse/packaging sprint at
PyCon in May?
The Warehouse team wants to make PyPI more sustainable, including
getting more people as regular code contributors. It's not bad as is --
there's a Docker Compose developer environment setup[0] and we're
reasonably responsive on GitHub and on IRC in #pypa-dev on Freenode. But
I want to check whether there are other things we ought to do to attract
and retain contributors (who are already skilled at Python and
contributing to FLOSS more generally -- we have to walk before we can run).
I'm looking for smaller tasks since we do need to concentrate most of
our efforts in the next few months on the immediate launch. In
Sumana's-gut-prioritization order:
1) Setup: have any of you had trouble in the last few weeks when trying
to get a developer setup going? If so, we should fix our
configuration/documentation.
2) Testing: Are there things that would be easy to add to some linters
or our continuous integration/codecov configuration that would help
contributors get faster and better feedback on pull requests?
3) Documentation: What bits of Warehouse feel mysterious or hard to
navigate? Developers who are new to a codebase need is to know *the
design rationale* of confusing bits -- why it was made this way, what
decisions are embedded in particular choices, whether particular
components are the result of a feature request, a quick fix after an
outage, an experiment, etc.
Here I think the next step is to use the answers to this question,
update our application structure overview[1] and/or to write something
like Zulip's architecture summary[2] or curate a list-of-links
(conference talks, blog posts, etc.) that would get us 30% of the way
towards a history and application overview like MediaWiki's.[3]
4) Setup, part II: could we do what Zulip does[4] and get setup with
turnkey hosted droplets/VMs for use at sprints and for people with
lower-end laptops and network connections?
And of course if I've missed some category of barrier that's gotten in
your way, please speak up.
[0] https://warehouse.readthedocs.io/development/getting-started/
[1] https://warehouse.readthedocs.io/application/
[2]
https://zulip.readthedocs.io/en/latest/overview/architecture-overview.html
[3] http://aosabook.org/en/mediawiki.html
[4] https://zulip.readthedocs.io/en/latest/development/request-remote.html
Warehouse, especially with a goal of a Warehouse/packaging sprint at
PyCon in May?
The Warehouse team wants to make PyPI more sustainable, including
getting more people as regular code contributors. It's not bad as is --
there's a Docker Compose developer environment setup[0] and we're
reasonably responsive on GitHub and on IRC in #pypa-dev on Freenode. But
I want to check whether there are other things we ought to do to attract
and retain contributors (who are already skilled at Python and
contributing to FLOSS more generally -- we have to walk before we can run).
I'm looking for smaller tasks since we do need to concentrate most of
our efforts in the next few months on the immediate launch. In
Sumana's-gut-prioritization order:
1) Setup: have any of you had trouble in the last few weeks when trying
to get a developer setup going? If so, we should fix our
configuration/documentation.
2) Testing: Are there things that would be easy to add to some linters
or our continuous integration/codecov configuration that would help
contributors get faster and better feedback on pull requests?
3) Documentation: What bits of Warehouse feel mysterious or hard to
navigate? Developers who are new to a codebase need is to know *the
design rationale* of confusing bits -- why it was made this way, what
decisions are embedded in particular choices, whether particular
components are the result of a feature request, a quick fix after an
outage, an experiment, etc.
Here I think the next step is to use the answers to this question,
update our application structure overview[1] and/or to write something
like Zulip's architecture summary[2] or curate a list-of-links
(conference talks, blog posts, etc.) that would get us 30% of the way
towards a history and application overview like MediaWiki's.[3]
4) Setup, part II: could we do what Zulip does[4] and get setup with
turnkey hosted droplets/VMs for use at sprints and for people with
lower-end laptops and network connections?
And of course if I've missed some category of barrier that's gotten in
your way, please speak up.
[0] https://warehouse.readthedocs.io/development/getting-started/
[1] https://warehouse.readthedocs.io/application/
[2]
https://zulip.readthedocs.io/en/latest/overview/architecture-overview.html
[3] http://aosabook.org/en/mediawiki.html
[4] https://zulip.readthedocs.io/en/latest/development/request-remote.html
--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc