►
From YouTube: Kubernetes SIG Architecture 20190314
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Yeah
I
know
a
bunch
of
people
are
at
the
open
source,
Leadership
Summit
I
was
there.
We
have
to
do
some
art,
mr.
bule
and
stuff
after
this,
but
we
have
windows,
GA,
conformance,
sub-project
onboarding.
We
have
the
right
folks
here
and
make
notes
and
Paris
is
going
to
be
talking
about
mentoring
and
successful
planning
from
contributed
estate
career
experience.
B
B
We
have
Aaron
did
some
work
on
the
project
for
consolidating
the
product
Ward's,
so
Thank,
You,
Aaron
I
have
a
few
volunteers
to
to
help
that
we
need
to
spend
some
at
for
onboarding.
So
I
just
wanted
to
ask
whether
they
thought
we
should
have
a
short
weekly
meeting
in
order
to
get
that
started
since
the
current
working
group
meetings
are
monthly
and
we
can
go
through
some
of
the
outstanding
issues
and
review
them
together
and
talk
about
how
we
manage
the
the
product
board
and
things
like
that.
B
C
I
absolutely
think,
that's
a
great
idea
so
to
to
me
it's
it's
sort
of
like
the
the
initial
part
of
this
effort.
There
was
a
lot
of
discussion
of
like
ease
components
like
an
architecture
thing,
or
is
it
this
CN
CF
conform?
It's
working
great
thing,
I.
Think,
like
the
actual
doing
the
work
is
sick
architecture.
It's
sub-project.
Some
projects
can
have
meetings.
This
is
already
supported
and
sexy
animal
now.
So
if
somebody
wants
to
put
that
meeting
together
and
run
it,
we
have
all
the
infrastructure
in
place
to
support
that
I.
C
B
B
E
D
A
B
B
E
E
Okay,
nice
to
me:
yes,
yes,
okay,
Liam,
the
personick
update
to
zoom.
So
it's
not
behaving
very
well.
Alright!
That
Diane
I
was
there
earlier
to
I,
just
couldn't
a
newt,
so
so
on
the
windows
front,
so
we
were
taught
to
get
pretty
much
all
of
the
three
main
requirements
that
you
wanted
for
GA,
but
you
are
validating
on
the
cap,
all
of
the
what's
working:
what's
not
working
and
what
may
work
in
the
future
post
GA
we
updated
all
of
those.
The
cap
is
up
to
date
and
and
Merson.
E
As
you
know,
for
late
last
week
we
were
able
to
finalize
all
the
PRS
that
we
had
in
our
in
our
table.
We
would
pretty
much
closed,
all
of
them
before
code
freeze
and
we
merged
the
last
one
on
Tuesday
and
the
last
part
of
it
was
getting
all
our
runs
on
test
Crete
for
GCP,
as
well
as
assured
to
be
cream,
and
we
also
pretty
much
got
vSphere
clean
as
well
for
the
most
part,
so
the
three
main
requirements
that
we
have
for
Jay
were
those
three
and
kind
of
validated
them.
E
B
E
So
so
from
that
aspect
that
one
you're
a
hundred
percent
right,
we
don't
expect
anybody
to
go
and
read
the
cap,
so
we
did
two
things
that
we
added
a
contributors
guide
for
Windows
that
was
merged
yesterday
morning,
and
we
obviously
keep
updating
that
over
time
that
doesn't
really
have
any
1.14
limitations.
So
it's
going
to
be
a
living
document.
The
second
part
is
a
documentation.
That's
undergoing
review
right
now
we,
the
PR,
has
been
submitted.
E
There
are
some
things
that
are
not
working
and
we
didn't
put
blockers
on.
We
realize
that
inside
Windows
that
in
certain
situations
a
user
might
use
them
and
it
just
won't
work
on
Windows.
So,
for
example,
they
bought
the
port
security
context
right,
apparmor
selinux,
those
are
not
working.
We
didn't
put
a
block
on
that.
So
if
someone
doesn't
read
our
documentation,
then
they
might
get
into
a
couple
of
situations
like
that
we
are
filing
PRS
for
some
of
the
items
that
we
think
will
never
work
on
Windows
to
explicitly
block
them.
E
C
B
Yeah
the
latest
documentation
PR
in
detail,
but
if
lots
of
other
people
are
looking
at
it
are
we
gonna
be
I'm,
pretty
satisfied
by
the
level
of
detail
in
the
cap
and
that
probably
needs
to
be
simplified,
some
for
user
documentation,
but
you
know
basically,
there
were
a
few
major
high-level
issues.
I
think
that
can
be
conveyed
if
you
used
to
summarize
it
pretty
easily
so
I'm,
not
too
worried
about
that
I
think
it'll
be
a
while
before
it
gets
a
lot
of
usage
anyway.
B
C
C
G
C
G
C
B
E
B
H
H
Right,
sorry
about
that,
all
right,
so
before
I
get
started
yesterday,
Josh,
burkas
and
I
did
a
presentation
at
open
source
leadership
summit
on
not
your
average
mentoring
talk.
It
was
pretty
much
about
some
of
the
high-level
things
that
we
put
in
place
within
this
project.
Some
of
the
things
all
of
you
are
very
familiar
with,
like
the
release
team
and
it
sounds
like
you're
doing
very
similar
things
with
API
review.
I
just
heard
the
the
community
meeting
that
Matt
gave-
and
it
sounds
like
everybody's
on
to
a
really
good
start
here.
H
As
far
as
mentorian
is
concerned,
so
I'm
actually
I
was
pretty
much
planning
on
giving
a
lot
of
this
talk
to
architecture,
but
I'm
gonna
do
something
a
little
bit
different
now
and
I'm
gonna
go
into
some
really
tactical
things
that
I
think
we
could
do.
That
would
have
an
impact.
So
let's
get
started.
H
But
people
poke
around
when
we
ask
for
when
we're
explicitly
asking
for
them
to
step
up
into
roles.
They're
gonna
be
poking
around.
So
it's
always
good
to
have
issue
hygiene
regardless
and
PR
hygiene,
so
labeling
and
contributor
experience
and
people
that
work
closely
with
contributor
experience
can
actually
come
in
and
do
sort
of
an
audit
if
that's
something
that
you're
interested
in,
especially
when
it's
coming
to
first
new
contributors
as
well
as
growing
the
ones
that
you
have
so
really
good
stuff
from
people
and
contributor
experience
that
that
can
come
in.
H
If
you
want
and
talk
about
it,
there's
actually
a
couple
live
conversations
that
we're
having
with
networking
as
well
in
regards
to
issue
triage
specifically
clean
and
audit.
Your
owners
files
as
people
are
getting
promoted
into
these
things.
We
do
have
a
lot
of
inactivity.
There's
tons
of
issues
that
are
set
right
now,
DIMMs
I,
know
leading
a
couple
efforts.
I
felt
Brian
commented
on
one
earlier.
This
is
super
critical
and
stuff,
and
work
excuse
me
and
work
that
can
be
done.
While
we
do
the
rest
of
this
work
as
well.
H
But
this
is
important
because,
as
we
grow
our
new
set
of
leaders
within
the
project
and
with
an
architecture,
we
just
need
to
make
sure
that
they
have
clear
paths,
and
one
of
those
includes
making
sure
that
the
people
doing
the
work
are
showing
a
contributing.
Markdown
file
is
super
critical.
We
of
course
have
a
main
contributor
guy,
but
that
main
contributor
guides
scope
is
really
to
make
sure
it
covers
the
gamut
of
the
project
and
not
necessarily
go
into
any
super
specific.
H
I
know
Michael
Michaels
on
the
call
right
now
he
just
did
one
for
Windows
and
then
what
we
can
do
is
we
can
link
out
those
contributor
guides
to
from
the
main
contributor
guide
as
well
and
then
last
for,
like
the
house,
getting
in
order.
Part
is
roles
which
I
will
go
into
a
little
bit
and,
like
I
said
I
I
just
found
out
about
the
API
review,
stuff
and
Jordans
awesome
for
for
heading
this
up,
but
I
did
want
to
touch
on
building
teens
outside
of
just
this
API
review.
H
I
think
this
is
cool,
because
it
sounds
like
something:
that's
well
scoped
and
that's
exactly
what
role
should
be,
but
I'm
sure,
there's
plenty
of
other
things
that
this
sake
does
outside
just
API
review
that
can
deserve
a
team
or
people
who
are
in
sort
of
shadow
roles,
if
you
will
so
think,
I
think
each
one
of
you,
especially
if
you're
an
owner
and
you're.
Listening
to
this,
you
should
really
think
about
what
can
you
take
off
of
your
plate?
What
don't
you
like
about
your
about
your
contributing
journey
here?
H
What
do
you
feel
like
we
could
deserve
to
have
somebody
do
those
are
things
that
we
really
should
think
about
creating
roles
for
I
know,
like
the
furn
sense,
like
just
to
get
super
personal,
like
I'm,
ready
to
get
rid
of
a
lot
of
moderation,
duties
that
I
do
for
this
project.
I.
Think
a
lot
of
you
already
know
that
already
so
we're
creating
moderation,
teams
and
contributor
experience.
So
this
is
a
way
for
us
to
scale
in
in
areas
where
we
didn't
necessarily
think
about
that
say
three
months
ago.
H
H
So
it's
important
that
we
figure
those
things
out
and
a
lot
of
these
roles
too,
like
I,
put
new
contributor
ambassador
on
here.
A
lot
of
these
roles
can
actually
help
out
with
these
growing
pains
that
were
what
that
we're.
Seeing
and
mentoring
so
like
a
new
contributor
ambassador
could
host
a
meeting
once
a
month,
and
you
would
delegate
to
this
individual
to
like
grow
a
team
of
people
who
could
help
actually
on
board
people
quicker
than
just
reading
documentation
sort
of
like
an
AMA.
H
If
you
will,
but
it's
set
on
your
agenda,
people
know
about
it:
it's
a
place
where
they
can
go
and
just
get
live,
support
immediately,
just
to
get
kind
of
either
ramped
up
or
whatever
I
mean
it
doesn't
even
need
to
be
new
contributor
ambassador.
It
can
be
a
current.
It
just
could
be
a
contributor
ambassador
if
you
want
and
like
communications
lead
to
is
another
role
that
I
thought.
H
That
would
be
super
beneficial
for
this
group,
because
most
people
are
so
in
depth
with
just
getting
some
of
the
technical
specifics
out
the
door
and
releasing
features
which
is
awesome
but
like
let's
communicate
better
and
one
of
the
ways
that
we
can
do.
That
is
by
having
someone
have
that
as
a
duty
and
then
that
person
could
be
responsible
for
making
sure
that
certain
things
are
released
on
a
cadence
like,
for
instance,
taps
every.
You
know
every
week
or
something
that's
just
like
an
example
for
4
p.m.
H
but
like
for
architecture
like
API
reviews,
even
like
somebody
that
would
that
could
figure
out
how
to
automate
communications
around
certain
steps
of
that
to
make
sure
that
everybody
is
in
the
know,
just
stuff
like
that
would
be
super
helpful.
I.
Think
in
these
growing
stages,
if
you
will
I
even
included
a
little
photo
there
of
the
role
books,
that
the
release
team
does
and
I.
Think
that
like
when
you
set
your
issues
for
these
roles.
So,
for
instance,
contributor
experience.
Actually
do
I
have
this
up.
No,
but
I.
H
Have
it
in
this
talk
contributor
experience
just
pretty
much
filed
any
issue.
That
said,
we
want
to
create
all
these
roles
and
come
help
us,
and
then
these
people
who
will
get
nominated
into
these
roles
will
ultimately
build
the
teams
and
build
the
guidelines
and
the
scope
of
done
here
is
when
the
role
books
are
done.
So
then,
then
we
kind
of
have
a
start
and
a
stop.
There.
H
So
the
other
thing
that
I
think
we
could
do
a
lot
better
job
of
as
far
as
mentoring
is
concern
is
generating
content.
That's
not
documentation.
People
have
different
learning
styles.
This
is
something
that
I
am
studying
heavily
as
of
late,
especially
now
that
dr.
Anita
Sharma
from
OSU,
that's
Oregon,
State,
University's,
open
source
lab
are
studying
mentoring
within
open
source
communities
and
things
along
those
lines,
and
they
found
out
that
that
successful
mentoring
communities
are
ones
that
have
ample
learning
content
that
isn't
documentation
so
live
streaming
and
recording
content
is
super
hot.
H
These
days,
I
think
a
lot
of
you
see
that
in
your
networks,
people
use
twitch
to
do
live
code,
reviews
things
like
that.
It
really
accelerates
people's
learning
environments
and
it's
something
that
you
can
also
delegate
to
to
other
people
to
help
out
with
so
live.
Api
review
sessions
streamed
or
recorded.
We
have
access
and
weeding
contributor
experience
has
access
to
YouTube,
which
is
an
awesome
source
for
us
to
get
out
this
content.
But
yesterday
on
the
Syrian
committee,
meeting,
Tim
st.
H
This
is
like
this
is
critically
important,
but,
like
you
can
even
think
about,
it
is
okay,
let's
show
people
what
some
common
dependency
failures
are
or
where
people
fail
a
lot
in
kubernetes
kubernetes.
You
can
talk
about
the
problems
that
you
see
in
communities.
Kubernetes.
You
can
talk
about
the
the
code
structure,
problems
that
you
see
that
maybe
other
people
could
tackle
that
aren't
necessarily
covered
in
issues.
So
the
TLDR
here
is:
let's
fire
up
the
zoom
share
your
screen
and
start
talking.
We
can
either
do
that
for
you
through
something
called
meet.
H
Our
contributors
meet
our
contributors,
if
you
don't
know
happens
once
a
month
and
it's
on
the
first
Wednesday
of
the
month,
and
it's
super
fun
three,
but
to
mean
anywhere
between
three
to
six
contributors
get
on
the
line
and
we
ask
live
questions.
It
usually
works
itself
out
the
team
between
ten
12
questions,
and
this
is
where
a
lot
of
people
advertise
for
their
sig
as
well
so
like
when
will
a
Versailles
on
Twitter
and
all
kinds
of
other
sources.
H
A
que
will
make
sure
that
it's
a
targeted
demographic
of
contributors
and
not
just
like
randoms
on
the
internet
that
are
watching
this
stuff,
which
is
cool
too,
if
you're
random,
on
the
internet,
watching
this
video
right
now,
but
but
it's
really
targeted
to
our
crew,
so
that
we
know
that
we're
getting
value
out
of
it.
And
what
you
see
on
the
screen
now
is
just
some
of
the
latest
videos
and
the
cool
part
is
I,
didn't
even
have
to
type
in
kubernetes.
H
It's
already
coming
up
as
first
search
results,
which
is
great
exactly
what
we
wanted
it
to.
We
also
do
code
based
live
code,
reviews
all
types
of
fun
stuff
and
the
the
code
based
tour
for
kubernetes
kubernetes
Stefon,
just
randomly
decided
to
take
someone's
question
that
I
thought
was
a
troll
question
at
first,
which
was
so
describe
kubernetes
kubernetes
and
he
just
fired
up,
fired
up
his
github
and
started
going
through
it,
and
it
was
wonderful
and
now
it
has
9
under
views.
H
So
the
content
is
definitely
worthwhile
for
us
and
all
the
feedback
that
I
get
for
people
that
watch
it
is
that
they
want
more
of
it.
So,
let's,
let's
get
back
to
that
all
right.
The
other
thing
about
the
stuff.
That's
not
documentation
or
even
videos
is
the
users
contributor
summit
to
your
advantage
and
you're.
H
The
chairs
and
tech
leads,
and
thanks
for
from
SIG's
for
this
one
and
and
other
things
we'll
be
getting
a
message
within
the
next
24
hours
about
Barcelona,
specifically,
but
think
about
even
something
like
as
far
away
as
San
Diego
think
about
Shanghai.
How
can
you,
as
the
Stig,
take
advantage
of
this
code
we've
run
workshops
that
would
make
people
more
informed.
H
H
Support
for
me
at
that
time
period
was
my
peers
and
having
an
academic
counselor
like
mentor
all
of
us
together,
because
we
all
had
same
goals
and
a
lot
of
the
time
so
I
was
taking
tests.
So
I
implemented
that
into
some
different
stakes
and
subgroups
who
needed
mentoring.
So
a
lot
of
them
didn't
have
the
time
either,
which
is
obviously
the
I
think
the
thing
that
we're
trying
to
solve
for
the
most
and
the
kubernetes
project
in
general
is
just
we
can't
grow
time.
So
group
mentoring
will
really
help
with
that.
H
So
you
give
a
clear
goal,
which
is
hey,
be
an
approver
in
three
months,
and
how
do
you
find
out
those
goals
you
get
them
from
the
community
membership
document?
So
then
we
get
to
also
test
out
the
validity
of
this
live
document
because,
for
instance,
if
it
says
that
you
need
you
know,
20
PRS
or
something
like
that.
H
As
far
as
a
structure
is
concerned,
if
they
haven't
already
built
up
that
natural
trust
with
the
project,
then
you
know
we
should
be
able
to
go
through
these
guidelines
and
still
establish
that
trust
with
them
through
that.
But
it
provides
clear
goals
to
people
everybody's
working
together
on
the
thing
and
we
can
create
safe
spaces
for
them.
So
some
of
those
space
bases
those
safe
spaces
could
include
like
private
slack
channels
where
people
won't
feel
like
they're
asking
anything
embarrassing.
H
Maybe
you
know
they
want
clarification
as
to
what
a
sub
project
is
again,
something
like
that,
but
we
can
still
up,
can
spin
up
group
mentoring
at
any
time.
This
isn't
something
that
is
necessarily
structured
in
any
way.
The
only
thing
that
we
need
is
the
intent
to
do
it,
and
at
least
one
to
two
mentors
who
could
moderate,
who
would
be
able
to
mentor
anywhere
between
three
to
ten
people
at
a
time.
H
H
This
is
the
be
explicit
part,
and
this
has
to
this
boils
down
into
just
what
we're
looking
for
from
people.
Ask
and
listen.
I
think
that's
the
most
important
part
as
we
grow.
Our
mentoring
programs
here
is
that
we're
doing
both
listening
piece
is
crucial.
I'll
show
you:
where
is
what
on
here?
It
is
so.
Last
year
we
did
a
kubernetes
contributor
survey.
One
of
the
questions
was:
what's
your
biggest
blocker,
you
can
see
the
green.
H
There
is
not
enough
time
in
the
week
and
then
you
can
see
the
red
on
the
left
is
don't
know
enough
to
mentor.
So
obviously
we
can't
control
time,
nor
can
we
control
other
people's
schedules,
that's
on
them,
but
what
we
can
control
is
what
they
don't
know
and
that's
a
reason
why
I
feel
like
I'm
pushing
the
content
so
hard
is
because
these
are
areas
where
we
can
do
better
with
if
we
just
try
but
not
enough
hours
in
the
week.
H
This
is
why
I
don't
push
one-on-one
mentoring,
especially
just
brand,
on
one-on-one
mentoring
like
the
forms
and
things
like
that.
I
just
think.
There's
too
much
level
of
ambiguity
there
that
we
just,
unfortunately,
can't
control.
So
that's
that's
sort
of
why
I
think
being
explicit
and
listening
to
the
fact
that
people
don't
have
the
time
is
so
crucial.
So
on
this
thing,
I
put
that
on
this
thing
on
the
slide.
H
I
put
that
maybe
you
all
should
have
this-
have
a
survey
yourself
about
why
people
don't
contribute
to
architecture
the
hardest
parts
about
contributing
to
architecture.
What
topics
do
they
struggle
with
continually?
What
learning
content
do
they
want
to
see?
What
some
of
the
questions
that
you
would
ask
a
mentor?
This
is
I
think
this
is
actually
about
how
I
started
to
talk
yesterday,
because
this
is
how
I
heard
that
some
of
the
people
that
were
wanting
one-on-one
mentoring
actually
don't
need
it.
H
They
just
needed
better
documentation
in
some
cases,
or
they
just
needed
like
a
support,
channel
and
things
along
those
lines.
So,
if
you
are
explicit
with
what
people
are
wanting,
then
you'll
be
able
to
better
suit.
You
know
better
tailor,
what
we're
providing
them
and
that's
pretty
much
it
for
me.
B
D
H
Yeah
no
I
think
that's
that's
pretty
accurate
I.
Think.
A
lot
of
what
I
just
discussed
could
be
several
work
streams
that
are
going
on
at
the
same
time.
I.
Don't
necessarily
think
any
of
this
is
like
you
know.
We
need
to
do
X,
Y,
&
Z,
before
we
do
before
we
do
the
rest,
but
I
think
the
quickest
things
that
can
be
done
are
identifying
the
areas
where
people
need
learning
and
then
serve
it
to
them.
H
C
So
I
kind
of
feel
like
in
terms
of
getting
the
class
together
and
showing
them
how
it's
done
and
having
everybody
rally
around
a
common
set
of
work.
Jordan
has
now
effectively
set
that
up
with
API
review
and
I've
got
the
infrastructure
in
place
for
conformance
and
Tim
will
help
rally.
Folks
and
do's
has
been
it's
thoroughly
helpful
as
well.
So
the
other
currently
enumerated
sub
project
that
belongs
to
Sigma
architecture
is
code
organization.
C
It
seems
like
we
ought
to
put
together
something
for
that
if
we
want
that
to
be
a
sustaining
ongoing
thing,
because
at
present
I
feel
like
it's
been
a
bunch
of
piecemeal
project
proposals,
I
think
I
just
saw
a
flag
fly
across
some
notification,
the
other
day
and
I'd
love
to
understand.
Like
the
broader
vision
there,
yeah.
B
I
was
thinking
we
would
focus
on
the
two
other
sub
projects,
which
are
actually
somewhat
active
right
now.
The
beak
are
used
in
conformance
testing
and
get
those
on
more
solid
footing,
just
to
like
double
down
on
our
effort
there
and
before
really
starting
up
that
new
effort.
Although
I
know,
Jordan
has
been
poking
at
part
of
it,
a
little
bit
yeah.
I
I
think
the
API
reviews
to
mostly
as
a
toehold
some
a
lot
of
what
Paris
just
talked
about
like
flushing
out
roles
and
especially
for
API
review,
where
it's
kind
of
a
good
ramp
from
training
to
a
greater
involvement.
We
I
think
we
want
to
have
a
good
idea
about
who
the
people
are
in
each
of
their
roles
so
that
we
can
target
target
them
for
additional
training
or
shadowing
opportunities.
So,
following
up
with
what
Ferriss
talked
about
getting
that
more
solid
footing
for
the
quarter
quarter
code
organization,
we're
talking
about
that,
go
module.
I
B
I
think
the
challenge
with
the
organization
is
it's
not
really
a
coherent
effort
that
we
can
onboard
more
people
to
get
I
mean
we
need
that
someone
I'm,
leading
it
and
putting
out
a
roadmap
before
we
get
on
board
more
people.
It's
just
people
have
so
far
been
solving
problems
as
they
come
up
and
they
were
blocking
some
other
thing,
so
it
has
grown.
You
know
iteratively
and
organically
and
we're
hoping
to.
F
Off
I
mean
I
feel
like
this
is
a
topic
code
organization
that
needs
a
contributor
but
not
sort
of
the
leaf
contributor,
more
of
a
stem
contributor,
someone
who's
willing
to
take
the
whole
thing
and
bring
up
other
contributors
to
get
the
work
done
like
I'm,
happy
to
help
bootstrap
that
person
I
don't
have
the
time
to
help
people
with
sort
of
the
leaf
efforts.
I
think
there's
a
lot
of
exploration
that
needs
to
be
done
before
the
leaf
efforts
can
start
I.
F
H
That
was
that's
a
key
to
about
the
roles
and
I
I.
Just
didn't
have
enough
time,
necessarily
just
to
get
through
all
of
the
concepts
of
the
roles,
but
I
mean
what
we're
essentially
doing
is
feeding
these
roles
for
other
people
to
build
so
I
mean
you
are
obviously
giving
these
people
a
level
of
trust
and
credit,
but
at
the
same
time
you
still
will
have
to
approve
their
guidelines
and
role
books,
though
I
mean
it's
just
giving
someone
the
empowerment
to
to
do
the
work
and
build
the
team.
C
I
B
Okay,
so
thanks
everyone
Paris
for
that
I
found
that
very
helpful.
We'll
definitely
have
some
excuse
of
action
items
to
come
out
of
that,
such
as
defining
some
roles.
We're
going
to
set
up
for
the
I
see
some
people
who
asked
to
be
involved
in
or
who
are
involved
in
informants
show
up
later
Tim
Sinclair
is
gonna,
send
out
a
doodle.
Maybe
we
should,
if
you
want
to
be
in
the
conformance
testing,
specific
meetings,
to
help
on
board
with
reviewing
conformance
tests
and
dragging
that
effort
forward.
B
Maybe
drop
your
name
into
the
notes
stock
under
that
topic,
which
is
the
second
topic
in
the
amid
agenda
notes
for
today,
and
we
will.
The
holistic
architecture
group
will
meet
again
in
two
weeks
we're
on
priority
meetings.
Definitely,
if
things
come
up
use
the
mailing
list.
Just
my
continual
reminder
that
github
notifications
and
the
slack
are
not
not
as
reliable,
at
least
not
for
me.