Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenFeature – a vendor-agnostic, community-driven API for feature flagging

github.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#61

Post by j45 »

remram wrote: post #56
j45 wrote: post #52

Earlier quoted context omitted.

I suspect it’s because some users will actually be pioneers and early adopters vs believing they are. This kind of threshold adds some flexibility into the subjectivity of finding the best cohort to test a feature with.

Where the best cohort to test with is the one that agrees with you... You can call this measure "courage" but that is not actually what you are measuring. What you measure is not that different from agreement.

I didn’t use the word courage, still I understand what you’re saying.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#62

Post by inhumantsar »

remram wrote: post #50
adontz wrote: post #21

A little story from personal experience. Most people think of feature flags as boolean on/off switches, maybe per user on/off switches. If one is testing shades of colors for a "But Now!" button that may be OK. Regarding more complex tests my experience is that there are not a lot of users who tolerate experiments. Our solution was to represent feature flags as thresholds. We assigned a decimal number [0.0, 1.0) to e…

What does "tolerating experiments" mean? If they can tell it's an experiment, then isn't your change bad? Do you mean "tolerate change"? But then you still eventually roll out the change to everyone anyway... Or do you mean that users would see a different color for the "buy now" button every day? From a purely statistical point of view, if you select users which "tolerate" your change before you measure how many use…

I think you might be mixing things up a bit.

the tolerance score wouldn't be tied to a specific change. it's an estimate of how tolerant a person is of changes generally.

it's not that different from asking people if they want to be part of a beta testers group or if they would be open to being surveyed by market researchers.

targeting like that usually doesn't have a significant impact on the results of individual experiments.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#64

Post by remram »

inhumantsar wrote: post #62
remram wrote: post #50

Earlier quoted context omitted.

What does "tolerating experiments" mean? If they can tell it's an experiment, then isn't your change bad? Do you mean "tolerate change"? But then you still eventually roll out the change to everyone anyway... Or do you mean that users would see a different color for the "buy now" button every day? From a purely statistical point of view, if you select users which "tolerate" your change before you measure how many use…

I think you might be mixing things up a bit. the tolerance score wouldn't be tied to a specific change. it's an estimate of how tolerant a person is of changes generally . it's not that different from asking people if they want to be part of a beta testers group or if they would be open to being surveyed by market researchers. targeting like that usually doesn't have a significant impact on the results of individual…

If only people who like changes like your change, should you really go ahead?

Plus you don't know what that correlates to. Maybe being "tolerant of changes" correlates with being particularly computer-savvy, and you're rolling out changes that are difficult to navigate. Maybe it correlates to people who use your site only for a single task, it would appear they don't mind changes across the platform, but they don't see them. Maybe it correlates with people who hate your site now, and are happy you're changing it (but still hate it).

You can't use a selected subset that is not obviously uncorrelated from your target variable. This is selection bias as a service.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#65

Post by remram »

j45 wrote: post #61
remram wrote: post #56

Earlier quoted context omitted.

Where the best cohort to test with is the one that agrees with you... You can call this measure "courage" but that is not actually what you are measuring. What you measure is not that different from agreement.

I didn’t use the word courage, still I understand what you’re saying.

adontz did above, that's what they called this user-tolerance-for-experiments metric. I didn't mean to imply you would too, apologies.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#66

Post by j45 »

remram wrote: post #65
j45 wrote: post #61

Earlier quoted context omitted.

I didn’t use the word courage, still I understand what you’re saying.

adontz did above, that's what they called this user-tolerance-for-experiments metric. I didn't mean to imply you would too, apologies.

Oh, no need to apologize at all.

I could have clarified as well that I was leaning more towards the user-tolerance... or as I like to call it user-guess that this feature might be OK with them :)

Another thing I like about granular and flexible feature flag management is you can really dial in and learn from which features get used by whom, actually.... instead of building things that will collect dust.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#67

Post by sgammon »

ahtihn wrote: post #51
martypitt wrote: post #9

Earlier quoted context omitted.

Lombok is a very divisive framework in Java, with strong opinions on both sides. Given that, it's a bold choice to include Lombok in a library that other developers will pull into their stack - it's likely to make this a non-starter from those in the 'no' camp. As Lombok is just compiler sugar, when building an SDK for other developers, it's probably less alienating to just write the boilerplate that Lombok saves you…

Lombok is a compile-time dependency. Consumers of a library using lombok don't need to depend on lombok, so I don't see why it would matter?

The symbols remain in the final library, necessitating either class exclusions within the scope of a JAR you don't control (which is a terrible idea) or the addition of a dependency which is irrelevant, inert, and has no place in your codebase.

It is embarrassing for a library to ship ABI-visible symbols from Lombok.

Post reply on HN