Add flag owner?

[goncalossilva]

Could it be widely useful if flags could have a specific organization member as an owner, or would it be a niche feature? What would be the consequences of it? Only meta-data?

[kemasdimas]

Curious to know more about this, what will be the expected use case if we can get a many-to-many relationship between members and flags?

[goncalossilva]

Good question. I was thinking about 1-to-1, not many-to-many. This mirrors a growing pattern we're seeing at Doist where specific individuals are responsible for specific flags (within a specific timeframe). We keep track of this in comments, e.g.:

/**
 * @owner goncalossilva
 * @expires February, 2022
 * @see https://github.com/Doist/repo/pull/1234
 */

This is slowly spreading across most teams without any effort to consolidate, hence the question whether this might be widely useful or not. What's your experience been like?

[kemasdimas]

I'm not a Doister yet, so haven't got any idea on how the team using this internally

I assume the flag <-> person relationship is used as a way to track a feature rollout, so in case something went wrong, the individual responsible for the rollout can easily halt the release

If that's the case, I think adding a new column in the database is better. It will be easier to keep track of the responsibility from 1 dashboard, without needing to dig into the codebase

Anyway, do you mind if I start contributing to this repo? I want to know what it feels like working on Doist 😊

[goncalossilva]

I assume the flag <-> person relationship is used as a way to track a feature rollout, so in case something went wrong, the individual responsible for the rollout can easily halt the release

Yes. It's also about cleaning up feature flags after a while, and having that responsibility well laid out.

If that's the case, I think adding a new column in the database is better. It will be easier to keep track of the responsibility from 1 dashboard, without needing to dig into the codebase

Sure, that seems like a good way to go about it implementation-wise. I'd leave this up for debate for a little while longer, though. One of FFS's values is “Lean”, and it's not 100% clear to me if this isn't bloat from the perspective of other organizations. If it's not something widely useful, it shouldn't be here. Having said this, FF ownership and sunset are common challenges and this pairs nicely with #46.

Anyway, do you mind if I start contributing to this repo? I want to know what it feels like working on Doist 😊

Go for it! It's OSS, and there are plenty of tickets to pick from. 😄

[pixyzehn]

Let me explain our iOS team's use case at Doist as it's similar to what @goncalossilva shared as an example😊

In our case, the owner in code is responsible for only cleaning it up when it's fully released or not needed anymore. Thus, it should be a developer who has the access to the code. The idea is to avoid having stale flags. Perhaps, with many developers, having a tool like uber/piranha might be a better solution.

Example:

// Owner: [Developer Name], When to remove: [Tentative Date]
let xxx = Flag()

I assume the flag <-> person relationship is used as a way to track a feature rollout, so in case something went wrong, the individual responsible for the rollout can easily halt the release

In our case, the owner in code isn't necessarily the person who is responsible for a feature rollout. In fact, a release manager or anyone at our team can turn on a flag via a dashboard. If the flag owner here means this case, I think having role permissions in the dashboard can be useful for some bigger teams.

[kemasdimas]

Thank you @pixyzehn for your additional explanation 👍

So what I understand is, the comment itself is mainly to mark the logic block where the flag is used to toggle a feature in the source code

Let's say, the flag rule is "gradually roll out X feature from January 10th to January 30th", and today is February 1st. Then, the developer responsible for this code will need to clean up their code (removing the deprecated feature and also its flag logic) and commit it to the codebase to be packaged in the next release

This got me thinking...

Because the flag rule in FFS can be set by anyone on the team (presumably the release manager), is there currently a way to let the code owner knows if the flag is already stale / expired?

[pixyzehn]

So what I understand is, the comment itself is mainly to mark the logic block where the flag is used to toggle a feature in the source code

@kemasdimas You're welcome😊 Yes, it is. To be precise, it's where the flag is defined in the source code.

Because the flag rule in FFS can be set by anyone on the team (presumably the release manager), is there currently a way to let the code owner knows if the flag is already stale / expired?

That's a good point. Just to be clear, our iOS team isn't using FFS in production yet. We're still using a third-party platform where a feature flag's rule can be set by anyone in a dashboard.

How our iOS team knows that is via communications in a squad where we work closely and we'll decide when / how to release together.

Usually, once it's fully released, we can see it as stale because there shouldn't be any turnaround at this point. However, when to make it stale / expired depends on the situation. For example, if a feature is very experimental, we might want to keep it for a while to see how it goes.

[goncalossilva]

This connects with #46, which is a planned feature. As a follow-up, it's a great idea to leverage the information from scheduled rollouts! Once we reach 100%, the flag is probably stale, even if the team wants to keep it around for a little while longer in case there is need to revert the rollout.