►
From YouTube: OpenFeature - Project Meeting, September 29th, 2022
Description
Notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit?usp=sharing
OpenFeature website: https://open-feature.github.io/
A
A
A
B
C
A
B
A
B
Okay,
cool
everyone
have
the
link
to
the
meeting
notes,
if
not
I'm,
gonna
post
it
in
Zoom
real
quick.
So
if
you
want
to
go
ahead
and
join,
if
you
have
anything
to
add
to
the
agenda,
feel
free
and
yeah
I
guess
first
thing
is:
if
anyone
first
time
at
the
meeting,
if
they
feel
like
introducing
themselves,
please
feel
free
to
do
so.
If
not
no
big
deal.
A
D
B
Right
and
then
like
I,
mentioned
Todd
volunteered
to
do
scribe
work
for
today
do
we
have
any
volunteers
for
for
the
next
meeting,
yeah
yeah,
okay,
Perfect
all
right!
Thank
you
very
much
cool
all
right,
I!
Guess
we
can
jump
right
into
it.
Todd.
It
looks
like
you're
first
up
on
the
agenda
and
I'll
just
take
notes,
while
you're
you're
chatting
so
yeah.
A
C
C
That
does
mean
we
couldn't
add
new
features,
but
it
means
that
there'd
be
no
breaking
changes
for
those
contracts
without
the
kind
of
approval
of
the
technical
steering
committee
and
like
really
good
reasoning,
we
want
to
do
this
because,
obviously,
every
time
we
make
a
breaking
change
to
Providers
the
provider
contract
or
the
evaluation
API
people
have
to
absorb
that
and
we
don't
want
to
have
to
keep
pushing
that
work
onto
all
of
our
consumers.
So
that's
the
goal.
Take
a
look
at
that
document.
C
C
B
A
B
C
C
F
C
So
they
were
heavily
inspired
by
a
couple
of
other
projects.
One
was
open.
Telemetry
I
also
had
a
look
at
a
couple
of
other
projects
that
have
specifications
in
them
and
they
they
have
very
similar
language,
but
it's
not
as
far
as
I
know.
There's
no
cncf
definition
around
this.
The
whole
idea
is
really
just
to
give.
You
know
our
consumers
some
kind
of
level
of
guarantees
of
stability
with
certain
parts
of
the
API.
E
Yeah
yeah
I
think
semantically,
it's
even
similar
to
what
kubernetes
is
doing.
Also
the
Voting
is
different
like
there
is
this
early
stage
where
changes
can
happen
at
any
time
and
then
that's
the
stage
where
okay
changes
require
deliberate
decision
by
a
committee,
but
they
can
still
be
breaking
and
then
there's
this
stuff
is
not
going
to
break
without
any
major
version
changes
kind
of
stage.
That's
like
what
I
think
Alpha
Beta
GA
hack
is
available
in
kubernetes.
E
The
only
comment
that
I
would
make
what
I
like
about
the
kubernetes
approach
is
that
I
make
recommendations
for
end
users
like
for
an
experimental
feature.
We
recommend
not
using
this
for
production
level
code.
It
might
not
be
that
relevant
for
code,
but
they
just
make
okay.
We
wouldn't
don't
use
this.
If
you
want
to
use
it
in
any
critical
systems,
I
think
that's
what
they
should
do
for
experimental.
C
B
Yeah
I
mean
just
to
kind
of
also
go
into
details
too.
We
we
did
look
at
open,
Telemetry
to
see
what
they
were
doing.
They
have
quite
a
bit
more
complicated
problem.
They're
trying
to
solve
so
theirs
is
a
little
bit
more
in
depth
so
that
we
did
a
modified
version
of
that.
They
also
did
not
have
anything
like
a
hardening
status,
which
I
thought
personally
was
pretty
important.
B
They
actually
went
from
experimental
to
stable
with
a
like
a
freeze
in
between
and
the
freeze
could
actually
be
like
you
could
freeze
it
and
that
could
either
be
for
because
you
know
the
maintainers
wanted
to
focus
on
other
topics
and
it
actually
bumped
back
to
experimental
later,
and
we
didn't
like
that
approach.
We
thought
like
once
it
kind
of
graduated
to
like
a
hardening
stage.
We
wouldn't
want
to
ever
move
it
back
to
experimental.
It's
not
really
fair
to
people.
So
that
was
the
inspiration
there.
C
A
E
A
E
E
C
I
think
that's
a
good
way
to
look
at
it.
I
was
only
going
to
say
Dan
if
you're
interested,
especially
in
that
the
hotel
thing
with
the
feature
freeze,
it's
I
can
send
you
the
link
I
can
maybe
maybe
Mike
can
even
pull
it
up
or
I'll.
I'll
put
it
in
the
document
later
so
yeah
I
mean
I'd,
say
their
future
freeze
is
pretty
similar
to
hardening
it's
just
not
unidirectional
like
it
can
kind
of
be
applied
to
go
both
ways.
I
I,
don't
know.
F
B
Cool
yeah
thanks
yeah.
It
was
one
of
those
things
where
it's
only
like
three
sentences,
but
it
took
Todd
and
I
like
four
hours
to
write
it,
but
any
feedback
would
be
really
appreciated
here,
because
it's
like
it's.
It
really
took
a
lot
of
effort
to
decouple
like
spec
statuses,
from
like
code,
you
know
and
I
do
think
there
is
a
clear
distinction.
B
I
think
that's
the
next
topic
Todd
wants
to
talk
about
is
like
the
sdks
versus
the
spec,
but
this
is
definitely
focused
more
on
like
the
spec,
which
I
think
we
can
be
a
little
bit.
You
know
better
about
kind
of
locking
it
in
in
some
reasonable
way,
and
another
kind
of
interesting
note
to
specifications
is
like
technically,
unless
you
have
contradictions
in
your
spec,
there
is
no
bug
in
a
spec,
and
so
that's
another
interesting
way
to
kind
of
look
at
it
and
and
yeah
something
that
that
challenged
us.
B
Yeah
any
feedback
on
that
there
is
an
issue
open
for
those
that
don't
have
the
link.
Here's
the
the
notes-
and
there
is
a
link
to
the
poll
request
there.
You
know
feedback
on
on
the
statuses-
would
be
very
much
appreciated,
so
everyone's
on
the
same
page
and
yeah
hand
it
off
to
Todd
again
for
the
SDK
portions.
C
But,
as
we've
said
before,
we
really
want
to
head
towards
a
1.0
I
personally,
really
hope
that
that's
the
last
round
of
spec
changes
before
we
kind
of
move
into
a
hardening
phase.
We
won't
know
that,
really
until
everybody's
going
to
implement
it
and
play
the
things
for
a
while,
but
I
again
have
the
date,
October
5th
I'm,
hoping
that
all
the
current
round
of
changes
to
be
absorbed
so
basically
to
get
the
sdks
up
to
zero.
C
Five
zero
of
the
spec,
as
done
by
October,
5th
I,
think
we're
well
on
our
way
to
meeting
that
goal.
I'd
like
them
to
have
all
of
the
providers
updated.
That
might
be
a
little
bit
of
a
tall
order.
I'm,
certainly
going
to
do
my
best
to
update
all
of
the
community
providers
that
are
in
my
purview,
so
Java
JavaScript
stuff
like
that.
But
there's
going
to
be
some
vendor
providers,
we'll
try
and
reach
out
to
those
maintainers.
C
The
changes
are
not
huge,
so
I,
don't
think
it'll
be
too
difficult,
but
I'd
like
to
have
those
all
done
by
the
12th
the
following
week
and
I'd
like
to
be
basically
have
candidate
release
clients
for
the
following
week
after
that
for
the
SDK,
which
may
not
have
any
changes,
but
just
so
that
we
could
say.
Okay,
all
of
our
providers
are
up
to
date.
All
of
our
providers
are
working.
This
looks
like
our
1.0
for
for
kubecon.
C
That's
where
I
would
like
to
be
in
it
from
a
timeline
perspective.
That's
just
my
proposal.
If
you
disagree,
if
you
think
that's
too
ambitious,
if
you
think
it's
not
ambitious
enough,
let
me
know,
but
we
don't
have
an
issue
or
anything
like
that.
I
can
certainly
capture
that
an
issue
if
people
feel
like
that's
a
good
idea.
B
Yeah
I
think
the
main
thing
is:
it's
super
important
that
we
we
stabilize
the
sdks
as
soon
as
possible
and
then
hit
the
1.0.
So
we
can
follow
semantic
convention,
it's
just
too
tedious
for
every
provider
and
everything
to
upgrade
every
time
we
introduce
breaking
changes.
So
we
rip
the
Band-Aid
off
basically
over
the
last
two
weeks
and
made
all
of
the
major
changes
that
we
were
aware
of,
and
so
once
you
know
all
that
stuff's
out
there
you
know.
B
Hopefully
you
know
providers
can
be
updated
and
we're
basically
in
a
good
state
for
for
a
1.0
release.
So
that
was
the
main
goal
here.
Hopefully
the
timeline
isn't
too
aggressive,
but
I
did
want
to
make
sure
that
we
had
like
Hard
dates
there,
that
we
could
shoot
for
and
we
can.
We
can
modify
it
a
little
bit
but
I'd
like
to
kind
of
lock
in
like
dates
and
targets.
So
we
can
really.
You
know,
work
towards.
You
know
having
it
ready
by
by
October
17th
time
frame,
yeah.
E
F
I
have
a
quick
question
on
too
the
timelines
look
good
to
me.
Are
we
doing
any
framing
around
the
1.0
so
like
that
it's
spec
1.0
and
complying
because
I
don't
know
of
any
one,
that's
actually
using
this
in
the
wild.
Yet
you
know
in
that
sense
of
like
stability,
1.0
I,
don't
know
if
I'm
mainly
on
you
know,
but
there's
two
kind
of
differences
where
there
can
still
be
some
unknown
bugs
we
don't
no
one's
really
exercised
in
production
workloads
that
I'm
aware
of,
but
it
is
complying
to
the
1.0
spec.
B
F
B
C
Yeah,
so
so
we
we
just
to
Circle
back
just
to
make
sure
everybody's
on
the
same
page.
On
this
one,
we
had
an
earlier
conversation
and
one
of
the
meetings
where
we
decided
consciously
to
decouple
spec
versions
from
SDK
versions
so
and
I.
Think
they're,
especially
recently,
there's
been
a
lot
of
good
reasons
why
this
is
a
good
idea.
I'll
specifically
talk
about,
go
so
go
we
realized.
Oh,
it
would
be
a
good
idea
to
include
the
context.
The
sorry
the
go
context.
C
The
context.context
is
how
you'll
see
it
in
a
lot
of
used
in
a
lot
of
apis.
We
wanted
that
to
be
available
in
the
flag.
Evaluation
calls,
that's
not
something
we
spec
out,
because
it's
completely
related
to
go
right.
So,
if
you
were
to,
you
could
have
a
totally
compliant
go
SDK
and
then
decide
to
have
a
breaking
change
where
you
introduce
context
right
and
it's
not
it's
no
less
or
more
compliant
to
the
open
feature
spec.
But
it's
a
change
in
how
that
particular
SDK
works.
C
C
So
we
want
to
have
a
spec
heading
towards
stability,
so
that
if
there
is
a
breaking
change
in
the
spec,
so
so
that
we
can
be
confident,
there's
not
going
to
be
a
breaking
change
in
the
spec
that
would
force
everybody
to
have
breaking
changes
in
all
of
their
implementing
sdks.
That's
what
we
want
to
want
to
avoid.
E
B
It
well,
the
provider
is
different,
so
in
this
case
it'd
be
the
SDK
and
right
now
we
do.
Markets
like
this
is,
like
you
know,
a
particular
version
release
of
the
spec,
and
so
that's
how
I've
been
like
whenever
we
do
a
big
spec
change,
I
would
create
an
issue
and
all
the
different
sdks
and
like
once
it's
compliant.
We
throw
the
little
spec
badge
up
on
on
the
SDK.
The
versions
themselves
are
kind
of
arbitrary
I've,
just
been
bumping
by
minor
version
numbers
every
time.
F
B
Yeah
I
mean
I
think
the
balance
is
like
the
stability
guarantee,
so
I
mean
I,
guess
version.
Maybe
itself
doesn't
matter
but
like
we
have
to
give
people
the
confidence
that
we're
not
just
gonna
like
change
a
bunch
of
stuff
like
the
next
day
and
so
I,
that's
The,
Balancing,
Act,
I
think
the
adoption
will
be
low
until
we
have
that
guarantee.
To
be
honest,
so.
C
B
A
C
I'm
not
married
to
a
1.0
as
a
label.
It's
it's!
It
is
a
it's
a
meaningful
label
because
it
does
instill
some
confidence,
but
I,
don't
I,
don't
think
we
need
to
do
a
1.0
I
think
we
need
to
have
messaging.
That
says
this
is
stable.
You
should
you
should
move
into
production
with
this
or
we're
confident,
you're
you're,
now
able
to
move
into
production
with
this
at
least:
try
try
hardening
it
in
your
QA
environments
and
stuff
like
that.
C
F
B
Yeah
I
mean
it
makes
sense,
and
that's
also
kind
of
one
of
the
challenges
that
we
ran
into
too.
When
we're
talking
about
it.
It's
like
you
know
if
we
open
it
up
to
a
bunch
of
people
and
say
like
it's
time
to
use
it
and
then
all
of
a
sudden
there's
just
some
almost
embarrassing.
You
know
level
of
thing
that
we
like
omitted,
or
you
know
forgot
to
think
about
like
it'd,
just
be
a
bummer.
B
If
we
had
no
ability
to
change
it,
so
we're
kind
of
trying
to
be
careful
with
the
language,
but
we
also
want
to
make
sure
that
it's
like
you
know
we.
We
are
fairly
confident
we're
in
a
good
spot
and
now
is
a
good
time
to
to
start.
You
know
using
it
and
providing
feedback,
and
if
there
is
something
like
that,
we
have
the
out
to
make
changes,
but
we're
we're
pretty
confident
that
we've
we've
covered
at
least
the
basics
of
feature
flagging.
B
C
I'm
almost
tempted
to
add
your
your,
like
simple
wording
to
the
document:
statuses
Alloys
so
like
we
think
this
works,
I
I,
you
put
I,
can't
remember
exactly
how
you
put
it
there,
but
it
might
be
good
to
put
like
tldrs.
We
think
this
works,
but
you
know
we're
testing
it
like
I,
I,
actually
kind
of
like
how
how
well
that
boils
it
down,
but
yeah.
Maybe
we
want
to
be
more
official
well
at
least
a.
A
E
B
C
C
Okay,
so
I'm
gonna
I,
think
my
takeaway
is
I'm,
gonna,
add
an
issue
to
talk
about
these
things
and
then
like.
We
can
talk
specifically
in
that
issue
about
whether
we
want
to
do
a
1.0
like
some
of
the
things
Dan
brought
up.
I
think
those
are
good
put
in
an
issue
so
I'm
going
to
capture
kind
of
what's
in
this
subpoint
in
a
in
a
discussion,
and
then
we
can.
A
I
have
one
question
regarding
before,
because
before
the
one
1.0
will
be
released,
I
think,
from
my
point
of
view,
the
Java
SDK
have
a
name
in
a
package
Java
SDK.
It
looks
kind
of
a
little
little
bit.
Weird
I
cannot
say
this
is
quite
often
the
package
itself.
They
add
Java
to
the
package
name
like
I
can
see
someone
use
kotlin
when
they
want
to
make
it
clear.
This
class
was
written
in
kotlin,
but
it's
not
very
common
to
use
Java
to
I
mean
even
if
compared
to
jrpc,
open
Telemetry.
C
C
Yeah
I,
I,
I
kind
of
agree
to
be
honest,
I
think
it's
not
a
bad
point,
and
this
is
if,
since
we
have
breaking
changes
already,
it's
probably
not
the
worst
time
to
do
it,
we
should
talk
to
to
Justin.
Specifically,
we
could
I
mean
I'd,
encourage
you
to
make
an
issue
in
the
Java
SDK.
If
you,
if
you
feel
that
way,
okay,
like
I,
said
I,
don't
think
it's
a
bad
idea.
We
can
at
least
have
the
discussion.
C
A
Joseph
mine's,
just
a
quick
one,
leading
on
from
what
we've
already
been
discussing.
So
we've
had
a
sort
of
wave
of
breaking
changes
coming
into
the
the
go
SDK
just
gonna.
Let
you
know
what
those
are
and
then
sort
of
give
the
pseudo
guarantee
that,
hopefully
we
won't
have
any
more
coming
in
before
before
cubecon.
A
So
the
first
one
we
mentioned
already,
the
introduction
of
context.context
is
really
common
across
many
go
packages.
So
it's
good
to
have
it
and
it's
popped
in.
As
the
first
argument,
we've
had
the
flattened
evaluation
context
so
that
decouples
the
the
the
provider
facing
API
from
the
client-facing
API
and
just
prevents
breaking
change
in
the
future.
A
If
we
add
anything
in
on
the
client
side
and
then
we've
also
got
the
the
changes
required
for
the
050
spec
release,
so
those
have
all
been
added
in
and
we
should
be
doing
a
release
either
today
or
tomorrow.
Just
depends
how
quickly
we
will
work
to
get
everything
ready
but
yeah.
Just
let
you
know
that
all
those
break
changes
coming
in.
So
it
should
be
clear
now
to
sort
of
provide
us
together
for
the
go
SDK.
B
All
right
looks
like
I
have
the
next
few
topics
and
again,
if
anyone
has
any
topics
to
add,
feel
free
to
add
it,
I'll
really
link
the
the
docs
again,
but
real
quick
I'm,
just
gonna
give
a
quick
update.
One
of
the
things
that
we
had
noticed
was
the
playground
which
was
originally
you
know
intended
for,
like
kind
of
experimentation
purposes,
but
kind
of
pivoted
more
towards
a
demo.
B
So
basically
I
spent
a
decent
number
a
decent
amount
of
time
this
this
week,
prepping
an
updated
demo,
make
it
a
lot
easier
to
run
and
then
Todd's
actually
working
in
kind
of
beautifying,
the
UI
too.
So
it
looks
less
like
a
hackathon
project
and
more,
like
you
know,
a
real
demo,
so
I'll
just
quick
quickly
show
you
what
we've
been
up
to
this
does
not
have
the
updated
UI.
B
If
you've
configured,
you
know
different
vendors,
it
will
show
up
in
a
drop
down
and
you
can
basically,
you
know
hot
select,
a
different
vendor
to
have
that
control
the
feature
flag
itself
out
of
the
box.
It
will
ship
with
flag
D
and
go
feature
flag
as
well,
and
that
all
kind
of
just
runs
in
the
respective
containers
and
so
I'll
show
you
quickly
what
it
would
look
like
if
I
were
to
start
it.
B
B
Basically
that
saves
it
behind
the
scenes,
and
hopefully
this
works,
but
of
course
it
won't
because
it's
a
live
demo.
Oh
there,
it
goes
okay,
cool,
so
yeah
there
we
go.
Basically,
this
is
just
the
regular
flag.
B,
you
know
flag
configuration
when
you
make
an
update
here.
It
saves
it
to
disk
and
then
gets
reloaded
so
like
nothing
crazy,
but
it's
kind
of
nice,
because
it's
all
self-contained
and
easy
to
run.
B
If
we
go
back
to
here
and
let's
just
change
the
color
to
red
and
save
it.
It's
all
you
know
fairly
standard
feature
flagging
stuff,
but
you
see
that
basically
without
reloading
I
can
just
change
which
provider
is
is
powering
the
demo
and
then
it
goes
back
to
like
more.
You
know
the
the
vendor.
You
know
UI
and
workflows
around
Flag,
Management
and
stuff,
and
they
can
really
start
telling
a
story
about
that.
So
I
think
it's
it's
a
pretty
cool
way
to
do
it.
B
You
can
really
see
that,
like
it
didn't
require
a
code
change
it
didn't
require.
You
know
anything
beyond
just
setting,
you
know
a
different
provider
and
it
just
works.
So
yeah
feedback
would
be
appreciated
on
this,
but
this
is
what
we're
working
on.
Hopefully
it's
available
by
the
end
of
the
week
and
we'll
have
sections
for
each.
You
know
setting
up
each
vendor
to
get
the
the
flags
configured
properly,
so
it
has
like
the
you
know
like,
for
example,
the
FIB
algo
can
have
like
rule
sets
here.
B
So
in
this
case
we're
looking
at
the
currently
logged
in
user.
If
it
ends
in
at
fast,
it
will
show,
or
it
will
run
a
different
algorithm
and
so
like
that's,
that's
one
thing
as
well
that
we'll
we'll
show
how
to
do
that.
So
in
this
case,
if
you
click
on
it
without
being
logged
in
it
takes
a
while
it's
running
a
inefficient
algorithm
and
then,
if
we
were
to
quickly
log
in.
B
And
run
it,
it
should
be
really
fast
so
that
that
should
also
work
across
all
vendors
as
well,
so
I'll
make
sure
we
add
documentation
in
there.
So
people
can
go
set
up.
You
know
the
launch
Darkly
or
the
harness
or
whatever,
and
if
there
is
any
kind
of
like
you
know,
sign
up
code
or
whatever
that
you'd
like
us
to
to
include
in
the
docs.
You
know.
Definitely
let
me
know,
and
we
can
add
it
as
part
of
like
the.
B
If
you
don't
have
an
account,
you
know,
click
this
link
or
use
this
code
or
whatever,
but
I
think
this
would
be
hopefully
a
nice
way
to
get
people
exposed
to
it
really
easily,
because
it's
just
your
run,
Docker
compose
and
then,
if
you
want
to
you,
know
test
it
out
with
a
different.
You
know
vendor
it's
really
easy
to
just
register
it
and
it
will
show
up
in
the
list.
So
any
questions
on
that.
C
B
Exactly
yep,
so
I'll
show
or
we'll
definitely
have
that
in
the
documentation,
but
basically
in
the
dot
EnV
here,
if
you
set
up
a
token,
it
will
basically
automatically
be
pulled
into
the
docker
compose
and
then
it
will
show
up
as
in
the
list.
So
that's
all
that
it
really
takes
it's
it's
not
any
more
advanced
than
that.
Obviously,
if
you
haven't
set
up
the
feature
Flags
in
those
environments,
you
won't
be
able
to
toggle
anything,
but
that
that's
all
it
takes
to
to
basically
add
a
new.
A
B
We'll
see
here
and
then
I
guess
real
quick
too.
One
thing
that
we
are
including
right
now
inside
the
the
docker
compose
file
is,
is
Jaeger,
and
so,
if
you
want
to
play
around
with
like
what
different
feature,
Flags
would
look
like.
So,
for
example,
if
I
wanted
to
filter
on
select
here,
hopefully
I
can
find
an
operation
for
the
Fibonacci
piece.
B
Here
so
this
is
kind
of
cool.
It's
a
nice
way
to
like
filter
on
requests
based
on
you
know,
open
Telemetry
data
and
see
like
kind
of
the
impact
on
response
time.
So
in
this
case
we
had
like
you
know
these
ones
were
running
the
Binet
algorithm.
So
they
were.
You
know
about
three
to
four
milliseconds.
B
This
one
is
running
recursive,
which
was
seven,
so
it's
kind
of
an
interesting
way
to
visualize
that,
even
though
the
same
request,
so
it's
a
nice
way
to
kind
of
slice
and
dice
the
data
and
something
that's
I
would
encourage
you
to
play
around
with.
If
you
have
any
interest-
and
it's
all
just
available
in
the
demo.
B
Exactly
so,
if
we
went
into
here,
you'd
see
FIB
elgo
here,
you'd
see
that
this
is
recursive.
This
came
from
harness,
and
so
basically
that
would
happen
automatically.
If
the
provider
has
the
name
set
properly
you'd
see
like
which,
which
vendor
you
know
basically
was
responsible
for
the
flag
evaluation.
B
Well,
all
right,
let
me
see
I
think
I
had
a
couple
other
notes
here
as
well
yeah.
So
if
you're
interested
definitely
follow
that
at
branch-
and
let
us
know
if
there's
you
know
anything
that
you'd
like
to
add
or
see
we're
going
to
try
to
get
it
out
there
and
then,
as
soon
as
it
is
available,
I
mean
it's.
A
good
opportunity
to
you
know,
provide
feedback
and
prove
you
know
the
documentation,
whatever
whatever
you
know,
is
appropriate.
Once
you
have
a
chance
to
play
with.
B
It
would
be
helpful
all
right,
so
completely
changing
topics
now
and
going
to
kubecon.
If
you
are
going
to
be
at
kubecon,
we
I
have
a
quick
sign
up
form.
I
would
encourage
you
to.
Basically
let
us
know
that
you're
going
to
be
there,
so
I
can
go
ahead
and
you
know
try
to
schedule
some
some
Gatherings
while
we're
there.
The
dining
space
office
is
actually
in
Detroit
or
we
have
one
in
Detroit.
So
we
we
could
either
go
to
the
dynastrace
office.
B
B
B
B
You
know
to
our
hearts
content
and
then
we
just
have
a
single
place
where
you
can
see,
like
you
know
our
blogs
and
our
docs
and
all
of
that
type
of
stuff.
So
not
sure
if
there's
any
thoughts
on
that,
but
I
thought
it
was
Justin
had
brought
it
up
in
an
issue
a
couple
days
ago
and
I
thought
it
was
a
pretty
good
idea
and
certainly
worth
considering.
F
B
Yeah
I
mean
right
now.
The
the
existing
page
is
is
kind
of
ugly
and
definitely
doesn't
have
a
ton
of
content.
So
it's
one
of
those
things
where
it'd
be
kind
of
nice
to
to
just
move
off
of
it.
If,
unless
we're
going
to
invest
time
and
energy
into
making
it
like
a
nice,
you
know
marketing
landing
page
so
which
I
don't
think
we
will
honestly
at
least
not
at
this
stage.
Well,
we.
E
B
Yeah,
basically
I
mean
we
still
have
full
control
of
like
the
main
landing
page,
and
we
can
make
it
look
pretty
you
know
nice
still,
but
it's
just
like
you
know.
Do
we
want
to
have
two
completely
separate
repos,
that
kind
of
just
dump
you
off
into
the
the
docs,
which
is
the
case
right
now,
so
I,
don't
think
it
prevents
us
from
doing
what
you're
talking
about
it
just
kind
of
makes
it
more
clear
where
you
would
add
that
content
yeah.
E
B
Could
be
I
mean
docusource
supports
just
like
react
and
stuff
so
be
pretty
easy
to
just
throw
on
custom
react
pieces,
but
yeah.
We
can
certainly
talk
about
it
like
I'm,
not
not
totally
convinced
but
I
do
think
it's
a
pretty
good
idea
and
we
should
probably
do
something
before
keep
con
and
make
sure
like
the
kind
of
the
happy
pass
and
the
value
props
are
clear
to
everyone
when
they
they
first
go
to
the
page
by
the
way
Dan.
If
you
are
gonna,
go
to
kubecon
and
you
haven't
purchased
your
ticket.
F
B
A
E
Yeah
I
mean
this
was
just
based
on
the
issue
that
I
handed
in
that
on
my
request,
joining
the
governance
board.
So
the
main
reason
is
this
is
yeah
or
to
clarify
this
is
still
the
bootstrapping
governance
board.
Main
reason
is
that,
obviously
we
had
an
initially
governance
board,
but
this
was
not
like
widely
active
so
far,
and
obviously
this
is
now
going
to
be.
The
goal
is
really
to
drive
it
towards
activity.
You
can
read
in
the
issue
what
the
goals
actually
are.
E
It's
really
like
it's
setting
up
governance
meetings,
which
are
right
now
not
happening
helping
with
the
enhancement
process
process
which
we
have
already
but
like
making
it
more
formal
and
in
more
than
more
people,
also
work
on
some
of
the
charter
work.
Some
of
these
documents
are
very
early
work
in
progress,
also
to
help
us
on
what's
included
and
what's
not
included.
E
E
E
I
mean
I
got
all
the
votes
from
the
governance
board.
There
is
no
official
vote
right
now,
because
it's
the
unselected
seats
but
I
was
reaching
out
to
them
and
that's
actually
my
goal.
So
just
you
know
what
this
is
about
and
again
with
I
think
we
initially
stated
like
half
a
year
in
which
would
put
this
into
next
year.
C
A
B
Like
I
have
one
more
and
I
think
David,
maybe
added
in
this
last
one
so
I'll
I,
think
I
know
what
he's
meaning
by
it,
but
I'll
yeah
I,
don't
know
for
sure.
So,
at
any
rate,
the
next
topic
was
hacktoberfest,
so
we
had
Todd
and
I
thought
at
first,
at
least
that
it
was.
It
was
a
good
idea,
something
we
may
want
to
take
advantage
of.
We
came
up
with
kind
of
a
high
level
proposal
of
what
it
could
potentially
look
like.
B
You
know
issue
templates
and
then
a
process
for
like
when
an
issue
is
created
like
if
it's
approved
you
know
assigning
it
to
the
appropriate
people
and
and
having
that
process
be
be
pretty
easy
to
follow.
So
so
people
know
how
to
add
those
pieces
and
I
think
that's
going
to
be
an
important
part
of
of
the
project.
So
I
do
think
like
that.
B
That
makes
sense
to
me
is
just
whether
or
not
we
want
to
add
the
hacktoberfest
label
and
and
honestly,
like
I
kind
of
want
to
try
it,
but
I
do
understand
that
it
could
become
a
a
pain.
But
maybe
at
that
point
we
just
stop
adding
adding
the
labels
so
I
guess
my
proposal
is
like
we
could
do
it
either
in
all
contribs
or
maybe
just
the
JS
contrib,
and
you
know,
because
that's
something
that
Todd
and
I
can
definitely
handle
if
it
becomes
overwhelming.
B
We
basically
just
rip
out
the
Oktoberfest
pieces
and
just
say,
like
you,
know,
we're
not
participating
this
year.
Essentially,
so
any
any
thoughts
on
that
you
know
Pro
or
against
Oktoberfest,
so
I've
only
participated
from
like
a
developer,
not
from
a
maintainer.
So
I
don't
really
know
what
the
the
what
it's
going
to
be
like.
F
F
B
I
yeah
I,
don't
know,
I
mean
it's
probably
similar
to
like
the
good
first
issue,
type
stuff
where
actually
like,
there's
Bots
and
a
bunch
of
things
that
pick
it
up
and
so
like,
and
the
quality
I
think
we
could
really
be
across
the
board.
I
mean
you
could
get
some,
probably
a
really
amazing
pull
requests
and
some
that
are
like
I'm
here
for
a
t-shirt,
so
I
think.
D
Yeah,
so
usually
you
get
a
few
active
contributors
who
submit
something
big
and
it's
still
a
good
way
to
raise
awareness
about
the
project,
because
many
experienced
open
source
contributors
just
look
at
dashboards,
so
they
see
some
highlights
based
on
technology,
Etc,
so
hyping
everything.
Then
please
leads
to
some
organic
traffic,
even
if
you
don't
actively
promote
at
the
same
time,
if
you
expect
to
have
dozens
of
experienced
developers
and
companies
during
cryptographers,
it's
not
going
to
happen.
D
Well,
sometimes
you
can
get
someone
and
routine
over
there
course
of
months
and
years
in
the
community,
but
yeah
I
would
definitely
advise
against
creating
a
bunch
of
new
common
friendly
issues
like
complete
documentation
here
and
there,
because
the
maintenance
overhead
is
coromandos
and
the
outcome
isn't
big,
so
maybe
actually
the
advising
color
wise
try
doing
some
Integrations
Etc.
There
are
plenty
of
projects
that
would
benefit
from
integrating
feature
Flags.
So
who
knows.
E
I
think
I
have
a
very
different
opinion
from
Google
some
of
code,
but
people
are
trying
just
I
mean
they're,
just
just
getting
a
T-shirt
and
that's
pretty
much
the
effort
they
put
into
it.
The
effort
that
you
would
put
into
forgetting
a
t-shirt
so
I
think
the
currently.
This
project
was
very
purpose
last
year
about
hacktoberfest
I,
think
it
wasn't
friendly
at
all,
because
it
was
more
or
less
spamming,
most
of
the
work
that
they
were
doing
there.
E
B
We
will
tag
you
but
yeah.
Well,
you
can't
attack
me,
but
now
that
you
mentioned
it,
yeah
you're
gonna
be
Auto
included
on
all
the
PRS,
but
no
I
mean
I,
think
point
taken,
but
I
I
think.
That's
also
why
we
try
to
have
the
the
guidelines
too
or
it's
like
you'd
only
get
the
label
if
you've
followed
the
process,
and
then
it's
very
like
isolated.
Like
you
know,
contributing
to
kubernetes
is
a
significantly
higher
barrier
than
writing.
B
But
you
know
some
of
the
core
people
that
helped
really
get
it
to
the
state.
It
is
now
like
getting
something
for
those
people
and
so
figuring
out,
especially
like
if
there's
any
like
you
know,
vendors
or
companies
that
want
to
help
basically,
like
you
know,
pool
pull
some
resources
to
to
help
kind
of
make
this
a
reality.
I
think
that
would
be
kind
of
what
we're
looking
at
now,
not
sure.
If
anyone
on
the
call
was
in
a
place
that
they
could,
you
know
escalate
to
some.
B
You
know
marketing
team
or,
if
there's
any
kind
of
like
budget
available
for
this
type
of
stuff,
but
if
there
is
any
interest,
we're
trying
to
kind
of
work
through
that
and
see
what
we
could
do,
you
know
for
some
kind
of
like
maintainer
gift
or
something
of
some
sort
just
to
keep
people.
You
know
interested
and
kind
of
you
know
thank
them
for
the
the
hard
work
over
the
last.
You
know,
seven
months
or
so.
So
that's
an
idea.
B
It's
still
kind
of
a
work
in
progress,
but
if
it's
something
that
you're
interested
in
you
know
try
to
contact
me
and
we
can
try
to
work
through
the
details.
We
have
to
move
quickly,
though
the
order
has
to
be
in
like
in
the
next
couple
weeks
and
or
or
sooner
for
it
to
be
a
reality.
So
yeah
I
I,
think
that
was.
That
was
not
my
issue,
but
I
think
that's
what
David
was
meaning
by
this
and
he's
on
vacation.