Merge pull request #15 from alphagov/configure-the-project

Configure the project

Author: stevenjmesser

config/tech-docs.yml

@@ -3,19 +3,18 @@ host: team-docs.design-system.service.gov.uk
 
 # Header-related options
 show_govuk_logo: true
-service_name: Name of API
-service_link: https://www.larry-the-cat.service.gov.uk
-phase: Beta
+service_name: Design System team docs
+service_link: https://team-docs.design-system.service.gov.uk
+phase: Alpha
 
 # Links to show on right-hand-side of header
 header_links:
-  About: https://www.larry-the-cat.service.gov.uk/about
-  Get Started: https://www.larry-the-cat.service.gov.uk/get-started
-  Documentation: /
-  Support: https://www.larry-the-cat.service.gov.uk/support
+  Team: https://design-system.service.gov.uk/design-system-team/
+  Roadmap: https://design-system.service.gov.uk/community/roadmap/
+  Sprint board: https://github.com/orgs/alphagov/projects/53
 
 # Enables search functionality. This indexes pages only and is not recommended for single-page sites.
-enable_search: false
+enable_search: true
 
 # Tracking ID from Google Analytics (e.g. UA-XXXX-Y)
 ga_tracking_id:
@@ -32,8 +31,8 @@ collapsible_nav: true
 max_toc_heading_level: 2
 
 # Prevent robots from indexing (e.g. whilst in development)
-prevent_indexing: false
+prevent_indexing: true
 
 show_contribution_banner: true
-github_repo: alphagov/YOUR_REPO
+github_repo: alphagov/design-system-team-docs
 github_branch: main

source/API-reference.html.md.erb

@@ -1,25 +1,10 @@
 ---
-title: About the [name of API] API
-weight: 10
+title: About these docs
+weight: 1
 ---
 
-# About the [name of API] API
+# About these docs
 
-<%= warning_text("You can use the Technical Documentation Template (TDT) to create and publish technical documentation for users in government, including API documentation.<br/><br/>
-We’ve provided these starting pages with a best practice API documentation structure. It includes the template structure of the documentation sections you need, and is based on <a href='https://www.gov.uk/guidance/how-to-document-apis'>our latest guidance on how to document APIs</a>.<br/><br/>
-You can also start from scratch if you’re not using the TDT to create API documentation.") %>
+This is a reference guide for who we are and the way we do things. It's a playbook for anyone in the GOV.UK Design System team that tells us the 'right way' to do things.
 
-Use this section to start your documentation with a short overview of:
-
-- what your API does and does not do
-- whether your API is in the alpha, beta or live phase
-- the benefits of using the API, so users can compare it to other APIs
-- whether it’s free to use
-- whether your users need to build or buy anything before they use it (technical prerequisites)
-- who can use your API, and any restrictions on using it or its data
-
-Avoid trying to sell your API. Describe features as benefits for your users instead.
-
-Keep your introduction short, so your users can read and understand it easily. For example see the [GOV.UK Platform as a Service (PaaS) introduction page](https://docs.cloud.service.gov.uk/#gov-uk-platform-as-a-service).
-
-You can read more about [documentating APIs](https://www.gov.uk/guidance/how-to-document-apis).
+What's written here is the way we do things now, but that will change from time to time.

source/get-started.html.md.erb

@@ -0,0 +1,40 @@
+---
+title: Principles
+weight: 4
+---
+
+# Principles
+
+These principles guide us in working on the design system. They’re designed to inspire action, help us make decisions and set boundaries. We rely on principles rather than process.
+
+## 1. Be open
+
+Be transparent about our processes and the decisions we make. Take on feedback and change our work or our ideas.
+
+## 2. Be inviting
+
+Actively encourage members of the team, people at GDS, and the wider community to get involved in our work and help shape decisions.
+
+## 3. Transfer power
+
+Enable others to make decisions about the design system. Seek out people and ideas proactively that we can involve in activities.
+
+## 4. Educate
+
+Provide people with the knowledge and skills to iterate and improve the design system sustainably.
+
+## 5. Progress, don’t perfect
+
+Focus on validating the riskiest assumptions. Highlight where the cost of being wrong is low. Trust the community’s insights to guide us. Iterate.
+
+## 6. Don’t skip the basics
+
+We create things of value that are usable, accessible, consistent and versatile. We look after the team’s health. We produce high-quality work and document it for our users.
+
+## 7. Expect a bumpy road
+
+It’s okay to make a call that turned out to be wrong. That’s how we learn and improve. 
+
+## 8. Lift each other up
+
+Own our team and its ceremonies collectively. Create a safe and empathetic environment for each other, facilitators and contributors both. Give or ask for help.

source/how-the-api-works.html.md.erb

@@ -0,0 +1,6 @@
+---
+title: What we do
+weight: 3
+---
+
+# What we do