More wording udpates

Author: mrm9084

articles/azure-app-configuration/feature-management-python-reference.md

@@ -48,7 +48,7 @@ Here are some of the benefits of using Python feature management library:
 Feature flags are composed of two parts, a name and a list of feature-filters that are used to turn on the feature.
 
 ### Feature Filters
-Feature filters define a scenario for when a feature should be enabled. When a feature is evaluated for whether it is on or off, its list of feature filters is traversed until one of the filters decides the feature should be enabled. At this point, the feature is considered enabled and traversal through the feature filters stops. If no feature filter indicates that the feature should be enabled, it will be considered disabled.
+Feature filters define a scenario for when a feature should be enabled. When a feature is evaluated for whether it is on or off, its list of feature filters is traversed until one of the filters decides the feature should be enabled. At this point, the feature is considered enabled and traversal through the feature filters stops. If no feature filter indicates that the feature should be enabled, it considered disabled.
 
 As an example, a Microsoft Edge browser feature filter could be designed. This feature filter would activate any features attached to it, as long as an HTTP request is coming from Microsoft Edge.
 
@@ -184,7 +184,7 @@ The following snippet demonstrates how to add a customized feature filter `MyCri
 feature_manager = FeatureManager(feature_flags, feature_filters=[MyCustomFilter()])
 ```
 
-Feature filters are registered by providing when creating `FeatureManager` with `feature_filters`. If a custom feature filter needs any context they can be passed in when calling `is_enabled` using `kwargs`.
+Feature filters are registered by providing when creating `FeatureManager` with `feature_filters`. If a custom feature filter needs any context, they can be passed in when calling `is_enabled` using `kwargs`.
 
 ### Filter Alias Attribute
 
