Merge pull request #6898 from keveleigh/header-casing

Header capitalization phase 2

Author: David Kline

Documentation/Contributing/CONTRIBUTING.md

@@ -17,7 +17,7 @@ From here you file:
 - **Documentation issue** - Issue with the Mixed Reality Toolkit [documentation](https://microsoft.github.io/MixedRealityToolkit-Unity)
 - **Feature request** - Proposal for a new Mixed Reality Toolkit feature
 
-## Proposing Feature Requests
+## Proposing feature requests
 
 When requesting a new Mixed Reality Toolkit feature, it is important to document the customer benefit / problem to be solved. Once submitted, a feature request will be reviewed and discussed on GitHub. We encourage open and constructive discussion of each feature proposal to ensure that the work is beneficial to a large segment of customers.
 

Documentation/Contributing/CodingGuidelines.md

@@ -26,7 +26,7 @@ MRTK supports a diverse set of users – people who prefer to configure componen
 
 All your code should work by BOTH adding a component to a GameObject in a saved scene, and by instantiating that component in code. Tests should include a test case both for instantiating prefabs and instantiating, configuring the component at runtime.
 
-### Play-In-Editor is your first and primary target platform
+### Play-in-editor is your first and primary target platform
 
 Play-In-Editor is the fastest way to iterate in Unity. Providing ways for our customers to iterate quickly allows them to both develop solutions more quickly and try out more ideas. In other words, maximizing the speed of iteration empowers our customers to achieve more.
 
@@ -44,7 +44,7 @@ MRTK is a community project, modified by a diverse range of contributors. These
 
 When you fix a bug, write a test to ensure it does not regress in the future. If adding a feature, write tests that verify your feature works. This is required for all UX features except experimental features.
 
-## Coding Conventions
+## Coding conventions
 
 ### Script license information headers
 
@@ -55,7 +55,7 @@ All Microsoft employees contributing new files should add the following standard
 // Licensed under the MIT License.
 ```
 
-### Function / Method summary headers
+### Function / method summary headers
 
 All public classes, structs, enums, functions, properties, fields posted to the MRTK should be described as to its purpose and use, exactly as shown below:
 
@@ -106,7 +106,7 @@ In the example below, the *Package here* should be filled with the package locat
 public class MyNewComponent : MonoBehaviour
 ```
 
-### Spaces vs Tabs
+### Spaces vs tabs
 
 Please be sure to use 4 spaces instead of tabs when contributing to this project.
 
@@ -135,7 +135,7 @@ private Foo()
 }
 ```
 
-### Naming Conventions
+### Naming conventions
 
 Always use `PascalCase` for public / protected / virtual properties, and `camelCase` for private properties and fields. The only exception to this is for data structures that require the fields to be serialized by the `JsonUtility`.
 
@@ -154,7 +154,7 @@ protected string MyProperty;
 private string myProperty;
 ```
 
-### Access Modifiers
+### Access modifiers
 
 Always declare an access modifier for all fields, properties and methods.
 
@@ -188,7 +188,7 @@ public void Bar() { }
 protected virtual void FooBar() { }
 ```
 
-### Use Braces
+### Use braces
 
 Always use braces after each statement block, and place them on the next line.
 
@@ -289,7 +289,7 @@ public class MyClass
 }
 ```
 
-### Initialize Enums
+### Initialize enums
 
 To ensure all enums are initialized correctly starting at 0, .NET gives you a tidy shortcut to automatically initialize the enum by just adding the first (starter) value. (e.g Value 1 = 0 Remaining values are not required)
 
@@ -315,7 +315,7 @@ public enum ValueType
 }
 ```
 
-### Order Enums for appropriate extension
+### Order enums for appropriate extension
 
 It is critical that if an Enum is likely to be extended in the future, to order defaults at the top of the Enum, this ensures Enum indexes are not affected with new additions.
 
@@ -364,7 +364,7 @@ public enum SDKType
 }
 ```
 
-### Review Enum use for Bitfields
+### Review enum use for bitfields
 
 If there is a possibility for an enum to require multiple states as a value, e.g. Handedness = Left & Right. Then the Enum needs to be decorated correctly with BitFlags to enable it to be used correctly
 
