►
From YouTube: Cartographer community meeting - Nov. 10th 2021
Description
00:00 Intro
01:16 The TL;DR
05:38 RFC 015 discussion (Supply Chain selection with traits)
38:31 Community meeting structure and agenda discussion
52:15 Testing practices discussion
Community meetings happen each Wednesday at 8:00 AM PT/11:00EDT
See the agenda here (https://bit.ly/2Z67z08), add any topic you may want to discuss and join us live!
A
A
A
A
B
B
B
We
are
going
to
reduce
the
set
of
roles
that
the
controller
gets,
and
this
is
a
breaking
change,
but
basically
we
want
to
limit
the
scope
of
what
a
controller
can
do
to
a
given
workload
and
the
way
we're
going
to
model
that
is
by
using
the
service
account
that's
in
the
same
name
space
as
the
workload
which
it's
operating
on.
So
in
that
case
the
controller
would
only
get
the
permissions
that
it
that
the
workload
has
in
that
namespace.
B
A
A
C
D
D
A
E
E
Apparently,
I
can't
find
my
zoom
there.
It
is
zoom
likes
to
hide
okay.
Oh,
I
did
a
good
job
with
the
draft.
Look
at
that.
So
the
idea
of
this
one
is
that
is:
is
in
a
lot
of
use
cases.
There
are
supply
chains
that
handle
doing
multiple
chores,
work,
behaviors
and
then
there's
different
permutations
of
those
supply
chains,
and
I've
got
some
examples
that
could
come
up,
but
the
the
kinds
of
characteristics
a
supply
chain
might
resolve
for
is
like
the
type
of
work.
E
I
hear,
there's
a
type
called
job
where
people
just
want
a
workload
to
end
in
a
job
being
executed,
I'm
thinking
in
terms
of
like
agents-
I
don't
know
if
that
makes
sense
in
the
kubernetes
world,
it
sure
makes
sense
as
like
runnables
and
other
infrastructures,
and
then
another
thing
would
be.
What
sort
of
input
will
be
provided
for
these
workloads,
whether
they're
going
to
run
tests
and
what
kind
of
tests
they'll
run
when
when
it
comes
to
techton?
E
E
So
the
solution,
the
proposed
solution
is
to
be
able
to
specify
selectors
with
different
characteristics
that
could
then
match.
Sorry
provided
workloads
with
different
characteristics
would
then
match
the
most
suitable
supply
chain
and,
and
the
general
rule
would
be
that
the
workload
would
be
selected
by
a
perfect
match.
E
All
of
the
things
are
the
same,
but
if
not,
then
an
over
match
which
does
not
match
any
other
supply
chain
more
perfectly
and
one
of
the
alternatives
I
talked
about
and
possibly
an
alternative.
That's
and
that's
not
non-exclusive
that
we
could
do
both
is
that
the
it
might
be
nice
to
be
able
to
select
on
select
on
the
kind
of
other
values
in
the
spec
of
the
workload
such
as.
E
D
F
E
That
if
we
match
perfectly,
we
win
if
there
is
a
if
there
is
an
over
match,
that
is
to
say
that
the
so
now
I've
got
to
remember,
which
way
I
mean
by
over
match.
I
should
have
made
that
a
little
bit
more
clear
will
only
be
selected
by
when,
when
there
are
more
possible
matches
in
the
supply
chain.
So
if
the
supply
chain.
E
B
B
G
I
think
something
I
I
like
about
that
is
that
it
really
maximizes
the
portability
of
the
workload.
So
if
you
bring
your
workload
to
a
different
supply
chain
that
has
less
labels
on
it,
you
know
and
that
still
still
matches
the
most
things.
If
that
makes
sense,
your
application
still
runs
in
that
context.
So
I
I
really
like
the
proposal
just
a
little
bit
of
feedback
on
the
motivation.
G
You
know
I
kind
of
get
the
sense
that
it's
the
view
is
like
a
work.
The
developer
is
choosing
what
you
know.
Kind
of
policies
apply
to
their
workload,
but
I
think
I
view
it
more.
Like
the
you
know,
the
platform
is,
you
know,
deciding
what
policies
to
apply
to
a
workload
and
currently
for
some
some
things
like
testing
right.
G
It
makes
sense
that
the
developer
has
to
kind
of
indicate
because
we
don't
have
field
selectors
or
things
like
that,
yet
that
you
know
there's
some
thing
that
the
workload
is
you
know,
kind
of
requires
if
that
makes
sense,
but
for
like
scanning
you
know,
does
it
make
sense
for
the
developer
to
decide
when
their
application
gets
scanned,
or
does
it
make
more
sense?
For
the
you
know,
platform
to
say
scanning
is
a
requirement
for
applications.
E
Yeah,
I
I
get
that,
but
it's
like
that's
that's
a
decision
for
the
platform
right.
So
if
the
platform
decides
you
know,
the
the
supply
chain
is
always
going
to
have
a
security
scan
in
it.
Then
it
doesn't
matter
whether
that's
specified
here,
I'm
overspecifying
for
a
broader
audience,
all
right
that
hey,
maybe
you
want
to
be
out
of
select
on
these
things
right
at
that
point,
I
would
just
say
you
just
take
this
this
out
and
say:
that's
not
a
characteristic
right.
We
don't
support
that
as
a
characteristic.
We
support
that
as
a
that's.
G
E
Yeah
I
was
trying
to.
I
was
just
trying
to
make.
I
was
trying
to
make
this
the
feeling
of
combinatorial
combinatorial
explosion.
Really
that's
why
I
put
it
there
and
I
was
looking
for
examples
right,
but
you
can
imagine
some
kind
of
combinatorial
explosion
and
and
having
a
bunch
of
a
bunch
of
very
specific
and
also
like.
I
think
the
thing
I
was
trying
to
point
out:
oh
oh,
this
is
supposed
to
be
a
mutation
here.
E
This
was
where
I
was
supposed
to
be
pointing
out.
You
could
have
said
web
image
test
scan
or
you
could
have
said
web
test
image,
scan
the
point
being,
there's
that
with
commodore
combinatorial
explosions
and
having
only
a
single
selector,
you've
now
got
a
string.
You've
got
to
know
how
to
form
rather
than
just
say
these
are
the
things
I
am.
E
I
I
think
certain
platforms
are
going
to
say
absolutely
not
all
right
and
I
think
other
people
might
say
well
yeah,
let's,
let's
make
that
possible,
because
maybe
maybe
we've
got
a
bunch
that
I
don't
know.
We
trust
the
scan.
I
think
I've
heard
people
talk
about
how
if
it's
built
by,
if
it's
built
something
built
by
a
builder,
that
that
is
already
going
to
make
sure
that
the
correct
objects
that
the
cve
safes
objects
are
installed.
H
H
Am
I
going
to
be
able
to
work
around
getting
away
what
the
platform
does
it's
just
almost
calling
out
that
it
may
be
just
worth
having
an
example
just
calling
out,
like
a
bullet
point,
just
to
say
that
that's
you
wouldn't
be
able
to
as
a
developer.
You
know
as
a
developer,
you're
not
able
to
skip
certain
policies
applied
by
the
platform.
E
J
J
G
In
the
future,
if,
if
there's
some
fields
like
you're,
providing
a
pre-built
image
and
pre-built
images
need
to
be
scanned,
but
images
built
using
the
systems
build
tool,
don't
need
to
be
scanned
right.
We
could
introduce
a
system
for
enforcing
that.
If
this
field
is
set
right
on
the
workload,
then
a
scan
always
happens,
otherwise
it
doesn't,
and
then
it's
policy
based
and
not
something
a
developer
chooses.
Maybe
when
we're
talking
about
best
match
labels.
You
know,
at
least
in
this
context.
G
E
100
and
in
fact
yeah
I
mean
there's
that's
why
I'm
saying
it's
completely
separate
right.
If,
in
that
scenario,
you
don't
want
the
work
globe
to
specify
whether
it's
in
or
out,
you
want
it
to
be
inferable
all
right,
I'm
down
with
that.
I
just
like
I
said
I
was
just
looking
for
words.
That
would
help
me
with
permutations,
not
not
anything,
really
very
concrete
here,
so
I'll,
just
drop
it
and
I
think
it'll
throw
less
spanners
into
rationalizing
this.
H
H
B
I
think
one
of
the
the
key
things
to
keep
in
mind
too,
is
like
maybe
the
developer:
isn't
the
one
actually
applying
these
labels
right?
It
could
be
something
that's
done
by
the
platform
automatically
based
on
certain
characteristics
like
based
on
certain
fields
in
your
in
your
workload
itself,
and
so
I
think
we
need
that
flexibility
to
say
like
hey.
These
are
things
that
could
be
provided
by
the
developer,
but
not
necessitate
it
so
that
we
can
remain
flexible
on
the
oss
side
about
like
how
the
magic
happens.
E
This
is
definitely
optional
propositions.
That's
why
scan
is
still
okay,
it's
just
it's
throwing
a
spanner
in
the
thinking
right.
These
are
optional
propositions.
I
would
say
that
not
you're
not
allowed
to
skip
testing
is
also
something
an
operator
can
suggest
and
when
they
do
that
they
don't
match
on
it
as
a
characteristic.
E
They
don't
say
the
developers
hey
you'll
need
to
do.
You
know,
label
test
techton,
they
will
say,
give
us
the
text
on
parameter
or
this
will
fail,
and
we
will
see
that,
because
we'll
see,
parameter
for
detect
on
pipeline
was
not
passed
in
the
workload
goes
into
a
into
a
status
of
not
ready
with
the
unmatched
field.
So
that's
that's
already
supported
right.
E
If
that's
the
approach
that
the
operators
wish
to
take,
if
they
want
to
let
someone
select
or
opt
in
and
out,
this
is
how
they
could
do
so
and
that's
why
I
think
this
is
down
the
bottom.
When
I
was
talking
about
selecting
on
fields.
That's
why
I
personally
feel
like
this
is
always
going
to
be
non-exclusionary.
E
Decide
describe
the
fact
that
I
believe
we
should
implement
both.
I
just
don't
think.
I
think
the
quickest
and
easiest
way
to
keep
us
moving
forward
was
to
start
with
the
label
selectors,
because
that
opens
up
the
world
of
possibilities
for
supply
chains
without
heavy
templating
and
field
selectors
and
ytt,
and
that
sort
of
stuff.
Do
you
think
the
ultimate
goal
here
right
to
make
the
supply
chains
a
little
easier
to
reason
about.
H
Yeah,
no,
it's
just
yeah.
That
sounds
good.
If
we
have
those
scenarios
it
just
all.
The
only
way
of
coming
from
is
not
to
give
the
impressions
to
a
developer
that
by
removing
a
selector,
they
can
choose
to
not
select
certain
behaviors
like
scanning
and
test,
and
that's
just
from
a
plain
devil's
advocate.
That's
it
could
be
assumed
that
way.
I
think
if
we
just
call
that
out,
that's
not
what
this
is
about
and
I
think
that's
satisfies
it.
E
Is
sometimes
what
this
is
about,
so
I
think
we'll
have
to
call
that
out.
It
is
yeah.
Hey
we're
flexible
enough
that
if
that's
what
you
want
to
do
do
that
right.
The
person
in
control
is
the
operator
so,
and
the
offer
reader
needs
to
know
that
the
I
guess
that's
the
scenarios
we'll
come
up
with
here
in
the
case
where
an
operator
is
suggesting
that
you
can,
where
the
developer
can
opt
in
or
out
they
can
use
labels.
E
E
H
E
H
E
But
in
the
case
of
the
the
test,
for
example,
if
you
specify
workload
spec
parallel
workload,
params
I
forget
where
params
live,
is
it
in
spec,
spec,
params,
tecton
pipeline
name
and
the
techdom
pipeline
right?
Two
options
might
might
present
themselves
to
the
operator
in
the
term
in
terms
of
what
they
want
to
control,
they
might
say
we
always
have
to
have
one,
in
which
case
there
is
no
characteristic
available.
E
There
is
that
field,
and
there
is
a
pipeline
that
expects
that
that
param
sorry
they
expect
that
param
to
be
fulfilled
or
it
will
fail,
or
they
might
say,
and
it
can
be
optional,
all
right.
They
can
choose
to
do
it
or
not.
Do
it
and
the
easier
way
is
to
select
by
a
select
by
a
characteristic
that
way
when
it's
absent,
that's
an
error,
not
a
not
a
opt
out,
so
to
be
a
little
clearer.
E
If
I
was
the
writing
the
workload
and
I
said
characteristic
testing
and
I
failed
to
put
in
the
field,
then
I
get
an
error
that
told
me.
I
forgot
to
do
something,
whereas,
if
I
put
in
something
and
I
forgot
to
put
in
the
field,
it
would
never
actually
run
because
I
chose
not
to
have
that
characteristic.
Regardless
of
the
fact,
and
that's
it
back
to
steven's
point
about
portable
workloads,
all
right,
it
makes
them
more
portable.
H
No,
I
I
get
the
point
yeah
for
bill's
letters,
but
I
just
don't
know
I'm
just
trying
to
work
through
on
workloads
because
you
know
do
we
want
to
be
able
to
give
to
provide
those
selectors
as
optional
selectors
on
workloads,
rather
than
just
decide
what's
needed,
based
on
what's
in
the
spec
or
whatever
to
then
the
controller
work
out,
what
selectors
for
templates
and
various
other
things
needs
need
to
be
used
to
be
chosen,
but
yeah.
Another
I'll
wait
for
those
scenarios
and
I'll
probably
clearly.
E
E
So
there's
another
use
case,
and
I
think
we
need
to
capture
that
in
some
way,
because
I
think
that's
the
core
of
where
this
was
driven
from
was
the
ability
to
get
started
really
quickly.
When
you're
using
cartographer
and
whatever
the
platform's
providing
in
terms
of
supply
chains,
you
could
use
them
all,
and
then
we
can
start
to
limit
what
you
can
do
by
just
removing
them.
D
The
overmatch
part
of
of
characteristics
would
then
require
that
we're
we're
giving
up
on
or
we're
foreclosing
the
ability
to
have
two
supply
chains
match
on
one
workload.
So,
and
I
think
that
that
that's
something
that
in
the
past,
I
thought
we
there
would
be
use
cases
that
would
come
up
for
that.
I
don't
I've
been
noodling
and
and
have
become
less
and
less.
I
thought
it
less
and
less
likely,
but
if
this
is
the,
if
there's
the
rfc,
that's
going
to
close
that
door,
we
should
make
sure
that.
E
D
D
B
B
To
match
on
multiple
supply
chains,
right,
like
you,
you
would
still
never
select
multiple
supply
chains.
You
could
potentially
partially
match
on
a
few
different
ones,
but
you
would
still
only
ever
select
the
best
possible
one
and
if
it's
unclear
what
the
best
possible
one
is.
So
if
you
had
like
two
supply
chains
that
match
the
max
number
of
labels,
then
you
would
error
right.
Yeah,.
D
What
I
was,
what
I
was
saying
is:
if,
if
a
use,
if
a
user
organization
came
and
said,
oh
actually,
we'd
like
to
have
two
supply
chains
run
against
this
one
workload.
If
we
go
with
this,
then
cartographer
would
would
not
be
able
to
handle
that
case.
I'd
say:
well,
it's
going
to
match
with
the
best
one.
E
Yeah,
but
I
think
I
think
I
think
the
discussions
that
often
come
up
about
multiple
workloads
often
relate
to
similar
use
cases.
As
this,
which
is,
there
is
multiple
things
that
we'd
like
to
see
happen
and
we're
trying
to
work
out
how
best
to
select
for
work
to
be
done
in
a
clear
and
obvious
way,
and
this
is
one
way
another
way
might
be-
to
have
multiple
supply
chains
that
can
all
do
specific
work.
E
I
know
there
are
also
some
other
use
cases
for
multiple
supply
chains,
but
I'm
not
sure
that
the
ones
where
you
do
very
separate
work
are
even
if
they're
healthy.
They
could
probably
be
solved
by
having
us
a
single
supply
chain
with
more
components
and
again
it
comes
down
to
how
you
select
for
those
and
how
complex
those
are.
E
I
mean
I'm
not
saying
that
there
isn't
a
reason
I'm
just
like.
I
think
this
is
a
part
of
that
discussion
right
around
why
we
might
have
them,
but
I
agree
that
it
is
putting
cement
in
there
in
the
locks,
because
now
we've
got
not
just
a
validation,
but
now
also
a
behavior
that
is
predicated
on
there,
only
being
one
that
should
select.
A
E
Obviously,
the
first
work
piece
is:
I
can
see
your
kid
there,
david,
the
the
first,
the
first
step
obviously
is
just
to
put
in
those
user
scenarios
just
to
sort
of
like
clarify
it.
A
bit
I
feel
like
the
selecting
on
fields
and
selecting
on
on
labels
is
both
valuable,
but
we
can
get
started
with
the
fields,
a
lot
easier.
Sorry,
the
labels
a
lot
quicker,
so
we
should
probably
start
work
on
that
unless
anyone
has
any
big
objections
to
this.
This
work.
H
I
think,
as
long
as
we
just
go
through
those
scenarios
validate
that
it
is,
does
it's
gonna
be
clear
from
the
user
experience
from
the
developer's
point
of
view
that
they
can't
can't
choose
to
avoid
scanning
or
like
we
just
like?
We
just
talked
about
as
long
as
as
long
as
that's
that's
that
doesn't
enable
that
behavior.
I
think
I
guess
it's.
Okay
from
my
point
yeah.
It.
E
H
But
there's
also
that
user
experience,
if
I
remove
a
selector
label
that
gives
me
that
if
I've
got
the
ability
to
do
that,
if
I'm
a
developer
and
my
interface
is
a
workload
that,
for
me,
is
I
own
that
that
workload,
the
things
that
are
on
that.
So
if
I
remove
something
from
there
like
that
label
selector,
then
it
gives
me
the
impression
that
I
could
do
that.
I
guess
maybe
it's
user
experience
or
something
like
that.
Well,.
E
L
Matter
right,
I
was
just
going
to
mention.
Other
person
can
be
done
is
also
like
if
you're
already
using,
let's
say
opa
with
gatekeeper
that
like
lets,
you
write
those
policies
with
like
arago,
you
could
say:
oh
the
workload
comes
without
these
annotations,
so
the
workload
does
not
say.
Oh
I
have
these
capabilities
like
I
don't
have
the
capability
of
being
scanned.
G
It's
just
gonna
add
to
that.
I
think
I
think
a
big
part
we're
missing
here
is
like.
I
don't
think
this
is
an
end-all,
be-all
feature
for
deciding
you
know
what
supply
chains
match.
What
workloads,
I
think
we're
thinking
about
this
like.
Currently,
we
have
a
problem
where
web
test
or
web
scan
test.
If
you
choose
that
label,
you
end
up
with
really
non-portable
workloads
right
that
the
selection
mechanism
is
reversed.
G
You
know
like
labels,
that
a
developer
adds
or
you
know-
can-
can
parse
the
contents
of
the
workload
and
add
labels
automatically.
At
the
same
time,
right,
like,
I
think,
there's
there's
additional
infrastructure
we
can
think
about
in
the
future
for
for
dealing
with
those
policy
things,
but
putting
policy
related
things
like
scanning
in
this
kind
of
makes
it
feel
like
it's.
You
know
like
it's
a
direct
developer
use
case
to
enable
or
disable
scanning,
and
that's
not
really
the
intent
is
that
I
don't
know.
Did
I
hit
the
different
things?
A
Thank
you,
okay,
yeah.
Probably
it's
an
ongoing
discussion
regarding
this
rfc.
Thank
you
for
your
input.
So
next
items
it's
indeed
related
to
this,
the
community
meeting
structure
timing.
We
were
discussing
with
we
with
most
of
you
last
week
that,
for
example,
the
last
community
meeting
we
had
more
than
an
hour
and
most
of
the
time
was
just
discussing
rfc
14,
which
is
useful,
it's
great
and
there
was
an
idea
or
a
proposal
to
have
a
separate
meeting
to
discuss.
A
I've
been
checking
this
idea
with,
with
some
other
open
source
projects
out
there
it's
well,
it's
not
that
common.
The
the
the
proposal
here
is
two
things.
First,
the
mobile
open
mic
discussions
before
rfcs
because
tend
to
be
shorter
than
rfc
discussions
and
and
that
way,
if
the
rfc
discussion
needs
to
go
beyond
the
one
hour
limit
and
the
stakeholders
are
willing
to
to
keep
the
discussion
longer,
the
discussion
can
happen
the
same
meeting.
We
don't
need
to
open
a
separate
meeting
for
this
and
it
will
still
be
in
the
open.
A
I
can
see
reactions
right
now.
Well,
I
was
I
was
just
testing
some
funny
reactions
here
to
to
remind
that.
The
time
is
about
finish
for
a
specific
discussion,
but
I
just
wanted
to
know
your
thoughts
regarding
this
to
have
the
rfc
discussion
at
the
end
or
yeah
last
section
of
the
meeting.
So
it
can,
you
know,
last
longer
if
it's
needed.
J
I
I
D
D
I
D
D
J
A
E
A
E
Was
talking
about
that
that
message
about
when
people
want
to
ask
us
some
basic
question
or
some
or
any
kind
of
question?
That's
not
rfc
related.
We
were
talking
about
prioritizing
those
first
okay,
I
feel
like
having
an
office
hours
meeting
for
those
kinds
of
questions,
so
that
this
one's
more
formally
around
design
decisions
right
and
team
health,
so
that
the
office
hours
is
a
space
for
people
to
talk.
Maybe.
F
E
H
Yeah
so
the
community
office
hours
that
I've
been
involved
in
for
the
last
six
years.
They
we
tend
to
use
a
half
of
or
try
to
get
half
of
the
the
alloy
using
demos
and
people
discussing
things.
Also,
oh
sorry,
steve.
I
didn't
see
your
hand
up
there
by
the
way
I
just
jumped
in
but
yeah
yeah.
If
there's
people
that
have
something
to
bring
up,
maybe
introduce
an
rfc,
but
I
mean
I
went
far
too
long
on
that.
H
I
should
have
added
my
comments
onto
the
rsc
directly
to
marty's
point,
but
not
everybody
can
always
make
the
office
hours
either
whether
that's
work
time
but
also
different
parts
of
the
world
as
well.
So
it's
also
what
we
want
people
to
be
able
to
view
back
on
recordings
and
give
them
some
eye
candy
and
engage
into
the
slack
channels
and
and
comments
on
rfcs
which
can
handle
our
asynchronous
as
well.
Sorry,
steven.
G
I
I
I
I
think
I
agree
with
a
lot
of
what's
with
what's
been
said.
I
worry
a
little
bit
about
the
framing
of
you
know.
It
seems
like
we're
saying
internal
discussion
us
you
know,
like
maybe
maintainers
group,
as
a
synonym
for
a
vmware
or
something
like
that
versus
community
things,
and
not
talking
about
external
issues.
Right
like
I
think
we
should
kind
of
avoid
that
framing
if
we
can
and
think
about
it.
G
So
I
you
know,
even
though
I
believe
we
everything
things
should
move
towards
being
more
asynchronous,
and
you
know
we
should
embrace
the
community
more
right.
You
know
if
we
need
two
hours
of
meetings
a
week
cloud
unit.
Build
packs
has
three
right
now,
even
though
it
is
a
little
bit
larger.
So
I
don't
think
it's
that
unusual.
Whatever,
however,
we
want
to
frame
them.
A
Yeah,
okay,
so
in
summary,
at
least
for
now
we'll
say
that
we
need
to
agree
on
some
things.
Probably
basic
questions
from
users
are
not
the
most
common
thing
on
community
meeting
now
that
I
think
they
will
fully
that
kind
of
questions
are
for
selections.
That's
the
most
usual
place
to
where
users
go
for
basic
things.
A
A
Well,
that
will
that
will
go
against
the
big
rocks
small
rocks
principle,
just
to
ensure
that
we
are
not
rushing
on
rfc
discussions,
because
we
agree
that
they
are
important
and
also
as
as
the
as
as
we
see
how
it
goes
and
how
it
progresses.
We
we
will
need
to
consider
framing
a
separate
office
hours
that
for
for
some
open
source
projects.
Here
it's
been
a
bi-weekly
thing
and
some
other
projects
are
not
doing
it
anymore,
but
certainly
for
photographer.
A
G
Does
anybody
feel
strongly
like
we
need
more
meeting
hours
sooner,
because
I
know
that
one
thing
was
brought
up?
Is
that
we're
trying
to
you
know
in
the
next
couple
weeks
and
kind
of
get
through
a
number
of
rfcs
that
you
know?
One
thing
I
didn't
hear
there
is
like
a
a
plan
to
extend
the
amount
of
time
we
have
open
meetings
a
week
in
the
near
future.
G
A
C
I
We
never
really
finished
that
discussion
and
the
current
state
of
the
code
is,
you
know,
you'll
see
different
tests,
depending
on
her
different
style
of
tests,
depending
on
who
happened
to
have
worked
on
that
piece
of
code
or
who
most
recently
touched
it
and
decided
to
refactor
it
into
their
style
of
choice.
I
guess-
and
it
just
seems
unsustainable
and
certainly
a
you
know-
higher
barrier
of
entry
for
newcomers
to
try
and
like
learn
different
testing
styles
and
figure
out
what
tests
are
right
where
and
what
you?
What
even
is
like
like.
I
If
someone
wants
to
make
a
contribution
like
what
type
of
test
do
you
write
and
that
that
to
be
more
specific,
like
some
people
write
integration
level
tests,
some
people
write
cuddle
tests
and
those
are
usually
used
like
mutually
exclusively,
but
even
within,
like
unit
testing.
Just
like
the
way,
we
format
them
and
the
nesting
structures,
and
things
like
that
is
just
like.
They
all
look
different
and
it
seems
like
it
seems
a
little
unsustainable
and
I
don't
know
how
to
come
to
a
decision.
K
I
L
Yeah,
I
wonder
if
this
is
one
of
those
things
that,
like
as
we
do
the
reviews
and
as
the
team
gets
like
more
settled
on
an
approach,
it's
something
that
like
will
come
up
during
the
review
process
as
we're
like
giving
feedback
about
the
code
being
produced,
I
think,
like
a
style
guide
can
be
useful,
but
it's
only
as
useful
as
we
enforce
it.
Right
like
as
reviewers
looking
at
the
code,
we
actually
like
provide
suggestions
that
match
the
the
style
guide
and
yeah
linking
wise
there's
so
much
linkedin
can
do
it
too.
I
Yeah
I'd
be
happy
to
wait
until,
like
we've
settled
on
an
approach,
but
I
just
don't
see
us
even
moving
towards
settling
on
an
approach
right
now.
I
think
we're
just
continuing
to
diverge
so
maybe
like
we're
not
ready
for
a
style
guide
yet,
but
I
feel
like
we
if
we're
not
gonna,
if
we're
not
ready
for
that,
then
we
need
some
other
mechanism
of
moving
towards
converging
out
of
style.
I
D
Some
of
the
folks
in
this
conversation
took
a
crack
at
a
testing
convo
a
little
bit
ago
and
didn't
come
to
an
agreement.
I
wonder
if
we
want
to
do
something
more
formal,
where
we
have
some
examples
of
like
here's,
a
pattern.
Here's
another
pattern
there
in
conflict
have
a
have
a
talk
and
then
take
a
vote.
D
H
Personally,
I
think
an
issue
would
be
good
to
capture
this
exactly
what
the
problem
is
and
try
and
get
people
to
chime
in
yeah.
I
think
I
think
it'd
be
really
good
and
then
come
back
to
the
core,
because
I'm
pretty
sure
most
people
can't
remember
a
lot
of
the
discussions
or
thought
points
were
in
the
last
meeting
you
referred
to,
so
we
probably
lose
those
things,
and
if
we
can
get
them
down
into
an
issue,
then
it
will
help
job
remind
me,
because
it's
not
going
to
be
solved
overnight.
E
H
F
J
E
I
have
been
wherever
I
feel
like,
so
I
think
this
is
another
action
item
to
take
from
this
is
when
I
feel
like.
I
am
changing
a
style
that
has
changed
recently,
and
this
is
not
just
in
testing
but
in
code
instead
of
just
changing
it,
I
at
the
very
least
throw
something
into
the
into
the
public
chat
about
what
I'm
seeing,
but
I've
seen
no
response
to
any
of
that.
E
So
I
don't
know
how
to
drive
it
if
we're
being
averse
to
having
the
conversation
or
what
but
like
I
just
want
to
get
like,
even
if
it's
there
at
least
it's
documented.
We
can
then,
if
we
have
an
issue
for
styles
or
we've
built
up
the
contributing
guide
for
the
section
on
styles,
we
can
just
add
what
we
have
agreed
on
by
having
those
discussions.
They
can
happen
asynchronously,
as
I'm
saying
all
right
as
well.
E
I
still
think
it's
a
good
idea
to
have
an
issue
around
testing,
especially
around
anything
that
people
still
feel
is
a
major
issue,
but
I'm
just
saying
as
well.
You
see
something
you
see
it
feel
like
you're
about
to
thrash,
because
I
hate
that
feeling
more
than
doing
the
thing
I
don't
like
right.
If
I'm
like.
Oh
I'm,
just
changing
the
code
back
again,
then
I'd
throw
something
in
the
chat.
E
So
there's
an
example
of
that,
for
I
don't
like
horizontal,
slash
vertical
lists
in
var
declarations
and
there's
one
of
those
in
the
chat
just
by
ways
of
example,
right,
whether
I
like
it
or
not,
I
bring
it
up
before.
I
just
keep
on
committing
my
changes
right
or
along
with
committing
my
changes,
but
say
you
know,
this
thing
seems
to
be
a
point
of
contention.
Let's
deal
with
it,
there's
a
link
for
that,
probably
somewhere.