Feature Management & Experimentation docs (copy and paste)

.github/CODEOWNERS

@@ -105,13 +105,11 @@ static/  @rohanmaharjan100 @wei-harness
 /src/components/Docs/data/serviceReliabilityManagementData.ts @sunilgupta-harness
 
 # Chaos Docs
-/docs/chaos-engineering/ @neelanjan00 @SmritiSatya @shovanmaity @Jonsy13 @Saranya-jena @Adarshkumar14 @ispeakc0de @amityt @uditgaurav @S-ayanide @vanshBhatia-A4k9 @ksatchit @umamukkara @SarthakJain26
+/docs/chaos-engineering/ @neelanjan00 @SmritiSatya @shovanmaity @Jonsy13 @Saranya-jena @Adarshkumar14 @ispeakc0de @amityt @uditgaurav @S-ayanide @vanshBhatia-A4k9 @ksatchit @umamukkara
 /release-notes/chaos-engineering.md @neelanjan00 @SmritiSatya @Jonsy13
 /src/components/Roadmap/data/ceData.ts @krishi0408 @neelanjan00 @SmritiSatya @vishal-av @SushrutHarness
 /src/components/Docs/data/chaosEngineeringData* @krishi0408 @neelanjan00 @SmritiSatya @vishal-av @SushrutHarness
 # Chaos FAQs
-/docs/faqs/chaos-engineering-faqs @neelanjan00 @SmritiSatya @shovanmaity @Jonsy13 @Saranya-jena @Adarshkumar14 @ispeakc0de @amityt @uditgaurav @S-ayanide @vanshBhatia-A4k9 @ksatchit @umamukkara @SarthakJain26
-/docs/faqs/static @neelanjan00 @SmritiSatya @Jonsy13 @Adarshkumar14 @ksatchit @umamukkara
 /kb/chaos-engineering/chaos-engineering-faq @neelanjan00 @SmritiSatya @ksatchit @umamukkara
 
 # Platform Docs
@@ -141,10 +139,10 @@ static/  @rohanmaharjan100 @wei-harness
 /docs/platform/connectors/ @krishi0408 @vishal-av
 
 # IDP Docs
-/docs/internal-developer-portal/ @Debanitrkl @OrkoHunter @manishas @khushisharmaharness
-/release-notes/internal-developer-portal.md @Debanitrkl @OrkoHunter @manishas @khushisharmaharness
-/src/components/Roadmap/data/idpData.ts @Debanitrkl @OrkoHunter @manishas @khushisharmaharness
-/src/components/Docs/data/internalDeveloperPortal.ts @Debanitrkl @OrkoHunter @manishas @khushisharmaharness
+/docs/internal-developer-portal/ @Debanitrkl @OrkoHunter @manishas
+/release-notes/internal-developer-portal.md @Debanitrkl @OrkoHunter @manishas
+/src/components/Roadmap/data/idpData.ts @Debanitrkl @OrkoHunter @manishas
+/src/components/Docs/data/internalDeveloperPortal.ts @Debanitrkl @OrkoHunter @manishas
 
 # SCS Docs
 /docs/software-supply-chain-assurance/ @sunilgupta-harness @tejakummarikuntla @pranay-harness
@@ -195,6 +193,7 @@ static/  @rohanmaharjan100 @wei-harness
 
 #FME Docs
 /src/components/Roadmap/data/fmeData.ts @dtk-DaveKarow @kleinjoshuaa @deej-split
+/docs/feature-management-experimentation/ @lenasano
 
 # Open Source Docs
 /docs/open-source/ @dewan-ahmed @rustd @SushrutHarness

docs/feature-management-experimentation.md

@@ -0,0 +1,14 @@
+---
+hide_table_of_contents: true
+hide_title: true
+title: Feature Management & Experimentation Documentation
+id: feature-management-experimentation
+---
+
+<!-- # Feature Management & Experimentation -->
+
+<!-- Custom component -->
+
+import FeatureManagementExperimentation from '@site/src/components/Docs/FeatureManagementExperimentation';
+
+<FeatureManagementExperimentation />

docs/feature-management-experimentation/10-getting-started/docs/_category_.json

@@ -0,0 +1,7 @@
+{
+    "label": "Getting started",
+    "collapsible": true,
+    "collapsed": true,
+    "className": "red",
+    "position": 3
+}

docs/feature-management-experimentation/10-getting-started/docs/key-concepts.md

