Replace absolute links with relative ones

We previously used absolute links because there was so much linking between micro-sites. Now the content lives in a single repository/build we can use relative links with impunity. This has a big advantage: Docusaurus will error on broken links in the build, so we can have confidence that internal linking works.

With this change there are zero links to playbook.hackney.gov.uk in the site content.

Author: spikeheap

docs/api-playbook/04-Governance/api_compliance.md

@@ -9,8 +9,8 @@ The APIs compliance checklist will be used as part of future Service Standard As
 
 ### Checklist
 1. The API has corresponding SwaggerHub documentation for all of the API endpoints it exposes.
-2. The API has completed the [API specification assessment process](https://playbook.hackney.gov.uk/api-specifications/assessment_process/)
-3. The API has been developed in Hackney’s preferred tech tech stack, unless otherwise agreed and as per standards defined in our [API playbook](https://playbook.hackney.gov.uk/API-Playbook/).
+2. The API has completed the [API specification assessment process](/api-specifications/assessment_process/)
+3. The API has been developed in Hackney’s preferred tech tech stack, unless otherwise agreed and as per standards defined in our [API playbook](/api-playbook/).
 4. The API has been developed following the TDD approach and has end-to-end tets in place
     - End-to-end tests guide for DynamoDB
     - End-to-end tests guide for PostgreSQL

docs/api-playbook/04-Governance/developer_onboarding.md

@@ -9,13 +9,8 @@ We love innovation and are always open to learning, iterating and improving. To
 
 - Our preferred BE stack is documented [here](../../Development%20Lifecycle/How%20to%20build%20an%20API/Preferred%20tech%20stack/).
 
-### Reusable components catalogue
-Before you commence the development of a new API, micro-frontend or NuGet shared package, please refer to our [Developer Hub](https://developer-api.hackney.gov.uk/), where you can find information about available reusable components and APIs available for reuse.
-
-**Please Note:** The Developer Hub is being actively developed. It currently provides information about available APIs, with new features, such as a catalogue of available shared packages, due to be released soon.
-
 ### Development standards
-All technical members of a project team must familiarise themselves with [Hackney’s development standards](https://playbook.hackney.gov.uk/ways-of-working/), which follow the Twelve Factor Application methodology. Those define the high level principles to follow when developing a digital product.
+All technical members of a project team must familiarise themselves with [Hackney’s development standards](/ways-of-working/), which follow the Twelve Factor Application methodology. Those define the high level principles to follow when developing a digital product.
 Playbooks
 
 #### What are they?
@@ -29,61 +24,6 @@ We use playbooks to provide guidance of the standards and ways to implement to e
 #### Technical assessments:
 
 Hackney’s playbooks reflect the standards and quality of technical implementation that digital services should follow and will be assessed against to be accepted into service. We do understand that sometimes there are use cases, which will require a different approach and we are always open to suggestions for improvements. Any deviations or proposals for changes must be documented in the form of an Architecture Decision Record ( ADR ) and presented at a community of practice to promote collaboration and consistency.
-API and Backend services Playbook
-https://playbook.hackney.gov.uk/API-Playbook/
-
-You can find information about:
-- API and Listeners Boilerplate
-- Development process
-- Deployment pipeline
-- IaC approach
-- Testing process
-- Preferred tech stack
-- Data migrations
-- Monitoring
-- Events Driven Architecture
-- Security practices for APIs
-
-### Micro frontends (MFE) Playbook
-https://playbook.hackney.gov.uk/micro-frontends/
-
-You can find information about:
-- MFE cli and boilerplate
-- Development process
-- Testing process
-- Preferred tech stack
-- Quickstart guide
-
-### Communities of practice
-
-#### Technical architecture
-
-**When?** Every Wednesday, 16:00-17:00.
-
-**What is it?** A platform to discuss proposals for changes to technical and architectural approaches and tooling, as well as a place to suggest new technical implementations.
-
-**How can I make use of it?** Please join the #hackit-technical-architecture slack channel and drop a message there with a topic you wish to discuss at the meetup. The meetup is open to everyone so feel free to forward the calendar invitation to anyone who might be interested.
-
-**Paper template:** TBC
-
-#### Data meetup
-
-**When?** Every Tuesday, 15:30 - 16:30.
-
-**What is it?** A platform for proposing changes to existing reusable API’s data models or suggesting the creation of new ones. The community of practice can also be used to discuss any other data related topic, such as data migration technical approaches and overall data architecture discussions.
-
-**How can I make use of it?** Please join the #hackit-data-architecture slack channel and drop a message there with a topic you wish to discuss at the meetup. The meetup is open to everyone so feel free to forward the calendar invitation to anyone who might be interested.
-
-**Paper template:** When preparing a paper to present at the data meetup, please use the following format found [here](https://docs.google.com/document/d/1aIf6K7_ipH7QPtzzBFfSRBhoV98vPVKL5CaKWpLBrs8/edit?usp=sharing).
-
-
-#### Frontend meetup
-
-**When?** Every Thursday, 15:00 - 16:00.
-
-**What is it?** A platform to discuss frontend specific tooling and approaches, micro-frontend architecture and reusability and suggestions for changes.
-
-**How can I make use of it?** Please join the #frontend slack channel and drop a message there with a topic you wish to discuss at the meetup. The meetup is open to everyone so feel free to forward the calendar invitation to anyone who might be interested.
 
 ### Preferred technical stack
 Our preferred technical stack for API and backend services (e.g. Listeners) implementation can be found [here](- Our preferred BE stack is documented [here](../../Development%20Lifecycle/How%20to%20build%20an%20API/Preferred%20tech%20stack/).
@@ -96,17 +36,17 @@ To set up your developer workstation, please refer to the Workstation Setup Guid
 ### Technical ways of working
 
 #### Pull Request process
-Hackney’s official pull request process to follow as part of the Software Development Lifecycle can be found [here](https://playbook.hackney.gov.uk/ways-of-working/).
+Hackney’s official pull request process to follow as part of the Software Development Lifecycle can be found [here](/ways-of-working/).
 
 ### API specifications
-All APIs must be built in a reusable manner, unless they implement a very specific use case. Any new proposed reusable APIs or changes to the data models of existing ones should follow the [API specification assessment process](https://playbook.hackney.gov.uk/api-specifications/assessment_process).
+All APIs must be built in a reusable manner, unless they implement a very specific use case. Any new proposed reusable APIs or changes to the data models of existing ones should follow the [API specification assessment process](/api-specifications/assessment_process).
 
 
 ### API documentation
 We use [SwaggerHub](https://app.swaggerhub.com/organizations/Hackney) to document our APIs and their respective data contracts. All new and existing APIs must have corresponding SwaggerHub documentation. It is the responsibility of the engineers who amend existing APIs to also update the documentation so it is kept up-to-date.
 - If you or your team is building new APIs or making changes to existing API endpoints, please request SwaggerHub access so you can amend the specifications documented to ensure they are always up-to-date.
 
-In addition, we also have [API specifications](https://playbook.hackney.gov.uk/api-specifications/), which capture a summary of the user needs and any other findings related to an API.
+In addition, we also have [API specifications](/api-specifications/), which capture a summary of the user needs and any other findings related to an API.
 - A new API specification must be produced for all new APIs.
 - The API specification document should link off to the SwaggerHub page that outlines the API contract.
 - The API specification should be updated when the API introduces new endpoints or changes to existing functionality.
@@ -128,14 +68,3 @@ You will find information about:
 ### APIs
 To assess the API compliance prior to deploying it, please refer to [APIs compliance checklist](../api_compliance).
 
-### Asking a question
-For any questions and suggestions regarding our tech stack, tools, processes and practices, please contact us via:
-
-- Slack: #hackit-dev-team channel
-- Lead Developers - via direct slack message or email
-    - Mirela Georgieva ([email protected])
-    - Selwyn Preston ([email protected])
-    - Tuomo Karki ([email protected])
-    - David Dean ([email protected])
-    - Faisal Gazi ([email protected])
-

docs/api-playbook/04-Governance/our_ways_of_working.md

@@ -74,8 +74,7 @@ Always follow the **least privilege** principle - only pipeline machine users ha
 
 The Twelve-Factor App Methodology is suggested by developers for smoothly working and delivering Software as a Service (SaaS) Applications or Web Apps with a focus on Microservices.
 
-More information about Hackney Council’s Development standards can be found on the link below:
-    [https://playbook.hackney.gov.uk/ways-of-working/](https://playbook.hackney.gov.uk/ways-of-working/)
+More information about Hackney Council’s Development standards can be found [here](/ways-of-working/)
 
 As part of our Organisation's ways of working and managing APIs, we encourage developers that every time an API is deployed to production to publish the Swagger definition accordingly.
 
@@ -90,7 +89,3 @@ As part of our Organisation's ways of working and managing APIs, we encourage de
 - Notifications by email if secrets are exposed, pipelines cancel deployment if errors occur.
 - AWS scans our repositories
 - GitGuardian scanning
-
-**Continuous Feedback**
-
-We are always looking at ways we can improve. If you have any ideas or suggestions please share your feedback on our playbook [GitHub Repo](https://github.com/LBHackney-IT/API-Playbook).

docs/api-playbook/09-Support/creating_support_doc.md

@@ -25,4 +25,4 @@ To create support documentation that is easy to find and becomes quickly availab
     - The item to be included should match the id you have given to the support document created.
 - Create a pull request with your changes.
 
-Once the changes are approved and merged, the support documentation will be available at https://playbook.hackney.gov.uk/API-Playbook/.
+Once the changes are approved and merged, the support documentation will be available in the [API playbook](/api-playbook/).

docs/api-playbook/README.md

@@ -23,6 +23,3 @@ Today we have come to the point where our playbook has taken a more governance r
 
 ## Who this Playbook is for:
 This playbook is primarily used to onboard new developers, whether they are new members of staff or new agency partners we work with. However, we would be thrilled if this playbook is also read by a wider audience. We are also always happy to receive contributions or feedback to make this even better.
-
-## Help us improve:
-We are always looking at ways we can improve. If you have any ideas or suggestions please share your feedback on our playbook [GitHub Repo](https://github.com/LBHackney-IT/API-Playbook).

docs/api-specifications/README.md

@@ -10,6 +10,3 @@ Some people may wonder why we have decided to publish our design specifications.
 - Learning - the specifications are a quick reference point on how we design the various APIs
 - Onboarding - a quick way to get colleagues up to speed on the design/development process
 - Continuous collaboration - as technology evolves and as we get new points of view there is always the opportunity to revisit our designs and improve on them. Our specs should be where this all kicks off.
-
-## Help us improve
-We are always looking at ways we can improve. If you have any ideas or suggestions please share your feedback on our Specifications [GitHub Repo](https://github.com/LBHackney-IT/API-Specifications).

…/api-specifications/asessment_process.md …api-specifications/assessment_process.mddocs/api-specifications/asessment_process.md renamed to docs/api-specifications/assessment_process.md docs/api-specifications/asessment_process.md renamed to docs/api-specifications/assessment_process.md

@@ -1,3 +1,6 @@
+---
+sidebar_position: 1
+---
 # Assessment Process
 ## Purpose
 The purpose of this process is to provide a clear,open and  consistent method of providing new and amended API specifications, evaluating them and getting them published in a way that is easy for a wider audience to access.

docs/architecture-pillars/1-Reliability/automated_remediation.md

@@ -9,8 +9,8 @@ AWS Config official documentation that details additional features can be found
 
 In Hackney, we are adopting several mechanisms to ensure that deployed resources are compliant with our preferred configuration, e.g. no database should be publicly accessible. Those include:
 - Following the [least privilege principle](../../Security/dev_least_principles/), where engineers are unable to manually create AWS resources but must instead automate the creation via IaC (infrastructure as code) and CI/CD pipelines.
-- Adopting [Terraform-compliance](https://playbook.hackney.gov.uk/API-Playbook/terraform_compliance) security and compliance testing framework for performing pre-deployment  checks to ensure only compliant resources are deployed.
-- Using [serverless safeguards](https://playbook.hackney.gov.uk/API-Playbook/serverless_safegaurd)  to ensure AWS resources provisioned via the Serverless framework are also compliant.
+- Adopting [Terraform-compliance](/api-playbook/Development%20Lifecycle/API%20Practices%20and%20tools/terraform_compliance/) security and compliance testing framework for performing pre-deployment  checks to ensure only compliant resources are deployed.
+- Using [serverless safeguards](/api-playbook/Development%20Lifecycle/API%20Practices%20and%20tools/serverless_safeguard/)  to ensure AWS resources provisioned via the Serverless framework are also compliant.
 
 However, some of those must be set up on a per-project basis, thus not guaranteeing security risks prevention by the proposed mechanisms due to no current way to ensure 100% take up amongst project teams.
 

docs/architecture-pillars/1-Reliability/core_resource_compliance.md

@@ -1,7 +1,7 @@
 # Core AWS resources compliance checks
 
 ### Context
-At Hackney, we follow an infrastructure-as-code (IaC) approach and use Terraform to provision most of our AWS cloud resources. For our APIs, which are Lambda functions exposed via AWS API Gateway, we use the Serverless framework as it significantly speeds up the delivery and resource creation.  For more information please refer to [our playbook](https://playbook.hackney.gov.uk/API-Playbook/).
+At Hackney, we follow an infrastructure-as-code (IaC) approach and use Terraform to provision most of our AWS cloud resources. For our APIs, which are Lambda functions exposed via AWS API Gateway, we use the Serverless framework as it significantly speeds up the delivery and resource creation.  For more information please refer to [our playbook](/api-playbook/).
 
 From a Development perspective, each project manages its own Terraform files(or Serverless configuration) to provision resources for our microservices and frontend applications. Terraform is then applied automatically as part of the CI/CD pipeline workflow during deployment.
 

docs/architecture-pillars/1-Reliability/preferred_data_source.md

@@ -10,7 +10,7 @@
 **If a new data store is required:**
 - Perform an evaluation if SQL or NoSQL is more suitable for your project’s needs.
     - [Guidance provided further down in this document.](#choosing-the-right-type-of-database-technology)
-- Design the API that will interact with the data and present it at the Data Meetup as per our [API specifications assessment process.](https://playbook.hackney.gov.uk/api-specifications/assessment_process/)
+- Design the API that will interact with the data and present it at the Data Meetup as per our [API specifications assessment process.](/api-specifications/assessment_process/)
 - Use Terraform to provision the new database resource in AWS.
     - Use one of the [Terraform common repository](https://github.com/LBHackney-IT/aws-hackney-common-terraform) templates (if applicable)