Cleaning up our third party packages/docs is something that has been on my mind for a while, and I'd be happy to take a stab at it. First, there are some simple issues that could be addressed:

• Packages can be found in multiple places - the "Third Party Packages" doc (TPP doc), and a similarly named section for most of the API guides. Some packages are listed in both places, some only in one or the other. This is inconsistent and a little confusing - users may not think to check the other location for more potential packages. I'd propose moving all packages into the TPP doc. One doc is easier to maintain than ~15. The API guides could then link to their corresponding sections in the main TPP doc.
• Inconsistent descriptions. The TPP doc itself is pretty consistent - most packages have a brief one to two line description. However, the descriptions in the individual API topics are not. Some are a line or two, some a paragraph, and some even contain basic (and unnecessary) installation/setup instructions. Aside from the inconsistency, descriptions that are significantly larger may come across as carrying an implicit recommendation when this may not be the case. We should cap descriptions at a couple of lines or a single, terse paragraph.

Beyond that, I'd like to introduce a checklist/process that we can use to both approve new third party packages, as well as to (very occasionally) cull the list of recommended packages. I don't want to be too restrictive, but there are several packages that are no longer compatible, and I don't think it's helpful to point users to them. e.g., packages that haven't been updated in 5+ years^[1], packages that have been archived^[2], and packages that don't have tests or CI ^[3]. At a minimum, I think we should require that packages meet the following:

• Must have tests & CI.
• Maybe a baseline coverage metric (70-80%)?
• Must be tested against at least one officially supported version of Django.
• Must be tested against a relatively modern version of DRF (released within the last 2-3 years?). This might be implicitly covered by testing against modern Django versions.

Lastly, the "How to create a Third Party Package" section could use some love. The guide is somewhat outdated, but overall, I'd like to cut down on the amount of information present here. Most users are going to be more concerned with what packages are available rather than the process of creating a package. This information could be moved to a separate resource, and I'm thinking we could maintain our own cookiecutter that maintains this kind of tutorial information.