I just submitted the PEP to the SC.
In the meantime, I’d like to discuss how the Council’s various responsibilities should be organized in terms of GitHub repos. This is intentionally not precisely specified in the PEP so that the Council retains flexibility, but it’s good to think about it anyway. I’ll write out my thoughts and conclude with a proposal, but I’m happy to hear other opinions.
- The user-facing reference should live at Type System Reference — typing documentation and the python/typing repo—there’s already something there, and it’s a good place.
- The spec and conformance test suite should be in the same repo, so that it’s easy to review a proposed spec change and its corresponding test suite changes together.
- The spec should be hosted at typing.readthedocs.io, so as much as possible of the typing-related documentation is under one domain.
- There should be a dedicated repo for asking the Council to make a decision (analogous to python/steering-council). This allows people who want to follow along without too much noise to follow just this repo. It also creates a clear record of the Council’s decisions.
So with that in mind, I propose that the Council should work with two repos:
- python/typing contains the user-facing reference, spec, and conformance test suite. The former two power a docs site at typing.readthedocs.io (though come to think of it, maybe we should move it to typing.python.org?).
- python/typing-council doesn’t contain any significant code or docs, but issues can be opened there to request the Council to make a decision. The repo could contain practical information about the Council, such as current membership and procedures.
As a corollary, spec/conformance test suite changes come in three kinds:
- Changes that don’t affect content (wording improvements, reorganization, test cases for features that aren’t covered yet) are handled through PRs to python/typing that may be merged by anyone with access to that repo. The Council should supervise such changes and speak up if anything needs more discussion.
- Content changes that are relatively small are handled by the Council. (For example, Inconsistencies between `Type` and `type` should take this path.) After initial discussion, someone creates a PR to the spec and test suite. Then they open an issue on the python/typing-council repo asking for a decision, and also bring up the issue here on Discuss. After at least a week, the Council makes a decision.
- Larger changes, such as new type system features, need a PEP. Such PEPs would come with proposed changes to the spec and test suite. When the PEP is ready for a decision, the author posts on the python/typing-council and python/steering-council repos. The Typing Council then comes up with a recommendation, and the Steering Council makes the final decision.
The exact boundaries between these levels would be up to the Council.
How should the Council make decisions? The PEP suggests decision-making should mostly take place on GitHub. Possibly this will be impractical if the Council finds it important to speak with one voice. However, one approach is simply that the Council members discuss their decision on the issue in the typing-council repo.