►
Description
Today we thought small about what we could deliver to move us closer to the vision we discussed in the Think Big portion of the discussion last week. https://www.youtube.com/watch?v=ZAAzBViRhF4
The very next step will be to create an artifact from what is already created specific to the testing group and then socialize that with Engineering Managers to validate a similar solution with their data would be an outcome that's valuable.
A
A
We
have
daniel
and
kyle
here
joining
us
to
help
us
talk
through
this.
I
put
into
the
agenda
a
quick
recap
of
last
week's
think
big.
Our
target
personas
team
leads
directors,
etc.
They
want
to
be
able
to
organize
stuff
files,
code,
business
logic
within
a
model
repo
by
their
team
or
in
some
other
logical
manner.
Potentially,
that's
what
I
got
out
of
our
discussion
and
rewatching
it
for
them
that
solves
the
problem,
potentially
of
being
able
to
block
merges
in
those
critical
paths
and
just
understand
test
coverage
code
quality.
A
Many
of
the
things
that
we
test
for
today-
and
this
is
a
differentiator
for
gitlab,
because
our
normal
structure
of
files
within
the
repo
can
be
maintained,
while
teams
can
have
a
different
view
of
what
they
own.
If
we're
breaking
this
out.
Logically,
anything
to
add
to
that
anything
that
I
missed
in
our
discussion
last
week.
A
A
It
may
need
further
iteration,
but
create
an
issue
that
the
team
can
schedule
in
an
upcoming
milestone
so
that
we
can
start
to
make
tangible
progress
towards
that
really
big
vision
and
help
daniel
and
his
folks
get
a
sense
of
code
coverage
or
test
coverage
for
their
team,
so
jumping
in.
Let's
start
with.
What
can
we
do
in
the
next
milestone
to
test
out
this
idea,
see
if
there's
legs
here
and
get
us
moving
ricky?
Do
you
want
to
verbalize
your
point?
There.
B
B
C
Yeah
I
I
was
gonna
say
I
think
I
brought
up
that
idea
in
the
slack
that
I
recall,
and
it
was
essentially
just
using
code
owners
as
a
way
to
indicate
that
ownership
and
then
filter
everything
down
by
by
the
using
group
code
ownership.
So
you
would
say,
like
testing,
owns
all
of
these
components
and
then
be
able
to
filter
the
coverage
reports
down.
Based
on
that
group
ownership,
I
think,
was
the
idea
I'll
see.
If
I
can
hunt
down
the
selector
do.
C
B
I'm
just
thinking
that,
as
a
the
only
my
I'm
wondering
about
code
owners
that
I
like,
I
don't
think
I'm
a
code
owner
anywhere,
so
I
don't
know
how
I
would
interact,
how
that
would
interact
with
me
and
how
I
would
like,
while
I'm
working,
how
I'd
connect
to
that
or
is
this
sorry,
did
I
miss
the
persona
we're
talking
about
here?
Am
I
off
base.
A
I
was
about
to
say,
that's
great
drew,
but
we
don't
care
about
you
in
this
case
I
yeah
that's.
I
realized
that
I
was
talking.
I
was
like
I
might
not
matter
at
all
you
matter
just
not
for
this
use
case
in
particular,
perfect
and
thinking
about
team
lead
or
vp,
and
thinking
about
my
team
owns
this
chunk
of
code
using
code
owners
could
be
a
way
forward
for
us
dan.
You
have
a
concern,
though,
if
you
want
to
vocalize
that
for
us.
D
Because,
currently
I
mean-
and
I
don't-
I
forgive
my
ignorance-
I
think-
is
probably
the
good
description
here
being
polite
to
myself,
I'm
not
sure
of
generally
speaking
people
in
teams
around
even
code,
they
kind
of
air
quote
on,
because
we
don't
really
own
codec
right.
I
don't
are
actually
members
of
the
kind
of
code
owners
group
anyway,
and
I
wonder
what
the
impact
that
would
be.
C
C
C
D
B
I
don't
know
of
any
other
way
to
do
it.
Yeah.
When
I
was
thinking
about
this,
I
kept
coming
back
to
the
idea
of
wouldn't
it
be
cool
if
there
was
a
concept
of
a
team
within
a
project
on
gitlab
like
the
app
like
if
there
was
like
a
team
section
that
you
could
go
and
manage
separate
from
from
groups,
but
I
think
that's
just
it's
just
like
a
it's
a
group.
D
B
Yeah,
I
was
just
I
was
thinking
about
this
as
a
as
something
we
could
potentially
do
in
a
single
milestone
is
just
configure
this
for,
like
one
segment
for
for
a
couple,
people
who
fit
the
persona
we're
looking
forward
to
to
make
sure
that
the
result
is
usable.
The
way
we
think
it's
going
to
be
do
we
is
that,
is
that
something
that's
worth
sort
of
prototyping?
I
guess
like
I'm,
putting
it
to
a
few
targeted
people
and
saying
do
you
want
this
like
are?
Are
you
using
this?
The
way
we
think
you.
A
B
A
A
B
Sorry,
the
other
thing
is
the
feature
categorization
effort
from
scalability,
like
that's
a
thing
where
they're,
attributing
controllers
and
workers
to
a
specific
feature,
and
then
those
features
are
then
attributed
to
a
specific
team
within
the
code
through
like
meta
programming.
I
don't
know
if
that's
another
thing
that
isn't
code
owners
that
might
work.
D
Yeah,
I
think
I
think,
with
that
you
still
have
to
figure
out
mapping
that
can
I
don't
I
don't
know
if
there's
like,
because
that's
sort
of
more
like
service
level
ownership.
I
think
maybe
I
just
am
getting
that
wrong.
I
I
don't
think
that's
at
that
level
to
give
us
the
full,
like
report
on
what
it
is,
what
the
code
is.
Yeah.
B
B
D
D
Otherwise
I
know
this
is
my
opinion.
Obviously
I
have
those,
but
you
know
then
it's
senior
em
going
hey
coverage
is
not
good
enough
teams.
You
know
instead
of
the
em
sort
of
being.
I
even
want
everyone
to
be
able
to
look
at
it
and
make
sense
of
it.
So
I
would
probably
go
most
smallest
unit
because
we're
talking
about
team
coverage
reports,
so
I
would
go
a
team
level
rather
than
than
senior
like
sort
of
combined
team
level,
because
then
you
still
have
to
sort
of
break
it
down.
D
A
B
B
So
what
is
that
report?
What
would
that
look
like,
because
there's
a
bunch
of
different
things
that
we
can
do?
We
could
there's
a
already
an
html
report
that
gets
generated
by
our
spec.
That
takes,
like
I,
don't
know,
five
minutes
to
load
up
in
chrome
that
has
all
of
the
files
in
it
yeah
you
can.
You
can
generate
one
of
those
that's
smaller
and
then
we
have
an
html
page.
You
can
look
at.
B
B
B
A
A
And
I'll
go
back
to,
I
think
our
end
product,
at
least
for
dan,
was.
I
want
to
see
how
the
team
is
doing
and
if
we
scope
that
down
to
an
em,
I
think
we
could
take
package
or
verify
testing
and
say
for
code
that
we're
code
owners
of
just
how
is
coverage
trending
over
time
or
what
is
coverage
even
today.
Just
show
me
what
it
is,
and
maybe
we
can
generate
a
report
this
week
and
another
report
next
week
and
just
say:
how
does
it?
How
is
it
trended
in
the
default
branch.
C
I
think
project
because
we're
talking
about
the
project
code
coverage
so
like
what,
when
I,
if
this
matters,
what
I
was
thinking
is
almost
like
in
the
ui,
you
could
just
see
a
chart
of
code
coverage
over
time
and
pick
in
a
drop
down
which
group
we're
talking
about
in
the
code
owners.
So
starting
with
the
html
reports
to
talk
about,
is
definitely
a
good
start,
but
I
think
what
seems
to
be-
and
that's
the
like
tangible
thing
in
my
mind
I
want
to.
C
E
B
C
D
Do
you
ricky,
do
you
have
a
link
to
the?
I
was
trying
to
find
the
the
attribution
that
you
were
talking
about
earlier
for
the
features,
because
that
oh,
like
yeah,
I'm
just
not
sure
I
still
am
kind
of
not
convinced
that
code
on
this
is
the
way
to
do
it.
It
might
be
the
way
to
do
it
in
like
a
really
short
term
to
go.
Here's
the
thing,
let's
see
what
it
looks
like
to
see
the
output.
B
As
far
as
far
as
code
owners
goes,
I
understand
why
that's
a
big
problem
in
the
www
repo
because
it
does
have
like
you
said
permissions
aspects,
and
only
these
people
can
merge
it
and
stuff
like
that,
but
I
don't
think
we're
using
it
that
way
on
the
gitlab
repo.
I'm
not
sure
about
that,
though,
and
I
was
I
was
I'm
like
honest
question.
B
C
Yeah,
I
I
have
some
hypothesis,
but
I
would
say
I
think,
just
test
it
out.
There
shouldn't
be
any
required
approvals
that
are
generated
in
the
get
lab
repo.
Unless
I'm
misunderstanding
things,
there
will
be
listed
of
code
owner
approvals
in
the
merge
request,
approval
widget.
Those
are
the
things
that
come
to
mind,
I'm
not
sure
if
drew
or
scott
you've
encountered
anything
that
is
different
than
that
as
you've
done
more.
Mrs
than
me
probably.
E
For
instance,
we
have
in
there
a
front
end
code
owner
kind
of
thing,
so
it
has
all
the
frontend
files,
as
you
said,
js,
and
so
when
you
make
an
edit
in
mr
to
a
front-end
file
it'll,
I
think
the
danger
butter,
whatever
it
says,
say
yes,
the
reviewer
will,
let's
suggest
a
front-end
person.
I
think
it's
just
a
suggestion
and
it's
a
bot.
So
I
don't
know
how.
C
C
Let
me
ask
the
team,
like
I
can
ask
that
during
productivity.
I
think
it's
about
a
question
daniel
your
perspective
is
spot
on
like
if
we
conflate
code
owners
to
be
more
than
just
what
someone
who's
a
user
would
think
of
code
owners
is.
We
should
maybe
stop
and
think
before
going
down
it
so
I'll,
take
the
action
to
just
run
it
by
engineering
productivity
and
see
what
the
impacts
would
be.
B
And
then
yeah,
the
alternative
that
I
was
thinking
about
is
adding
another
configuration
right
like
making
something
new.
That
seems
to
be
the
other
thing
and
I
like
I,
I'm
not
sure
that
the
feature
categorization
is
going
to
make
sense
it
it
may,
but
that
might
even
be
like
a
next
iteration,
because
that
allows
you
to
be
granular
down
to
the
method
level,
so
you're
actually
adding
specific
methods
into
that
feature
categorization.
B
A
A
D
B
Is
that
is
it
useful
for
us
to
look
at
a
smaller
version
of
exactly
what
we
have
today
or
do
we
want
to
think
about
a
new
view?
Is
that
something
that
like
we
should?
We
could
do
in
the
next
milestone
and
just
say:
does
this
become
actionable
when
we
make
it
smaller,
because
I
think
that's
something
we
could
validate
at
least
as
a
one-off
with
relatively
low
overhead
right?
It's
we
know
how
to
produce.
We
know
how
to
produce
a
smaller
version
of
exactly
what
we
have.
B
B
B
B
So
for
that,
like
you,
could
just
generate
that
by
knowing
what
files
you
care
about
in
terms
of
coverage
and
then
just
running
those
are
spec
tests,
yeah
yeah,
so
you
could
probably
do
that
locally.
If
you
had
that
list
of
files
that
your
team
cared
about,
you
could
generate
that
artifact
locally
and
then
yeah.
A
B
B
A
I
think
we
could
generate
it
for
testing
and
then
show
the
output
to
dan
or
another
em
and
say.
Would
this
be
helpful,
because
what
we
want
to
see
is
okay
by
the
end
is
the
outcome
if
it
was
applicable,
data
gonna
get
you
what
you
need
and
if
not,
then
we
can
iterate
on
what
that
outcome
is
at
least
for
the
the
small
version
of
it,
and
then
we
can
find
a
happy
path
or
a
non-code
owner's
way
to
get
that
data
or
a
better
way
to
map
the
data.
A
A
Helpful,
okay
cool,
so
I
think
it's
we'll
take
on
we're.
Gonna
generate
some
sort
of
report
for
testing
data
for
testing
features,
verify
testing,
features
to
show
code
coverage
or
test
coverage
for
what
we
care
about
we'll
socialize.
That
report
with
a
couple
of
ems
to
get
feedback
on.
Is
this
helpful?
If
not,
why
or
how
could
we
make
this
data
actionable
for
you
and
your
team
and
we
can
iterate
from
there
on
actually
bringing
that
artifact
into
the
ui
and
figuring
out
that
risky
and
hard
part
of?
A
B
A
D
Think
put
in
this
superscript
accident
only,
I
was
like
that's
not
a
fun
size
problem.
I
know
early
at
time,
but
I
did
want
to
point
out
really
quickly
on
the
category
mapping
that
ricky
mentioned.
I
already
wrote
this
out,
so
no
one
has
to
take
notes
that
mapping
to
controllers
and
and
whatnot's
already
done
and
then
the
mapping
I've
done
from
controllers
and
whatnot
two
product
categories
is
already
done,
and
then
the
product
categories
I've
already
mapped
to
groups.
D
So
whatever
we're
doing
right
now-
and
I
think
this
seems
like
a
good
plan
to
figure
out
what
the
report
would
look
like,
it
makes
total
sense
to
me,
but
I
think
whatever
we
do
going
forward,
I
would
argue
that
that
is
the
single
source
of
truth
of
team
construction
and
members
of
team
rather
than
then
having
a
separate
group
membership
that
has
to
be
updated
independently,
which
lives
in
guild
lab.
Although
we
do
that
actually
pretty
well,
because
we
use
that
all
the
time.
D
B
Yeah,
I
think
this
is
what
I'm
thinking
here
is
like
how
what
what
is
someone
else
going
to
want,
like
not
gitlab
like
what
is
some
customer
going
to
want
when
they
look
at
that?
Are
they
going
to
want
to
have
our
whole
yaml
situation
built
out?
Are
they
going
to
want
a
code
owner's
file
that
they
can
add
people
to
get
lab
groups
in
them?
So
I
think
it's
important
to
keep
that
in
mind.