On 21 September 2017 at 10:51, Ned Batchelder firstname.lastname@example.org wrote:
Write a document that proposes some quality metrics. Share it around. Get people to like it. If it becomes popular, then people will start to value it as a standard for project quality.
And explore the academic literature for research on quality measures that are actually predictors of real world benefits (e.g. readability, maintainability, correctness, affordability).
There doesn't seem to be all that much research out there, although I did find https://link.springer.com/chapter/10.1007/978-3-642-12165-4_24 from several years ago, as well as http://ieeexplore.ieee.org/document/7809284/ from last year (both are examples of pay-to-play science though, so not particularly useful to open source practitioners).
Regardless, Ned's point still stands: the PEP process only applies to situations where the CPython core developers (or a closely associated group like the Python Packaging Authority) are the relevant global authorities on a topic. Even PEP 7 and PEP 8 are technically only the style guides for the CPython reference implementation - folks just borrow them as the baseline style guides for their own Python projects.
"Which characteristics of Python code are useful predictors of the ability to deliver software projects to specification on time and within budget?" (the most pragmatic definition of "software quality") is *not* one of those areas - for that, you'd be more looking towards groups like IEEE (Institute of Electrical & Electronics Engineers) and ACM (Association for Computing Machinery), who study that kind of thing across multiple languages and language communities, and try to put some empirical weight behind their findings, rather than relying primarily on instinct and experience (which is the way we tend to do things in the open source community, since it's more fun, and less effort).