open-feature / open-feature/openfeature.dev

Improve experimentation documentation and messaging

Open
#1,362 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

good first issue
Dominant language
TypeScript
Stars
65
Forks
117
Avg merge
1d 11h
Merged PRs (30d)
41

Description

Context

At KubeCon EU 2026, the experimentation discussion (recap) concluded that OpenFeature should more explicitly communicate that it supports experimentation use cases.

Problem

OpenFeature already has API surface relevant to experimentation (tracking API, hooks, targeting key) but the website and docs don't make this obvious. Users exploring experimentation platforms may not realize OpenFeature can be part of their stack.

Suggested improvements

  • Add an experimentation section or page to the docs explaining how OpenFeature supports experimentation workflows
  • Document the tracking API with experimentation-focused examples
  • Blog post or tutorial showing an end-to-end experimentation setup with OpenFeature
  • Update the homepage or feature list to mention experimentation as a use case

Related

  • open-feature/spec#370: Experimentation support: standardized context fields and experiment grouping
  • open-feature/spec#371: Official evaluation metrics hook for experimentation

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing website documentation, homepage or feature list, and the tracking API material mentioned in the issue, along with the related experimentation specification discussions. Done means the selected documentation and messaging clearly explain OpenFeature's experimentation use cases, with experimentation-focused examples or an end-to-end tutorial where the scope is agreed.

Written by the indexing model from the issue text.

Assessment

Domain
content, documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
43/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.