Feature toggle for content management
Janeera D A
Objective: To introduce a "Feature Toggle" mechanism within Document360 that allows writers to efficiently manage content updates tied to specific product features, ensuring seamless content rollbacks and releases.
Pain point: When a new feature is developed, associated documentation such as release notes and related articles must be updated to reflect the changes. However, there are instances where a feature might be pulled from the release due to unforeseen circumstances. In such cases, writers need to manually revert or roll back the content, which can be time-consuming, error-prone, and is a major pain point for many writers.
Proposed Solution: Implement a "Feature Toggle" system in Document360, enabling writers to assign specific codes or tags to content blocks or entire articles that correspond to a new feature. This concept is already widely used at the code level to manage feature releases and can be effectively applied to documentation.
Functionality:
Toggle Assignment: Writers can assign a unique code or tag to content blocks or articles related to a specific feature. This tag would act as a feature identifier.
Toggle Control: A toggle switch will be available for each tagged feature within the Document360 interface. When the toggle is turned on, the content associated with that feature will be included in the published version of the documentation. If the toggle is turned off, the content related to the feature will be excluded from the publication.
Publishing Workflow: Before pushing the updated documentation live, the system will check the status of each feature toggle. Only the content with toggles turned on will be published, while content with toggles turned off will be withheld.
Rollback and Updates: If a feature is pulled from a release, writers can simply turn off the corresponding toggle, preventing the related content from being published without needing to manually roll back or delete the changes. When the feature is ready to be reintroduced, the toggle can be turned back on, and the content will be included in the next publication cycle.
Benefits:
Efficiency: Reduces the time and effort needed to manage content rollbacks when features are delayed or canceled.
Accuracy: Ensures that only relevant, approved content is published, reducing the risk of errors.
Flexibility: Allows for easy re-introduction of content when a feature is eventually released.
Widely Recognized: This approach is already a proven solution at the code level and can be similarly effective when applied to documentation.
The Feature Toggle system would significantly streamline the content management process for feature-related updates, addressing a major pain point for writers, and ensuring that content releases are managed with precision and minimal manual effort.
Log In
J
John Munkberg
We have a very similar use case - but tied to FEATURE FLAGs in our product itself. I ship a new feature, but it's hidden behind a feature flag. Users can "opt in" to enable that feature or not. Or somethings we (product management) decides to enable that feature for certain customers (maybe it's a paid feature). We currently use LaunchDarkly to control these flags, but it could be any Web Service. My ask as an extension of this, it could publish all the HELP TEXT, but allow the live online help to SHOW / HIDE articles based on the value of the flag?
So customer A sees an article about the new feature they enabled, and customer B doesn't see that because they did not enable the feature.