Added section on ownership of flags in environments

docs/contributing/feature-flags.md

@@ -254,23 +254,60 @@ the retrieval methods:
 
 ## Feature flag lifecycle
 
+:::tip LaunchDarkly access
+
 Let your management know when you need to change something about a feature online inside
 LaunchDarkly. Only a small number of users have accounts with LaunchDarkly to save on licensing
 costs.
 
-Feature flags don’t necessarily have to ever be deleted from LaunchDarkly, just unused. Linking them
-to Jira helps create a history of the feature and there are copious logs and audit records online
-that can be kept. Feature flags not accessed for a long period of time will automatically move to an
-"inactive" state that can also help with identifying technical debt to clean up.
+:::
+
+The process and ownership considerations for updating flag values are dependent upon the environment
+and change as the flagged code progresses through the development lifecycle.
+
+### Development environments
+
+In the development environments, ownership of the flag values is in the hands of the development
+team. The Engineering Manager of the team is responsible for maintaining and updating flag values.
+
+By default, flags should be **enabled** in the development environment as soon as the flag is
+created. This allows the feature to be viewed and exercised by product, design, the development
+team, and others within the organization. There is an understanding that there may be rough edges
+around the product deployed behind a feature flag in the development environment, as parts of the
+feature may be introduced incrementally into `main` behind the feature flag. As a general rule,
+defects should not be recorded about new features without checking with the development team first,
+to avoid reporting unfinished functionality.
+
+### QA environments
 
-While feature flags can be left indefinitely in LaunchDarkly without accumulating technical debt, it
-is essential that any logic based on these flags be removed from code as soon as the feature
-launches successfully. When defining the tasks for feature-flagged code, be sure to include a
-cleanup task for removing this logic. You may want to consider multiple tasks - one for each of the
-steps in the removal process.
+In the QA environments, the QA team owns the flag values. The QA Managers are responsible for
+maintaining and updating flag values as new features are enabled for QA testing.
+
+Flags should be **disabled** by default in the QA environments. This allows the flagged
+functionality to be fully built and tested by the developers and introduced into QA when ready. When
+the feature is `Ready for QA` the QA Engineers on the team should work with the QA Managers to
+enable the flag.
+
+The QA Managers are also responsible for ensuring that during regression testing the environment
+under test has the proper flag values set to match the desired production environment after
+deployment.
+
+### Production environments
+
+In the production environments, the ownership of the flag values is shared between product and
+engineering.
+
+Flags are **disabled** by default in the production environments. Only when the Product Manager is
+ready for the feature to be enabled should the Engineering Manager enable the flag.
 
 ### Unwinding a feature flag
 
+Once the flag has been enabled in all environments and the feature is verified to be functioning as
+expected, the final steps are to remove the flagged conditional logic from our codebase, then the
+flag itself. When defining the tasks for feature-flagged code, be sure to include a cleanup task for
+removing this logic. You may want to consider multiple tasks - one for each of the steps in the
+removal process.
+
 Due to the complexity of the different client deployments and how we expose feature flags through
 our API, it is important that each feature flag be removed in the appropriate sequence.
 
@@ -293,8 +330,12 @@ can update to the latest version to begin using the feature. See
 Once we have satisfied the requirements of
 [backward compatibility](https://bitwarden.com/help/bitwarden-software-release-support/#release-support-at-bitwarden)
 for our clients, we can completely remove the feature flag from the server codebase. This can be
-done by removing the flag value from the `FeatureFlagKeys`. This should then be deployed to the
-server to complete the removal process.
+done by removing the flag value from the `FeatureFlagKeys`.
+
+Once the server codebase has been deployed to all environments without any references to the flag,
+the flag should be archived in LaunchDarkly. Feature flags not accessed for a long period of time
+will automatically move to an "inactive" state that can also help with identifying technical debt to
+clean up.
 
 ## Self-hosted considerations