From bb587c5d0990567395e845db062fa7ea27b436b1 Mon Sep 17 00:00:00 2001 From: christianbraeunlich Date: Thu, 17 Mar 2022 21:44:33 +0100 Subject: [PATCH 1/3] change wit to with --- content/docs/BestPractices/api-page/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/BestPractices/api-page/index.md b/content/docs/BestPractices/api-page/index.md index b2d38d46..b541fe10 100644 --- a/content/docs/BestPractices/api-page/index.md +++ b/content/docs/BestPractices/api-page/index.md @@ -166,7 +166,7 @@ It is common use to give certain fields a more describing name. Some examples ar These fields should always be part of the API Page: * SystemId - * This field should be exposed wit the name ```id``` + * This field should be exposed with the name ```id``` * SystemModifiedAt * This field should be exposed with the name ```lastModifiedDateTime```. If you choose a different name, then the webhook functionality will not work properly. From 42358aab34506f91a1a582624fd713ff550f81a5 Mon Sep 17 00:00:00 2001 From: christianbraeunlich Date: Thu, 17 Mar 2022 21:44:50 +0100 Subject: [PATCH 2/3] added period at the end --- content/docs/BestPractices/CustomTelemetry/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/BestPractices/CustomTelemetry/index.md b/content/docs/BestPractices/CustomTelemetry/index.md index 9f8b7ba0..02fc2d19 100644 --- a/content/docs/BestPractices/CustomTelemetry/index.md +++ b/content/docs/BestPractices/CustomTelemetry/index.md @@ -71,7 +71,7 @@ Of course it is possible to have a single object as a central place to emit tele ## Candidate data for telemetry -Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on (knowing about CPU performance counters on the database is useless if the partner cannot scale the database) +Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on period (knowing about CPU performance counters on the database is useless if the partner cannot scale the database). Also, note that customers pay for data ingestion. So be mindful to not flood their telemetry resources. Consider to use TelemetryScope::ExtensionPublisher by default and only use TelemetryScope::All in case the customer can also act on the data. From 417cc2f0253340e011fda08b22538f0e4fb106d1 Mon Sep 17 00:00:00 2001 From: Henrik Helgesen Date: Thu, 24 Mar 2022 14:50:26 -0700 Subject: [PATCH 3/3] Update content/docs/BestPractices/CustomTelemetry/index.md Removed the word period --- content/docs/BestPractices/CustomTelemetry/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/BestPractices/CustomTelemetry/index.md b/content/docs/BestPractices/CustomTelemetry/index.md index 02fc2d19..c2f1eb20 100644 --- a/content/docs/BestPractices/CustomTelemetry/index.md +++ b/content/docs/BestPractices/CustomTelemetry/index.md @@ -71,7 +71,7 @@ Of course it is possible to have a single object as a central place to emit tele ## Candidate data for telemetry -Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on period (knowing about CPU performance counters on the database is useless if the partner cannot scale the database). +Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on (knowing about CPU performance counters on the database is useless if the partner cannot scale the database). Also, note that customers pay for data ingestion. So be mindful to not flood their telemetry resources. Consider to use TelemetryScope::ExtensionPublisher by default and only use TelemetryScope::All in case the customer can also act on the data.