►
From YouTube: Steering Committee 20180620
Description
Chat log (times may be off):
00:07:15 Clayton Coleman: i think we do
00:25:04 Sarah Novotny: I have to drop in a few minutes.
00:31:43 Sarah Novotny: apologies, I have to drop. See you in a month :)
A
All
right,
so
this
is
June
20th
2018.
This
is
the
steering
committee
meeting,
we're
still
not
quite
sure
if
we
have
quorum
yet,
but
we
figured
we'd
start
the
recording
and,
as
we
chatter
in
case
anything
gets
decided
with
Clayton
here
I
think
we
may,
we
may
actually
have
forum.
So
let's
see
the
the
agenda
does
somebody
want
to
sign
up
to
be
posing
for
this
meeting
I?
B
We
originally
had
a
sprint
planning
where
we
had
Sprint's
with
the
backlog
and
I
know
that
chase
was
supposed
to
curate
our
black
clog
for
us,
but
I.
Don't
know
where
that
left
off
and
I
don't
know
if
we
can
sign
up
for
Sprint's
or
if
we
should
have
a
forcing
function
for
us
to
for
us
to
get
together
and
knock
out
pieces
of
the
backlog.
I
know
we
talked
about
it
during
our
brief
to
get
together
at
coupon
in
Austin,
I
think
it
was,
and
we've
never
actually
decided
to
do
that.
I.
C
A
Mean
one
of
the
things
we
can
do
is
we
can
take
this
time
we
got
in.
You
know
most
of
an
hour
left
here.
We
can
make
this
a
little
bit
of
a
working
session
like
on
that
whole
thing
of
getting
the
office
hours
up
and
running
like
I
can
schedule
the
meeting
like
you
can
write
the
two
paragraphs
Sara.
We
can
actually
it'll
probably
take
us
20
minutes
to
get
that
done,
but
at
least
we'll
be
done.
Yeah.
C
B
So
it's
part
of
the
backlog
that
we
discussed,
that
we
were
gonna
do,
which
relates
to
that
original
topic
was
that
we
said
we
were
going
to
review
some
of
the
charters
and
find
commonality.
Yeah
update
the
original
proposal
that
Phil
had
written
quite
I,
don't
know
where
that
stands.
Have
people
actually
had
the
time
to
review
some
of
the
charters
and
defines
the
comment
sections
that
we
want
to
put
into
the
template.
B
G
B
B
B
Alright,
that
seems
like
a
plan
and
then
by
next
week
we
can
make
a
PR
and
then
we
can
start
to.
Maybe
we
can
start
to
divvy
up
the
backlog
of
outstanding
charters,
because
I
don't
think
it's
fair
to
those
who
have
put
the
effort
in
for
us
to
keep
on
talking
about
this
and
not
try
to
make
do
our
level
best
to
to
get
that
done.
Right,
yeah.
B
To
help
define
a
policy
for
like,
or
at
least
help
to
define
the
structure
for
the
docs
looks
to
define
a
policy
for
what
it
means
to
be
in
Trinity
stocks
right,
the
maintenance
lifecycle
of
those
things
because
they're
very
confused
by
some
of
it,
and
some
of
it
are
broader
beyond
the
scope
of
what
the
docs
folks
understand
like.
Should
we
be
documenting
alpha
features
in
the
main
documentation
website?
If
so,
what
are
the
clauses
we
should
be
specifying
inside
of
the
Alpha
features
right?
B
B
A
So
I
don't
think
it's
unreasonable
to
say
hey
if
we
can't
find
an
owner
for
some
docs,
we
just
like
move
them
to
an
attic
or
we
leave
them
in
github
in
someplace
that
doesn't
get
published
on
the
site
or
something
like
that.
You
know
they.
There
should
be
some
due
diligence
around
it,
but
it
doesn't
seem
crazy
to
try
and
say
hey
by
default.
If
there's
no
owner
get
rid
of
it
Sara.
So.
C
C
D
I
mean
if
I'm
own
head
I
agree
with
Sarah.
If,
if
they,
if
sigdoc
skills,
this
is
a
problem,
bring
us
a
proposal,
we
will
say
we
agree
with
it.
We
grant
you
the
authority
to
delete
locks
if
you
feel
it
they're
stale,
but
that's
a
really
bad
outcome.
How
do
we
incentivize
and
enforce
that
people
keep
Doc's
up
to
date?
Well,.
A
Mean
one
thing
we
could
do
is
we
could
say:
hey
Doc's
folks,
it's
okay
to
actually
point
people
at
the
appropriate
slack
channel,
and
then
you
know
pr's
accepted
slash,
bug
those
folks
so
that
they
stop
getting
bucked
right,
I
mean
I,
don't
know
if
that's
a
good
idea
or
not
so
there's
two
problems,
one
of
them.
It's
like
how
do
we
actually
encourage
people
to
write
an
update
Docs
for
the
right
things
and
then
how
do
we?
You
know
who
has
permission
to
kick
out
Doc's
that
are
on
maintained
or
they
can't
find
owners.
A
F
Isn't
just
about
Doc's
I?
Think
right,
like
this
is
a
general
like
you're
not
doing
like
what
you
need
to
do
to
release
the
feature
right
and
it
could
have
like
tests
have
the
same
thing
where
if
you
don't
write
tests
good
enough
or
or
like
not
filing
future
requests
or
having
whatever
you
need
to
do
for
the
release.
It's.
A
Here's
the
thing
is
that
if,
if
the
feature
is
not
documented,
it
won't
be
used
well,
it'll,
probably
rot
it'll,
be
you
know.
We
could
also
say
that
something's
not
like
what
are
the
sticks,
that
we
have
I
guess
so
one
of
the
sticks
that
we
have
is
conformance
another
stick
that
we
have
is.
Is
you
know
that
people
actually
use
your
thing,
and
you
know
Doc's
can
be
one
way
to
do
that.
A
B
What
does
a
sig,
chair
or
technical
lead
mean
if
they're
not
maintaining
some
of
the
specs
of
these
things
to
write
like
part
of
the
lifecycle
management?
Responsibility
should
be
in
in
their
Charter.
So
as
we
start
to
talk
about
charters
and
as
we
start
to
talk
about
you
know,
what
does
it
need
to
add
a
feature
and
be
a
chair
of
a
sig,
you
should
be
managing
the
lifecycle
of
the
features
that
you're
responsible
for
for
that
snake
is.
B
Think
unaware
of
the
state
right
now
I,
don't
think.
There's
a
feedback
loop
between
Docs
and
maybe
some
of
the
sig
leads
I.
Think
we
took
a
proactive
measure
to
say
like
we're,
going
to
trainwreck
all
the
docs
for
sequester
lifecycle
and
actually
try
to
manage
all
them,
and
what
we
found
was
a
state
of
affairs
that
we
didn't
expect.
D
B
A
Putting
people
in
the
way
I
mean
one
of
the
lovers
that
we
have,
and
this
is
going
to
be
something
through
through
save
architecture,
is
the
API
review
process
and
and
this
idea
of
and
and
the
the
in
the
future
gate
process.
So
we
could
say
that
Docs
folks
have
to
be
in
the
loop
if
you're
going
to
turn
a
feature
on
by
default,
they
have
to
be
in
the
loop
if
you're
going
to
promote
in
API
to
beta
and
and
like
you
just
can't
do
it.
If
you
don't
have
the
docs
in
place,
yeah.
D
What
I
mean
is
nominate
some
process
through
cig
docks
or
remember
whether
that's
individual
people
or
some
group
thing
or
whatever
that
says
your
PR
is
not
going
to
get
merged.
So
you're
you
have
a
corresponding
docks
PR
in
the
pipeline
and
we
don't
require
that
today
and
therefore
it
doesn't
get
done
or
maybe
like
maybe
the
right
point.
F
B
Think
that's
a
little
bit
backwards
because
oftentimes,
you
create
a
proposal
in
which
you
actually
write
in
code
adrift
and
I.
Think
maybe
before
I,
like
Tim's
idea
of
blocking
the
actual
feature,
promotion
or
the
actual
larger
PR
merge
until
docks
are
in
place,
seems
reasonable.
That
I
don't
know
how
you
enforce.
That
is.
B
D
B
D
D
A
F
F
So
there's
like
I
guess:
I
just
mean
like
there's
there's
a
quality
bar
aspect
here
which,
like
the
docs
may
be
the
sig
docs,
is
responsible
for
reviewing
there's
a
notion
of
like
tutorials
versus
conceptual
documentation
versus
task
documentation
right
like
I
guess
the
sig
Docs
would
actually
need
to
come
up
with
some
sort
of
metric
about
whether
deciding
something
sufficiently
documenting,
yeah
I.
Think
actually.
D
B
D
F
That's
still
not
gonna
force
people
to
update
things
yeah
and
we
need.
We
need
a
signal
first
I
think
which
we
don't
have
like
and
then
I
think
we
need,
like
it.
I
guess.
The
question
I
have
is
like
if,
if
the
SIG's
had
a
dashboard,
for
instance-
and
there
was
like
a
little
like
green,
yellow
red
dot
next
to
every
doc
they
owned
like
within,
would
they
naturally
just
fix
the
docs
on
their
own?
Well,.
B
I
think
part
of
the
release
process
could
be
to
you
know
if
we
had
automation
or
some
way,
shape
or
form
to
be
part
of
the
lifecycle
for
release
is
to
make
sure
that
all
of
the
owner,
things
that
are
checked
off
in
the
charter
for
a
given
cig,
actually
have
been
updated
appropriately
and
part
of
the
release.
Managers.
Job
would
be
to
to
wrangle
that
sig,
chair,
okay,
so
I
I
think
you.
A
A
We
have
a
mix
there
right
because,
like
SIG's,
diamo
actually
specifies
who
owns
what
code
based
on
a
sig
basis,
but
the
owners
file
generally
right
now
only
specifies
people
and
I
think
it's
even
worse
in
Docs,
because
the
doc
stuff,
like
you,
can
look
at
the
history
of
who's
modified
this
doc
and
try
and
to
it
which
sig
that
belongs
to.
But
there
is
no
way
to
say
which
you
know
which
sig
owns,
which
doc
across
the
entire
docs
repo,
so
maybe
that's
at
least
a
place
to
start
I.
F
B
There'd
be
well-defined,
responsible
parties
where
the
docks
folks
can
like
go
poke
to
understand
like
can
we
get
rid
of
this
as
part
of
the
release
process
and
part
of
like
any
release
would
be
like
a
chair.
You
need
to
make
sure
that
you
update
the
docks
or
do
these
things
still
apply
yes
or
no
I.
D
B
F
A
I'm
worried
that
dude
on
release
is
too
late,
because
that
hits
the
thing
that
Phil's
talking
about,
which
is
people
check
in
a
bunch
of
code
and
then
all
of
a
sudden
we're
waiting
from
the
right
docs
and
then
those
have-have
held
up
the
entire
the
entire
cycle
right,
so
we're
sweet.
Let
go
of
the
only
stick
that
we
have,
which
is
saying
no
in.
A
A
Right
there's
risk
in
terms
of
like
untangling
and
ripping
code
out,
so
it's
so.
It
seems
to
me
that
the
API
review
slash
feature
promotion
like
like
we
need
to.
We
need
to
take
seriously
about
having
a
checklist
when
things
move
to
beta
when
we
add
new
things
like
flags,
and
we
have
to
have
a
chokehold
on
that
where
that
stuff,
like
you
know
it
can't
just
be
a
sig
yoloing
stuff
in
we've,
got
a.
We
got
to
get
some
set
of
process
around
that
at
this
point.
F
E
We
nominate
membership
within
the
sig
to
at
least
say
is
those
servers
like
responsible
stewards
to
act
that
the
docs
were
written?
So
we
don't
overburden
sig
Docs,
like
I,
assume,
there's
far
more
people
outside
of
Doc's,
and
that
means
like
we
just
find
a
sub
role
or
some
kind.
That
says
this
person
can
a
okay
that
yeah
I
agree.
The
doc
here
is
sufficient.
B
D
Fear
is
that
people
are
lazy
and
that
we
already
have
the
option
like
any
PR
that
comes
through
any
reviewer
could
say:
hey
man.
This
needs
some
dots,
but
because
it's
not
there
in
your
face,
it
tends
to
get
forgotten
and
I'm
as
guilty
of
it,
as
anybody
probably
more
and
in
that
I
reviewed
too
many
PRS
too
quickly.
I
I
think.
D
The
only
way
that
we
have
this
succeed
is
if
it's
a
required
component
now,
maybe
it's
not
every
PR,
maybe
it's
PRS
that
touch
feature
gates
and
PRS
that
touch
Flags,
slash,
configs
and
PR
is
the
touch
api's
and
that's
it,
and
hopefully
that's
not
the
preponderance
of
PRS,
but
I.
Don't
really
know
I.
E
Think
that's
fine,
or
even
if
it's
just
a
conscious
action
to
say,
Doc's
not
required,
but
by
default
Doc's
were
required
and
then
hopefully
Tim.
That
would
be
enough
of
a
conscious
reminder
on
your
part
and
we
would
trust
reviewers
to
do
the
right
thing
first,
rather
than
be
as
disruptive
as
requiring.
How
happy
are
we
with
release
notes.
B
According
to
the
docs
people,
there's
there
because
I've
been
sitting
on
cigarettes
and
some
ducks
to
try
and
gets
pieces
of
this
done.
The
cycle
is
here,
and
one
of
the
one
of
the
issues
is
that
there's
a
bunch
of
the
people
who
are
managing
the
release,
notes
have
reached
out
to
a
bunch
of
people
and
they
have
not
responded.
I.
B
You
could
also
have
like
a
I,
don't
know
about
doc
cell
GTM,
but,
like
the
release,
note
required
flag
or
label
is
pretty
sufficient
for
people
to
stop
and
make
sure
that
and
notes
the
reviewer
that
like
no,
we
should
really
have
a
release
engineer,
so
you
could
do
something
very
similar
with
like
a
separate
doc
section.
That
list
says.
A
So
the
difference
here
in
my
mind
is
that
release
note
require.
It
is
like
oh
great
I'll
fix
that
it'll.
Take
me
two
minutes
right.
Writing.
Docs
is
like
oh
I'll
get
to
that
next
week.
Let's
get
this
in
and
then
you
know
people
will
people
will
promise
it
and
then
it
won't
happen
and
then
the
release
yeah.
D
A
Because
I
think,
like
the
stick
we
have
is
like,
we
need
to
get
to
the
point
where
we
have
that
API
review
process.
We
have
a
checklist
and
I
think
adding
Docs
to
that
makes
a
ton
of
sense,
but
not
every
change
that
we're
talking
about
is
going
to
go
through
the
API.
We're
not
going
to
get
everything
right.
We're
not
gonna
get
everything,
but
I.
Think
things
will
improve
dramatically
if,
if
any
major
new
features
require
some
sort
of
Docs
I.
D
Mean
I'm
actually
sort
of
from
this
conversation,
I
sort
of
like
the
idea
of
leading
out
it.
The
way
we
do
at
least
I
was.
If
it
came
up
and
said
you
need
to
put
a
release
notes.
Sorry,
you
need
to
put
a
Doc's
section
in
your
PR
comment
and
you
have
to
say
Doc's
not
applicable,
or
you
have
to
say,
Doc's,
here's
a
PR
link
and
the
Bob.
Let
you
merge
until
that's
been
acknowledged.
D
F
There's
there's
two
there's
two
things:
people
need
right
like
guidance
and
motivation
right
and
if
we're
just
talking
about
like
like
the
stick
like
the
beatings,
will
continue
until
more
Alec
improves
sort
of
like
it's
not
gonna
help,
unless
we
also
have
the
guidance
there
and
if
we
just
give
guidance,
maybe
like
we
at
least
move
like
Derek
or
or
Tim,
was
saying
we
move
the
pendulum.
Oh
I,.
B
A
I
mean
like
it's
better
than
nothing,
but
I
really
suspect
that
it
ends
with
you
know
it's
just
like
security
warning
fatigue,
I
think
it'll
be
like
Doc's
won't,
you
know,
fatigue
and
people
will
just
be
like.
Oh
it's.
This
thing
that
I
have
to
do
to
make
this
thing
go
away,
so
I
can
check
in,
like
I
agree
that
we
need
to
have
a
cultural
change
here.
I'm
just
afraid
that
this
isn't
enough
to
actually
sort
of
ignite
that
I.
D
Mean
the
other
alternative
is
we
push
it
on
to
reviewers
and
instead
of
just
saying
lgt
em,
you
have
to
say
code,
LG,
TM,
Doc's,
LG,
TM
or
l,
know
l
g
TM
and
you
know
I
don't
know
about
you
guys,
but
I
have
can
github
replies.
I
have
to
think
about
which
one
I'm
gonna
use
and
this
forces
me
to
think
even
harder
about
which
one
I'm
gonna
use
and
before
I
say,
release
note,
L,
GTM,
I'm,
gonna,
stop
and
think.
Did
I
really
did
I
read
the
release.
D
D
D
A
So
it
may
make
sense
for
us
to
say
that,
like
for
any
PR,
you
know
on
a
you
know,
per
repo
basis,
there's
a
set
of
LG
teams
that
need
to
be
specified
and
and
all
of
those
have
to
be
met
for
the
thing
to
go
on,
because
then
you
know,
but
then
are
we
gonna
end
up
with
like
8
LG
TMS
that
you
have
to
do?
Maybe.
D
D
A
Okay,
so
one
one
sink
that'll
be
impacted
by
this
quite
heavily
I
believe
is,
is
API
machinery,
because
there's
a
lot
of
work,
that's
going
on
in
terms
of
refactoring
and
everything
that
around
that,
especially
as
like,
if
we
say
hey,
these
docs
include
docks
are
on
client
go
I'm,
not
sure
this
is
a
bad
thing,
but
I'm
just
like
this
will
hit
some
cigs
more
than
others.
I.
D
Mean
it'll
hit
any
sig
who's
doing
a
high
volume
of
PRS.
They
happen
to
be
they
doing
a
bunch
of
really
energetic
work
right
now
and
I
suspect
that
99%
of
their
work
doesn't
require
Doc's
changes
or
release
notes,
but
some
of
it
will
and
forcing
him
to
stop
and
think
about.
It
might
not
be
so
bad
in,
like
the
client
go
stuff
like.
F
A
Yeah,
maybe
that's
good
enough.
Well,
I
mean
part
of
that
part
of
the
problem
with
client
go.
Is
that
there's
big
like
they
don't
have
an
upgrade
guide
for
like
how
do
you
move?
One
version
client
go
to
another,
so
it's
like
you
up.
You
update
you're,
like
I,
don't
know
a
bunch
of
stuff
broke
and
I
have
to
like
go
spelunking
to
figure
changed.
D
A
B
A
We
can
work
with
them
around
that
I
think
it's
I
mean
this
is
at
least
the
conversation
that
we
had
here
is
a
little
bit
of
a
primer
of
some
of
the
options
that
we're
thinking
about
here
there
may
be
stuff
we're
not
considering.
There
may
be
stupid,
simple
things
that
that
can
happen
sooner,
that
we're
not
saying
yeah.
D
A
D
Yeah
I
think
we
need
to
do
both
I.
Think
I,
don't
want
to
impose
anything
on
sake,
Docs,
because
I
know
that
staffing
up
sig
Docs
is
not
gonna,
be
the
easiest
thing
in
the
world,
but
I
want
them
to
feel
empowered
and
to
own
the
documentation
and
if
they
feel
like
we're
doing
a
poor
job
of
keeping
documentation
up
to
date-
and
it
sounds
like
we
are
I
mean
I
know
we
are,
but
it
sounds
like.
They
also
feel
that
way.
Then
I
want
them
to
step
up
and
demand
more
from
us.
Well.
A
I
think
I
think
it's
more
than
just
keeping
the
docs
up
to
date.
I
think.
The
fact
is
that
we
have
a
lot
of
Doc's.
Some
of
them
are
out
of
date.
Some
of
them
aren't
they.
You
know
they're,
not
necessarily
the
right
Doc's,
that
we
need
for
certain
scenarios,
and
so
I
mean.
Is
that
your
impression
Tim,
as
you
went
through
this
exercise
through
the
cluster
lifecycle?
Yes,.
A
Contributors
to
our
project
fall
into
categories,
where
there's
individuals
looking
to
get
stuff
done
and
then
there's
companies.
When
companies
are
looking
to
get
stuff
done,
they
actually
can
bring
other
resources
to
bear.
Do
we
want
us?
You
know
I,
think
there's
this
natural
thing
that
if
like
hey,
you
know
if
we're
trying
to
make
doc
changes
and
we
have
Jennifer
who's,
been
involved
a
lot
saying:
sick
Doc's.
You
know
you
know.
Naturally
you
know
she'll
gravitate
to
helping
out
review
Docs
for
things
that
you
know
hep
Tio's
been
working
on.
A
D
A
I
part
of
it
is
that
like
look,
if,
if
we
actually
get
more
docs
going
in,
we
get
more
Doc's
changed
in
reviewed
because
actually
like
this
is
wildly
successful.
All
of
a
sudden.
Is
there
a
problem
where
the
docs
team
is
then
the
cig
Doc's
folks
are
overloaded.
Oh
I
expect
so
already
overloaded,
but
like
do
we
make
that
problem
worse?
What
are
the
lovers
that
we
have,
and
this
is
a
different
topic
to
incentivize?
D
It
be
a
wonderful
problem:
I
mean
that
we
had
so
many
new
Docs
and
changes
tic
TOCs
coming
through
that
the
cig
Knox
team
said.
Oh,
my
god,
we
can't
deal
with
it
like
I,
would
love
to
make
that
problem
and
then
find
a
way
to
go
and
beat
the
deep-pocketed
companies
and
don't
any
more
tech,
people,
tech,
bums
people.
A
B
E
B
Okay,
I
think
I
think
with
the
formation
of
the
sig
cloud
provider.
That's
a
very
specific,
focused
area
where
there's
there's
a
tremendous
amount
of
rot
and
I'm
working
with
I'm
working
with
the
newly
formed
sig
leads
to
try
and
address
these
issues,
because
it's
clear
that
there
was
no
owner.
So
it
was
kind
of
like
ad-hoc,
volunteer
people
publishing
pieces
of
it.
But
there
is
no
concise
documentation
for
best
practices
and
I'm,
currently
working
with
those
folks
to
try
and
at
least
get
it
in
a
healthy
place
for
112.