►
From YouTube: OpenFeature Project Meeting - Mar 31, 2022
Description
Project meeting with discussion about: brand improvements, Updates and responsibilities, OTel semantic conventions, Glossary, SDK Research
Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ
OpenFeature website: https://open-feature.github.io/
B
A
B
This
one
water
is
definitely
a
big
one.
It's
it's
the
silicon
valley
of
canada,
okay,
and
so
we
get
some
of
their
like
orbiters
I'd,
say,
and
the
other
thing
that
does
contribute
some
to
to
windsor
is
we're
across
the
river
from
detroit.
So
I
used
to
work
in
detroit,
okay,
detroit's,
a
bigger
city,
obviously
in
the
us.
C
B
D
B
C
C
B
I
think
we'll
give
people
a
few
minutes,
I'm
sure
mike's
coming.
Oh
the
other
thing
that
could
be
a
complicating
factor
here.
I
hope
mike's
not
fallen
victim
to
it.
Is
that
the
wind
I
live
relatively
close
to
mike
he
lives
in
michigan,
and
the
wind
here
is
is
crazy
right
now,
so
we're
getting
almost
90
kilometer
an
hour
winds
so
so
like
about.
I
think
that's
about
55
in
in
us
units.
B
F
A
G
I
I
I've
also
posted
a
link
to
a
new
doodle,
seeing
as
the
other
one
had
expired,
where
you
can
put
in
your
preferences
for
the
meeting
times,
the
new
doodle
will
expire
on
the
15th
of
april,
so
you
have
two
weeks,
so
I'm
counting
on
you
other
than
that
I'll
pass
the
mic
on
to
mike,
which
has
prepared
a
few
things.
Well,
first,
we
have
introductions
for
new
people.
Sorry
yeah.
G
A
D
B
E
Perfect
all
right,
yeah,
I'm
mike
beamer
with
dynatrace
as
well.
I
think
most
of
you
have
probably
met
me
on
previous
calls
and
I
just
have
a
couple
topics
and
in
in
the
future
too.
If
anyone
has
any
agenda
items,
please
feel
free
to
add
them
to
the
stock,
and
then
we
can
definitely
kind
of
drive
the
discussion
going
for
you
know
going
forward.
E
First
off
a
topic
that
I
had
was
just
some
overall
brand
improvement,
so
it
kind
of
came
up
a
a
week
or
so
ago.
In
our
slack
channel.
Our
logo
is
certainly
a
placeholder
logo
and
I
have
an
issue-
a
github
issue
around
that
already
with
a
couple
of
just
potential
ideas
in
there.
If
you
have
any
ideas,
certainly
feel
free
to
just
include
it
in
there.
I
believe
and
correct
them
from
wrong
eloise
that
we
may
have
access
to
a
designer
next
week.
G
Yeah,
so
we
have
one
of
our
designers
being
available
there
and
his
request
was
more
or
less
to
give
them
more
background
and
the
projects.
Everything
will
be
like
what
the
project
represents,
what
it
does
and
also
ask
him
to
actually
ask
questions
there
and
share
it
with
you,
obviously,
on
the
issue,
and
he
can
then
make
some
proposals
for
what
the
logo
is
going
to
look
like.
G
E
E
I
suppose
we
did
get
a
new
website
domain,
so
openfeature.dev
that
was
in
a
roundabout
way,
donated
by
the
cncf,
even
though
we're
not
officially
a
project
as
part
of
it,
but
it
does
probably
show
at
least
a
level
of
interest
from
their
perspective,
which
is
great
news
for
us
going
forward
and
then
just
with
the
website
in
general
like
right.
Now,
it's
it's
pretty
basic.
So
it
is
something
that
we
should
consider
some
some
improvements
to
it.
E
If
there's
me,
you
know
minor
copy
that
you
want
to
suggest
that's
all
available
on
that
github
repo
as
well,
so
feel
free
to
open
a
pull
request,
or
you
know,
update
slack.
If
there's
anything,
that's
you
know
confusing
or
out
of
date,
all
right
next
topic,
kubecon
eu,
so
at
least
todd-
and
I
will
be
there
so
if
anyone
else
is
going
to
be
there,
I'd
love
to
meet
you
in
person,
maybe
schedule
some
some
workshops
or
whatever
makes
the
most
sense.
E
G
G
That's
it
that's
not
a
joke
or
anything.
Is
it
an
actual
boat
like
we,
and
we
will
obviously
invite
like
people
from
this
project
from
honestly
working
on
plus
some
people
from
the
toc
and
the
tags
that
are
working
there
and
yeah
get
them
on
a
boat
with
I
mean
remember,
what
do
you
do
in
valencia
when
you
get
on
the
boat?
It's
pretty
obvious.
E
C
E
Something
so
cool,
yeah
and
vendor
update
and
responsibilities
so
welcome
to
to
harness
and
launch
darkly.
It's
really
really
great
to
have
them
on
board.
I
don't
think
we
have
a
representative
from
harness
yet,
but
they
did
agree
to
be
a
part
of
this
project,
so
hopefully
we'll
start
seeing
them
in
in
future
community
meetings,
let's
see
here
the
other
pieces,
I've
been
asked
a
couple
times
how
how
the
different
vendors
can
really
help
contribute
to
this.
E
I
thought
someone
had
a
comment
but
yeah
basically
we're
working
on
the
the
research
phase
right
now,
but
really
quickly.
We
want
to
start
porting
that
over
to
like
the
the
initial
version
and
kind
of
an
experimental
version
of
the
spec
itself,
and
it's
going
to
be
extremely
important
to
make
sure
that
the
providers
for
the
the
different
vendors,
the
core
functionality
is
supported.
You
know
really
really
well
with
with
minimal
burden
on
the
developers
using
the
open
feature
sdks.
E
So
if
we're
going
to
make
changes
to
the
spec,
we
want
to
make
sure
that
all
the
downstream
providers
work
and
that
that
does
not
have
any
negative
impact
on
on
the
different
providers
that
have
already
you
know
written
integrations
for
this
system,
but
become
more
important
as
the
spec
stabilizes.
But
that's
something
that
kind
of
float
the
idea
out
there
that
we
do
need
to
make
sure
that
you
know
these
changes.
Don't
have
you
know
kind
of
adverse
effects
on
on
the
downstream
providers
and
then
the
last
one
was.
E
Right
now,
we've
signed
up
for
free
trials,
but
they
expire
in
some
cases,
so
perhaps
having
some
kind
of
either
shared
environment
where
we
can,
you
know,
be
invited
to,
and
we
can
you
know,
experiment
with
a
few
different
features
or
extending
a
free
trial,
at
least
for
you
know
a
couple
weeks
or
months.
So
if
you
represent
a
particular
vendor
and
you're
interested
in
in
you
know
helping
us
in
that
front,
definitely
let
us
know
any
questions
on
that
topic
or
feedback.
E
Nope,
okay
cool
next
one
is
I'd
like
to
propose
that
we
submit
a
pull
request
to
the
open,
telemetry
semantic
convention
related
to
feature
flagging.
It
is
recommended
to
keep
it.
You
know
you
know
project
and
vendor
neutral,
so
we
wouldn't
even
call
this
open
feature.
It
would
just
be
called
feature
flag
and
I
do
if
you
have
access
to
this
doc.
You
can
see
the
initial
github
issue
I
created,
which
refers
back
to
the
open,
telemetry
spec
and
what
their
you
know.
E
Naming
conventions
recommend,
and
I
did
take
an
initial
crack
at
what
I
thought
would
be
useful,
but
your
feedback
there
would
be
really
really
helpful,
also
an
open,
telemetry
maintainer.
I
talked
to
said
that
if,
if
we
can
get
some
vendors
to
basically
give
it
a
thumbs
up
thumbs
down-
or
you
know
some
some
suggestion-
modifications,
it
will
make
it
easier
for
us
to
eventually
merge
into
open
telemetry,
which
then
again,
that's
that's
in
the
open,
telemetry
specs.
E
That
should
mean
that
all
observability
vendors
should
be
aware
of
these
semantic
convention
properties,
which
means
that
you
know
whatever
we
put
in
there
would
could
be
handled
special
in
observability
like
uis.
So
I
think
todd's
going
to
show
an
example
of
that
in
just
a
little
bit
of
where
that
could
be
used,
but
think
about
how
you
know
you
can
see
like
the
flag,
ids,
the
back
end
provider,
maybe
even
links
back
to
like
managing
that
individual
flag.
E
C
That's
it
jing
is
worth
like
trying
to
do
like
a
survey
or
something
for
so
there's
the
different
hotel
providers.
Right,
like
I
don't
know
like
light
stuff
and
honeycomb
and
all
the
rest
of
them
is
it.
Is
it
worth
doing
like
a
survey
in
their
community,
slacks
and
or
mailing
lists
or
wherever
their
communities
are
to
ask
people
who
are
you
who
are
kind
of
already
instrumenting
their
future
flag?
What
what
they
use,
just
as
a
kind
of
starting
from
a
point
of
what
people
are
doing
today,
I
don't
know
yeah.
E
E
C
Mean
I
would
guess
most
of
people
I
would
guess
just
just
with
the
people
who
are
involved
in
in
this
group
are
probably
plugged
into
probably
collectively
all
of
the
various
providers
or
many
of
them
like
I
can.
I
definitely
could
post
on
the
honeycomb
slack.
If
there's
a
if
there
was
a
survey,
I
could
you
know
easily
just
post
it
on
the
honeycomb
slack
and
at
least
get
some
data
points.
That
way,
I'm
sure
there's
other
people
who
are
in
various
other
kind
of
communities
for
the
different
hotel
providers.
A
G
C
E
Perhaps
maybe
we
start
with
that,
then.
So,
if
you
do
have
some
channels
to
post
that
in
and
if
we
feel
like
a
survey
is
more
appropriate,
we
could
certainly
go
ahead
and
create
that
and
then
the
open
telemetry
maintainer
that
I
talked
to
recommended
that
we
could
basically
use
our
thread
in
open
feature
and
reference
that
in
the
pull
request
when
we
go
ahead
and
try
to
define
it
in
spec
and
that
should
be
sufficient
from
their
perspective.
E
B
Please
submit
a
pr
for
the
glossary
just
so
we
can
improve
our
communication,
especially
because
we're
not
always
in
real
time
meetings
like
this.
I
just
wanted
to
highlight
that.
I
also
wanted
to
talk
a
little
bit
about
some
of
the
recent
discussions
and
proposals
and
even
some
some
basic
implementations.
We've
done
so
for
those
of
you
who
followed
up
on
the
spec
discussion.
One
of
the
things
we've
spent
some
time
on
recently
is
adding
better
type
support.
B
We
did
some
surveys
of
existing
sdks
and
vendors
and
found
that
having
strongly
typed
flag
results
like
values
is
pretty
common
and
you
know
what
we're
trying
to
do
is
create
a
union
of
of
a
lot
of
these
sdks
and
unified
standards.
So
we
were
trying
to
kind
of
come
up
with
a
proposal
for
that
and
some
interfaces
for
it.
So
I
linked
a
discussion
that
I
thought
was
pretty
productive
and
I'm
going
to
share
my
screen
really
quickly
and
just
go
over
some
of
the
code.
B
B
With
actual
publicly
published
modules
for
various
languages,
but
I'm
going
to
go
quickly
through
what
we
have
here
and
do
a
little
demo
in
a
bit.
So
we
have
some
types
here.
We
have
this
features
type,
and
this
essentially
is
the
the
very
basic
api
for
getting
strongly
typed
flag
values,
and
we
have
a
number
of
providers
implementing
this
at
this
point,
so
you
can
see
they're
typed,
it's
also
basic.
B
In
this
case
you
know,
you
see,
string
flags,
you
see
number
flags
and
you
see
even
more
complex
json
flags
which
a
few
providers
support.
We
try
to
abstract
that
all
the
way
I'll
open
up
a
particular
implementation
kind
of
at
random.
Here
this
is
the
cloud
views
provider
which
steve
arch
who's,
not
with
us
today,
it's
from
hobbies
he
initially
committed
and
we've
since
adapted
it
with
the
moving
interfaces.
B
But
you
can
see
here
we
have
you
know
the
same
interface
here
just
implemented
by
this
provider
and
there's
a
there's
a
little
bit
of
there's
a
little
bit
of
basic
logic.
We
have
some
convenience
methods
that
are
exported
by
the
sdk
as
well,
that
help
kind
of
take
the
the
provider
specific
flag
responses
and
do
some
validation
just
to
make
them
the
behavior
as
consistent
as
possible
across
all
of
all
the
different
providers.
B
And
if
you
look
at
the
consuming
code,
obviously
it
has
no
idea
what
the
underlying
provider
is,
but
you
can
see
that
we
now
have
type
safe
values.
We
have
booleans
for
booleans,
we
have
strings
for
strings
for
strings,
so
this
value
is
a
is
a
string
so
that
that's
the
that's
the
introduction
to
this
repository
for
those
of
you
who
aren't
familiar
with
it.
It's
really
a
good
experimentation
ground.
But
again
I
want
to
highlight
that's
all
this
is.
This
is
just
for
experimentation.
B
B
B
It
may
seem
a
little
bit
premature
for
something
like
that,
but
I
think
it's
actually
a
very
important
topic
to
to
get
a
handle
on
early
because
we're-
and
you
know
we're
an
sdk-
that's
trying
to
abstract
a
lot
of
functionality.
We
want
to
maintain.
You
know
a
high
amount
of
extensibility
and
exposed
points
for
integration,
while
also
maintaining
a
lot
of
simplicity
for
the
very
basic
use
cases.
So
how
we
kind
of
do
advanced
features
how
we
do
integrations.
B
We
need
to
figure
that
out
early,
so
another
interface,
we
kind
of
came
up
with
and
is
discussed
in
some
proposals
is
this
concept
of
hooks,
so
hook
is
basically
an
arbitrary
extension
point
where
you
can
register
specific
logic
before
a
flag
evaluation
after
and
in
a
few
other,
what
we're
referring
to
as
life
cycle
events
during
flag
evaluation.
So
these
give
a
lot
of
opportunity
for
extension,
without
introducing
hard
dependencies
in
our
sdk.
B
Open.
Telemetry
is
obviously
a
first
class
use
case
for
us,
so
this
would
probably
be
a
good
example
of
something
that
we
would
implement.
We'd,
implement
an
open,
telemetry
hook
and
publish
it
so
that
consumers
could
take
advantage
of
open
telemetry
without
forcing
open
telemetry
as
a
dependency
of
just
using
open
feature.
B
So
here
you
can
see
we
have
a
hook
open,
telemetry
hook.
It
extends
our
it
implements
our
hook,
interface
and
the
before
it
sets
up
some
open
telemetry
span
information
and
in
the
finally,
it
basically
ends
the
span.
So
it
ends
the
telemetry
data,
there's
also
some
exception
handling
in
our
in
our
error.
B
B
B
C
B
G
So
it's
not
like
limited
to
cncf
projects
that
are
already
inside
of
the
cncf,
but
also
for
riders
to
gain
more
like
interest
and
feedback
from
people
like
the
question
that
pete
brought
up
as
well.
I
tell
you
this.
They
are
some
intellectual
data
today,
usually
it's
a
20-minute
presentation.
I
think
we
have
plenty
of
material
and
we
could
easily
share
it
with
the
app
delivery
community.
You
don't
actually
next
week,
I'm
just
saying
next
week,
there's
more
like
a
slot
being
available
where
you
could
share
it
in
case
you're
interested.
E
E
B
E
D
B
Okay,
sorry
about
that,
all
right,
so
yeah
demo
latest
it
wouldn't
be
a
demo
if
if
there
wasn't
some
of
it,
so
I
fixed
my
compilation
issue
here
so
anyway,
I'll
get
back
to
the
example
hook,
so
the
open
telemetry
hook
like
I
said
we
have
it
before,
even
after
I'm
starting
my
demo
here
and
I'll
open
the
demo
page.
So
this
is
a
very
simple
demo
it
by
default.
B
It
just
serves
this
a
very
basic,
welcome
message
and
then
you'll
see
if
we
go
into
launch
darkly
and
we
change
the
message
hit,
save
in
a
few
seconds.
This
should
be
updated.
So
now
you
can
say
it's
you
can
see
it's
the
next
gen
api.
So
that's
just
the
basic
functionality
that
we've
covered
before
with
this
repository,
the
new
stuff
that
is
uncovered
with
our
new
hook
is
our
open
telemetry.
So
I'm
using
zipkin,
which
basically
is
an
open,
telemetry,
compatible
metrics
analyzer.
B
I
can
run
a
query
and
I
should
be
able
to
see
numerous
a
few
activities
here,
but
yeah
you
can
see
this
one.
This
is
the
api
call
that
I
was
showing
and
the
interesting
thing.
If
we
dig
into
this,
you
can
see
the
stack
and
you
can
see
on
the
stack.
We
have
a
feature
flag.
Boolean,
you
can
see
the
feature
flag
name,
you
can
actually
see
the
feature
flag
id.
You
can
see
the
underlying
provider.
B
You
can
see
the
service
name,
all
this
kind
of
exciting
stuff
yeah.
So
so
this
is
the
kind
of
data
that
we
could.
We
could
hypothetically
expose.
You
know,
flag
values,
all
kinds
of
things,
and
this
is
this
is
really
the
key
of
the
extensibility.
You
know
we're
talking
about
we're
we're
saying
we
don't
have
a
hard
dependency
on
open
telemetry,
but
you
can
see
how
these
kinds
of
integrations
would
be
would
be
very
useful.
B
Other
use
cases
to
be
considered
here,
like
I
said,
validation,
so
one
that
could
be
very
interesting
say
you
have
a
feature
flag
that
controls
the
color
of
a
banner
and
that
banner
is
a
csx,
a
css
hex
value
you
if
you
could
leverage
an
after
hook.
That
would
take
that
value
and
validate
it
just
to
make
sure
it's
a
valid
hex
value.
B
There's
also,
you
know
arbitrary
ways.
You
could
transform
the
response.
Logging
is
another
one,
so
you
can
see
we've
kind
of
injected
some
logging.
Here
we
have
another
hook,
implementation
again,
very
basic.
It
just
does
some
console
logging,
but
you
can
see
the
life
cycle
of
a
flag
evaluation.
Just
with
this
kind
of
stuff,
we
can
add
new
new
hooks
as
well
new
hook
functionality
as
well.
B
Especially
when
I
use
it,
yeah
absolutely
100
yeah,
that's
another
very
valid
use
case
and
that's
kind
of
why
we
have
this
error
hook,
so
the
error
hook
only
evaluates
in
the
case
of
an
error.
So
if
there
was
some
kind
of
error,
condition
and
we'd
have
to
in
the
spec
to
find
what
those
would
be
right,
so
that
could
be
couldn't
connect
to
the
provider.
You
know
an
error,
a
type
error
with
the
provider.
B
You
would
get
that
information
in
the
error
hook
and
you
could
interrogate
it
additionally,
we're
also
thinking,
probably
if
you
throw
in
an
error
hook,
it's
not
something
that
the
api
is
going
to
handle
so
for
for
having
like
fail
loud
implementations,
you
could
have
an
arrowhook
that
simply
rethrows
errors,
so
that
would
just
be
a
way
to
add
visibility
to
the
system
we
want
in
general.
I
think
we
want
the
api
to
behave
in
such
a
way
that
failures
never
cause
runtime
issues.
B
G
I
think
I'm
talking
about
a
different
use
case,
so
assume
that
I
have
a
feature
flag
that
evaluates
to
true
and
I'm
looking
at
the
the
trace
that
you
show.
But
I
have
no
idea
because,
like
the
rule,
handling
is
done
in
the
feature
flagging
back
end
and
I
might
want
to
find
out
like
why
did
it?
Why
is
it
true?
G
It
should
like
always
be
false
and
then
say
yes,
it
is
true
because
of
like
I
don't
know,
the
region
is
set
to
something
specific
and
or
the
rule
that
was
triggered
was
this
type
of
rule.
It
might
be
more
of
a
debugging
functionality,
because
you
don't
want
to
send
this
back
verbally,
all
the
time,
but
at
least
providing
an
ability
that
you
can
put
this
into
a
trace.
Like
I
see
we
deployed
a
system,
you
have
all
the
rules,
but
the
system
is
kind
of
behaving
funky
and
you
have
no
idea.
G
They
can
switch
it
off
and
then
see
it
in
the
creases
why
things
are
happening
because
maybe
well
like
sticking
to
this
example.
People
are
evaluating
the
region
and
they
would
have
turned
it
on
for
japan.
Realizing
it's
not
on
for
japan
and
then
seeing
that
they're
validating
the
ip
of
the
gateway,
rather
than
they
act
forward
for
fe,
realizing
it
and
then
being
able
to
fix
that
kind
of
problem.
B
Right,
yeah,
yeah,
that's
a
good
point.
I
I
think
the
there's
a.
I
see
a
lot
of
value
in
what
you're
proposing.
I
think
the
underlying
challenge
would
be
getting
that
information
from
the
future
future
flag
provider
right.
So
when
a
decision
is
made,
you
know,
there's
context,
that's
injected.
I
can't
say,
for
example,
how
many
feature
flag
providers
are
doing
that
evaluation
on
the
client.
I
think
most
of
them
are
there's
also
a
few
that
I
believe,
do
them
in
the
server.
C
Agreed
maybe
like
a
kind
of
nice
generic
extensible
way
of
doing
it
would
be
to
let
providers
attach
kind
of
arbitrary,
like
essentially
like
attributes
in
hotel
right
where
you
could
attach
kind
of
like
metadata
about
the
flagging
decision,
and
that
would
be
available
on
the
hook
context.
And
then,
in
turn
like
when
you're,
when
you're
creating
those
hotel
attributes.
You
could
add
whatever
that
mess
stated.
B
Yeah,
that
makes
a
lot
of
sense.
I
I
agree
that
that
could
be
a
good
approach
and
it
sounds
somewhat
similar
to.
I
think
the
problem
we're
going
to
face
with
defining
the
context
yeah.
So
we
have
context
already
in
a
lot
of
providers
and
exactly
what
parameters
are
in
there
exactly
how
they
map,
from
from
some
kind
of
open
feature
spec
to
the
internal
provider,
understanding
of
those
same
parameters-
I
I
think,
there's
there
may
be
some
overlap
there,
but
I
agree
yeah.
That's
that's!
Probably
a
good
approach.
E
In
the
fact
that
I
think
it
does
exist
in
some
providers
already
like
the
ability,
I
think,
to
launch
darkly,
for
example,
you
can
actually
see
like
the
the
rule
evaluation.
If
you
do
like
the
detailed
method,
so
some
we
can
maybe
look
there
start
and
see
what
they
expose
and
maybe
just
encourage
other
vendors
to
add
support
for
it
and
it's
like
kind
of
optional.
It's
certainly
nice
information,
but
it
wouldn't
be
a
hard
requirement
to
have
it
so
by
showing
the
value
of
it,
I
think,
makes
it
definitely
encourages
other.
E
K
B
B
So
I
think
I
think
that
puts
us
in
a
situation
where
we
have
to
treat
them
treat
them
differently,
but
certainly
there's
going
to
be
a
lot
more
to
consider
when
we
talk
about
a
client-side
implementation,
yeah-
and
that's
that's
a
great
point
as
well-
how
much
of
that
is
going
to
be
exposed?
Obviously,
there's
security
and
performance
implementations
with
that
when
we
talk
about
client-side
sdks.
B
Is
there
any
additional
comments
or
questions
like
the
github
issue,
so
that
this
code
is
this
code
is
obviously,
as
you
witnessed
at
the
beginning,
still
very
much
in
progress,
but
I
I
will
have
a
pr
open
very
soon
with
a
with
a
summary
of
this
kind
of
functionality,
and
there
is
an
issue
that
was
linked
in
the
discussion,
so
feel
free
to
take
a
look
at
that.
If
you
want
to
comment
on
on
these
hooks,
this
is
again.
C
I've
just
got
one
question.
Maybe
I
should
just
ask
this
in
the
in
the
github
issue,
but
it
feels
like
a
big
kind
of
decision
to
be
made
is
whether
these
hooks
can
can
like
mess
with
they're
like
middleware,
where
they
can
kind
of
change
things
as
things
are
flowing
through
them,
or
are
they
hooks
where
they
can't
really
mess
with
things
and
they're
just
kind
of
like
you
know,
like
a
one-way
kind
of
like,
like
an
observer
of
the
system
that
can't
kind
of
like
mess
with
the
system.
B
Yeah,
I
agreed,
I
think
it's
a
great
point.
This
is
the
type
of
thing
that
I
think
we
need
to.
We
need
to
decide
upon
on
philosophically
I'm
certainly
okay
with
having
hoaxes
like
pure
side
effects,
with
no
overall
impact
on
on
return,
values
or
something,
but
I
can
see
the
value
in
going
the
other
way
as
well,
and
we
may
want
two
different
artifacts.
Maybe
we
want
a
certain
type.
E
F
Yeah
quickly,
asking
always
actually
maybe
you
can
provide
a
little
bit
of
background
here.
What
we
discussed
is
that
it
might
be
worthwhile
creating
a
buzz
on
on
the
topic
via
press
releases,
collaborating
on
on
a
communications
initiative
there.
Otherwise,
maybe
you
could
share
a
little
bit
regarding
the
rationale
of
this,
because
I
think
you
had
something
on
your
mind
why
press
release
might
come
in
handy
here.
G
G
What
it
is
about,
and
getting
this
out
by
cubecon
and
then
or
helping
to
organize
around
this,
I
think
it
would
make
a
lot
of
sense.
It
actually
would
help
us
also
within
the
cncf
ecosystem,
because
right
now
the
people
know
about
the
project.
Also,
the
initial
set
of
contributing
companies
here
is
actually
quite
impressive.
G
I
know
that
this
is
going
to
be
most
likely
quite
some
work
to
get
so
many
marketing
and
pr
people
in
the
rooms.
I
totally
understand
if
you
do
not
want
to
participate
or
just
want
to
do
it
on
a
personal
like
from
a
personal
perspective,
but
not
from
your
company
perspective.
Still,
the
the
approach
would
be,
and
that's
why
we
brought
our
team
here
as
well,
and
I've
seen
this
like
work,
for,
I
think
the
initial
open
telemetry
one
the
idea
to
work
on
one
google
doc,
which
is
more
or
less
the
blueprint
boilerplate.
G
What
we
will
all
be
talking
about
in
the
in
the
press
release
and
then
everybody
can
obviously
contribute
them
to
their
after
their
liking
of
the
bringing
their
own
company
focusing
there,
but,
like
the
gist
of
the
message,
should
be
the
same.
So
the
idea
was
to
get
started
on
this
and
also
propose
it
if
you're
interested
in
joining
these
activities
to
be
apr
and
marketing
teams
work
on
this,
ideally
rather
quickly,
because
kubecon
is
actually
mirrored
and
most
of
us
think
and
they're
not
like.
G
G
So
first
question
who
wants
to
like
be
part
of
this,
either
with
the
blog
post
or
with
the
press,
release
and
wants
to
see
it
and
b,
who
is
obviously
also
willing
to
involve
their
their
company
teams,
do
to
get
this
out
of
the
door
chef
here
volunteered
to
help
us
like
coordinate
us
and
enjoy
getting
this
out
of
the
door
in
time
again.
The
rest
is
obviously
collaborative
effort.
G
I
just
wanted
to
bring
it
up
right
now.
It's
now
end
of
march.
It
just
gives
us
like
one
and
a
half
months
which,
even
for
pr
and
approval
timelines
for
most
companies
should
still
be
fine.
So
that's
the
background
on
this
one
and
again
it
also
was
one
of
the
recommendations.
If
you
do
this,
it
will
most
likely
also
accelerate
the
cncf's
acceptance
as
well,
because
I
mean,
if
I
just
look
at
it
from
that
perspective.
F
So
basically,
a
quick
recap
would
be
that
we,
whoever
wants
to
join,
takes
part
in
an
initiative
that
we
orchestrate
a
couple
of
of
press
releases
or
we
coordinate
and
online
a
couple
of
press
releases.
We
would
come
up
with
building
blocks
to
ensure
that
we
all
use
like
matching
messaging
actually,
and
that
would
allow
everybody
who
wants
to
chime
in
to
create
awareness
for
the
respective
company
plus,
of
course,
for
the
for
for
the
new
standard
and
to
increase.
G
Yeah
and
it's
oppression-
it's
just
I
mean
it.
It
is
a
project
that
people
should
be
aware
of,
of
course,
so
yeah,
please
add
yourself
in
case.
You
want
to
join
and
then
also
add
your
email
address
in
well.
We
don't
have
all
the
email
addresses
of
people
which
we
wouldn't
need
that
we
should
reach
out
to
you
about.
H
H
G
E
Yeah
cool,
I
guess
to
quickly
summarize
then
so
we
I'm
gonna,
try
to
get
some
documentation
on
how
you
can
add
a
provider
to
our
experimental
repo
once
that's
in
place.
I
would
certainly
encourage
you
to
do
that,
especially
if
you
represent
a
vendor,
but
if
you
just
have
interest
in
how
this
could
work,
you
know
play
around
with
that.
I
think
todd
if
you
could
also
maybe
add
some
docs
on
on
how
to
build
a
hook.
E
You
know
some
really
basic
information
on
that
as
well,
so
same
thing,
you
can
build
a
hook
kind
of
experiment
with
the
life
cycle
there.
Any
feedback
you
know
is
great
in
those
issues
and
then
hopefully
we
can
start
getting
this
experimental
project
in
a
good
enough
state
where
we
can
at
least
start
like
an
experimental
spec
effectively.
We
need
to
start
porting
over
the
the
obvious
pieces.
E
There's
some
stuff,
that's
very
obvious
that
we
can
start,
including
in
the
specs,
so
starting
to
get
that
going
as
quickly
as
possible.
Hopefully,
that's
something
that
we
can
chat
about
the
next
community,
sync
where
we
can
show.
Maybe,
like
the
initial,
you
know
part
of
the
spec,
so
you
know
it
gives
us
a
better
framework
to
to
start
making
some
some
modifications
to
that
from
there.
Then
I
think
it's
it's
a
matter
of
basically
implementing
that
spec
in
a
handful
of
languages
and
that's
something
that
we
can
also
chat
about.
E
B
I
might
jump
in
there.
One
thing
that
I
I
would
like
to
highlight
is
we
do
have
a
very
basic
provider
that
just
uses
environment
variables.
So
if
you
want
to
toy
with
some
of
the
really
basic
stuff
in
the
sdk,
you
can
use
the
environment
variable
one
as
just
as
a
purely
conceptual
toy.
I
I
think
it
would
be
nice
sooner
rather
than
later,
as
we
start
the
spec
to
come
up
with
a
cloud
native
coupe
native
provider.
B
I
think
that
we
have
right
now
we're
in
a
place
where
we
have
again
to
kind
of
do
this
work
of
unioning
a
whole
bunch
of
sdks
and
functionality
and
conceptual
back-ends
across
many
different
vendors
and
kind
of
once.
We
start
to
feel
solid
about
that.
I
think
it
puts
us
in
a
place
where
then
we
can
come
up
with
a
our
own
cloud
native
provider,
that
kind
of
would
conform
to
to
the
interface,
that's
slowly
being
developed
as
a
union
of
all
those
different
features.
B
I
hope
that
answers
the
question,
but
I
feel
like
I
feel
like
the
as
soon
as
we
start
to
have
a
very
like
alpha
sdk.
It
seems
like
a
good
time
to
to
maybe
look
into
a
very
basic
crd
based
cloud
native
type
provider.
I
don't
know
if
mike
agrees
with
that
or
anyone
else
on
the
call
does,
but
that's
my
kind
of
feeling
in
that
direction.
E
Yeah,
I
mean
I
think
I
mean
if
someone
has
a
strong
interest
in
that
area
and
expertise,
especially
like
getting
getting
the
discussion
happening,
could
probably
happen
now.
We
know
that
there's
some
basic
functionality
that
has
to
be
in
place
for
this
to
work,
but
right
now,
we've
just
been
focusing
more
on
the
spec
side,
so
it
really
kind
of
from
like
a
a
resourcing
perspective,
haven't
had
the
opportunities,
but
it
makes
sense
to
start
on
it
as
soon
as
possible.
E
K
E
Yeah,
I
mean
there's
a
little
bit,
so
we
have
like
a
kubernetes
operator
repo
in
there,
but
it's
basically
just
kind
of
a
high
level
description
of
what
we
were
hoping
to
achieve
and
the
the
basic
concept
is.
It
would
just
be
like
another
provider,
just
like
the
launch
darkly
provider
or
something
this
would
be
like
a
cloud
native
provider
which
would
take
advantage
of
some
some
of
the
kubernetes.
You
know
specific
patterns
like
like
the
operator,
and
you
know
sidecar
things
like
that,
and
we
wanted
to
provide
something.
E
So
if
you
were
in
the
kubernetes
world
just
getting
started
with
feature
flagging,
you
could
use
this
like
cloud
native
provider
to
basically
immediately
feel
the
benefits
of
future
flag
management,
and
then
it
could
all
be
kind
of
part
of
the
story
to
replace
that
with
whatever
provider
you
need
in
the
future
to
serve
your.
You
know
your
your
future
goals
so,
basically
just
lowering
the
barrier
to
getting
started
with
feature
flag
management.
E
Yep
and
at
a
high
level
too,
we
were
hoping
to
have
the
evaluation
logic
in
a
sidecar
process
that
could
be
attached
to
the
pod,
and
then
that
way
we
could
basically
write
the
evaluation
logic
in
a
single
language,
and
then
you
know
open
feature:
you'd
register
the
cloud
native
provider.
It
would
just
communicate
with
that
process
and
handle
flag
evaluations
to
kind
of
keep
things
simple.
It
also
has
some
interesting
potential
benefits
like
if
you
look
at
like
k
native
or
something
that's
like
time.
E
Sensitive,
startup
or
you
wouldn't
want
to
load
the
sdk
and
have
it
pull
in
the
configurations.
You
could
actually
offload
flag
evaluation
onto
a
currently
running
process,
so
it
is
pretty
interesting.
We
also
were
talking
about
on
that
process
could
also
be
another
interesting
touch
point
for
for
providers
to
hook
into
as
well.
So
you
could,
theoretically
have
like
a
launch
darkly
provider
at
that.
E
Sidecar
process
level
effectively,
and
maybe
we
could
even
you
know,
come
together
and
make
kind
of
the
operator
part
work
with
any
kind
of
back-end
provider.
So
if
you
happen
to
be
in
kubernetes
and
you
felt
like
there's
an
architectural
advantage
of
moving
flag
evaluation
to
a
sidecar
or
maybe
like
a
demon
set,
you
could
just
take
advantage
of
that.
So
it's
still.
E
G
I
think
we're
like
we're
putting
up
like
the
whole
thing
in
here,
and
maybe
we
should
put
it
into
some
issues
like
there's
a
whole
implementation,
so
I'm
much
more
like
okay,
it's
like
people
want
to
learn
more
about
open
future
and
how
it
could
feel.
This
was
really
like
back
to
diana's
point
about,
like
a
very
simple
crd.
G
I
think
it
helps
us
to
get
some
understanding
out
there
and
some
momentum
in
the
community
that
they
can
play
around
with
if
they
can
do
something
that
they
actually
enjoy,
even
with
the
earliest
case,
as
as
I
like
it
because
right
now,
they
kind
of
can't
do
this.
That's
why
I
would
go
like
really
super
simple.
This
is
the
crd.
That's
the
feature
even
saying
that
this
is
not
stable,
so
most
likely
going
this
way.
C
Gonna
get
more
give
more
people
you're
gonna,
if
you
want
to
give
people
a
way
to
play
with
this
idea,
having
early
providers
with
the
vendors
is
going
to
get
way
more
people
like
if
someone.
If
someone
is
interested
in
trying
out
this,
the
the
sdk
and
the
spec
they're,
probably
they're,
already
running
a
feature
flagging
system
and
just
like
plugging
into
that
provider
would
be
way
less
barrier
to
entry
than
hey
stand
up
start
doing
feature
flagging
from
scratch.
C
Using
this
experimental
feature,
flagging
provider
like
I
feel
like
you'll,
get
more
it's
a
lower
barrier
barrier
to
entry
to
say
if
you're
using
launch,
darkly
here's
an
experimental
provider
with
this
sdk
versus,
if
you're,
using
any,
if
you're,
whatever
feature
flagging,
you're
using
or
not,
you
know,
start
running
a
brand
new
feature.
Flagging
implementation.
B
B
Can
just
we
can
just
decide
what
what
we
want
to
what
we
want
to
do?
First,
what
we
want
to
do?
Second,
but
I
I
mean,
if
you're
in
a
coupe
native
environment
you're
already
you
already
understand
kubernetes,
you
already
understand
crds,
and
maybe
you
even
have
some
has
some
understanding
in
terms
of
writing.
Your
own
operator
and
you've
just
never
been
in
the
future
flag
world.
It
could
be
a
really
good
point
of
entry
for
people
to
get
into
the
feature
flying
world
because
they
they
do
understand.
C
That
makes
sense
to
me.
I
like,
I
think,
to
me.
I
think
what
would
be
important
to
get
right
from
the
beginning
is
not
to
conflate
these
two
things
too
much,
because
it's
gonna
be
really
confusing
for
people
like
I,
I
think
I
saw
a
tiny
bit
of
like
like
daniel's
kind
of
confusion
of
like
wait
is
open
feature
like
a
us,
an
sdk
for
for
kind
of
like
standardizing,
how
we
use
feature
flags
or
is
it
a
feature,
flagging
kind
of
providing
system?
C
C
So
I
think,
having
open,
telemetry
and
zipkin
or
jager,
or
something
like
that,
it
helps
people
who,
like
people
who
are
brand
new
to
this
and
don't
know,
what's
going
on,
there's
gonna
be
a
ton
of
confusion.
Otherwise,
I
think
of
like
oh
yeah,
have
you
heard
about
that
open
feature
thing?
It's
like
a
kubernetes
based
open
source
feature
flagging
implementation.
Someone
else
is
like
wait.
I
thought
it
was
like
an
sdk
for
blah
blah
blah.
E
C
C
G
We
create
dark
tests.
I
think
it
would
make
them
clear,
like
using
open
feature,
even
in
the
alpha
stage,
with
launch
directly
with
scout.
Please
and
then
obviously,
the
various
participants
can
just
submit
the
page.
I
kind
of
make
it
work
with
that
one
linking
even
to
the
very
experimental
one
I
think,
would
make
it
way
more
obvious,
because
I
would
click
on
dots
and
they
could
see.
Okay.
This
is
how
you
use
it
with
providers,
and
this
is
like
how
you
maybe
use
it
like
this
environment.
G
Where
else
it
would
make
it
to
your
point
of
view,
I
think
much
clearer,
because
that's
the
first
thing
you've
been
using
yeah
like
every
feature
playing
what
is
good
exactly
clicking
on
the
docs
and
if
that's
getting
started
with
long
story
which
calculates
with
yeah
like
go
after
solutions,
it
becomes
pretty
obvious
and
okay,
there's
also
like
a
simplistic
implementation
like
the
one.
We
have
right
now
with
environment
variables,
I'm
kind
of
like
getting
the
idea.