►
From YouTube: OpenFeature Project Meeting- June 9, 2022
Description
Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit?usp=sharing
OpenFeature website: https://open-feature.github.io/
A
A
A
E
D
E
D
No,
no,
if
it
gets
anything
like
that,
we
just
switch
to
to
a
oh
wow.
I
can't
even
speak
anymore,
a
a
webinar
format
and
where
we
have
the
main
speakers
and
when
someone
wants
to
speak,
they
raise
their
hand
and
we
let
them
in
that's
kind
of
how
everyone
else
has
been
doing
it.
After
a
certain
number
of
people.
E
And
a
couple
of
the
other
meetings
that
I've
been
to
with,
like
the
other
you
know,
sigs
and
stuff
like-
are
way
smaller
than
these,
which
I
was
kind
of
surprised,
but
I'm
sure
there's
some
that
are
large.
But
like
the
app
delivery,
one
was
pretty
small,
the
one
the
meeting
I
went
to
at
least
yeah
I'll.
D
A
D
E
C
Sure
so
hi
everyone,
my
name,
is
marco.
I
used
to
work
with
beat
at
thoughtworks
many
months
ago
and
that's
why
I'm
here
I
shared
about
this
little
meeting
in
a
private
slack
with
ex-colleagues
a
few
weeks
ago.
So
that's
why
I'm
here
feature
flagging
is
something
I've
been
looking
and
using
for
a
few
years.
In
fact,
with
pete
we've
been
discussing
ideas
for
a
few
years
now,
so
I'm
courageous
to
see
what
you
come
up
with
anything
can
help
eventually.
E
D
A
E
Cool
all
right,
pete
is
not
here
so
we'll
circle
back
to
that.
Unless
and
I'm
not
exactly
sure
you
mentioned
something
about
the
cde
foundation
and
potentially
they
said,
would
it
be
worth
pursuing
a
membership?
I
don't
know
much
about
that,
so
we'll
let
him
speak
to
it.
If
someone
does
know
you
know
we
can
talk
about
it
quickly.
Now.
E
Is
it
worth
pursuing?
I
guess
I
guess
that's
the
general
question.
I
don't
really
know
you
know
what
how
it
would
fit
potentially
in
there.
I
think
there
are
some
potential.
You
know
integration
points,
but
not
sure
what
the
benefits
of
like
a
membership
would
be
or
what
that
means
to
pursue.
So,
if
you,
you
know.
G
I'll
have
to
I'll
have
to
look
into
it.
I
think
perfect.
There
are
a
handful
of
like
cicd
tooling,
like
jenkins
x,
and
things
like
that
that
are
projects
in
the
cdf
and
there's.
Certainly
I
I'm
trying
to
think
about
like
what
projects
we
already
have
and
it's
a
lot
of
like
ci
cd
tooling-
and
this
is,
I
don't
know,
I'm
not
entirely
clear
on
the
like
whether
like
our
project
was
right
now
like
headed
towards
cncf,
and
what
does
it
mean
to
be
part
of
both
and
does
that
make
sense?
E
Yeah,
let's,
let's
I
guess
think
about
that.
The
one
thing
that
I
can
mention
regarding
this,
at
least
is
we
submitted
a
paper
for
kubecon
us
and
one
of
the
topics
was
trying
to
integrate,
basically
open
feature,
flag
d
and
captain
actually,
as
part
of
like
a
pipeline
and
and
part
of
the
pitch,
was
really
like.
E
You
know
doing
production
release
it
or
release
testing
effectively,
so
releasing
a
new
feature
behind
a
feature:
flag,
kicking
off
automated
tasks
that
test
that
new
feature
kind
of
quality
gates
in
production.
I
guess
if
you
will-
and
that
was
going
to
be
something
we
try
to
demo.
Of
course
we
don't
know
if
the
talk
was
accepted
at
this
point,
but
that
was
you
know.
We
thought
a
fairly
interesting
topic
to
discuss
so
cool.
I
guess
we'll
circle
back
if
he
joins.
E
He
can
certainly
try
to
elaborate
on
that,
but
I
think
it's
something
that
we
can
just
kind
of
consider-
and
I
think
justin's,
probably
the
perfect
person
to
kind
of
think
about
where
that
could
make
sense
and
if
it
makes
sense
at
all
so
perfect
next
one
is:
was
the
open,
telemetry
semantic
convention
issue?
If
you
don't
mind,
add
a
comment
on
there.
It's
one
of
those
things
where
we
really
won't
get
it
through
unless
we
prove
that
there's
you
know
kind
of
industry,
broad
industry,
support
for
this.
E
If
you
take
a
look
at
the
issue
itself
and
it's
confusing
or
you
don't
understand,
or
you
totally
disagree,
let
me
know
we
can
try
to
talk
through
it
and
you
know
see
if
we
can.
You
know
compromise
effectively.
I
do
think
there's
a
lot
of
value
here,
but
it's
not
mission
critical
we
get
it
merged
in.
E
This
is
just
basically
adding
convention
to
a
span,
so
we
can
just
do
it
ourselves
if,
if
they
don't
merge
it
in
it
doesn't
really
stop
us,
but
I
do
think
it
adds
a
bit
of
awareness
to
feature
flagging
in
the
open
telemetry
world,
which
certainly
benefits
us.
It's
the
you
know
second,
most
popular
project
on
the
cncf,
so
that's
why
it
would
be
nice
to
get
it
in
and
it's
really
just
seems
to
be
in
kind
of
a
pending
state.
E
They
think
they're,
just
waiting
for
more
people
to
kind
of
you
know
add
their
support
to
it,
and-
and
I
think
I
mentioned
in
the
last
call
just
adding
like
the
thumbs
up
emoji
is
useful,
but
they
can't
really
tell
you
know
what
company
or
who
you
are.
It
could
just
be
like
you
know,
a
random
bot
or
something
adding
adding
a
little
emoji
in
there.
So
if
you
just
add
a
little
comment,
that
would
be
super
super
helpful
and
hopefully
we
can
get
that
thing
resolved
quickly.
E
No
worries
we
were
just
talking
about
your
topic
here
and
it
sounds
like
justin
is,
is
very
involved
in
that
project,
so
it
might
be
something
that
we
can
kind
of
chat
about.
You
know
in
the
future
and
see
like
what
makes
the
most
sense,
and
I
don't
know
justin
do
you
have
anything
to
kind
of
elaborate
on
that.
G
No,
I
think
I
think
the
big
question
for
me
is
like
is
cncf
the
right
place
to
have
like
the
feature
flagging
clients.
Certainly
the
flag
d
stuff
makes
a
ton
of
sense
in
cncf,
but
like
does
it
make
sense
to
have
it
in
both?
Does
it
make
sense
to
like
not
split
them
up
or
dual
membership?
We
would
need
to
talk.
G
Yeah,
so
I'm
not
clear
on
what
it
means
to
be
for
a
single
project
to
be
a
member
of
both
and
like
if
we
would
want
to
split
up
client,
libraries
and
flag
the
implementation
which
doesn't
really
seem
like
where
we're
headed.
So
I
wouldn't
push
that
way.
So
we
just
need
to
think
through
what
what
that
governance
structure
would
mean
to
be
part
of
both
projects.
H
Yeah,
the
context
is
that
I
am,
I
was
chatting
to
to
to
liz
fong
jones
about
open
telemetry
and
she
she
just
kind
of
mentioned.
Like
you
know,
it
sounds
like
some
of
this
stuff
is
more
on
the
cd
foundation
side,
and
it's
exactly
the
thing
that
you
were
just
saying
where,
like
like,
the
the
flag
d
stuff,
is
very
clearly
like
cncf
territory,
but
the
the
feature
flagging
stuff
might
be.
H
A
E
E
First,
one
that
we're
gonna
have
to
start
working
on
is
documentation
so
figuring
out
our
strategy.
For
that
you
know
it
seems
like
something
like
a
docusaurus
or
something
seems
to
be
the
most
popular,
but
how
that
could
look,
especially
you
know,
spanning
multiple
repos
and
what
our
strategy
is
going
to
be
for
keeping
this
thing.
You
know
up
to
date
and
all
making
sense.
I
think
once
we
start
getting,
you
know
this.
This
thing
in
an
alpha
state.
E
We
have
providers
available,
we'll
have
to
have
some
kind
of
like
onboarding
docs,
so
you
know
there's
a
lot
of
work
to
be
done
in
the
documentation
or
from
a
documentation
standpoint,
and
it
really
hasn't
been
looked
at
too
much.
So
if
there's
anyone
that
has
any
you
know
background
in
that
or
interest
in
that
any
help
would
be.
You
know
greatly
appreciated
on
that
topic.
E
Next
one
is
the
github
workflows,
so
I
have
a
couple
issues
you
can
see
it
in
in
the
notes.
First,
one
is
just
like
a
stale
issue
bot.
It
seems
like
that's
just
kind
of
a
common
thing
to
have.
I
don't
know
if
anyone
has
any
strong.
You
know
opinions
on
that.
I
know
it
can
be
kind
of
annoying
if
you
open
up
an
issue
and
after
like
60
days
it
just
kind
of
closes,
but
it
may
be
a
nice
way
to
keep.
E
You
know
some
of
the
backlog
relatively
clean
unless
they're,
you
know
active
issues,
so
there
is
an
issue
there.
If
someone
has
a
you
know
a
pro
or
a
con
for
that
approach.
You
know,
let
us
know
there,
but
it's
something.
That's
probably
worth
you
know,
trying
to
wire
it
up,
and
if,
if
someone
feels
like
trying
to
wire
it
up,
take
a
crack
at
it,
I
mean
we
have
it
in
the
community
repo
issues
right
now
same
thing
with
the
first
spot
or
the
first
interaction
bot.
E
I
think
that
could
be
pretty
valuable.
Having
done
a
few
things
in,
like
you
know,
open
telemetry
recently,
my
first
experience
wasn't
great.
It
was
basically
like.
Why
are
you
doing
this
type
of
thing,
and
that
was
kind
of
annoying
for
when
you
spent
time
to,
you
know
open
up
a
pull
request,
so
if
we
could
maybe
make
our
first
interaction
bot
slightly
more
friendly
at
a
minimum.
Just
saying
like
thanks
for
your
contribution,
even
if
we
end
up,
you
know
not
merging
it
in.
E
E
The
last
two
I
don't
do
not
have
issues
for
yet,
but
it
may
be
worth
looking
at.
Some
kind
of
you
know
org
label
strategy,
starting
to
see
how
labels
can
be
used
when
they
kind
of
get
sucked
up
into
the
the
roadmap
itself,
and
so
just
having
some
kind
of
general
like
label
strategy
could
be
really
really
helpful.
I
started
on
it,
but
if
anyone
has
any
like
strong
opinions-
or
you
know,
you
know
previous
projects
where
they
had
some
label
strategy
that
worked
really
well
anything
related.
E
That
would
be
super
super
helpful
and
then
the
last
one
is
it's
probably
an
in
a
similar
thought,
just
issue
templates.
So
if
we
could
find
some
common
issues
that
are
issue
templates,
that
we
would
like
to
support
just
thinking
about
that
as
well
just
so,
we
can
have
some
more
consistency
when
it
comes
to
new
feature,
requests
and
inspect
proposals
and
bugs,
and
anything
else
like
that.
Just
trying
to
get
in
front
of
that
would
be
a
helpful
thing
as
well.
E
I'll
probably
create
just
basically
like
placeholder
issues
in
the
community
section
for
both
of
those
topics,
and
we
can,
you
know
kind
of
chat
about
it
and
assign
it
from
there.
I
have
not
done
that
yet,
though,
so
it's
just
more
of
an
fyi
and
if
that's
an
area
of
interest
for
anyone
could
certainly
use
some
help
on
those
cool.
E
Next,
just
a
quick
update
on
the
playground,
repo,
so
todd
was
able
to
get
the
node.js
sdk
in
a
pretty
good
spot.
It's
nearly
spec
and
playing,
except
for
the
part
where
we
changed
the
spec
a
couple
days
ago.
So
sorry
justin.
I
saw
your
comment
too,
but
the
plan
is
to
get
that
all
expected
compliant
as
soon
as
possible
and
update
the
playground,
but
the
playground
is
up
to
date.
It's
just
technically
not
quite
up
to
spec
because
of
the
changes
we
also.
As
part
of
that
you
can
see.
E
The
next
topic
was
the
contrib
repo.
So
I
just
started
the
process
of
that:
the
contrib
repo
and
it's
kind
of
subject
to
change.
How
we,
you
know
want
to
name
it
and
how
that
should
work,
but
it's
basically
a
place
for
you
know:
providers
to
be
stored,
hooks
to
be
stored,
and
those
will
likely
have
to
be
like
closely
related
to
the
language
that
you're
implementing.
So
the
the
way
I've
named
it
so
far
was
node.js.
E
You
know
start
to
be
added
to
this
repo,
also
different
hooks
so
working
like
the
hotel
hook,
and
maybe
a
logging
hook
and
a
few
others
and
then
making
those
all
available
on
npm
as
well.
So
once
those
are
available,
it's
much
much
easier
to
start
testing
open
feature,
at
least
for
node,
and
if
we
could
figure
out
what
strategy
works
best,
we
can
start
working
on.
E
B
Yeah,
it's
pardon
me.
It's
probably
worth
saying
that
providers
need
not
I'm
sorry,
my
I'm
getting
over
something
here.
It's
probably
worth
saying
that
providers
need
not
define
like
like
the
implemented
in
this
contributory
bow
all
the
time.
I
think
that
likely
vendors
will
want
to
write
their
own
provider.
I
mean
we've
already,
I
think
heard
specifically.
That
split
would
be
probably
writing
their
own
provider,
so
it's
not
like
they
would
have
to
put
their
provider
in
the
consumer's
repo.
B
E
Yeah
and
I
think
that's
going
to
be
part
of
it-
we'll
we'll
probably
start
with
the
node
one,
because
it's
just
kind
of
easier
to
get
started
and
just
figure
out
how
that
should
be
structured
and
look.
You
know
worst
case
like
I
would
say
if
something
like
you
know,
split
decides
to
put
it
in
their.
You
know
separate
location.
We
might
build
just
throw
like
a
readme
in
there
and
just
say,
like
you
know,
under
under
the
providers,
there's
a
split
one
and
you
can
find
the
code.
E
You
know
on
this
other
repo
or
something
like
that.
So
those
are
items
that
we're
gonna
have
to
kind
of
figure
out,
but
we're
gonna
try
to
start
that
over
the
next.
You
know
week
or
so
so
you
know
start
looking
forward.
I
guess
to
the
contribut
repo-
and
that
brings
me
to
the
last
topic
on
my
agenda-
was
just
general
feedback
on
the
roadmap.
E
G
I
think
we
need
to
add
things
to
that
which
amount
to
the
pieces
that
allow
people
to
actually
use
the
thing
like
it
needs
to
be
released
to
to
a
like,
I
guess,
there's
the
spec
and
then
there's
the
sdks,
but
like
we
actually
need
like
a
proper
release
to
the
package
management
systems.
We
need
documentation.
E
Which
I
think
it
was
only
in
like
the
spec
repo,
so
I
can
take
a
look
at
it,
but
I
mean
the
bigger
goal
is
because
it
spans
so
many
repos
figuring
out
how
we
can
be
very
clear
on
what
it
takes
to
get
to
an
alpha
state,
so
I'll
see
what's
available.
If
anyone
else
has
any
ideas
or
experience
or
you
know
has
worked
on
other
projects,
that's
done
this
really
well,
and
I
can
use
that
as
a
reference
or
something
you
know.
E
B
Yeah,
okay,
so
I
think
my
stuff
will
be
pretty
quick.
So
one
thing
that
came
up,
I
we've
talked
about
it
a
couple
times
and
I
think
I
I
can't
remember
if
it
was
at
the
flag,
the
sig
meeting,
alex
kind
of
mentioned
something
about
it
too.
I
agree
with
the
idea
that
we
need
some
kind
of
cross-platform
test
suite
or
test
spec,
so
we're
generating
from
the
from
the
spec
we're
generating
a
json
file.
B
B
Obviously,
it's
a
decent
amount
of
work,
but
that's
that's
the
plan
and
I
think
it's
a
good
thing
to
have
so
I'm
gonna
conditional
on
that
issue
on
that.
If
anybody
has
any
comments
or
ideas,
you
know
feel
free
to
add
something
in
this
doc
or
say
something
now
or
comment
on
the
issue
I'll
I'll
I'll,
create
an
issue
and
put
one
in
this
doc
and
also
paint
the
channel.
When
I
create
it.
B
H
E
Validate
that
your
stuff
is
spec
compliant,
I
think
so.
I
guess
that
is
appropriate.
It's
yeah,
okay,
just
trying
to
figure
out
because
that's
sometimes
the
challenge
is
figuring
out.
What
is
the
best
place
to
put
some
of
these
like
project
related
issues
and
I've
kind
of
gone
back
and
forth
between
spec
and
and
community
in
some
cases,
and
if
you
choose
the
wrong
one,
it
doesn't
get
the
the
same
level
of
interaction.
It
seems,
but
I
think
in
this.
H
H
B
B
They
would
be
testing
yeah,
so
so
harness
harness
literally
implemented,
basically
this
for
their
sdks,
but
it's
not
really
tests.
It's
basically
a
set
of
kind
of
assertions
in
a
well-structured
format,
so
it
gives
some
input
and
it
gives,
and
then
it
gives
an
expected
output
and
so
your
job
in
writing.
A
test
harness
in
a
given
language
is
to
kind
of
parse
that
input
and
then
find
a
way
to
make
sure
that
the
output
matches
the
expected
output.
So
it's
it's
really
not
much
other
than
like
inputs
and
unexpected
outputs.
B
Possible
yeah,
like
I
mean
we
could
we
could
basically
have
like
a
I
mean
you
could
have
a
mock
provider,
so
that
could
be
part
of
it
too.
That's
probably
the
easiest
way.
I
mean
that's
how
I've
been
testing.
My
sdks
is
basically
the
node
sdk
basically
has
a
mock
provider
right
and
every
test
sometimes
grows.
Sometimes
it
returns
this
value
or
that
value
right.
B
So
I
I
think
I
I
think
that
the
goal
would
be
to
define
some
kind
of
schema
for
kind
of
describing
yeah
the
inputs,
the
expected
outputs
and
maybe
the
state
of
the
mock
provider
for
a
given
test.
I'm
not
sure
I
haven't
really
thought
too
much
in
detail
about
it,
but
welcome
to
any
totally
interested
in
any
ideas
or
feedback
on
that.
One.
H
B
Basically,
yeah
based
not
the
providers,
but
the
actual
I
mean.
Maybe
a
similar
thing
for
providers
would
be
interesting
yeah,
but
I
think
it's
really
about
the
core.
Like
you're
saying:
okay,
got
it:
okay,
flag
d,
update,
I
mean
I'll.
This
one's
gonna
be
really
quick,
I
think
but
yeah
we
we've
made
a
lot
of
interesting
progress
on
flag
d.
B
There's,
there's
still
some
decisions
to
be
made
and
stuff
up
in
the
air
about
it,
but
I
I
have
at
least
on
my
local
kubernetes
cluster,
a
really
interesting
end-to-end
demo,
working
with
black
d.
You
know:
reading
values,
loading
them
dynamically
configuration
config
maps,
crd
representing
a
feature
flag
that
propagates
through
the
cluster,
so
yeah,
there's
still
there's
still
like.
B
We
still
got
to
kind
of
reach
some
coherency
because
there's
kind
of
multiple
architectures
being
proposed,
and
it
may
be
that
it
may
be
that
we
have
multiple
architectures,
I'm
not
sure
yeah.
So,
if
you're
interested
in
seeing
how
that
stuff
works,
please
attend
next
week
next
thursday,
our
our
sub
group
meeting
on
flight
d
and
some
of
the
fundamental
stuff-
I
don't
know
if
alex
wants
to
add
anything.
I
know
he's
been
working
a
lot
on
that
project.
F
Yeah,
I
mean
just
to
say
that
I
think
it's
pretty
close,
it's
usable
it
compiles
across
seven
architectures,
it's
pretty
light.
It
has,
you
know,
as
todd
was
saying
a
little
way
to
go
on
the
refinement
of
the
evaluation
engine
integration,
whether
it's
going
to
be
a
done
a
particular
way,
but
I
feel
pretty
good
about
it.
I
think
we're
pretty
much
there
for
kind
of
an
alpha
version.
E
You,
know
json
file
and
then
test
it
locally
and
stuff,
so
like
there's,
some
pretty
interesting
opportunities
for
maybe
end
to
end
tests
or
for
other
other
places
where
this
could
really
shine
so
to
be
determined
some
of
those
pieces.
But
I
think
it
does
lead
to
some
interesting
opportunities
in
the
future.
E
Like
was
teased
earlier.
If
you
have
interest,
definitely
join
the
meetings
next
week
and
we'll
try
to
upload
the
recordings
of
those
as
well.
So
if
you
don't
have
time,
you
know
just
go
ahead
and
review
that,
and
and
we'll
provide
a
really
quick
update
on
these
meetings
as
well.
Without
trying
to
overload
these
meetings
with
with
two
kind
of
distinct
topics,
cool
justin
looks
like
you're
up
next
yeah.
G
On
the
java
sdk,
the
test
suite
has
gotten
out
of
date
with
the
spec,
and
so
I'm
just
like
re-implementing
all
those
annotations
that
I
put
in
along
with
some
validation
that
things
look
right,
because
I
could
not
figure
out
the
gradle
build
issues.
I'm
doing
this
in
a
janky
python
script
with
regexes.
G
So
we'll
see
how
that
goes.
My
hope
is
to
have
the
java
sdk,
like
production,
ready
by
end
of
july,
I'm
just
traveling
a
lot
this
month,
and
so
I'm
not
able
to
put
a
ton
of
focus
on
it,
but
I
want
to
get
it
for
use
internally
for
production
use
in
end
of
july.
So
let's
see
vendor
roadmap,
so
we
should
probably
be
tracking,
like
the
vendors
that
are
going
to
launch
with
this
thing
and
whether
or
not
they
have
back
ends
for
various
languages.
G
So
if
we're
gonna,
if
we're
gonna
launch,
presumably
with
python
javascript
in
java,
then
we
should
have
some
form
of
tracking
where
we're
like
cool
launch.
Darkly
here
are
your
three
like.
Are
you
going
to
release
these
and
if
so,
when?
Okay
split
like
same
thing,
some
sort
of
dashboard
and
and
just
like
understanding
of
who's,
going
to
be
writing
what
software.
E
Yeah,
no,
that
makes
sense.
I
think
that
contribs
repo,
that
I'm
going
to
start
or
have
started
already
but
just
haven't
released
it
yet
should
help
in
that,
and
hopefully
we
can
get
some
commitment
from
the
different
vendors
and
I
to
I
guess
to
answer
your
first
question
like
the
the
languages
that
we're
targeting
right
now.
All
of
them.
You
know,
basically
support
these.
If
we
start
getting
number
obscure
languages,
we
may
run
into
problems.
But
the
couple
that
we're
talking
about
right
now
is
is
pretty
well
supported
and
but
figuring
out.
E
B
I
was
just
gonna
say
I
think
I
think
having
commitment
is
really
the
important
thing.
That's
a
great
point:
justin.
I
think
that
it
would
kind
of
be
a
bit.
It
would
be
a
bit
of
a
flop
if
we
kind
of
you
know
had
had
like
an
official
announcement
or
alpha
released
for
various
languages
and,
like
you
know,
made
a
bit
of
a
big
deal
about
it,
but
there
were
no
existing
providers
and
there
was
no
buy-in
vendors.
That
would
feel
feel
like
a
bit
of
a
flop.
B
G
So
we
allow
the
ability
to
add
a
structure
to
an
evaluation
context
and
structures
aren't
necessarily
serializable
in,
like
the
java
sense
of
the
word
or
might
have
cyclical
json
objects
or
any
number
of
other
things.
And
so
I
think
what
that
results
in
is
us
throwing
exceptions
when
you
add
things
to
a
context.
B
B
They
already
behave
like
you
kind
of
explained,
so
there's
there's
a
few
sdks
that
support
objects,
and-
and
I
I
you
know-
I
don't
mention
any
by
name
but
like
I
ran
into
the
exact
issue
you're
talking
about
so
I
I
had
an
unserializable
object
that
had
a
reference,
a
referential
cycle
in
it
and
when
I
threw
that
into
the
context,
I
just
got
an
error
and
my
value
defaulted.
So
basically
it
did
exactly
what
I
kind
of
would
expect
the
open
feature
to
do
so.
G
B
H
B
G
B
Well,
maybe
I'm
missing
something,
because
I
I've
been
spending
a
lot
of
time
in
go
language
and
and
javascript
and
unless
in
java,
but
is
there,
is
there
a
reason
why
serialization
needs
to
occur
at
the
point
that
that
something's
added
to
the
context,
if
serialization
only
happens
during
evaluation?
Is
that
a
reasonable
solution,
or
I.
H
I
mean
you
could
do
something
really
wacky
like
try
and
serialize
it
and
then
like
make
a
note
that,
like
this,
is
terrible
like
it's
broken
and
then
like
at
the
point
that
you
evaluate
just
like
say
like
oh
yeah.
This
is
a
broken
context,
so
I'm
gonna
just
always
return
like
I'm.
I'm
sure
that
there's
I
bet
that
there's
ways
to
do
it
either
way.
I
think
the
question
is
more
like
what
would
we
want
the
behavior
to
be?
H
It
does
seem
pretty
like
my
like
my
because
of
that,
like
I
would
lean
towards
like
failing
fast
and
then
I
don't
know
it
feels
like
such
a
cop
out
but
like
having
like
an
option
of
like
configuring
it
or
something
and
saying
like
if
you
really
really
want
to
never
for
an
exception,
then
we'll
do
something
about
it.
But
that
feels
like
a
total
cop-out
like
and
puts
a
lot
of
extra
burden
on
implementing
the
sdk.
H
But
like-
and
I
think
we've
talked
about
this
before
but
like-
I
think,
also
think
through
the
opposite
right
you
put
in
something
that
should
be
stopping
a
feature
from
being
evaluated
or
not,
but
you
you've
messed
something
up.
So
now
that
context
is
broken,
and
now
everything
is
returning
a
default
value
which
hasn't
been
turned
on
for
two
years,
and
you
know
you
get
like
a
night
capital
scenario
and
the
the
company
loses
a
million
dollars
a
second
or
whatever,
like
that's
like
a
total
exaggeration
yeah,
but
it
is
definitely.
G
Yeah,
I
think
the
question
is
like
whether
like
would
you
fail
fast,
like
my
concern,
is
in
a
world
where
we
have
dynamically
built
context
and
you're,
taking
like
data
from
provider
x
and
shoving
it
into
your
context
like
that
being
malformed
in
some
way
and
the
result
being
that
at
3
a.m?
Now
your
thing
starts,
throwing
exceptions
like
if
we
could
say,
like
exceptions
happen
in
development
time
and
once
you
get
it
right
there
like
production
will
be
safe.
Then
I
feel
really
good
about
throwing
exceptions,
but
I'm
just
not
sure
that
that's.
H
Third,
a
third
path.
Maybe
is
we
say
that
we
ignore
that
context
so,
rather
than
returning
a
default
value?
If
you
inject
context
that
can't
be
serialized,
then
it's
ignored
and
we
logs
stuff,
and
that
might
be
like
a
comprehensive.
The
thing
I
really
worry
about
is
the
like
reverting
to
a
default
value,
I
think,
is
actually
can
be
a
really
treacherous
thing
to
do
so
ignore
like
if
you
inject
kind
of
crappy
context,
then
it's
ignored
feels
like
maybe
it's
like
the
least
terrible,
like
alternative.
G
G
H
E
That
would
be
a
a
weird
there's,
a
lot
of
situations
where
default
values
could
come
back.
I
guess
so
like
I
get
it,
but
it's
like
you
know
like
I.
I
don't
think
you'd
probably
want
to
say
like
default
pass
or
like
super
super
dangerous.
Otherwise
you
should
be
removing
that
feature
flag.
I
know
it's
a
bigger
problem
and
sort
of
out
of
scope
of
open
feature
itself,
but,
like
maybe
that's
part
of
like
the
education
part
of
it.
It's
like.
G
G
B
Though
I
mean
even
this,
education
like
calling
out
the
default
should
be
safe,
because
you
know
people
are
going
to
use
feature
flags
for
legal
things
right
like
to
to
pete's
point
like.
What's
worse,
a
500
or
you've
accidentally
allowed
access
to
something
in
your
application.
That
is
not,
maybe
maybe
you
needed
some
legal
hurdle
cleared.
Maybe
it's
like
now.
You
have
a
hipaa
violation
or
something
like
that.
B
Like
there's
a
lot
of
horrible
things
that
could
that
could
potentially
happen
in
worst
case
scenarios,
so
part
of
it
might
be
that
the
doc
the
default
should
always
be
sane
and
safe
right
so-
and
I
mean
even
for
the
client
side-
something
that's
come
up
a
lot
lately
is
that
a
lot
of
vendor
a
lot
of
vendor
domains
are
blocked
on
the
client
in
yeah,
by
block
list
by
by
dns
black
holes
and
stuff,
like
that.
So
in
that
case,
you're
going
to
default.
F
Just
to
play
devil's
advocate
like
there's.
Typically
an
80
20
rule
right
in
most
things
in
life,
you'll
find
80
percent
of
people,
like
your
opinion
on
how
things
should
look,
but
they'll
always
be
the
vocal
20
who
say
why
the
hell
did
you
do
this,
so
maybe
building
a
modular
composable
system
where
we
can
actually
augment
the
specification
to
certain
companies
and
individuals.
Requirements
might
be
something
we
think
about
as
a
long-term
goal,
because
you
can't
make
the
assumption
that
one,
like
one
way
of
doing
things,
is
going
to
fit
everyone
yeah.
H
E
H
H
Partly
because
it's
like
tapping
into
all
of
that
great
wisdom
and
knowledge
and
like
historical
arguments,
but
also
because
they're,
the
ones
that
eventually
have
to
implement
these
specs?
So
if
we're,
if
we
come
up
with
something
that
was
like
in
our
opinion,
is
the
right
way
to
do
it,
but
then
it
makes
it
harder
for
every
vendor
to
implement.
Then
that's
kind
of
got
ramifications
too
right.
So.
E
Yeah,
I
think
I
think,
that's
a
good
idea,
a
great
idea.
Actually,
where
should
we
put
it
because
we
could
put
if
we
put
it
like
a
you
know
or
read
me
somewhere
or
a
markdown
page
somewhere,
we
could
basically
just
ask
and
then
they
could
say,
launch
darkly's
opinion
is
this
or
whatever,
and
it
would
be
very
clear.
You
know
what
the
different
vendors
think
of
different
topics
so
or
maybe
doug
or
someone
else
from
you
know,
launch
darkly.
Couldn't
you
know?
I
H
I
could
take
like
an
action
item
to
try
and
figure
out
that
broader
thing
of
like.
What's
the
like,
how
can
we
kind
of
like
draw
on
the
knowledge
of
the
of
the
various
vendors
and
kind
of
put
together
like
a
advisory
council
or
something
else
something
where
something
like,
even
if
it's
just
like
literally
just
a
list
of
email
addresses
where
we
can
just
email
them
and
say
hey,
we
had
this
question
and
kind
of
start
a
conversation
going.
It's
worth
a
try.
F
Yeah,
I
think,
in
the
roots
of
having
it
as
almost
like
an
advisory
board
right
you
get
sort
of
four
or
five
individuals
and
you
just
we
don't
so
much
just
give
them
a
carte
blanche
or
give
us
your
laundry
list
of
things
that
you
think
about,
but
more
like
here's.
Here's
a
design
that
we're
thinking
of
doing.
I
Yeah,
I
think
one
thing
that
dan
and
I
have
been
discussing
is
just
a
better
understanding
of
what
the
rules
and
engagement
are
for
vendors
as
it
relates
to
this
project.
I
think
across
things
like
public
speaking
opportunities,
promotional
opportunities
making
some
of
these
recommendations
on
the
technical
perspective,
I
think
it
would
be
helpful
for
us
to
have
a
good
sense
of
what
you
all
believe
is
best
for
the
community.
I
We
can
obviously
push
as
much
as
we
want,
but
we
want
to
make
sure
that
we're
doing
it
in
a
way
that
doesn't
come
off
as
being
self-promotiony
or
salesy
or
any
of
that
type
of
stuff.
So
that's
one
thing
dan
and
I
were
actually
just
chatting
about
last
week,
and
it
might
be
a
good
way
to
think
about
this
vendor
council
is
this:
is
the
rules
of
engagement
for
the
people
that
have
commercial
projects
in
the
space.
A
H
H
I
think
it
might
be
more
nuanced
than
that,
because
I
I
think
that
there's
gonna
be
the
client-side
server-side
aspect,
and
I
almost
think
that
for
some
of
the
vendors
there's
a
tech
there's
like
a
platform,
specific
aspect
like
I
can't
remember,
I
think
I
was
looking
at
the
launch
darkly
like
the
read
the
repo
list
and
there's
and
it's
more
detailed
than
just
like
this-
is
the
javascript
client
side.
It's
like
this
is
the
react
thing
this
is
or
whatever
thing.
So.
G
H
I
think,
like
the
client
client-side
server-side
split
is
like
a
very
very
is
a
pretty
big
split.
I
am
supe.
I
am,
I
think
I'll
probably
get
proved
wrong,
but
I
would
love
it
if
we
could
figure
out
a
way,
so
the
sdk
itself
was
not
client-side,
specific
or
server-side
specific.
I
think
that's
feasible
that
you
could
have
like,
rather
than
it
being
the
node
sdk.
H
If
we
could
get
to
that,
it
would
be
awesome
because
I
think
that's
the
dream.
That's
like
the
dream.
In
that
kind
of
diagram
I
put
in
my
blog
post
of
like
having
just
one
implementation
of
like
the
core
sdk
and
then
being
able
to
do
like
client-side,
specific
stuff
and
react
specific
stuff
or
whatever,
without
having
to
have
like
all
of
the
stuff
in
the
middle
duplicated.
So.
E
Yeah
that
makes
sense
it
part
of
the
yeah.
Definitely
the
focus
has
been
server
side,
although
we
had.
I
had
talked
to
a
few
people
about
starting
to
investigate
client
side
and
just
kind
of
what
the
nuances
are
there.
So
hopefully
we
start
seeing
a
little
bit
of
you
know:
action
in
that
area
as
well,
but
just
trying
to
stay
relatively
focused.
E
H
Did
I
did
start
like
some
experiments
with
the
with
getting
like
a
just
a
really
simple
react.
Javascript
I
talked
to
todd
about
it
a
little
bit,
I
think,
like
I
ran
into
some
issues
where
I
think,
like
the
just
the
the
sdk
wasn't
quite
like
ready
to
be
to
be
plugged
in,
but
I
think
maybe
it's
at
a
slightly
different
spot
now.
So
I
might
kind
of
take
another
run
of
that
in
my
copious
spare
time
and
see
if
I
can
plug
it
in
to
plug
it
into
something.
E
B
H
Yeah,
I
think
the
main
work
would
be
implementing
the
would
be
building
a
provider
for
like
a
client-side
provider,
because,
like
I
I'd
hoped
that
probably
pretty
naively
I'd
hoped
that
I
could
just
take
like
the
split
provider
or
launch
rp
provider
and
just
plug
it
in.
But
but
we've
we've
used
the
no
the
back
end
versions,
the
server-side
versions
of
the
providers,
and
they
don't.
They
don't
work
in
client-side,
because
they're
not
supposed
to
so
yeah
a
little
bit
of
work.
There.
E
Looks
like
we
have
quite
a
few
different
action
items
done
for
for
next
week,
yeah
and
and
review
the.
I
guess,
call
for
help
if
there's
any
error
areas
that
you
find
interesting.
Let
me
know
I'll
definitely
try
to
take
a
look
at
those
on
the
roadmap
and
make
sure
that
we
have
everything
up
to
date,
and
you
know
again,
if
you
feel
like
something's
missing
or
should
be
a
higher
priority,
either
take
it
on
yourself.