It’s a fair question. 
I like to think, though, that yes, I would be more accepting of that.
Also a fair question, and I’ll explain why I do think (or at least hope) so. But for a short answer I can’t do better than @dstufft:
Here’s the long version, which maybe is too long but some of it is stuff that’s been kicking around in my head in these various threads and I think is maybe good to have out there. A lot of it is not specific to Python at all but just has to do with what is helpful for people to make decisions.
First, the same question (“what’s the use of a new decision-making body?”) could be asked about typing or the C API or the typing system, both of which have also recently proposed similar governance changes — or even about Python itself, which has evolved from a more freewheeling approach in the very early days, to the PEP system, then to the steering council, and so on. And I’d say the reason in those cases is similar to what I envision: as a project or problem (or a sub-project or sub-problem) grows over time, often it becomes useful to adopt a more explicit set of guidelines, processes, and so on, as opposed to a loose structure of “propose something and someone who knows about that topic will make an ad-hoc decision”. Often that kind of “institutionalization” also comes with a specific intent to sketch out some kind of vision or philosophical goal, to distill the implicit wisdom of past failures and triumphs into more explicitly stated principles.
This has an effect both on those proposing ideas and those evaluating them. For the former, it points towards a hoped-for future and thus gives a sense of what counts as progress. For the latter, it provides a psychological push to be a little more compartmentalized, a little more rigorous, a little more careful about doing things in a consistent and coherent way, and a nudge away from a mindset of just considering each individual matter in isolation. This can be true even if those decision makers are the same people who were making decisions before, and it can true even if they already took that responsibility quite seriously, simply because publicly and collectively clarifying that role and how it is to be performed can clarify some things in their individual minds as well.
Second, and really a corollary of the above, is that I think there is significant value in making decisions that are not bound to an immediate, specific proposed change. It is of course necessary to decide where to place your foot for your next step, but it’s helpful to also look some distance ahead and see where you are going. My impression is that this, although theoretically possible, is not super natural in a Github-issue-type system, where there is more typically a sense that tickets will be raised about specific, separately addressable issues. We’ve seen a profusion of such discussion in the last year or so on this forum, and (call me crazy ) I actually see it as a good sign.
Third, building on the above, is that having a clearly decision process makes it easier to have a clear record of past decisions, especially of that broad type. In a system like what we have, often an implicit set of notions is built up in a way that’s scattered across dozens of old Github issues. Those who are steeped in that accumulated knowledge then can feel burdened by having to tell newcomers that this or that idea isn’t going to work, and that burden is increased if to explain why they have to dig up some old closed issue.
Compare that with how, in the PEP system, it’s very common for a new idea to be met with a response of “see PEP XXX which proposed this but was rejected or abandoned”. And then maybe the idea can be revived, or maybe not, but the PEP hopefully provides a convenient entry point into what’s been discussed in the past.
Of course, we have PEPs for packaging too, so what’s the difference? Well, similar to what I said above, I’m sort of hoping that a packaging council could take clear stances on questions at a different level. Like, lay out a set of explicit priorities and goals. Adjudicate differences of opinion on things like “should the tutorial show several ways or just one way”. And yes, reject contributions (maybe even mine! ) that don’t fit the vision — but at least be able to reject them by reference to some principles that have been clearly agreed on in past decisions.
Which leads to the next reason, namely that I think decisions from an explicit decision-making body would be perceived (hopefully not just by me ) as having greater legitimacy. I don’t mean that current decisions are illegitimate or anything like that, just that a decision carries more weight if the whole community (and I don’t just mean the developers) has consensus that there is a definite way to present a proposal and a definite set of criteria on which it will be evaluated by a definite set of people. And they may still decide the decision-making process is headed in the wrong direction, and go off and do their own thing, and that can also turn out great (for instance, conda ).
And then there’s one more reason, which maybe is sort of conceptually backwards, but it’s basically my own interpretation of that @dstufft quote above: the situation we’re in came about from the process we have, so if we don’t want to be in that situation we probably need to change something about the process. And in a way a decision to move forward with a packaging council would at least indicate a collective desire to shake things up a bit and not continue along the same path we’ve been on. I call this backwards thinking (on my part) because it’s basically saying that setting up a packaging council would not so much cause things to change as indicate that things have already changed (namely, the mindset). But, like I said above, sometimes the causality can run in that seemingly backwards way, and adopting a new framework can indeed make people feel a bit like there’s more room to maneuver, and decisions can be made that might not have been made before.
So yeah, I do think that even if the same set of people are making decisions, it helps to have a clear statement of who is making them, what decisions they’re making, and what plays into those decisions (e.g., a record of past decisions that were made explicitly to constrain future ones), and even just a new way of doing things to shake off a bit of the accumulated dust. Most of this doesn’t really have anything to do with Python. It’s relevant for everything from school boards to legislative subcommittees to governance of a local chess club.
Obviously it’s not a guarantee that the mere existence of a packaging council will automatically make things better. If the same people make the same decisions in the same way then certainly nothing will change. But I do think that sometimes changing the process and the conception of how the decisions are being made can result in those decisions being made differently.
And yeah, more specifically, there are some things I think would help in terms of what I think the council should “be like”, such as tackling some “visionary” issues and formulating a long term plan (rather than just continuing to evaluate specific proposals). And I think it would be help if the process builds on the packaging survey and user study stuff we’ve seen, to further cultivate a channel for user feedback.
I should add, too, that I think pretty much all of in these discussions do agree on a lot, and that’s one reason I do think these discussions are valuable, and why I appreciate everyone’s continued involvement in them. I don’t see anyone saying “Nah, the docs are fine, packaging is fine, just forget the whole thing, no change is needed”. We all share some sense of the problem at its most general level and want to fix it. It’s that common base that makes it conceivable that adding a bit more thoroughgoing structure to these deliberations might actually help.
