Add Microsoft FeatureManagement Documentation

[beeme1mr]

There's a Mircosoft FeatureManagement provider but it doesn't have documentation. Without docs, it's difficult for new users to learn how the provider works. A readme should be created under /src/OpenFeature.Contrib.Providers.FeatureManagement that explains how the add the dependency to the project, how to use it in openfeature, and any limitations or gotchas that a user may encounter. Once the docs have been updated, this provider can be added to the OpenFeature ecosystem page.

[beeme1mr]

Hi @ericpattison, would you be willing to write this doc?

[theperm]

At first glance its not clear if the provider wraps the Feature management for access through the OpenFeature SDK API or does it operate in the reverse, enable access to OpenFeature backends through FeatureManagment IConfiguration - it looks more like the former, but it feels like the latter would be more desirable since its a native .NET feature. This is where documentation is required to at the very least provide an overview of what exactly this does.

[ericpattison]

@beeme1mr I'll set aside some time to work on the documentation.

@theperm I can understand the confusion. This implementation is to allow FeatureManagement to be a provider to OpenFeature.

I agree that a configuration source/provider for FeatureManagement to fetch information from OpenFeature would be great, but I'm personally not sure if this repo would be the best place for that (maintainers, please feel free to correct me if you disagree).
There are some challenges that would have to be addressed in order to safely provide that configuration source though, for example configuration providers are synchronous IO only, and are typically only loaded once and held in memory unless you can signal a reload mechanism.

All that said, I wouldn't mind finding time to put that together.

[theperm]

Ok i see... I'm not sure that approach would be popular but I'm new to OpenFeature so still mulling it over in this respect. I guess if using Azure App configuration it would provide a live configuration, but to use OpenFeature on top of FM/appsettings.cs doesnt feel the way i would want to develop a dotnet app. Using dotnet FeatureManagement as an abstraction to openfeature feels more natural since its native .net but it would also open up easy access to all the OpenFeature provider backends into the .net FeatureManagment through a single provider using IFeatureDefinitionProvider. This i think would be a better proposition. This would reduce the amount of custom providers people would have to create in .Net for all the feature flag backends out there. Food for thought.