Transfer to Django Commons

[thibaudcolas]

Follow-up from #192.

Requirements

Per Requirements for incoming repositories

1. ✅ All maintainers (people with release permissions) agree to the transfer - Transfer to Django Commons #205 (comment)
2. ✅ New admins and maintainers are identified: @thibaudcolas @knyghty (might add more later)
3. ✅ Tests that run in CI thanks to Update all the things #196
4. ✅ Maintained documentation
5. ✅ Adopt Django Commons's Code of Conduct bf3ae04
6. ⌛️ After transferring, switch to PyPI's "Trusted Publisher"
   process (see example in django-commons-playground)
7. N/A - django-commons should be added as maintainer to the readthedocs project

Repository requirements

Tests

• ⌛️ [Required] Clear instructions on how to run tests
• ⌛️ [Required] Tests run with at least oldest supported LTE versions of Django and Python
• ⌛️ [Suggested] Good test coverage (>70%)

Documentation

• ⌛️ [Required] How to install and use the project
• ⌛️ [Required] How to contribute
• ⌛️ [Required] Organized and maintainable
• ⌛️ [Suggested] Contains architecture documentation

Code of Conduct

• ✅ [Required] Repository contains CODE_OF_CONDUCT.md that links to Django Commons's Code of Conduct. See django-commons-playground for an example

Maintainer requirements

• ✅ [Required] All maintainers (release permission) agree to transfer project
• ❌ [Required] The repository will be transferred to the django-commons GitHub organization
• ❌ [Required] The Django Commons PyPI admin team (cunla and stormheg) is added as owners to PyPI and Test PyPI projects
• ✅ [Required] Any previous maintainers who are not repository admins are removed as owners on PyPI and Test PyPI projects

[knyghty]

Sure

[MarcelWilson]

Can someone provide some background behind the motivation for this? I don't really know django nor the group django-commons. Is there any chance the move would narrow the focus of AXE testing in selenium?

[thibaudcolas]

@MarcelWilson I shared more background here: #192 (comment)

Django Commons as an organization doesn’t really have a say in the direction of any of the packages hosted there, it’s just a way for maintainers to band together with explicit rules / processes on how maintainership is shared