Removed trailing whitespace (#3485)

docs/dev-process/breaking-change-contract.md

@@ -20,18 +20,18 @@ Any change that is a clear violation of the public contract.
 ### Unacceptable changes:
 
 + A code change that results in a change to the existing behavior observed for a given input with an API, protocol or the PowerShell language.
-+	Renaming or removing a public type, type member, or type parameter; renaming or removing a cmdlet or cmdlet parameter (note: it is possible to rename a cmdlet parameter if a parameter alias is added. This is an acceptable solution for PowerShell scripts but may break .NET code that depends on the name of the original member on the cmdlet object type.)
-+	Decreasing the range of accepted values within a given parameter.
-+	Changing the value of a public constant or enum member; changing the type of a cmdlet parameter to a more restrictive type.
++ Renaming or removing a public type, type member, or type parameter; renaming or removing a cmdlet or cmdlet parameter (note: it is possible to rename a cmdlet parameter if a parameter alias is added. This is an acceptable solution for PowerShell scripts but may break .NET code that depends on the name of the original member on the cmdlet object type.)
++ Decreasing the range of accepted values within a given parameter.
++ Changing the value of a public constant or enum member; changing the type of a cmdlet parameter to a more restrictive type.
     + Example: A cmdlet with a parameter -p1 that was previously type as [object] cannot be changed to be or a more restrictive type such as [int].
-+	Making an incompatible change to any protocol without increasing the protocol version number.
++ Making an incompatible change to any protocol without increasing the protocol version number.
 
 ### Acceptable changes:
 
-+	Any existing behavior that results in an error message generally may be changed to provide new functionality.
-+	A new instance field is added to a type (this impacts .NET serialization but not PowerShell serialization and so is considered acceptable.)
-+	Adding new types, new type members and new cmdlets
-+	Making changes to the protocols with a protocol version increment. Older versions of the protocol would still need to be maintained to allow communication with earlier systems. This would require that protocol negotiation take place between the two systems. In addition to any protocol code changes, the Microsoft Open Specification program requires that the formal protocol specification for a protocol be updated in a timely manner.  An example of a MS protocol specification document (MS-PSRP) can be found at: https://msdn.microsoft.com/en-us/library/dd357801.aspx
++ Any existing behavior that results in an error message generally may be changed to provide new functionality.
++ A new instance field is added to a type (this impacts .NET serialization but not PowerShell serialization and so is considered acceptable.)
++ Adding new types, new type members and new cmdlets
++ Making changes to the protocols with a protocol version increment. Older versions of the protocol would still need to be maintained to allow communication with earlier systems. This would require that protocol negotiation take place between the two systems. In addition to any protocol code changes, the Microsoft Open Specification program requires that the formal protocol specification for a protocol be updated in a timely manner.  An example of a MS protocol specification document (MS-PSRP) can be found at: https://msdn.microsoft.com/en-us/library/dd357801.aspx
 
 ## Bucket 2: Reasonable Grey Area
 
@@ -39,9 +39,9 @@ Change of behavior that customers would have reasonably depended on.
 
 Examples:
 
-+	Change in timing/order of events (even when not specified in docs)
++ Change in timing/order of events (even when not specified in docs)
     + Example: PowerShell events are handled by interleaving their execution with the execution of the main pipeline thread. Where and when this interleaving occurs might change. This order of execution is not specified but is deterministic so changing it might break some scripts.
-+	Change in parsing of input and throwing new errors (even if parsing behavior is not specified in the docs)
++ Change in parsing of input and throwing new errors (even if parsing behavior is not specified in the docs)
     + Example: a script may be using a JSON parser that is forgiving to minor syntactic errors in the JSON text. Changing that parser to be more rigorous in its processing would result in errors being thrown when no error was generated in the past thus breaking scripts.
 
 Judiciously making changes in these type of features require judgement: how predictable, obvious, consistent was the behavior? In general, a significant external preview of the change would need to be done also possibly requiring an RFC to be created to allow for community input on the proposal.
@@ -52,7 +52,7 @@ Change of behavior that customers could have depended on, but probably wouldn't.
 
 Examples:
 
-+ correcting behavior in a subtle corner case that has no obvious utility. 
++ correcting behavior in a subtle corner case that has no obvious utility.
 
     + Example: the existing behavior of the PowerShell cd called without arguments is to do nothing. Changing this behavior to be consistent with UNIX shells which typically set the CWD to the user’s home directory
 
@@ -75,7 +75,7 @@ It is impossible to evolve a code base without making such changes, so we don't
 + All bucket 1, 2, and 3 breaking changes require contacting team at @powershell/powershell.
 + If you're not sure into which bucket a given change falls, contact us as well.
 + It doesn't matter if the existing behavior is "wrong", we still need to think through the implications. PowerShell has been in broad use for over 10 years so we be must be extremely sensitive to breaking existing users and scripts.
-+	If a change is deemed too breaking, we can help identify alternatives such as introducing a new API or cmdlet and obsoleting the old one.
++ If a change is deemed too breaking, we can help identify alternatives such as introducing a new API or cmdlet and obsoleting the old one.
 
 Request for clarifications or suggested alterations to this document should be done by opening issues against this document.
 

docs/dev-process/map-json-files.md

@@ -13,7 +13,7 @@ This file is a simple json hashtable that describes mapping between files in sou
 
 #### Example
 
-There is an entry 
+There is an entry
 
 ```
 "monad/src/engine/COM/ComMethod.cs":  "engine/COM/ComMethod.cs",
@@ -27,16 +27,16 @@ It tells us that file `ComMethod.cs` located at `monad/src/engine/COM/ComMethod.
 Our dev module contains a number of functions that can be used to work with this mapping file.
 
 * `Copy-MappedFiles` -- copies files from psl-monad into PowerShell/PowerShell. Used for "sd -> github" integration.
-* `Send-GitDiffToSd` -- applies patch from git to **admin** enlistment with respect to all `map.json` files. 
+* `Send-GitDiffToSd` -- applies patch from git to **admin** enlistment with respect to all `map.json` files.
   It supports `-WhatIf` switch.
 
 ```
-> Send-GitDiffToSd -diffArg1 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be~1 -diffArg2 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be -AdminRoot d:\e\ps_dev\admin 
+> Send-GitDiffToSd -diffArg1 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be~1 -diffArg2 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be -AdminRoot d:\e\ps_dev\admin
 > cd d:\e\ps_dev\admin
 > sd online ...
 > # move files to new change list (i.e. with sdb)
 > sd submit -c <n>
- 
+
 ```
 
 ## Updating `map.json`
@@ -45,7 +45,7 @@ If you are bringing new (that are not yet included) files from source-depot, you
 
 This way, we can keep track of changes and have ability to integrate changes back to Source Depot.
 
-Use this approach for any files from source-depot (including test files) 
+Use this approach for any files from source-depot (including test files)
 
 ## Creating `map.json`