Readthedocs.org: Document Feature flag user can request us

Created on 27 Dec 2018  路  4Comments  路  Source: readthedocs/readthedocs.org

We have several Feature flags that can be applied to projects. Although, we don't have a document that explains that they are there and how to request them to be enabled.

List of Feature flags available,

https://github.com/rtfd/readthedocs.org/blob/dec39ba70315eca338359f8381af4610a3e56274/readthedocs/projects/models.py#L1018-L1029

We should write some docs around this mentioning them and explaining how they are used and how to request them.

Comes from: https://github.com/rtfd/readthedocs.org/pull/5036#issuecomment-450011872

Accepted documentation

Most helpful comment

I don't think the point behind feature flags is to advertise to users to get a feature added, it's for us to manage the flags internally or automatically. Once a feature is ready for production, a user can manage the feature by themself, but this shouldn't require feature flags.

Our use cases for feature flags are:

  • Quick iteration to get a partial/half baked feature out
  • Sampling builds to test large changes

We shouldn't expect users to ask us for a feature -- features are ready when they're ready.

All 4 comments

@humitos
If I'm not wrong, the user has to request the admin for the enable of any of the Feature flag.
So, here's something that I thought.
In the docs, we can have these grouped in a separate heading.
And in the project admin in readthedocs.org, we can add links to these which will redirect to a new issue in RTD with prefilled details (with Project name/slug).
And in the docs, we can do the same thing, only the project details required needs to be manually filled in by the user.

Edit: Or we can just add in the docs.

I think just a specific page under our docs is enough. Maybe another entry in the FAQ with a general question like: "I want a different configuration that's not available under Admin" or well, something better than that ;)

Okay.
Working on it.

I don't think the point behind feature flags is to advertise to users to get a feature added, it's for us to manage the flags internally or automatically. Once a feature is ready for production, a user can manage the feature by themself, but this shouldn't require feature flags.

Our use cases for feature flags are:

  • Quick iteration to get a partial/half baked feature out
  • Sampling builds to test large changes

We shouldn't expect users to ask us for a feature -- features are ready when they're ready.

Was this page helpful?
0 / 5 - 0 ratings