Added an intro section to CSE (microsoft#2)

Added an intro to CSE and the respective links
daparm · Aug 10, 2018 · d14cb3a · d14cb3a
1 parent fdfa0cb
commit d14cb3a
Show file tree

Hide file tree

Showing 10 changed files with 30 additions and 21 deletions.
diff --git a/CSE.md b/CSE.md
@@ -0,0 +1,9 @@
+# Microsoft CSE (Commercial Software Engineering)
+
+Our team, CSE (Commercial Software Engineering), works side by side with customers to help them tackle their toughest technical problems both in the cloud and on the edge. We meet customers where they are, work in the languages they use, with the open source frameworks they use, on the operating systems they use. We work with enterprises and startups across many industries from financial services to manufacturing. Our work covers a broad spectrum of domains including IoT, machine learning, and high scale compute. Our "super power" is that we work closely with both our customers’ engineering teams and Microsoft’s product engineering teams, developing real-world expertise that we use to help our customers grow their business and help Microsoft improve our products and services.
+
+We are very community focused in our work, with one foot in Microsoft and one foot in the open source communities that we help. We make pull requests on open source projects to add support for Microsoft platforms and/or improve existing implementations. We build frameworks and other tools to make it easier for developers to use Microsoft platforms. We source all the ideas for this work by maintaining very deep connections with these communities and the customers and partners that use them.
+
+If you like variety, coding in many languages, using any available tech across our industry, digging in with our customers, hackfests, occasional travel, and telling the story of what you’ve done in [blog posts](https://www.microsoft.com/developerblog/) and at conferences, then come talk to us. 
+
+> You can checkout some of our work on our [Developer Blog](https://www.microsoft.com/developerblog/)
diff --git a/Engineering/CodeReviews.md b/Engineering/CodeReviews.md
@@ -1,6 +1,6 @@
 # Code Reviews
 
-Developers working on CSE projects will conduct peer code reviews on every pull request (or check-in to a shared branch).
+Developers working on [CSE](../CSE.md) projects will conduct peer code reviews on every pull request (or check-in to a shared branch).
 
 ## Goals
 
@@ -46,8 +46,8 @@ The following guidelines are framed prescriptively in terms of VSTS git, but app
         *   Each team may choose to _maintain or reset_ votes when code changes as part of a review.
     *   Every pull request _must_ be linked to a work item.
     *   All code review comments must be resolved before completing the pull request.
-    *   Enforce the standard merge strategy described in CSE's [Source Control](../Engineering/SourceControl.md) guidance.
-    *   Per CSE's [CI/CD](../Engineering/CICD.md) guidance, execute a build on every pull request and update to a pull request to verify that:
+    *   Enforce the standard merge strategy described in [CSE](../CSE.md)'s [Source Control](../Engineering/SourceControl.md) guidance.
+    *   Per [CSE](../CSE.md)'s [CI/CD](../Engineering/CICD.md) guidance, execute a build on every pull request and update to a pull request to verify that:
         *   The project builds without warnings.
         *   All unit tests pass.
         *   The code passes all configured lint rules.

diff --git a/Engineering/CodeReviews/CSharp.md b/Engineering/CodeReviews/CSharp.md
@@ -2,11 +2,11 @@
 
 ## C# Style Guide
 
-CSE developers follow Microsoft's [C# Coding Conventions](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions) and, where applicable, Microsoft's [Secure Coding Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines).
+[CSE](../CSE.md) developers follow Microsoft's [C# Coding Conventions](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions) and, where applicable, Microsoft's [Secure Coding Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines).
 
 ## Linters
 
-CSE projects should check code style with the [StyleCop Analyzers for the .NET Compiler Platform](https://github.com/DotNetAnalyzers/StyleCopAnalyzers). The minimum rules set teams should adopt is the [Managed Recommended Rules](https://msdn.microsoft.com/en-us/library/dd264893.aspx) rule set.
+[CSE](../CSE.md) projects should check code style with the [StyleCop Analyzers for the .NET Compiler Platform](https://github.com/DotNetAnalyzers/StyleCopAnalyzers). The minimum rules set teams should adopt is the [Managed Recommended Rules](https://msdn.microsoft.com/en-us/library/dd264893.aspx) rule set.
 
 Documentation on setting up code analysis for a project is provided [here](https://docs.microsoft.com/en-us/visualstudio/code-quality/code-analysis-for-managed-code-overview).
 

diff --git a/Engineering/CodeReviews/Go.md b/Engineering/CodeReviews/Go.md
@@ -16,7 +16,7 @@ All developers should run ```gofmt``` in a pre-commit hook to ensure standard fo
 
 ### ```go vet```
 
-```go vet``` is a static analysis tool that checks for common go errors, such as incorrect use of range loop variables or misaligned printf arguments. CSE Go code should be able to build with no ```go vet``` errors.
+```go vet``` is a static analysis tool that checks for common go errors, such as incorrect use of range loop variables or misaligned printf arguments. [CSE](../CSE.md) Go code should be able to build with no ```go vet``` errors.
 
 ### What about ```golint```?
 

diff --git a/Engineering/CodeReviews/Python.md b/Engineering/CodeReviews/Python.md
@@ -2,11 +2,11 @@
 
 ## Python Style Guide
 
-CSE developers follow [Google's Python Style Guide](https://google.github.io/styleguide/pyguide.html).
+[CSE](../CSE.md) developers follow [Google's Python Style Guide](https://google.github.io/styleguide/pyguide.html).
 
 ## Linters
 
-CSE projects should check Python code with automated tools. ```pylint``` is the minimum, but we prefer to run three different tools:
+[CSE](../CSE.md) projects should check Python code with automated tools. ```pylint``` is the minimum, but we prefer to run three different tools:
 
 ### [```Pyflakes```](https://github.com/PyCQA/pyflakes)
 

diff --git a/Engineering/Retrospectives.md b/Engineering/Retrospectives.md
@@ -1,6 +1,6 @@
 # Retrospectives
 
-Development teams working on CSE projects will conduct [agile retrospectives](https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649) for each iteration and project milestone.
+Development teams working on [CSE](../CSE.md) projects will conduct [agile retrospectives](https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649) for each iteration and project milestone.
 
 ## Goals
 
@@ -28,15 +28,15 @@ Within that script, the facilitator can make choices with regard to which activi
 
 ### Project or Milestone Retrospective
 
-These are the most intense retrospectives, in that they cover more project working time and should be the strictest with regard to following the ceremony described in the retrospective book. The goal of most project or milestone retrospectives is to identify proposed changes that the engineering crew or all of CSE might try in the next project. Teams should cover the overall project or milestone, including the development phase, how the on-site hack went, how well the customer engineering team engaged, how well the wrap up activities went, how well the whole CSE team worked together, etc.
+These are the most intense retrospectives, in that they cover more project working time and should be the strictest with regard to following the ceremony described in the retrospective book. The goal of most project or milestone retrospectives is to identify proposed changes that the engineering crew or all of [CSE](../CSE.md) might try in the next project. Teams should cover the overall project or milestone, including the development phase, how the on-site hack went, how well the customer engineering team engaged, how well the wrap up activities went, how well the whole [CSE](../CSE.md) team worked together, etc.
 
 A project or milestone retrospective will usually take **3-4 hours**, depending on how long or complex the milestone was and how many people are involved in the retrospective.
 
-We recommend that project and milestone retrospectives bring in an experienced facilitator to work with the team. CSE will maintain a list of experienced facilitators for teams to request.
+We recommend that project and milestone retrospectives bring in an experienced facilitator to work with the team. [CSE](../CSE.md) will maintain a list of experienced facilitators for teams to request.
 
 1. Set the stage.
     1. Thank everyone for being here.
-    1. Walk through the standard CSE retrospective introduction slide deck, reminding everyone of the purpose, script, and expected behaviors.
+    1. Walk through the standard [CSE](../CSE.md) retrospective introduction slide deck, reminding everyone of the purpose, script, and expected behaviors.
     1. Each participant introduces themselves and their role on the project.
     1. Do one Set the Stage activity: 4.1-4.3.
     1. Run a quick Working Agreement activity (4.4) to give participants a chance to add any items to the standard working agreement.

diff --git a/Engineering/SourceControl.md b/Engineering/SourceControl.md
@@ -1,8 +1,8 @@
 # Source Control
-There are many different options when working with Source Control. In CSE we use [VSTS](https://csesd.visualstudio.com/_projects) for private repositories and [GitHub](https://github.com/) for public repositories.
+There are many different options when working with Source Control. In [CSE](../CSE.md) we use [VSTS](https://csesd.visualstudio.com/_projects) for private repositories and [GitHub](https://github.com/) for public repositories.
 
 ## Goals
-* Following industry best practice to work in geo-distributed teams which encourage contributions from all across CSE as well as the broader OSS community
+* Following industry best practice to work in geo-distributed teams which encourage contributions from all across [CSE](../CSE.md) as well as the broader OSS community
 * Improve code quality by enforcing reviews before merging into master branches
 * Improve traceability of features and fixes through a clean commit history
 
@@ -23,9 +23,9 @@ Consistency is crucial, therefore the team has to agree on their approach before
 
 ## Resources
 * [Git](https://git-scm.com/) `--local-branching-on-the-cheap`
-* [VSTS](https://www.visualstudio.com/team-services/) --> Question: Do we have a an account for hosting CSE projects or is the plan to host them on individual/regional accounts?
+* [VSTS](https://www.visualstudio.com/team-services/)
 * [the GitHub Hello World](https://guides.github.com/activities/hello-world/)
-* [CSE Git details](SourceControlDetails.md) provides details and best practices on how to use Git as part of a CSE project.
+* [CSE Git details](SourceControlDetails.md) provides details and best practices on how to use Git as part of a [CSE](../CSE.md) project.
 
 ## Q&A
 ### Q: I just committed a secret - how can I remove it from the git history?

diff --git a/Engineering/SourceControlDetails.md b/Engineering/SourceControlDetails.md
@@ -19,7 +19,7 @@ A public repository needs to have the following files in the root directory of t
 
 It's also important to reference the Microsoft Open Source Code of Conduct in the [README.md](Templates/README.md) and/or [CONTRIBUTING.md](Templates/CONTRIBUTING.md) files.
 
-Links to CSE template files: [LICENSE](Templates/LICENSE), [README.md](Templates/README.md) and [CONTRIBUTING.md](Templates/CONTRIBUTING.md) 
+Links to [CSE](../CSE.md) template files: [LICENSE](Templates/LICENSE), [README.md](Templates/README.md) and [CONTRIBUTING.md](Templates/CONTRIBUTING.md) 
 
 To start to contribute by creating your own branch (e.g. `user/your_alias/feature_name`) and committing early and often - just ensure your commit comments are useful to others and describe the *WHAT* and *WHY* (instead of the *HOW*). 
 

diff --git a/Engineering/UnitTesting.md b/Engineering/UnitTesting.md
@@ -1,7 +1,7 @@
 # Unit Testing
 
 ## Goals
-Unit tests play an integral role in building quality software and enabling agile methodologies. CSE recommends all efforts follow [Test Driven Development](http://deviq.com/test-driven-development/) where ever possible, i.e. code should have unit tests unless it's developed for an environment with unit testing capabilities, e.g. Azure Stream Analytics. With TDD, engineers start with coding the test(s), which will initially fail. The implementation of the unit is finished when the unit satisfies the tests.
+Unit tests play an integral role in building quality software and enabling agile methodologies. [CSE](../CSE.md) recommends all efforts follow [Test Driven Development](http://deviq.com/test-driven-development/) where ever possible, i.e. code should have unit tests unless it's developed for an environment with unit testing capabilities, e.g. Azure Stream Analytics. With TDD, engineers start with coding the test(s), which will initially fail. The implementation of the unit is finished when the unit satisfies the tests.
 
 ### Unit tests have several goals:
 - Ensure code fulfills functional and non-functional requirements
@@ -40,7 +40,7 @@ For more complex applications, unit tests also ensure:
 - Stateful applications restore state when re-started
 
 ## Specific Guidance
-Languages and Platforms provide their own unit test tools and frameworks. In CSE, we prefer:
+Languages and Platforms provide their own unit test tools and frameworks. In [CSE](../CSE.md), we prefer:
 - .NET / Visual Studio: https://docs.microsoft.com/en-us/visualstudio/test/unit-test-your-code
 - .NET / NUnit: http://nunit.org/ 
 - .NET Core: https://docs.microsoft.com/en-us/dotnet/core/testing/

diff --git a/README.md b/README.md
@@ -1,6 +1,6 @@
-# Code-With Customer/Partner Engineering Playbook
+# CSE Code-With Customer/Partner Engineering Playbook
 
-An engineer...
+An engineer working for a [CSE](./CSE.md) project...
 
 * Has responsibilities to their team – mentor, coach, and lead
 * Knows their **playbook**. Follows their playbook.  Fixes their playbook if it is broken.  If they find a better playbook, they copy it. If somebody could use your playbook, give them yours.