Draft update to Python Packaging Governance

My (long) two cents: I see a fundamental problem with the concept of governance that spans multiple projects.

Governance over a single project seems straightforward to me. A project seeks to meet a need in the ecosystems it’s relevant to, and corresponding goals are relatively straightforward to define. (Note that these goals comprise both technical and non-technical aspects; e.g., the latter include diversity and contributor experience.) Stakeholders can disagree with regard to the definition and prioritization of those goals, and on the best methods to achieve them; but, ultimately, there is a singular entity around which goals are defined and that entity is a clear ‘center of gravity’ for the governance.

I don’t see how this works for governance over multiple projects—at least, for governance that tries to direct the projects it’s governing. We have examples of well-established entities that are succeeding in supporting multiple projects: Linux Foundation, Apache Foundation, NumFOCUS, and more. But while they may place some constraints on projects in order for those projects to remain under their umbrellas, they are not governing the projects, in terms of defining the totality of the technical and non-technical goals for those projects to strive toward.

I believe that this is the fundamental and unresolvable problem that’s been styming Python packaging governance discussion: that governance of a collective of projects is not viable.

Why should a pip maintainer (who is not also a twine maintainer) have a direct vote over how twine does things?

Does our pip maintainer have deep knowledge of twine? Of its technical goals? Of its technical needs? Of the health of its community? Etc. It seems to me that the answer to all of these questions is “no,” and thus the answer to the prior question is “they shouldn’t.”

Instead, I think we should redirect our efforts toward a focus on:

  1. Standards
    • See my comment on the ‘What do you want?’ thread for a slice of my thoughts here
  2. User-persona-specific tooling recommendations
    • Like what pyOpenSci is doing for packaging for Python newcomers, but repeated many times over for different user stories
      • This likely needs to be a community effort more than a centralized one
  3. Non-opinionated resources for informing the community w.r.t. what tools are available
    • These are basically awesome lists, but with more focus on ‘list’ than ‘awesome’
    • A big part of the power of open source is innovation
    • But, with rapid innovation comes the information problem of not knowing what tools are out there
      • Note: I know there’s a strong desire for “one-tool-to-rule-them-all”, to reduce this information problem but in my view centralization (as distinct from standardization) is antithetical to innovation
    • So: regularly updated, highly visible information sources about the current state of the tooling ecosystem in a given area are key to mitigate the information problem amid rapid innovation
    • As best I understand, awesome lists are more or less the best tool we currently have to approach this challenge
2 Likes