# New \`python\` organization repository policy **URL:** \ **Category:** Core Workflow\ **Created:** [July 15, 2022, 11:22am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376 "2022-07-15T11:22:58Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [July 15, 2022, 11:22am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/1 "2022-07-15T11:22:58Z")
Hello, When asked about adding the typing\_extensions repository to the Python organization [(#126)](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](https://github.com/python/), 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](https://github.com/python/cpython)) - Tooling and support around CPython development (e.g. [pyperformance](https://github.com/python/pyperformance), [Bedevere](https://github.com/python/bedevere)) - Helpers and backports for Python/CPython features (e.g. [typing-extensions](https://github.com/python/typing_extensions), [typeshed](https://github.com/python/typeshed), [tzdata](https://github.com/python/tzdata), [pythoncapi-compat](https://github.com/python/pythoncapi-compat)) - Organization-related repositories (e.g. the[Code of Conduct](https://github.com/python/pycon-code-of-conduct), [.github](https://github.com/python/.github)) - Documentation and websites for all the above (e.g.[python.org repository](https://github.com/python/pythondotorg), [PEPs](https://github.com/python/peps), [Devguide](https://github.com/python/devguide), docs translations) - Infrastructure for all the above (e.g. [docsbuild-scripts](https://github.com/python/docsbuild-scripts), [buildmaster-config](https://github.com/python/buildmaster-config)) - Discussions and notes around official development-related processes and events (e.g. [steering-council](https://github.com/python/steering-council), [core-sprint](https://github.com/python/core-sprint)) Before adding a new repository, permission should be sought from the[Python steering council](https://github.com/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](https://www.python.org/psf/contrib/contrib-form/). 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](https://github.com/python/asyncio), [exceptiongroups](https://github.com/python/exceptiongroups) or [typed\_ast](https://github.com/python/typed_ast) and drafts of new guides and other documentation (e.g. [redistributor-guide](https://github.com/python/redistributor-guide)). General-use tools and libraries (e.g. [mypy](https://github.com/python/mypy) or [black](https://github.com/psf/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](https://github.com/python/typeshed), [tzdata](https://github.com/python/tzdata), or [pythoncapi-compat](https://github.com/python/pythoncapi-compat)). ---
**Author:** ![srittau](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/srittau/32/237_2.png) [@srittau](https://discuss.python.org/u/srittau)\ **Post date:** [July 15, 2022, 11:55am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/2 "2022-07-15T11:55:27Z")
> [@encukou](#): > > all repositories under python will need to […] have two-factor authentication for all committers I don’t think that this can be configured per repository, only per organization. (I just checked in an org/repository where I am owner.) Supposedly, this wouldn’t affect outside contributors to those repositories, either. What’s the best way to approach this? ---
**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\ **Post date:** [July 15, 2022, 12:35pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/3 "2022-07-15T12:35:34Z")
Correct, 2FA can only be set to required at the org level, however it also applies to outside contributors. See the warnings in the [GitHub docs](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization#about-two-factor-authentication-for-organizations): > **Warnings:** > > - When you require use of two-factor authentication for your organization, members, outside collaborators, and billing managers (including bot accounts) who do not use 2FA will be removed from the organization and lose access to its repositories. They will also lose access to their forks of the organization’s private repositories. You can [reinstate their access privileges and settings](https://docs.github.com/en/articles/reinstating-a-former-member-of-your-organization) if they enable two-factor authentication for their personal account within three months of their removal from your organization. > - If an organization owner, member, billing manager, or outside collaborator disables 2FA for their personal account after you’ve enabled required two-factor authentication, they will automatically be removed from the organization. > - If you’re the sole owner of an organization that requires two-factor authentication, you won’t be able to disable 2FA for your personal account without disabling required two-factor authentication for the organization. I guess 2FA is not currently required for [https://github.com/python](https://github.com/python)? It’s not necessarily a bad thing to have people without 2FA removed from the org, they can be re-added easily enough, but we should announce it first to give people time to enable 2FA. ---
**Author:** ![arhadthedev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/arhadthedev/32/6420_2.png) [@arhadthedev](https://discuss.python.org/u/arhadthedev)\ **Post date:** [July 15, 2022, 12:40pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/4 "2022-07-15T12:40:21Z")
> Note that several repositories remain in the organization for historic reasons, and would probably not be appropriate today. It looks like they can be moved and old links will continue to work: - [Repository redirects are here! - The GitHub Blog](https://github.blog/2013-05-16-repository-redirects-are-here/) - [Transferring a repository - GitHub Docs](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) - [How long does github forward renamed/moved repos? · community · Discussion #22669 · GitHub](https://github.community/t/how-long-does-github-forward-renamed-moved-repos/582) ---
**Author:** ![Jelle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jelle/32/1049_2.png) [@Jelle](https://discuss.python.org/u/Jelle)\ **Post date:** [July 15, 2022, 1:17pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/5 "2022-07-15T13:17:02Z")
> [@encukou](#): > > all repositories under python will need to require the CLA This is a change from current practice; typeshed and mypy (probably the most active repos in the org outside cpython) don’t require the CLA. Is there a legal reason for this change? Note that these repos currently don’t require the CLA, so any change would not cover some of the existing code. ---
**Author:** ![srittau](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/srittau/32/237_2.png) [@srittau](https://discuss.python.org/u/srittau)\ **Post date:** [July 15, 2022, 4:34pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/6 "2022-07-15T16:34:36Z")
> [@Jelle](#): > > python and mypy (probably the most active repos in the org outside cpython) don’t require the CLA. Just for clarification: I assume you mean **typeshed** and mypy. ---
**Author:** ![nanjekyejoannah](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nanjekyejoannah/32/529_2.png) [@nanjekyejoannah](https://discuss.python.org/u/nanjekyejoannah)\ **Post date:** [July 15, 2022, 6:32pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/8 "2022-07-15T18:32:41Z")
> [@encukou](#): > > Before adding a new repository, permission should be sought from the[Python steering council](https://github.com/python/steering-council). Note that several repositories remain in the organization for historic reasons, and would probably not be appropriate today. I agree but the decision may require some public discussion before SC decision, given several committers get notifications from these new repositories, sounds like good courtesy. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [July 15, 2022, 6:51pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/10 "2022-07-15T18:51:32Z")
> [@hugovk](#): > > I guess 2FA is not currently required for [Python · GitHub](https://github.com/python)? Correct. > [@hugovk](#): > > we should announce it first to give people time to enable 2FA. Hence this announcement. 🙂 Also note there’s no timeline announced yet, so this isn’t happening tomorrow (the PSF repos would have to move first). > [@arhadthedev](#): > > It looks like they can be moved and old links will continue to work Correct, although we are also not trying to cause massive upheaval by moving a bunch of projects that have existed under the python org for years either. > [@Jelle](#): > > This is a change from current practice; typeshed and mypy (probably the most active repos in the org outside cpython) don’t require the CLA. Is there a legal reason for this change? From the perspective of expectations, yes; I would expect folks assume stuff under the python org is being handled as best as possible from a legal perspective.I also don’t think we want the PSF pulled into any legal issues based on the code being hosted under our org due to the lack of CLA, which isn’t a huge burden IMO. Or look at it from the perspective of what we are saying the org _should_ be: stuff related to Python. In that case the PSF CLA makes sense to broadly apply as the repos under Python expected to fall under PSF jurisdiction legally anyway. As you point out there are some historical repos which that doesn’t fit, but we also wouldn’t want a slip-up of not having the CLA where it’s expected either. > [@Jelle](#): > > Note that these repos currently don’t require the CLA, so any change would not cover some of the existing code. CPython itself doesn’t have full CLA coverage either. But _some_ coverage is better than _no_ coverage. ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [July 15, 2022, 7:47pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/11 "2022-07-15T19:47:16Z")
Maybe we need to distinguish between 2FA and CLA? I’m all for 2FA everywhere ASAP, but CLA has limited benefits IMO, and deserves more discussion. ---
**Author:** ![dstufft](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dstufft/32/23_2.png) [@dstufft](https://discuss.python.org/u/dstufft)\ **Post date:** [July 15, 2022, 8:02pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/12 "2022-07-15T20:02:32Z")
> [@encukou](#): > > PSF infrastructure be moved under the psf organization, and I assume that PyPI and the related repositories for it are still fine to exist outside of the `python` organization, we just started utilizing and migrating stuff to the `pypi` organization, which is also controlled by the PSF. ---
**Author:** ![gpshead](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gpshead/32/54_2.png) [@gpshead](https://discuss.python.org/u/gpshead)\ **Post date:** [July 16, 2022, 4:57am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/13 "2022-07-16T04:57:16Z")
> [@dstufft](#): > > > [@encukou](#): > > > > PSF infrastructure be moved under the psf organization, and > > I assume that PyPI and the related repositories for it are still fine to exist outside of the `python` organization, we just started utilizing and migrating stuff to the `pypi` organization, which is also controlled by the PSF. Yes, we (python steering council) only speak for the GH `/python/` org. Moving PSF infra related things under the `psf` org is merely a suggestion meant more to imply _“somewhere managed by the PSF”_. ---
**Author:** ![malemburg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/malemburg/32/50_2.png) [@malemburg](https://discuss.python.org/u/malemburg)\ **Post date:** [July 18, 2022, 7:48am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/14 "2022-07-18T07:48:16Z")
Agreed. There are repos, such as the PEPs repo, where authors specify the license on a per document basis (usually public domain) and the Apache license required by the CLA is not one of those. Having a CLA wouldn’t give the PSF any benefit, since most of documents are without copyright anyway. However, it would make contributing harder. ---
**Author:** ![gpshead](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gpshead/32/54_2.png) [@gpshead](https://discuss.python.org/u/gpshead)\ **Post date:** [July 18, 2022, 6:45pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/15 "2022-07-18T18:45:46Z")
PSC and PSF hats: We’re going to get some clarification from legal council (Van) around which repos the CLA should or shouldn’t be applied and why. Personal hat: If the PSF CLA isn’t appropriate for a software project, that suggests it doesn’t _really_ fit the purpose of the GitHub `/python/` org. ---
**Author:** ![malemburg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/malemburg/32/50_2.png) [@malemburg](https://discuss.python.org/u/malemburg)\ **Post date:** [July 18, 2022, 7:09pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/16 "2022-07-18T19:09:47Z")
The CLA is needed for any software the PSF wants to redistribute under a PSF open source license. It’s not strictly needed for software / documentation which we only use internally (e.g. infrastructure) or manage in a repo for informational purposes (e.g. PEPs). The CLA also doesn’t add any security. In its current form, the CLA process doesn’t even require an email address, only a random Github account, but that’s being discussed in another topic. ---
**Author:** ![steven.daprano](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steven.daprano/32/1083_2.png) [@steven.daprano](https://discuss.python.org/u/steven.daprano)\ **Post date:** [July 19, 2022, 2:23am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/17 "2022-07-19T02:23:06Z")
> [@Jelle](#): > > This is a change from current practice; typeshed and mypy (probably the most active repos in the org outside cpython) don’t require the CLA. Is there a legal reason for this change? Brett replied: > [@](#): > > Legal, no? Security, yes. How does a CLA increase security? (I presume that “threat of being sued for copyright infringements” is considered a legal risk rather than a security issue.) ---
**Author:** ![Jelle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jelle/32/1049_2.png) [@Jelle](https://discuss.python.org/u/Jelle)\ **Post date:** [July 19, 2022, 2:51am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/18 "2022-07-19T02:51:28Z")
There was some confusion between CLA enforcement and 2FA enforcement. The latter increases security, but the former is what we’re talking about. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [July 20, 2022, 9:15pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/19 "2022-07-20T21:15:26Z")
> [@steven.daprano](#): > > How does a CLA increase security? It doesn’t it. I believe you’re replying to a post that I deleted after I realized I misread “CLA” for “2FA”. ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [July 23, 2022, 2:21am UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/20 "2022-07-23T02:21:37Z")
> [@hugovk](#): > > Correct, 2FA can only be set to required at the org level, however it also applies to outside contributors. Just to be clear for others, It applies to outside _collaborators_, i.e. people explicitly added with particular permissions to one repository rather than the whole org, not all _contributors_, which generally makes sense and is much less problematic. > [@arhadthedev](#): > > It looks like they can be moved and old links will continue to work: Yup, and so will git interactions, etc. > [@Jelle](#): > > This is a change from current practice; typeshed and mypy (probably the most active repos in the org outside cpython) don’t require the CLA. It seems while these are grandfathered in, the general desire would be to move them to the PSF org or their own org if possible? > [@malemburg](#): > > There are repos, such as the PEPs repo, where authors specify the > license on a per document basis (usually public domain) and > the Apache license required by the CLA is not one of those. > > Having a CLA wouldn’t give the PSF any benefit, since most of > documents are without copyright anyway. However, it would make > contributing harder. In modern times, all PEPs are required to be “licensed” “public domain” (which isn’t really a proper license) and CC0 (which is, more or less), and almost all historical PEPs were at least “PD”, with a few very old exceptions (that are hopefully no longer relevant). The PEPs repo has required the CLA for as long as I’ve been there (which admittedly, isn’t very long) and it hasn’t caused much of a problem, except for the serious bugs with the new bot that did cause major problems, blocking the work of one of our most active PEP editors, though they seem to be resolved now and hopefully won’t reoccur. The “CLA” is really more of a DCO rather than assigning copyright interest to the PSF, like most CLAs do. The author still needs to establish copyright ownership and the right to contribute their work before they can add it and release it under the CC-0. Licensing Apache on ingest, I presume, provides some amount of patent protection, though IANAL. > [@malemburg](#): > > It’s not strictly needed for software / documentation which we only use > internally (e.g. infrastructure) or manage in a repo for informational > purposes (e.g. PEPs). I don’t really follow the argument here. Internal use of software to which one does not have a legitimate license to use is still illegal and incurs liability, if anyone but PSF employees that have a signed contract in place are contributing to them. And I don’t understand the reasoning about the PEPs; they are no less copyrightable and publicly distributed than software, and arguably more so. If a user were to write a PEP, it get incorporated into the Python docs and formal specs, and then their employee claim ownership of it, or it turned out they got a significant chunk of it from someone else without permission, we’d be in big trouble. ---
**Author:** ![VanL](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vanl/32/639_2.png) [@VanL](https://discuss.python.org/u/VanL)\ **Post date:** [July 25, 2022, 6:02pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/21 "2022-07-25T18:02:24Z")
The reason for CLAs is threefold: 1. For anything that is going to be relicensed to the Python license, we need the right to do that. The CLA allows us to relicense to an OSI-approved license that is approved by the board. Currently only the Python license is approved generally, there are minor exceptions. 2. The CLA specifies the terms of how people license-in their code (under the Apache license, generally). This gives us the right to use the code absent them putting a licensing declaration in each file or PR. 3. The CLA protects Python/the PSF/all downstream users from a later accusation that an employee contributed to Python and was not allowed to do so. By having a document that _should_ be reviewed by legal within an organization, we make sure that anyone contributing to Python has their org’s ok to do so. For all of those wondering about CLA vs. DCO, item #3 is the biggest difference between them. As for mypy and typeshed, IF those are being more formally incorporated into the Python distribution, we should move to a CLA for the reasons identified above. If we are not incorporating them into Python… I don’t really understand why they are moving under the /python organization. - Van ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [July 25, 2022, 6:33pm UTC](https://discuss.python.org/t/new-python-organization-repository-policy/17376/22 "2022-07-25T18:33:14Z")
> [@VanL](#): > > For all of those wondering about CLA vs. DCO, item #3 is the biggest difference between them. Ah, I see—so the key distinction is procedural, as with the DCO, the _contributor_ certifies they “have the right to submit it under the open source license”, but the PSF CLA ensures that is actually formally affirmed by the contributor’s _employer_, if relevant, so that it remains legally binding if the contributor has a legally enforceable employment contract that would otherwise assign copyright interest in their open source contributors to said employer. > [@VanL](#): > > As for mypy and typeshed, IF those are being more formally incorporated into the Python distribution, we should move to a CLA for the reasons identified above. > > If we are not incorporating them into Python… I don’t really understand why they are moving under the /python organization. Actually, the situation is in fact the opposite, as I understand it—they are currently under the `python` organization for historical reasons, whereas at least mypy would not belong in such under the new policy unless grandfathered in. The justification for `typeshed` staying in such seems to be that it contains the canonical type stubs for the standard library (though also third party libraries as well…). It might be prudent to get CLA coverage for at least the stdlib stubs, in case they are ever considered to be shipped with Python itself, etc. [Next page](https://discuss.python.org/t/new-python-organization-repository-policy/17376.md?page=2)