(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).
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JP4T26I5HLO5SB3DKELDPQJPOR4JHLAN/
Code of Conduct: http://python.org/psf/codeofconduct/
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).
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JP4T26I5HLO5SB3DKELDPQJPOR4JHLAN/
Code of Conduct: http://python.org/psf/codeofconduct/