Small typos and markdown document root

Contributors.txt

@@ -0,0 +1,14 @@
+Georgi Chkodrov
+Bart de Smet 
+Aaron Lahman
+Erik Meijer
+Brian Grunkemeyer
+Beysim Sezgin
+Tiho Tarnavski
+Collin Meek
+Sajay Anthony
+Karen Albrecht
+John Allen
+Zach Kramer
+Jose Wilson Morris
+Sergey Baranchenkov

Doc/PlaybackInternals.md

@@ -39,14 +39,12 @@ In this simple case:
 ## Dealing with heterogeneity
 Life would be easy if everyone was tracing like IIS does.
 
-Unfortunately:
+Unfortunately, there is difference between Manifest and Classic providers:
 
-- There is difference between Manifest and Classic providers. 
-> In Manifest providers events are identified with { ProviderId, EventId, Version }. 
+- In Manifest providers events are identified with { ProviderId, EventId, Version }. 
+- In Classic providers events are identified as { EventGuid, Opcode, Version }
 
-> In Classic providers events are identified as { EventGuid, Opcode, Version }
-
-- There are many other formats completely different from ETW
+There are many other formats completely different from ETW
 
 Thus the real implementation of Playback contains few more parts:
 

README.md

@@ -1,25 +1,38 @@
 # Tx (LINQ to Logs and Traces)
  
-Tx is set of code samples showing how to use LINQ to events, such as:
+Tx allows you to do Language Integrated Query (LINQ) directly on raw event sources:
 
-* **Real-Time standing queries:**. E.g. producing a histogram every second how many bytes were send/received over TCP per IP address. 
-* **Queries on past history from trace/log files:** E.g. from past trace of IIS find the slow requests by correlating "begin" and "end" events.
+- ad-hoc query on past history in trace and log files
+- standing queries on real-time feeds, such as Event Tracing for Windows (ETW) sessions
 
-The initial set of supported technologies is:
-
-* Event Tracing for Windows (ETW)
-* Windows Event Logs
-* W3C Logs from IIS
-* Performance counter captures (.blg, ,csv, .tsv)
-* SQL Server Extended Events (XEvent)
-
-At its very core the Tx approach represents design pattern for building parsers.
-I.e. extending it is easy.
-
-Example of the extensibility is trace in the ULS (Unified Logging Service) format 
+The Tx approach is different than Databases, Hadoop, Splunk, Dapper, etc. which all require a stage of uploading before the events become available to queries.
 
+Instead, mixing Reactive Extensions (Rx) and LINQ-to-Objects allows the query to be embedded anywhere including:
 
+- In light-weight UI tools like [LINQPad](Source/Tx.LinqPad/Readme.md)  and [SvcPerf](http://svcperf.codeplex.com)
+- On original source machines, such as [Synthetic Counters](Samples/SyntheticCounters/readme.md)
 
+The following picture shows the dependencies among the main Tx components:
+
+![TxCodeMap.JPG](TxCodeMap.JPG)
+
+Here:
+
+- Dark green is .Net
+- Light green is mature open source
+- Light grey are framework components, also available on NuGet
+- Darker gray are tool experiences that come with Tx
+- White are samples
+
+For more see the [documentation](Doc\Readme.md)
+
+## Contribute
+
+There are lots of ways to [contribute](https://tx.codeplex.com/wikipage?title=Contributing) to the project, and we appreciate our [contributors](Contributors.txt).
+
+You can contribute by reviewing and sending feedback on code checkins, suggesting and trying out new features as they are implemented, submit bugs and help us verify fixes as they are checked in, as well as submit code fixes or code contributions of your own. Note that all code submissions will be rigorously reviewed and tested by the Rx Team, and only those that meet an extremely high bar for both quality and design/roadmap appropriateness will be merged into the source.
+
+You will need to sign a Contributor License Agreement before submitting your pull request. To complete the Contributor License Agreement (CLA), you will need to submit a request via the form (select "Reactive Extensions") and then electronically sign the Contributor License Agreement when you receive the email containing the link to the document. This needs to only be done once for any Microsoft Open Technologies OSS project.
 
 
 

Samples/Introduction/UlsLogs/Readme.md

@@ -79,7 +79,7 @@ The first choice here is which I*TypeMap interface to use:
 
 * Use ITypeMap if implementing plain transformation (all output events have the same type)
 * Use IRootTypeMap when implementing base class representing multiple possible partitioning mechanisms
-** Example is how the manifest vs. classic difference in ETW does not impact getting a timestamp from the header nor layout of the binary data (See [EtwTypeMap](../../../Source/Tx.Windows/EtwNative/EtwTypeMap.cs)
+** Example is how the manifest vs. classic difference in ETW does not impact getting a timestamp from the header nor layout of the binary data (See [EtwTypeMap](../../../Source/Tx.Windows/EtwNative/EtwTypeMap.cs))
 * Use IPartitionableTypeMap when:
 ** the input is multiplexed sequence of many types of event, that can be distinguished by some partition key
 ** the schema for any two occurrences of events with the same key is the same