On Fri, 31 Aug 2018 at 10:52, Donald Stufft
I also know that Nick has a few concerns with accessibility to the wider community, which I believe I addressed in the other email thread, but to reiterate, I don’t think that the wider community cares one way or another, and I think the biggest benefit comes from being able to tailor this process to what we need.
I think the wider community cares more about "Is it in a PEP?" than you believe, as we had folks outright refusing to accept Description-Content-Type as legitimate when it was only defined in https://packaging.python.org/specifications/core-metadata/#description-conte..., with no PEP to back it up as being an officially endorsed interoperability standard. Attempting to build legitimacy and credibility for a random collection of text files in a GitHub repo rather than continuing to use https://www.python.org/dev/peps/ feels like a pointless time-wasting distraction to me. It's not like PEP-level proposals come up all that often - even with the 5 year delay induced by the PEP 426 detour, PEP 566 still only had a handful of major changes in it (Description-Content-Type, Provides-Extra, the canonical conversion to a JSON-compatible data structure, allowing the Description to be in the metadata body, and explicitly referencing PEPs 440 and 508). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia