►
From YouTube: OpenFeature - Project Meeting, April 27th, 2023
Description
Meeting minutes https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ
OpenFeature website: https://open-feature.github.io/
B
B
D
B
F
E
B
E
E
G
H
J
E
G
C
G
A
G
Cool
yeah
so
I
think
that's
all
the
new
faces
thanks
everybody
for
joining
the
agenda
this
this
meeting
isn't
too
long.
So
it
might
be
a
short
and
sweet
one
unless
we
kind
of
just
kind
of
improvise,
which
sometimes
that
happens
too,
so
that
that's
we're
welcome
to
do
that,
but
I'll
get
started.
I
wanted
acrylic
to
quickly
debrief.
I
G
G
G
Yet
they
were
still
in
transit,
so
it
ended
up
being
less
of
a
maintainer
meeting
per
se
and
more
of
a
I
don't
know
interested
party
meeting
I
guess
there
was
a
lot
of
people
who
weren't
too
familiar
with
the
project
there,
but
we
basically
packed
out
all
the
seats
in
the
room
so
that
that
was
that
was
surprising.
I
I
mean
it's
more
of
a
conference
room.
G
It
wasn't
like
it
wasn't
like
an
Amphitheater
or
anything
like
that,
but
most
of
the
seats
were
filled
to
my
memory
and
there
was
a
lot
of
kind
of
interest
in
the
project
from
people
who
hadn't
heard
about
it,
and
so
we
kind
of
did
some
basic
introductions
and
I.
The
thing
I
appreciated
from
that
meeting
was
really
getting
use
cases
from
people
and
it
was
a
validation
of
a
lot
of
the
things
that
we
know
to
be
interesting
about
the
project
for
big
Enterprises.
G
We
heard
that
we
heard
also
the
like.
You
know:
our
org
has
internal
Solutions
right
now,
but
we
don't
have
an
SDK
or,
and
so
that
kind
of
thing
as
well,
so
it
was
yeah
just
a
big
validation
of
a
lot
of
the
stuff
we
already
know
and
I
think
we
actually
got
some
contributors
out
of
it.
As
well,
the
other
takeaway
there
that
was
a
consistent
theme
throughout
all
of
kubecon
was
people
want
python.
They
want
a
python
SDK
and
we
don't
have
it
yet.
I
H
G
G
G
So
if
you,
if
you
basically
click
that
link
you'll,
see
all
of
the
issues
we've
identified
as
required
for
a
1.0
release
of
python
and
some
of
them
have
already
been
knocked
off,
which
is
great,
but
we're
not
that
far
away
so
yeah
that
was
kind
of
the
output
of
that
meeting
and
then
at
the
booth.
We
saw
yeah
a
lot
of
people
interested
in
the
project.
G
We
had
a
lot
of
traffic
and
the
people
interested
for
kind
of
two
main
reasons
more
along
the
lines
of
what
I
already
mentioned
so
either
their
Enterprise
with
multiple
kind
of
Homegrown,
Solutions,
possibly
looking
to
migrate
to
a
vendor
and
yeah,
then
other,
in
other
cases,
we're
looking
to
get
into
future
Flags.
But
don't
want
to
make
a
commitment
with
the
vendor.
G
It
was
actually
more
in
the
first
category,
a
lot
more
people
interested
in
just
vendor
neutral
feature
Flags,
either
for
onboarding
or
kind
of
consolidating
yeah.
We
already
kind
of
talked
a
little
bit
of
a
python,
so
that
link
is
there
Pete
anyone
else?
If
you
are
interested
in
contributing
to
the
python
SDK,
we
could
definitely
use
even
more
help
there.
So
I'm
feeling
more
confident
than
ever.
We
have
the
right
team
in
place
now.
G
J
J
Not
quite
refresh
my
memories?
You
said
that
that
people
were
starting
to
use.
It
was
some
other
like
simple
key
value:
data
store
or
state
management
system
in
in
the
kubernetes
ecosystem,
that
that
were,
people
were
using
to
that
attached
to
flag,
D,
I,
think
and
or
they
were
using
it
as
like
a
provider,
but
it
wasn't
designed
in
any
way
to
do
like
flagging.
H
J
G
Yeah
I
mean
certainly
there's
a
lot
of
interesting.
Like
that.
That's
kind
of
one
of
the
interesting
things
about
the
project.
You
could
basically
have
any
kind
of
state
store
and
use
it
as
use
it
as
a
a
back
end.
I
mean
evaluation
becomes
a
little
bit
complicated.
If
you
don't
have
the
ability
to
kind
of
run
arbitrary
functions,
although
you
can
serialize
those
and
run
them
in
in
your
provider.
If
you
want
are.
I
H
I
H
G
F
E
G
G
B
G
I
think
I'll,
try
and
I'll
try
and
rephrase
your
internet
seems
more
stable.
Now
the
connection
is
more
stable
now,
but
what
I
think
I
got
from
that
was
yeah,
I
I
think
we
talked
to
kubecon
and
you
were
talking
about
some
kind
of
alternate
command
and
control
potentially
for
flag,
D
Beyond,
really
just
the
Primitive
stuff
we
have
yeah
I
mean
that's,
that's
definitely
something
that's
possible.
G
So
to
continue
to
maintain
neutrality,
we
may
want
to
consider
doing
that.
You
know
it's
kind
of
like
to
compare
open
Telemetry
to
open
feature,
it's
kind
of
like
a
yak
or
something
like
that.
So
as
it
gets
more
feature
Rich,
if
it's
especially,
if
we're
going
to
attach
things
like
a
UI
to
it,
we
may
want
to
break
it
out
into
a
separate
org
but
I
think
that's
a
decision.
We
need
to
make
it
at
probably
the
governance
level
of
the
project
and
maybe
involve
the
cncf.
G
G
I
I,
don't
know
I
I,
don't
know,
I
mean
at
the
very
least
the
GitHub
org,
but
it
may
need
to
be
moved
out
into
a
separate
cncf
project.
I
mean
the
the
org
is
just
a
an
artifact
in
GitHub,
but
it
may
require
separate
governance
to
avoid
conflicts
of
interest
and
that
kind
of
thing
so
yeah
I'm
I'm,
not
sure
about
that.
I
think
that
needs
to
be
again
something
to
GC
really
tackles
that's
kind
of
my
my
thinking
on
that.
But
I
mean
as
as
for
additional.
G
Like
extensions
to
flight
d,
I
I
mean
I,
think
it
there's
a
lot
of
value
there.
I,
don't
know
how
much
time
we're
going
to
I,
don't
know
how
much
time
or
resources
we
have
as
a
project
to
like
make
that
fully
featured
I
mean
I,
don't
think
it's
ever
going
to
be
like
an
Enterprise
alternative,
because
I
I
can't
see
people
contributing
things
like
saml
integration,
for
example,
and
that's
the
type
of
thing
you'd
want.
I
I
agree
with
all
this
stuff,
you're
saying
and
I.
Think
the
the
analogy
with
jaeger
is
is
a
very
apt
one,
but
you
know
a
lot
of
people
build
stuff
on
top
of
a
viego
as
far
as
I
understand
I'm,
not
like
super
deep
in
the
urban
country
world,
but
yeah
just
because
it
doesn't
have
all
that
all
that
stuff
I
think
I
think
that's
why
it's
a
nice
compliment
to
the
commercial
offerings,
because
it's
it
I.
I
K
K
Were
the
Flag
Day
conversation?
Is
there
something
we
have
to
get
scheduled
with
the
governance
board,
then
because
it's
definitely
been
a
question.
That's
popping
up
kind
of
yeah,
historically
so
yeah.
It
would
be
helpful,
I
think
to
know
if
we
can
actually
get
that
schedule
and
get
to
the
decision
on
it.
I
J
We
just
to
add
to
that,
do
we
have
a
do?
We
all
know
what
we're
talking
about
in
terms
of
what
the
up
like
what
what
are
the
is
it
like
as
it
currently
stands,
or
as
a
separate
project
or
are
there
I,
don't
know
things
in
between
or
is
it?
Is
it
just
one
of
two
options
that
everyone's
clear
on
or
are
there
other
options
as
well.
G
E
E
One
thing
is:
if
it
goes
to,
the
simpler
solution
is
having
well
simpler
in
a
way
like
is
having
you
know.
If
you
have
the
sub
project
that
stays
within
you
don't
have
to.
You
can't
have
a
different
governance
committee,
but
you
also
don't
have
to
go
over
the
whole
sandbox
application
again
If.
Instead,
it
becomes
a
completely
separate
project.
You
have
to
reapply
for
the
whole
sandbox
which,
like
cntf,
is
usually
quite
busy.
E
G
That's
kind
of
really
as
a
neutral
kind
of
demo
flag.
D
is
really
useful
there,
but
I
I.
Don't
really
feel
strongly
that
flag
D
even
necessarily
needs
to
maintain
its
sandbox
status,
because
it's
not
the
heart
of
the
project,
the
heart
of
the
project
or
the
vendor
neutral
sdks.
The
specification
all
that
stuff.
It's
an
implementation,
I'm
totally
happy
to
see
it
grow
and
flourish
and
become
its
own
thing.
However,
you
know,
however,
that
goes
but
I
don't
feel
like
super
strong
about
it.
G
K
You
know
like
that,
ofep
around
providing
the
providers
through
flag
D
that
impacts
how
like,
if
we
aren't
supporting
or
if
we
have
more
features
than
is
just
in
what
flight
D
offers
through
open
feature
you
that
SDK
is
then
abstracted
away
which
is
impactful
for
us
and
if
we
support
the
project
which
we
want
to
continue
to
by
default
a
flag
these
in
the
project.
It's
kind
of
hard
to
have
the
conversation
of
like
hey,
we
support
open
feature,
but
this
one
part
of
flag
D.
K
J
K
So
if
neither
of
those
went
through,
but
someone
wanted
to
use
open
feature
but
really
wanted
these
specific
features
from
the
SDK,
they
can
no
longer
access
it
because
the
SDK
would
be
implemented
in
a
sidecar,
which
you
know
in
one
pattern
and
not
saying
that
these
are
all
definitely
going
to
come
to
pass.
Or
you
know
a
lot
of
this
goes
through
process,
but
that's
just
where
you
can
see.
K
C
Yeah
and
I'd
like
to
Echo
that,
like
I've,
been
implementing
I've
been
working
on
some
some
open,
Future
Integrations
for
for
Dev
cycle
and
the
same
thing
like
the
the
tracking
endpoints
and
for
events
and
not
having
sort
of
How
It's
modeled
and
hey,
hey.
You
don't
really
have
access
to
the
the
the
the
sort
of
the
underlying
client
like
devcycle
SDK,
unless
you
sort
of
host.
That
yourself
is,
is
a
bit
odd.
C
G
Yeah
I
mean
I
I
think
as
far
as
tracking
that's
something
that
we're
open
to
discussing
further
the
the
I
mean
the
problem
is
that
there's
at
some
points
there's
an
impedance
mismatch
between
the
feature
set
of
some
of
the
some
of
the
tools
and
others
right.
So
not
every
tool
offers
tracking.
So
then
you
know
there's
a
question
of
well
does.
G
That
is
that
the
is
that
something
we
want
to
get
into
the
business
of
of
doing
maybe
I
mean
there's
there
could
be,
for
instance,
one
of
the
things
we
discussed
at
an
early
point
in
the
project
is:
is
kind
of
segmenting
out
tracking,
so
you
can
set
a
distinct
tracking
provider
which
may
or
may
not
be
the
same
underlying
provider.
That
does
your
feature.
Flags
and
abstracts
kind
of
similar
functionality
well
or
functionality
in
a
similar
way.
G
I
I
mean
I
think
it's
a
it's.
Definitely
an
interesting
thing
to
think
about
not
not
necessarily
the
tracking
thing
specifically,
but
how
does
the
SDK
provide
the
right
extension
points
so
that
a
vendor
can
do
the
things
they
want
like
so
vendors
or
or
so
on
one
hand,
vendors,
but
also
kind
of
application.
G
H
G
I
Like
are
there
I
mean?
Maybe
this
is
too
much
of
it
too
much
of
a
meaty
topic
to
get
into
right
now,
but
I
wouldn't
I
would
maybe
maybe
toddy
already
kind
of
get
exactly
what
what
Jonathan
and
Daniel
are
saying.
I'm
I'm
a
little
bit
I
would
love
to
get
hear
more
about
the
details
of
like
what
what
I
guess
a?
C
A
couple
of
things
like
just
as
like
I'm
in
the
middle
of
like
one
of
my
top,
my
head
of,
like
we,
have
functions
for
like
grabbing
all
variables
right
that
are
like
there's
certain
use
cases
where
people
want
to
grab
all
variables
are
all
all
all
all
experiments
that
that
our
SDK
has
and
so
those
functions.
Those
functions
are
used
pretty
frequently
by
our
customers,
and
we
can't
really
expose
that
through
the
current
API.
C
I
K
And
that's
I
think
where
the
question
is
and
I
just
say:
it's
a
pretty
midi
topic
to
get
into
I.
Think
I
don't
know
if
there
is
a
problem
there.
The
only
thing
I
was
Raising,
and
this
is
just
getting
back
to
like
why
we
see
Flag
Day
is
we're
trying
to
move
it
to
a
separate
project
is
because,
like
it
doesn't
do
that
today,
so
maybe
in
the
future,
but
also
just
the
way
our
SDK
works
is
usually
locally
in
memory
and
there's
trade-offs
around
that.
K
H
G
G
We
we've.
We
chose
not
to
implement
bulk
evaluation
intentionally
kind
of
at
the
recommendation
of
of
a
few
vendors
yeah,
and
it's
something
we
could
definitely
come
back
to
and
revisit.
If
there's,
if
there's
more
interest
but
yeah,
we
did,
we
did
kind
of
choose
not
to
do
that
at
the
end
of
the
day.
Like
I
think
all
abstractions
are
leaky
and
right.
G
Open
feature
is
an
abstraction,
so
there's
going
to
be
leaks,
and
so,
when
you
choose
to
use
it,
there's
going
to
be
parts
of
underlying
sdks
that
you
don't
have
full
full
access,
tube
and,
and
we
have
to
make
as
as
maintainers,
we
have
to
make
Intelligent
Decisions
over
how
leaky
we
want
that
abstraction
to
be
versus
how
complex
the
solution
gets
and
maintenance
gets,
and
the
specification
gets
right.
I'm
more
of
a
conservative.
Less
is
more
person
when
it
comes
to
stuff
like
that,
but
maybe
maybe
too
much
sometimes
yeah.
G
That's
that's
my
take
on
that
one
and
I
I.
Guess
that's
about
it
for
me,
because
I've
kind
of
mentioned,
the
the
client
stuff
and
the
event
internet
shutdown,
I'd,
love
feedback
on
those
there's
been
a
lot
of
good
feedback
already,
but
yeah.
Those
two
PRS
that
are
mentioned
there
and
the
notes,
179
and
182.-
are
I.
Think
really
important
for
for
our
client,
as
well
as
just
general
features
that
I
think
we
really
need
yeah.
That's
about
that's
about
all
I
had.
C
I
would
say
our
customers
are
lean,
probably
more
50,
50
and
and
a
lot
of
basically
all
of
our
customers
use
us
in
in
some
way
across
both
their
back
end
and
front
end,
be
it
mobile
or
web.
So
just
interested
to
see
like
interested
to
hear
sort
of
what
the
project
thinks
of
that
and
like
are.
Are
we
pushing
towards
sort
of
more
client-side
sdks
at
some
point,
or
is
that
something
that's
kind
of
open
for
for
a
future
thought.
G
That's
really
been
my
main
focus
over
the
last
couple
months,
so
both
the
both
the
draft
PR,
the
spec
PRS
that
I
mentioned,
contribute
to
that,
because
I
believe
that
both
initialization
and
shutdown
as
well
as
event
hooks,
are
kind
of
crucial
for
for
client
usage
and
then
the
last
one
is
like
the
static
versus
Dynamic
concept
context.
So
Pete
has
a
really
great
blog
post.
That
I
I'll
ask
him
to
link
in
the
notes
that
kind
of
goes
over
our
thinking
in
terms
of
client.
G
We
also
have,
if
you
look
actually,
if
you
look
in
both
the
PRS
that
I
mentioned,
you
can
see
in
our
playground.
I've
implemented,
I've
implemented
based
on
our
experimental
web
SDK,
which
is
published
as
an
experimental
module.
I've
implemented
five
web
client
providers,
so
flagsmith
Cloud
bees
launch
Darkly
split.
G
I
C
I
For
that
initial,
the
initial
kind
of
release
of
the
spec
and
then
we've
subsequently
turned
our
Focus
to
the
client
side
and
getting
pretty
darn
close
at
this
point
to
I
think
yeah,
I
think
very,
very
close
to
to
having
that
full
from
a
spec
perspective
like
the
full
thing
built
out,
and
then
it's
just
a
case
of
getting
all
of
the
providers
lined
up
to
support.
All
of
the
you
know.
I
I
One
thing
that
I
think
we
like
help
on
all
of
it
is
very
gratefully
received.
I
think
I've
said
this
before,
but
Todd's
probably
sick
of
me
hearing
it
because
I've
said
it
on
a
bunch
of
kind
of
interviews
with
vendors
and
stuff,
but
like
getting
getting
feedback
from
from
vendors
is
like
super
useful,
because
vendors
see
a
lot
more
of
people
like
what
people
are
doing
in
the
wild
than
we
have
access
to.
I
So
you
understand
the
use
cases
and
the
gotchas
and
all
that
stuff
a
lot
a
lot
more
and
like
kind
of
harvesting.
All
of
that
hard
one
experience
and
using
it
for
for
good
is,
is
part
of
what
we'd
like
to
do
specifically
I
think
a
place
where
I
feel
like
we've
not
had
as
much
input
or
experience
is
around
the
mobile
area.
I,
don't
know
if
anyone
else
maybe
I'm
speaking
outside,
but
it
feels
to
me
like
we
like.
I
Definitely,
for
me
my
focus
is,
or
my
experience
is
way
way
more
on,
like
client-side
JavaScript
than
than
Android
or
or
iOS,
and
when
we
have
talked
to
folks
about
mobile
stuff,
specifically
like
Justin's,
helped
us
out
a
lot.
They
were
talking
with
Folks
at
eBay.
There's
some
stuff,
that's
just
not
obvious.
I
Unless
you
have
like
kind
of
like
slogged
through
the
trenches
like
I,
think
we
heard
some
stuff
about
launch
Darkly
and
when
we
talked
to
launch
Darkly
about
kind
of
needing
to
be
a
lot
more
respectful
of
network
and
battery
and
stuff
like
that,
which
just
isn't
obvious
until
you've
slugged
through
it
a
little
bit.
So
that
would
be
particularly.
C
Yeah
I've
been
I've,
been
through
I've,
been
slogging
through
mobile
sdks
for
about
a
decade
with
tabletics
for
or
AP
testing,
and
now
with
with
devcycle
for
the
last
couple
years.
So
yeah
have
have
lots
of
experience
with
with
mobile
and
working
with
some
large
companies
there
so
happy
to
help.
Oh.
J
Just
just
that's
and
that's
happened
organically
as
well.
We
never
sat
down
and
designed
it
like
that.
It's
like
they're,
a
good
customer
use
cases
for
those
three
times
as
many
things.
So
it's
def.
It's
definitely
going
to
be
more
challenging
and
yeah.
So
my
my
thoughts
are
yeah
like
aiming
at
a
like.
The
common
denominator
is
possibly
going
to
be
a
little
bit
smaller
and
that's
going
to
make
it
a
little
bit
less
effective
that
that
would
be
my
Approach
foreign.
G
So
we're
minimizing
the
kind
of
code
that
that
has
to
we're
local,
localizing
and
centralizing
all
the
code.
That's
going
to
be
very
vendor
specific
in
terms
of
initialization
and
stuff
like
that
and
then
letting
developers
kind
of
run
wild
with
a
consistent,
API.
I.
Think,
that's
that's
the
vision,
that's
the
hope,
but
we
need
to
get
the
abstractions
right
and
and
like
one
of
the
key
things
is
like
the
static
context.
G
So
far,
we've
seen
at
least
on
the
client
you're
generally
working
in
the
context
of
one
user
and
then
changes
to
that
to
the
state
are,
are
slightly
less
frequent
and
sometimes
involve
chatter,
but
at
least
but
there's
at
least
like
this
kind
of
this
state.
That's
mutated,
this
kind
of
maintained
and
mutated
across
application
actions,
whereas
the
server
is
like
completely
Dynamic
right.
The
context
of
the
request
is
changing
with
every
single
HTTP
request.
G
C
You
know
I
would
point
out.
Probably
one
of
the
most
important
things
for
client
side
to
get
right
is
the
caching
mechanisms,
because
different
sdks
handle
those
caching
mechanisms
differently,
they're,
very
critical
to
like
how
the
flags
that
you
get
evaluated
on
the
client
side
and
and
updates
to
to
to
to
values
I
think
because
of
those
caching
mechanisms
and
how
you
may
want
not
want
to
delay
the
start
of
a
application.
You
may
want
to
use
cash
values
for
your
flags
at
the
startup
application.
C
G
Yeah
totally
I
mean
I'm
I'm
kind
of
relieved
to
hear
that,
because
that's
what
we
kind
of
notified
is
the
main
challenges.
So
we've
tried
to
create
hooks
into
the
API
that
allow
you
to
kind
of
control
and
react
to
to
those
things
like
react
to
changes
in
the
that
state
in
the
cache,
State
and
control
when
that
state
is
updated
and
that
kind
of
thing
so
yeah
I,
think
I
think
we're
on
track
there.
But
that
would
be
the
kind
of
thing
that's
great
to
have
validated.
J
C
Or
you
can
do
it
all
in
JavaScript,
but
for
certain
scenarios
it
actually
makes
a
lot
of
sense
to
use
the
native
like
for
as
a
vendor
like
for
us.
It
actually
makes
a
lot
of
sense
to
do
Bridges
to
the
native
code,
but
it
might
not
make
sense
for
openfeature
to
do
that
to
just
integrate
with
the
the
JavaScript.
F
C
I
H
A
I
I
think
I
would
Echo
the
thing
that
that
Todd
said,
but
I
think
that
we
I
think
we
have
and
the
a
kind
of
a
a
small
enough
kind
of
clean
enough
interface
between
the
SDK
and
the
provider,
that
a
lot
of
that
complexity.
We
can
kind
of
push
into
provider
space
and
as
long
as
there's
like
two
or
three,
like
kind
of
like
interaction,
points
between
the
running
open
feature,
SDK
and
the
provider
and
like
the
amount
of
stuff,
particularly
like
the
amount
of
kind
of
state
that
we're
trying
to
manage.
Going
back.
I
To
that
caching
thing.
The
USA
and
Jonathan,
like
the
amount
of
kind
of
state
and
bad
stuff
that
we're
trying
to
manage,
is
I
I.
Think
it's
almost
as
small
as
we
can
make
it
so
that
the
provider
can
can
figure
that
out
and
decide
whether
that
you
know
whether
that's
running
in
whether
the
state
is
running
on
you
know,
is
stored
in
JavaScript
or
native
runtime
and
where
that
kind
of,
like
calculation
is
being
made
as
to
where
to
evaluate
the
flag.
G
Yeah
I
think
it's
more
like
our
main
concern
to
to
basically
put
what
what
peaches
said
a
different
way.
Our
main
concern
is
to
present
an
idiomatic
API
to
the
application
author,
not
to
solve
not
to
solve
complex
problems
for
the
provider.
The
provider
knows
how
they
want
to
how
do
their
communication,
how
they
want
to
do
their
caching.
B
G
G
That's
an
interesting
data
point
as
well.
I
mean
because
the
one
thing
that
we
have
seen
is
that
people,
the
the
people
most
interested
in
open
feature
are
generally
in
my,
in
my
view,
not
hobbyists.
It
is
more
Enterprise
because
they're
looking
for
migration
paths,
they're
looking
for
no
vendor
lock-in,
that's
how
it
seems
at
least,
but
that
could
be
a
little
bit
of
sampling
bias.
On
my
end,.
G
I
H
I
Like
an
idiomatic
react
SDK
on
top
of
open
feature.
What
like,
what's?
What's
your
opinion,
totem
when
I
could,
when
I
could
kind
of
just
start,
I
guess
what
I
do
you
think
I
should
just
start
doing
that
now
and
B?
Would
it
make
more
sense
to
release
that,
just
as
a
release
that,
within
the
auspices
of
the
open
feature
umbrella
or
whether
I
should
just
release
it
as
just
like
a
little
Standalone
thing
for
now.
G
I
D
H
D
G
Yeah
I,
don't
like
it
I
think
I
I,
don't
know
if
you've
looked
at
my
most
recent
spec
PRS
but
I,
don't
think
they
do
that,
there's
the
one!
That's
a
draft
that
has
the
big
static
context
thing,
but
I
think
one
of
the
things
we
made
a
mistake
on
earlier
personally
is
that
we
didn't
segment.
The
spec
enough
and
I
tried
to
kind
of
do
that
in
I.
G
G
D
G
I
I
think
I,
don't
know,
I
mean
so
with
with
both
the
PRS
that
are
I.
Think
with
both
the
exist.
The
existing
spec
PRS,
like
the
events
and
the
initialization
one
I
I,
think
that
it's
only
adding
new
numbers
I
could
be
wrong.
I'll
have
to
go
and
double
check,
but
I
don't
think
we're
shifting
any
existing
requirements.
I
I
could
be
wrong,
but
I
don't
believe
we
are
so.
D
D
G
G
Obviously
we
can't
do
that
like
infinitely,
but
that's
kind
of
the
the
other
option
is
obviously
to
add
it
at
the
end
of
this,
even
though
there's
a
little
bit
of
a
gap
like
there'd,
be
some
somewhat
less
related
content
in
other
numbers,
you
could
append
them
towards
the
end
and
I.
Don't
really
think
that's
much
of
a
problem.
G
I
G
That's
what
I
was
kind
of
trying
to
mention
earlier
when
I
was
talking
about?
Is
it
just
if
you
share
your
screen
again,
I
I've
tried
to
topically
separate
things
recently
so
that
you
can
link
to
Concepts
more
than
numbers
so
like
see.
There's
if
you
scroll
down
I,
think
I
think.
There's
an
example.
There's
an
unnumbered
section,
I
believe:
there's
there's
some
unnumbered
sections
headings.
G
Maybe
there
isn't
in
section
one
but
I
I've
tried
to
add
them
in
a
few
places,
where
there's
more
like
a
conceptual
section
that
doesn't
actually
have
a
number
yeah
there's
a
good
example.
I've
tried
to
do
stuff
like
that
in
a
few
places
which
Maybe
helps
but
I
I
mean
I
would
be
okay
with
removing
removing
numbers
numbers
just
make.
It
seem
very
specification
and
make
it
very
easy
to
reference
an
exact,
an
exact
point
like
if
you're
saying
this
violates
such
and
such
point.
A
I
Think
through
wanting
to
like
when
it
comes
down
to
that
actual
kind
of
conversation
of
like
what
are
we
talking
about
here,
like
the
whole
point
of
a
spec,
is
to
be
an
ambiguous
and
very
clear
and
if
we
started
saying
like
this
value
is
like
that
part
of
the
spec.
Where
we
talk
about
blah
blah,
then
it's
just
way
less
useful.
But
to
that
point
like
that,
only
works
if
the
numbers
are
consistent,
because
otherwise
you
go
back
in
history
and
it's
like.
D
Yeah
see
it
like.
Html
has
IDs
like
this,
where
you
have
to
be
unique
within
the
within
the
document,
but
you
don't
have
to
be
ordered.
It's
not
a
necessary
need
for
order.
There
I
I'll
do
some
thinking
about
how
how
this
will
change
things.
I
know
it's
going
to
break
a
lot
of
the
hooks
that
we
like
a
lot
of
the
things
we
have
built
around
this
and
I'm
curious
how
the
gerk
and
stuff
if
the
gerk
and
stuff
would
be
affected
at
all.
H
G
I,
the
gherkin
framework
is
not
the
gherkin
framework
is
base
is
plain
English
that
matches
basically
section
one,
but
it's
all
high
level
enough
and
that
doesn't
directly
relate
to
to
any
of
the
spec
points
like
it
doesn't
specifically
tie
to
a
number
we
just
implemented
an.net
by
the
way
which
which
went
really
well,
but
it's
not.
No.
It's
not
attached
to
sections
I
think
the
only
the
numbers
are
mentioned
in
numerous
unit
test.
Suite
like
not
identity,
Suites,
but
unit
test,
Suites
I.