Update fair-billing-policy.md

articles/billing/fair-billing-policy.md

@@ -0,0 +1,11 @@
+# Fair Billing Policy 
+
+Stoplight's Fair Billing Policy means you will only be charged for active users in any given billing cycle. We adopted the Fair Billing Policy because we believe you should only pay for what you use. We also wanted to avoid setting strict user limits because it can lead to workflow bottlenecks and promotes poor engineering practices. 
+
+## Active User 
+To be considered an active user, you must perform one of the following actions: 
+- Push a commit 
+- Write or modify a file 
+- Publish documentation 
+
+> If you do not perform on of these actions durign a billing cycle, you will be considered inactive, and will not count towards your user count for that billing cycle. 

articles/getting-started/writers-playbook.md

@@ -1,43 +0,0 @@
-# Technical Writer Playbook 
-
-Documenting an API is crucial to its success but can be extremely time consuming. Here at Stoplight, we believe documentation should be beautiful, clean, and robust while maintaining a streamlined turnaround time. We’ve created a holistic documentation tool, Hubs, to address some of the problems our users were facing including:
- 
-- Documenting Endpoints 
-- Testing Endpoints 
-- Creating Non-Reference Documentation 
-- Managing Content
-- External and Internal Referencing 
-- Design and Style 
-
-
-## Documenting Endpoints 
-The most key component to API Documentation are its endpoints. To that end, we created a reference builder that allows you to [“power pages”](/documentation/referencing-other-data-sources) with your specification as you see fit. When you power a page or subpage with your specification, the endpoints are automatically documented and styled for legibility and aesthetic design. 
-
-## Testing Endpoints 
-Testing endpoints is a valuable tool for anyone who wants to consumer your API. Users want to know that your API functions properly before they commit to using it. To address this problem, we created [“Try it Out,” an HTTP Request Maker](/modeling/modeling-with-openapi/sending-http-requests). Try it Out allows you to send HTTP Requests to your API to test out its endpoints under any number of different conditions. You can customize Try it Out with security schemes, variables, headers, queries, and it even generates code in various programming languages. 
-
-## Creating Non-Reference Documentation 
-Great documentation is more than just API endpoints. Guides, tutorials, and other supplemental information enhance your users experience by providing them with all the information they need to access your API and your product. We broadened Hubs scope to accomodate all product documentation needs. You can easily build out your content within [Blocks](/documentation/blocks), a number of flexible content structures that can house a number of different forms of content including markdown, images, code snippets, and much more. 
-
-## Managing Content 
-Organizing a complex APIs endpoints and supplemental information can be a challenging task. Some specification can have hundreds of endpoints with supplemental information throughout. To assist with organizing content, we created an overview of all your pages, subpages, and their connections called “Table of Contents”. With a bird’s eye view of your content, you can easily organize and manage your content through drag drop functionality. 
-
-## External and Internal Referencing 
-To accomodate a larger variety of writing workflows, we expanded the capabilities of [Powering a Page](/documentation/referencing-other-data-sources) to allow for more files internally and externally to be referenced. You can now easily reference specification, Markdown, YAML, JSON, and Scenario files from within a Project or externally located. 
-
-## Design and Style 
-We wanted to create a new, beautiful, minimalistic, efficient design for less design-oriented individuals while allowing for customization. Hubs was designed to be display your documentation in a neat, efficient structure designed specifically for displaying the real beauty, your API. On the other hand, we didn’t want to stifle the creativity that goes into documentation design so we added in [theming](/documentation/design/theming) and [custom CSS](/documentation/design/custom-css). We also made it easier to add navigation, different kinds of content, and a more robust search. 
-
----
-Related Links 
-- [Documentation with Hubs](/documentation/introduction)
-- [Routing](/documentation/getting-started/routing)
-- [Headers](/documentation/getting-started/header-footer)
-- [Pages](/documentation/getting-started/pages)
-- [Subpages](/documentation/getting-started/subpages)
-- [Blocks](/documentation/blocks)
-- [Referencing Other Data Sources](/documentation/referencing-other-data-sources)
-- [Publishing](/documentation/publishing)
-- [Theming](/documentation/design/theming)
-- [Custom CSS](/documentation/design/custom-css)
-