Upmerge/6 16 (#1570)

* Supported Release Info and Upgrade Path for v1.2 (#1494)

* Supported Release Info and Upgrade Path for v1.2

* Update support-release-policy.md

* Update daprdocs/content/en/operations/support/support-release-policy.md

Co-authored-by: Aaron Crawfis <[email protected]>

* Adding K8s versions table (#1521)

* Adding table of kubernetes versions

* Updating intro

* Fix incorrect postgresql connection string example (#1524)

Co-authored-by: Aaron Crawfis <[email protected]>

* Update docs on using Codespaces with Dapr repos (#1522)

* Update docs on using Codespaces with Dapr repos

* Move codespaces.md under the Contributing topic

* Update daprdocs/content/en/contributing/codespaces.md

Co-authored-by: Aaron Crawfis <[email protected]>

* Fix two typos (#1526)

Co-authored-by: Aaron Crawfis <[email protected]>

* Update chinese content (#1527)

Co-authored-by: Aaron Crawfis <[email protected]>

* Updated to fix deprecated helm chart location (#1528)

The `https://kubernetes-charts.storage.googleapis.com/` location is no longer used, so this change updates this, the command to install, and the missing update step that will cause the install to fail if an update was never done after adding the location.

Co-authored-by: Aaron Crawfis <[email protected]>

* nr_consul_typo fixed malformed yaml (#1532)

Co-authored-by: Aaron Crawfis <[email protected]>

* Fix typo in azure-keyvault-managed-identity.md (#1541)

* Fix custom middleware sample code interface implementation error (#1539)

Fix custom middleware sample code interface implementation error, interface function declare error.

Co-authored-by: Aaron Crawfis <[email protected]>

* Fix the file name of secrets json (#1546)

* Tech writing touch-ups (#1555)

* Tech writing touch-ups (#1556)

Co-authored-by: Aaron Crawfis <[email protected]>

* Tech writing touch-ups (#1557)

Co-authored-by: Aaron Crawfis <[email protected]>

* Tech writing touch-ups (#1558)

Co-authored-by: Aaron Crawfis <[email protected]>

* Tech writing touch-ups (#1560)

Co-authored-by: Aaron Crawfis <[email protected]>

* Tech writing touch-ups (#1559)

Co-authored-by: Aaron Crawfis <[email protected]>

* Ignore intellij link that isn't resolvable (#1564)

* Update issue templates (#1563)

* Update issue templates

* Add needs-triage

* Updating PubSub documentation to remove slave wording (#1565)

* Updating PubSub documentation to remove slave

Bitnami has updated their Redis Helm chart to change redis-slave to redis-replicas. I am updating the documentation for PubSub to reflect this change and avoid confusion for any readers.

* Removing more instances of Redis slave naming

Co-authored-by: Aaron Crawfis <[email protected]>

* Actor Runtime Configuration Docs (#1495)

* Actor Runtime Configuration Docs

Addresses #1470

* Update daprdocs/content/en/developing-applications/building-blocks/actors/howto-actors.md

Co-authored-by: Aaron Crawfis <[email protected]>

* Update daprdocs/content/en/developing-applications/building-blocks/actors/howto-actors.md

Co-authored-by: Aaron Crawfis <[email protected]>

* add configuration examples

* configuration examples

* Fix syntax

* Add dotnet sample

* Update daprdocs/content/en/developing-applications/building-blocks/actors/howto-actors.md

Co-authored-by: Aaron Crawfis <[email protected]>

Co-authored-by: Bernd Verst <[email protected]>
Co-authored-by: Mark Fussell <[email protected]>
Co-authored-by: Zonciu Liang <[email protected]>
Co-authored-by: Simon Leet <[email protected]>
Co-authored-by: Maarten Mulders <[email protected]>
Co-authored-by: Newbe36524 <[email protected]>
Co-authored-by: Steven Jenkins De Haro <[email protected]>
Co-authored-by: Abdulaziz Elsheikh <[email protected]>
Co-authored-by: Antonio Fiumanò <[email protected]>
Co-authored-by: li1234yun <[email protected]>
Co-authored-by: greenie-msft <[email protected]>
Co-authored-by: voipengineer <[email protected]>
Co-authored-by: Evan Simkowitz <[email protected]>

.github/ISSUE_TEMPLATE/new-content-needed.md

@@ -1,8 +1,8 @@
 ---
 name: New Content Needed
 about: Topic is missing and needs to be written
-title: "[CONTENT]"
-labels: content/missing-information
+title: ''
+labels: needs-triage,content/missing-information
 assignees: ''
 
 ---
@@ -16,5 +16,12 @@ assignees: ''
 **Where should the new material be placed?**
 <!--Please suggest where in the docs structure the new content should be created-->
 
+**The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos**
+<!--
+Specify the URL to the associated pull request, if applicable
+
+For example: https://github.com/dapr/dapr/pull/3277
+-->
+
 **Additional context**
 <!--Add any other context or screenshots about the feature request here-->

.github/ISSUE_TEMPLATE/typo.md

@@ -1,8 +1,8 @@
 ---
 name: Typo
 about: Report incorrect language/small updates to fix readability
-title: "[TYPO]"
-labels: content/typo
+title: ''
+labels: needs-triage,content/typo
 assignees: ''
 
 ---

.github/ISSUE_TEMPLATE/website-issue.md

@@ -1,8 +1,8 @@
 ---
 name: Website Issue
 about: The website is broken or not working correctly.
-title: "[WEBSITE]"
-labels: website/functionality
+title: ''
+labels: needs-triage,website/functionality
 assignees: AaronCrawfis
 
 ---

.github/ISSUE_TEMPLATE/wrong-information-code-steps.md

@@ -1,8 +1,8 @@
 ---
 name: Wrong Information/Code/Steps
 about: Something in the docs is incorrect
-title: "[CONTENT]"
-labels: P1, content/incorrect-information
+title: ''
+labels: needs-triage,content/incorrect-information
 assignees: ''
 
 ---

daprdocs/content/en/concepts/faq.md

@@ -7,7 +7,7 @@ description: "Common questions asked about Dapr"
 ---
 
 ## How does Dapr compare to service meshes such as Istio, Linkerd or OSM?
-Dapr is not a service mesh. While service meshes focus on fine grained network control, Dapr is focused on helping developers build distributed applications. Both Dapr and service meshes use the sidecar pattern and run alongside the application and they do have some overlapping features but also offer unique benefits. For more information please read the [Dapr & service meshes]({{<ref service-mesh>}}) concept page.
+Dapr is not a service mesh. While service meshes focus on fine-grained network control, Dapr is focused on helping developers build distributed applications. Both Dapr and service meshes use the sidecar pattern and run alongside the application. They do have some overlapping features, but also offer unique benefits. For more information please read the [Dapr & service meshes]({{<ref service-mesh>}}) concept page.
 
 ## Performance Benchmarks
 The Dapr project is focused on performance due to the inherent discussion of Dapr being a sidecar to your application. See [here]({{< ref perf-service-invocation.md >}}) for updated performance numbers.
@@ -16,26 +16,24 @@ The Dapr project is focused on performance due to the inherent discussion of Dap
 
 ### What is the relationship between Dapr, Orleans and Service Fabric Reliable Actors?
 
-The actors in Dapr are based on the same virtual actor concept that [Orleans](https://www.microsoft.com/research/project/orleans-virtual-actors/) started, meaning that they are activated when called and deactivated after a period of time. If you are familiar with Orleans, Dapr C# actors will be familiar. Dapr C# actors are based on [Service Fabric Reliable Actors](https://docs.microsoft.com/azure/service-fabric/service-fabric-reliable-actors-introduction) (which also came from Orleans) and enable you to take Reliable Actors in Service Fabric and migrate them to other hosting platforms such as Kubernetes or other on-premise environments.
-Also Dapr is about more than just actors. It provides you with a set of best practice building blocks to build into any microservices application. See [Dapr overview]({{< ref overview.md >}}).
+The actors in Dapr are based on the same virtual actor concept that [Orleans](https://www.microsoft.com/research/project/orleans-virtual-actors/) started, meaning that they are activated when called and deactivated after a period of time. If you are familiar with Orleans, Dapr C# actors will be familiar. Dapr C# actors are based on [Service Fabric Reliable Actors](https://docs.microsoft.com/azure/service-fabric/service-fabric-reliable-actors-introduction) (which also came from Orleans) and enable you to take Reliable Actors in Service Fabric and migrate them to other hosting platforms such as Kubernetes or other on-premisis environments.
+Moreover, Dapr is about more than just actors. It provides you with a set of best-practice building blocks to build into any microservices application. See [Dapr overview]({{< ref overview.md >}}).
 
-### Differences between Dapr from an actor framework
+### Differences between Dapr and an actor framework
 
-Virtual actors capabilities are one of the building blocks that Dapr provides in its runtime. With Dapr because it is programming language agnostic with an http/gRPC API, the actors can be called from any language. This allows actors written in one language to invoke actors written in a different language.
+Virtual actor capabilities are one of the building blocks that Dapr provides in its runtime. With Dapr, because it is programming-language agnostic with an http/gRPC API, the actors can be called from any language. This allows actors written in one language to invoke actors written in a different language.
 
-Creating a new actor follows a local call like `http://localhost:3500/v1.0/actors/<actorType>/<actorId>/…`, for example `http://localhost:3500/v1.0/actors/myactor/50/method/getData` to call the `getData` method on the newly created `myactor` with id `50`.
+Creating a new actor follows a local call like `http://localhost:3500/v1.0/actors/<actorType>/<actorId>/…`. For example, `http://localhost:3500/v1.0/actors/myactor/50/method/getData` calls the `getData` method on the newly created `myactor` with id `50`.
 
-The Dapr runtime SDKs have language specific actor frameworks. The .NET SDK for example has C# actors. The goal is for all the Dapr language SDKs to have an actor framework. Currently .NET, Java and Python SDK have actor frameworks.
+The Dapr runtime SDKs have language-specific actor frameworks. For example, the .NET SDK has C# actors. The goal is for all the Dapr language SDKs to have an actor framework. Currently .NET, Java and Python SDK have actor frameworks.
 
 ## Developer language SDKs and frameworks
 
-### Does Dapr have any SDKs if I want to work with a particular programming language or framework?
+### Does Dapr have any SDKs I can use if I want to work with a particular programming language or framework?
 
-To make using Dapr more natural for different languages, it includes [language specific SDKs]({{<ref sdks>}}) for Go, Java, JavaScript, .NET,  Python, PHP, Rust and C++.
+To make using Dapr more natural for different languages, it includes [language specific SDKs]({{<ref sdks>}}) for Go, Java, JavaScript, .NET,  Python, PHP, Rust and C++. These SDKs expose the functionality in the Dapr building blocks, such as saving state, publishing an event or creating an actor, through a typed language API rather than calling the http/gRPC API. This enables you to write a combination of stateless and stateful functions and actors all in the language of your choice. And because these SDKs share the Dapr runtime, you get cross-language actor and functions support.
 
-These SDKs expose the functionality in the Dapr building blocks, such as saving state, publishing an event or creating an actor, through a typed, language API rather than calling the http/gRPC API. This enables you to write a combination of stateless and stateful functions and actors all in the language of their choice. And because these SDKs share the Dapr runtime, you get cross-language actor and functions support.
-
-### What frameworks does Dapr integrated with?
+### What frameworks does Dapr integrate with?
 Dapr can be integrated with any developer framework. For example, in the Dapr .NET SDK you can find ASP.NET Core integration, which brings stateful routing controllers that respond to pub/sub events from other services.
 
 Dapr is integrated with the following frameworks;

daprdocs/content/en/concepts/observability-concept.md

@@ -7,14 +7,14 @@ description: >
   Monitor applications through tracing, metrics, logs and health
 ---
 
-When building an applications, understanding how the system is behaving is an important part of operating it - this includes having the ability to observe the internal calls of an application, gauging its performance and becoming aware of problems as soon as they occur. This is challenging for any system but even more so for a distributed system comprised of multiple microservices where a flow, made of several calls, may start in one microservices but continue in another. Observability is critical in production environments but also useful during development to understand bottlenecks, improve performance and perform basic debugging across the span of microservices.
+When building an application, understanding how the system is behaving is an important part of operating it - this includes having the ability to observe the internal calls of an application, gauging its performance and becoming aware of problems as soon as they occur. This is challenging for any system, but even more so for a distributed system comprised of multiple microservices where a flow, made of several calls, may start in one microservices but continue in another. Observability is critical in production environments, but also useful during development to understand bottlenecks, improve performance and perform basic debugging across the span of microservices.
 
-While some data points about an application can be gathered from the underlying infrastructure (e.g. memory consumption, CPU usage), other meaningful information must be collected from an "application aware" layer - one that can show how an important series of calls is executed across microservices. This usually means a developer must add some code to instrument an application for this purpose. Often, instrumentation code is simply meant to send collected data such as traces and metrics to an external monitoring tool or service that can help store, visualize and analyze all this information.
+While some data points about an application can be gathered from the underlying infrastructure (e.g. memory consumption, CPU usage), other meaningful information must be collected from an "application-aware" layer - one that can show how an important series of calls is executed across microservices. This usually means a developer must add some code to instrument an application for this purpose. Often, instrumentation code is simply meant to send collected data such as traces and metrics to an external monitoring tool or service that can help store, visualize and analyze all this information.
 
-Having to maintain this code, which is not part of the core logic of the application, is another burden on the developer, sometimes requiring understanding monitoring tools APIs, using additional SDKs etc. This instrumentation may also add to the portability challenges of an application which may require different instrumentation depending on where the application is deployed. For example, different cloud providers offer different monitoring solutions and an on-prem deployment might require an on-prem solution.
+Having to maintain this code, which is not part of the core logic of the application, is another burden on the developer, sometimes requiring understanding the monitoring tools' APIs, using additional SDKs etc. This instrumentation may also add to the portability challenges of an application, which may require different instrumentation depending on where the application is deployed. For example, different cloud providers offer different monitoring solutions and an on-prem deployment might require an on-prem solution.
 
 ## Observability for your application with Dapr
-When building an application which is leveraging Dapr building blocks to perform service-to-service calls and pub/sub messaging, Dapr offers an advantage in respect to [distributed tracing]({{<ref tracing>}}) because this inter-service communication flows through the Dapr sidecar, the sidecar is in a unique position to offload the burden of application level instrumentation.
+When building an application which leverages Dapr building blocks to perform service-to-service calls and pub/sub messaging, Dapr offers an advantage with respect to [distributed tracing]({{<ref tracing>}}). Because this inter-service communication flows through the Dapr sidecar, the sidecar is in a unique position to offload the burden of application-level instrumentation.
 
 ### Distributed tracing
 Dapr can be [configured to emit tracing data]({{<ref setup-tracing.md>}}), and because Dapr does so using widely adopted protocols such as the [Zipkin](https://zipkin.io) protocol, it can be easily integrated with multiple [monitoring backends]({{<ref supported-tracing-backends>}}).
@@ -27,18 +27,18 @@ Dapr can also be configured to work with the [OpenTelemetry Collector]({{<ref op
 <img src="/images/observability-opentelemetry-collector.png" width=1000 alt="Distributed tracing via OpenTelemetry collector">
 
 ### Tracing context
-Dapr uses [W3C tracing]({{<ref w3c-tracing>}}) specification for tracing context and can generate and propagate the context header itself or propagate user provided context headers.
+Dapr uses [W3C tracing]({{<ref w3c-tracing>}}) specification for tracing context and can generate and propagate the context header itself or propagate user-provided context headers.
 
 ## Observability for the Dapr sidecar and system services
-As for other parts of your system, you will want to be able to observe Dapr itself and collect metrics and logs emitted by the Dapr sidecar that runs along each microservice as well as the Dapr related services in your environment such as the control plane services that are deployed for a Dapr enabled Kubernetes cluster.
+As for other parts of your system, you will want to be able to observe Dapr itself and collect metrics and logs emitted by the Dapr sidecar that runs along each microservice, as well as the Dapr-related services in your environment such as the control plane services that are deployed for a Dapr-enabled Kubernetes cluster.
 
 <img src="/images/observability-sidecar.png" width=1000 alt="Dapr sidecar metrics, logs and health checks">
 
 ### Logging
 Dapr generates [logs]({{<ref "logs.md">}}) to provide visibility into sidecar operation and to help users identify issues and perform debugging. Log events contain warning, error, info, and debug messages produced by Dapr system services. Dapr can also be configured to send logs to collectors such as [Fluentd]({{< ref fluentd.md >}}) and [Azure Monitor]({{< ref azure-monitor.md >}}) so they can be easily searched, analyzed and provide insights.
 
 ### Metrics
-Metrics are the series of measured values and counts that are collected and stored over time. [Dapr metrics]({{<ref "metrics">}}) provide monitoring capabilities to understand the behavior of the Dapr sidecar and system services. For example, the metrics between a Dapr sidecar and the user application show call latency, traffic failures, error rates of requests etc. Dapr [system services metrics](https://github.com/dapr/dapr/blob/master/docs/development/dapr-metrics.md) show sidecar injection failures, health of the system services including CPU usage, number of actor placements made etc.
+Metrics are the series of measured values and counts that are collected and stored over time. [Dapr metrics]({{<ref "metrics">}}) provide monitoring capabilities to understand the behavior of the Dapr sidecar and system services. For example, the metrics between a Dapr sidecar and the user application show call latency, traffic failures, error rates of requests, etc. Dapr [system services metrics](https://github.com/dapr/dapr/blob/master/docs/development/dapr-metrics.md) show sidecar injection failures and the health of system services, including CPU usage, number of actor placements made, etc.
 
 ### Health checks
 The Dapr sidecar exposes an HTTP endpoint for [health checks]({{<ref sidecar-health.md>}}). With this API, user code or hosting environments can probe the Dapr sidecar to determine its status and identify issues with sidecar readiness.