►
From YouTube: OpenFeature Project Meeting, May 12, 2022
Description
Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit#heading=h.wh8mkiotns4b
OpenFeature website: https://open-feature.github.io/
A
A
C
B
Next
week,
if
you
could
do
me
a
favor,
could
you
please
because
it
might
actually
work
a
bit
faster
like
all
of
those
who
are
wanting
to
participate?
Please
share
one
email
address
that
we
can
drive
to
communication
because,
via
slack
in
the
cncfs
like,
yes,
you
cannot
like
notify
the
channel
directly
or
on
the
issue
was
like
rather
slow,
and
I
think
we
will
need
to
access
in
real
time.
Yes,
kevin.
If
you
just
send
a
request
for
access
I'll
grant
it
it's
just
locked
because
we
haven't
published
it
yet.
B
B
E
B
Already
started
because
I
think
we
really
have
to
get
the
press
release
or
our
blog
or
whatever
people
want
to
announce
like
really
get
it
done
today,
because
it's
thursday
and
we
should
like
really
have
it
very
quickly.
So
the
first
thing
you
should
do
at
like
really
provide
the
email
of
who
we
should
include.
B
B
F
B
B
Yeah
so
yeah,
I
think
the
important
one
is
really
the
quotes
that
you
want.
Others
be
able
to
use
as
part
of
this
one
command
from
peter
still
has
to.
I
have
to
work
into
the
text.
I
will
do
this
today,
yeah
and
just
please
also
add
your
name
for
contact
details
that
we
have
a
very
fast
turnaround
now
on
this
one
and
yeah
agreement.
When
are
we
going
to
announce
it.
B
Usually,
actually
later
might
be
better
simply
because
many
of
you
will
have
especially
those
obviously
from
feature
flagging.
Companies
might
have
press
briefing
setup
anyways,
where
you
want
to
mention
it
and
then,
after
the
proper
announcement,
I
think
the
dyna
twist
team
is
currently
looking
into
the
20th,
which
would
be
friday,
maybe
thursday
just
but
we
can
also
do
this
via
email.
So
we
will
propose
one
date,
and
this
is
where
we,
then
the
blog
should
go,
live
and
timing-wise.
B
B
B
B
May
20's
or
19th
I
think
both
would
definitely
work,
but
it
allows
everybody
to
run
their
press
briefings,
but
they
also
might
want
to
mention
it.
They
can
brief
their
press
contacts
that
they're
going
to
announce
something,
and
then
it
would
be
the
end
of
the
week,
and
I
think
it
also
gives
us
the
most
headway
for
those
of
you
who
have
still
internal
conversations
to
be
had
here.
B
C
B
I
just
have
to
point
out:
please
add
your
contact
details.
We
have
for
most
of
you,
we
don't
have
the
email
addresses
the
flags
means
people
have
added
them,
but
please
add
them.
Otherwise
we
can't
reach
out
to
you
and
can't
coordinate
there
and
I'll
bother
you
a
bit
at
the
end
of
the
meeting
again
with
details.
Yes,
but
then
I'll,
let
you
jump
right
to
the
more
technical
topics,
but
this
is
now
really
time
sensitive.
That's
why
I'm
pressing
really
hard
on
getting
this
done
right
now,.
E
All
right,
thanks
always
looks
like
there's
a
handful
of
newcomers.
It's
just
I'm
not
sure
if
it's
all
in
alphabetical
order
here
or
not,
but
if
people
want
to
quickly
just
introduce
themselves
if
you're
new
to
the
meeting
and
then
we
can
go
ahead
and
get
started,
I
guess
I'll
hand
it
off
to
tom.
First,
I'm
going
to
go
ahead
and
just
yeah
anyone
else.
H
G
J
Cool
yeah
I
invited
I
won.
I
am
so
beautiful
by
the
community
based
in
london
called
topical
and
I'm
one
of
the
maintainers
of
the
openslow
specification
and
I'm
mainly
interested
in
seeing
how
I
could
what
this
is
about
and
how
I
could
make
it
work
with
the
post
hoc
product
analytics
and
future
flex
solution,
open
source
solution,
perfect
all
right.
Well,.
E
Thank
you
all
right,
so
we
can
kick
it
off
now.
The
first
thing
I
wanted
to
chat
about
real
quick
was
just
the
project,
roadmap
and
workflows,
really
I'd
kind
of
like
to
get
everyone's
feedback
on
how
we
want
to
formalize
that
I
I
have
some
ideas
right
now
of
of
what
likely
should
be
done,
for
you
know,
alpha
beta
and
kind
of
release
and
ga
release
stages,
but
how
we
want
to
basically
talk
about
that
as
a
community
and
decide
which
are
considered
priorities.
E
My
proposal
would
be.
I
can
open
up
a
github
issue
just
listing
out
the
different
major
topics
that
need
to
be
addressed.
If
we
can
come
to
some
reasonable
consensus
there,
I
can
either
create
issues
associated
with
each
of
those.
You
know
high
level
objectives
or
create
a
github
roadmap,
I'm
not
exactly
sure
what
people's
preference
are.
You
know
in
that
regard
or
which
one
works
better
than
the
other
for
better
or
worse.
I
have
a
lot
more
experience
with
jira
than
some
of
the
github
management
tools.
E
G
E
Or
maybe
yep
that
sounds
great
yeah
and
if
anyone
else
has
any
ideas,
I'll
try
to
start
with,
probably
a
github
issue.
I
think
that
makes
probably
the
most
sense
to
just
quickly
dump
out,
like
all
of
the
high
level
topics,
I'll
post
it
in
the
slack
channel,
we
can
go
back
and,
for
you
know,
kind
of
collaborate
there
and
once
we
kind
of
define
what
makes
the
most
sense
we
can
either
do
you
know
issues
or
or
roadmaps
or
whatever
the
preference
is
there,
and
that.
F
E
E
F
G
For
github,
we
cannot
use
projects
better,
so
one
which
allows
to
provide
multiple
views,
so
we
can
create
slices,
for
example,
technical
side
for
the
community
for
marketing
can
outreach
and
still
have
a
single
roadmap.
So
we
have
recently
created
a
prototype
and
captain
of
moving
to
projects
better
and
yeah.
We
can
work
with
mike
and
with
our
own
presentation
as
well.
E
Yeah
perfect:
let's
sync
up
next
week,
then
we
can
kind
of
go
through
that,
but
I
think
having
that
higher
level
roadmap
would
be
very
beneficial
for
everyone
here
to
be
on
the
same
page,
and
I
know
what
we're
currently
working
on
so
I'll,
hopefully
have
an
update
by
the
next
community
sink
and
then
I'll
try
to
try
to
work
through
some
of
these
as
an
issue.
So
we
can
kind
of
you
know
asynchronously
collaborate
on
that
cool
next
topic
was
open
telemetry.
E
E
They
did
kind
of
mention
not
sure
how
impactful
this
will
be,
but
in
the
pull
request
itself
they
mentioned
that
they
they
needed
to
determine
if
it
was
something
they
even
wanted
to
merge
in.
So
there
is
a
bit
of
kind
of
discussion
about
if
this
is
potentially
out
of
scope.
I
do
not
think
it
is.
I
think
it's
actually
very
valuable
in
a
distributed
trace,
but
if
you
could
take
a
look
at
the
proposal,
add
feedback.
You
know
github
reactions,
whatever
to
kind
of
show
that
there
is
a
broad.
E
You
know
interest
in
this
topic.
If
you
have
any
questions
specifically
on
on
what
this
provides,
you
know
certainly
reach
out
to
me
or
even
better
asking
that
issue,
so
we
can
clarify
any
anything
that
maybe
is
a
misunderstanding
there,
but
I
I
did
try
to
lay
out
like
how
it
would
look
like
in
in
zipkin,
which
then
would
apply
to
you
know
basically,
most
of
the
observability
vendors
that
are
spec
compliant.
E
Cool
next
one
is
the
open
feature
brand
refresh,
so
we
talked
about
it
a
little
bit
at
the
last
community
sync,
but
after
kind
of
the
the
hacker
news
post
came
out,
we
saw
very
clearly
there
was
some
confusion
around
some
of
the
messaging
I've
been
trying
to
look
at
that
situation
a
bit
and
part
of
that
was
trying
to
define
the
the
mission
and
vision.
So
I
did.
I
do
have
a
pull
request
open
for
that.
I
appreciate
the
the
comments
so
far.
E
E
I
also
have
a
couple
more
proposals
for
the
logo.
It
is
not
something
that's
likely
going
to
blow
your
mind
at
this
point
if
anyone
is
a
graphic
artist
or
no
graphic
artist,
that
wants
to
help
out.
Certainly
let
me
know,
but
I
I
like
it
better
than
the
light
switch,
and
so
I
think,
unless
I
get
some
serious
pushback,
we
may
just
go
forward
with
one
of
the
proposals
just
to
have
something.
E
E
There's
a
couple
other
variations
too,
but
they're
all
kind
of
playing
with
the
same
same
design
related
to
that
I
called
in
a
favor
with
one
of
my
buddies
he's,
helping
to
refresh
the
website
not
a
whole
lot
to
show
at
this
point,
but
I'm
hoping
to
have
something
maybe
later
today,
so
I'll
post
it
in
the
slack
channel.
You
guys
can
take
a
look
at
it.
E
E
Mainly
so
we
don't
have,
you
know
outdated
copy
there.
We
have
to
maintain
it
multiple
places,
things
like
that.
It's
something
that
we
can,
of
course
improve.
You
know
over
time
if
we
need
to
add
more
more
content
to
the
website.
We
certainly
can,
but
I
think
at
this
stage
it's
nice
to
just
get
the
basic
premise
across
on
the
site
and
then
lead
them
back
to
github,
where
or
most
of
the
actions.
G
E
J
E
What
the
best
approach
is,
but
certainly
don't
want
to
have
a
bunch
of
different
places
that
we
have
to
maintain
for
you
know
for
life.
Basically,
so
if
we
can
try
to
have
a
single
source
of
truth
and
in
most
cases
I
think
that
would
be
beneficial
here
and
then
the
last
thing
is
the
kubecon
t-shirts
came
in.
If
you
are
interested,
they
looked
like
this.
This
is
the
dark
version.
E
We
have
a
white
version
which
is
like
the
inverse
and
actually
the
toggles
flip
to
the
other
direction,
which
is,
I
don't
know
I
thought,
was
kind
of
fun,
so
that
was
kind
of
a
cool
little
thing
that
came
in
if
you're
going
to
be
in
valencia.
Let
me
know
what
your
t-shirt,
size,
preference
preferences,
they're,
they're,
u.s
sizes
and
I'll
make
sure
to
save
you
one
if
you're
not
going
to
be
there.
Let
me
know
anyways.
If
I
have
extras
I'll
I'll,
you
know
set
some
some
aside
for
the
next
time.
E
C
C
That's
a
definitely
an
important
feature,
really
cool
feature
that
I
think,
makes
open
feature.
You
know
adds
a
lot
of
utility.
So
thanks
a
lot
because
justin
abrams
actually
headed
that
up,
we
had
as
usual
a
lot
of
participation
from
the
community.
That's
all
emerged
now
feel
free
to
take
a
look
at
it.
We
also
have
the
evaluation
context
aspect
of
the
spec
there's
a
pr
open
for
that.
C
Please
go
ahead
and
take
a
look
at
that
that
one's
not
too
long,
it's
not
too
complicated.
We're
not
talking
about
any
of
the
really
fancy
or
complicated
context,
implicit
context,
propagation
that
we've
kind
of
touched
on
before
via
you
know,
continuations
or
thread
local
storage,
or
anything
like
that.
It's
really
just
the
structure
of
the
context,
objects
and
the
first
class
kind
of
fields
that
are
going
to
be
defined
there,
so
they
could
be
easily
mapped
to
providers
that
need
those
fields.
C
Yeah,
so
what
what's?
Next
events
are
probably
likely
the
last
piece
for
for
a
an
alpha
or
a
beta,
depending
on
how
important
we
kind
of
think
they
are.
I
know,
pete,
who
doesn't
seem
to
be
here
today,
was
specifically
really
concerned
about
events
for
the
client,
which
I
think
makes
a
lot
of
sense
for
specifically
for
javascript
clients.
Do
they
yeah
web
or
not.
So
I
agree
with
that.
C
E
E
Quick
jump
into
there,
the
the
on
ready
event
is
something
that
we've
sort
of
masked
in
the
current,
like
demo
environments
right
now
in
in
in
a
sort
of
hacky
way.
If
you
want
to
look
at
the
the
playground
repo,
you
can
see
what
we're
doing
so.
It
may
be
important,
but
to
todd's
point
it
may
not
be
something
that's
absolutely
required
for
like
an
alpha
spec,
but
very
likely
important
before
ga
at
least,
and
so
we
can
kind
of
define
the
the
importance
of
that
you
know.
C
C
Cool
okay,
so
the
next
thing
I
wanted
to
talk
about
was
was
the
playground.
So
we
had
a
repository
called
sdk
research.
Previously,
that's
been
renamed
to
playground
and,
as
the
name
suggests,
the
idea
now
is
that
you
can
kind
of
test
out
new
providers.
You
can
test
out.
You
know
the
existing
providers
we
have
and
just
kind
of
play
around
with
your
computer
concepts
there.
C
C
And
then
we
can
open
the
ui,
so
I'm
just
going
to
go
through
it.
It's
basically
a
has
a
guided
kind
of
tour.
I'm
just
going
to
read:
what's
here,
you
guys
can
pull
it
on
your
own
if
you'd
like
to
see
it
or
stay
tuned
for
the
recording.
Welcome
to
the
open
feature
demo.
This
is
the
landing
page
for
our
fictional
killer,
app
fibonacci
as
a
service.
First,
a
few
things
about
open
feature,
and
this
demo.
C
Open
feature
defines
abstractions
that
allows
the
use
of
a
single
api
to
evaluate
feature
flags,
no
matter
where
your
feature
flags
are
managed,
a
sas
vendor
an
in-house
implementation,
open
features,
cloud
native
solution
or
even
a
file
for
this
demo.
We
get
flag
definitions
from
a
simple
json
file
which
you
can
modify
with
this
embedded
editor.
C
Let's
get
started
learning.
How
open
feature
is
helping
the
authors
of
our
fictional
service
manage
this
landing
page.
The
company
has
been
in
the
process
of
changing
the
name
of
our
app,
but
legal
hasn't
quite
finished
the
process.
Yet
here
we've
defined
a
simple
boolean
flag,
new
welcome
message
that
we
can
use
to
update
the
name
instantly
without
redeploying
our
application,
use
the
editor
to
change
the
state
of
the
boolean
new
welcome
message:
flag
to
enabled
click,
to
enable,
I
add,
to
enable
click
anywhere
outside
the
editor
to
apply
the
change.
C
Great
so
now
you
see
the
name
changed
up
here.
Now,
let's
look
into
a
flag
with
an
associated
strength
value.
The
design
team
is
certainly
experimenting
with
new
color
palettes.
Let's
change
our
landing
pages.
Color
use
the
editor
to
change
the
default
variant
of
the
hex
color
flag
to
match
any
of
the
defined
variants.
So
it's
blue
right
now,
we'll
just
do
red
snazzy
choice.
Maybe
your
designer
yourself
feature
flags
provide
a
great
means
of
allowing
team
members
who
aren't
engineers
to
control
selected
aspects
of
application
characteristics.
C
Turns
out
calculating
fibonacci
at
n,
recursively
isn't
exactly
efficient,
luckily
top
minds
at
our
company
have
found
a
more
efficient
algorithm
for
calculating
fibonacci
and
it's
experimental.
So
we
only
want
to
allow
employees
to
test
it.
Let's
see
how
open
feature
can
help
with
that
click
here
to
log
in
enter
an
email
ending
with
at
bass.com
and
click
login.
So
let's
do.
C
C
We
should
enable
this
for
all
users
soon
and
you
can
see
there's
a
more
complicated
flight
here
that
actually
defines
some
very
basic
rules
and
that's
what
we
just
saw
demoed
thanks
for
taking
this
quick
tour
of
open
feature
and
in
the
latest
version
which
I
I
pushed,
but
I
didn't
demo
it
here.
We
have
an
additional
panel
here,
an
additional
tour
step
here
that
simply
says
hey.
C
C
C
I
think
I
think
that's
it.
So
if
anybody
has
any
questions
about
this
feel
free
to
ask
them
now,
you
can
definitely
pull
it
yourself.
It's
all
in
the
readme.
It's
relatively
easy
to
set
up.
It's
just
a
couple
steps,
at
least
if
you
want
to
get
the
json
provider
working,
which
is
which
is
good
just
for
understanding
some
of
the
key
concepts,
and
then
you
can
hook
it
up
to
any
provider.
We
have
to
find,
I
think.
D
C
Yeah
I
mean,
if
you
have
more,
if
you
have
more
thoughts
on
how
we
can
kind
of
qualify
that
I'm
I'm
totally
open,
I
it
is
a.
It
is
confusion
that
I'm
concerned
about.
So
I
don't
want
anybody
to
mistake.
You
know
this
json
file
provider
as
as
what
open
feature
is
right.
It's
just
it's
just
a
demo,
it's
just
one
provider
of
many.
I
think
that's
kind
of
the
point
you're
trying
to
make.
A
I'll
probably
take
it.
Thank
you
yeah.
So
sorry,
just
I
think
this
is
awesome.
Yeah
my.
I
wonder
whether
the
initial
json
provider
might
be
easier
for
people
to
understand
if
it
was
like.
If
maybe
there
was
like
a
simple
version
and
then
a
more
advanced
version,
the
one
that,
like
maybe
just
had
a
boolean
and
just
had
a
value,
because
this.
F
C
So
that's
a
good
point.
What
I
tried
to
do
was
kind
of
highlight
the
different
parts
here
with
the
with
this
mask
functionality,
so
so
like
this.
But
what
we
probably
could
do
to
your
point
is
actually
dynamically
add
the
text,
so
we
could
start
with
just
the
boolean
flag
and
then
maybe
add
the
hex
color
flag.
We
could
do
that.
Maybe
if
that,
if
that
partially
addresses
kind
of
what
you're
suggesting
I
did
I
was
trying
to.
C
I
was
kind
of
trying
to
strike
a
balance
between
not
making
things
over
complicated,
but
also
showing
some
of
the
more
powerful
features.
One
of
the
things
that
came
out
of
this
hacker
news
post
was
that
people
think
of
feature
flags
as
static
and
on
or
off
well,
as
some
people
do,
because
that's
the
implementation
they're
familiar
with
they're,
not
familiar
with
the
more
complicated
like
user
targeting
stuff.
So
I
want
to
show
that,
but
also
not
overwhelm
people.
A
A
A
F
F
That
the
json
provider
is
going
to
get
confused
with
you
know
what
is
available.
Otherwise,
and
if
you
add
sections
as
it
goes
along
the
demo,
it
almost
feels
like
it's
reinforcing
the
json
provider
for
it,
where
you
could
do
something
like
just
key
values
to
start
and
have
like
just
someone
saying
that
advanced
demo
that
does
more
targeting
or
something.
D
J
D
E
To
provide
a
bit
more
context
here,
one
of
the
problems
to
some
extent
is
like
the
entry
barrier
was
a
bit
high
like.
If
you
had
to
to
test
it
out,
you
know
sign
up
for
a
launch
darkly
or
a
flagsmith
account
or
whatever,
and
then
you
had
to
manually
create
all
of
the
flags
and
stuff
we
wanted
to
kind
of
lower
the
barrier,
but
still
show
the
flexibility.
E
If
you
are
interested
the
playground,
I
did
take
a
crack
at
a
very
simple
flag:
config,
like
json
schema,
so
this
is
actually.
It
runs
through,
like
a
very
basic
schema
for
for
validation
here,
but
yeah
the
point
still
stands.
Perhaps
we
could
even
potentially
have
something
above
that
shows
like
the
provider
being
used
and
you
could
literally
potentially
even
dynamically,
adjust
that
with
like
a
drop
down
or
something
that
could
be
an
option.
C
That's
a
good
point
like
that's
something
that
we
talked
about
earlier
and
I
actually
don't
think
it
would
be
crazy
hard.
So
we
could,
for
instance,
this
might
make
things
a
little
bit
brittle,
but
we
could,
we
could
add,
like
a
drop
down
or
icons
like
like
mike
suggesting
somewhere
on
the
screen,
where
you
could
literally
click
and
it
would
switch
to
a
different
provider.
We
could
do
that,
but
it
does.
C
It
does
require
whoever's
running
the
demo
and
if
they
have
no
idea
what's
going
on,
they
probably
don't
have
an
account.
It
does
require
them
to
have
the
have
a
key
configured
for
the
various
providers
right.
So
that
is
the
kind
of
thing
that
we
were
trying
we're
trying
to
remove.
Some
friction
around
that
just
to
just
get
the
concepts
understood.
E
Cool,
so
I
I'll
add
this
ticket
in
here
thanks
justin.
The
other
thing
that
we
could
potentially
do
is
like
just
make
sure
that,
in
the
video
that
we
record
and
maybe
associate
with
this
project,
we
could
make
it
extremely
clear
that
this
is
just
for
demo
purposes
or
something
so
yeah
definitely
add
some
comments
to
the
ticket
that
justin
created
and
we'll
try
to
address
them
as
soon
as
possible.
Yeah.
B
The
feature
management
system,
and
but
this
is
nomenclature
that
everybody
would
be
fine,
or
we
could
also
like
put
in
an
issue
and
then
also
make
this
it's
like
part,
even
of
the
high
level
architecture.
When
we
describe
things
because
then
we
can
see,
the
right
part
is
the
feature
flag
management
system.
The
left
part
is
the
application
with
the
feature
flags.
C
Flag
management
system
and
a
provider,
so
maybe
we
could
add
some
headings
to
kind
of
help,
that
the
other
thing
that
I
that
we
did
discuss
briefly
is
we
could
add
every
step
where
we
kind
of
show
the
different
flags
being
used
in
the
app.
We
could
have
some
kind
of
rendered
code,
snippet,
maybe
actually
pulling
from
the
real
source
code.
That
would
show
like
here's
how
this
flag
is
actually
being
evaluated.
Here's
the
flag
evaluation
api
calls
related
to
this,
but
we
could
do
something
like
that.
J
I
had
some
questions,
so
I
was
reading
the
spec,
but
maybe
I
just
don't
understand
it
fully
yet,
but
so
it
makes
like
this
demo
shows
like
different
kinds
of
feature:
flag
values
you
can
have.
You
can
have
like
a
boolean
value
like
a
string
and
like
json
is
it?
Is
it
expected
that
every
provider
supports
that
or
is
it?
Is
they
couldn't
really
find
a
lot
of
details
in
the
spec?
J
C
Yeah,
so
the
the
current
spec
I
mean
is
obviously
a
draft,
but
there
is
a
provider
section
that
defines
the
specific
methods
that
they
need
to
implement
and
everyone
is
required
to
produce
a
json
object.
However,
even
some
of
the
providers
we
currently
have
that
support
json
objects,
don't
directly
support
that
in
their
back
end
per
se,
so
the
easy
way
around
it
is
just
encode
json
as
a
string
now
you
know
and
then
like
the
details
of
that,
are
all
kind
of
up
to
your
provider.
C
But
there's
ways
around
that
like
I
said
it
could
just
be
encoding
a
string,
but
the
idea
right
now
is
that
all
providers
will
kind
of
support
that
basic
feature
set.
If
you
have
ideas-
or
you
disagree
with
that
kind
of
at
a
high
level,
you
know
that's
something
you
could
discuss
in
in
the
spec
feel
free
to
open
up
an
issue.
C
But,
like
I
said
right
now,
we
definitely
support
providers
that
don't
have
object,
value
support
as
a
first
class
kind
of
use
case
and
in
in
most
cases
what
they're
doing
is
just
storing
objects
as
strings
and
doing
some
amount
of
parsing
so
that
we
can
have
a
consistent
api
on
the
back
end
and
exactly
how
that
works
is
really
up
to
the
provider.
So
open
feature
doesn't
prescribe.
How
that's
done
that
that's
all
done
in
the
in
the
implementation
of
the
provider.
E
Right
and
also
to
quickly
just
jump
in
it's
like
if
it.
If
it's
not
supported
by
the
provider,
it
would
just
return
the
default
value,
so
I
it
wouldn't
be
ideal,
but
basically
the
provider
would
have
no
way
to
actually
return
the
appropriate
type,
and
it's
probably
better
to-
I
guess-
be
aware
of
that
than
try
to
mask
it
in
any
way.
So,
hopefully
that
that's
clear,
if
not,
I
would
definitely
recommend
opening
a
ticket
and
we
can
discuss
it.
There.
E
C
C
Make
a
video
like
we
talked
about,
and,
and
that
kind
of
thing,
so
I
I
think
really
we
went
over
all
of
this
stuff,
oh
and
then
there's
the
node
sdk
partner,
yeah,
so
the
last
bit
I
think
we
should
mention
which,
which
is
this-
is
a
good
lead
into
right.
Now
what
you're,
seeing
what
you?
What
I
just
demonstrated,
was
using
our
our
kind
of
our
playground,
implementation
of
the
node
open
feature
sdk.
C
We
do
have
basically
scaffolding
for
a
proper
official,
node
sdk.
Now
it's
being
published
to
npm,
even
though
it's
it's
basically
an
empty
package,
it's
being
published
as
an
alpha.
So
eventually,
what
we're
going
to
do
is
as
we
progress,
we're
going
to
tear
pieces
of
this
application
out
and
replace
them
with
real
implementations,
so
the
the
kind
of
toy
sdk
implementation
that
is
powering
this
right
now
will
be
replaced
with
the
official
sdk
implementation.
C
Yeah
I
mean
there's,
there's
not
much
more
to
say
around
that,
like
I
said
we're
publishing
a
package
of
feature
scope
in
npm
right
now.
It's
basically
just
a
stub,
but
very
soon
we'll
actually
start
adding
real
functionality
there.
I
won't
go
into
the
es
module
or
common
js
stuff.
I
think
that's
probably
too
fine
detail
for
this
talk.
So
unless.
D
D
I
can
file
a
ticket
for
for
that
work,
and
then
I
had
a
I
just
like
had
a
bunch
of
questions
as
we
went
as
I
went
through
implementing
all
the
spec
stuff
that
just
didn't
quite
make
sense,
and
if
we
just
want
to
skip
these,
that's
fine
but
I'll,
provide
folks
an
opportunity
to
say
what
the
answer
was
we
provide
in.
In
the
hooks
thing,
we
provided
a
mechanism
for
hook
hints
to
be
merged
in
from,
like
an
api
client
into
invocation.
Last
wins,
but
I'm
struggling
to
remember
what
why
we
did
that.
C
I
can't
I'd
like
to
see
the
exact
part
of
the
spec
you're
talking
about,
but
the
only
thing
that
the
only
thing
that
comes
to
mind-
and
maybe
it
was
actually
more-
maybe
it
was
kind
of
a
mistranslation
somewhere.
It
was
supposed
to
be
context,
merging,
but
there's
context
injected
at
various
levels
and
then
context
needs
to
be
merged.
So
you
know
you
may
have
you
may
have
on
the
api,
have
defined
properties
in
the
context
with
a
certain
value,
and
you
want
to
override
them
at
an
evaluation
level
at
invocation
level.
C
I
think
that
was
where
the
merge
kind
of
would
come
in
and
I'm
not
sure
if
there
was
a
kind
of
a
mistranslation
and
that
got
applied
to
hook
hints
or
it
was
intentional
to
apply
to
hook,
hence
because
it
could
be
a
similar
situation
there.
But
that's
my
that's
probably
what
it's
probably
something
like
that
that
happened.
We
should
review,
there's
no
confusion
around
it.
I'll.
D
D
C
Discussion
and
back
and
forth
on
this,
I
think
I
think
it's
probably
worth
like
having
another
issue
where
we
actually
nail
it
down,
but
there
was
a
lot
of
desire
in
the
early
points
of
development,
for
the
ability
to
actually
get
some
idea
of
what
was
happening
with
errors.
So
there's
a
proposal
initially
to
say:
hey
if
we
intentionally
throw
in
an
error
or
unintentionally,
throw
in
an
error
handler,
it
should
bubble
up,
and
obviously
this
is
even
applicable
to
every
language.
Some
languages
don't
have
throwing
semantics,
but
that
was
the.
C
That
was
the
kind
of
the
idea.
I
I
think
it's
probably
worth
opening
up
an
issue
to
discuss
it
further.
I'm
gonna
really
hammer
it
out.
A
lot
of
these
issues
were
kind
of
hard
to.
In
retrospect.
I
think
a
lot
of
these
issues
were
really
hard
to
figure
out
on
really
big
prs
where
we're
defining
a
lot
of
stuff,
and
it
will
probably
be
easier
now
to
open
smaller
pr's
and
smaller
issues
scope
to
just
one
or
two
points.
So
it's
probably
good
to
do
that.
D
C
So
that
that
is,
that
is
the
paradigm.
That's
how
everything
is
spec
out,
the
the
only
place
where
it
gets
tricky
and
I
think
that's
what
justin
we're
just
kind
of
started
on
is
when
we're
talking
about
errors
in
in
user-defined
functions,
and
even
cloud
b's
for
just,
for
example,
makes
this
distinction.
So
if
you're
adding
a
specific
function
or
handler
to
the
sdk,
how
do
we
want
that
to
behave?
Is
it
always?
In
that
case
we
catch
your
error,
or
do
we
allow
you
the
power
to
throw
errors
in
there?
C
That's
kind
of
where
things
get
a
little
bit
gray,
because
I
agree
in
general.
We
never
want
flag
evaluation
to
to
ever
bubble
up
ever
cause
at
normal
execution.
But
if
you're,
attaching
your
own
specific
handler
and
you
do
something
intentionally
to
throw
in
there-
then
it
then
we
just
have
to
decide.
I'm
not
saying
that
it.
That
should
be
a
you
know
that
should
bubble
up.
C
I
think
we
just
have
to
talk
about
it,
but
it's
slightly
different
than
than
basic
flag
evaluation,
and
cloud
b
is
just
for
instance,
again:
cloudbees
defines
actually
allows
that
as
an
option,
so
they'll
say
they'll
say
basically
do
you
want
us
to
to
swallow
these
errors,
or
do
you
want
us
to
re-throw
them
in
your
user
code?
So
we
could
do
something
like
that,
but
yeah.
E
I
think
that
requires
an
issue
mainly
yeah
and
I
think,
basically
exactly
what
todd
just
mentioned
and
what
what
hook
maybe
could
throw
if
we
really
wanted
to-
and
I
definitely
would
prefer
probably
to
do
everything
in
our
power
to
not
bubble
errors
up
to
users,
except
maybe
in
that
one
situation.
So
let's
discuss
that
there.
I
think
what
justin
was
talking
about
in
this
particular
piece,
though,
is
like
actually
like
doing
error
mapping
between
providers
to
like
the
spec
code.
E
So
one
of
the
things
we
had
mentioned
was
like
having
maybe
well-known
errors,
saying,
like
you
know,
flag,
not
found,
and
whatever
coming
back
from
the
details,
call
that
would
require
a
bit
of
work
potentially
to
like
capture
the
error
or
map
the
codes
to
whatever
we
we
deemed
you
know
appropriate
in
the
spec.
Is
that
is
that
correct
justin?
That's
what
you're
asking
here
yeah.
C
Yeah
yeah
mike's
exactly
right,
like
I
think
this
came
from
this
came
from
something
that's
been
brought
up
a
couple
times.
I
think
eloise
has
brought
it
a
couple
times,
but
other
people
as
well,
where
so
the
flag
defaulted,
because
something
happened
in
the
sdk.
Some
sdks
provide
metadata
about
what
went
wrong
so
launch
darkly,
for
example,
will
provide
an
error,
some
kind
of
reason
that
contains
an
error
in
some
cases
that
says:
okay.
Well,
I
couldn't
connect
to
the
api.
There
was
an
authentication
issue.
C
The
api
is
down
like
you're,
I
got
it
was
a
dns
black
hole
because
this
person
has
a
you
know
an
ad
blocker.
It
could
be
anything
like
that
and
we're
kind
of
we're
trying
to
find
a
mechanism
to
expose
those
underlying
error
reasons
in
the
detailed
evaluation
api,
and
so
I
think,
that's
kind
of
where
justin's
rubbing
up
against
some
ambiguity,
but
that
was
the
that
was
the
goal
of
the
specific
one.
D
C
I'm
not
married
to
the
number
scheme
at
all.
We
don't
have
to
number
them.
We
can
name
them.
We
can
not
have
any
identifier,
I'm
kind
of
I
kind
of
like
the
idea
of
identifiers
for
deep
linking,
but
it
also
makes
things
a
little
bit
brittle,
perhaps,
and
certainly
we
have
to
sanity
check
them.
So
that's
a
good
call
out.
E
Yeah,
does
anyone
have
an
opinion
on
that?
I
mean
for
for
just
ease.
It
may
be
nice
to
start
at
one
for
every
every
new
dedicated
file,
it
seems,
like
it's
gonna,
be
kind
of
a
nightmare
to
figure
out
like
each
portion
of
the
spec
like
what
what
new
number
that
starts
at,
and
I
don't
know
if
that
really
provides
a
whole
lot
of
value.
But
I
could
be
wrong.
I
guess
it
also
depends
if
we
want
to
merge
all
of
that
or
something
at
the
end.
C
We
could
have
an
integer
at
the
top
of
the
spec
file
that
has
to
match
the
you
know
the
prefix
version,
for
instance,
but
we
should
we
should
validate
this
somehow
I
mean
it's
probably
not
like
a
pressing
911
issue,
but
I
think
maybe
we
need
to
create
an
issue
for
it
and
decide
if
we
want
numbers
at
all.
I
mean
we
don't
have
to
roll
with
that
at
all.
At
this
point,.
E
A
E
Great
perfect,
thanks
for
the
update,
I
think,
todd
and
I
are
going
to
continue
to
work
on
the
the
node
one
as
well.
Our
availability
next
week
will
be
a
little
limited
with
with
coupon
and
everything,
so
there
may
be
a
slight
pause
there,
but
I
guess
keep
track
of
that
that
repo
as
well,
we
just
got
an
update
in
the
channel
too.
That
see
dave
from
harness
is
going
to
continue
to
work
on
the
golang
sdk,
which
is
great,
and
then
it
looks
like
we're.
J
J
D
C
I
think
you
posted
that
in
the
slack
channel
before,
and
it
did
seem
really
interesting,
so
feel
free
to
post
it
again
or
add
it
to
the
add
it
to
the
community
notes
appreciate
it.
It
definitely
seemed
dense,
very
good,
but
also
dense
and
probably
worth
taking
a
look
at
yeah.
It
seemed
like
there
was
a
lot
of
going
there.
I
skimmed
a
little
bit
of
it.
The
the
other
thing,
maybe
maybe
I
got.
E
Yeah,
I
think
that
all
makes
sense-
and
I
do
think
that's
something
we
should
address
as
soon
as
we
get
a
little
bit
further
along
with
the
spec
and
some
of
the
sdks
become
available.
So
yeah
good
point,
thanks
for
bringing
that
up,
it
does
look
like
eloise
wants
to
mention
one
more
thing
before
we
quickly
wrap
up
yeah.
B
I
think
a
general
discussion,
so
what
I
really
learned
during
this
pr
initiative
that
it
was
like
really
hard
to
reach
you
on
a
time
sensitive
basis.
So
I
was
like
I
was
a
github
issues,
weren't
working
that
great
slack
as
we
use
the
cncfs
like.
I
can
just
notify
people
you
can
only
post,
because
you
can
either
neither
use,
adhere
or
add
channel.
B
B
I
don't
know
like
to
have
an
open
feature
con
or
something
like
this
where
people
can
subscribe,
and
I
can
be
sure
that
I
can
reach
everybody
who
joins,
even
if
I
don't
have
like
the
email
address
available
where
they
can
simply
subscribe
to.
It
might
be
solved
at
some
point
if
you
get
their
own
slack
to
be
fair,
but
just
I
wanted
just
to
bring
it
up.
It
was
really
not
easy
to
have
a
conversation
where
I
could
get
people
notified.
B
D
B
Be
our
something
comes
up
or
like
we
get
an
invite,
say
to
speak
to
an
analyst,
and
I
want
to
involve
any
of
you
it's
like
hard
to
like
really
notify
you
that
you
actually
see
the
notification
somewhere,
because,
right
now,
it's
like
a
rather
passive
and
relying
on
people
to
read
it
while
actively
getting
it
pushed
to
them.
I
think
the
issue
with
github
is
the
same
that
we
all
have
we
just
get
so
many
github
notifications
most
likely
that
one
of
these
that
can
get
easily
buried
and
yeah.
B
B
B
E
Well,
dora
was
even
having
trouble.
You
know
we're
over
time,
so
if
you
have
to
drop,
feel
free,
but
yeah
appreciate
everyone's
time
here,
thanks
but
yeah.
This
is
something
we
should
probably
try
to
figure
out,
because
even
dora
had
trouble
joining
the
cncf
slack,
which
is
obviously
a
pretty
major
barrier
and
definitely
a
bummer.
So.