File tree diff: migrate feature flag to model field #11793
Conversation
There is no need to use a feature flag for this. We can use a model field as we are doing for all the other addons. As we are not exposing this field to the user yet, they can't enable it by themselves yet. So, we still have the control of it. This follows the pattern we have for all the other addons.
| @@ -185,6 +185,9 @@ class AddonsConfig(TimeStampedModel): | |||
| # EthicalAds | |||
| ethicalads_enabled = models.BooleanField(default=True) | |||
|
|
|||
| # File Tree Diff | |||
| filetreediff_enabled = models.BooleanField(default=False, null=True, blank=True) | |||
There was a problem hiding this comment.
I feel like we probably want to discuss the branding here before we bake it into the models. I feel like File Tree Diff is a weird name, and we probably want something a bit more user friendly.
I know we talked about Files changed being joint branding for docdiff & FTD, but I'm open to other ideas. We could always just have Files changed be a top-level concept for a workflow that includes docdiff and filetreediff?
There was a problem hiding this comment.
I like the "generic name" Files changed to involve both features: docdiff and file tree diff. Due to each addon being very specific (but related, tho), I'm not able to find better names for each of them. Both names are not ideal for marketing purposes; but are pretty descriptive of what they are... for a developer at least 😅
I think it's hard to explain what they do in a simple and nice name:
- Documentation page changes
- Files changed between versions
There was a problem hiding this comment.
@agjohnson @stsewd do you have any idea/suggestion?
There was a problem hiding this comment.
Documentation diff / DocDiff is also something we could use as overarching branding if we wanted, and is at least "brandable".
There was a problem hiding this comment.
Yeah, I've also been advocating for not using file tree diff to describe this addon or the feature. I think it makes the most sense for both of these features, and the addons and UI, to be combined.
Files changed at least describes the addon now. I don't feel it makes sense as a standalone addon that users can configure though.
Before we ship this, it feels like these should be a single, unified addon/feature. I don't particular like DocDiff for this. Diff view is short and clear, Documentation diff works too. Something closer to that works best I think.
There was a problem hiding this comment.
We could use visualdiff for docdiff and fileschanged for filetreediff. Those names are pretty explicit about what they are and I think they work well for marketing as well. What do you think?
There was a problem hiding this comment.
He, we are already using Visual Diff in the new dashboard actually:
There was a problem hiding this comment.
I think visual diff covers both well, I don't see a long term reason to use two names/addons/UIs.
Short term, I don't have opinions about not using filechanged but I would not surface this name in configuration/UI/marketing either. It should just be a single feature.
There was a problem hiding this comment.
OK. I will keep docdiff and filetreediff for the models and code names because we are already using those names in our code. When we expose this to users, I suppose we will use "Visual diff" as we are already doing, and maybe "Files changed" if we have 2 different features.
I don't want to rename the model fields to use fileschanged if we are already using filetreediff for the API response, for the function that calculate the diff, etc. It will just add more confusion to the code.
I'm happy to rename the code methods, functions, model fields, if we finally find a name that we like and we are convinced about 😄
There is no need to use a feature flag for this. We can use a model field as we are doing for all the other addons.
As we are not exposing this field to the user yet, they can't enable it by themselves yet. So, we still have the control of it.
This follows the pattern we have for all the other addons.