►
From YouTube: OpenFeature - Project Meeting, February 2nd, 2023
Description
Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ
OpenFeature website: https://open-feature.github.io/
A
C
B
B
A
C
C
C
All
right
and
then,
if
you
don't
mind,
just
adding
yourself
as
a
participant
on
here,
we
can
go
ahead
and
kick
it
off.
If
you
have
any
agenda
items
feel
free
to
add
them
looks
like
we
have
a
fairly
short
a
list
of
agenda
items
to
cover
so
yeah.
If
we
wrap
up
really
we
get
some
time
back
so
yeah,
Todd,
I,
guess
you're
up
first,
so
go
ahead!
Please
yeah.
A
A
Okay,
so
I
wanted
to
give
a
quick
update
on
on
client
side.
So
one
of
the
things
that
came
out
of
last
meeting
the
client-focused
one
was
kind
of
have
a
vendor
survey.
This
is
Pete's
idea,
and
so
you
can
see
it's
linked
here
right
now.
It's
just
a
markdown
document
and
and
GitHub
I
might
convert
it
to
something
a
little
bit
easier
to
send
out,
like
maybe
a
Google
survey
or
something
but
it'll
basically
be
that
same
content,
so
I'm
interested.
A
If
anybody
has
opinions
on
that,
but
at
some
point
we're
basically
going
to
send
that
out
to
to
vendors
as
well
as
people
who
we
know
are
somewhat
familiar
with
the
project
and
have
their
own
internal
feature:
flag
implementation,
just
to
kind
of
have
them
vet,
our
client-side
stuff
and
more
of
a
push
or
Quarry
type
pattern.
Instead
of
just
hoping
them
to.
You
know
they
stumble
on
the
spec
PR
or
some
of
the
ofaps.
So
please
make
comments
on
that.
A
If
you
think
anything
else
should
be
included,
we're
going
to
send
it
out
the
optimistical
My
optimistic
goal
may
be
overly
optimistic,
is
to
get
that
spec
PR
emerged
next
week.
Ideally,
that's
that's,
probably
overly
optimistic,
but
I
think
you
know
if
we're
targeting
that
we'll
we'll
we'll
get
immersed
as
soon
as
possible.
So
the
other
thing
I'm
personally
going
to
do,
is
updates,
summarize
and
and
prompt
some
people
who
have
commented
already
in
the
relevant
ofeps,
which
are
linked
in
the
issue.
A
I
also
have
linked
in
the
in
the
document
in
the
Google
Doc,
which
summarizes
things
I.
Think
some
of
those
are
fairly
non-controversial
and-
and
some
of
them
are
more
controversial,
so
yeah,
hopefully
I
can
get
some
merch
soon,
maybe
even
today,
Merchant
approved
and
then
the
ones
that
still
need
to
be
talked
about
will
stay
open.
Obviously,
and
then
there's
there
were
some
takeaways
from
the
last
meeting
that
are
also
linked
there
in
the
last
Point.
B
A
I
think
that's
the
update
on
client
side.
We
really
want
to
keep
that
stuff
moving.
We
want
to
keep.
Ideally
we
want
to
get
stuff
merged.
So
if
you
have
thoughts
on
there,
if
you
haven't
reviewed
the
spec
change
or
the
ofeps,
the
related
ofeps,
or
even
looked
at
that
issue,
I'm
talking
about
please
revisit
that
stuff,
but
I
don't
want
to
belabor
that
point
too
much.
A
Does
anybody
have
any
questions
or
comments
on
the
client
stuff
before
we
move
on
to
my
next
point
cool?
So
the
next
thing
I
want
to
talk
about
more
in
a
more
General
level.
I,
don't
think
we
necessarily
need
to
dive
into
each
of
the
specific
examples,
but
I'd
just
like
to
talk
about
it
and
see
if
anybody
has
any
any
kind
of
opinions
or
takes
is
breaking
changes
in
sdks
that
aren't
particularly
spec
related.
A
F
Issue
to
comment
down
because,
like
from
other
experiences,
I
can
tell
that
you
get
your
users
very
frustrated
very,
very
quickly
on
breaking
changes.
Foreign
I
think
we
should
be
very
obvious
and
like
stating
them
very
early
on,
so
what
we
ended
up
doing
in
another
approach
that
we
announced
them
way
ahead
of
time.
Let
people
comment
on
it
so
that
they
can
prepare
I,
think
we
learned
a
fair
share
there
like
in
the
beginning,
we
had
some
say:
okay,
we've
just
comment.
F
B
E
This
is
this
is
one
of
the
biggest
problems
with
running
across
so
many
different
languages
is
some
of
them
have
mechanisms
for
communicating
that
common
places
people
go
to
communicate
that
or
look
for
that
if
they're
going
to
upgrade
a
package,
obviously
for
the
people
that
literally
go
and
change
a
major
version
in
a
block
file,
then
that's
you
know:
they've
got
the
gun
and
it's
aimed
at
their
foot,
but
it's
it's!
It's
difficult!
Learning?
Where
yeah,
how?
C
Yeah,
that
seems
to
be
especially
the
case
with
the
the
go
one.
So
that's
what
we
ran
into.
We
decided
that
we
were
going
to
move
to
go
118
as
the
minimum
go
requirement
and
we're
like
well.
That
makes
sense
to
do
a
version
two
turns
out,
it's
quite
tedious,
to
say
the
least,
to
do
like
major
version
bumps
and
go,
and
it
also
after
kind
of
exploring
like
otel,
for
example,
did
not
treat
that
as
a
major
version
release.
C
C
We
have
to
do
a
lot
of
kind
of
tedious
work,
and
so
we
want
to
make
sure
that
we're
we
want
to
commit
to
to
basically
either
having
a
separate
Branch
for
version
two
or
like
a
subfolder
or
whatever,
and
that
seems
very
tedious,
especially
if
we're
going
to
bump
Go
versions
every
six
months
or
a
year
or
something.
So
that's
why
we
wanted
to
give
people's
thoughts
there.
But
that's
ghost
specific,
you
know
we
could
treat
that
very
differently
in
JavaScript,
for
example.
So.
A
Yeah
yeah
I
think
to
Eloise's
point
the
the
thing
that
I'm
I'm,
seeing
with
the
go
issue
and
it's
kind
of
intersects
with
what
Ben
said
too
semper
is
one
thing
like
we:
we
can.
We
we're,
obviously
we're
gonna
use
them
for
our
advantage.
That's
what
it's
there
for,
but
then
there's
mechanisms
beyond
that.
A
F
Think
the
point
is
I
think
we've
definitely
documented
I.
Think
half
a
year
is
also
Fair,
like
giving
people
half
of
your
time
to
change
or
upgrade
the
code
being
very
specific.
What
needs
to
be
changed
and
also
like
doing
an
assessment.
This
is
like
a
minor
change
that
they
might
need
to
do,
or
might
they
really
have
to
go
over
their
entire
code
base,
which
should
not
be
that
problematic
and
the
question
is:
what
does
the
change
actually
mean?
F
Can
I
still
build
and
run
against
an
older
version,
because
we
didn't
change
like
how
a
provider
works
like
if
you
only
change
the
SDK
but
it'll
provide
us
did
the
same?
I
might
stay
on
an
old
SDK
version
almost
like
making
a
number
of
okay.
This
is
what
we
consider
a
like
different
levels
of
impact.
This
is
how
we're
going
to
handle
them.
Then
work
with
the
SDK
providers
in
the
languages
in
JavaScript.
You
will
see
this
way
in
this
language.
F
Guidance
that
we
communicate
to
people
I
think
the
key
is
to
have
it
on
multiple
channels.
I
think
posting
it
on
the
slack
Channel
from
experience
is
not
enough,
because
a
lot
of
people
might
have
looked
there
if
it
pops
up
during
every
local,
build
that
you're
running
and
you
keep
ignoring
it.
I
mean
at
some
point.
F
We
have
to
assume
grown-up
developers
there
and
will
it
at
some
point,
break
their
build
after
half
a
year,
probably
but
not
for
half
a
year,
but
we
try
to
avoid
this
as
much
as
possible
and
also
allow
them
that
they
can
stay
on
older
versions.
I
think
that's
also
key
to
to
Ben's
point.
If
they
run
on
latest
with
certain
mitigation
strategies,
don't
use
latest,
it
will
still
work
like
your
entire
app's
going
to
work
all
if
your
providers
are
going
to
work
and
he
had
half
a
year
time
I
mean.
F
E
This
that's
an
interesting
point
as
well,
so
there's
gonna
need
to
be
forever
for
every
open
feature:
SDK
provider
there's
going
to
need
to
be
a
range
of
provider,
SDK
versions
that
are
valid
for
that
provider
right.
So
that's
yeah,
so
there's
kind
of
two
dimensions
of
version
and
complexity.
Here,
as
opposed
to
the
one
that
I'm
used
to
and
that's
tricky,
but
I
guess
you
can
get.
You
know
we
support
versions.
You
know
2.x
to
3.2
dot,
y
or
whatever,
and
that's
kind
of.
A
Yeah
I
guess
that
that's
true
it
you're
absolutely
right
and
it's
it's
a
challenge.
The
nice
thing
is
at
least
these
days
most
dependency
management.
Frameworks
have
a
way
of
expressing
that.
So
you
can
that's
what
we've
done
in
our
contributory
pose
like
the
the
ones
that
that
open
feature
maintains
is
we've
basically
put
in
you
know
the
npm?
Well,
sorry,
the
package
Json
in
npm
or
or
the
pawn
file
and
Maven
we've
used.
We
we
kind
of
consider
them
the
SDK
peer
dependencies
and
say:
okay,
you
have
to
have
an
SDK
in
this
range.
E
E
E
I'll
now
do
npm,
install
and
npm
run
and
see
what
happens
and
if
it
doesn't
start
spewing
out
massive
list
of
errors,
but
just
sort
of
we
weren't
styling
scientific
bailing,
but
we
weren't
failing
as
loudly
as
we
could
and
again
again.
There's
paradigms
around
that
I
mean
I
I,
don't
remember,
I,
think
rust
and
Java
are
the
only
two
languages.
I've
ever
really
seen
deprecation
warnings
in
right,
I
can't
remember
any
others
like
it's,
not
a
common
thing
to
do
in
other
languages,
but
yeah,
but
so
yeah.
E
If
there's
a
way
of
like
it,
would
be
ready,
it
might
be
easy
to
say,
like
you're
running,
open
feature,
JS
version
2.1
but
you're,
pointing
at
launch
Darkly
three,
and
that
just
won't
work
right
and
then
just
turn.
You
know:
do
it
Whatever
as
hard
an
exit,
as
you
can
kind
of
thing,
because
this
is
just
there's
no
there's
no
reason
why
you'd
ever
want
to
run
in
that
broken
state.
E
D
So
we
may
have
like
a
different
system
to
notify
people
that
build
providers
and
like
the
one
for
sdks,
as
as
you
say,
Ben
like
it
can
be
in
a
runtime
thing
like
super
strong
running
and
say:
hey:
it's
not
compatible,
but
notifying
providers
Builders.
Maybe
it's
a
different
way
of
doing
it.
I
I,
don't
know
exactly
how,
but
we
may
think
another
way,
maybe
having
a
mailing
list
or
something
I.
F
C
The
one
part
of
it
is,
we
should
encourage
people
to
add
their
provider
to
our
docs
and
if
it's
in
our
docs
and
we
do
introduce
a
breaking
change,
we
could
use
that
as
a
way
to
it's
kind
of
a
painful,
but
hopefully
we're
not
doing
that
very
often
like.
We
need
to
do
everything
we
can
to
not
break
that
contract.
We
can
extend
it
of
course,
and
that
might
also
fall
into
this
piece
too,
where
we
need
to
let
people
know
like
new
functionality.
C
C
A
Maybe
in
like
we
already
have
the
dot
GitHub
that
has
some
security,
related
maintenance
stuff,
so
maybe
yeah
I'll
look
into
where
a
good
place.
To
summarize,
a
lot
of
this
stuff
is
because
it
will
impact
both
sdks
and
providers.
As
we
kind
of
discussed,
we
can
have
some
high-level
guidelines
around
it.
A
B
B
F
C
C
Kubecon
EU
is
coming
up
relatively
soon
and
we
did
apply
for
a
booth
and
for
at
least
a
one
hour
like
in-person
time
slot.
As
far
as
I
know,
we
have
not
got
confirmation
that
we
have
it,
but
I'm
pretty
confident,
we'll
we'll
get
it
again
worst
case.
We
take
the
captain
booth
and
we
share
it.
So
I'm
sure
we
can
figure
out
a
way
to
to
have
a
presence
there.
C
We're
also
Todd
and
I,
had
submitted
a
session
on
basically
get
Ops
and
feature
flagging.
If
that's
accepted,
we
were
going
to
basically
do
a
version
of
that
or
apply
for
a
version
of
that
at
argocon,
which
is
the
day
before
essentially
keepcon
starts,
and
so,
if
anyone
is
is
planning
to
attend,
maybe
consider
also
going
to
Argo
Khan.
C
If
you
have
any
interest
in
some
of
these,
like
you
know
kind
of
get
UPS
flows
in
the
cloud
native
world,
so
hopefully
Todd
and
I
are
there
as
well,
we'll
certainly
be
at
kubecon.
So
if
you're
going
to
be
there,
let
me
know
if
you're
interested
in
helping
out
at
like
the
booth
or
just
you
know
swinging
by
and
saying
hi
we'll
be
there.
C
Basically
all
week
so
should
be,
should
be
a
good
time
and
then
one
of
the
things
that
we
should
think
about
this
might
be
something
for,
like
the
governance
committee
as
well
and
future
sessions,
but
figuring
out
like
if
there's
any
kind
of
like
press
release
or
announcements,
we'd
like
to
make
I
think
one
good
goal
should
be
a
client-side
or
you
know,
browser
essentially
support,
because
that's
a
big
one.
It's
been
a
topic
that
we've
talked
about
for
quite
a
while
and
I.
C
C
B
C
Makes
a
reason
to
go.
That's
a
that's
perfect.
Eloise
will
take
you
out
for
your
birthday
beer
all
right
next
one.
This
is
just
kind
of
an
FYI.
We
did
actually
based
on
Ben's
recommendations,
sign
up
for
a
tool
called
orbit
which
is
basically
like
a
community
kind
of
tracking
tool
and
then
David
went
ahead
and
applied
for
the
open
source
license
for
that.
So
we
do
have
access
to
that.
We
have
a
limited
seats
with
that
commercial
thing.
C
If
it's
something
that
of
interest
to
you,
you
know,
let
me
know-
and
it's
also
you
know
something
that
will
continue
to
kind
of
track
to
see
like
what
you
know
provides
like
the
essentially
the
most
engagement
you
know,
if
it's
certain
blog
posts
or
tweets
or
whatever
we
can
continue
to
do
that.
So
that's
basically
for
me:
yeah!
If
you
have
any
questions
on
that.
C
B
Yeah,
just
one
one
last
thing
on
orbit,
so
when
I
reached
out
for
the
for
the
license,
they
also
offered
to
have
kind
of
like
a
learning
session.
So
again,
if
anyone's
interested
there.
Let
me
know-
and
maybe
we
can
try
to
set
this
up
otherwise,
I'll
go
ahead
and
just
bring
back
the
interesting
findings
yeah
other
than
that.
The
first
edition
of
the
newsletter
will
hopefully
come
out
in
the
next
few
days.
B
I
hope,
yeah
and
if
you
have
any
blog
posts
or
videos
related
to
Future
Flags
in
general,
that
you
think
could
be
useful
for
first-time
users
or
it
could
be
useful
in
general.
Feel
free
to
add
in
the
links
here
or
I'll
also
create
an
issue
on
on
on
GitHub
yeah
I'll
also
put
in
a
call
for
adopters.
So
we
created
a
new
issue
template.
C
F
I
think
you
on
occupation,
for,
for
the
time
being,
unfortunately,
I
think
we're
making
good
progress.
I
think
the
biggest
topic
is
really
future
plans.
We
have
obviously
something
there,
but
that's
what
we
need
to
work
a
bit
more
on
and
then
waiting
to
get
sponsors
and
seeing
the
thing
obviously
move
forward.
F
C
Sounds
good,
let's
see
yeah,
so
we'll
continue
to
work
through
that
if
anyone
has
any
interest,
so
there
is
I
think
a
fork
of
our
proposal
in
the
org.
So
you
can
take
a
look
at
that.
You
know
feel
free
to
add
pull
requests.
If
there's
any
section
that
you
are
passionate
about
adding
content
to
otherwise
we'll
continue
to
kind
of
chip
away
with
it
and
hopefully
get
some
some
sponsors,
the
cncf
level,
soon
perfect
anything
else.