(Cross-posted from https://discuss.python.org/t/new-python-organization-repository-policy/17376 – please perfer commenting there.) Hello, When asked about adding the typing_extensions repository to the Python organization (https://github.com/python/steering-council/issues/126), the Steering Council discussed a general policy for the organization, as the current one (https://devguide.python.org/devcycle/#organization-repository-policy) seems outdated. We decided on the guidelines below. Note that existing repositories can stay under python. However, we will ask that: – PSF infrastructure be moved under the psf organization, and – all repositories under python will need to require the CLA and have two-factor authentication for all committers, otherwise move elsewhere or be archived. – Petr, on behalf of the Steering Council New Organization Repository Policy Within the GitHub Python organization, repositories are expected to relate to the Python language, the CPython reference implementation, their documentation and their development workflow. This includes, for example: - The reference implementation of Python and related repositories (i.e. CPython) - Tooling and support around CPython development (e.g. pyperformance, Bedevere) - Helpers and backports for Python/CPython features (e.g. typing-extensions, typeshed, tzdata, pythoncapi-compat) - Organization-related repositories (e.g. the Code of Conduct, .github) - Documentation and websites for all the above (e.g. python.org repository, PEPs, Devguide, docs translations) - Infrastructure for all the above (e.g. docsbuild-scripts, buildmaster-config) - Discussions and notes around official development-related processes and events (e.g. steering-council, core-sprint) Before adding a new repository, permission should be sought from the Python steering council. Note that several repositories remain in the organization for historic reasons, and would probably not be appropriate today. All non-archived repositories must require contributors to sign the PSF Contributor Agreement. Generally, new repositories should start their life under personal GitHub accounts or other GitHub orgs. It is relatively easy to move a repository to the organization once it is mature. For example, this would now apply to experimental features like asyncio, exceptiongroups or typed_ast and drafts of new guides and other documentation (e.g. redistributor-guide). General-use tools and libraries (e.g. mypy or black) should also be developed outside the python organization, unless core devs (as represented by the SC) specifically want to “bless” one implementation (as with e.g. typeshed, tzdata, or pythoncapi-compat).