@@ -194,7 +194,7 @@ The identifier for the feature filter can be overridden by using the `@FeatureFi
 
 ### Missing Feature Filters
 
-If a feature is configured to be enabled for a specific feature filter and that feature filter isn't registered, an `ValueError` exception is raised when the feature is evaluated.
+If a feature, configured to be enabled, for a specific feature filter and that feature filter isn't registered, an `ValueError` exception is raised when the feature is evaluated.
 
 ## Built-In Feature Filters
 
@@ -317,7 +317,7 @@ In the above example, the feature is enabled for users named `Jeff` and `Alicia`
 
 ## Variants
 
-When new features are added to an application, there may come a time when a feature has multiple different proposed design options. A common solution for deciding on a design is some form of A/B testing, which involves providing a different version of the feature to different segments of the user base and choosing a version based on user interaction. In this library, this functionality is enabled by representing different configurations of a feature with variants.
+When new features are added to an application, there may come a time when a feature has multiple different proposed design options. A common solution for deciding on a design is some form of A/B testing. A/B testing involves providing a different version of the feature to different segments of the user base and choosing a version based on user interaction. In this library, this functionality is enabled by representing different configurations of a feature with variants.
 
 Variants enable a feature flag to become more than a simple on/off flag. A variant represents a value of a feature flag that can be a string, a number, a boolean, or even a configuration object. A feature flag that declares variants should define under what circumstances each variant should be used, which is covered in greater detail in the [Allocating Variants](#allocating-variants) section.
 
@@ -361,7 +361,7 @@ The variant returned is dependent on the user currently being evaluated, and tha
 
 ### Variant Feature Flag Declaration
 
-Compared to normal feature flags, variant feature flags have two additional properties: `variants` and `allocation`. The `variants` property is an array that contains the variants defined for this feature. The `allocation` property defines how these variants should be allocated for the feature. Just like declaring normal feature flags, you can set up variant feature flags in a json file. Here's an example of a variant feature flag.
+Compared to normal feature flags, variant feature flags have two more properties: `variants` and `allocation`. The `variants` property is an array that contains the variants defined for this feature. The `allocation` property defines how these variants should be allocated for the feature. Just like declaring normal feature flags, you can set up variant feature flags in a json file. Here's an example of a variant feature flag.
 
 ```json
 {
@@ -397,7 +397,7 @@ Compared to normal feature flags, variant feature flags have two additional prop
 
 #### Defining Variants
 
-Each variant has two properties: a name and a configuration. The name is used to refer to a specific variant, and the configuration is the value of that variant. The configuration can be set using `configuration_value` property. `configuration_value` is an inline configuration that can be a string, number, boolean, or configuration object. If `configuration_value` isn't specified, the returned variant's `Configuration` property will be null.
+Each variant has two properties: a name and a configuration. The name is used to refer to a specific variant, and the configuration is the value of that variant. The configuration can be set using `configuration_value` property. `configuration_value` is an inline configuration that can be a string, number, boolean, or configuration object. If `configuration_value` isn't specified, the returned variant's `Configuration` property is `None`.
 
 A list of all possible variants is defined for each feature under the `variants` property.
 
@@ -479,22 +479,22 @@ The `allocation` setting of a feature has the following properties:
 | `default_when_disabled` | Specifies which variant should be used when a variant is requested while the feature is considered disabled. |
 | `default_when_enabled` | Specifies which variant should be used when a variant is requested while the feature is considered enabled and no other variant was assigned to the user. |
 | `user` | Specifies a variant and a list of users to whom that variant should be assigned. | 
-| `group` | Specifies a variant and a list of groups. The variant will be assigned if the user is in at least one of the groups. |
+| `group` | Specifies a variant and a list of groups. The variant is assigned if the user is in at least one of the groups. |
 | `percentile` | Specifies a variant and a percentage range the user's calculated percentage has to fit into for that variant to be assigned. |
 | `seed` | The value which percentage calculations for `percentile` are based on. The percentage calculation for a specific user will be the same across all features if the same `seed` value is used. If no `seed` is specified, then a default seed is created based on the feature name. |
 
-In the above example, if the feature isn't enabled, the feature manager will assign the variant marked as `default_when_disabled` to the current user, which is `Small` in this case.
+If the feature isn't enabled, the feature manager assigns the variant marked as `default_when_disabled` to the current user, which is `Small` in this case.
 
-If the feature is enabled, the feature manager will check the `user`, `group`, and `percentile` allocations in that order to assign a variant. For this particular example, if the user being evaluated is named `Marsha`, in the group named `Ring1`, or the user happens to fall between the 0 and 10th percentile, then the specified variant is assigned to the user. In this case, all of the assigned users would return the `Big` variant. If none of these allocations match, the user is assigned the `default_when_enabled` variant, which is `Small`.
+If the feature is enabled, the feature manager checks the `user`, `group`, and `percentile` allocations in that order to assign a variant. For this particular example, if the user being evaluated is named `Marsha`, in the group named `Ring1`, or the user happens to fall between the 0 and 10th percentile, then the specified variant is assigned to the user. In this case, all of the assigned users would return the `Big` variant. If none of these allocations match, the user is assigned the `default_when_enabled` variant, which is `Small`.
 
 Allocation logic is similar to the [Microsoft.Targeting](#microsofttargeting) feature filter, but there are some parameters that are present in targeting that aren't in allocation, and vice versa. The outcomes of targeting and allocation aren't related.
 
 
 ### Overriding Enabled State with a Variant
 
-You can use variants to override the enabled state of a feature flag. Overriding gives variants an opportunity to extend the evaluation of a feature flag. If a caller is checking a feature flag, that has variants, is enabled, the feature manager will check if the variant assigned to the targeted user has override configured. Overriding is done using the optional variant property `status_override`. By default, this property is set to `None`, which means the variant doesn't affect whether the flag is considered enabled or disabled. Setting `status_override` to `Enabled` allows the variant, when chosen, to override a flag to be enabled. Setting `status_override` to `Disabled` provides the opposite functionality, therefore disabling the flag when the variant is chosen. A feature with an `enabled` state of `false` can't be overridden.
+You can use variants to override the enabled state of a feature flag. Overriding gives variants an opportunity to extend the evaluation of a feature flag. When calling `is_enabled` on a flag with variants, the Feature Manager will check if the variant assigned to the current user is configured to override the result. Overriding is done using the optional variant property `status_override`. By default, this property is set to `None`, which means the variant doesn't affect whether the flag is considered enabled or disabled. Setting `status_override` to `Enabled` allows the variant, when chosen, to override a flag to be enabled. Setting `status_override` to `Disabled` provides the opposite functionality, therefore disabling the flag when the variant is chosen. A feature with an `enabled` state of `false` can't be overridden.
 
-If you're using a feature flag with binary variants, the `status_override` property can be very helpful. It allows you to continue using APIs like `is_enabled` in your application, all while benefiting from the new features that come with variants, such as percentile allocation and seed.
+If you're using a feature flag with binary variants, the `status_override` property can be helpful. It allows you to continue using APIs like `is_enabled` in your application, all while benefiting from the new features that come with variants, such as percentile allocation and seed.
 
 ```json
 {