►
From YouTube: OpenFeature - Project Meeting, July 21, 2022
Description
TODO: ADD descrioption here
OpenFeature website: https://open-feature.github.io/
B
C
E
A
C
A
All
right,
I
guess
we
can
probably
just
go
ahead
and
get
started
cool.
Let's
see.
Looking
through,
looks
like
there
may
be
a
few
new
attendees
if
you're
new
and
feel
comfortable
introducing
yourself,
if
you
don't
mind,
maybe
you're
raising
your
hand
or
something
or
just
unmeeting
yourself
and
saying
hi.
A
A
So
if
you're
working
on
sdk
try
to
make
sure
that
you
know
you're
compliant
with
the
tagged
spec
release
and
then,
if
you
have
any
interest
or
feedback
on
the
beta
spec,
you
know
take
a
look
at
that
proposal
and
then,
if
there's
anything
missing,
certainly
let
us
know
if
there's
you
know
something
that
you
feel
strongly
about
or
if
the
priority
of
any
item
you
disagree
with,
you
know.
Certainly
you
know
make
your
case
on
the
thread
and
we
can.
A
I
mean
that's
part
of
I
suppose
this
this
proposal
out.
There
is
what
what
needs
to
be
included
in
in
this
release.
So
I
mean
for
me.
I
would
say
that
the
beta
release
should
include
everything
that
we
would
want
in
ga,
essentially,
because
I
would
think
that
we'd
want
to
make
sure
that
that
beta
is
is
kind
of
encompassing
enough
to
to
not
require
like
major
breaking
changes
for
any
kind
of
ga
release,
so
that
should
include
at
least
the
thought
of
how
we
would
handle.
A
You
know,
client-side
feature
flagging
and
some
of
like
the
eventing
and
things
like
that.
So
that
was
my
main
thought
behind
some
of
the
proposals
there
that
one
of
the
items
on
there
that's
come
up
a
couple
times
is
like
like
tracking
events,
and
that's
a
thing
that
at
the
moment
I
have
written
as
kind
of
a
a
low
priority,
and
that
might
be
something
that
you
know
the
community
kind
of
disagrees
with
they're,
certainly
popular
in
a
lot
of
feature,
flagging
libraries.
A
So
I'm
just
trying
to
decide
if,
if
that
makes
sense,
that's
something
that
we'd
want
to
tackle
as
part
of
a
beta
release
or
not
so
yeah.
I
mean
that's
kind
of
the
purpose
of
that.
That
issue
is
to
kind
of
discuss
like
what
we
would
like
to
consider
beta
and
so
for
me,
it's
basically
just
achieving
sufficient
coverage
of
existing.
You
know
kind
of
what
you'd
expect
out
of
a
feature
flagging
tool
and
for
me,
a
lot
of
that
is
just
you
know.
A
E
Yeah,
I
mean,
I
think,
scope
and
majority
are
two
two
different
things
and
just
if
you
don't
have
to
find
them
like,
should
I,
as
a
feature
flagging
provider,
implement
beta.
What
kind
of
can
I
expect,
I
think
down
the
road.
We'll
have
features
that
might
be
alpha
and
we
might
be
able
to
steal
something
there
from
other
projects,
but
it's
open,
telemetry
or
kubernetes.
How
they're
naming
apis
and
specs.
A
E
A
Okay,
that
makes
sense
yeah,
I
mean
the
the
sort
of
hard
part
about
looking
too
closely
at
what
open
telemetry
does
is
they
have
everything
slapped,
as
is
experimental
still
so
for
the
most
part,
so
I
think
eventually
we
need
to
like
try
to
stabilize
it
sooner
than
later.
So
you
know,
providers
and
stuff
can
have
a
little
bit
more
confidence
that
we're
not
going
to
rip
the
you
know
carpet
out
from
under
them
or
something
so,
but
yeah.
B
B
The
hotel
use
case
is
interesting
because
they
strongly
aligned
to
the
the
stages
of
incubation
within
the
cncf
as
their
north
star
for
alpha
beta
graduated
status.
So
I
think
that
they're
very
tentative
about
graduating
further
in
that
process,
because
that
also
binds
a
level
of
supportability
to
the
tools,
and
I
think
until
we've
had
that
conversation
about
how
we
want
to
support
the
open
community
that
we
should
be
very,
very
cautious
about
it
like
like.
A
A
I
appreciate
the
help
there
ben
nicely
done
cool
and
that's
it
for
major
updates.
Here,
a
lot
of
things
happening
behind
the
scenes
there.
I
one
more,
I
suppose,
announcement
it's
not
really
an
achievement
per
se,
but
I
did
start
signing
up
for
some
of
our
different
accounts
that
we're
eligible
for
so
there's
like
a
password
manager
that
we
have
access
to
as
well.
A
I
did
start
the
process
of
reserving
an
organization
on
docker
hub,
but
I
have
not
heard
anything
back.
So
it's
something
I'll
continue
to
pursue
to
see.
If
we
can,
you
know
get
that
reserved,
but
yeah,
just
kind
of
going
through
the
process
of
just
registering
the
organization
and
a
bunch
of
different
tools,
so
more
information
to
come
there.
If
there's
anything
that
you
specifically
need,
you
know,
send
it
out
in
slack
or
ping
me
or
something
and
go
ahead
and
reserve
that
cool
it
looks
like
justin's
up
next.
B
A
B
Just
an
example,
but,
like
token
push
tokens
from
pm
that
kind
of
thing
like
ci
push
tokens
just
so
that
we
don't
have
like
critical
level
access
in
there,
but
at
least
so
the
community
and
folks
who
are
contributors.
If
we
need
to
set
up
a
new
action
cicd
thing
we
we've
got
kind
of
a
reference
for
that.
I
think
that
can
be
a
really
useful
way
to
use
lastpass.
A
Yeah,
actually,
that's
a
good
point.
So
what
I
had
started
on
yesterday
was
creating
and
you
may
see
it
floating
around,
though
it's
an
open
feature
bot
account,
so
we
could
actually
have
like
a
personal
access
token
associated
with
that
account,
as
opposed
to
my
personal
or
something,
and
that
is
in
the
one
pass
or
one
password
account
right
now.
So
if
you
need
that
we
can
just
provide
access
to
to
that
account
and
then
start
using
that
for
certain
situations.
So
it's
brand
new.
A
D
D
We're
going
to
be
doing
tracking
events
and
the
way
that
ebay
does
it.
It
would
be
very
useful
to
us
to
have
to
not
have
the
support
burden
of
okay.
If
you
want
to
use
our
thing,
you
have
to
use
our
client
instantiate
our
client
and
then
also
here
are
four
hooks
that
you
need
to
put
in
this
order
that
are
specific
to
our
implementation,
so
that
everything
works
properly.
A
Yeah
for
me,
I
think
it
makes
perfect
sense
and
I
actually
prototyped
it
in
the
node
sdk
in
like
15
minutes
like
it's
actually
pretty
trivial,
to
register
this.
So
I
I
have
no
problem
with
it,
but
I'd
be
kind
of
curious
to
hear
other
people's
opinions
on
that,
and
there
is
an
issue
open
for
for
anyone.
That's
just
catching
up
on
this.
I
think
we
can
post
that
to
the
chat.
C
My
only
feedback
is
that
it
makes
the.
I
think
it
makes
the
context
transformer
concept
completely
redundant,
and
I
don't
mean
that
in
a
bad
way,
it
just
handles
the
same.
It
handles
that
problem
as
a
subset,
so
I'm
in
favor
for
it.
For
that
reason,
because
I
really
think
the
context
transformer
has
been
seen
to
be
useful.
It's
been
used
in
a
few
integrations
already,
because
it
makes
sense
that
you
need
to
take
the
open
feature
context
which
is
very
flexible
and
refine
it
into
something
that
a
particular
provider
needs.
C
C
The
word
hooks
too
much
to
a
point
where
it's
it's
confusing
like
we
just
need
to.
We
need
to
make
sure
that
it's
very
clear
that
this
is
a
different
than
the
application
author
facing
hooks.
So
I
I
don't
know
if
it
makes
sense
to
kind
of
rename
things
a
little
bit
or
or
what
or
maybe
come
up
with
a
different
name.
I
mean,
I
guess
it
is
very
similar
to
the
application
author
facing
hook.
C
So
you
know
the
the
thing
that
can
be
optional
included
in
all
kinds
of
dependencies
is
very
thin
and
only
has
application
author-facing
stuff,
and
then
they
have
sdk
packages
that
have
these.
You
know
concepts
and
abstractions
for
creating
things
like
different
sinks
or
collectors
or
whatever.
So
that
may
be
something
we
want
to
consider,
as
we
add
abstractions
and
artifacts
to
our
sdk.
It
gets
bigger,
and
so
the
the
proposition
of
including
it
into
a
third-party
library,
for
instance,
becomes
more
tenuous.
C
I
mean
this
is
a
minor
thing,
so
it
wouldn't
be.
I
don't
think
it's
a
deal
breaker,
but
just
something
to
keep
in
mind,
and
we
could
always
do
that
split
later
down
the
road.
If
we
wanted
to,
we
could
make
you
know
we
can
keep
the
sdk
what
it
is
and
then
split
out
an
api
that
is
just
the
application
author
facing
components
later.
If
we
wanted
to
that's
my
two
cents.
D
C
Yep,
I
think
that
we've
talked
about
supporting
multiple
providers.
When
we
talked
about
that
one
thing
that
I
can't
remember
it
was
justin,
or
maybe
it
was
pete
somebody
kind
of
had
the
idea
of
like
a
mega
provider
which
would
amalgam
amalgamate
multiple
providers.
So
you
would
write
a
provider
that
just
has
other
providers
in
it,
which
seems
like
it
would
be
a
fairly
elegant
solution,
and
I,
I
think
that
in
that
case
you
would
want
those
provider
specific
hooks
to
to
run
right
because
you're,
basically
aggregating
other
providers
into
your
makeup
provider.
C
D
A
F
It
that
that
thing
that
justin
was
saying
about
wanting
to
as
a
kind
of
provider
wanting
to
kind
of
have
a
bunch
of
stuff,
that's
kind
of
essentially
not
wanting
to
avoid
like
requiring
the
the
application
implementers
to
kind
of
like
install
this
hook
here.
And
do
this
stuff,
like
it
kind
of
reminds
me
a
little
bit
of
that
hotel
thing
of,
like
I
think,
they're
called
bundles
or
distributions,
or
something
where
it's
like.
F
A
pre-configured
kind
of
set
of
things
bundled
like
wired,
together
kind
of
for
you,
and
I'm
wondering
whether,
like,
if
we
solve
like
we
solve
this
one
case
of
like
we
want
to
kind
of
like
have
hooks
but
like
managed
by
the
provider.
Whether
we
then
will
well
whether
you
then
as
you're
building.
This
will
find
out
like
oh
actually.
We
also
have
this
other
thing
that
we
kind
of
want
the
provider
to
be
able
to
do
and
then
like.
F
I
wonder
whether
we're
going
to
end
up
wanting
to
have
a
more
general
abstraction
of
like
a
way
to
let
the
provider
kind
of
like
wire
stuff
up
ahead
of
time,
and
then
we
could
avoid
having
to
have
this
whole
extra
thing
and
we
could
just
use
regular
hooks
and
use
that
mechanism
to
kind
of
pre-wire
things.
I'm
not
I'm
not
sure.
I'm
articulating
with
my.
A
Yeah,
I
mean
I
think
that
was
kind
of
what
I
had
done
in
my
my
little
local
prototype
was
inside
the
provider
itself.
You
would
just
like
register
hook,
so
it'd
be
completely
abstracted
away
from
the
developer,
but
it
would
tap
into
the
same
like
life
cycle
that
we
already
have.
You
know
built
in
the
sdks.
A
So
then
it's
just
kind
of
like
it
would
be
the
thing
that
would
run
closest
to
flag
evaluation.
Basically,
and
so
you
could
use
that
to
like
say
inside
the
provider
say
you
could
have
it
throw
or
something
if,
if
the
targeting
key
was
missing
or
something
like
that,
you
could
do
that
in
a
provider
hook
which
would
just
tap
into
the
existing
mechanisms.
C
Pete's
pete's
proposition
correctly
it
like
that's
that's
one
way
we
could
do
it,
but
but
I
think
what
I
was
understanding
from
pete
is
kind
of
a
way
to
basically
attach
multiple
hooks
or
pro
or
even
a
provider,
basically
an
entire
configuration
to
bundle
that
in
a
single,
a
single
api,
so
you
could
say
open,
feature,
dot,
add
dyna,
trace
or
whatever,
and
it
would
add
some
kind
of
provider.
It
would
add
some
kind
of
hooks.
It's
basically
a
bundle
of
could
pre-configured
of
all
feature
pre-configured
in
a
certain
way.
Yeah.
F
And
I
think
like
I
I
what
I
imagine
that
being
more
commonly
showing
up
for
is,
is
not
like
a
vendor-specific
thing,
but
like
a
big
enterprise-e
company,
specific
thing
of
like
our
recipe
of
like
we
used
this,
you
know
we
talked
to
dynatrace
and
this
other
thing.
We
got
this
that
weird
logging
framework
that
everyone
hates
that
we
need
to
set
up,
and
you
know
all
those
things
like.
I
think
I
I
don't
want
us
to
build.
I
don't
think,
like
I'm
nervous
about
this
kind
of
like
saying.
F
Oh,
that
sounds
like
a
fun
thing
to
define
spec
for
and
then
we
end
up
like
having
an
extra
spec,
but
it
just
occurred
to
me
that,
like
solving
that,
more
generally
might
be
better
than
having
to
do
like
a
special
case
for
this
hook
thing
and
then
realizing.
We
end
up
wanting
to
solve
this
problem
anyway,
down
the
road.
D
A
D
The
only
other
places
where
we
have
extension
points
to
mine,
in
my
mind,
is
around
like
start-up
and
tear-down
life
cycle,
like
you,
don't
have
any
any
hook
hooks
for
that,
but
I'm
not
sure
like
beyond
that.
I'm
not
clear
on
when,
when
we
would
have
other
extension
points
that
we
would
use
this
bundled
concept
for,
if
that
makes
sense,.
C
C
That's
probably
what
what
these
bundles
would
contain,
at
least
at
this
point,
but
I
agree
with
pete
and
that
I
think
we
should
just
kind
of
have
a
quick
thought
experiment,
maybe
in
a
in
a
different
meeting
or
maybe
in
the
thread
about,
if
that
is
a
potentially
better
way
to
solve
the
provider,
hooks
issues
than
provider
hooks,
but
I'm
not
necessarily
saying
that.
I
just
think
it
is
kind
of
a
good,
quick
thought
experiment
to
to
go
through
because
at
least
when
you
described
it
just
in
your
your
use
case
was
like.
C
Oh,
you
know.
We
have
this
kind
of
pattern.
We
want
to
set
this
up.
We
want
to
do
this
teardown
or
whatever,
and
it
sounds
like
pete's
proposal
could
could
solve
your
problem
by
just
you
know,
adding
your
provider
and
then
adding
a
certain
set
of
hooks.
If
I'm
understanding
correctly-
and
that
would
just
be
part
of
the
suite-
I
don't
know
if
that
makes
sense
or
not.
A
Yeah,
I
think
considering
that
makes
a
ton
of
sense
and
maybe
the
next
step
justin.
We
just
introduced
the
that
exactly
what
alex
just
posted
the
open
feature,
enhancement
proposal
flow.
It's
it's
pretty
new,
so
maybe
a
little
rougher
on
the
edges,
but
it's
worth
trying
to
go
through
that
research
go
to
the
research
repo
and
then
basically
open
a
pull
request
with
the
proposal
on
there,
and
we
can
kind
of
have
conversation
in
that
thread
and
then,
once
we,
you
know,
come
to
consensus.
We
would
just
merge
that
over.
A
So
we
have
the
history
of
kind
of
what
the
decision
was.
The
one
thing
just
quickly
worth
noting
about
the
provider
hooks.
The
one
benefit
would
be
the
order
like
you'd,
be
guaranteed
to
say,
like
this
would
run
basically
last,
which
could
have
a
lot
of
benefits
as
well.
But
that
could
be
something
that
we
could
just
cover
in
the
threat,
but
I
think,
having
like
kind
of
the
thought
experiment
documented
and
that
thread
would
probably
be
pretty
beneficial
for
future
us.
I
suppose.
G
Just
just
just
been
thinking
about
multiple
providers,
I
could
imagine
there'd
be
a
like
a
fairly
large
class
problem
and
confusion
around
those
like
how
huge
you
know
like
do.
They
run
asynchronously,
do
they
not
which
one
runs
first,
which
doesn't
like
I
just
that
sounds
like
a
massive
ball
of
wool
and
a
mega
provider
which
also
there's
a
word
is
amazing.
It
would
solve
a
lot
a
lot
of
those
by
solving
all
of
those
problems.
Right
like
just
go
and
bind
the
two
together.
A
Yeah,
I
I
mean
we
haven't
really
talked
too
much
about
a
mega
provider
and
I
think
it
would
be
kind
of
depend
on
the
situation
and
I
think
theoretically,
it
would
work,
but
there
would
be
a
lot
of
questions
out
there
and
it
would
really
be
up
to
whoever
decides
to
implement
it.
You
know,
does
it
make
sense?
Does
it
actually
solve
the
problems
that
they're
intending
to
solve?
I.
E
Yeah
I
mean
I
mean
it
can
see,
use
cases,
but
I
think
we
should
also
like
for
the
offeps
try
to
describe
the
use
case
that
you
want
to
handle
like
an
obvious.
One
might
be
triggering
certain
feature
flags
more
on
the
say,
product
manager,
line
of
business,
side
and
they're
using
different
tooling,
and
you
have
more
on
the
infrastructure
devops
side
and
they
will
use
different
tools.
So
usually
they
should
not
interfere
with
each
other
because
they
are
triggering
entirely
different
feature
flags,
at
least
in
an
ideal
world,
but
yeah
I'm.
E
F
I
mean
like
so
that
that
use
case
is
exactly
the
thing
that
I
was
thinking
of
when
I
was
talking
about.
It
is
like
you
know,
someone
using
someone's
using
like
like
the
devs,
are
using
split
for
their
stuff
and
then
someone's
using,
like,
I
don't
know,
a
like
an
a
b
testing
thing
and
like
from
the
application
offers
perspective,
they
shouldn't
care.
They
should
just
be
asking
for
the
state
of
a
feature
flag
and
it
should
all
be
kind
of
hidden.
F
Ideally,
I
think,
like
personally,
I
think,
a
success
criteria,
kind
of
almost
for
us
like,
as
as
kind
of
like
defining
the
spec,
is
like.
Can
you
do
that
mega
provider
concept
entirely
in
user
land
and
not
like
just
just
in
just
using
the
standard
kind
of
provider
mechanism,
rather
than
having
some
kind
of
special
case
stuff
in
in
open
feature
yourself?.
C
A
E
A
D
A
C
C
C
So
the
goal
the
goal
here
was
to
be
able
to
define
a
kind
of
platform,
agnostic,
end-to-end,
behavior
somewhere,
probably
in
some
some
repo
that
we
could
use
as
a
sub-module
for
sdks
and
then
the
sdks
could
all
test
against
it.
So
I
was
gonna
kind
of
just
build
this
from
scratch
and
then
dave
johnson
had
since
they
built
something
similar
in
harness.
He
actually
kind
of
pointed
me
in
the
direction
of
maybe
using
cucumber,
which
I
thought
was
a
really
interesting
proposal.
C
So
that's
what
I
did
and
I'll
show
you
what
that
looks
like
so
this
is.
This
is
basically
a
a
very
incomplete
or
you
know
just
a
poc
kind
of
amount
of
of
code,
and
it
just
does
some
basic
tests.
It's
all
written
in
gherkin,
which
is
the
cucumber
language
for
specifying
tests,
and
so
this
is
like
a
full
end
to
end
kind
of
test.
Setup
and
then
has
kind
of
included
assertions
and
state.
C
Here
so
basically,
these
tests
match
the
gherkin
you
see
on
the
left,
so
the
idea
is
that
if
any
of
these
expressions
don't
match
the
test
fails,
if
any
of
these
test
cases
are
missing,
the
test
fails
and
it
pulls
out
values
from
the
actual
gherkin
and
uses
that
as
test
data,
so
they
get
injected
into
the
test.
So
this
is
basically
how
all
these
kind
of
frameworks
work.
C
So
the
one
missing
piece,
then,
is
because
this
is
an
integration
test.
We
need
kind
of
a
consistent
back
end.
I
didn't
want
to
kind
of
put
the
burden
of
mocking
a
provider
on
every
single
implementation,
so
I
think
I
came
up
with
a
fairly
elegant
solution
for
that.
It's
basically
a
show
you,
a
distribution
of
flag
d.
C
So
it's
it's
just
this
little.
It
adds
basically
one
layer
to
a
flag
d
image
and
then
we
have
it
published
at
flag
d
test.
Bed,
I
think,
is
what
I
called
it
right
now
on
our
github,
so
the
the
basic
field
they
are
is
you
can
run
this
basic
this,
this
flag,
d
container
just
run
it
in
docker
and
it
exposes
flag
d
with
configurations
that
kind
of
match
this
gherkin.
C
So
this
is
running
obviously
on
my
machine
now
and
then
I
can
run
these
integration
tests
and
basically
it's
going
to
set
up
a
provider
that
talks
to
flag
d
run
the
evaluations
end
to
end,
and
you
know
we
get
basically
an
end-to-end
test
suite
just
to
prove
that
that's
actually
working
I'll
run
the
integration
again
without
running
the
container
and
you'll
see
everything
just
fails
because
the
values
aren't
available.
So
everything
just
defaults.
C
C
We
could
even
kind
of
embed
these
scenarios
into
non-normative
data
non-normative
sections
in
the
spec.
If
we
felt
like
it
or
we
could
have
a
separate
repo
for
for
them,
but
then
we'd
just
kind
of
pull
that
as
a
sub
module
and
any
sdk
that
wanted
to
implement
this,
and
they
would
write
the
ger
contest
and
that's
it.
I
would
recommend
we
keep
them
fairly
high
level
and
it
would
all
be
black
box
kind
of
end-to-end
testing.
So
you
know
no,
no
implementation.
D
C
So
right
now
I
guess
this
is
something
that
I'll
talk
about
in
a
second.
Maybe
I
should
have
had
these
points
in
different
orders,
but
right
now
we
have
the
node
contribs
repo
up,
which
has
the
flag
d
provider
in
it.
That's
what
I
would
that's
where
I
would
suggest
we
have
flag
d
provider
implementations
for
every
language,
so
I
was
going
to
hopefully
start
working
on
a
java,
contribs
repo,
something
I
would
like
to
get
some
help
with,
but
I
don't
think
it
should
be
in
the
sdk.
C
D
C
C
C
F
Something
that
always
kind
of
hurts
my
brain
a
little
bit
with
these
kind
of.
I
think
it's
really
like.
I
think
it's
a
really
interesting
approach.
I
mean
it's
really
good
approach.
One
thing
that
always
really
hurts
my
brain
a
bit
with
these
kind
of
like
integration
tests
is
like
what
are
we
actually
testing
like?
Are
we
testing
the
the
provider
we're
testing
the
like
we're
testing
the
actual
running
provider?
Are
we
testing
the
the
like
the
sdk
implementation,
the
open
feature,
sdk
implementation,
we're
testing
like
the
provider
implementation
like
or
is.
D
C
So
I
think
yeah,
so
it's
an
integration
test.
So
there's
definitely
you
know
it
doesn't.
Have
it's
not
a
fully
granular
test.
What
I
would
argue
what's
being
tested
here
is
some
of
the
basic
sdk
functionality,
so
the
actual
the
defaulting
behavior
look.
What
we
could
test
is
the
defaulting
behavior,
the
evaluation
behavior,
the
context
passing
behavior.
C
It
makes
sure
that
if
a
flag
is
not
that,
we
can
make
sure
that
if
a
flag
is
not
found
by
the
provider,
for
instance,
that
the
default
is
fired,
so
it
would
be
mostly
the
sdk
functionality
itself
that's
being
tested
here,
because
the
flag
d
provider
is
there
is
used
and
because
flag
d
is
configured
in
the
in
the
background,
those
aren't
really
under
test
yeah.
I
hope
that
answers
your
questions.
F
B
I
think
just
to
chime
in
the
ultimate
goal
here
from
my
perspective,
is
to
test
performance
against
the
api
right,
but
making
sure
the
sdks
are
all
homogenous
in
their
responses,
or
at
least
they
expect
at
least
we
have
the
expectation
of
they
will
comply
to
the
api.
What
they
do
like
todd
said
internally
could
be
very
different,
but
this
definitely
looks
like
an
awesome
start
to
me,
but
to
your
point
rmp,
I
think
it
is
kind
of
a
bit
of
a
an
iceberg
right.
F
F
I
think
it's
just
good
to
be
really
clear
on
that,
and
I
do
think
it's
interesting.
The
idea
of
like
you
could
that's
at
some
point,
if
you,
if
you
could
get
like
a
nice,
a
nice
kind
of
like
set
of
of
kind
of
cucumber
scenarios,
you
could,
in
theory,
also
use
this
as
a
way
to
help
someone
implementing
a
provider.
C
Yeah
and
I
agree,
I
think
I
think
that
the
challenge
will
be
kind
of
enumerating
tests
that
don't
actually
deviate
at
all
into
implementation,
but
also
provide
a
lot
of
value.
So
I
can
talk
more
about
what
those
might
be,
but
I
think
I
kind
of
mentioned
some
of
them,
so
you
know
defaulting
behavior
and
errors,
making
sure
that
context
is
passed
correctly.
That's
all
stuff
we
can.
A
C
Yeah
I'll
I'll
stop
sharing
here.
So
there's
a
couple
other
things
I
wanted
to
mention.
I
think
I
can
be
short
on
this
one,
because
the
context
transformer
discussion,
I
think,
can
we
can
basically
pre-empt
that
with
the
discussion
on
on
provider
hooks,
so
I
won't
even
get
into
it.
I
think
that
if
we
input
provider
hooks,
the
kind
of
transformer
should
go
away.
C
I
think
that's
it
for
that
point
and
then
quickly
I'll
say
we
basically
finished
the
node
sdk
contribs
groundwork.
So
again,
this
is
like
a
this
is
a
mono
repo
and
nx
monorepo,
where
you
can
basically
add
providers,
you
can
add
hooks.
You
can
add
code
that
essentially
anybody
can
use
to
extend
open
feature
and
add,
add
functionality,
and
it's
where
we're
hosting
the
flag
d
provider.
For
now
we
don't
have
a
java
contribs.
I
think
we
will
need
one
relatively
soon,
that's
my
opinion.
At
least.
C
I
would
like
help
on
that.
If
anybody
feels
like
they
have
the
ability
to
lend
some
lend
a
hand
there
but
yeah.
My
plan
was
to
probably
go
with
similar
concepts
to
what
we
have
in
the
in
the
node
sdk,
in
terms
of
maybe
using
release,
please
to
manage
releases
and
just
have
a
big
mono
repo
of
maven
artifacts.
C
D
A
good
idea,
my
my
main
question,
is
like
why
mono
repo,
I
have
a
like
the
thought
that
I
had
originally
well.
The
thought
that
I
had
45
seconds
ago
was
if
we
need
to
update
something
and
there's
like
a
com
conflict
in
how
dependencies
are
managed
between
these
different
projects.
Man,
that
sounds
like
a
pain
in
the
ass
could
be,
and
so
that
was
my
thought
that
this
there's
as
much
thought
as
I've
put
into
it.
So.
C
A
A
One
idea
is
like
there's
some
content
that
could
pretty
easily
be
moved
in
there
like
the
glossary,
for
example.
So
if
we
do
move
like
the
glossary
to
the
docs,
do
we
have
a
strong
opinion
on
you
know
removing
it
from
the
spec
portion,
which
maybe
it
doesn't
even
make
sense
to
be
there
in
general?
I
I
don't
really
want
to
maintain
it
in
two
places
and
get
away
with
it.
A
A
Okay,
yeah,
no,
no
problem
that
makes
sense
cool,
I'm
glad
I
brought
it
up
then,
before
I
moved
it
so
and
the
other
one,
I'm
still
I'm
working
on
provider
recommendations.
I
have
some
stuff
written
locally,
but
that
is
something
that
expect
a
pull
request,
probably
either
today
or
tomorrow,
and
that
just
talks
about,
like
you,
know,
recommendations
on
where
you
could
put
your
provider
what
names
you
should
use
if
you're
gonna.
A
G
A
I
mean
it's
a
great
question.
I
think
that's
something
we
should
talk
about.
I
mean,
ideally,
there
would
be
some
kind
of
like
badge
of
some
kind.
You
know
if
it
was
like
if
this
was
maintained
by
like
the
vendor,
that
I
think
that
means
more
than
just
some
random
contributor.
You
know
that
just
did
it
because
they
find
it
interesting
or
something
like
that.
How
we
can
denote
that.
A
A
G
Maybe
certification
is
the
wrong
word
but
like
or
I
don't
know,
just
some
sort
of
yeah,
I'm
just
in
my
head.
I've
got
this
idea
of
like
a
big
grid
and
you've
got
like
you
know:
yeah
the
vendor
provider
or
vendor
offered
provider
or
the
I
don't
know
some
approved
providers.
It's
just
like,
like
we've
had
issues
with
like
node
sdks
right
there's.
G
G
G
It
but
like
yeah
it's
I
guess
my
worry
would
be
like
someone
just
throws
the
provider
out
there
and
then
I
don't
know
yeah.
Maybe
it
sort
of
decays,
because
the
specs
changed
and
then
you
know
yeah
make
yeah.
I
don't
know.
Maybe
it's
simple
to
just
have
like
you
know,
an
official
provider
or
a
provider
contributed
one
in
a
open
source,
one
or
something
but
yeah.
So.
E
Yeah,
this
is
a
bit
down
the
line.
I've
seen
this
issue
like
in
the
wwc,
where
it
was
really
about
browser
renders
and
like
doing
this.
I
think
the
best
approach
there
is
still
a
test
suite,
but
in
this
case
we
even
had
like
the
browser
vendors
being
responsible
for
running
that
test,
suite
and
publishing
that
the
results
which
we
could
then
federate.
E
E
E
You
run
your
test
suite
you
publish
your
results
based
on
a
release,
what
you
pass
and
keeping
it
in
people's
responsibility,
because
otherwise
you
you
you
produce
a
lot
of
overhead
and
who
would
volunteer
to
probably
dedicate
one
full-time
person
to
just
maintaining
test
suites
of
stuff-
they
quite
frankly
like
conceptually
care
about
because
they
want
the
project
to
be
great,
but
when
it
comes
down
to
everyday
work,
they're
not
like
that
invested
into
it.
I.
F
Think
you
get
into
some
weird
kind
of
political
waters
potentially
as
well,
where,
like
someone's
grumpy,
because
they're
things
not
officially
supported,
and
then
I
think
keeping
it
just
extremely
objective
on.
Does
it
pass
the
test
we
will
not
make
sense.
I
also
feel
like
it's
a
like
a
good
problem
to
have
in
the
future,
because
there's
so
much
adoption
of
open
feature.
Doesn't
I
don't
think
it's
necessarily
something
we
need
to
be
super
stressed
about
right
now.
A
F
A
Thing
that
we
may
want
to
include,
though,
is
just
say
like
if
we
could
have
some
kind
of
official
stamp
like
yes,
this
is
you
know
like
thomas
just
just
worked
on
the
go
feature,
flag,
node
provider
and
if
we
could
just
say
like
yes,
this
is
like
kind
of
maintained
by
like
that
project
or
something
I
think
that
gives
it
a
little
bit
more
substance
than
just
like.
You
know.
This
is
a
person,
that's
just
a
big
fan
of
that
project.
D
D
E
Couple
days,
unless
people
are
always
quite
worse,
if
they
look
at
open
source
projects
to
decide
whether
they're
good
quality
or
not,
I
think
every
one
of
us
has
like
the
checkbox
list
that
they're
going
after
and
looking
at
the
project
like
how
many
people
are
working
on
it.
How
if
we
have
to
release
what
a
compliance
test,
coverage
and
so
forth,
so.
A
It's
mainly
around
like
our
docs,
like
which
ones
would
we
want
to
highlight,
and
how
would
we
make
it
clear?
You
know,
because
there
is
a
distinction,
I
think
between
you
know,
vendor
or
project
supported
ones
versus
just
community
supporting
ones.
So
I
think
that's
probably
a
good
idea
just
having
some,
maybe
two
different
tables,
or
at
least
a
column
that
specifies
the
the
difference.
B
Yeah,
it
was
just
to
reiterate
the
idea
that
the
research
repo
now
has
the
ofep
convention
and
I
put
together
a
template.
So
if
you
wanted
to
get
started,
I
just
wanted
to
spend
two
minutes
just
explaining
how
if
you
want
to
bring
something
to
discussion,
just
create
a
branch
off
that
repo
or
fork
it
and
create
your
own
branch
and
then
create
a
pr
off
of
that,
and
you
can
use
the
template
and
we
increment
the
the
template
version
to
say
hey.
This
is
some
feature
I
want
to
chat
about.
B
What's
nice
about
that,
is
you
get
the
discussion
in
the
history
of
the
pr
when
it's
been
merged,
but
then
also
you
can
get
the
end
result.
The
problem
as
we're
seeing
with
the
issues
is
that
we
came
to
a
conclusion
on
something,
but
that
could
be
lost
right.
You
know
that's
just
sitting
in
an
issue,
whereas
we
now
have
something
that
is
in
the
git
log,
and
we
also
make
revisions
on
those
things
right
as
time
passes.
So
I
just
wanted
to
to
call
out
that.
B
Firstly-
and
the
second
thing
was,
I
don't
know,
there's
a
standard
convention
in
the
organization
in
github,
I've
noticed
pr's
have
been
merged
that
I
haven't
finished
reviewing,
so
I
was
on
holiday.
I
was
reviewing
a
pr
and
I
had
open
questions
on
it.
It's
been
it's
been
merged
in
and
I
just
I
don't
care
about
that.
You
know
that
that's
cool,
but
I
think
maybe
as
an
organization
as
a
team
we
should
think
about.
B
Should
we
say
that
at
least
all
all
issues
must
be.
All
questions
must
be
answered
and
by
answering
that
that
means
that
the
person
who
answers
it
can't
be
the
one
to
resolve
it,
because
otherwise
I
could
just
answer
and
resolve
and
then
that
would
auto
pass
the
github
check
box.
So
maybe
we
could
just
make
a
convention
of
saying
look
as
long
as
the
person
you
replied
to
closes
that
out.
We're
happy-
and
I
don't
know
mike
this
is
one
for
you,
but
at
an
organizational
level
we
can
enable
that
on
our
projects,.
B
G
C
Yeah,
arguably,
there's
still
some
value,
even
if
that's
not
the
case,
because
the
act
of
going
and
resolving
something
has
some
amount
of
of
responsibility
like
it's
at
least
an
action
that
you
know.
I
went
in
as
I
said,
resolve
to
this
and
it's
and
it's
auditable
you
can
see
who
resolved
it.
I
believe
so
there's
at
least
that,
but
I
guess
the
question
is
how
valuable
that
is
in
itself.
I.
B
A
Yeah
I
mean
it
seems
like
an
easy
change
to
make
and-
and
we
can
certainly
test
it
out,
at
least
if
and
if
someone
has
opposition
to
it.
You
know
we
could
talk
about
it
at
the
next
community
meeting
or
something
but
I'll
go
ahead
and
enable
it
for
now
and
let's,
let's
see
how
it
goes,
but
I
mean
it
seems
like
a
pretty
low
barrier
honestly
just
to
resolve
all
the
the
comments
on
a
pull
request
before
it's
merged.
C
B
Yeah
my
experience
with
github
bonus
files
owners
files
versus
github
is
really
interesting
right
because
you
can
actually
have
permissions
in
github
that
supersede
the
owner's
file
permissions,
so
you
might
be
on
one,
but
not
the
other.
You
might
be
on
both
and
then
the
behavior
becomes
like
really
bizarre,
so
yeah
if
you've
got
if
you
know
how
it
works
exactly
because
we've
done
this
in
the
tag.
App
delivery
and
we've
had
a
lot
of
problems
with
it.