Update a few docs bits and pieces (#11423)

Author: PyvesB

doc/adding-new-config-values.md

@@ -6,15 +6,15 @@ Any new configuration setting or secret must be correctly registered so that it
 
 This generally includes adding the corresponding information for your new setting(s)/secret(s) to the following locations:
 
-- [core/server/server.js](https://github.com/badges/shields/blob/master/core/server/server.js) - Add the new values to the [schemas](https://github.com/badges/shields/blob/master/core/server/server.js#L118-L193). Secrets/tokens/etc. should go in the `privateConfigSchema` while non-secret configuration settings should go in the `publicConfigSchema`.
+- [core/server/server.js](https://github.com/badges/shields/blob/master/core/server/server.js) - Add the new values to the [schemas](https://github.com/badges/shields/blob/e1443eb7146466ad987830c1f286e2b0b186500c/core/server/server.js#L67-L215). Secrets/tokens/etc. should go in the `privateConfigSchema` while non-secret configuration settings should go in the `publicConfigSchema`.
 - [config/custom-environment-variables.yml](https://github.com/badges/shields/blob/master/config/custom-environment-variables.yml)
 - [docs/server-secrets.md](https://github.com/badges/shields/blob/master/doc/server-secrets.md) (only applicable for secrets)
 - [config/default.yml](https://github.com/badges/shields/blob/master/config/default.yml) (optional)
 - Any other template config files (e.g. `config/local.template.yml`) (optional)
 
 The exact values needed will depend on what type of secret/setting you are adding, but for reference a few commits are included below which added secrets and or settings:
 
-- (secret) [8a9efb2fc99f97e78ab133c836ab1685803bf4df](https://github.com/badges/shields/commit/8a9efb2fc99f97e78ab133c836ab1685803bf4df)
+- (secret) [4a75cf09a786c5e93232ae699af985e5bc89440e](https://github.com/badges/shields/commit/4a75cf09a786c5e93232ae699af985e5bc89440e)
 - (secret) [bd6f4ee1465d14a8f188c37823748a21b6a46762](https://github.com/badges/shields/commit/bd6f4ee1465d14a8f188c37823748a21b6a46762)
 - (secret) [0fd557d7bb623e3852c92cebac586d5f6d6d89d8](https://github.com/badges/shields/commit/0fd557d7bb623e3852c92cebac586d5f6d6d89d8)
 - (configuration setting) [b1fc4925928c061234e9492f3794c0797467e123](https://github.com/badges/shields/commit/b1fc4925928c061234e9492f3794c0797467e123)

doc/code-walkthrough.md

@@ -99,7 +99,7 @@ test this kind of logic through unit tests (e.g. of `render()` and
 
 [entrypoint]: https://github.com/badges/shields/blob/master/server.js
 [core/server/server]: https://github.com/badges/shields/blob/master/core/server/server.js
-[scoutcamp]: https://github.com/espadrine/sc
+[scoutcamp]: https://github.com/badges/sc
 [legacy-request-handler]: https://github.com/badges/shields/blob/master/core/base-service/legacy-request-handler.js
 
 ## Downstream caching

doc/deprecating-badges.md

@@ -145,4 +145,4 @@ Some other information that may be useful:
 - [Contributing Docs](../CONTRIBUTING.md)
 - [Badge Tutorial](./TUTORIAL.md)
 - [Service Tests Tutorial](./service-tests.md)
-- Previous Pull Requests that deprecated badges like [#2352](https://github.com/badges/shields/pull/2352) and [#2410](https://github.com/badges/shields/pull/2410)
+- Previous Pull Requests that deprecated badges like [#10371](https://github.com/badges/shields/pull/10371) and [#11075](https://github.com/badges/shields/pull/11075)

doc/input-validation.md

@@ -8,7 +8,7 @@ When we receive input data from an upstream API, we perform input validation to:
 
 ## Writing schemas and validation
 
-- The default validation mechanism should be to use [Joi](https://github.com/sideway/joi) to define a schema for the input data. Validation against Joi schemas is implemented in the base classes and inherited by every service class that extends them. Sometimes additional manual validation is needed which can't be covered by Joi and plugins in which case we implement it by hand.
+- The default validation mechanism should be to use [Joi](https://github.com/hapijs/joi) to define a schema for the input data. Validation against Joi schemas is implemented in the base classes and inherited by every service class that extends them. Sometimes additional manual validation is needed which can't be covered by Joi and plugins in which case we implement it by hand.
 
 - If validation is implemented manually (because we need to enforce a constraint that can't be expressed with Joi), invalid data should throw an [InvalidResponse](https://contributing.shields.io/module-core_base-service_errors-InvalidResponse.html) exception.
 
@@ -23,7 +23,7 @@ When we receive input data from an upstream API, we perform input validation to:
 
 - We don't need to validate characteristics we don't rely on. For example, if we're just going to render a version on a badge with the same exact value from the API response and do not need to sort or transform the value, then it doesn't matter what format the version number is in. We can use a very relaxed schema to validate in this case, e.g. `Joi.string().required()`
 
-- http://mterczynski.pl/joi-schema-generator/ is a tool that can be used to reverse engineer a schema from an API response. This can be a great starting point to tweak from. If using this as a starting point, remember to remove fields we don't rely on to render a badge.
+- https://joi.dev/tester/ is a tool that can be used to reverse engineer a schema from an API response. This can be a great starting point to tweak from. If using this as a starting point, remember to remove fields we don't rely on to render a badge.
 
 - If theory (docs) and practice (real-world API responses) conflict, real-world outputs take precedence over documented behaviour. e.g: if the docs say version is a semver but we learn that there are real-world packages where the version number is `0.3b` or `1.2.1.27` then we should accept those values in preference to enforcing the documented API behaviour.
 

doc/releases.md

@@ -20,7 +20,7 @@ This is the core, free, anonymous service available for anyone to use and which
 
 We do not have a fixed schedule for deploying updates to the Shields.io production environment, but we typically deploy the latest version at least once per week.
 
-We do not have any guaranteed SLA for the Shields.io service, but we do have monitoring and observability capabilities in place and our [Operations team](https://github.com/badges/shields#project-leaders) will review and address any availability, performance, etc. issues on a best-effort basis.
+We do not have any guaranteed SLA for the Shields.io service, but we do have monitoring and observability capabilities in place and our [Maintainer team](https://github.com/badges/shields#project-leaders) will review and address any availability, performance, etc. issues on a best-effort basis.
 
 More information about the production environment can be found [here][production hosting]
 

doc/service-tests.md

@@ -224,7 +224,7 @@ take effect, including the HTTP method (in this case GET), scheme (https), host,
 and path.
 
 [icedfrisby-nock]: https://github.com/paulmelnikow/icedfrisby-nock#usage
-[nock]: https://github.com/node-nock/nock
+[nock]: https://github.com/nock/nock
 
 ## Code coverage
 
@@ -254,4 +254,4 @@ comment there instead.
 - [IcedFrisby API][]
 - [Joi API][]
 - [icedfrisby-nock][]
-- [Nock API](https://github.com/node-nock/nock#use)
+- [Nock API](https://github.com/nock/nock#usage)