Fix minor typos

ghdocs/BestPractices/ComponentDesign.md

@@ -83,7 +83,7 @@ controlling the disabled state of the input element.)
 
 |BAD|GOOD|Notes|
 |---|----|-----|
-|isChecked|checked|There is an HTML precidence for checked.|
+|isChecked|checked|There is an HTML precedence for checked.|
 |isVisible|visible|
 |isSelected|selected|
 |isEnabled|disabled|If the state is enabled by default, it should be named for the exceptional case.|
@@ -464,9 +464,9 @@ class Foo extends React.Component {
   }
 ```
 
-## Experimental: Use a store for storing shared state within a component heirachy which must be shared across objects
+## Experimental: Use a store for storing shared state within a component hierarchy which must be shared across objects
 
-While React state management is very useful for simple, private state, it becomes unweildy when many things share that state
+While React state management is very useful for simple, private state, it becomes unwieldy when many things share that state
 and you start ending up with many owners of the same state value. In these cases it may drive you towards a flux solution, but
 before we jump there, lets call out a few things.
 
@@ -571,7 +571,7 @@ html[dir=rtl] .ms-Foo {
 }
 ```
 
-Additionaly try to have symetrical paddings rather than using padding-right or left specifics.
+Additionally try to have symmetrical paddings rather than using padding-right or left specifics.
 
 ## Do not use core fabric classnames, but instead use core fabric scss mixins.
 

ghdocs/BestPractices/Styling.md

@@ -295,7 +295,7 @@ Scenarios like "make this area of the screen use a different theme" become reall
 
 If a button has 20 different possible states, using scss you must load the css for all 20 of the states pre-emptively, so you end up loading way more rules than you will ever actually use. There is no "plt1 styles vs delay loaded styles". The best you can do is to partition your css to specific modules, and delay load the modules. But in this model, you will still preempt loading a lot of rules that aren't used.
 
-Sass also encourages "mixins" as a way to have one definition of styles that can be used in multiple places. This completely fights against bundle size, since mixins simply stamp duplicates copies of the same rules whereever they're used, resulting in bloated (but highly compressable) style definitions. The compression helps but all of this could be avoided by using a different approach to defining our styling.
+Sass also encourages "mixins" as a way to have one definition of styles that can be used in multiple places. This completely fights against bundle size, since mixins simply stamp duplicates copies of the same rules wherever they're used, resulting in bloated (but highly compressible) style definitions. The compression helps but all of this could be avoided by using a different approach to defining our styling.
 
 ## Constant battle with specificity
 

ghdocs/Contributing/ChangeFiles.md

@@ -5,7 +5,7 @@ When we publish new releases, we need to know what major, minor or patch changes
 
 ## Writing a change description
 
-Please write a change desription such that it is easy for the release manager to understand the impact of the change. When we ship out new releases, we need to build a cumulative set of **Release notes**. Those release notes are a summation of individual changes checked in. Hence, it is important that developers write clear and understandable change descriptions.
+Please write a change description such that it is easy for the release manager to understand the impact of the change. When we ship out new releases, we need to build a cumulative set of **Release notes**. Those release notes are a summation of individual changes checked in. Hence, it is important that developers write clear and understandable change descriptions.
 
 ## Change annotation