Fix broken links in documentation (microsoft#146237)

Author: ImJoakim

doc/Authoring.md

@@ -1,7 +1,7 @@
-[Manifest Specification]:   doc/manifest/schema/1.6.0
-[versionSchema]:            doc/manifest/schema/1.6.0/version.md
-[defaultLocaleSchema]:      doc/manifest/schema/1.6.0/defaultLocale.md
-[installerSchema]:          doc/manifest/schema/1.6.0/installer.md
+[Manifest Specification]:   manifest/schema/1.6.0
+[versionSchema]:            manifest/schema/1.6.0/version.md
+[defaultLocaleSchema]:      manifest/schema/1.6.0/defaultLocale.md
+[installerSchema]:          manifest/schema/1.6.0/installer.md
 
 # Authoring Manifests
 
@@ -41,7 +41,7 @@ Manifests submitted to the Windows Package Manager Community Repository should b
 
 ## Creating your first manifest
 
-Once you have a package in mind that doesn't already exist in the repository, you can now start [creating your package manifest](https://docs.microsoft.com/en-us/windows/package-manager/package/manifest?tabs=minschema%2Cversion-example). We recommend using the [Windows Package Manager Manifest Creator (a.k.a Winget-Create)](https://github.com/microsoft/winget-create) to help you generate your manifest. Winget-Create is a command line tool that will prompt you for relevant metadata related to your package. Once you are done, Winget-Create will validate your manifest to verify that it is correct and allow you to submit your newly-created manifest directly to the winget-pkgs repository by linking your GitHub account. Alternatively, you can use the [YamlCreate.ps1 Script](Tools/YamlCreate.ps1). More information on using YamlCreate is found in the [script documentation](doc/tools/YamlCreate.md).
+Once you have a package in mind that doesn't already exist in the repository, you can now start [creating your package manifest](https://docs.microsoft.com/en-us/windows/package-manager/package/manifest?tabs=minschema%2Cversion-example). We recommend using the [Windows Package Manager Manifest Creator (a.k.a Winget-Create)](https://github.com/microsoft/winget-create) to help you generate your manifest. Winget-Create is a command line tool that will prompt you for relevant metadata related to your package. Once you are done, Winget-Create will validate your manifest to verify that it is correct and allow you to submit your newly-created manifest directly to the winget-pkgs repository by linking your GitHub account. Alternatively, you can use the [YamlCreate.ps1 Script](/Tools/YamlCreate.ps1). More information on using YamlCreate is found in the [script documentation](tools/YamlCreate.md).
 
 ## Installer Architectures
 If you are authoring a manifest yourself one of the important things to note related to installer types is architecture. In many cases the installer itself may be an x86 installer, but it will actually install the package for the architecture of the system. In these cases, the installer type in the manifest should indicate the architecture of the installed binaries. So in some cases the actual installer itself targets x86, but in fact it will install an x64 version of the package.

doc/FAQ.md

@@ -23,11 +23,11 @@ Getting started is the hard part. There are several tools which we recommend for
 
 First is the [Windows Package Manager Manifest Creator (a.k.a Winget-Create)](https://github.com/microsoft/winget-create). Winget-Create is a command line tool that will prompt you for relevant metadata related to your package. Once you are done, Winget-Create will validate your manifest to verify that it is correct and allow you to submit your newly-created manifest directly to the winget-pkgs repository by linking your GitHub account.
 
-Second is the [YamlCreate PowerShell Script](Tools/YamlCreate.ps1). This tool is great for those who are technically inclined and understand the basics of forking, cloning, and commits. YamlCreate iterates much faster than Winget-Create but has largely the same functionality. More information on YamlCreate can be found in the [Script Documentation](doc/tools/YamlCreate.md).
+Second is the [YamlCreate PowerShell Script](/Tools/YamlCreate.ps1). This tool is great for those who are technically inclined and understand the basics of forking, cloning, and commits. YamlCreate iterates much faster than Winget-Create but has largely the same functionality. More information on YamlCreate can be found in the [Script Documentation](tools/YamlCreate.md).
 
-Need more information? Take a look at the document on [Authoring Manifests](AUTHORING_MANIFESTS.md) and the [Microsoft Documentation Site](https://docs.microsoft.com/windows/package-manager/package/manifest).
+Need more information? Take a look at the document on [Authoring Manifests](Authoring.md) and the [Microsoft Documentation Site](https://docs.microsoft.com/windows/package-manager/package/manifest).
 ## **How do I get the AppsAndFeaturesEntries for an installer?**
-The best way to get the AppsAndFeaturesEntries, or the ARP Entries, for an installer is to run the installer inside of the [Windows Sandbox](https://docs.microsoft.com/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview). Instructions on how to enable the sandbox can be found at the link above, or in the [SandboxTest PowerShell Script Documentation](doc/tools/SandboxTest.md). The [SandboxTest PowerShell Script](/Tools/SandboxTest.ps1) is a great way to get the AppsAndFeaturesEntries for a manifest you have already created. The SandboxTest Script will validate and test the manifest by downloading and installing the package in the Sandbox and comparing the ARP Entries before and after the installation. For the technically savvy, @jedieaston has created an [Add-ARPEntries Script](https://github.com/jedieaston/Add-ARPEntries) which uses Docker to populate the AppsAndFeaturesEntries for an existing manifest. Please note, however, that only the ARP Entry for the *Primary Component* should be added when a package installs multiple components.
+The best way to get the AppsAndFeaturesEntries, or the ARP Entries, for an installer is to run the installer inside of the [Windows Sandbox](https://docs.microsoft.com/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview). Instructions on how to enable the sandbox can be found at the link above, or in the [SandboxTest PowerShell Script Documentation](tools/SandboxTest.md). The [SandboxTest PowerShell Script](/Tools/SandboxTest.ps1) is a great way to get the AppsAndFeaturesEntries for a manifest you have already created. The SandboxTest Script will validate and test the manifest by downloading and installing the package in the Sandbox and comparing the ARP Entries before and after the installation. For the technically savvy, @jedieaston has created an [Add-ARPEntries Script](https://github.com/jedieaston/Add-ARPEntries) which uses Docker to populate the AppsAndFeaturesEntries for an existing manifest. Please note, however, that only the ARP Entry for the *Primary Component* should be added when a package installs multiple components.
 ## **What should I do if a package is being published by a new publisher?**
 The best practice for this is to create a situation where the package automatically switches to the new publisher using the ARP Entries for the package. To do this, two copies of the package must be added to the repository - one under the original package identifier and one under a new package identifier for the new publisher. This will cause anyone on a package published by the old publisher to be updated to the new version, at which point the ARP Entries will cause the Windows Package Manager to match the package to the new publisher and all future updates will be taken from the new package identifier.
 
@@ -38,7 +38,7 @@ For the package version added under the new package identifier, the metadata sho
 *Additional Notes*:
 While this is currently the best practice, this may change in the future with the implementation of [microsoft/winget-cl#1899](https://github.com/microsoft/winget-cli/issues/1899) and [microsoft/winget-cl#1900](https://github.com/microsoft/winget-cli/issues/1900). The origination of this best practice can be found [here](https://github.com/microsoft/winget-pkgs/issues/66937#issuecomment-1190154419)
 ## **How long do packages take to be published?**
-The answer to this question depends on multiple factors. First, the pull request approval. When submitting a package to the repository, your pull request will go through a series of automated checks in the validation pipeline. You will see labels applied to your pull request based on the results of the validation. Secondly, all pull requests must be reviewed and approved by one of our [community moderators](https://github.com/microsoft/winget-pkgs/blob/master/Moderation.md). Finally, the pull request must be merged and pass through the publishing pipeline. Once the publishing pipeline has succeeded for your pull request, you will see a comment and a label indicating this status.
+The answer to this question depends on multiple factors. First, the pull request approval. When submitting a package to the repository, your pull request will go through a series of automated checks in the validation pipeline. You will see labels applied to your pull request based on the results of the validation. Secondly, all pull requests must be reviewed and approved by one of our [community moderators](Moderation.md). Finally, the pull request must be merged and pass through the publishing pipeline. Once the publishing pipeline has succeeded for your pull request, you will see a comment and a label indicating this status.
 
 After your PR is approved and merged, the changes are *generally* published within one hour. If you are not seeing the changes published after your pull request has been merged, check the [WinGetSvc-Publish Pipeline](https://dev.azure.com/ms/winget-pkgs/_build?definitionId=338) for errors. If the pipeline is erroring, please check to see if any [issues](https://github.com/microsoft/winget-pkgs/issues) have been opened regarding the failures and create a [new issue](https://github.com/microsoft/winget-pkgs/issues/new) if there isn't one already.
 ## **What does this label on my PR mean?**

doc/Moderation.md

@@ -4,7 +4,7 @@ The Windows Package Manager community repository is the location for manifests p
 
 ## Moderators
 
-In addition to Microsoft employees, several community members have been identified through their high-quality submissions, willingness to help others, and adherence to our [code of conduct](CODE_OF_CONDUCT.md).
+In addition to Microsoft employees, several community members have been identified through their high-quality submissions, willingness to help others, and adherence to our [code of conduct](/CODE_OF_CONDUCT.md).
 
 When we initially implemented moderation, we observed several objective criteria. These included the number of Pull Requests (PR)s made, the length of time they had been active in the project, and their interaction with others who submitted PRs.
 

doc/README.md

@@ -37,7 +37,7 @@ For more details, see ["Submit packages to Windows Package Manager"](https://doc
 
 ### In Windows Sandbox
 
-You can use the [Sandbox Test](Tools/SandboxTest.ps1) PowerShell script for testing a manifest installation in [Windows Sandbox](https://docs.microsoft.com/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview). The manifest will be also validated.
+You can use the [Sandbox Test](/Tools/SandboxTest.ps1) PowerShell script for testing a manifest installation in [Windows Sandbox](https://docs.microsoft.com/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview). The manifest will be also validated.
 
 Just provide the path to manifest as parameter:
 
@@ -50,7 +50,7 @@ Just provide the path to manifest as parameter:
 To submit a package to this repository, you should follow these steps:
 
 1. Follow the [Contributing](#contributing) guidelines below.
-2. [Author](AUTHORING_MANIFESTS.md) a Manifest.
+2. [Author](Authoring.md) a Manifest.
 3. [Test](#test-your-manifest) your manifest.
 4. [Submit](#submit-your-pr) your pull request (PR).
 5. Respond to any feedback in your PR.