I agree. The lack of any substantial results from the first discussion has certainly put me off investing any time or energy into the second and any subsequent ones.
Couple of suggestions that have come in regarding how to proceed with these strategy discussions, that I feel I need to clarify what I see as the expected deliverable from these 5 strategy threads (2 completed, 3 planned).
The 5 topics for strategy discussions were chosen based on feedback from the user survey and key observations around how this community works. The strategy discussions are a way to validate whether each strand should be taken further. This is the reason why each prompt has been a low ball question to gauge how strong the signal is for each prompt. They are not meant to be deep-dives that would end in a white paper.
The expected deliverable from these 5 threads is a high-level strategy document that will indicate which threads (workstream) we will be pursuing in depth and who will be working on each workstream. I expect this deep-dive to produce the policy doc/white paper/technical roadmap that is expected by many in this thread. Generally, I expect the strategy to look like this
Next 3-6 months- Produce high-level strategy doc, set up workstreams and working group for each workstream, define objectives and deliverables for each working group
Next 1 year- Deep dive into each workstream, targeted user surveys as suggested by multiple people in this thread, options analysis and building consensus for the chosen solution(s), define technical roadmap
Next 2-5 years- Develop solutions and deliver
I do not expect the deep-dive to take one year but building consensus might take a year. I have to see how each thread plays out in the community before we get to the point of developing the white paper. The suggestions regarding user surveys and policy docs that have come in via this thread are perfectly valid but it is too soon to do it right away, at least in my opinion.
This thread is definitely getting off topic (I know that because I’m sure I just replied to some of these comments on another thread )
Shamika’s post seems to be the last on-topic one.
So how do we feel about this as the outlined approach?
A post was merged into an existing topic: Python packaging documentation feedback and discussion
Personally, I find it disappointing, if I’m honest. Workstreams and working groups doesn’t sound like the sort of thing I’d expect in volunteer-driven open source work. It feels too “management heavy”, and I don’t like the implication that things get done “in private” (I imagine working groups will use face to face calls and similar, which are much better high-bandwidth ways of having discussions, but they do exclude non-participants, even in the best cases).
On a personal note, I want to be involved in this work, but I cannot imagine staying motivated over 18 months of nothing but discussions, planning and consensus building. I think it’s the wrong approach, and I’d much rather we identified and worked on small, independent changes that produce measurable, incremental improvements. Basically, the classic agile approach.
I’m also bothered by the idea that we can somehow just magically find resources for these workstreams. Many of the people doing the most work in the packaging ecosystem don’t participate heavily in these discussions, because they are busy actually developing tools. We don’t want to divert them from that, but equally, what use is a working group that doesn’t include the key players?
Sorry. I don’t want to be negative, but that’s my honest view…
I do not think this makes sense. Who out of the people working on Python packaging will still be here 5 years from now? Especially volunteers who just come and go as time, energy, and motivation permit. Who will ensure continuity of this work over 5 years? I feel like this is the wrong approach entirely.
How can this be applied to volunteers?
I guess, probably I am just not the target audience at all for this message, and I am missing a lot of context.
I have mixed feelings.
I agree with @pf_moore that that sounds a bit bureaucratic and is a pretty protracted timeframe. That said, I do feel that these discussions are helpful in getting ideas out there and understanding the various perspectives that people bring to the problem.
Maybe the main specific worry I have about that outline is that it seems too specific for its timescale. It doesn’t seem realistic to me that we can know now that will we spend 6 months talking, 1 year doing a “deep dive”, and so on. That would seem to preclude taking earlier action on some low-hanging fruit (like maybe some doc revisions), and it also pushes actual action so far into the future that the ground could change under our feet by then.
Personally (as may be obvious from my own posts ) I tend to think it’s more fruitful for people to just lay their cards on the table and say “I think X is a problem and I think we could solve it with Y”, and then for someone else to say “I don’t think X is a problem” or “I agree X is a problem but I think we need to solve it with Z”, and via a sort of Socratic dialogue converge on agreement on at least some tangible proposals. I understand that can be somehwat draining for those with more knowledge and experience, who are reluctant to participate if it just means a long slog of bringing less experienced folks up to speed on issues that have been rehashed ad nauseum over the years, but I’m not sure to what extent other modes of discussion would ameliorate that.
So far, to put it as optimistically as possible , I think there is some useful emerging consensus on particular problems or desiderata that are getting close to the level of specificity where progress towards a solution might be possible: a clear pathway for packaging applications, a clear move away from having packages install by default into a system Python, maybe even some more “opinionated” docs. I don’t see so much agreement on solutions at this point though. And there also are still areas where there’s disagreement about whether something is even a problem that needs to be fixed.
As @pf_moore noted, it’s unclear who would eventually implement whatever gets decided on. Is the intent that if there is sufficient agreement on certain courses of action, the PSF will be funding that work? A related issue that has been mentioned here and there in these threads is the disconnect in mission/purview/authority between the steering council and PyPA. These raise some doubt about whether adequate action would be taken even if we could agree on everything.
So all in all I’m okay with the concept of “take some time to hash out the issues, settle on some solutions, and make them happen”. But I’m not sure that committing to a timeline like the one @smm laid out is the best way to go about that.
I don’t think I really understand what this would entail ↩︎
I want to preface this by highlighting @pf_moore 's post on the Packaging Strategy Part 2 thread that summarizes many of the concerns people have about this process, and directly led to the creation of this “Structure” thread:
As the person currently responsible for facilitating this process, it would be particularly helpful to hear your viewpoint and responses to the points described there.
Err, well, is the second thread really “completed”? It seems that the discussion primarily petered out on that specific thread not because it was in any way “complete”, nor because the nominal “deadline” elapsed, nor due to lack of interest in the specific topic (as active discussion on the same topic has continued on this thread and others).
Rather, as the other folks here commented, many participants were likely just simply exhausted from the first thread, and perhaps discouraged by the lack of tangible results of the “strategy thread” format, and concluded their limited time and energy, so essential to the continued health of the Python packaging ecosystem, would be better spent elsewhere on more productive avenues.
I bring this up because if the whole goal of the strategy discussions was:
…Then the primarily “signal” is likely merely going to be a strong decay in responses (and overall enthusiasm for the effort) from discussion to discussion regardless of sub-topic.
Furthermore, there are a lot of other confounding variables at play—for example, particularly given the lack of active moderation and guidance (as others have mentioned), the discussion naturally bounced between the different primary topics as well as other unrelated ones within one topic’s thread.
And conversely, a lot of simultaneous discussion about or directly related to those same topics happened in other threads; for example:
- On the “Part 1” topic of unification, the prior Wanting a singular packaging tool/vision thread and the Pip/Conda compatibility thread it spawned has still been going strong.
- On the “Part 2” topic of user support and documentation, the discussion here and the new PyPA mechanism for making official recommendations thread has been quite active and constructive.
- The overall packaging strategy, processes and priorities as well as both subtopics has featured prominently in the PEP 704 thread, and to some extent the PEP 582 thread.
Given all of that, it’s hard to see how much useful, reliable “signal” that actually measures the relative community interest and support for each of the topics can actually be gained from this approach, at least as I’ve interpreted the above (perhaps incorrectly).
If that was the primarily “deliverable” here rather than actually having the discussions themselves actually mean something and directly motivate funding and action in the directions participants agreed upon, is there a reason the present approach was taken over a single thread with a Discourse poll, which would seem like a far quicker, less effort-intensive and unreliable (though of course still far from perfect) way to collect such “signal”?
Is the following a correct translating of the envisioned process?
User Survey / | \ V V V Thread 1 ... Thread 5 <--- WE ARE HERE \ | / V High level strategy document / | \ V V V Stream 1 ... Stream 5 | | | V V V WG 1 ... WG 5 | | | V V V Objectives & deliverables | | | V V V Targeted user surveys | | | V V V Options analysis | | | V V V Choose solution | | | V V V Build consensus | | | V V V Define technical roadmap | | | V V V Develop solutions | | | V V V Deliver solutions
To be frank, this whole process seems quite drawn out, bureaucratic and complicated, not to mention volunteer-intensive, a resource which is in critically short supply. It also doesn’t sound close to any of the approaches actually proposed on the strategy thread (competing PEPs with packaging council who decides, evolve
pip to meet these requirements, consider new governance structures, get everyone in a room for an in-person summit, etc). Furthermore, it would seem to be at odds with the fundamental established principles of how decisions are made and implemented in the Python and packaging community:
- Discussions are open to all interested, not just members of defined “workgroups”
- Ideas are freely proposed, discussed and iterated until consensus is reached, rather than proceeding through a rigid “waterfall” process
- Solutions are chosen as the result of consensus, not chosen first and then consensus built around them
- Anyone can propose an idea, but it is the proposer’s responsibility to help provide a reference implementation
- Proposals are typically accompanied by a working prototype, rather than actual implementation only coming at the very end
Furthermore, who’s the “we” here? Who’s going to be deciding which to pursue in depth? Who’s going to be part of the workgroups? Who’s going to write the roadmaps? Who’s going to develop the solutions?
Assuming the proposed solutions involve creating something other than a brand new tool/website (which would likely end up in a xkcd 927 situation), if the maintainers and community of the affected tool(s) aren’t involved and supportive throughout this process, any proposed solution will (after going through all those steps) be dead on arrival and you’ll have to go back to square one.
Certainly the current process is far from perfect, and it’s well within scope to propose major changes (as we explored in the first strategy thread). However, a full departure from the underlying fundamental principles is likely to not provide a lot of buy-in from the community, without which any resulting strategy unfortunately has little hope of succeeding.
Stepping back a bit, I want to emphasize a broader point. Maybe I missed it somewhere, but it would have been very helpful to have clearly communicated all of this beforehand, before the community invested hundreds of posts and surely at least a comparable number of total volunteer person-hours following and participating in these discussions.
It would of course have better informed people’s responses, particularly those discussing and actively planning community-driven next steps (e.g. competing PEPs and a council to vote on them, changes to
pip’s scope, PyPUG improvement, PyPA governance/process adjustments, etc.).
And more importantly, it seems to be a central assumption of those participating that they were the workgroups discussing and proposing the actual solutions. If people were actually made aware up front that the primary goal of the threads was merely “gauge[ing] how strong the signal is for each prompt”  rather than their ideas and proposals themselves genuinely playing a direct and meaningful role in the final practical outcome of all of this, I suspect many would have made different choices as to whether to spend their valuable volunteer time and energy participating.
which would then be used as input to a high-level strategy document, which would then inform the creation of workgroups, which would then perform surveys user surveys and options analysis, which would then inform the decision on a solution, around which they would then build consensus, when would then motivate a technical roadmap, which would then motivate the development of solutions, which only then would produce actual results ↩︎
Sorry for the triple post, but I just wanted to shout out the fact that for those interested something like this:
We’ve (@pradyunsg , @FFY00 and I) finally been able to formally open signups and topic proposals for the Python Packaging Summit at PyCon 2023! We’ve currently scheduled it in two separate sessions at the beginning and end of the event to give people some time to think in between, and if there’s enough interest, we could potentially reserve some open space between those two or meet up during the sprints for additional informal discussions. Hoping to see you all there!
FWIW, I believe something like this was one of the original options we were presented with.
Everyone voted for Discourse threads, which is why we’ve been doing Discourse threads.
Just to be clear, I wasn’t criticizing the idea of Discourse threads for this (I voted for it myself), just offering another option we’re providing for those interested.
FWIW, looking back at the post in question, 53% of people voted for Discourse at the time (or if I don’t include my own vote, an even 50%) while 44% voted for virtual meetings, and 3% voted “do not want to participate” (in-person meetings wasn’t an option). I wouldn’t call that “everyone” (and opinions may have changed over time), and it certainly doesn’t mean that there isn’t value in also having in-person discussions.
As someone who won’t be at PyCon US, I hope that the discussions are recorded and published somehow. In the past, we haven’t been good at doing this. I know it’s really hard to record the sort of interactive discussion the summit is intended for, but IMO it’s crucial, with the wide range of people involved in packaging discussions, that we don’t end up with people able to attend PyCon being in a privileged position to influence things.
Particularly as one of the good things with the strategy discussions is how they’ve got new people, with different viewpoints, involved. ↩︎
I won’t be there either, so I’m sure everyone will enjoy not having us clog up all the threads
Thanks for looking it up. I knew after I posted that I should’ve done it myself, but am already struggling to keep up with my tasks today Clearly I remembered an earlier state of the results, because that’s much closer than I thought - maybe it’s close enough to justify setting up a virtual meeting?
Sorry to hear you won’t be able to make it this year (as I was hoping to finally get to meet you IRL), and thanks for the feedback! Yeah, that’s the plan, like with last year. As linked in my post above and the 2022 and 2023 packaging summit web pages link the notes from last year, which are hopefully detailed enough for what you’re looking for, and one of us (probably Pradyun and/or myself) will be taking them again this year.
I prefer the agile approach too. My only concern is that while we focus on incremental changes, we might end up neglecting discussions or decisions that we need to make regarding long-term strategy. But I do think a suitable compromise can be found between incremental changes and long-term strategy planning.
This approach was taken to gather thoughts from maintainers and also to gauge if there is interest in pursuing the key topics further.
I would expect the community to decide which high-level strategy topics we want to pursue in depth. If there is a working group, I would expect this group to decide which topic to pursue in depth within the working stream they are working on. The working group will be volunteer driven.
Previously, for any major development project that is resource heavy, the PSF has secured funding to support development and delivery of the project. I expect this policy to continue for any major project that has been identified via strategy planning.
You are right. This was an error at my end. I should have communicated the plan for the strategy discussions before initiating them. I do regret making this mistake.
I seem to have given the wrong impression regarding the timeline. I did not express myself properly. I expect the timeline to look like this-
Over the next 12 months- Produce high-level strategy doc, set up workstreams and working group for each workstream, define objectives and deliverables for each working group. Deep dive into each workstream, targeted user surveys as suggested by multiple people in this thread, options analysis and building consensus for the chosen solution(s), define technical roadmap
April 2024 onwards- Develop solutions and deliver
This should be viewed as a worst-case scenario timeline. It should also be viewed as the timeline for any major development project we may wish to pursue. If there are no delays with securing funding or generating community consensus, I expect development to start much sooner. I do recognise that this clarification will not alleviate any of the concerns expressed regarding the timeline, working groups or making incremental changes but I wanted to ensure I have shared my thoughts on this process correctly.
As people have expressed concerns regarding working groups, are there any other options that we have not explored that would be suitable for a sustained discussion and decision-making process? Are discussions on Discourse the only alternative? To be clear, I am not advocating for or against Discourse. I want to make sure we have sight of all possible options.
Thanks; I appreciate you taking the time to respond here. As much as there are things that could have gone a lot better (at least in hindsight), I don’t think anyone here would envy being in your position here, given the overwhelming breath of the problem space, and the sometimes deafening cacophony of cats to herd. You’re also stuck inn the role of the one project manager in a room full of programmers and scientists, and as others noted we can speak very difficult languages sometimes with different expectations and ways of doing things.
It’s understandable that there’s a lot of healthy skepticism toward a relative outsider coming in with a somewhat unconventional plan to accomplish what many veterans and newcomers alike have wanted to do since forever but from experience accept as nearly impossible—unify the packaging landscape and develop a single coherent high-level strategy. However, maybe just maybe the right balanced of fresh-faced enthusiasm and out of the box thinking combined with battle-hardened experience and proven strategies, catalyzed by a healthy infusion of financial resources, will finally succeed where countless others have not. I certainly hope so…
Thanks for the clarifications. As it seems you picked up on, I think some of what might have raised people’s concerns was not only the length of time of the process, but also the apparent complexity/number of steps involved as well as the perception of it being more rigid/water-fally and less flexible/agile than you may have actually intended it.
Sure. Some here have suggested at least trying one or a couple virtual meetings to complement the threads and seeing how well-attended and productive they are and how well they are received, given they were a close second in your previous poll and the Discourse threads have met a mixed reception so far. We could also give this topic (or multiple related ones that this has organically spawned) a slot at the upcoming packaging summit, or even schedule a dedicated BoF session, meetup or sprint at PyCon.
Beyond that, as mentioned above, deep into the first strategy thread (and before I think people were aware of what you shared with us now, that there was a whole plan for working grounds, workstreams etc) there was some considerable discussion and some amount of rough agreement around an overall path forward to gather community consensus and decide on a course of action on these topics, that is somewhat of a hybrid of the accepted PEP/PyPA process and the sort of thing you propose:
- Discuss and agree on the overall process and document that in a PEP (i.e. the equivalent of your strategy document)
- Determine a “steering council” of ≈3-5 ish PEP delegates to oversee and steward the process—the PEP in step 1 would determine how and by whom these are selected
- Invite community members or teams of them to propose PEPs with different ways of addressing the overall topic (equivalent to your workgroup technical proposals)
- The community discuss, revises and iterates on the proposals, via Discourse threads and other venues (equivalent to your consensus building stage)
- A final decision is made on which PEP(s) to accept and implement based on the community consensus and the input of the affected maintainers, as determined by the council of PEP delegates
- The accepted proposals are implemented (with funding as needed/available)
This was originally proposed by @dstufft in post 225, followed up by me in post 228 and further discussed by others in the immediate posts following. There were also some other approaches proposed there, but that one is probably the closest to the one you were thinking of, and the one that seemed to garner the most support.