►
From YouTube: OpenFeature - Project meeting, November 10th, 2022
Description
meeting notes: https://docs.google.com/document/d/1p...
OpenFeature website: https://open-feature.github.io/
A
C
B
C
B
A
C
D
A
F
A
Okay,
it
can
be
Justin's
replacement,
I'll,
just
move
him
to
the
next
one:
hello,
Pete,
hey
Steve,
all
right
I'll
share
the
link
again.
If
anyone
has
any
anything
to
add
to
the
the
meeting
notes,
please
feel
free
I,
just
like
kind
of
prefix
it
with
your
name.
So
we
know
who
to
to
call
on
when
we
get
there
perfect
any
volunteers
for
roles
for
next
time.
E
E
A
So
hopefully
you
know
I
can
review
that
with
the
governance
board
and
we'll
come
to
some
kind
of
consensus
on
where
we'd
like
to
you
know,
spend
the
next
three
or
six
months
on
the
project
and
then
some
also
some
like
goals
for
what
we'd
like
to
achieve
in
terms
of
like
adoption
rates
and
things
like
that.
So
nothing
concrete
at
this
point
it's
more
of
a
proposal,
but
just
wanted
to
give
everyone
a
heads
up
that
that's
kind
of
what
I'm
I'm
trying
to
work
on
behind
the
scenes.
Right
now.
D
A
That's
what
I'm
thinking,
probably
a
Google
doc,
would
be
best
and
I
can
share
it
and
get
notes
and
kind
of
collaborate
there.
So
I'll
just
transform
what
I've
done
so
far
on
Miro
to
to
a
doc
and
I
get
that
shared
out.
So
we
can.
Everyone
can
be
on
the
same
page.
Nothing
should
come
as
too
surprising
it's
more
around,
like
you
know,
adoption
and
downloads,
and
you
know
community
outreach
and
certain
like
technologies
that
we
need
to.
A
B
D
A
D
A
There
is
a
road
map
kind
of
it's.
It
was
one
that
we
were
using
initially
to
track
like
the
initial
like
sdks
and
those
have
more
or
less
been
moved
to
complete.
So
it's
it's
pretty
empty
and
we
probably
want
to
just
restructure
it
in
general,
like
some
of
the
focus
isn't
necessarily
on
like
the
the
core
like
Alpha
sdks
anymore.
It's
it's
transitioned
to
other.
D
A
A
A
A
Cool
all
right,
I
just
want
to
give
another
quick
update
on
open
Telemetry.
This
is
like
the
the
pull
request
that
yeah
won't
go
away.
It
seems
I
thought
it
was
a
very
non-controversial
suggestion
on
the
open,
Telemetry
side.
I
think
we've
gotten
good
feedback,
but
it's
taken
a
long
time
to
get
there.
The
current
proposal
is
to
shift
instead
of
doing
if
you're
familiar
with
open,
Telemetry
and
Concepts.
A
Instead
of
doing
like
a
individual
span
for
a
flag
evaluation,
it's
an
event
on
a
span
which
conceptually
the
only
real
difference,
is
you
lose
out
on
timing,
which
I'm
not
gonna,
fight
that
battle?
If
that's
the
direction
that
those
guys
want
to
go,
I,
don't
think.
That's
that
big
a
deal.
They
also
want
to
include
a
spec
for
logs.
So
basically,
logs
and
events
are
effectively
the
same
thing
in
hotel,
so
I
basically
am
going
to
break
it
out
to
like
a
higher
level,
abstraction
and
say
like
if
you're
going
to
write
logs.
A
You
do
it
in
this
format.
If
you're
going
to
do
a
span
event,
you
do
it
in
this
format
and
they're
going
to
be
basically
the
same.
So
that's
the
current
proposal,
I
suppose
the
one
nice
thing
about
the
logs
is,
if
even
if
you
weren't
using
like
open
feature,
if
you're
just
like
a
vendor,
maintaining
an
SDK
and
you
want
to
dump
logs
in
a
certain
format
like
Telemetry
tools
could
start
picking
that
up
and
using
it
as
well.
So
there
is
some
advantages
of
doing
just
logs.
There's
less
you
know
overhead
involved.
A
D
A
A
D
G
A
A
Of
it
is
exactly
the
the
spot
where
it
changes
slightly
is
where
you're
enhancement
proposal
had
brought
up
the
the
idea
of
like
adding
in
provider
specific
metadata.
That
is
something
that
wouldn't
be
covered
in
this
one
right
here,
but
you
could
certainly
do
it.
Nothing
prevents
you
from
adding
like
arbitrary
data.
It's
just
not
covered
in,
like
the
spec
I.
G
Think
that's
I
mean
I.
Think
personally,
that
part
is
fine,
because
if
a
provider
wants
to
get
that
stuff
in
there,
then
they
can
pump
stuff
into
hotel
as
part
of
the
flag
evaluation
right,
I
mean
I.
Almost
think
like
to
me.
That's
the
most
useful
to
me.
That's
the
most
useful
part
for
a
for
an
end
user
of
this.
G
The
most
useful
part
is
the
semantics
around
the
the
flagging
attributes,
because
that's
what
like
as
an
end
user,
you
generally
want
to
you
don't
really
like
unless
you
unless
and
there's
something's
going
wrong,
you
don't
really
care
lifestyle
is
going
pretty
badly
wrong.
You
don't
really
care
about
how
long
the
flag
evaluation
is
taking.
But
you
are,
you
do
want
to
know
which
flag
was
on
during
this
yeah.
A
Exactly
and
that's
why
I
kind
of
dropped
that
that
part
of
the
requirement
like
it,
it
may
have
value
in
some
cases,
but
it's
only
valuable
if,
if
for
some
reason,
the
flag
evaluation
is
really
slow,
which
shouldn't
be
the
case
and
if
it
is
slow,
it's
typically
because
it's
doing
some
kind
of
like
Network
call,
which
you'd
also
see
in
hotel.
So
like
it
really
doesn't
matter
an
event.
I
think
is
perfectly
fine
and
I've
done
a
few
proof
of
Concepts.
You
can
even
see
it
in
the
open,
Future
demo
application.
A
A
G
A
Which
then
allows
you
to
kind
of
do
any
kind
of
slicing
and
dicing
you'd
like
okay,
okay
and
maybe
maybe
next
time
I
could
do
a
quick
demo
to
get
you
know
so
people
can
can
actually
see
it.
I
think
that
may
be
helpful.
I.
Don't
have
it
prepared
right
now,
but
I'm
happy
to
show
off
you
know
and
at
the
next
meeting
and
give
people's
thoughts.
A
B
Been
interesting
to
to
listen
to
some
of
the
talk
on
the
pr,
though,
because
it's
clear
that
even
the
hotel
community
and
some
of
the
maintainers
of
the
semantic
conventions
see
a
lot
of
value
in
feature
Flags.
They
care
a
lot
about
how
it's
represented,
because
they
use
them
themselves.
So
I
think
we're
barking
up
the
right
tree.
B
A
Focused
there
I
would
say
and
like
almost
wanting
to
like
rethink
all
of
like
or
certain
parts
of
hotel
to
make
it
work
so
like
that
was
kind
of
part
of
like
almost
a
blocker
at
this
point,
but
we'll
see
like
we're,
hoping
to
kind
of
have
a
balance
between
like
something
that
we
can
get
in
quickly
and
useful,
but
also
taking
as
much
advantage
of
like
what
hotel
can
provide
as
possible.
So
yeah,
it's
an
interesting
thread.
A
We
have
like
well
over
100
comments
on
there
and
some
of
them
are
pretty
detailed
responses.
So
if
you
have
any
interest,
definitely
kind
of
review
that
cool-
that's
it
for
me,
looks
like
Todd,
is
next
and
and
just
a
reminder,
if
you
want
to
add
anything,
please
feel
free
to
I'll
link
it
one
more
time
in
the
chat.
B
A
B
B
B
B
So
it
may
just
be
like
work
like
I
may,
reach
out
to
people,
because
I
think
I
know
who
those
people
are
in
a
de
facto
sense
for
each
SDK,
but
I.
Think
I'd
like
to
start
a
slack
thread
or
or
maybe
an
issue
in
community
to
talk
about
the
responsibilities
of
maintainers
and
what
the
expectations
are.
I
mean.
Obviously
it's
a
voluntary
position,
but
there's
a
responsibility
to
do
reviews
in
a
reasonable
time
and
participate
in
certain
discussions
and
meetings.
B
So
I'd
like
to
have
two
volunteers
for
each
SDK,
like
I,
said:
I
have
an
idea
of
who
those
people
are
so
I'll,
probably
just
reach
out
to
them
and
coordinate
that
and
then
I'll
kind
of,
especially
with
the
the
technical
steering
committee.
I'll
kind
of
bring
that
up
an
issue
and
we
can
kind
of
make
it
official
put
it
in
the
charter.
B
B
Okay,
so
then,
and
the
two
sdks
actually
I
guess:
there's
three
there's
there's
PHP
in
addition
to
Python
and
Ruby.
So
these
are
kind
of
being
actively
worked
on
they're,
not
1.0.
We
have
the
401.0
C,
sharp,
Java,
JavaScript
and
Dot
net
or
sorry
and
go
so
then
there's
python,
Ruby
and
PHP.
These
are
all
underactive
development,
they're,
not
spec
complete,
but
I'm
I'm,
trying
my
best
to
Shepherd
those.
B
You
know
I
can
make
sure
that
things
are
kind
of
to
spec,
but
in
terms
of
making
sure
that
these
sdks
are
are
you
know,
comporting
to
the
paradigms
of
the
language
that
they're
written
in?
That's
something
I
need
expertise
in
so
I
think,
especially
with
Ruby
and
PHP.
Were
there
but
python
I.
Think
we've
we've
been
having
a
little
bit
of
issues
getting
traction.
B
D
If
you
brought
it
up
now,
we
yesterday
talked
sorry
that
David
and
I
we
we
talked
to
open
source
at
apple
and
they
proposed
to
file
an
issue
on
the
Swift
board,
So
that,
obviously
you
picked
this
up.
So
it's
developed
open
source,
but
there
are
a
lot
of
Apple
people
on
there
and
the
recommendation
was
for
the
open
feature
SDK
to
file
it
directly
on
the
Swift
port
for
for
support.
There.
B
G
I
mean
I
think,
depending
on
how
much
appetite
we
have
to
to
do
this
like
if
we're
posting
on
there
saying
like
trying
to
solicit
explicit
people
to
to
build
something,
I
think
we
can
also
make
it
clear
that
we're
excited
to
offer
kind
of
support
and
guidance
on
the
open
feature
side
of
things
rather
than
just
being
like
you.
Someone
should
do
this
just
to
make
it.
You
know,
put
some
sugar
on
top
of
like
we
would
love
to
help
help
you
in
doing
this.
B
Yeah
I
think
we
I
think
we
can
offer
a
high
degree
of
support
like
we
have.
You
know.
Obviously
we
have
all
these
publishing
from
the
org.
We
have
kind
of
a
pattern
for
for
even
doing
extensions
with
contribs,
like
I
think
we
have
a
lot
of
the
busy
work
taken
care
of,
and
we
can
certainly
help
with
that.
It's
really
just
getting
somebody
who
understands
the
language,
idioms
yeah,
that's
what
we
need.
Yeah.
G
B
Yeah
to
be
clear,
we
have
contributors
who
are
doing
a
great
job,
there's
nothing
wrong
with
anything.
That's
that's
been
committed
so
far
with
python.
The
issue
is
that
we
don't
have
I,
think
a
point
person
like
we
don't
have.
We
don't
have
somebody
who
really
understands
the
whole
who
who's
like
you
know,
taking
a
lot
of
responsibility
for
the
whole
picture
in
terms
of
the
pipeline
implementation.
E
B
G
G
E
E
Mean
yeah,
it's
just
I
think
it's
just
like
something
to
bear
in
mind.
That's
going
to
come
down
the
line
when
it
when
people
start
stretching
stuff
and
then
they're
like
or
actually
like
you
know,
putting
it
out
into
their
code
and
like
oh,
we
need
to
be
able
to
do
this.
Fungible
thing
with
this
widget
in
this
view,
version
blah
and
you
know,
and
it's
like
well,
you
know
that's
not
sort
of
like
you
know
that
doesn't
exist
in
a
browser
or
whatever
you
know
it's
it.
G
Thing
like
I.
Think,
like
I.
I,
really
hope
that
we
could
get
to
the
point
that
there's
like
a
a
small
kind
of
Kernel
like
JavaScript
SDK.
That
works
in
that
provides
enough
kind
of
capabilities.
And
then
you
can
bolt
on
top
like
the
react,
specific
stuff,
the
express,
specific
stuff,
the
like
next
and
react,
native,
blah,
blah
and
and
have
those
ones
be
like
pushed
further
and
further
out
into
kind
of
community
and
like
someone
who
cares
mostly
about
react,
but
also
uses
open
feature.
Maintaining
them.
G
E
Can
get
yeah
yeah
but
and
the
thing
is
those
boundaries
like
they
have
I.
Don't
I
know
this.
Isn't
this?
Isn't
you
know
anyone's
fault
or
anything?
There's
they
they.
Those
boundaries
haven't
been
tested
that
much
currently,
but
when
people
start
throwing
it
at
all,
these
new
crazy
native
react:
Java,
Script
mobile
Frameworks,
it's
like
yeah,
it's
gonna,
be
it's
going
to
be
tested,
I,
think
and
I.
Think
I
do
think.
There's
like
there's,
probably
a
really
elegant
solution
somewhere,
it's
just
it's!
It's
quite
murky
in
the
future.
I
think
yeah.
F
So
if
I,
when
I,
did
the
providers
for
cloud
bees
yeah
basically
hit
that
exact
same
thing,
there's
one
JavaScript
SDK
for
openfeature
and
Cloud
views
provide
two
sdks
for
JavaScript
one
for
browser,
one
for
Server
I.
Don't
fully
understand
the
nuances
in
the
subtle
different,
the
sole
differences
between
them
so
I,
just
when
I've
created
the
provides
I
just
went
and
went
I'll
just
create
two
providers.
The
implementation
is
basically
exactly
the
same
thing.
Apart
from
it
calls
the
relevant
relevant
provider.
F
I
do
know
that
when
you
get
down
into
react
the
way
it
works
when
you
go
to
a
web
pages,
it
repeatedly
re-renders
elements
on
the
page,
and
so
we've
seen
this
in
our
logs
and
the
impression
data
we
get
when
flags
are
evaluated.
You'd
you'd
think
you
go
to
a
page
and
like
when
somebody
goes
to
a
page.
It
evaluates
the
flag
once
in
actual
fact
it
kind
of
evaluates
it.
F
15
16
times,
yeah
I
bet,
so
our
analytics
that
we've
we've
got
built
into
our
system
of
when
you
we
do
anything
with
with
front
end.
The
numbers
are
just
blown
completely
out
the
water
they're
crazily
High,
because
every
single
kind
of
change
in
a
page,
reevaluates
the
flag
and
so
I
think
I.
Think
we
had
discussions
at
some
point
before
I
joined
the
project
of.
Should
there
be
a
react
native
SDK
for
that
would
kind
of
handle
this
and
just
make
it
easier
to
develop
with.
D
A
G
I've
I've
got
one
I
did
like
a
really
basic,
just
like
react
hook
on
top
of
yeah,
like
a
react
hook
on
on
top
of
like
a
hook-based
thing
on
on
top
of
the
JavaScript
St,
the
S,
the
open
feature,
JavaScript
SDK,
because
that's
like
that's
like
my
my
day,
job
is,
is
like
trying
to
figure
out
how
to
get
that
stuff
to
work
to
a
large
extent
and
yeah
so
I
know
I've
got
I've
got
something
there.
I
think
I'd
be
I'd,
be
very
happy
to
to
I.
G
100
expect
like
to
Ben's
point
that
if,
if
I
like
put
out
any
kind
of
like
react,
specific
thing,
it
would
be
kind
of
torn
apart
by
people
of
saying,
like
oh
I,
need
to
do
this
thing.
It
doesn't
do
this
thing,
I'm
very
happy
to
provide
a
straw
man
that
can
be
beaten
up,
but
I
think
having
having
something
as
a
starting
point
would
be
good.
I.
G
Think
a
sign
of
success,
like
kind
of
going
back
to
the
okr
thing
would
be
if
people
are
so
angry
at
how
bad
we
are
at
react
stuff
that
they
go
and
create.
Like
a
complete
contained
thing
that
becomes
astounding,
because
that's
definitely
like
the
pattern
in
JavaScript
is
like
the
really
successful
kind
of
like
libraries
or
Frameworks
in
the
ecosystem
are
generally
kind
of
like
respond.
Just
100.
G
E
Yeah,
that's
that's
what
our
experience
is
like
everyone's
got
an
opinion
and
no
one
can
agree
that
any
of
them
are
right,
which
maybe
it's
kind
of
healthy
in
a
way.
But
the
other
thing
that
I
was
just
thinking
was
like
is
I
feel
like
this
is
something
that
we've
learned
over
time
is
whether
there
might
be
sort
of
client
or
server
specific
parts
of
the
specification
you.
H
E
Like
a
like
a
re-render
event
or
or
hook
or
something
which
obviously
like
conceptually,
wouldn't
exist
in
a
go
SDK
but
fully
would
do
across
like
I
mean
yeah
I,
don't
know
how
Swift
lays
you
know
whether
it
has
a
similar.
Like
you
know,
life
cycle
model
to
react,
but
I
would
fully
I
I.
Just
think.
One
of
the
mistakes
we
made
early
on
was
was
trying
to
lump
everything
together
and
not
separate
them
out
as
two
distinct
I
mean
Concepts.
G
G
It
I
think
I
think
it's
both
like
not
like.
So
normally
for
most
of
the
vendors
there's
like
the
core-
and
you
know,
there's
vendors
here
you
can
talk
just
probably
better
than
I
can
but
there's
normally
there's
like
a
core
SDK
for
like
node
and
for
front
end
and
then
on
top
of
that
or
kind
of
plugged
into
that.
There's
like
react,
specific
stuff
or
view
specific
stuff
or
whatever
and
I
think.
G
The
main
reason
for
those
two
core
sdks
is
the
life
cycle
is
just
so
different
for,
like
for
server
side,
you
boot
like
at
the
beginning
of
the
process,
booting
and
then
you're.
Basically,
you've
got
memory.
You're
long-lived
you
can
kind
of
like
do
like
like
you
can
expect
to
live
for
a
while
for
the
client-side
stuff.
G
You've
you've
got
to
like
you're,
almost
always
going
to
get
asked
a
question
before
you're
ready
or
you
have
to
support
that,
and
you
don't
have
any
kind
of
like
memory
right
like
you
could
suddenly
lose
all
the
stuff
and
and
if
you
want
to
and
you've
and
you've
you're
on
the
other
end
of
a
freaking,
crappy
Network
right.
So
the
like,
not
just
the
so
like
the
way,
the
actual
implementation,
a
lot
of
times
with
the
provider,
has
to
be
really
different.
B
G
Not
sure
whether
you
can
still
I
I
kind
of
feel
like
there
is
a
way
of
threading,
the
needle
and
adding
enough
stuff
to
the
SDK
that
it
could
support
both
contexts
but
I
think
on
the
provider
level
to
Steve's
point
I.
Think
you're
always
going
to
have
vendors,
what
like
just
for
being
able
to
to
to
deliver
Flags
in
a
performant
way,
using
whatever
their
implementation
is
they're
going
to
have
two
different
implementations
to
work
in
those
two
different
contexts.
That's
my
yeah.
B
You're
totally
right
even
beyond
that,
though
part
of
it
is
just
the
JavaScript
ecosystem
and
the
realities
of
the
runtime,
because
it's
not
just
that
the
sdks
are
used
very
different
ways
which
is
kind
of
what
you're
alluding
to.
But
it's
also
that
fundamentally,
the
run
time
is
totally
different
from
the
browser
to
node
right,
like
there's
Primitives
that
literally
do
not
exist.
You
can't
read
a
file
system
in
a
browser,
so
there's
there's
a
whole
bunch
of
stuff
like
that.
B
That
necessitates
different
different
deployments
or
different
iterations
of
an
SDK
different
versions
of
an
SDK
for
vendors,
where
we
have
things
a
little
bit
different,
and
this
goes
back
to
what
you
were
saying
too
about
a
kernel.
The
the
API
or
sort
of
the
SDK.
The
feature
SDK
is
does
not
concern
itself
with
IO.
It
does
not
concern
itself
with
with
any
of
those
things.
It's
really
just
interfaces.
I
mean
it
does
do
some
work,
but
it's
massaging
data
that
it
is
really
completely.
B
It
is
completely
unaware
where
it
came
from
right,
so
it
actually
makes
it
relatively
easy
for
us
to
just
Define
an
SDK
entirely
in
an
agnostic
way,
and
then
you
can
look
at
the
SDK.
It
has
no
dependencies
on
any
node
Primitives
or
any
browser
Primitives.
It's
completely
neutral
and
I
think
that
we'll
be
able
to
continue
down
that
path.
B
So
I
I
think
we're
on
the
right
path
and
I
think
that
we
will
end
up
kind
of
in
a
so
far.
Everything
points
to
that.
We're
going
to
end
up
in
a
place
where
we
do
have
this
kernel,
that's
completely
common
to
both
to
all
JavaScript
runtimes,
and
then
all
these
extensions
that
are,
you
know,
associated
with
one
runtime
or
another,
and
providers
associated
with
one
runtime
or
another
I.
G
Apart
from
the
bit
where
you
said
no
problem,
I
think
that
we've
still
got
a
couple
of
things
where
we're
going
to
realize
that
there's
a
part
of
the
spec
or
the
SDK
that
needs
to
be
added
in
order
to
support
running
in
those
two
different
contexts
and
I
I.
Have
this
feeling
I
can't
quite
put
my
finger,
what
it
is,
but
there's
something
around
the
life
cycle
and
and
we've
kind
of
got
a
kind
of
okay
version
of
it
around
kind
of
events
for
like.
G
Are
you
ready
to
or
like
the
responses
for
like?
Is
this
feature
like?
Basically?
Are
you
ready
to
give
me
a
future
Flags
but
I
think
like
like
definitely
for
for
reaction,
I.
Think
for
all
the
Frameworks
there's
a
very
common
kind
of
situation
where
someone
comes
and
asks
you
for
a
feature
flag,
and
you
want
to
say
it's
not
ready
yet
but
like
I'm
gonna
call
you
back
when
it's
ready
right,
like
and,
and
you
and
I
I
have
I
haven't
tried
to
implement
it
yet.
G
But
I
have
a
feeling
that
there's
going
to
be
like
a
thing
where
you
can
get
it
to
work
with
the
SDK,
but
it's
a
pain
in
or
there's
just
like
some
hook
that
we
don't
have
available
hook
in
the
general
sense.
We
don't
have
available
that
we
need
to
add,
but
I'm
not
saying
that
in
a
like
a
oh,
this
is
terrible,
I'm,
just
saying
I
think
there's,
maybe
one
or
two
little
extra
things
we're
going
to
need
to
add
to
make
it
easy
to
do.
E
G
B
So
this
this
is
kind
of
exactly
what
we
were
just
talking
about.
There's
two
PRS
there
316
and
142..
So
316
is
an
experimental
version
of
the
JavaScript
SDK
that
supports
Eventing.
So
you
can
subscribe
to
I'm
ready.
My
Associated
configuration
changed
I'm.
My
provider's
closing
down
and
error
I.
Think
right
now,
which
is
yeah
I
mean
it's
all
very
experimental.
B
It
is
published
in
npm
under
an
alpha,
a
special
Alpha
tag
with
a
commit
hash
on
it,
but
then
we,
what
I
did
was
I
used
that
as
the
basis
for
an
experimental
flag,
D
web
provider,
which
is
exactly
like
our
flag,
D
server-side
provider,
except
it
talks
from
it,
uses
basically
grpc
over
HTTP
from
the
browser
to
do
flag
evaluations
right
from
from
JavaScript
and
because
of
the
way
JavaScript
Works.
Obviously
Eventing
is
super
relevant,
so
it
also
has
event
support,
so
I
mean
take
a
look
at
those
things.
B
I
can
demo
them
later
they're,
not
quite
ready.
It's
basically
there
for
review,
but
I'm
hoping
that
by
the
next
time
we
have
a
meeting
I'll
be
able
to
show
that
some
of
this
stuff
works,
but
it's
nice.
It
does
exactly
what
Ben
was
referring
to
like
you
can
kill
flag
D
and
the
flag
evaluations
will
still
work
because
they're
retrieved
from
local
storage,
they're
cached
there
you
can
even
restart
the
browser
with
flag
D
dead
and
you'll
still
get
flag
evaluations.
B
It's
all
very
experimental
again,
it's
just
to
prove
out
some
of
these
Concepts
and
to
explore
some
of
these
Concepts
and
and
push
the
boundaries
of
the
SDK.
Again.
There
is
SDK
changes
here.
I
think
they're
also
relevant
to
the
server
side.
So
you
know
it's.
It
would
be
nice
for
the
server
to
also
know
a
flag
configuration
change.
There's
there's
benefit
there
and
it
does
work
both
server-side
and
and
client
side.
The
providers
obviously
implemented
just
for
for
the
web
client,
but
yeah
take
a
look.
B
B
B
I'm
actually
glad
fire
showed
up.
This
is
disposal
is
something
that
fire
mentioned
earlier
well
before
kubecon,
and
it
goes
back
to
some
of
the
previous
discussion
when
you
start
adding
handlers
and
you
start
adding
event
event.
Listeners
disposing
of
them
becomes
important,
and
so
that's
also
something
that
we
need
to
probably
add
into
the
SDK
as
well
as
some
providers
may
may
set
up
timers
or
something
like
that
intervals.
B
Yeah
there
may
be
caches
to
flush,
so
there's
yeah
exactly
there's,
there's
probably
the
need
for
the
spec
to
font
to
define
a
way
to
do
this
from
an
API
just
say:
hey,
like
I'm,
shutting
down
cleaning
everything
up
or
I'm,
changing
my
provider
clean
everything
up
or
I'm
done
with
feature
Flags
or
something
like
that
clean
everything
up.
There's,
there's
probably
some
valid
use
cases
there.
B
H
Yeah,
it's
yeah
I
wanted
to
finish
that
proposal
off
for
the
spousing
of
stuff
and
basically
for
all
the
reasons
you
listed,
because
the
post
hoc
node
client,
as
as
these
times
running
to
for
local
evaluation
right.
That
is
the
latest
list
of
Beauty
Flex
defined
on
the
server
side
and
flushing
of
events,
because
you
can
Center
a
product
analytics
event
for
each
time
a
future
flag
gets
called,
and
then
you
can
do
any
other
stuff.
So
that
was
the
reason
why
I
wanted
that
dispose.
H
So
I
can
like
cleanly
clean
all
the
stuff
up
when
like
stick
to
him
or
another
sort
of
stops,
yeah
so
I
plan
to
finish
that,
maybe
over
the
weekends
we
can
like
discuss
it
next
time
or
in
GitHub.
But
I
was
just
thinking
this
to
maybe
make
it
a
bit
the
same
way
as
optiment.
He
has
for
her
exporters,
where
you
just
have
like
either
like
a
shutdown
function
or
like
this
post
function.
B
D
Yeah
governance
board
again
sorry
for
canceling
on
Monday
this
week.
The
reason
is
actually
oops
this
out
there
is
there
a
massive
snowstorm
here
in
Tahoe
and
I
needed
to
get
here
and
I
had
to
reschedule
my
day
So.
The
plan
is
how
to
put
this
next
week,
Tuesday
out
there.
That
would
also
work
for
Justin.
D
D
D
I've
worked
with
David
as
well,
who
helped
out
on
some
of
the
governance
work,
so
we
could
be
most
of
the
stuff
over
from
open,
telemetry,
basically
taking
something
that
already
Works
rather
than
Reinventing,
something
that
would
be
my
proposal
also
for
the
voting,
maybe
quickly
on
the
voting,
how
open
Telemetry
handled
it
so
that
the
bootstrap
governance
board,
which
we
would
have
right
now
as
well.
We
find
a
time
early
next
year,
where
we
would
then
have
an
official,
an
official
vote.
D
F
D
Because,
obviously,
this
is
also
usually
related
to
some
additional
work
that
people
have
to
do
again,
we'll
bring
the
bits
and
pieces
in
there.
David
and
I
are
working
on
merging
them
over
right.
Now
we
have
like
this
massive
piece,
we're
going
to
break
it
down
into
smaller
PRS,
as
we
go
forward
here
and
obviously
also
shared
on
the
open
feature
channel
so
that
you
have
all
full
I.
Don't
remember,
you
said
sorry
David.
D
D
D
Yeah,
that's
one
and
they're
also
asked
people,
because
what
what
my
feedback
so
far
is
and
what
I
started
to
see
is
I
feel
like
feedback
I
got
from
people.
A
lot
of
people
have
questions
about
open
feature,
but
most
questions
they
have
are
not
about
how
open
feature
Works
per
se
I
mean.
Luckily,
we
have
an
SDK,
that's
pretty
much
self-describing,
but
they
have
a
lot
of
questions
about
feature.
Flags
like
I,
did
a
session
at
the
kubernetes
community
days
and
their
questions
like
okay.
D
D
How
do
I
actually
do
this
I?
Think
that
that's
one
thing
where,
where
I
got
the
feedback,
that
people
need
help,
or
some
at
least
some
guidance
and
the
other
topic
was
also
whether
we
want
to
because
we
have
not
the
first
people
who
are
starting
to
roll
out
I,
think
it
was
during
kubecon
when
we
got
the
first
feedback
that
somebody
is
now
running
open
feature
in
production
like
to
also
collect
those
use.
Cases
like
in
a
very
short,
well-defined
format.
D
What
they're
doing
with
it,
how
they're,
using
it
I
mean
I,
would
volunteer
and
I
can
work,
also
like,
together
with
David,
to
collect,
collect
those
use
cases.
It
would
still
be
good
to
have
some
native
speaker
then
eventually
read
over
them
and
well
David.
Technically,
you
are
native,
but
he
grew
up
like
one
year
in
the
US
and
but
to
give
it
another.
D
H
So
you
were
looking
for
people
like
using
Opera
featuring
production.
We
are
using
the
future
and
production
and
it's
all
the
node.js
client,
with
the
poster
profile
that
I
wrote
and
we
are
using
it
just
to
for
future
development
and
up
slacking
so
that
it
also
drives
my
some
of
my
proposals
to
students
looking
for
our
ability
to
use
it.
D
G
And
on
the
on
the
kind
of
like
the
general,
like
best
practices
for
future
Flags,
like
various
very
so
I've
I've
written
random
stuff
over
the
years,
but
like
also
like
the
vendors,
have
some
pretty
good
stuff
out
there
like
split
and
launch
Darkly.
Both
did
a
few
different
ebooks
I.
Think
launch.
Darkly
has
like
a
little
like
kind
of
semi-agnostic
like
best
practice
when
using
feature
Flags
or
something
there's
quite
a
lot
of
material
out
there,
because
luckily,
you.
G
Who's
trying
to
make
money
is
trying
to
kind
of
do
sem
and
kind
of
get
get
stuff
so
yeah.
So
that's
one.
One
thing
we
could
do
pretty
easily
is
just
collect
some
some
resources
to
point
people
to
like
some
further
reading
for
for
just
that
basic
stuff
like
how
do
I
manage
my
Flags?
How
do
I?
You
know
that
kind
of
stuff,
yeah.
D
G
D
G
E
Be
able
to
have
as
well
not
a
huge
amount.
No,
we
I
mean
I,
we
kind
of
I.
Don't
know,
maybe
I've
been
thinking
about
it
too
much,
but
maybe
it's
a
legitimate
question,
but
it
just
people
have
different
approaches
for
that
sort
of
stuff.
What
we
I
mean
we,
we
sort
of
so
we
don't
try
and
tell
people
to
suck
eggs,
but
maybe
we
should
I,
don't
know,
show
them
what
eggs
look
like
or
something.
G
My
experience
from
like
kind
of
similar
to
allies
is
like
actually
pretty
crazy.
It's
like
like
particularly
like.
If
you
live
in
this
world
and
you
think
about
it
all
the
time
there's
some
stuff
that
you
kind
of
just
assume
is
like
yeah
given
but
like
for
people
who
are
literally
there's
a
lot
of
people.
G
E
F
E
E
It's
we
figured
it
out
and
it's
like
six
months
work
to
or
maybe
not
that
much
you
know
so
I
mean
but
yeah
I
I
might
take
a
note
and
try
and
do
something
get
some
simple
content
that
we
could
provide
yeah
the
JavaScript
SDK
that
it
would
be
great,
like
I'd,
be
more
than
happy
to
because
our
front
end
uses
itself
and
that's
JavaScript
react.
We
I'd
definitely
be
up
for
getting
that
open
feature
SDK
into
that
for
production,
because
that
would
be
you
know.
H
C
D
C
And
then
I'll
also
also
add
the
adult
option
page.
That
was
actually
something
I
was
already
looking
into.
One
more
thing
is
there
is
a
group
within
the
cncf
right
now,
for
example,
I
think
Don
and
Don
Foster
is
also
part
of
it,
and
it
is
the
tag
contributor
strategy,
so
they
also
have
other
documentation.
C
Examples
like
when
it
comes
to
contributor
ladders
and-
and
things
like
that,
so
also
have
a
look
at
that
to
see
if
it's,
if
it's
updated,
even
compared
to
the
open,
Telemetry
ones,
because
from
what
we
know,
they're
also
looking
to
change
them
quite
soon
so
or
at
least
change
how
they
structured
something
so
also
I'll,
look
there
and
then
add
in
some
PRS
and
yeah.
Add
you
for
the
review.
That's
kind
of
it.
G
A
I
think
so
yeah
I
mean
it.
We
I
think
this
might
be
a
good
thing
to
talk
about,
maybe
at
the
next
one
as
well,
but
we
did
talk
to
them
when
we
were
out
at
kubecon.
They
seemed
very
interested.
They
kind
of
wanted
to
turn
this
into
more
of
like
a
cncf
like
you
know,
demo
application,
so
you
could
tie
it
into
different
services.
So
from
that
perspective
it
seems
like
a
nice
fit.
A
D
D
A
A
So
yeah,
if
we
can
I,
mean
that's
kind
of
a
minor
one,
they
they
were
interested
I
do
think
it's
worth
doing,
because
then
we
could
even
tie
the
two
parts
together
that
we
talked
about
like
the
Telemetry
data
inside
flag
evaluations
and
they
could
do
like
a
b.
You
know
experimentation
stuff
inside
the
demo
application
there's
a
lot
to
like
about
it,
plus
it's
just
a
like
a
pretty
complex
demo,
application
that
spans
tons
of
different
services.
So
you
could
really
show
some
cool
ways
of
maybe
flag
dependencies
and
all
kinds
of
stuff.
A
A
Cool
we're
basically
running
out
of
time.
I'm,
just
gonna
leave
a
teaser
here
for
this,
then
this
is
based
on
a
conversation
I
had
with
Justin
at
kubecon,
and
basically
he
was
saying
that
some
of
the
teams
that
eBay
really
like
to
let
the
compiler
do
their
work
for
them.
Basically,
and
so
the
idea
being
like.
If,
if
the
sdks
can
have
some
kind
of
awareness
of
what
flags
are
available,
we
can
let
the
the
compiler
kind
of
fighter
battles
for
us.
A
I
I,
really
like
the
idea.
I
do
think
we
need
the
flexibility
of
like
allowing
you
know,
string
flag
identifiers,
but
if
we
can
also
come
up
with
a
pattern
where
you
could
provide
like
a
list
of
known
and
then
you
can
let
the
auto,
like
so
I,
have
an
experiment
going
locally
in
JavaScript.
Javascript
allows
you
to
well
typescript,
specifically,
it
allows
you
to
like
really
ex
yeah
kind
of
take
advantage
of
their
typing
system
and,
like
it's
pretty
cool,
so
maybe
I
can
provide
a
demo
next
week.
A
A
Design
around
it
yeah
exactly
so
I'd
like
to
experiment
with
that,
it
seems
really
really
promising,
because
even
cool
things
like
it
knows
what
the
expected
types
is,
and
so
it
only
Auto
completes
like
the
flags
that
have
the
right
types
and
so
there's
a
bunch
of
cool
stuff.
We
could
get
for
free
with
that.
F
A
C
D
Think
yeah
I
think
that
we
should
still
try
to
get
something
worked
on
asynchronously,
especially
on
the
chart
there,
but
we
can
handle
most
of
it
and
also
like
starting
on
the
roadmap.
Asynchronously
so,
and
people
have
more
flexibility
to
dedicate
some
of
their
time
and
then
for
the
next
meeting.
We
then
try
to
come
up
with
it.
I
think
it's
fine,
okay,.