Update CSE to ISE to reflect organisation changes. (microsoft#951)

* Change CSE -> ISE

* CSE -> ISE

* Fixed broken link.

* PR comment resolutions

* Removed unnecessary references to ISE

* External link is broken, cannot find the new location for it, removed.

* Updated as requested in PR.

* PR comments.

* Minor whitespace tweak to fix a broken link.

* Update .projector/workItemTemplates/engineering-fundamentals.yml

---------

Co-authored-by: Shiran Rubin <[email protected]>
Co-authored-by: Tess Ferrandez <[email protected]>

Author: 3 people

.projector/workItemTemplates/engineering-fundamentals.yml

@@ -508,7 +508,7 @@ items:
           - name:
               As a dev crew, if this engagement is considered a tented project or
               sensitive work, we have ensured that project details are not
-              tracked within CSE tooling
+              tracked within ISE tooling
             type: story
           - name:
               As a dev crew, if applicable, all crew members have acknowledged any

CONTRIBUTING.md

@@ -1,8 +1,8 @@
 # Contributing
 
-Demonstrating Engineering Fundamentals is core to what we do at CSE and is one of the primary values we bring to our customers, helping them to level up while collaborating on their business scenarios.
+Demonstrating Engineering Fundamentals is core to what we do in ISE and is one of the primary values we bring to our customers, helping them to level up while collaborating on their business scenarios.
 
-The purpose of this repo is to provide guidance to CSE Dev Crews with regards to engineering fundamentals. It describes recommended practices based on continuous project learnings in different areas. It can be used as a tool at the beginning of an engagement that can be shared with customers to help set the project up for success. This repo is *not* intended as a code repo, instead it provides guidance and links to appropriate sample code repos that represent good examples.
+The purpose of this repo is to provide guidance to ISE software engineers and data scientists (together forming a Dev Crew) with regards to engineering fundamentals. It describes recommended practices based on continuous project learnings in different areas. It can be used as a tool at the beginning of an engagement that can be shared with customers to help set the project up for success. This repo is *not* intended as a code repo, instead it provides guidance and links to appropriate sample code repos that represent good examples.
 
 This project welcomes contributions and suggestions.
 
@@ -44,7 +44,7 @@ When you submit a pull request, a CLA-bot will automatically determine whether y
 comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
 
 This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
-For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [[email protected]] (mailto:[email protected]) with any additional questions or comments.
+For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [[email protected]](mailto:[email protected]) with any additional questions or comments.
 
 ### Permissions & Contributions
 

README.md

@@ -1,6 +1,6 @@
-# CSE Code-With Customer/Partner Engineering Playbook
+# ISE Code-With Customer/Partner Engineering Playbook
 
-An engineer working for a [CSE](docs/CSE.md) project...
+An engineer or data scientist working on an [ISE](docs/ISE.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.

docs/CSE.md renamed to docs/ISE.md

@@ -1,6 +1,6 @@
 # Who We Are
 
-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 start-ups 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 "superpower" is that we work closely with both our customers’ engineering teams and Microsoft’s product engineering teams, developing real-world expertise that we can use to help our customers grow their business and help Microsoft improve our products and services.
+Our team, ISE (Industry Solutions 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 start-ups 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 "superpower" is that we work closely with both our customers’ engineering teams and Microsoft’s product engineering teams, developing real-world expertise that we can 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.
 

docs/SPRINT-STRUCTURE.md

@@ -6,7 +6,7 @@ The purpose of this document is to:
 - Provide content in a logical structure which reflects the engineering process
 - Extensible hierarchy to allow teams to share deep subject-matter expertise
 
-## The first week of a CSE Project
+## The first week of an ISE Project
 
 ### Before starting the project
 

docs/agile-development/advanced-topics/collaboration/teaming-up.md

@@ -1,13 +1,13 @@
 # Engagement Team Development
 
-In every CSE engagement, dynamics are different so are the team requirements. Based on transfer learning among teams, we aim to build right "code-with" environments in every team.
+In every ISE engagement, dynamics are different so are the team requirements. Based on transfer learning among teams, we aim to build right "code-with" environments in every team.
 
 This documentation gives a high-level template with some suggestions by aiming to accelerate team swarming phase to achieve a high speed agility however it has no intention to provide a list of "must-do" items.
 
 ## Identification
 
 As it's stated in Tuckman's [team phases](https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development), traditional team development has several stages.
-However those phases can be extremely fast or sometimes mismatched in teams due to external factors, what applies to CSE engagements.
+However those phases can be extremely fast or sometimes mismatched in teams due to external factors, what applies to ISE engagements.
 
 In order to minimize the risk and set the expectations on the right way for all parties, an identification phase is important to understand each other.
 Some potential steps in this phase may be as following (not limited):

docs/agile-development/advanced-topics/collaboration/why-collaboration.md

@@ -69,7 +69,7 @@ As soon the pair finds out that the PBI will warrant swarming, the pair brings i
 
 ## Benefits of increased collaboration
 
-Knowledge sharing and bringing CSE and customer engineers together in a ‘code-with’ manner is an important aspect of CSE engagements. This grows both our customers’ and our CSE team’s capability to build on Azure. We are responsible for demonstrating engineering fundamentals and leaving the customer in a better place after we disengage. This can only happen if we collaborate and engage together as a team. In addition to improved software quality, this also adds a beneficial social aspect to the engagements.
+Knowledge sharing and bringing ISE and customer engineers together in a ‘code-with’ manner is an important aspect of ISE engagements. This grows both our customers’ and our ISE team’s capability to build on Azure. We are responsible for demonstrating engineering fundamentals and leaving the customer in a better place after we disengage. This can only happen if we collaborate and engage together as a team. In addition to improved software quality, this also adds a beneficial social aspect to the engagements.
 
 ## Resources
 

docs/agile-development/advanced-topics/team-agreements/team-manifesto.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-CSE teams work with a new development team in each customer engagement which requires a phase of introduction & knowledge transfer before starting an engagement.
+ISE teams work with a new development team in each customer engagement which requires a phase of introduction & knowledge transfer before starting an engagement.
 
 Completion of this phase of ice-breakers and discussions about the standards takes time, but is required to start increasing the learning curve of the new team.
 
@@ -28,7 +28,7 @@ A few important points about the team manifesto
 - It aims to give a common understanding about the desired expertise, practices and/or mindset within the team
 - Based on the needs of the team and retrospective results, it can be modified during the engagement.
 
-In CSE, we aim for quality over quantity, and well-crafted software as well as to a comfortable/transparent environment where each team member can reach their highest potential.
+In ISE, we aim for quality over quantity, and well-crafted software as well as to a comfortable/transparent environment where each team member can reach their highest potential.
 
 The difference between the team manifesto and other team documents is that it is used to give a short summary of expectations around the technical way of working and supported mindset in the team, before code-with sprints starts.
 

docs/agile-development/core-expectations/README.md

@@ -1,6 +1,6 @@
 # Agile core expectations
 
-This section contains core expectations for agile practices in CSE:
+This section contains core expectations for agile practices in ISE:
 
 - It should stay concise and link to external documentation for details.
 - Each section contains a list of core expectations and suggestions:
@@ -215,7 +215,6 @@ ___
 ### Documentation
 
 - [What Is Scrum?](https://www.scrum.org/resources/what-is-scrum)
-- [10 Sprint Retrospective Ideas and Games for Your Next Sprint](https://miro.com/guides/retrospectives/ideas-games)
 - [Agile Retrospective: Making Good Teams Great](https://www.goodreads.com/book/show/721338.Agile_Retrospectives)
 - [User Stories Applied: For Software Development](https://www.goodreads.com/book/show/3856.User_Stories_Applied)
 - [Essential Scrum: A Practical Guide to The Most Popular Agile Process](https://www.goodreads.com/book/show/13663747-essential-scrum)

docs/code-reviews/README.md

@@ -1,6 +1,6 @@
 # Code Reviews
 
-Developers working on [CSE](../CSE.md) projects should conduct peer code reviews on every pull request (or check-in to a shared branch).
+Developers working on projects should conduct peer code reviews on every pull request (or check-in to a shared branch).
 
 ## Goals
 

docs/code-reviews/inclusion-in-code-review.md

@@ -3,7 +3,7 @@
 Below are some points which emphasize why inclusivity in code reviews is important:
 
 * Code reviews are an important part of our job as software professionals.
-* As CSE we work with cross cultural teams from across the globe.
+* In ISE we work with cross cultural teams from across the globe.
 * How we communicate affects team morale.
 * Inclusive code reviews welcome new developers and make them comfortable with the team.
 * Rude or personal attacks doing code reviews alienate - people can unknowingly make rude comments when reviewing pull requests (PRs).
@@ -43,7 +43,7 @@ Below are some points which emphasize why inclusivity in code reviews is importa
 
 ## Culture and Code Reviews
 
-We as CSE, may come across situations in which code reviews are not ideal and often we are observing non inclusive code review behaviors. Its important to be aware of the fact that culture and communication style of a particular geography also influences how people interact over pull requests.
+We in ISE, may come across situations in which code reviews are not ideal and often we are observing non inclusive code review behaviors. Its important to be aware of the fact that culture and communication style of a particular geography also influences how people interact over pull requests.
 In such cases, assuming positive intent of the author and reviewer is a good start to start analyzing quality of code reviews.
 
 ## Dealing with the Impostor Phenomenon

docs/code-reviews/process-guidance/author-guidance.md

@@ -9,7 +9,7 @@
 
 - Add one or more reviewers (depending on your project's guidelines) to the PR. Ideally, you would add at least someone who has expertise and is familiar with the project, or the language used
 - Adding someone less familiar with the project or the language can aid in verifying the changes are understandable, easy to read, and increases the expertise within the team
-- In CSE code-with projects with a customer team, it is important to include reviewers from both organizations for knowledge transfer - [Customize Reviewers Policy](../tools.md#reviewer-policies)
+- In ISE code-with projects with a customer team, it is important to include reviewers from both organizations for knowledge transfer - [Customize Reviewers Policy](../tools.md#reviewer-policies)
 
 ## Be open to receive feedback
 

docs/code-reviews/recipes/azure-pipelines-yaml.md

@@ -2,7 +2,7 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers follow the [YAML schema reference](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema).
+Developers should follow the [YAML schema reference](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema).
 
 ## Code Analysis / Linting
 

docs/code-reviews/recipes/bash.md

@@ -2,11 +2,11 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers follow [Google's Bash Style Guide](https://google.github.io/styleguide/shell.xml).
+Developers should follow [Google's Bash Style Guide](https://google.github.io/styleguide/shell.xml).
 
 ## Code Analysis / Linting
 
-[CSE](../../CSE.md) projects must check bash code with [shellcheck](https://github.com/koalaman/shellcheck) as part of the [CI process](../../continuous-integration/README.md).
+Projects must check bash code with [shellcheck](https://github.com/koalaman/shellcheck) as part of the [CI process](../../continuous-integration/README.md).
 Apart from linting, [shfmt](https://github.com/mvdan/sh) can be used to automatically format shell scripts. There are few vscode code extensions which are based on shfmt like shell-format which can be used to automatically format shell scripts.
 
 ## Project Setup

docs/code-reviews/recipes/csharp.md

@@ -2,7 +2,7 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers follow Microsoft's [C# Coding Conventions](https://learn.microsoft.com/dotnet/csharp/fundamentals/coding-style/coding-conventions) and, where applicable, Microsoft's [Secure Coding Guidelines](https://learn.microsoft.com/dotnet/standard/security/secure-coding-guidelines).
+Developers should follow Microsoft's [C# Coding Conventions](https://learn.microsoft.com/dotnet/csharp/fundamentals/coding-style/coding-conventions) and, where applicable, Microsoft's [Secure Coding Guidelines](https://learn.microsoft.com/dotnet/standard/security/secure-coding-guidelines).
 
 ## Code Analysis / Linting
 

docs/code-reviews/recipes/go.md

@@ -2,7 +2,7 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers follow the [Effective Go](https://golang.org/doc/effective_go.html) Style Guide.
+Developers should follow the [Effective Go](https://golang.org/doc/effective_go.html) Style Guide.
 
 ## Code Analysis / Linting
 
@@ -16,7 +16,7 @@ Using the Go extension for Visual Studio Code, you get language features like In
 
 #### 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](../../CSE.md) Go code should be able to build with no `go vet` errors. This will be part of vscode-go extension.
+`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. Go code should be able to build with no `go vet` errors. This will be part of vscode-go extension.
 
 #### golint
 
@@ -157,7 +157,7 @@ steps:
 
 ## Code Review Checklist
 
-The Go language team maintains a list of common [Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) for go that form the basis for a solid checklist for a team working in Go that should be followed in addition to the [CSE Code Review Checklist](../process-guidance/reviewer-guidance.md)
+The Go language team maintains a list of common [Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) for go that form the basis for a solid checklist for a team working in Go that should be followed in addition to the [ISE Code Review Checklist](../process-guidance/reviewer-guidance.md)
 
 * [ ] Does this code [handle errors](https://golang.org/doc/effective_go.html#errors) correctly? This includes not throwing away errors with `_` assignments and returning errors, instead of [in-band error values](https://github.com/golang/go/wiki/CodeReviewComments#in-band-errors)?
 * [ ] Does this code follow Go standards for method [receiver types](https://github.com/golang/go/wiki/CodeReviewComments#receiver-type)?

docs/code-reviews/recipes/java.md

@@ -2,7 +2,7 @@
 
 ## Java Style Guide
 
-[CSE](../../CSE.md) developers generally follow the [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html).
+Developers should follow the [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html).
 
 ## Code Analysis / Linting
 

docs/code-reviews/recipes/javascript-and-typescript.md

@@ -2,7 +2,7 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers use [prettier](https://prettier.io/) to do code formatting for JavaScript.
+Dvelopers should use [prettier](https://prettier.io/) to do code formatting for JavaScript.
 
 Using an automated code formatting tool like Prettier enforces a well accepted style guide that was collaboratively built by a wide range of companies including Microsoft, Facebook, and AirBnB.
 

docs/code-reviews/recipes/markdown.md

@@ -2,7 +2,7 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers treat documentation like other source code and follow the same rules and checklists when reviewing documentation as code.
+Developers should treat documentation like other source code and follow the same rules and checklists when reviewing documentation as code.
 
 Documentation should both use good Markdown syntax to ensure it's properly parsed, and follow good [writing style guidelines](#writing-style-guidelines) to ensure the document is easy to read and understand.
 

docs/code-reviews/recipes/python.md

@@ -2,9 +2,9 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers follow the [PEP8 style guide](https://pep8.org/) with [type hints](https://www.python.org/dev/peps/pep-0484/). The use of type hints throughout paired with linting and type hint checking avoids common errors that are tricky to debug.
+Developers should follow the [PEP8 style guide](https://pep8.org/) with [type hints](https://www.python.org/dev/peps/pep-0484/). The use of type hints throughout paired with linting and type hint checking avoids common errors that are tricky to debug.
 
-[CSE](../../CSE.md) projects should check Python code with automated tools.
+Projects should check Python code with automated tools.
 
 Linting should be added to build validation, and both linting and code formatting can be added to your pre-commit hooks and VS Code.
 

docs/code-reviews/recipes/terraform.md

@@ -2,9 +2,9 @@
 
 ## Style Guide
 
-[CSE](../../CSE.md) developers follow the [terraform style guide](https://github.com/jonbrouse/terraform-style-guide/blob/master/README.md).
+Developers should follow the [terraform style guide](https://github.com/jonbrouse/terraform-style-guide/blob/master/README.md).
 
-[CSE](../../CSE.md) projects should check Terraform scripts with automated tools.
+Projects should check Terraform scripts with automated tools.
 
 ## Code Analysis / Linting
 

docs/design/design-reviews/README.md

@@ -53,14 +53,14 @@ There is also a healthy balancing act in supporting a healthy debate while not h
 
 The dev crew should always participate in all design review sessions
 
-- [CSE](../../CSE.md) Engineering
+- [ISE](../../ISE.md) Engineering
 - Customer Engineering
 
 ### Domain Experts
 
 Domain experts should participate in design review sessions as needed
 
-- CSE Tech Domain
+- ISE Tech Domains
 - Customer subject-matter experts (SME)
 - Senior Leadership