Bug 1408827 - Where is code link broken for DevTools documentation. r=sole
authorMiguel Useche <migueluseche@mozilla-hispano.org>
Mon, 20 Nov 2017 23:11:15 -0400
changeset 438091 d51767ade62cb979d95e3e2adce51ea057919000
parent 438090 7e60ad275b73df53b06eebe2d71b788016e45cd6
child 438092 c3cd5881c7ee9e5c6b9d8b02c074c5b59cb94219
push id117
push userfmarier@mozilla.com
push dateTue, 28 Nov 2017 20:17:16 +0000
reviewerssole
bugs1408827
milestone59.0a1
Bug 1408827 - Where is code link broken for DevTools documentation. r=sole
devtools/docs/contributing/making-prs.md
devtools/docs/getting-started/README.md
--- a/devtools/docs/contributing/making-prs.md
+++ b/devtools/docs/contributing/making-prs.md
@@ -7,17 +7,17 @@
 To create a patch you need to first commit your changes and then export them to a patch file.
 
 With Mercurial:
 * `hg commit -m 'your commit message'`
 * `hg export > /path/to/your/patch`
 
 With Git, the process is similar, but you first need to add an alias to create Mercurial-style patches. Have a look at [the detailed documentation](https://developer.mozilla.org/en-US/docs/Tools/Contributing#Creating_a_patch_to_check_in).
 
-## Commit messags
+## Commit messages
 
 Commit messages should follow the pattern `Bug 1234567 - change description. r=reviewer`
 
 First is the bug number related to the patch. Then the description should explain what the patch changes. The last part is used to keep track of the reviewer for the patch.
 
 ## Submitting a patch
 
 Once you have a patch file, add it as an attachment to the Bugzilla ticket you are working on and add the `feedback?` or `review?` flag depending on if you just want feedback and confirmation you're doing the right thing or if you think the patch is ready to land respectively. Read more about [how to submit a patch and the Bugzilla review cycle here](https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch).
--- a/devtools/docs/getting-started/README.md
+++ b/devtools/docs/getting-started/README.md
@@ -1,12 +1,12 @@
 # Getting started
 
-1. Learn [where the code is](./getting-started/where-is-the-code.md) and about the [architecture](./getting-started/servers-and-actors.md) of the tools.
-2. [Set up your machine](./getting-started/build.md) to build the tools, then [configure a development profile](getting-started/development-profiles.md).
-3. You can now experiment by changing things and rebuilding, look at the [files and directories overview](../files/README.md) or you could also [find something to work on](./bugs-issues.md).
+1. Learn [where the code is](./where-is-the-code.md) and about the [architecture](./architecture-overview.md) of the tools.
+2. [Set up your machine](./build.md) to build the tools, then [configure a development profile](development-profiles.md).
+3. You can now experiment by changing things and rebuilding, look at the [files and directories overview](../files/README.md) or you could also [find something to work on](../bugs-issues.md).
 
 ## Additional documentation
 
-* [Mozilla Developer Network](http://developer.mozilla.org/) (also known as *MDN*) has a lot of information about XUL elements, HTML, JS, DOM, Web APIs, Gecko-specific APIs, and more.
+* [MDN Web Docs](http://developer.mozilla.org/) (also known as *MDN*) has a lot of information about XUL elements, HTML, JS, DOM, Web APIs, Gecko-specific APIs, and more.
 * [DXR](http://dxr.mozilla.org/mozilla-central/source/) is a source code search engine - search for symbols you want to learn about, eg. `nsIDocument`. [Searchfox](http://searchfox.org/mozilla-central/source) is an alternative.
 
 It is a good idea to [add smart keyword searches](https://support.mozilla.org/en-US/kb/how-search-from-address-bar) for DXR and MDN, so you can search faster.