From bebde4f3523283a558cf464d323f3debf3ecb7a1 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 5 Apr 2024 17:32:52 -0400 Subject: [PATCH 01/18] Add draft feature flag project proposal --- projects/feature-flag.md | 106 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 projects/feature-flag.md diff --git a/projects/feature-flag.md b/projects/feature-flag.md new file mode 100644 index 00000000..316a4586 --- /dev/null +++ b/projects/feature-flag.md @@ -0,0 +1,106 @@ +# Feature Flag Semantic Conventions + +OpenFeature is a CNCF Incubating project aiming to standardize feature flags. +They currently provide 11 open source SDKs in various languages and support more than 10 feature flagging backends. +OpenFeature has had contributions from over 50 companies and is actively developed by a combination of end users, feature flagging vendors, and platform providers. + +OpenFeature provides observability data via OpenTelemetry hooks. +A hook is an OpenFeature plugin which may execute logic at various stages of the feature flag evaluation process. +Currently, those hooks use the experimental feature flagging semantic convention. + +OpenFeature is looking to expand their observability solution either by improving the currently available hooks or by providing native instrumentation within the OpenFeature SDK itself. +In order to support that effort, OpenFeature requires a stable semantic convention to build instrumentation around. +This project aims to develop and stabilize feature flag semantic conventions, using the existing experimental semantic conventions as a starting point. + +## Problem 1: Determining Flag Impact + +Currently, it is impossible to determine the impact a feature flag has on key metrics for your services. +For example, if a feature flag is enabled for 25% of users, additional data is required to know if that subset of users is experiencing faster, slower, or unchanged response times. +This problem can become exponentially more challenging if multiple feature flags are evaluated over the course of a single transaction. + +Further, it may also be difficult or impossible to know exactly how many users are being affected by a particular feature flag. +For example, if a feature flag targets users with a particular email domain, it may require additional monitoring data to determine what portion of your users or traffic is receiving a particular experience. + +## Problem 2: Flag management separate from monitoring data + +Feature flags are typically managed outside your monitoring tooling. +There is no standardized way for a flag management system to notify a monitoring system that a feature flag ruleset is changed, or if a rule is enabled or disabled. +This lack of standardization means that even if a flag management system emits a flag change event, the monitoring tool may not be able to correlate that change with the services that it impacts. +It also means that a person responsible for monitoring an application often has to check two separate tools in order to determine if a flag change was the root cause of a change in service metrics or behavior. +Because rulesets and monitoring data are managed in separate tools, it may be difficult to determine exactly which ruleset was used and if it has been changed between when it was evaluated and when a person investigating an issue is looking at the monitoring data. + +## Target Use Cases + +- Analyze the impact a feature flag has on key service metrics such as response time and failure rate. + If a feature variant is enabled for some subset of users, it is necessary to be able to distinguish those transactions from other transactions in your monitoring backend. +- Associating a flag change with a change in key service metrics. + This is useful additional context during root cause analysis. + One example of when this is useful may be determining the ruleset that was evaluated in order to determine the flag variant. +- Determine how many users are experiencing a particular flag variant. + In many feature flagging services it is possible to target a flag variant by some attribute of context such as the user’s email domain, however it may be difficult or impossible to know what percentage of your traffic falls into the cohort. +- Determining why a particular flag evaluation returned the variant that it did. + For example, a ruleset may depend on contextual info such as the currently logged in user, their user-agent, or their geographic location in order to determine the flag variant. +- Identify which services are evaluating a specific feature flag. + This is useful for the process of removing flags from your code and feature flagging service, an important part of the flag lifecycle. +- Analyzing the impact of the actual flag evaluation. + Some feature flag libraries and services do async work such as database or remote calls to decide which variant of a feature flag should be returned. + +## Deliverables + +The project deliverable will be a stable feature flag semantic convention for flag evaluations, also called impressions, and feature flag changes. +Both client and server uses should be considered, and prototypes should be created for at least one server and at least one client use case. + +While prototypes will be delivered as a part of the development effort of this project, stable instrumentation is out of scope of this project and is expected to come from the OpenFeature project in the form of OpenFeature hooks or native instrumentation in OpenFeature SDKs. +Any use of baggage, including propagating fields to be used in feature flag evaluation context, is also out of scope. + +## Staffing + +The project is expected to be mainly staffed by OpenFeature contributors representing a strong subsection of the feature flagging vendor and user community. +This group will provide the domain expertise to ensure the feature flag observability meets the requirements of feature flag vendors and users. + +This project also includes @dyladan acting as one of the project leads. +@dyladan is a member of the GC, maintainer of OTel JS, and has experience developing semantic conventions. +@dyladan will provide the necessary expertise to ensure the proposed semantic conventions meet the standards and expectations of the OpenTelemetry community and semantic conventions SIG. + +TODO: list engineers committed to working on the project + +### Required staffing + +**Project Leads:** Daniel Dyla and Michael Beemer (OpenFeature founder/GC member) + +**Engineers willing to write and review prototypes:** + +TODO: list prototype languages and engineers + +- JS - Daniel Dyla (Maintainer) + +## Meeting Times + +This project expects to meet every 2 weeks until this charter is fulfilled. +The exact time and date of the meeting will be determined after the project is approved. + +## Timeline + +We expect the project to take about 1 calendar quarter. The OpenFeature project is currently targeting Kubecon NA 2024 to announce stable OpenTelemetry support. + +- 2-4 weeks - First experimental semantic convention built on pre-exising feature flag semantic conventions +- 2-4 weeks - Prototype implementation and review +- 2-4 weeks - Incorporate feedback from prototype implementers +- 2-4 weeks - Final review period including the greater spec and maintainer community + +## Labels + +This project will use the label [`area:feature-flag`](https://github.com/open-telemetry/semantic-conventions/labels/area%3Afeature-flag) to track issues and pull requests in the semantic conventions repository. + +## Project Board + +Once the project is approved a project board will be created and linked here. +The project lead and all other relevant project members should have edit access to the board. +The board will be pre-populated with at least the following issues to track deliverables and the timeline. + +- **signal type for feature flag impressions** - agree on which signal type or types should be used to represent feature flag impressions. +- **signal type for feature flag changes** - agree on which signal type or types should be used to represent feature flag changes. +- **semantic conventions for feature flag impressions** - make any necessary additions to the semantic conventions to support feature flag impressions +- **semantic conventions for feature flag changes** - make any necessary additions to the semantic conventions to support feature flag change events +- **prototype feature flag impressions** +- **prototype feature flag change events** - feature flag change events may not be generated by SDKs or instrumentations, but by the feature flag management tools. From 848a7ca2d4328d4adccab3dccdf4d8cf24a5cc83 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 5 Apr 2024 17:44:48 -0400 Subject: [PATCH 02/18] Git handles don't work in markdown --- projects/feature-flag.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 316a4586..7c13f59f 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -58,9 +58,9 @@ Any use of baggage, including propagating fields to be used in feature flag eval The project is expected to be mainly staffed by OpenFeature contributors representing a strong subsection of the feature flagging vendor and user community. This group will provide the domain expertise to ensure the feature flag observability meets the requirements of feature flag vendors and users. -This project also includes @dyladan acting as one of the project leads. -@dyladan is a member of the GC, maintainer of OTel JS, and has experience developing semantic conventions. -@dyladan will provide the necessary expertise to ensure the proposed semantic conventions meet the standards and expectations of the OpenTelemetry community and semantic conventions SIG. +This project also includes Dan Dyla acting as one of the project leads. +Dan is a member of the GC, maintainer of OTel JS, and has experience developing semantic conventions. +Dan will provide the necessary expertise to ensure the proposed semantic conventions meet the standards and expectations of the OpenTelemetry community and semantic conventions SIG. TODO: list engineers committed to working on the project From 68784590afa1b6491521da7ff72bfde7e2d1f11e Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 5 Apr 2024 17:48:54 -0400 Subject: [PATCH 03/18] Mike is a co-founder of openfeature --- projects/feature-flag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 7c13f59f..607719e4 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -66,7 +66,7 @@ TODO: list engineers committed to working on the project ### Required staffing -**Project Leads:** Daniel Dyla and Michael Beemer (OpenFeature founder/GC member) +**Project Leads:** Daniel Dyla and Michael Beemer (OpenFeature co-founder/GC member) **Engineers willing to write and review prototypes:** From b9f24fd8831d4c954a110cb7ef69ac0cb3ee4ce6 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 5 Apr 2024 17:57:45 -0400 Subject: [PATCH 04/18] Spell check --- .cspell.yaml | 1 + projects/feature-flag.md | 10 +++++----- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/.cspell.yaml b/.cspell.yaml index 38bfb91d..0c304d1e 100644 --- a/.cspell.yaml +++ b/.cspell.yaml @@ -69,6 +69,7 @@ words: - arminru - austinlparker - beedgen + - beemer - blanco - bogdan - bogdandrutu diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 607719e4..f67ed808 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -24,10 +24,10 @@ For example, if a feature flag targets users with a particular email domain, it ## Problem 2: Flag management separate from monitoring data Feature flags are typically managed outside your monitoring tooling. -There is no standardized way for a flag management system to notify a monitoring system that a feature flag ruleset is changed, or if a rule is enabled or disabled. +There is no standardized way for a flag management system to notify a monitoring system that a feature flag rule set is changed, or if a rule is enabled or disabled. This lack of standardization means that even if a flag management system emits a flag change event, the monitoring tool may not be able to correlate that change with the services that it impacts. It also means that a person responsible for monitoring an application often has to check two separate tools in order to determine if a flag change was the root cause of a change in service metrics or behavior. -Because rulesets and monitoring data are managed in separate tools, it may be difficult to determine exactly which ruleset was used and if it has been changed between when it was evaluated and when a person investigating an issue is looking at the monitoring data. +Because rule sets and monitoring data are managed in separate tools, it may be difficult to determine exactly which rule set was used and if it has been changed between when it was evaluated and when a person investigating an issue is looking at the monitoring data. ## Target Use Cases @@ -35,11 +35,11 @@ Because rulesets and monitoring data are managed in separate tools, it may be di If a feature variant is enabled for some subset of users, it is necessary to be able to distinguish those transactions from other transactions in your monitoring backend. - Associating a flag change with a change in key service metrics. This is useful additional context during root cause analysis. - One example of when this is useful may be determining the ruleset that was evaluated in order to determine the flag variant. + One example of when this is useful may be determining the rule set that was evaluated in order to determine the flag variant. - Determine how many users are experiencing a particular flag variant. In many feature flagging services it is possible to target a flag variant by some attribute of context such as the user’s email domain, however it may be difficult or impossible to know what percentage of your traffic falls into the cohort. - Determining why a particular flag evaluation returned the variant that it did. - For example, a ruleset may depend on contextual info such as the currently logged in user, their user-agent, or their geographic location in order to determine the flag variant. + For example, a rule set may depend on contextual info such as the currently logged in user, their user-agent, or their geographic location in order to determine the flag variant. - Identify which services are evaluating a specific feature flag. This is useful for the process of removing flags from your code and feature flagging service, an important part of the flag lifecycle. - Analyzing the impact of the actual flag evaluation. @@ -83,7 +83,7 @@ The exact time and date of the meeting will be determined after the project is a We expect the project to take about 1 calendar quarter. The OpenFeature project is currently targeting Kubecon NA 2024 to announce stable OpenTelemetry support. -- 2-4 weeks - First experimental semantic convention built on pre-exising feature flag semantic conventions +- 2-4 weeks - First experimental semantic convention built on pre-existing feature flag semantic conventions - 2-4 weeks - Prototype implementation and review - 2-4 weeks - Incorporate feedback from prototype implementers - 2-4 weeks - Final review period including the greater spec and maintainer community From 84b5278a522a3eb4883ad4e54dec08679d1856cf Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Sun, 7 Apr 2024 09:20:38 -0400 Subject: [PATCH 05/18] Add ryan to list --- projects/feature-flag.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index f67ed808..6256e895 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -62,7 +62,11 @@ This project also includes Dan Dyla acting as one of the project leads. Dan is a member of the GC, maintainer of OTel JS, and has experience developing semantic conventions. Dan will provide the necessary expertise to ensure the proposed semantic conventions meet the standards and expectations of the OpenTelemetry community and semantic conventions SIG. -TODO: list engineers committed to working on the project +The following is a list of engineers committed to working on the project: + +- Daniel Dyla (OTel GC, OTel JS, Dynatrace) +- Ryan Lamb (OpenFeature TC, LaunchDarkly) +- TODO: more engineers ### Required staffing @@ -72,7 +76,8 @@ TODO: list engineers committed to working on the project TODO: list prototype languages and engineers -- JS - Daniel Dyla (Maintainer) +- JS - Daniel Dyla (OTel JS Maintainer) +- Review Prototypes - Ryan Lamb (OpenFeature TC) ## Meeting Times From 0b2d0f544a3a91ee98c2bfe634256097f4a3531f Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Wed, 24 Apr 2024 13:54:30 -0400 Subject: [PATCH 06/18] Apply suggestions from code review Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com> --- projects/feature-flag.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 6256e895..6d9a42bf 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -1,12 +1,12 @@ # Feature Flag Semantic Conventions -OpenFeature is a CNCF Incubating project aiming to standardize feature flags. +[OpenFeature](https://openfeature.dev/) is a CNCF Incubating project aiming to standardize feature flags. They currently provide 11 open source SDKs in various languages and support more than 10 feature flagging backends. OpenFeature has had contributions from over 50 companies and is actively developed by a combination of end users, feature flagging vendors, and platform providers. OpenFeature provides observability data via OpenTelemetry hooks. A hook is an OpenFeature plugin which may execute logic at various stages of the feature flag evaluation process. -Currently, those hooks use the experimental feature flagging semantic convention. +Currently, those hooks use the experimental [feature flagging semantic convention](https://opentelemetry.io/docs/specs/semconv/feature-flags/). OpenFeature is looking to expand their observability solution either by improving the currently available hooks or by providing native instrumentation within the OpenFeature SDK itself. In order to support that effort, OpenFeature requires a stable semantic convention to build instrumentation around. From b5cc7f9e25d3d0f3f93e1ddb605a6f7a70e73acc Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Wed, 24 Apr 2024 13:56:44 -0400 Subject: [PATCH 07/18] Code review --- projects/feature-flag.md | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 6d9a42bf..472dbaaf 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -2,7 +2,7 @@ [OpenFeature](https://openfeature.dev/) is a CNCF Incubating project aiming to standardize feature flags. They currently provide 11 open source SDKs in various languages and support more than 10 feature flagging backends. -OpenFeature has had contributions from over 50 companies and is actively developed by a combination of end users, feature flagging vendors, and platform providers. +OpenFeature has had contributions from over 50 companies and is actively developed by a combination of end users, feature flagging vendors, and platform providers (see the list of [interested parties](https://openfeature.dev/community/interested-parties)). OpenFeature provides observability data via OpenTelemetry hooks. A hook is an OpenFeature plugin which may execute logic at various stages of the feature flag evaluation process. @@ -62,12 +62,6 @@ This project also includes Dan Dyla acting as one of the project leads. Dan is a member of the GC, maintainer of OTel JS, and has experience developing semantic conventions. Dan will provide the necessary expertise to ensure the proposed semantic conventions meet the standards and expectations of the OpenTelemetry community and semantic conventions SIG. -The following is a list of engineers committed to working on the project: - -- Daniel Dyla (OTel GC, OTel JS, Dynatrace) -- Ryan Lamb (OpenFeature TC, LaunchDarkly) -- TODO: more engineers - ### Required staffing **Project Leads:** Daniel Dyla and Michael Beemer (OpenFeature co-founder/GC member) @@ -76,8 +70,11 @@ The following is a list of engineers committed to working on the project: TODO: list prototype languages and engineers -- JS - Daniel Dyla (OTel JS Maintainer) -- Review Prototypes - Ryan Lamb (OpenFeature TC) +The following is a list of engineers committed to working on the project: + +- JS Prototype - Daniel Dyla (OTel GC, OTel JS, Dynatrace) +- Review Prototypes - Ryan Lamb (OpenFeature TC, LaunchDarkly) +- TODO: more engineers ## Meeting Times From 524f4641657b8d181412568828687bfa5b8e3c17 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 26 Apr 2024 08:45:54 -0400 Subject: [PATCH 08/18] Add project sponsors --- projects/feature-flag.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 472dbaaf..a387646a 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -62,10 +62,14 @@ This project also includes Dan Dyla acting as one of the project leads. Dan is a member of the GC, maintainer of OTel JS, and has experience developing semantic conventions. Dan will provide the necessary expertise to ensure the proposed semantic conventions meet the standards and expectations of the OpenTelemetry community and semantic conventions SIG. +The project is sponsored by Dan Dyla and Alexander Wert, an OpenTelemetry semantic conventions maintainer. + ### Required staffing **Project Leads:** Daniel Dyla and Michael Beemer (OpenFeature co-founder/GC member) +**Project Sponsors**: Daniel Dyla and Alexander Wert + **Engineers willing to write and review prototypes:** TODO: list prototype languages and engineers From a25a5a43aa47667bcc644e85bbba6168e5a0fb6e Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 26 Apr 2024 08:46:32 -0400 Subject: [PATCH 09/18] Add shortcomings of existing experimental semconv --- projects/feature-flag.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index a387646a..f4d9f62b 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -45,6 +45,35 @@ Because rule sets and monitoring data are managed in separate tools, it may be d - Analyzing the impact of the actual flag evaluation. Some feature flag libraries and services do async work such as database or remote calls to decide which variant of a feature flag should be returned. +## Experimental Semantic Conventions + +Currently, the experimental [feature flagging semantic convention](https://opentelemetry.io/docs/specs/semconv/feature-flags/) defines a minimal set of attributes to track a flag evaluation: key, provider name, and the returned variant, and shows how they can be used in logs and span events. +While this provides a lot of value, there are several shortcomings that we would like to address: + +### Shortcoming 1: key may not be unique + +Many feature flag providers introduce the concept of a collection of feature flags used by the same service, which we will call projects. +While the flag key uniquely identifies a feature flag within a project or scope, it may not be globally unique across your application or service if your app evaluates flags from multiple projects. + +### Shortcoming 2: lack of sufficient context + +Most feature flag evaluation services support a concept called flag context. +Context is a set of attributes input into the flag ruleset to influence the returned variant. +One example of this may be the current logged in users email domain; a ruleset may turn a particular variant on for only users from a particular company. +The current experimental semantic conventions currently do not address this concept. + +### Shortcoming 3: lack of metric support + +It is common to analyze new features, A/B tests, and experiments using metrics split by feature flag data. +In the current semantic convention, there is no metric advice. +This leaves the user to decide which attributes to use on their own, which may lead to cardinality explosions or imprecise results. + +### Shortcoming 4: no flag change events + +This is related to key uniqueness in that a flag's ruleset or possible variants may change over time. +These changes can have a massive impact on user experience and it is important to be able to view them in context of your observability data for effective root cause analysis. +Further, without a revision ID or similar concept, it may be difficult to determine exactly which ruleset was evaluated to return a particular feature flag variant. + ## Deliverables The project deliverable will be a stable feature flag semantic convention for flag evaluations, also called impressions, and feature flag changes. From 2b03d1112d7747b8b621339dc961459c6c91f08b Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 26 Apr 2024 08:49:55 -0400 Subject: [PATCH 10/18] Spellcheck --- projects/feature-flag.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index f4d9f62b..7c6a48a4 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -58,8 +58,8 @@ While the flag key uniquely identifies a feature flag within a project or scope, ### Shortcoming 2: lack of sufficient context Most feature flag evaluation services support a concept called flag context. -Context is a set of attributes input into the flag ruleset to influence the returned variant. -One example of this may be the current logged in users email domain; a ruleset may turn a particular variant on for only users from a particular company. +Context is a set of attributes input into the flag rule set to influence the returned variant. +One example of this may be the current logged in users email domain; a rule set may turn a particular variant on for only users from a particular company. The current experimental semantic conventions currently do not address this concept. ### Shortcoming 3: lack of metric support @@ -70,9 +70,9 @@ This leaves the user to decide which attributes to use on their own, which may l ### Shortcoming 4: no flag change events -This is related to key uniqueness in that a flag's ruleset or possible variants may change over time. +This is related to key uniqueness in that a flag's rule set or possible variants may change over time. These changes can have a massive impact on user experience and it is important to be able to view them in context of your observability data for effective root cause analysis. -Further, without a revision ID or similar concept, it may be difficult to determine exactly which ruleset was evaluated to return a particular feature flag variant. +Further, without a revision ID or similar concept, it may be difficult to determine exactly which rule set was evaluated to return a particular feature flag variant. ## Deliverables From 3ba6f3e5c6a4e0adfa0a99f256f698e55848c53c Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Tue, 30 Apr 2024 23:21:52 -0400 Subject: [PATCH 11/18] Update projects/feature-flag.md Co-authored-by: Alexander Wert --- projects/feature-flag.md | 1 + 1 file changed, 1 insertion(+) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 7c6a48a4..67779807 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -107,6 +107,7 @@ The following is a list of engineers committed to working on the project: - JS Prototype - Daniel Dyla (OTel GC, OTel JS, Dynatrace) - Review Prototypes - Ryan Lamb (OpenFeature TC, LaunchDarkly) +- Federico Bond (OpenFeature Python, Independent) - TODO: more engineers ## Meeting Times From 3384555c342105162990bfcbfaee62514b87c4f1 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Thu, 9 May 2024 09:42:36 -0400 Subject: [PATCH 12/18] Update projects/feature-flag.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: André Silva <2493377+askpt@users.noreply.github.com> --- projects/feature-flag.md | 1 + 1 file changed, 1 insertion(+) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 67779807..25728f6a 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -108,6 +108,7 @@ The following is a list of engineers committed to working on the project: - JS Prototype - Daniel Dyla (OTel GC, OTel JS, Dynatrace) - Review Prototypes - Ryan Lamb (OpenFeature TC, LaunchDarkly) - Federico Bond (OpenFeature Python, Independent) +- André Silva (OpenFeature dotnet) - TODO: more engineers ## Meeting Times From 349c23bda1b94ac587a279ff5f627498fd7ffe60 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Thu, 9 May 2024 10:12:48 -0400 Subject: [PATCH 13/18] Add andre to spelling --- .cspell.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/.cspell.yaml b/.cspell.yaml index a55d5f2c..71767086 100644 --- a/.cspell.yaml +++ b/.cspell.yaml @@ -32,6 +32,7 @@ words: - alevenberg - alolita - amye + - andré - aniszczyk - apac - anoshin From 1de0ba365eab1dc4131cc0b1d5b16b26dd80413a Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Thu, 9 May 2024 12:38:33 -0400 Subject: [PATCH 14/18] Add lukas and organize project staffing --- projects/feature-flag.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 25728f6a..a0a094d1 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -95,21 +95,23 @@ The project is sponsored by Dan Dyla and Alexander Wert, an OpenTelemetry semant ### Required staffing -**Project Leads:** Daniel Dyla and Michael Beemer (OpenFeature co-founder/GC member) +**Project Leads and Sponsors:** -**Project Sponsors**: Daniel Dyla and Alexander Wert +- Alexander Wert - Project Sponsor (OTel SemConv, Elastic) +- Daniel Dyla - Project Lead and Sponsor (OTel GC, OTel JS, Dynatrace) +- Michael Beemer - Project Lead (OpenFeature co-founder and GC, Dynatrace) -**Engineers willing to write and review prototypes:** +**Engineers:** -TODO: list prototype languages and engineers +The following is a list of engineers committed to working on the project and write and review prototypes: -The following is a list of engineers committed to working on the project: - -- JS Prototype - Daniel Dyla (OTel GC, OTel JS, Dynatrace) -- Review Prototypes - Ryan Lamb (OpenFeature TC, LaunchDarkly) -- Federico Bond (OpenFeature Python, Independent) +- Alexander Wert - (OTel SemConv, Elastic) - André Silva (OpenFeature dotnet) -- TODO: more engineers +- Daniel Dyla - (OTel GC, OTel JS, Dynatrace) +- Federico Bond (OpenFeature Python, Independent) +- Lucas Reining (OpenFeature TC) +- Michael Beemer - (OpenFeature co-founder and TC, Dynatrace) +- Ryan Lamb (OpenFeature TC, LaunchDarkly) ## Meeting Times From 3a27694358aaa0ab0acc49f59735f1d967b8bd5c Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 10 May 2024 09:04:13 -0400 Subject: [PATCH 15/18] Fix lukas' name spelling --- projects/feature-flag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index a0a094d1..092c6b4d 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -109,7 +109,7 @@ The following is a list of engineers committed to working on the project and wri - André Silva (OpenFeature dotnet) - Daniel Dyla - (OTel GC, OTel JS, Dynatrace) - Federico Bond (OpenFeature Python, Independent) -- Lucas Reining (OpenFeature TC) +- Lukas Reining (OpenFeature TC, Codecentric) - Michael Beemer - (OpenFeature co-founder and TC, Dynatrace) - Ryan Lamb (OpenFeature TC, LaunchDarkly) From 8a3fde585c347a783397bd6525f83b4133819799 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Fri, 10 May 2024 09:08:38 -0400 Subject: [PATCH 16/18] Add lukas and codecentric to cspell --- .cspell.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.cspell.yaml b/.cspell.yaml index 8f1961df..f183ac08 100644 --- a/.cspell.yaml +++ b/.cspell.yaml @@ -64,6 +64,7 @@ words: - cijo - cncf - codeboten + - codecentric - codecov - codeowners - danielgblanco @@ -120,6 +121,7 @@ words: - lmolkova - logz - lucavallin + - lukas - magnusbaeck - maintainership - mancuso From a32c028c5057748572e9f945ce4529fd88d0a3e3 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Mon, 13 May 2024 09:48:50 -0400 Subject: [PATCH 17/18] Wording suggestions from review --- projects/feature-flag.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/projects/feature-flag.md b/projects/feature-flag.md index 092c6b4d..bc1cae55 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -16,23 +16,23 @@ This project aims to develop and stabilize feature flag semantic conventions, us Currently, it is impossible to determine the impact a feature flag has on key metrics for your services. For example, if a feature flag is enabled for 25% of users, additional data is required to know if that subset of users is experiencing faster, slower, or unchanged response times. -This problem can become exponentially more challenging if multiple feature flags are evaluated over the course of a single transaction. +This problem can become exponentially more challenging if multiple feature flags are evaluated over the course of a single trace. Further, it may also be difficult or impossible to know exactly how many users are being affected by a particular feature flag. -For example, if a feature flag targets users with a particular email domain, it may require additional monitoring data to determine what portion of your users or traffic is receiving a particular experience. +For example, if a feature flag targets users with a particular email domain, it may require additional telemetry data to determine what portion of your users or traffic is receiving a particular experience. -## Problem 2: Flag management separate from monitoring data +## Problem 2: Flag management separate from telemetry data -Feature flags are typically managed outside your monitoring tooling. -There is no standardized way for a flag management system to notify a monitoring system that a feature flag rule set is changed, or if a rule is enabled or disabled. -This lack of standardization means that even if a flag management system emits a flag change event, the monitoring tool may not be able to correlate that change with the services that it impacts. +Feature flags are typically managed outside your telemetry tooling. +There is no standardized way for a flag management system to notify a telemetry system that a feature flag rule set is changed, or if a rule is enabled or disabled. +This lack of standardization means that even if a flag management system emits a flag change event, the telemetry tool may not be able to correlate that change with the services that it impacts. It also means that a person responsible for monitoring an application often has to check two separate tools in order to determine if a flag change was the root cause of a change in service metrics or behavior. -Because rule sets and monitoring data are managed in separate tools, it may be difficult to determine exactly which rule set was used and if it has been changed between when it was evaluated and when a person investigating an issue is looking at the monitoring data. +Because rule sets and telemetry data are managed in separate tools, it may be difficult to determine exactly which rule set was used and if it has been changed between when it was evaluated and when a person investigating an issue is looking at the telemetry data. ## Target Use Cases - Analyze the impact a feature flag has on key service metrics such as response time and failure rate. - If a feature variant is enabled for some subset of users, it is necessary to be able to distinguish those transactions from other transactions in your monitoring backend. + If a feature variant is enabled for some subset of users, it is necessary to be able to distinguish those traces from other traces in your telemetry backend. - Associating a flag change with a change in key service metrics. This is useful additional context during root cause analysis. One example of when this is useful may be determining the rule set that was evaluated in order to determine the flag variant. From 4d2190d524e2295226887aa9b9c990a88660b895 Mon Sep 17 00:00:00 2001 From: Daniel Dyla Date: Tue, 21 May 2024 14:52:36 -0400 Subject: [PATCH 18/18] Add andre's employer --- .cspell.yaml | 2 ++ projects/feature-flag.md | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/.cspell.yaml b/.cspell.yaml index 64ef5d29..eed73cd8 100644 --- a/.cspell.yaml +++ b/.cspell.yaml @@ -127,6 +127,7 @@ words: - kuisathaverat - lalitb - lambdanis + - lexis - liatrio - lightstep - lmolkova @@ -154,6 +155,7 @@ words: - nakamura - neumann - neumüller + - nexis - nirga - nikimanoledaki - novotny diff --git a/projects/feature-flag.md b/projects/feature-flag.md index bc1cae55..60ba18c0 100644 --- a/projects/feature-flag.md +++ b/projects/feature-flag.md @@ -106,7 +106,7 @@ The project is sponsored by Dan Dyla and Alexander Wert, an OpenTelemetry semant The following is a list of engineers committed to working on the project and write and review prototypes: - Alexander Wert - (OTel SemConv, Elastic) -- André Silva (OpenFeature dotnet) +- André Silva (OpenFeature dotnet, Lexis Nexis Risk Solutions) - Daniel Dyla - (OTel GC, OTel JS, Dynatrace) - Federico Bond (OpenFeature Python, Independent) - Lukas Reining (OpenFeature TC, Codecentric)