►
From YouTube: OpenFeature - Project meeting, September 15th, 2022
Description
Notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit?usp=sharing
OpenFeature website: https://open-feature.github.io/
A
A
C
E
C
C
C
C
C
F
Yeah
so
yeah
go
ahead.
Last
week,
Steve
made
the
point
that,
while
the
language
go
is
commonly
referred
to
as
golang,
its
official
name
is
go
and
we've
aimed
the
goolang
SDK
as
such,
and
we
should
probably
rename
it
to
go
SDK
so
that
there's
an
issue
in
the
SDK
for
this
and
I've
created
a
checklist
of
things.
We
need
to
do
to
make
this
happen
and
we're
hoping
to
do
this
early
next
week.
F
If
anyone
has
any
concerns
about
this,
then
we
can
even
talk
about
now
or
add
it
to
the
issue.
I'll
link
it
in
the
chat,
but
yeah
you
should
be
able
to
just
carry
on
using
you
know
the
old
name.
You
just
won't
be
able
to
get
any
updates,
so
you
should
rename
it
to
Nico
SDK
when
we
do
that
to
prevent
that.
C
Yeah
that
was
kind
of
our
thought
too
was
like
rip
the
Band-Aid
off.
We
have
a
similar
issue
for
the
one
we've
called
node
so
far
and
and
going
through
the
process
of
JavaScript,
so
it
will
be
the
same
concerns
there's
already
an
issue
kind
of
outlining
that
and
I
think
yeah
ripping
the
Band-Aid
off
is
probably
a
good
analogy
here
and
just
kind
of
dealing
with
with
kind
of
the
impact
that
we'll
have
now
versus
you
know.
C
After
we
kind
of
announce
like
a
1.0
release
and
stability,
then
obviously
we're
kind
of
stuck
so
we'll
get
into
that.
I
think
in
a
couple
agenda
points
later
in
the
the
session
here
today,
but
yeah
that
was
kind
of
one
of
the
thoughts
here
is
just
kind
of
dealing
with
some
of
these.
You
know
relatively
major
changes
that
we
just
want
to
kind
of
get
out
of
the
way
if
we
think
they're
worth
it.
C
Of
course,
if,
if
there's
a
lot
of
pushback
or
we
think
it's
not
worth
the
effort,
certainly
you
know
bring
it
up
because
it
it
is
a
little
impactful
and
that's
yeah
I,
think
now's
a
good
time
to
do
it,
but
we
don't
necessarily
have
to
well
all
right
Skye
thanks
for
the
update
and
then
the
issue
is
linked
in
the
notes
now.
So,
if
anyone
wants
to
check
it
out,
you
know
please
do
that.
B
Yeah
I'm
sure
miss
Korean
really
quickly
a
little
neuron
section,
so
there
is
a
provider
section
in
the
in
the
Dockside.
Already
we've
got
a
couple
things
here.
One
is
this
checklist.
The
checklist
is
things
that
you
should
consider
when
doing
your
provider.
A
lot
of
them
are
really
basic
and
really
easy
to
implement,
but
also
could
be
tricky.
Gotchas,
like
one
of
the
one
of
the
ones,
for
instance,
is
flag.
B
Keys
might
need
to
be
transformed,
that's
something
that
a
few
providers
need,
because
not
all
flag
keys
are
valid
so
that
there's
a
whole
bunch
of
like
functional
requirements.
Here
you
should
consider
and
then
non-functional
things
like
the
providers
added
to
the
dock.
There's
you
know
released
in
a
certain
way,
so
this
is
a
good
place
to
start
for
a
to-do
list.
B
If
you're
implementing
a
provider
and
I
also
implemented
these
little
copious
markdown
things,
so
you
can
actually
just
paste
them
into
GitHub
markdown
paste
them
as
GitHub
mark
down
into
an
issue.
If
you
felt
like
it,
there's
also
an
FAQ
that
was
added
so
I'm,
hoping
that
SEO
can
catch
some
of
these.
B
Hopefully,
if
you,
if
anybody
Googled
some
of
these,
take
a
anybody,
who's
written
a
provider
or
is
familiar
with
that
aspect
of
the
spec,
maybe
just
do
a
quick
run
through
this
and
make
sure
it
makes
sense
to
you
and
if
you
can
think
of
something
to
add,
please
open
a
PR,
and
that's
really
all
there
is
for
that.
One
there's
also
the
test
harness
so
I
have
a
couple
links.
There.
B
Justin
recently
opened
an
issue
in
the
Java
SDK
that
I've
assigned
to
myself
and
there's
a
link
to
the
test
harness
repo.
The
test,
harness
repo
is
really
simple.
It's
just
a
set
of
cucumber
tests,
a
very
small
set
right
now
that
I'm
working
on
expanding
and
a
Docker
file
for
a
test
bed.
The
test
bed
is
basically
just
flag
D,
it's
just
a
container
that
that
runs
flag
D
with
a
built-in
set
of
flags
that
correspond
to
the
kirken
test.
B
The
requirement
is
that
you
need
a
flag
D
provider.
Obviously,
but
you
can
take
a
look
in
the
GitHub
actions
in
in
the
node
sample
and
in
the
the
PRL
open
for
Java.
It's
really
simple.
You
can
just
basically
run
a
container
as
a
service
in
the
in
the
GitHub
action
and
then
run
an
intake
integration
test
Suite.
So
that's
the
idea.
B
G
Yeah,
so
just
a
little
bit
of
news
regarding
this
outfit
for
the
flag
events,
so
we've
got
a
couple.
Changes
to
the
the
node
SDK
will
be
the
JavaScript
SDK
for
flag
d
to
allowed
to
work
in
web
environments.
So
we've
done
a
little
bit
of
rework.
So
it's
going
to
be
working
with
the
the
connect
build
API,
so
different
protocol,
a
little
bit
more
lightweight
for
web
development,
but
I
put
together
a
proof
of
concept
for
the
flag
of
ending.
G
So
at
the
moment
you
can
create
two
events.
One
just
says
provider
ready.
The
other
is
for
a
configuration
change
and
that
allows
us
allows
us
to
have.
You
know
immediate
updates
on
like
a
front-end
environment
when
a
flag
is
changed
in
the
back
end,
I've
got
a
quick
demo
for
you,
which
will
90
break
but
I'll
give
it
a
go
anyway.
G
G
Currently,
it's
set
with
the
flag
value
here
in
this
flag,
the
instance
of
not
yellow.
You
must
just
come
in
here
and
update
it
to
yellow
and
the
subscription
means
that
you
know
immediately.
We
get
that
change
scene
in
the
front
end
and
just
down
here
you
can
see,
there's
a
little
code,
snippet
of
how
that
is
being
implemented.
So
you
listen
to
the
configuration
change
event
and
you
can
just
pass
in
and
listener
for
it,
and
these
will
be
propagated
through
all
clients
but
yeah
just
to
demo.
G
H
I'm,
sorry,
my
bad.
This
is
really
interesting
to
me,
because
the
thing
that
I
really
struggle
to
understand
is
when
would
you
be
building
a
react
site
locally
in
node.js
and
then
wanting
to
use
a
Linux
binary
to
control
the
flags
like
I'm,
just
trying
to
understand
the
worlds
that
this
is
combining?
Wouldn't
you
want
to
have
some
sort
of
like
node
or,
like
you
know,
JavaScript
native
version
of
flagp.
G
I
think
you
know,
keeping
your
eggs
in
one
basket
might
be
one
argument
for
it.
If
you've
got
a
back
end
with
flag
evaluations
happening
in
flag
D
I
personally,
wouldn't
want
to
then
introduce
another
flag
provider
for
a
second
set
of
flags
for
the
front
end,
especially
if
you
need
things
to
link
up
between
the
two.
H
B
Yeah,
it's
I
think
it's
basically
that
so
grpc
grp
or
the
the
connect
protocol
works
on
HTTP.
So
you
could.
The
architecture
I
would
think
you'd
want
for,
for
this
would
be
distinct
from
like
something
that
the
open
feature
operator,
for
instance,
would
deploy
for
you,
so
you'd
just
deploy
a
standalone
flag
d
as
a
container
somewhere
in
your
infrastructure
as
a
pod
you'd
expose
that
via
a
cloud
load,
balancer
or
or
your
own
load
balancer
and
your
infrastructure.
However,
you
want
to
do
that
and
it's
going
to
expose
that
externally.
B
So
this
is
an
externally
available
service
that
exposes
a
flag
D
instance
that
you've
deployed
specifically
for
client-facing
Flags.
Then
the
flag,
D
web
client,
which
is
you
know,
similar
to
the
flag,
D
JavaScript
provider,
except
not
using
jrpc
it
uses
HTTP
via
connect,
is
then
talking
to
that
instance.
Through
that
load,
announcer,
probably
I
mean
you,
don't
really
even
need
the
load
balancer
you
could
hypothetically
like
just
expose
that
flag
D
somewhere
in
your
infrastructure
and
put
SSL
in
it.
I.
B
Don't
think
you'd
want
to
do
that,
but
you
could,
but
that's
the
idea
and
I
I.
Think
yeah
I
think
it's
just
distinct
from
it's
a
little
bit
different
from
like
the
way
say,
we're
doing
it
with
open
picture
operator
or
something
like
that
and
there's
more
manual
infrastructural
steps
for
sure.
But
that's
the
architecture
I
had
in
my
head.
H
H
Http
2
is
not
supported
on
Big
5
or
big
IP
in
many
places,
so
I
I'm,
just
I'm
not
again
I'm,
just
trying
to
think
about
hypotheticals
here
that
stop
this
from
actually
working,
but
it
makes
sense
now
you've
mentioned
I,
never
thought
that
this
was
going
to
be
stag,
D
Standalone
in
a
container.
So
that
makes
a
lot
more
sense.
I
understand
it.
C
Yeah
and
I
think
probably
it
would
make
sense
to
have
a
standalone
sync
on
on
this
topic.
So
the
one
reason
I
wanted
to
show
it
here
was
just
to
show
like
the
Eventing
API,
because
that's
part
of
like
the
the
overall
spec
but
I
think
like
a
dedicated
section
on
like
the
flag.
D
implementation
probably
makes
sense,
so
we
can
talk
through
in
in
the
flag,
D
Channel
or
interest
in
the
slack
Channel
and
try
to
get
something
on
the
calendar,
but
yeah
I
I
think
really.
C
Let
me
look
here:
Todd
did
you
have
anything
else?
Next
or
no?
It's
me
actually,
okay,
so
I
was
talking
to
the
hotel
team
about
what
we
can
do
potentially
about
you
know,
stabilizing
the
spec
itself
and
one
of
the
things
I
had
talked
about
was
figuring
out
different
stability
levels
or
status
levels
it.
It
seemed
to
me
that
open
Telemetry
was
kind
of
missing
a
status
and
turns
out
they
they
kind
of
are,
but
they
they
technically
have
it.
They
just
don't
show
it
in
their
status
table.
C
Did
you
excuse
me
sorry
about
that?
Basically,
they
have
a
feature
freeze,
status,
level
and
I.
Think
that
actually
makes
sense.
It's
a
lot,
I
think
in
line
with
what
we're
looking
for
and
so
I'm
working
on,
defining
what
a
feature
flight
or
feature
freeze
would
look
like
in
our
status,
Dock
and
then
I
would
propose
that
in
the
next
maybe
week
or
so,
we
Define,
which
ones
could
be
basically
good
candidates
for
having
feature
be
frozen.
C
We
do
need
to
you,
know,
Implement
some
kind
of
freeze
on
the
spec
itself,
and
so
I'm
kind
of
working
through
that
right
now
and
feedback
would
be
great.
I'll
put
the
the
pull
requests
in
the
stock
Channel
once
it's
available,
but
it
is
going
to
be
pretty
heavily
inspired
by
what
open
Telemetry
does
in
terms
of
their
stability
levels
and
I
think
they
they
have
a
lot
of
the
same.
You
know
problems
or
challenges
that
we
have
so
I.
Think
it's
it's
a
pretty
good
reference
point
and
I
don't
know.
C
I
can
open
it
up
too,
if
there's
any
feedback
on
on
that
proposal,
but
yeah,
okay,
so
yeah
look
for
that
in
the
future.
I
think
that
that
is
I
I,
move
that
in
front
of
Todd's
Point,
actually
because
I
think
the
the
freezing
of
the
spec
is
an
important
part
in
order
to
have
a
release
candidate,
SDK,
and
so
that's
why
I'll
hand
it
over
to
Todd
now
to
talk
about
that.
B
Yeah,
so
thanks
the
as
we
kind
of
get
closer
to
to
a
coupon
that
was
kind
of
one
of
the
dates
that
was
important
to
the
project.
What
we'd
hope
to
do
is
be
able
to
move
some
sdks
into
a
release,
candidate
status,
so
I've
kind
of
been
throwing
that
or
heard
out
those
words
that
they're
a
little
bit
casually
recently
but
I'd
like
to
talk
about
you
know,
specifically,
probably
the
the
four
sdks
I
have
listed
there.
B
I
I've
been
implementing
providers
helping
Implement
providers
as
well
as
doing
a
few
different
pocs,
and
it
seems
to
me
that,
like
what
we
have
in
most
sdks
at
this
point
is
fairly
feature
complete.
So
as
far
as
like
the
goals
and
the
visions
that
I
think
are
out
are
laid
out
in
the
spec
implicitly
and
use
cases
that
I've
I've,
you
know
seen
across
those
various
providers,
I
think
we're
pretty
much
there.
B
So
I'd
like
to
get
to
a
spot
where
we're
comfortable,
saying
you
know
the
either
this
build,
or
you
know
a
next
few
builds
from
here.
Like
maybe
there's
some
key
issues
in
particular
SDK
people
are,
are
passionate
about,
but
I'd
like
to
be
able
to
identify
like
yeah
we're
getting
close
to
release
candidate.
B
A
H
C
If
we
still
kind
of
leveraged
what
open
Telemetry
did
they
have
different
meanings
to
what
stable
means
and
the
way
I'm
kind
of
thinking
about
it
would
be
like
the
developer
facing
interfaces
would
effectively
like
have
a
you
know,
be
stable.
We
would
not
introduce
breaking
changes,
but
we
can
still
add
you
know
we
still
have
the
flexibility
within
reason
to
update
like
the
provider
interfaces
and
things
like
that.
Those
are
easier
for
for
a
user.
Basically,
if
you
upgrade
open
feature,
then
you
just
upgrade
to
the
appropriate
like
provider.
C
C
The
basics
work,
so
we've
tested
that
at
client
side,
but
yeah,
of
course,
like
it,
hasn't
really
been
battle
hardened
at
all.
Looking
at
you
know,
existing
you
know,
feature
flag,
vendor
sdks,
like
they're
they're,
relatively
similar
to
to
server
side,
at
least
in
terms
of,
like
you
know,
their
interfaces,
but
I
suppose
that
we
have,
you
know,
representation
from
a
number
of
flag
vendors.
If
they
have
any
specific.
You
know
areas
that
we
should
consider.
C
You
know
I,
guess.
Definitely
let
us
know
we
could
also
have
the
ability
to
to
potentially
add
to
the
spec
specifically
for
for
Mobile
use
case,
or
you
know,
client-side
use
cases
and
kind
of
extend,
extend
the
spec
for
for
that
area,
since
we
haven't
really
explored
it.
Maybe
that
could
even
be
part
of
our
you
know.
Stability
guarantee
is
that
it's
for
server
side
or
something
at
the
moment.
D
Yeah,
because
there
is
one
use
case
that
you
can
see
in
some
client
sdks
like
when
you
retrieve
all
flags
at
once,
just
to
have
like
a
local
copy,
and
this
is
not
something
we
are
dealing
with
from
for
now.
So
I
already
see
some
use
cases
where
we
can
expect
some
changes
in
the
spec.
If
we
want
to
implement
such
thing,
I'm
not
sure
we
want,
but
this
is
some
things
that
are
happening
in
in
your
Frontline.
One.
B
I
think
that
might
be
the
most
productive
way
to
do
this.
Okay,
good
I'm,
seeing
some
thumbs
up
so
I
can
I
can
work
on
scheduling
a
meeting
and
creating
a
document
or
something
like
that
where
people
could
talk
about
what
kind
of
concerns
they
want
to
bring,
but
again
I
hate
meetings
for
the
sake
of
meeting.
So
hopefully
we
can
leave
that
meeting
with
issues
specific
research
issues.
A
A
C
A
B
Yeah
this
one
should
be
quick,
so
we've
been
using
release
please
in
a
couple
repos
I
I
really
like
release
please
but
I'm
not
trying
to
force
it
on
anyone.
If
you
don't
like
release,
please
you
don't
want
to
use
it.
That's
that's
totally
fine,
but
I
think
what
we
do
need
to
kind
of
agree
on
I
think
is
how
we're
actually
doing
releases.
B
One
of
the
issues
that
I've
seen
is
that
everyone
is
below
zero
right
now
and
there's
been
a
little
bit
of
inconsistency
with
the
release.
Semantics
I
would
like
to
agree
that,
while
we're
below
one,
we
kind
of
do
the
the
shift
of
semantic
meaning
of
all
the
numbers.
So
a
breaking
change
is
a
minor
change
now.
So,
if
you
go
from
0.1
to
0.2
you're
implying
that
there's
a
breaking
change,
I
I
think
that's
helpful.
B
I
mean
I,
please
anybody
who
doesn't
like
that
idea,
let
me
know,
but
I
I
think
it
might
be.
A
good
thing
to
do.
I
also
think
that
we
need
to
make
sure
that,
within
our
sdks,
the
release
process
is
transparent
and
Democratic,
where
applicable,
release.
Please
really
helps
with
that,
because
the
release
process
is
made
into
a
PR.
You
can
see
the
version
numbers
that
are
going
to
change.
You
can
see
the
generated
change
log,
somebody,
the
the
bot
actually
opens
up
a
PR,
and
then
somebody
merges
it.
B
B
I
Of
the
automated
tools
may
may
try
and
still
Force
up
a
first
number
increase,
because
if
you
get
like
the
exclamation
mark
or
breaking
change
in
a
commit
message,
some
things
go.
I'll
automatically
release
it
as
a
what
a
bumping
up
the
next
major
version,
but
so
so
that's
something
we
can
easily
get
past.
B
C
Yeah-
and
it
is
probably
worth
mentioning
that
we
have
like
example,
configurations
in
a
lot
of
different
languages
for
release,
please
too
and
I
I
suppose
at
least
Todd
and
I
have
kind
of
built
up
some
expertise
with
the
tool
recently.
So
if
you
need
help
and
you're
interested
in
using
it,
you
know
we
have
no
affiliation
with
it.
It
just
works.
Well,
so
yeah
perfect
one
other
one.
C
C
Someone
from
dynastrace
actually
reviews
it
every
couple
weeks
and
then
we'll
look
through
the
issues
there,
and
then
we
can
schedule
some
like
tweets
and
things
like
that
around
there.
So
if
there's
anything
particular
we'll
add
it
in
there
I
think
it's
good.
You
know
if
we
add
blog
posts
or
release
providers,
anything
like
that
could
be
scheduled
if
we'd
rather
do
it
more
on
demand
too.
You
can
just
message
in
the
slack
Channel
and
we
can,
you
know,
try
to
schedule
it
a
little
bit
quicker.
C
But
if
it's
something
that
you
know
it
can,
a
slight
delay
is:
okay,
just
throw
it
in
that
that
Community
issue
and
it
will
just
get
scheduled
and
tweeted
and
whatnot
cool
next
one.
This
one's
kind
of
an
interesting
teaser,
I
would
say:
we've
talked
about
super
providers
and
a
bunch
of
other
crazy
Concepts
in
the
past.
Thinking
about
it
a
bit
more
I
thought,
maybe
a
Federated
provider
would
be
a
more
business
appropriate
name
for
it.
C
So
I
came
up
with
like
a
little
proof
of
concept
of
of
what
that
could
look
like,
and
it's
it's
incredibly
simple.
Actually,
as
you
you
may
expect,
the
only
challenge
would
be
is
like
if
all
of
the
different
like
registered
providers
had
provider
hooks,
there
was
no
real
clean
way
of
dealing
with
that,
so
I,
basically
just
extract
them
all
out
and
just
run
through
all
provider.
C
Hooks
I'm
going
to
just
link
it
in
the
the
slack
Channel
if
anyone's
interested
or
in
the
zoom
Channel,
if
anyone's
interested
to
look
at
it.
It's
it's
just
a
pull
request
right
now,
it's
more
of
a
just,
a
proof
of
concept
to
say
like
Yep.
This
is
possible,
but
it
does
unlock
some
pretty
interesting
possibilities
of
you
know.
Looking
at
different
data
sources,
and
you
know
pulling
from
you
know
the
first
one
wins
basically
in
this
scenario,
so
yeah.
C
Next
one
is
I,
don't
know
if
people
have
noticed,
but
someone
from
the
community
developed
the
PHP
SDK,
that's
spec
compliant
now,
at
least
it
should
be
so
we
need
to
probably
review
it
and
test
it
out,
but
it
is
now
available
and
I
think
it's
composer
or
something
like
that.
As
the
PHP
package
manager,
it
should
be
available
on
there
now
and
so
definitely
test
it
out.
C
If
you
have
any
interest
in
PHP,
but
it's
pretty
cool
to
see
someone
basically
from
the
community
just
read
through
the
spec,
build
it
basically
completely
themselves
and
then
donate
it
back
to
the
project,
so
pretty
exciting
and
and
yeah
definitely
definitely
worth
checking
out.
If
you
have
any
interest
in
PHP
next,
one
is
the
python
SDK.
C
This
is
an
area
that
I
think
at
least
between
Todd
and
I,
are
kind
of
lacking
python
expertise,
at
least
at
like
the
Enterprise
level
and
I
think,
because
of
that,
it's
kind
of
gotten
a
little
out
of
it's
It's,
the
only
one.
That's
not
spec
compliant
right
now
and
definitely
has
received
probably
the
least
amount
of
love
from
at
least
the
team
at
dynatrace.
So
I'm
not
sure
if,
if
there's
anyone
that
has
interest
or
expertise
in
that
area,
that
would
be
willing
to
help.
Maybe.
C
We're
basically
looking
for
for
help
maintaining
that
project,
otherwise,
we'll
have
to
you
know
kind
of
keep
asking
around,
but
it's
an
area
that
it'd
be
great
to
get
a
spec
and
plant
I.
Think
it's
relatively
close,
just
looking
through
the
code,
but
you
know
not
being
a
python
expert
by
any
means
and
yeah
I
just
want
to
make
sure
that
we're
in
a
good
spot
if
we're
going
to
advertise
it.
C
Otherwise
we
basically
just
need
to
continue
to
add
that,
like
that,
you
know
that
warning
at
the
top
that
it's
still
you
know
a
work
in
progress
because
of
that
it
has
not
been
added
to
documentation
or
anything.
But
I
do
know
that
you
know
some
work
has
been
done
on
there,
so
I
don't
want
to
just
totally.
You
know
discount
that,
but
it
we
need
to
make
sure
it's
either
spec
compliant
or
clearly
marked
as
something
that's.
You
know
kind
of
looking
for
maintainers.
A
C
Been
a
few
like
pull
requests
which
has
been
open
for
quite
a
while
that
I
think
you
know,
hasn't
hadn't
really
been
a
review
and,
like
so
things,
just
kind
of
still
installed
out
a
bit
and
yeah
I.
Think
we
just
if
we
can
give
it
a
little
bit
of
love.
I,
think
it
wouldn't
take
a
ton
to
get
over
the
last
remaining
like
spec
issues
to
to
get
it
in
a
good
spot.
So
any
help
there
would
be
very
much
appreciated.
C
Yeah,
perfect!
The
next
one
is
I
created.
A
really
simple,
cubecon
sign
up
form
I'll,
also
just
link
that
quickly
in
Zoom.
But
it's
also
on
the
notes.
If
you're
going
to
be
at
kubecon,
please
fill
it
out
and
then
I'll
make
sure
to
keep
everyone
in
contact
and
we'll
try
to
schedule
some
time.
There.
I
know
that
there's
going
to
be
like
an
after
hours
like
event
thing
that
the
dynatrace
and
a
few
others
are
sponsoring
so
I'll
make
sure
to
you
know,
get
you
an
invite
to
that.
C
We'll
also
have
the
booth
there.
So
if
you
have
any
interest
in
either
stopping
by
the
booth
or
helping
out
at
the
booth,
that
would
be
great
and
I'm
gonna
see
if
I
can
get
a
swag
budget.
If
I
can
I'll
try
to
make
sure
that
we
can
get
some
something
kind
of
cool.
So
definitely
let
me
know
you
know,
sign
up
and
we'll
be
in
contact
this.
This
doesn't
help
Justin,
unfortunately,
but
I
do
have
a
kubecon
like
discount
code
available.
C
So
if
you
are
going
to
go
make
sure
to
use
that
it's
20
off,
so
it's
you
know
fairly
significant,
because
these
tickets
are
kind
of
comically
expensive
for
what
they
are,
but
it
should
be
a
pretty
cool
opportunity
for,
for
us
to
you,
know,
get
together
and
meet
and
also,
if
you're
going
to
be
there
just
you
know,
love
if
you're
willing
to
share.
At
least
let
us
know
your
schedule.
C
So
we
can
try
to
find
some
times
to
meet
up
and
you
know:
grab
lunch
or
you
know,
do
an
open
feature.
In-Person
meeting
again-
or
you
know,
there's
opportunities
to
certainly
take
advantage
of
our
time
being
in
the
same
place
and
that
is
it
on
kubecon
any
any
thoughts
on
any
of
that
cool.
There
will
be
a
few
sessions,
unfortunately,
I
think
I've
mentioned
it
a
couple
times.
Mine
is
like
Friday
late,
so
I
think
most
people
are
probably
like
on
an
airplane
at
that
point.
C
A
A
C
C
Good-
and
that
does
remind
me-
you
had
at
one
point
mentioned
the
like-
that
General
groups
I
o
mailing
address
and
if
we
wanted
to
get
rid
of
it,
I
think
this
was
the
only
place
that
we
referenced
it
still
so
I
guess
we
can
talk
about
that
too.
When
we
we
chat
through
it
and
see
what
we
want
to
do.
C
Stuff
yeah,
perfect,
okay,
yeah,
it's
one
of
those
areas
that
I'm,
admittedly
fairly
weak
in.
If
that's
something
that
we
have
expertise
in
that
area
and
there's
you
know
some
obvious
issues
in
the
spec,
you
know
now
is
obviously
a
great
time
to
do
that
and
it
becomes
a
little
bit
more
challenging
or
we
have
to
get
more
creative
with
adding
like
client
or
mobile
side.
You
know
exceptions
to
spec,
which
is
something
that
would
be.
C
C
Improvements
that
need
to
be
made
to
the
sdks
I
would
highly
encourage
you
to
look
at
that
and
do
that
as
soon
as
possible,
even
if
they're
breaking
just
kind
of
rip
the
Band-Aid
off
and
and
make
sure
that
it's
you
know
clearly
communicated
in
the
release
notes,
but
like
it's
going
to
be
basically
impossible
to
do
once
we
we
Mark
these
as
as
1.0.
So
if
there's
any
like,
you
know,
breaking
changes
that
would
introduce
or
need
to
be
introduced
in
order
to
to
you
know,
make
it
easier
or
more
developer
friendly.
C
You
know,
consider
that,
and
do
it
if,
if
necessary,
don't
just
do
it
for
the
sake
of
doing
it,
but
if
it,
if
it
makes
sense,
then
it
makes
the
sdks
better
long
term.
You
know
consider
making
those
changes.
There's
a
handful
that
are
in
the
works
for
node,
so
just
be
kind
of
watching
out
for
that
and
I'll
I'll
try
to
communicate
it
and
tag.
Anyone
that's
been
involved
in
that
project,
but
just
look
for
those,
and
you
know
feedback
would
be
appreciated
there,
but
that
that's
the
intent
behind
it.
C
J
A
C
So
I
mean
that's
kind
of
up
to
us.
I
mean
the
main
thing
that
we're
trying
to
shoot
for
is
stabilizing
the
spec
itself
and
then
having
you
know,
I
guess
our
core
sdks
and
we
can
choose
what
our
core
sdks
are
looking
through,
like
I.
Think
Pete
was
the
one
that
linked
it.
Some
of
the
launch,
Darkly,
like
usage
information
like
python,
is
like
a
couple
percent.
C
So
it's
like
not
something
we
want
to
totally
ignore,
but
it's
also
not
like
the
main
SDK
that
we,
you
know,
absolutely
need
for
like
a
1.0
release,
so
I
would
say
right
now
and
I
think
it's
listed
on
our
in
our
notes.
Right
now,
but
I
would
say
like
java.net,
node
or
or
JavaScript
and
go
would
likely
be
the
ones
that
would
be
like
our
primary,
but
then
any
of
the
other
sdks
like
whenever
it
gets
to
the
the
appropriate
maturity
level.
C
B
B
So
so
all
I'm
saying
there
is
if
the
Ruby
SDK,
if
a
ruby
SDK,
would
really
help
help
your
organization
I,
would
not
hesitate
to
to
kind
of
throw
some
way
behind
that,
and
there
has
been
some
interest
in
Ruby
from
some
people
kind
of
related
to
the
project
already,
so
you
might
actually
find
that
there
is
a
like
a
critical
mass
there.
You
know
that
some
Point
anyway
I
just
wanted
to
bring
that
up
like
what
you
described
is
kind
of
kind
of
a
huge
use
case
for
for
the.
J
J
Put
the
headset
just
switched
off
it
works
now.
Does
it
work?
Yeah
I
didn't
have
that
much
kind
of
insight
in
the
open
feature,
Community
I
basically
filled
out
a
form
that
I
was
interested
to
contribute
which
I
am
but
I.
Don't
know
about
your
guy
mailing
list
or
anything
else.
Any
other
means
of
communication
that
you
guys
use.
C
Yep
and
then,
if
you,
if
you
can
add
yourself
as
like
an
interested
party,
it's
just
it's
there's
a
list
on
the
community
repo.
If
you
add
yourself
there,
then
we
can
add
you
as
like
a
member
of
the
org
and
then
then
it's
easier
to
like
mention
you
in
issues
things
like
that
and
then
once
you're
ready
with
Ruby
too,
we
can,
you
know,
talk
about
creating
like
the
repos
and
getting
all
that
stuff.
Prepped.
C
C
I
Yeah
sorry
I
was
so
late.
I
am
an
engineer
at
virtue,
which
is
a
secure
email
and
file
sharing
startup,
and
we
recently
did
a
proof
of
value
with
launch
Darkly
as
a
feature
flag
provider.
We
didn't
have
a
great
managed
feature
flag
solution
internally
before
that,
and
it
looks
like
we're
going
to
be
moving
forward
with
launch
Darkly
through
the
proof
of
value
process
with
them.
I
You
know
many
of
the
questions
we
were
asking
are
the
ones
that
openfeature
is
working
to
solve
around,
avoiding
vendor
lock-in,
and
you
know
protecting
the
future
of
future
flagging
without
one
paid
solution,
so
yeah
definitely
interested
in
contributing
more
working
on
figuring
out
the
details
internally
around
what
that
might
look
like,
but
for
now
yeah
just
wanted
to
attend
a
meeting
and
see
kind
of.
What's
up
so
nice
to
meet
you
all
yeah
great
welcome
nice
to
meet
you.
C
C
C
E
Just
made
me
made
me
think
of
something:
is
there?
Is
there
any
like
desire
to
to
do
like
a
little
bit
of
a
marketing
push
around
like
the
1.0
like
get
on
some
podcasts
or
things
like
that,
because
it
it
feels
like
it
would
be,
definitely
possible
to
do,
but
it
would
just
require
well
a
some
people
who
are
willing
to
be
on
a
podcast
but
and
they'll
then
be
just
organizing
it
like
going
and
sending
out
emails
to
podcast
hosts
and
saying
okay,
would
you
like
to
do
a
podcast
about
this.
C
C
H
C
E
C
E
C
I
mean,
hopefully
they
don't
watch
this
recording
so
far.
That
cncf
has
not
been
super
responsive
like,
for
example,
I
open
up
an
issue
like
three
months
ago
to
get
access
to
their
sneak
stuff
and
there's
been
no
response
yet
so,
like
it's
gonna,
be
I'll,
ask
I,
think
because
we're
sandbox
and
not
like
incubated
anything
like
it's
the
lowest
priority
and
we'll
see,
especially
around
cubecon
time
frame,
maybe
tricky.
But
there
are
a
few
people
that
I
know
like
internally,
especially
that
that
may
be.
C
D
D
I've
done
one
about
open,
featuring
a
podcast,
but
it
was
in
French
and
I
would
I
did
it
is
because
I
was
doing
a
Meetup
before
for
go
theater
flag
and
some
people
reach
me
so
maybe
meetups
is
also
way
to
improve
on
communication
and
and
to
start
like,
maybe
having
a
presentation,
we
can
run
locally
on
on
meetups,
so
the
world
are
spreading.
Also.
E
E
C
That
yeah
yeah
there
was
there
was
someone
here.
We
could
maybe
try
to
redo
that
it
did
take
a
little
while
to
do
the
the
official
press
release,
but
we
could.
We
could
look
at
that
again
for
sure
it
could
even
be
a
slightly
after
cubecon
too,
if
we
had
to,
but
just
around
you
know
shortly
after
the
1.0
release
would
be
nice
to
have
something
officially
so
I'll
Circle
back
to
the
people
that
were
involved
in
that
one
and
see.
C
A
C
Yeah
perfect,
that
that's
that's
good
I'll
try
to
provide
an
update
at
the
next
Community
sync
and
I'll,
ask
around
here
and
see
if
we
have
any
like
what's
possible
and
if
you
guys
think
of
anything
too.
Definitely
let
me
know-
and
we
can
we
can
work
through
that
one
and
then
yeah,
like
I
mentioned
more
resources
on
the
docs
I
think
would
be
helpful.
I
think
it's!
We
have
a
little
bit
there,
but
definitely
not
enough
to
to
probably
be
self-sufficient.