finishing touches

peps/pep-0752.rst

@@ -81,15 +81,15 @@ Other package ecosystems have generally solved this problem by taking one of
 two approaches: either minimizing or maximizing backwards compatibility.
 
 * `NPM <https://www.npmjs.com>`__ has the concept of
-  `scoped modules <https://docs.npmjs.com/about-scopes>`__ which were
+  `scoped packages <https://docs.npmjs.com/about-scopes>`__ which were
   `introduced`__ primarily to combat there being a dearth of available good
   package names (whether a real or perceived phenomenon). When a user or
   organization signs up they are given a scope that matches their name. For
   example, the
   `package <https://www.npmjs.com/package/@google-cloud/storage>`__ for using
   Google Cloud Storage is ``@google-cloud/storage`` where ``@google-cloud/`` is
-  the scope. Regular user accounts (non-organization) may publish
-  `unscoped <https://docs.npmjs.com/about-scopes>`__ packages for public use.
+  the scope. Regular user accounts (non-organization) may publish `unscoped`__
+  packages for public use.
   This approach has the lowest amount of backwards compatibility because every
   installer and tool has to be modified to account for scopes.
 * `NuGet <https://www.nuget.org>`__ has the concept of
@@ -105,6 +105,7 @@ two approaches: either minimizing or maximizing backwards compatibility.
   indices like PyPI are required and installers do not need to change.
 
 __ https://blog.npmjs.org/post/116936804365/solving-npms-hard-problem-naming-packages
+__ https://docs.npmjs.com/package-scope-access-level-and-visibility
 __ https://learn.microsoft.com/en-us/nuget/nuget-org/id-prefix-reservation
 __ https://devblogs.microsoft.com/nuget/Package-identity-and-trust/