@@ -394,7 +394,7 @@ public enum Handedness
 }
 ```
 
-## Best Practices, including Unity recommendations
+## Best practices, including Unity recommendations
 
 Some of the target platforms of this project require to take performance into consideration. With this in mind always be careful when allocating memory in frequently called code in tight update loops or algorithms.
 

Documentation/Contributing/ExperimentalFeatures.md

@@ -1,4 +1,4 @@
-# Experimental Features
+# Experimental features
 
 Some features the MRTK team works on appear to have a lot of initial value even if we haven’t fully fleshed out the details. For these types of features, we want the community to get a chance to see them early. Because they are early in the cycle, we label them as experimental to indicate that they are still evolving, and subject to change over time.
 
@@ -31,7 +31,7 @@ Keep scenes in a scene folder near the top: `MRTK.Examples/Experimental/FooBar/S
 > [!NOTE]
 > We considered not having a single Experimental root folder and instead putting Experimental under say `MRTK.Examples/HandTracking/Scenes/Experimental/HandBasedMenuExample.unity`. We decided to go with folders at the base to make the experimental features easier to discover.
 
-### Experimental Code should be in a special namespace
+### Experimental code should be in a special namespace
 
 Ensure that the experimental code lives in an experimental namespace that matches the non-experimental location. For example,
 if your component is part of solvers at `Microsoft.MixedReality.Toolkit.Utilities.Solvers`, its namespace should be `Microsoft.MixedReality.Toolkit.Experimental.Utilities.Solvers`.