@@ -0,0 +1,116 @@
+---
+title: Key concepts
+sidebar_label: Key concepts
+sidebar_position: 3
+helpdocs_is_private: false
+helpdocs_is_published: true
+---
+
+<p>
+  <button hidden style={{borderRadius:'8px', border:'1px', fontFamily:'Courier New', fontWeight:'800', textAlign:'left'}}> help.split.io link: https://help.split.io/hc/en-us/articles/9648555765133-Foundational-concepts </button>
+</p>
+
+## Key concepts
+Take 5 minutes to learn the foundational concepts of Harness Feature Management & Experimentation.
+
+## What is a feature flag?
+A feature flag wraps or gates a section of your code, allowing it to be selectively turned on or off remotely with precision, down to the level of an individual user, at any time, without a new code deployment.
+
+### Decouple your deploy from your feature release
+Feature flags allow you to decouple your deploy from your release, so your work in progress and new features are deployed in a turned-off state to any environment, which includes production, without impacting your users. 
+
+### Control your release with targeting rules
+Once your code is deployed, you can instantly turn on or off features for any individual user, group of users, or percentage of users, by creating or updating targeting rules. This approach facilitates faster software delivery practices with greater safety, including: 
+
+* Trunk-based development to reduce time lost merging code branches
+* Testing in production to allow dev, QA, and stakeholder review without impacting your users
+* Early access or beta testing for a subset of your users in production
+* Canary releases and monitored rollouts to limit the blast radius of release incidents
+* Instant kill switches to shut off exposure to a feature without rollback or redeploy
+* Infrastructure migration without downtime or risk of data loss
+* Experimentation and A/B testing to make bigger bets with less risk
+
+## The role of data in Harness FME
+FME provides visibility into your controlled releases by comparing data about feature flag evaluations with data about what happened after those evaluations. The data points that feed those comparisons are impressions and events. The results of those comparisons are called metrics.
+
+### Impressions
+An impression is a record of a targeting decision made. It is created automatically each time a feature flag is evaluated and contains details about the user or unique key for which the evaluation was performed, the targeting decision, the targeting rule that drove that decision, and a time stamp. Refer to the [Impressions](https://help.split.io/hc/en-us/articles/360020585192-Impressions) guide for more information.
+
+### Events
+An event is a record of user or system behavior. Events can be as simple as a page visited, a button clicked, or response time observed, and as complex as a transaction record with a detailed list of properties. An event doesn’t refer to a feature flag. The association between flag evaluations and events is computed for you. An event, associated with a user (or other unique keys), arriving after a flag decision for that same unique key, is attributed to that evaluation by FME’s attribution engine.
+
+To be ingested by FME, an event must contain the same user or unique key for which a feature flag evaluation was performed and a time stamp. Events are sent to FME from within your application, either from an existing customer data platform or error subsystem, or with a bulk upload using [Split Admin API](https://docs.split.io). Numerous events in integrations streamline event ingest for you.
+
+### Metrics
+FME calculates metrics by attributing events to impressions and applying metric definitions to them. A metric definition can be as simple as a count of events per user or as complex as an average of values pulled from an event’s property after filtering those same events by another property. 
+
+For example, from a stream of room_reservation events, calculate the average number of room nights booked for platinum members by examining the room_nights property after filtering the room_reservation events to those where the property club_membership = platinum.
+
+To promote one version of the truth, metrics are defined in a central location, not on a flag-by-flag basis, and all metrics are calculated for all flags. FME lets you elevate any metric your account created to be a key metric for a given feature flag. Then all the remaining metrics are sorted by impact and displayed immediately below the key metrics. This design, unique to FME, avoids blind spots caused by only looking for what you expect to find which automatically surfaces unexpected impacts. Refer to the [Metrics](https://help.split.io/hc/en-us/articles/22005565241101-Metrics) guide for more information. 
+
+### Alerts
+Alerts notify metric stakeholders and the team rolling out a particular feature when a metric threshold has exceeded a rollout or experiment that uses a percentage rollout rule.
+
+Alerts, like the metrics they are based on, are centrally defined once, and then applied to every rollout or experiment automatically. This is another design unique to FME. Our goal is to make learning and safety at speed the default experience, for every rollout. Once you define thresholds for metrics, any future rollout or experiment that exceeds them will fire an alert. When that happens, notifications are sent out, and an alert box is presented on the Targeting and Alerts tabs for the feature flag in question. Refer to the [Configuring metric alerting](https://help.split.io/hc/en-us/articles/19832312225293-Configuring-metric-alerting) guide for more information.
+
+## Using FME in your application
+Targeting decisions are made locally, in memory, from within your own application code. There is never a reason to send private user data to Harness. Let’s take a look at how this is accomplished.
+
+### FME SDKs
+To use Harness FME, include and initialize one of FME SDKs in your application. Once the SDK is initialized, targeting rules are retrieved from a nearby content delivery network (CDN) node, cached inside your code, and updated in real-time in milliseconds using a streaming architecture. 
+
+As needed, your application makes a just-in-time call to the FME SDK in local memory, passing the feature flag name, the userId or unique key, and optionally, a map of user or session attributes. The response is returned instantly, with no need for a network call. After the evaluation is performed, the SDK asynchronously returns an impression record to Harness. Refer to our [SDK overview](https://help.split.io/hc/en-us/articles/360033557092-SDK-overview) for more information.
+
+### Split evaluator
+As an alternative to using FME SDKs, you can make REST API calls to a Split Evaluator hosted inside your own infrastructure. Like the SDK, this method never requires you to send private user data to the Harness network. The evaluator makes it possible to operate from within languages that do not yet have a published FME SDK and should only be used in that case. Refer to the [Split evaluator](https://help.split.io/hc/en-us/articles/360020037072-Split-Evaluator) guide for more information.
+
+## FME's structure
+Harness FME is architected to support teams and organizations of any size, from a single developer to multiple value-stream enterprises. Take a moment to familiarize yourself with the concepts of your Harness account, project, environment, and objects, e.g., users, groups, tags, traffic types, feature flags, segments, and metrics.
+
+![](https://help.split.io/hc/article_attachments/30794709286029)
+
+### Account
+Your company has one Harness account. Your account is the highest level container. Harness FME support may ask you for your account ID to speed troubleshooting. You’ll find your account ID in the URL for every page you visit in the FME application.
+
+### Users
+A Harness user is someone with access to the Harness user interface. Administrators can invite new users to Harness. All paid plans include SSO for user authentication and can support either invites or just in time provisioning.
+
+### Groups
+A group is a convenient way to manage a collection of users in your account. You can use groups to grant administrative controls and grant environment, feature flag, or segment-level controls. Refer to the [Manage user groups](https://help.split.io/hc/en-us/articles/360020812952-Manage-user-groups) guide for more information.
+
+### Projects
+Projects provide separation or partitioning of work to reduce clutter or to enforce security. All accounts have at least one project. Use multiple projects only when you want to deliberately separate the work of different teams, product lines, or areas of work from each other. By design, objects within FME are not meant to be shared or moved across projects. Refer to the [Projects](https://help.split.io/hc/en-us/articles/360023534451-Workspaces) guide for more information.
+
+### Environment
+Within each project, you may have multiple environments, such as development, staging, and production. Refer to the [Environments](https://help.split.io/hc/en-us/articles/360019915771-Environments) guide for more information.
+
+### Feature Flags
+Feature flags are created at the project level where you specify the feature flag name, traffic type, owners, and description. Targeting rules are then created and managed at the environment level as part of the feature flag definition. Refer to the [Feature flag management](https://help.split.io/hc/en-us/articles/9650375859597-Feature-flag-management) guide for more information.
+
+### Targeting rule
+Targeting rules for each feature flag are created at the environment level. For example, this supports one set of rules in your staging environment and another in production. Rules may be based on user or device attributes, membership in a segment, a percentage of a randomly distributed population, a list of individually specified user or unique key targets, or any combination of the above.
+
+<!--  Refer to the [Creating a rollout plan](https://help.split.io/hc/en-us/articles/9805284145549-Creating-a-rollout-plan) guide for more information. -->
+
+### Segment
+A segment is a list of users or unique keys for targeting purposes. Segments are created at the environment level. Refer to the [Segments](https://help.split.io/hc/en-us/articles/360020407512-Create-a-segment) guide for more information.
+
+### Traffic type
+Targeting decisions are made on a per-user or per unique key basis, but what are the available types of unique keys you intend to target? These are your traffic types, and you can define up to ten unique key types at the project level.
+
+For feature flags that make decisions or observe metrics at the userId level, the traffic type should be user. If decisions and observations are based on account membership (to facilitate all users for a particular customer being treated the same, for instance), the traffic type should be account. Other common types are anonymous and device, but you have total flexibility in employing different traffic types. Refer to the [Traffic type](https://help.split.io/hc/en-us/articles/360019916311-Traffic-type) guide for more information.
+
+### Tag
+Use tags to organize and filter feature flags, segments, and metrics across the Harness user interface. Because they allow you to filter items in lists, they are a great way to filter by team, epic, layer of system (front-end vs back-end), or any other. Refer to the [Tags](https://help.split.io/hc/en-us/articles/360020839151-Tags) guide for more information on how to use them.
+
+### Statuses
+Statuses provide a way for teams to indicate which stage of a release or rollout a feature is in at any given moment, and as a way for teammates to filter their feature flags to see only features in a particular stage of the internal release process. There is a fixed list of status types. Refer to the [Use statuses](https://help.split.io/hc/en-us/articles/4405023981197-Use-statuses) guide for more information.
+
+<!-- asking Ani about the Creating a rollout plan link (private doc)
+## Additional essential guides
+Now that you have a grounding in our foundational concepts, the following links take you to our essential guides that walk you through:
+* [Creating and managing a feature flag](https://help.split.io/hc/en-us/articles/9650375859597)
+* [Creating a rollout plan](https://help.split.io/knowledge/articles/9805284145549/en-us?brand_id=4847928)
+* [Setting up and using metrics](https://help.split.io/hc/en-us/articles/9652327065485)
+
+-->

docs/feature-management-experimentation/10-getting-started/docs/onboarding-guide.md

@@ -0,0 +1,20 @@
+---
+title: Onboarding guide
+description: Quickstarts for Split Feature Management & Experimentation
+sidebar_label: Onboarding guide
+sidebar_position: 2
+helpdocs_is_private: false
+helpdocs_is_published: true
+---
+
+<p>
+  <button hidden style={{borderRadius:'8px', border:'1px', fontFamily:'Courier New', fontWeight:'800', textAlign:'left'}}> help.split.io link: https://help.split.io/hc/en-us/sections/360003930711-Step-by-step, https://help.split.io/hc/en-us/articles/360025035812-Introduction, https://help.split.io/hc/en-us/articles/360025334751-Step-1-Install-the-SDK, https://help.split.io/hc/en-us/articles/360025334851-Step-2-Create-a-feature-flag-and-target-users, https://help.split.io/hc/en-us/articles/360025335031-Step-3-Send-event-data, https://help.split.io/hc/en-us/articles/360025335091-Step-4-Create-a-metric-monitor-and-measure-the-impact <br /> ✘ images still hosted on help.split.io </button>
+</p>
+
+Quickstarts can help you get started with Split Feature Management & Experimentation.
+
+## Quickstart wizard
+
+You can follow the SDK Setup and Event Ingestion **Quickstart wizard** in Harness. Click **Help** in the left navigation menu, and click on one of the quickstarts.
+
+![A screenshot of the Quickstart guides in Split UI](./static/fme-quickstart.png)

docs/feature-management-experimentation/10-getting-started/docs/overview.md

@@ -0,0 +1,49 @@
+---
+title: Overview
+sidebar_label: Overview
+description: How to make Feature Management & Experimentation work for you
+sidebar_position: 1
+helpdocs_is_private: false
+helpdocs_is_published: true
+---
+
+<p>
+  <button hidden style={{borderRadius:'8px', border:'1px', fontFamily:'Courier New', fontWeight:'800', textAlign:'left'}}> help.split.io link: https://help.split.io/hc/en-us/articles/360016583411-Videos-Product-overview <br /> ✘ images still hosted on help.split.io </button>
+</p>
+
+Harness Feature Management & Experimentation (FME) combines capabilities for feature delivery and control with built-in tools for measurement and learning. FME connects insightful data to every feature release, eliminates hesitation from the software development process, and supports modern practices like continuous delivery and progressive delivery.
+
+![](./static/overview.png)
+
+### Architected for performance, security, and resilience
+
+Harness FME is built on a global feature flag and data processing architecture that serves 50 billion daily feature flags to over 2 billion end users around the globe.
+
+* **Performance:** FME streaming architecture pushes changes to its SDKs in milliseconds.
+* **Security:** The SDKs evaluate feature flags locally, so customer data is never sent over the internet.
+* **Resilience:** Our SaaS app, data platform, and API span multiple data centers. Plus, our SDKs cache locally to handle any network interruptions.
+
+Our stateless architecture scales to millions of users with no degradation in performance. FME SDKs reside in your frontend, backend, and mobile apps where they make feature flags and targeting decisions locally, without the need to send private user data outside your app for evaluation.
+
+## FME features
+
+### Feature flags
+Feature flags turn on and off features to specific users or segments. You can tailor access to beta testers and early adopters based on individual IDs, attributes, dependencies, or percentages. Gradually target users little by little to limit the blast radius of your releases.
+
+### Release monitoring
+Release monitoring detects the impact of each feature on system performance and user behavior, starting with the earliest stage of a gradual rollout. With detection and triage done at the flag level, you can ship more often and with greater confidence.
+
+### Experimentation
+Experimentation centralizes notifications for metric impacts, review periods, and change requests, empowering your team with actionable data to make rapid, precise, data-driven decisions.
+
+## Harness platform
+
+If you're new to Harness, review the [Harness platform onboarding guide](/docs/platform/get-started/onboarding-guide) and [Harness platform key concepts](/docs/platform/get-started/key-concepts).
+
+## Get started with FME
+
+Some resources to get started with FME:
+
+* [What's supported?](./../whats-supported.md)
+* [Onboarding guide](./onboarding-guide.md)
+* [Key concepts](./key-concepts/)