►
From YouTube: OpenFeature - Project meeting, August 4, 2022
Description
Notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit?usp=sharing
OpenFeature website: https://open-feature.github.io/
A
C
D
A
B
B
E
B
C
B
Well,
nice
to
meet.
You
welcome
all
right,
yeah
Pete's,
also
a
West
coaster,
so
cool
all
right.
We
can
go
ahead
and
kick
it
off.
First
thing:
I
want
to
start
with
is:
is
I'd
like
to
release
the
the
spec
v020
I
have
a
an
issue
open
right
now
for
kind
of
what
that
release
process
would
look
like
the
the
last
kind
of
remaining
task
would
be
there.
There's
a
pull
request
open
right
now
for
removing
the
context
Transformer
from
the
spec
I.
B
Don't
think
that
would
be
super
impactful
for
most
sdks
besides,
maybe
the
node
one,
and
basically
the
replacement
would
be
a
provider
hook
which
would
then
tap
into
the
existing
like
hook
functionality.
Obviously,
that
provides
a
lot
more
flexibility
and
then
also
doesn't
introduce.
You
know:
A
New,
Concept
that
that
SDK
developers
will
have
to
to
deal
with
so
I'm
going
to
wait
until
that
one
is
officially
accepted
and
then
cut
the
release.
B
Justin's
not
here.
So
this
one
probably
isn't
that
interesting
to
to
most,
but
the
the
group
I
o
email
address
I
think
we're
going
to
keep
that
for
a
little
while
that
one
actually
allows
us
to
to
sign
up,
for
you
know,
accounts
and
things
like
that
that
we
don't.
We
can't
actually
use
the
cncf
one
for
that
one.
So
that
was
a
an
action
item
from
the
last
meeting,
but
I
think
it
does
make
sense
to
keep
it
at
least
temporarily.
B
B
We
shouldn't
be
for
any
dependencies
again,
I,
don't
think
that
one
will
be
real
impactful,
considering
that
most
of
our
sdks
are
are
low
to
basically
no
dependencies,
but
it
is
something
to
just
be
aware
of,
and
also
be
careful
if
you're,
an
SDK,
no
maintainer
to
not
introduce
any
dependencies
that
have
licenses
that
could
you
know,
become
an
issue
down
the
road
code.
Any
questions
about
any
of
any
of
those
topics
so
far.
E
Yeah
I
had
one
question
about
the
removing
of
the
contact.
Transformers
I
was
messing
around
with
it
today
and
if,
if
you
try
to
get
resolved
bullying
with
Boolean
value
in
node,
and
you
pass
like
your
flat
key
and
your
default
and
then
you
have
the
third
parameter,
the
transformed
contacts
when
I
pass
anything
there
it
it
doesn't
become
available
for
me
in
the
hook,
I
was
expecting
that
everything
will
be
accessible
or
in
even
the
default
contact
Transformer.
So
I
don't
know
if
I'm
doing
something
wrong
in
my
profiler
or.
B
E
B
So,
at
a
high
level,
the
idea
is
to
remove
the
context
Transformer
and
replace
it
with
hooks.
It
would
allow
provider
developers
to
basically
build
hooks
into
the
provider,
and
that
would
be
a
kind
of
abstracted
away
from
anyone.
That's
going
to
be
using
that
provider
itself
and
that
would
allow
you
to
you
know,
do
whatever
you
need
using
the
regular
like
hook,
functionality.
E
Yeah
I
understand,
but
so
at
the
moment,
if,
if
I,
do
a
resolved,
Boolean
value
pass
the
third
parameter
for
contact
to
pass
like
extra
contextual
data
at
the
moment.
For
me
it
doesn't
end
up
in
the
at
the
currently
contact
Transformer,
so
I
cannot
like
it
only
for
me.
It
only
seems
to
get
the
targeting
key
and
the
contacts
that
I
passed
when
I
created
my
client
not
like
stuff
I
passed
on
a
one-off
bases
when
I
want
to
evaluate
a
future
flag
s,
but
we
can
discuss
it.
Yeah.
A
B
Let's
see
next
one
is
we've
been
working
on
the
documentation
quite
a
bit
recently,
so
I
can
give
a
quick
update
on
what
that
looks
like
keep
in
mind.
I'm,
not
a
designer,
and
if
anyone
is
I
would
certainly
appreciate
some
kind
of
help
here,
but
I
do
think
it's
it's
a
decent
First
Step.
Here
you
can
see
that
this
is.
Hopefully
you
can
see.
My
screen
I
need
a
thumbs
up
from
someone
that
you
can
see.
B
B
So
there's
some
improvements,
certainly
that
need
to
be
made.
But
you
can
see
that
we
start
having.
You
know
some
of
the
Core
Concepts
defined
here
with
the
language
and
some
examples,
and
then
I
also
brought
in
the
specification.
So
you
can
see
here
this
is
using
a
git
sub
module.
So
we'll
have
to
make
sure
that
when
we
do,
you
know
major
specification
releases.
So
we
update
the
sub
module,
but
the
rest
is
just
kind
of
automatic
and
just
pulled
right
in
from
the
the
official
spec
and
part
of
the
idea.
B
A
B
B
You
can
run
docky
Source
locally
to
test
it,
but
I
also,
actually
that's
a
good
point.
One
thing
to
mention.
Hopefully
this
isn't
an
issue:
I
was
trying
to
cut
down
on
on
like
kind
of
the
cognitive
load
when
you,
you
add
new
stuff
to
the
docs,
but
I
I
added
a
real,
quick
plug-in
here.
Actually
there's
two
of
them,
and
this
will
automatically
do
the
the
sub
module.
Assuming
you
have,
you
know,
get
set
up
on
your
computer.
B
It
will
do
the
the
sub
module
like
recursive
call
when
you
first
run
it,
and
it
also
will
make
sure
to
copy
over
the
content
from
external
content.
So
this
is
just
a
generic
plugin
that
moves
files.
So
if
we
add
like
additional
sub-modules,
we
can
configure
it
to
move.
You
know
documentation
to
whatever
parts
of
the
dock.
We
need.
That's
just
a
quick
aside.
B
Basically,
what
you'll
need
to
do
once
you
want
to
add
in
in
your
content
as
you
pull
it,
it
is
using
yarn
because
it's
we
could
switch
to
npm,
but
yarn.
Just
comes
kind
of
pre-bundled
since
stocky
Soros
is
a
Facebook
project,
but
you're
just
calling
this
repo.
You
just
do
a
yarn
to
get
all
the
dependencies
and
then
it's
just
a
like
npm
runs
start
with
right.
B
You
know,
run
the
docs
locally
and
then,
if
you
add
content
under
docs
under
the
different
sections,
it
will
just
start
showing
up
the
one
caveat
to
that
is
you
may
need
to
update
the
docosaurus
config
or
they
they
basically
have
some
of
the
excuse
me.
It's
not
here
it's
so
these,
like
so
here's
a
footer
section,
for
example,
but
we
also
have
items.
B
So
this
is
like
something
like
the
top
bar
navs
and
stuff
like
that,
so
the
items
will
show
up,
but
you
may
need
to
have
like
navigational
options
potentially
configured
and
happy
to
go
into
more
information
on
that.
If
you
have
any
questions,
but
it's
a
pretty
simple
process,
it
actually
works
pretty
easy.
The
only
thing
to
keep
in
mind-
and
this
is
another
I-
guess-
good
transition
to
the
changes
that
I
made
to
the
spec.
B
Is
you
basically,
you
can
start
adding
in
these
like
Header
information
to
you
know,
the
title
would
would
go
to
like
the
the
the
title
of
the
page
in
the
head
description
same
deal
and
then
you
can
start
controlling
like
the
sidebar
positions
and
stuff
like
that,
so
you
may
have
to
experiment
with
metadata,
but
it's
it's
pretty
straightforward.
If
you
have
any
questions,
you
know
feel
free
to
ping
me.
C
B
B
There's
a
tool
called
artifact
Hub
that
may
or
may
not
work
for
us.
They
seem
to
be
more
around
like
kubernetes
assets,
so
it's
not
a
perfect
fit,
but
then
you
know
otel,
basically
just
has
like
a
a
table
that
they
just
dump
out
a
bunch
of
stuff
so
like
I'm,
trying
to
find
some
some
reasonable
option,
probably
somewhere
in
between
those
two.
If
anyone
has
any
ideas
of
a
good
way
to
kind
of
make
some
of
these,
you
know
providers
and
hooks
more
easily
discoverable.
B
That's
kind
of
the
challenge.
I
think
we
need
to
solve
next
and
then
yeah,
basically
back
to
your
point,
Dan
I
think
making
it
like
a
clear
section
here
where
it
would
I
think
it
is
okay
for
it
to
to
be
like
these
end-to-end
examples.
For
saying,
like
you
know,
using
open
feature
with
with
flag
D
or
any
of
the
vendors.
A
tutorial
I
think
would
be
a
perfect
spot
for
that.
E
B
Sure
yeah
I'm
certainly
open
for
ideas
here.
This
is
just
trying
to
get
content
out.
So
we
can,
you
know,
go
from
there
there's
also
certain
opportunities
for
like
blog
posts.
If
anyone
has
any,
you
know
blogs
that
they'd
like
to
add
I
would
start
with
an
issue
first,
but
go
ahead
and
create
that
and
then
you
know,
feel
free
to
start
contributing
and
yeah
if
there's
any
other
like
items
or
doc,
structure
we'd
like
to
see
additional
content.
B
Anything
like
that,
you
know,
go,
go
ahead
and
create
an
issue
and
feel
free
to
contribute,
because
this,
this
is
something
that
I
think
will
obviously
become
really
really
important
for
people
to
start
understanding
how
to
use
open
feature
at
all
and
what's
available
to
them
so
yeah
cool,
it
is
still
kind
of
in
like
a
soft
launch
mode.
I
would
say
like
there
is
no
link
from
the
main
website
here.
So
if
you
do
have
time
to
kind
of
go
through,
it
make
sure
the
content
is
easily
digestible.
D
B
D
Started
I
started
like
just
essentially
tearing
apart
the
the
page
that
that
was
already
there
and
I
think
I'm
still
gonna
submit
it
just
as
a
if
I
submit
it
as
a
PR
I'll,
probably
just
tear
apart
that
page.
But
it's
not.
The
intention
is
not
like
I
think
we
should
replace
this
page.
It's
just
like,
like
a
it's.
Just
gonna
be
like
a
place
to
put
the
content,
but
I
think
maybe
we'll
end
up.
Maybe
it
could
be
a
separate,
a
separate
page,
but
that's
that's
just
kind
of
where
I
started.
Sure
yep.
B
B
Would
it
be
better
to
have
docs
in
you
know,
docosaurus
format,
basically
in
each
SDK
and
then
kind
of
pull
them
in
and
merge
them
in
the
docs,
using
like
the
sub
modules
like
I
did
for
the
spec,
or
would
it
be
better
to
have
a
section
inside?
You
know
the
docs
repo
itself
and
we
just
have
to
make
sure
to
keep
them
in
in
sync,
in
some
reasonable
fashion.
D
I
mean
I
think
my
take
on
this
is
like
this
definitely
for
some
kind
of
like
language,
language,
ecosystems.
People
expect
the
docs
to
be
essentially
just
embedded
like
in.
Like
read
me.
You
know
like
if
it's
an
npn
module,
you
kind
of
expect
it
all
to
just
be
like
right
there
in
the
readme
and
like
keeping
it
in
sync,
keeping
the
docks
in
sync
between
like
a
readme
and
then
maybe
somewhere
else
in
the
repo
and
then
also
in
the
in,
like
a
separate
repo
for
the
documentation
might
be
painful.
D
B
Mean
it
would
be
relatively
easy:
it's
just
there's
a
bunch
of
stuff
like
Badges
and
licensing
information
and
stuff
on
the
main
readme
that
we
don't
want
to
strip
out
I.
Suppose
I
guess
that's
the
big
question,
it's
something
we
don't
necessarily
have
to
answer
now,
but
I'd
like
to
kind
of
figure
out
the
ideal
way
of
of
managing
like
SDK
specific
documentation
without
adding
like
a
you
know,
a
huge
amount
of
cognitive
over
it
or
something.
D
I
mean
if
you'll
get
if
you
were
a
end
user,
and
you
were
getting
to
the
point
that
you
wanted
to
read
like
the
specific
documentation
for
like
the
the
node
provider,
for
whatever
I
kind
of
feel
like
it,
doesn't
need
to
all
be
in
one
centralized
place
like
if
it
just
links
to
the
the
repo
or
whatever.
Then
that
would
serve
the
purpose.
I,
don't
think,
there's
that
much
benefit
in
having
all
of
the
detailed
implementation
readme's
for
every
SDK
in
this
in
the
same
place,
I'm.
D
D
B
A
B
A
B
That's
fine
like
to
have
have
a
bunch
of
documentation
on
through
a
bunch
of
repos.
Has
the
potential
becoming
stale
quickly
so
yeah
I
like
that
I
think
that's
a
nice,
easy
approach
that
that
will
scale
well
until
we
need
to
rethink
it
a
bit
so
circling
quickly
back
to
just
like
discoverability
of
like
providers
and
and
hooks
what
do
we
think
about
maybe
just
doing
a
thing
similar
to
what
we
just
talked
about
for
SDK
is
for
now
at
least
have
just
kind
of
like
a
I.
B
A
D
I
I
would
vote
them.
I
would
I
would
lean
towards
making
it
super
easy
for
someone
to
add
their
provider
and
not
have
to
like
read
a
bunch
of
things
of
like
oh
well,
there's
this
generalized
abstraction
for
a
provider,
and
you
fill
in
this
Json
like
making
it
so
that
someone
can
just
literally
just
like
go
in
there
and
edit
some
markdown
or
something
close
to
that
yeah
foreign.
D
Okay,
from
like
the
presenting
the
information,
the
number
ones
like
I
feel,
like
the
number
one
use
case,
is
for
a
app
like
someone,
an
application
integrated
like
someone
who
just
wants
to
get
started
with
open
feature
for
their.
You
know
for
their
vendor
or
open
source
thing
and
their
language,
and
so
just
having
like
the
basic
thing
of
like
the
providers.
First
and
then
does
that,
like
the
hooks
and
all
the
like
fancy
like
additional
stuff
kind
of
like
further
down
yeah.
B
I
think
it
makes
sense
to
especially
if
you
don't
have
any
kind
of
filtering
functionality
to
keep
them
clearly
separated
for
now
it
makes
the
most
sense.
Okay,
I'll
see
what
I
can
find
it.
There's
some
simple
things
that
I
can
use
in
docky,
Source
I
think
to
make
it
pretty
straightforward
for
now
so
I'll
see
what
I
can
come
up
with
just
so
we
have
a
kind
of
a
place
to
register
these
and
related
to
that
in
the
provider.
B
So
if
you
are
going
to
work
on
a
provider,
there's
a
couple
of
maybe
recommendations
there
to
take
a
look
at
and
if
you
have
feedback
on
that,
certainly
let
me
know,
but
just
try
to
add
a
little
bit
of
consistency.
So,
even
if
you
know,
if
you
are
looking
through
a
table,
for
example,
you
can
follow
a
pretty
clear
pattern
of
what
these
things
would
be
called.
D
D
Should
we,
if
we've
got
like
an
illustration,
should
we
like
upload
like
the
source
for
the
illustration
to
like
to
some
other
like
directory
and
like
somewhere,
so
that
if
someone
comes,
you
know
if
I,
if
I
win
the
lottery
and
go
and
live
in
Tahiti
and
someone
wants
to
update
the
image,
you
know,
it'd
be
good
for
them
to
not
have
to
do
it
from
scratch.
But
I,
don't
I
I
can't.
A
D
D
A
B
Yeah,
so
maybe
we
can
document
that
because
I
actually
that's
an
interesting
question
and
I'm
glad
you
brought
that
up
Alex,
because
Todd
has
actually
been
embedding
both
the
the
configuration
for
excela
draw
and
the
image.
But
it
sounds
like
we
could
basically
just
do
both
as
long
as
people
are
aware
that
that's
possible.
That's
the
challenge,
I
suppose,
but.
D
B
So
one
idea
potentially
could
be
in
in
darkosaurus
at
least
there's
like
a
static
content
folder,
so
we
can
maybe
just
throw
like
a
readme
or
something
that
either
references
that
folder
or
in
that
folder
potentially
like
it's,
not
really
a
big
deal.
If
someone
you
know
sees
that
publicly
or
something
so
just
to
make
it
obvious
that,
like
any
any
of
the
or
some
of
these
drawings
at
least
could
be,
you
know
edited
in
Excalibur
cool.
That
was
a
good
tip
thanks,
Alex
and
I
guess
also
related
to
Alex.
B
A
Yeah
I
was
just
gonna
try
and
do
a
general
project
overview
kind
of
I.
You
know
why
does
open
feature
exist?
Who
are
some
of
the
people
who
are
involved
in
building
it
and
then
look
at
sort
of
a
specific
implementation
that
I
was
involved
with.
So
that's
the
flag
D
in
the
open,
Future
operator
and
my
ambitionists
have
a
demo
set
up,
so
I
can
use
probably
launch
Darkly
or
something
similar
blacksmith,
I
I.
A
B
Yeah,
and
so
ours
was
basically
the
idea
was
around
quality
getting
in
production.
It's
not
really
a
super
novel
concept,
but
but
the
idea
is
like
you
know
you
may
have
tested.
You
know
your
your
code
in
lower
environments
very
heavily,
but
then
your
robots
production
and
it
breaks
and
it
breaks
because
of
a
configuration
between
environments
and
so
the
the
idea
here
is
like
you're
introducing
you
know
a
new
service
that
you
know
requires.
You
know
an
off
token.
For
example,
the
auth
token.
E
B
Work
in
production,
but
it's
behind
a
feature
flag
that
feature
flag
or
that
that
new
feature
is
tested.
You
know
automatically
with
some
kind
of
end-to-end
test,
but
only
enabled
for
that
end-to-end
test
when
it
fails
the
quality
gate.
Basically,
we
can
go
through
some
kind
of
remediation
flow
change
that
password
and
then
it
will
go
through.
You
know
past
the
quality
gate
and
then
the
feature
will
be
rolled
out
to
end
users.
So
the
idea
is
basically
testing
testing
and
production
in
an
automated
fashion.
B
B
B
You
know
certainly
feel
free
to,
but
they're
they're
available
and
easy
to
just
kind
of
Port
over
to
to
whatever
you
know,
SDK
you're,
currently
working
on
and
then
there's
one
last
one
that
may
be
kind
of
interesting
to
the
group
Todd
before
you
went
on.
Vacation
opened
up
an
open,
open
feature,
enhancement
proposal
for
flag
change
events,
and
so,
if
you
want
to
take
a
look
at
what
the
proposal
is
there,
it's
I
think
pretty
pretty
comprehensive.
There's
a
few
open
questions
on.
B
If,
if
you
have
any
interest
in
that,
it's
not
something
that
we're
pushing
real
real
heavily,
but
it
is
something
that
change
events
seem
to
be
fairly
common
across
most
sdks,
and
it
would
be
nice
to
be
able
to
support
that
and
I
do
think
it
adds
some
pretty
interesting.
You
know
flexibility
for
how
you
could
use
feature
flagging,
especially
for
things
like
whatever
Alex
was
talking
about
with
you
know,
infrastructure
and
and
whatnot.
If
you're
able
to
subscribe
to
to
change
events
without
actually
having
to
have
like
a
request.
A
A
B
I'm
pretty
sure
we
do
I
think
it
may
be
like
you
share
it
with
another
group,
and
we
have
to
just
you
know:
do
it
for
a
couple
hours,
which
may
be
better
honestly
so
not
to
do
Booth
Duty
the
whole
time
so
yeah
I'll
check
on
that
and
try
to
report
it.
The
next
community
meeting,
but
it
could
be
a
cool
opportunity
to
you
know,
talk
to
a
bunch
of
end
users
and
and
get
maybe
some
of
the
vendors
involved
and
stuff
as
well.
A
B
E
B
I
mean
I
would
just
start
with
the
the
initial
proposal
and
keep
it
relatively
simple.
We
just
want
to
make
sure
that
we
have
you
know
kind
of
community
buy-in
to
make
sure
that
you
don't.
You
know,
invest
too
much
time
that
that
we
decide
that
this
isn't
the
right.
You
know
it's
not
a
an
item
that
you
even
want
to
address
right
now,
because
this
one
I
think
is
maybe
potentially
iffy,
because
it
kind
of
gets
out
of
scope
of
of
feature
flagging
in
general.
B
B
Yeah,
that
would
be
my
I
like
there's,
certainly
other
likely
higher
priority
tasks,
so
I'd
say,
feel
free
to
put
out
the
proposal,
but
it's
it's
something
that
I
think
will
like.
We
obviously
need
to
like
invest
in
like
client-side
feature
flagging,
and
things
like
that.
You
know
before
we
start
looking
at.
C
E
B
D
The
only
thing
we
add
to
that
that
spec
kind
of
like
becomes
like
a
real
kind
of
like
an
extra
thing
that,
like
every
provider
potentially
has
to
implement
and
and
it
feels
like,
there's
a
potential
where
some
people
like
like
so
this,
like
events,
for
example,
that,
like
I,
think
a
lot
of
the
commercial
providers
are
definitely
gonna.
Gonna
like
be
interested
in
this
because
they
all
have
I
think
I.
Think
most
of
them
have
like
something
like
this
for
a
b
testing,
but
most
of
the
open
source
ones.
D
A
A
B
I
I
think
that's
likely
how
all
these
more
advanced
features
would
would
work.
So,
for
example,
like
for
the
Eventing
one,
not
all
providers
will
be
able
to
do
that.
It's
just
kind
of
I
mean
or
they
can,
but
it
will
take
a
lot
of
effort.
They'd
have
to
like
manually
track
it
in
the
provider,
and
so
the
idea
was
we'd.
Probably
just
want
to
have
have
the
providers
document
that
this
is
like
an
unsupported
Behavior,
especially
for
the
event
one.
It
would
just
never
fire.
B
C
I
was
wondering
actually
for
this.
Are
we
gonna
have
documentation
at
some
point
about
like
portability
between
providers,
because
that
kind
of
brings
up
then,
like
one
of
the
goals,
the
community
was
thinking,
you
know
like
you
can
switch
between
providers,
but,
as
we
continue
talking,
there's
always
like
these
edge
cases
to
it
that,
like
there's
portability
but
not
so
I
wonder
if
we
can
solve
it
with
documentation.
Maybe
I.
B
Think
that's
our
only
option
to
some
extent,
it's
like
it
shouldn't
break
I
think
that
that
needs
to
be
a
goal,
but
for
something
like
you
know,
change
like
flight
change
events.
It's
like
you
know,
if
you're,
using
a
tool
that
supports
it,
you
get
it
and
if
you
don't
and
you
need
it,
you
may
need
to
change
to
a
tool
that
supports
it
to
some
extent.
So.
D
B
D
We
wanted
to
do
that.
It
feels
like
there
needs
to
be
some
kind
of
like
word
or
like
language
for
like
these
kind
of
like
chunks
of
the
spec
but
like
either
you
do
like
vendors,
do
or
don't
support
like
I.
Like
you
know,
vendor
a
can
say
you
know
we
support
core
open
feature.
Plus
the
you
know,
events
extension
or
like
the
events,
bundle
or
whatever
the
word
is,
and
then
someone
someone
who
comes
along
can
be
like
Oh
I'm.
D
B
A
B
Have
to
make
sure
that
for
some
of
these
big
ones,
that
that
will
certainly
not
have
coverage
across
every
implementation
keep
those
as
a
separate
number
and
we
could
either
have
something
that
says
like
you
know
this,
this
provider
supports
these
ones
or
this
provider
doesn't
support.
You
know
whatever
section
five
or
something
or
whatever
we
want
to
call.
That
could
be
one
way
to
to
call
that
out.
Yeah.
A
And
some
could
be
grouped
into
core,
you
know
core
or
primary
functionality,
I
guess
because
I
think
like
I
like
producer,
but
I,
think
it
makes
a
lot
of
sense
when
a
provider
goes
to
add
their
product
detail
to
the
docs
I.
Guess
it's
on
them
to
fill
out
that
Matrix,
what
they
support
and
then
maybe
some
of
the
search
functionality
actually
might
be
able
to
say.
Like
you
know,
you
could
search
for
SDK
support
core
which
supports
whatever
extensions
we
want
to
have
like
events,
and
you
could
see
very
easily
yeah.
B
No,
that
makes
sense
I
mean
it's
pretty
easy
to
add
like
metadata
into
our
specs.
So
maybe
that,
like
I,
think
what
we
have
now,
we
could
could
probably
say
is:
is
core
I
think
everything
else
that
we've
talked
about
Beyond
this
so
far
has
been
yeah
things
that
would
not
necessarily
translate
across
all
all
vendors,
and
you
know,
different
tools
that
are
available,
so
that
would
be
the
maybe.
That
is
something
we
could
do
right
now.
B
Kind
of
just
go
through
and
say
like
these
are
the
core,
the
core
functionality
and
unless
something
you
know
that
gets
proposed,
that's
obviously
part
of
core
everything
else
would
go
under
some
kind
of
you
know
extensions
or
something
like
that.
That
could
be
kind
of
named
and
called
out
explicitly.
C
E
B
Okay,
yeah
I
think
that's
a
good
idea.
I
can
take
that
as
an
action
item
and
just
try
to
put
a
basic
proposal
out
there,
for
you
know
what
we
basically
would
call
spec
enhancements
that
are
outside
of
core
and
probably
try
to
formalize
like
what
we
have
as
core
already,
because
I
I,
think
and
I
guess
uses
an
opportunity
to
review
what
we
have
so
far,
but
I
I
think
everything
that
we
have
in
there
should
be
pretty
universally
applicable
to
tools.
D
Yeah,
it's
not
I
snuck
this
in
there
while
we
were
while
we
were
talking,
I
was
just
thinking
about
it.
Kind
of
like
follows
on
a
little
bit
from
what
we
were
just
saying
so
I
guess
I'm,
just
I'm
wondering
like
what's
the
at
what
point
do
we
want
to
start
kind
of
like
actively
kind
of
talking
to
to
vendors,
to
open
source
projects
and
saying
like
hey
this?
D
B
Yeah
so
kind
of
unofficially
it
started
already
I
think
we
should
try
to
you
know
get
this
going.
I
mean
this
is
the
best
way
to
start
getting
feedback
too.
It's
like
when
you
go
to
implement
a
provider
you
see
what's
missing,
we
can
get
real
users
to
test
it
out.
The
only
thing
is
like
the
spec
is
still
changing.
You
know
we'll
try
to
not
break
it,
but
you
know
any
anyone
that
implements
a
provider
is
going
to
have
to
be
a
little
bit
flexible.
B
At
this
stage
you
know
again
we'll
try
to
avoid
major
issues
and
breaking
changes,
but
I
mean
the
more
providers
we
have
at
this
stage.
I
think
the
better
it
is
for
this
back
and
just
the
success
of
the
project.
I
do
know
that
split
has
started
working
on
a
a
basic
at
least
Java
provider
and
then
same
with
Cloud
bees,
and
then
the
the
go
feature
flag
and
Thomas
I'm
sure
you've
seen
him
around
in
slack,
especially
he
worked
on
one
for
node.js.
B
B
I
started
on
that
in
the
the
documentation
right
now
under
the
provider
docs
it's
more
around
the
the
naming
conventions
about
like
repos
and
stuff
I
think
I
had
language
in
there
at
least
I
did
in
my
notes
about
preferring
to
keep
it
in
in
orgs,
as
opposed
to
inside
the
like.
The
open
feature
maintained
one,
so
that
would
be
like
I
think
my
preference,
but
it
all
comes
back
to
the
discoverability.
So
we'll
have
to
have
that.
B
Like
you
know,
people
have
the
ability
to
find
what
providers
are
available,
but
yeah
I,
I,
think
I,
hope
that
there's
language
in
there
I'll
review
that
too,
if
I
didn't
put
it
in
there,
I
may
extend
that
just
to
say,
like
it
kind
of
provide
recommendations,
so
yeah
I
think
at
the
end
of
the
day
it
kind
of
comes
down
to
whatever
you
know.
You
guys
want
to
do.
To
be
honest,
whatever
makes
the
most
sense
so.
D
Would
it
make
sense
to
go
like
going
back
to
that's
listing
vendors
thing,
I,
wonder
if
it
makes
sense
to
kind
of
like
have
like
a
a
document
or
something
that's
just
keeping
track
of
like
who?
Who
who
we've
talked
to,
because
I
think
various
people
are
talking
to
various?
You
know
various
people
who
we've
talked
to
and
who
and
who
like
and
what
the
states
is,
because
I
I
guess
what
the
thing
I
worry
about.
The
most.
D
To
be
honest,
is
that,
like
some
someone
out,
there
is
kind
of
like
like
checked
like
was
paying
attention?
Token
feature
like
in
what
like
maybe
one
of
the
very
early
meetings
and
then
it's
kind
of
like
falling
off
their
radar
and
then
we're
gonna
kind
of
at
some
point.
Do
some
big
announcements
and
they
and
people
are
going
to
feel
like
that.
They
they
got
they
lost
out
from
being.
A
B
Do
it
on
just
like
a
Doc
Page,
you
know
like
a
Google
Docs
or
something
and
just
share
it
with
the
the
group
I
think,
especially
as
we
start
adding
documentation
and
if
we
have
maybe
one
or
two
people.
You
know
that's
been
attending
a
lot
of
these
meetings
and
kind
of
understand
the
situation
go
through
it
once
and
and
make
sure
that
the
docs
make
sense.
The
process
is,
is
pretty
straightforward,
then
I'd
feel
a
bit
better
about
reaching
out
to
the
ones
that
have
been
maybe
less
active
about.
D
Maybe
it
could
just
be
like
a
like
a
and
it
I
don't
know.
If
you
can
do
this
in
the
issue,
markdown,
you
probably
can,
or
just
having
like
a
table
of
like
the
vet,
like
essentially
Like
A
reproduction
of
the
table.
That
would
be
on
the
website
right
of
like
the
vendor
and
then
the
which
provider
they're
working
on,
and
then
we
can
kind
of
keep
track
of
who's
working
on
one.
B
B
Yeah,
okay
I'll
try
to
get
the
issue
out
there
at
least,
and
we
can
kind
of
work
through
it.
Maybe
that's
another
topic
for
another
community
meeting
for
how
we
can
make
the
the
process
a
bit
easier
to
track,
but
I
think
it
makes
sense.
You
know
from
my
perspective,
it's
like
we
have
to
have
these
providers
in
place
or
you
know.
Nothing
else
is
really
that
valuable.
Honestly,
it's
yeah!
You
know
you
have
to
register
that
in
open
feature
for
anything
to
work.
D
You
know
it's
also
like
there's
this
kind
of
Snowball
Effect
right
like
once,
you
get
enough
people
doing
something
then
I
think
it
get.
It
goes
from
like
oh
I,
don't
know
if
I
want
to
do
this
thing
to
like.
Oh
I
should
do
this
thing,
because
all
the
other
people
are
doing
this
thing.
So
I
guess
that's
part
of
what
I'm
thinking
as
well.
Just
from
like
a
marketing
kind
of
aspect,
it's
it.