@@ -43,18 +43,19 @@ See [this PR](https://github.com/microsoft/MixedRealityToolkit-Unity/pull/4532)
 Add an `[Experimental]` attribute above one of your fields to have a small dialog appear in the component editor that mentions your feature is experimental and subject to significant changes.
 
 ### Menus for experimental features should go under "Experimental" sub-menu
+
 Ensure that experimental features are under "experimental" sub-menus when adding commands to menus in the editor. Here are a few examples:
 
 Adding a top-level menu command:
 
-```csharp
+```c#
 [MenuItem("Mixed Reality Toolkit/Experimental/MyCommand")]
 public static void MyCommand()
 ```
 
 Adding a component menu:
 
-```csharp
+```c#
 [AddComponentMenu("MRTK/Experimental/MyCommand")]
 ```
 
@@ -71,15 +72,15 @@ Aim to have zero changes in folders other than experimental folders. Here is a l
 
 Changes outside of these folders should be treated very carefully. If your experimental feature must include changes to MRTK core code, consider splitting out MRTK changes into a separate pull request that includes tests and documentation.
 
-### Using you experimental feature should not impact people's ability to use core controls
+### Using your experimental feature should not impact people's ability to use core controls
 
 Most people use core UX components like the button, ManipulationHandler and Interactable very frequently. They will likely not use your experimental feature if it prevents them from using buttons.
 
 Using your component should not break buttons, ManipulationHandler, BoundingBox, or interactable.
 
 For example, in [this ScrollableObjectCollection PR](https://github.com/microsoft/MixedRealityToolkit-Unity/pull/6001), adding a ScrollableObjectCollection caused people to not be able to use the HoloLens button prefabs. Even though this was not caused by a bug in the PR (but rather exposed an existing bug), it prevented the PR from getting checked in.
 
-### Provide and example scene that demonstrates how to use the feature
+### Provide an example scene that demonstrates how to use the feature
 
 People need to see how to use your feature, and how to test it.
 
@@ -91,7 +92,7 @@ Others will not use the experimental feature if it does not work, it will not gr
 
 Test your example scene on your target platform, make sure it works as expected. Make sure your feature also works in editor, so people can rapidly iterate and see your feature even if they don’t have the target platform.
 
-## Graduating experimental code into MRTK code  
+## Graduating experimental code into MRTK code
 
 If a feature ends up seeing quite a lot of use, then we should graduate it into core MRTK code. To do this, the feature should have tests, documentation, and an example scene.
 

Documentation/Contributing/Feature_Contribution_Process.md

@@ -1,4 +1,4 @@
-# Feature Contribution Process
+# Feature contribution process
 
 > [!WARNING]
 > 10/1/2019: This page is deprecated because it provides guidelines for contributing very large systems to MRTK before the 2.0 release. After the 2.0 release, large changes need to be performed more carefully, and the process for this is not yet decided. We expect most MRTK contributions to have much smaller changes than what is covered here.
@@ -16,13 +16,13 @@ The following process has been drafted to ensure all new work complies to the up
 5. [Submit a PR Implementing any required SDK components](#sdk-implementation)
 6. [Submit a PR Implementing feature demos or full scale Examples](#example-implementation)
 
-### New Proposal
+### New proposal
 
 Start by opening a new Proposal or Task describing the feature or the problem you want to solve. Describe the approach and how it fits into the version of the Mixed Reality Toolkit you're targeting. This will enable everyone have a discussion about the proposal and, hopefully, identify some potential pitfalls before any work is started.
 
 New Proposals will be reviewed and discussed during our weekly ship room meetings and if a proposal is accepted, supplemental tasks will then be created and assigned.
 
-### Architecture Draft
+### Architecture draft
 
 The first task once the initial proposal has been accepted, will be to draft the initial architecture document for the feature or work to be done. This document should typically be one or two pages long and include a high level overview of the feature and how it will relate to other parts of the Mixed Reality Toolkit.
 
@@ -36,7 +36,7 @@ Ensure that the architecture of the feature complies with the [New Feature Requi
 
 Once the draft is completed, this can be appended to the Proposal / Task issue on GitHub for final public review.
 
-### Architecture Documentation
+### Architecture documentation
 
 Once the draft architecture is accepted, additional pull requests can be made to submit the final full architecture documents to the repository.
 
@@ -46,7 +46,7 @@ Once the architecture document is approved, only then can the first code submiss
 
 Development can begin in your own private branch and complete as normal, however, the PR's submitted back to the core MRTK project should be submitted in stages to ensure the review and approval is as smooth as it can be (and ensure core changes do not impact other features)
 
-### Core Implementation
+### Core implementation
 
 The initial work that should be submitted, is to implement:
 
@@ -59,26 +59,26 @@ If needed, the architectural document can be updated to align with any changes t
 
 Please ensure that all existing Unit Tests and any new tests are all passing prior to submission.
 
-### SDK Implementation
+### SDK implementation
 
 Once the core interfaces and events are merged in to development, work can then be submitted for the SDK components.  Adding the concrete implementation of the feature and testing against the supported platforms and unit tests.
 
-### Example Implementation
+### Example implementation
 
 Once the SDK components are merged, then any demo scenes or updates to the example scenes can be submitted.
 
 * Demos are for specific feature highlighting and demonstration
 * Examples are full working scene learning examples
 
-## New Feature Requirements
+## New feature requirements
 
 Most feature implementations can be broken down into 3 main parts:
 
 1. [The Feature Manager](#manager-implementation-requirements)
 2. [The Event Data](#event-data-implementation-requirements) (Optional)
 3. [The Feature Handler](#handler-implementation-requirements) (Optional)
 
-### Manager Implementation Requirements
+### Manager implementation requirements
 
 * Assembly Definitions for code outside of the `MixedRealityToolkit` folder.
   * This ensures features are self-contained and have no dependencies to other features.
@@ -95,14 +95,14 @@ Most feature implementations can be broken down into 3 main parts:
 * Have a default implementation located in `MixedRealityToolkit.Services/<FeatureName>`
 * Events that can be raised with the system should be defined in the interface, with all the required parameters for initializing the event data.
 
-### Event Data Implementation Requirements
+### Event data implementation requirements
 
 The Event Data defines exactly what data the handler is expected to receive from the event.
 
 * All Event Datum for the feature should be defined in `MixedRealityToolkit/EventDatum/<FeatureName>`.
 * All new Event Data classes should inherit from `GenericBaseEventData`
 
-### Handler Implementation Requirements
+### Handler implementation requirements
 
 The Handler Interface defines each event a component should be listening for and the types of data passed. End users will implement the interface to execute logic based on the event data received.
 

Documentation/Contributing/PullRequests.md

@@ -1,4 +1,4 @@
-# Pull Requests
+# Pull requests
 
 ## Prerequisites
 
@@ -8,7 +8,7 @@ A comment in the PR will let you know if you do.
 > [!IMPORTANT]
 > If you are a Microsoft employee and are not a member of the [Microsoft organization on GitHub](https://github.com/Microsoft), please link your Microsoft and GitHub accounts on corpnet by visiting [Open Source at Microsoft](https://opensource.microsoft.com/) before you start your pull request. There's some process stuff you'll need to do ahead of time.
 
-## Creating a Pull Request
+## Creating a pull request
 
 When you are ready to submit a pull request, [create a pull request](https://github.com/microsoft/MixedRealityToolkit-Unity/compare/mrtk_development...mrtk_development?expand=1) targeting the [mrtk_development](https://github.com/microsoft/mixedrealitytoolkit-unity/tree/mrtk_development) branch.
 
@@ -25,7 +25,7 @@ The project maintainers will review your changes. We aim to review all changes w
 > [!NOTE]
 > All PR's submitted to the project will also be vetted according to the [MRTK coding standards guide](CodingGuidelines.md), so please review these before submitting your PR to ensure a smooth process.
 
-## Pull Request Guidelines
+## Pull request guidelines
 
 These guidelines are based off of the [Google's engineering practices](https://google.github.io/eng-practices/review/developer/small-cls.html).
 

Documentation/Contributing/Roadmap.md

@@ -2,11 +2,11 @@
 
 This document outlines the roadmap of the Mixed Reality Toolkit.
 
-## Current Release
+## Current release
 
 [Microsoft Mixed Reality Toolkit v2.1.0](https://github.com/Microsoft/MixedRealityToolkit-Unity/releases/tag/v2.1.0)
 
-## Upcoming Releases
+## Upcoming releases
 
 | Product | Description | Timeline | Project board |
 | --- | --- | --- | --- |
@@ -15,7 +15,7 @@ This document outlines the roadmap of the Mixed Reality Toolkit.
 
 Release details, including backlog items, can be found on the [GitHub milestone pages](https://github.com/Microsoft/MixedRealityToolkit-Unity/milestones). The complete set of open issues can also be found on [GitHub](https://github.com/microsoft/MixedRealityToolkit-Unity/issues).
 
-## Mixed Reality Toolkit (MRTK) Roadmap
+## Mixed Reality Toolkit (MRTK) roadmap
 
 The Mixed Reality Toolkit is an all-new product, built to be cross MR/AR/VR/XR platform by design. There are two planned pre-releases after which the Mixed Reality Toolkit will become the primary product.
 

Documentation/Contributing/UnitTests.md

@@ -1,4 +1,4 @@
-# Writing and Running Tests in MRTK
+# Writing and running tests in MRTK
 
 To ensure MRTK is reliable, MRTK has a set of tests to ensure that changes to the code does not regress existing behavior. Having good test coverage in a big codebase like MRTK is crucial for stability and having confidence when making changes.
 
@@ -43,7 +43,7 @@ It's also possible to run the playmode tests multiple times via the `run_repeat_
 .\run_repeat_tests.ps1 -Times 5
 ```
 
-### Pull Request Validation
+### Pull request validation
 
 MRTK's CI will build MRTK in all configurations and run all edit and play mode tests. CI can be triggered by posting a comment on the github PR `/azp run mrtk_pr` if the user has sufficient rights. CI runs can be seen in the 'checks' tab of the PR.
 
@@ -66,15 +66,15 @@ public IEnumerator MyTest() {...}
 
 Run the following from a command line ([PowerShell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell?view=powershell-6#powershell-core) is recommended)
 
-```ps
+```powershell
 cd scripts\tests
 # Repeat the test 5 times. Default is 100
 python .\generate_repeat_tests.py -n 5 -t MyTest
 ```
 
 Copy and paste the output into your test file. The following script is for running multiple tests in sequence:
 
-```ps
+```powershell
 cd scripts\tests
 # Repeat the test 5 times. Default is 100
 python .\generate_repeat_tests.py -n 5 -t MyTest MySecondTest

Documentation/CrossPlatform/UsingARFoundation.md

@@ -1,6 +1,6 @@
 # How to configure MRTK for iOS and Android [Experimental]
 
-## Install Required Packages
+## Install required packages
 
 1. Download and import the **Microsoft.MixedReality.Toolkit.Providers.UnityAR** package, from [GitHub](https://github.com/microsoft/MixedRealityToolkit-Unity/releases/tag/v2.2.0) or [NuGet](../MRTKNuGetPackage.md)
 
@@ -64,7 +64,7 @@ The following steps presume use of the MixedRealityToolkit object. Steps require
 
     For more information about configuring the Unity AR camera settings provider: [Unity AR camera settings provider](../CameraSystem/UnityArCameraSettings.md).
 
-## Building a Scene for Android and iOS devices
+## Building a scene for Android and iOS devices
 
 1. Make sure you have added the UnityAR Camera Settings Provider to your scene.
 
@@ -87,6 +87,6 @@ iOS Project Configurator Settings
 
 5. Build and run the scene
 
-## See Also
+## See also
 
 - [Unity AR Camera Settings](../CameraSystem/UnityArCameraSettings.md)

Documentation/DetectingPlatformCapabilities.md

@@ -9,7 +9,7 @@ provides a way to identify specific capabilities at runtime, (e.g. if the curren
 The Mixed Reality Toolkit provides the [`MixedRealityCapability`](xref:Microsoft.MixedReality.Toolkit.MixedRealityCapability)
 enumeration, which defines a set of capabilities for which an application can query at runtime.
 
-### Input System capabilities
+### Input system capabilities
 
 The default MRTK Input System supports querying the following capabilities:
 
@@ -34,7 +34,7 @@ if (capabilityCheck != null)
 }
 ```
 
-### Spatial Awareness capabilities
+### Spatial awareness capabilities
 
 The default MRTK Spatial Awareness system supports querying the following capabilities:
 
@@ -56,7 +56,7 @@ if (capabilityCheck != null)
 }
 ```
 
-## See Also
+## See also
 
 - [IMixedRealityCapabilityCheck API documentation](xref:Microsoft.MixedReality.Toolkit.IMixedRealityCapabilityCheck)
 - [MixedRealityCapability enum documentation](xref:Microsoft.MixedReality.Toolkit.MixedRealityCapability)