handbook-normalize-heading (#3459)

Normalized the headings through out the handbook and updated associated css styling.

handbook/README.md

@@ -1,3 +1,5 @@
+# Welcome to Fleet
+
 ## Introduction
 
 The Fleet handbook is the central guide for how we run the company. As part of our value of being transparent, the handbook is open to the world. We welcome feedback, and contributions, so please make a merge request with suggested improvements throughout these pages.  

handbook/company.md

@@ -23,27 +23,27 @@ Zach partnered with our CEO, Mike McNeil, to found a new, independent company: F
 
 ### Quickly with craft
 
-##### Iterate by taking baby steps. 
+#### Iterate by taking baby steps. 
 
 We try to always make the minimum viable change. Small changes provide faster feedback, and help us to stay focused on quality. 
 
-##### Help each other get all the way done. 
+#### Help each other get all the way done. 
 
 We collaborate and help our teammates to see tasks through to completion.
 
-##### Focus on fewer tasks at one time. 
+#### Focus on fewer tasks at one time. 
 
 By focusing on fewer tasks at once, we are able to get more done, and to a higher standard, while feeling more positive about our work in the process. 
 
-##### Role play as a user.
+#### Role play as a user.
 
 When making changes, we put ourselves in the mindset of the end user. We keep in mind how someone might use the product for the first time, or how an existing user might react to a new change.
 
-##### Reread anything you write for users.
+#### Reread anything you write for users.
 
 We check everything that a user might read for clarity, spelling errors, and to make sure that it provides value.
 
-##### Review and merge PRs daily. 
+#### Review and merge PRs daily. 
 
 We value constant iteration and feedback. Reviewing and merging PRs daily keeps our open source community thriving.
 

handbook/engineering.md

@@ -32,13 +32,13 @@ Check out the [Fleet 4.1.0 blog post](https://blog.fleetdm.com/fleet-4-1-0-57dfa
 
 **Upgrade plan** - Once sentence that links to user to the upgrading Fleet documentation here: https://github.com/fleetdm/fleet/blob/main/docs/01-Using-Fleet/08-Updating-Fleet.md
 
-#### Manual QA
+### Manual QA
 
 After all changes required for release have been merged into the `main` branch, the individual tasked with managing the release should perform smoke tests. Manual smoke tests should be generated for a release via the [Release QA ticket template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=&template=smoke-tests.md&title=) and assigned to the person responsible. 
 
 Further ocumentation on conducting the manual QA pass can be found [here](#manual-qa). 
 
-#### Release freeze period
+### Release freeze period
 
 In order to ensure quality releases, Fleet has a freeze period for testing prior to each release. Effective at the start of the freeze period, new feature work will not be merged. 
 
@@ -89,7 +89,7 @@ Premium support for support/troubleshooting: **All versions**
 
 - If things get heated, remember to stay [positive and helpful](https://canny.io/blog/moderating-user-comments-diplomatically/).  If you aren't sure how best to respond in a positive way, or if you see behavior that violates the Fleet code of conduct, get help.
 
-#### Requesting more details
+### Requesting more details
 
 Typically, the *questions*, *bug reports*, and *feature requests* raised by members of the community will be missing helpful context, recreation steps, or motivations respectively.
 
@@ -108,13 +108,13 @@ Typically, the *questions*, *bug reports*, and *feature requests* raised by memb
 - Let's say a community member submits the feature request "I want the ability to do X in Fleet." A follow up question could be "If you were able to do X in Fleet, what's the next action you would take?" or "Why do you want to do X in Fleet?." 
 - Both of these questions provide helpful context on the underlying motivation behind the feature request when it is brought to the Roundup meeting. In addition, the community member receives a response and feels heard.
 
-#### Feature requests
+### Feature requests
 
 If the feature is requested by a customer, the on-call engineer is requested to create a feature request issue and follow up with the customer by linking them to this issue. This way, the customer can add additional comments or feedback to the newly filed feature request issue.
 
 If the feature is requested by anyone other than a customer (ex. user in #fleet Slack), the on-call engineer is requested to point to the user to the [feature request GitHub issue template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=idea&template=feature-request.md&title=) and kindly ask the user to create a feature request.
 
-#### Closing issues
+### Closing issues
 
 It is often a good idea to let the original poster (OP) close their issue themselves, since they are usually well equipped to decide whether the issue is resolved.   In some cases, circling back with the OP can be impractical, and for the sake of speed issues might get closed.
 

website/assets/styles/pages/handbook/basic-handbook.less

@@ -142,6 +142,7 @@
 
     h1 {
       padding-bottom: 16px;
+      margin-top: 24px;
       margin-bottom: 0px;
       font-size: 36px;
       line-height: 48px;
@@ -169,10 +170,11 @@
       font-weight: 700;
     }
     h4 {
-      font-size: 18px;
+      font-size: 16px;
       padding-top: 24px;
       padding-bottom: 16px;
       margin-bottom: 0px;
+      font-weight: 700;
     }
     h5 {
       font-weight: 700;