►
From YouTube: CI team split ama 2020-09-17
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
All
right
thanks,
everyone
for
joining
this
meeting
is
the
ci
team
split
ama
today
is
september
17th,
so
I'll
just
set
a
little
bit
of
context
here.
There's
an
agenda
at
your
questions.
We
have
a
ton
of
questions
already,
but
the
kind
of
kind
of
like
the
high
level
context
is,
you
know,
as
we've
been
working
as
a
ci
team
for
for
several
months
now,
the
team
is
is
getting
large.
We
have
competing
concerns,
and
so
you
know
one
of
the
the
hopes
out
of
this.
A
The
split
is
to
to
try
to
provide
more
more
focus
in
terms
of
the
the
work
the
engineers
are
doing,
but
then
also
to
be
able
to
optimize
for
the
the
priorities
and
product,
because
it's
it's
hard
to
have
competing
kind
of
product
metrics
that
were
that
we're
trying
to
work
towards
in
a
single
group.
A
So
that's
that's
kind
of
the
background
context
section
I
put
the
the
sections
on
the
two,
the
two
groups
in
there
and
the
the
various
feature
areas,
and
so
we'll
just
jump
down
into
the
discussion,
and
the
first
first
item
is
for
me
and
I
decided
to
kick
this
off.
It
would
be
great
to
get
product
perspective
on
each
of
these
teams
and
some
color
on
the
vision
and
road
maps.
So
I
think,
though
you
have
the
first
first
one
in
there.
If
you
want
to
go
through
that.
C
C
A
pipeline
authoring
team
main
goal
is
to
improve
the
altering
user
experience
and
I
would
say
that
it's
also
aligned
directly
with
one
of
our
performance
indicators
that
we
measure
on
product,
which
is
time
to
first
to
first
get
build.
I'm
mentioning
that
because
it's
it's
really
important
super
critical
that
both
the
goals
of
the
product
and
goals
of
the
team
are
aligned.
This
will
make
our
work
more
focused.
It's
based
on
my
experience,
my
past
experience
when
engineers
and
product.
C
If
they
have
like
conflict
of
interest,
it
can
be
the
structure
to
the
team,
so
it's
really
good
to
see
that
both
product
and
the
team
and
engineers
see
things
eye-to-eye
in
this
team
and
in
terms
of
the
focus
of
the
team.
I
know
that
in
the
handbook
it
is
mentioned
the
priority,
but
it
is
not
a
prioritized
list.
C
It's
just
like
something
that
we
created
this
morning
that
we
believe
is
the
main
focus
that
we
will
work
on
that
and
it
won't
be
in
this
order
and
so
to
start
with
making
sure
it's
easier
to
start
with
different
kinds
of
pipelines,
for
instance
like
a
mobile
application,
improving
the
way,
our
templating
documentation
and
more
and
the
second
one
is
improving
the
linter
and
the
integration
with
edit.
C
We
have
this
issue
where
we're
debating
whether
we
go
with
the
web
ide
or
the
editor
like
this
is
exactly
what
the
team
is
looking
for
as
we
proceed
to
our
next
to
our
roadmap.
So
once
we
get
settled
on
that,
we'll
work
closely
on
how
we'll
integrate
better
with
this
editor,
obviously
give
smart
feedback
errors
and
warnings
to
our
users,
all
in
helping
them
to
reduce
the
learning
curve
and
helping
them
to
get
their
first
pipeline
and
the
third
one
is
implementing
the
pipeline
visual
builder.
This
is
to
help
our
user
experience.
C
I,
for
this
will
be
one
of
the
primary
features
we'll
be
focused
on
throughout
this
year,
and
so
I
have
to
say
that
this
is
something
that
is
very
similar
that
myself
and
nadia
the
ux
designer
work
on
on
the
apm
team.
So
we
have
some
experience
on
how
to
build
something
similar
and-
and
lastly,
is
the
improvement
of
the
keyword
on
on
our
ci
yaml
file.
So
we
want
to
make
it
easier
but
flexible
for
our
users
to
to
configure
it.
So
we
added
some
examples
in
the
handbook
like
additional,
adding
additional
rules.
C
Keywords
such
as
needs
and
metrics,
and
so
obviously,
all
of
those
improvement
to
the
ciaml
file
is
a
part
of
this
team
and
yeah.
As
I
mentioned,
go
to
the
the
handbook
read
all
that,
and
obviously,
if
you
have
more
questions,
feel
free
to
thank
myself
or
json
or
just
ask
a
question
in
the
team
channel
back
to
you,
tom.
D
I'll
just
jump
in
real,
quick
and
just
add
on
to
that
thanks
dove.
For
I
mean
I
think
getting
all
that
information
in
the
handbook
is
super
useful
and
I
just
wanted
to
kind
of
underline
for
people
what
dove
said
about
the
time
to
first
green
pipeline
being
a
really
key
metric,
and
I
think
a
really
key
way
to
understand
like
why.
Why
is
the
split
happening
that
obviously
everybody
knows
here?
D
D
D
Why
is
everybody
quiet
and
listening
to
me
if
I'm
muted,
I
was
just,
I
think,
trying
to
underline
how
important
verify
is
to
kind
of
the
customer
adoption
journey
and
that
the
more
people
use
ci
the
more
likely
they
are
to
become
ultimate
customers,
whereas
if
they,
if
that
stays
flat,
they
tend
to
turn
out,
and
so
it's
this
really
key
adoption
metric
in
that
time
for
time
to
first
green
build.
D
Obviously
it's
very
important
to
that
experience,
and
so
you
know
I
think,
in
the
I
haven't
been
as
close
to
the
team.
Obviously,
but
I
think
in
the
past
you
know
it's
been
hard
to
prioritize
juggle
both
of
those
things
and
this
you
know
with
dove
and
his
experience
coming
from
apm
and
nadia
as
well.
You
know
we
are
able
to
really
focus
on
prioritizing
that
so
just
wanted
to
underline
that
before
we
move
on.
E
A
Yeah,
I
think
if
anyone
has
any
immediate
questions
we
can
we
can
do
those.
I
want
to
make
sure
we
we
get
to
get
through
everything,
but
I
don't
want
to
lose
stuff
in
the
threads,
because
I
know
there's
a
lot
going
on
so
is:
does
anyone
have
anything
that
they
would
like
clarification
on
or
any
additional
questions
for
dove.
F
I've
got
one
on
number
point
number
one,
making
it
easier
to
get
started
with
more
kinds
of
pipelines:
eg
the
mobile
app.
F
C
Yeah
we
linked
it
on
the
handbook,
but
it's
more
like
providing
more
examples
without
templating
capabilities
around
different
mobile
application,
different
data
data
pipeline
configuration
and
stuff
like
that
it
is
possible
today
and
but
we
won't
likely
want
to
improve
the
documentation
and
the
templates
that
we
provide
to
our.
E
Yeah,
the
thinking
you
made,
I
think,
is
right,
sam
any
other
questions
for
dove
by
the
way,
hats
off
to
dove
and
jason
for
getting
the
three-year
vision
written
overnight.
They
put
like
tremendous
pressure
on
me
because
I
don't
have
that
out
there
yet,
but
I'll
work
on
that
this
week.
Okay,
so
for
ci,
the
easy
way
you
can
think
about
this
is
the
way
these
two
groups
are
being
divided
is
based
not
just
on
the
product
perspective,
but
on
the
user's
perspective
right.
E
It's
it's
pipeline
authoring
is
a
subset
of
what
was
ci,
which
is
the
distinct
activity
that
the
user
would
need
to
start
with
first
and
be
successful
with
before
it
opens
up
everything
in
ci,
and
so
ci
is
everything
after
they've
authored,
whether
first-time
users
of
the
pipeline
authoring
or
a
really
advanced
user.
That's
going
into
a
lot
of
rules
and
bridge
pipeline
configurations
once
all
of
that
is
in
place,
then
the
rest
of
what
happens
that
the
interaction
with
pipeline
is
under
ci.
E
So
what
I
did
here
was
just
really
briefly
touch
on
the
things
that
are
the
three
areas
that
I
want
to
focus
on.
That
is
going
to
find
its
way
into
my
three-year
vision,
update
to
my
direction
page
so
what's
written
there
is
ci,
is
about
interacting
with
with
and
running
already
interacting
with
pipelines
that
are
have
runners
already.
E
The
details
after
they've
ran
someone
put
those
notes
there.
I
wasn't
quite
sure
what
the
rest
of
that
means
as
far
as
performance
execution
up
to
the
runner.
The
three
areas
I
want
to
focus
on
for
ci
team
is
improving
the
interaction
with
pipeline.
I
tried
to
list
out
the
feature
labels
of
the
issues
that
would
be
relevant
to
that,
so
making
it
easier
to
set
configurations
for
finding
a
pipeline,
so
that
has
everything
to
do
with
setting
and
managing
variables
permissions
and
the
part
of
merge
requests.
E
That
is
behavior
impacted
by
our
ci
settings,
because
we
know
the
source
code
team
is
generally
responsible
for
merge
requests,
but
there
are
things
that
we
do
in
ci
that
impacts
that
mercy
request
behavior
and
we
would
own
that
work
as
far
as
making
it
easier
to
run
a
pipeline.
E
And
then
there
are
things
that
happen
after
a
pipeline
has
ran
and
when
I
want
to
make
it
easier
to
to
access
or
manage
those
things,
some
of
the
things
being
artifacts
the
pipeline
graph.
There
is
a
we
could
debate
the
the
label
there
for
ci
graphs
and
analytics
there's
a
question
that
fred
has
later
under
the
discussion.
E
But
I,
when
I
was
trying
to
carve
out
some
distinct
areas
within
the
label,
ci
interactions
which
had
over
a
thousand
issues.
I
saw
that
there
were
some
recurring
themes
about
wanting
to
see
analytics
and
wanting
to
see
certain
things
in
the
graph
that
make
them
understand
what's
happening.
E
E
The
second
area
that
I
want
to
focus
on
with
the
ci
team
is
providing
features
for
analyzing
our
pipeline
performance.
There
is
a
group
of
persona
that
I
don't
think
we
have
given
the
tools
and
features
for
them
to
look
at
pipeline
from
an
overall
perspective
of
how
it's
doing
it
would
be
the
engineering
manager
of
a
team
or
even
director
of
engineering
that
would
want
to
see
the
patterns
and
the
places
where
pipelines
can
be
optimized,
so
they
would
want
to
look
at
data
and
job
durations
failure
rates.
E
Any
data
about
a
pipeline
has
ran.
I
those
are
features
that
I
think
we
can
also
target
for,
for
example,
an
ultimate
tier,
which
I
don't
think
we
currently
have
a
lot
of
ci
features
and
ultimate
or
paid
vici
features.
So
I
want
to
drive
some
of
that
through
this
area
of
focus,
and
then
the
third
thing
that
I
think
is
assumed
under
both
teams,
but
I
did
want
to
call
it
out-
is
I
really
want
to
make
a
concerted
effort
to
address
those
issues
that
are
impacting
usability
of
our
existing
future?
E
I
want
to
make
more
emphasis
on
fixing
those
bugs
addressing
those
tech
debt
that
make
our
existing
features,
either,
not
usable
or
not
usable
at
all
or
reduces
usage,
because
there's
just
it's
just
problematic
and
there's
too
many
workarounds
that
our
users
have
to
to
make
in
order
to
use
the
existing
features.
I
think
ux
debt
and
ui
ui
polish
also
lends
itself
to
making
existing
features
more
usable,
and
I
know
the
recent
change
of
direction
that
product.org
was
given
what
product
managers
were
given
is
to
prioritize
usability
over
new
features.
I
I'll
go
ahead,
okay,
so
yeah!
I
wanted
to
talk
about
which
metrics?
Would
you
consider
important
for
this
site
as
similar
to
the
time
to
first
screen
deal
in
authoring,
which
would
be
the
metric
that
you
would
chase
for
for
users
of
the
ci
side?.
E
I
think
we
have
an
issue
dove
that
jason
opened,
that
is,
to
instrument
how
we
would
measure
time
to
first
green
build.
I
don't
know
the
status
of
that
one
is
that,
is
that
me
going.
D
E
Oh,
so
that's
a
really
good
question
I
haven't
been
able
to
think
through
because
we
one
of
the
things
that
we
have
for
the
stage
metric,
which
is
unique
users
triggering
a
pipeline.
E
So
that's
one
of
the
metrics
that
we're
tracking
is.
Is
it
easy
for
a
user
to
trigger
that?
I
would
want
to
work
on
is?
Are
the
things
that
I'm
working
on,
make
it
easier
for
users
to
trigger
a
pipeline,
because
if
authoring
is
about
making
a
pipeline
exist,
the
rest
of
interaction
is
I'll.
Give
you
a
clear
example:
miguel.
E
One
of
the
issues
that
is
planned
for
13.5
is
to
pre-fill
the
manual
the
run
pipeline
form
with
the
variables
from
the
yaml
file.
That
would
make
it
easier
to
trigger
the
pipeline,
and
so
that
would
fall
under
interaction
because
there's
an
existing
pipeline,
it's
hard
to
trigger
it,
because
there's
so
many
variables
you
have
to
manually
enter,
but
that
issue
would
address
that
and
that's
in
13.5.
That's
a
good
example.
F
The
one
that
the
question
I
was
going
to
ask-
I
was
just
wondering
so
on,
let's
see
be
to
provide
features
for
analysts
of
pipeline
performance
and
patterns.
Example,
data
on
job
duration
and
failure
rates.
I
was
kind
of
wondering
like
so
what's
like
products
idea
for
that
is
that
to
like,
maybe
have
like
a
a
separate
view
that
users
can
like
view
granular
data.
Is
that
like
a
personal
dashboard
for
them,
or
is
this
still
like
kind
of
up
in
the
air
on
what
like
products
idea
for?
This?
Is.
E
So
I
we
don't
really
have
to
design
for
the
solution
for
that
yet
peyton,
I
don't
think
that's
an
area
that
we've
invested
in
that
I'm
aware
of
in
the
past,
and
so
it's
kind
of
green
field.
For
me,
right
now,.
F
Yeah
agreed,
thank
you.
I
think
that's
a
really
interesting
point
for
ci.
E
Hey
miguel,
by
the
way
I'm
gonna
find
in
the
agenda
notes
there,
where
I'm
highlighting
the
unique
user
string
and
pipeline
there
is
already
a
performance
indicator
for
that
and
I'll
I'll
find
that
handbook
page
and
link
to
it.
So
I'll
turn
that
into
a
link.
You
can
look
at
that.
That
is
a
metric
that
we're
measuring
now.
A
Oh
I'll
take
I'll
take
that
one
and
I
know
we're
we're
getting
close
to
the
scheduled
time.
I
think
we
can
just
go
over
because
we
have
a
pretty
long
agenda
here
and,
if
folks
need
to
drop
this
is
being
recorded
and
I'm
happy
to
follow
up
with
anyone
off
after
after
this
meeting
today.
If
anyone
wants
to
chat
about
anything,
my
schedule's
fairly
open
so
point
two
on
here.
It
was
a
comment
from
jason.
A
He
was
interested
in
the
the
sort
of
technical
analysis
that
we
did
on
the
team
split,
and
I
linked
a
bunch
of
things
in
here
that
I
kind
of
worked
on
over
the
last
few
months
and
to
to
provide
a
little
bit
of
a
backstory
to
some
people
who
have
who
are
maybe
new
to
the
team
or
just
weren't.
Aware
of
this.
A
few
months
ago,
ci
was
was
was
one
bucket.
A
We
put
all
of
our
issues
into
one
category
label
or
one
group
label
and
that
that
count
was
3500
or
something
like
that
and
that
was
bugs
and
features
and
and
it
became
clear
that
we
needed
to
get
a
bit
more
granular
with
it.
So
the
first
first
item
I
linked
here
was
the
first
pass
at
doing
this,
so
we
just
kind
of
like
started,
bucketing
things
and
and
we
sort
of
iterated
from
there.
A
So
this
is
kind
of
how
we
got
from
one
area
of
things
to
more
things,
which
is
where
we
are
today.
So
it's
it's
it's
it's
hard
to
take
this
big
pile
and
sort
of
break
it
down.
A
So
then,
as
we
as
we
went
through
that
the
other
other
issues
here
are
just
around
how
we've
been
tracking
technical
debt
and
bugs-
and
this
is
this-
is
sort
of
the
the
focus
for
this,
which
is
because-
and
I
wrote
this
in
here
like
focusing
on
tech,
debt
and
bugs
is-
is
important
from
the
engineering
side,
because
these
are
things
that
distract
the
team,
that
that
make
it
harder
for
us
to
be
predictable.
And
so
this
is.
A
At
things,
and
you
can
kind
of
see
the
different
issues
or
spreadsheets
in
there
and
then
there's
also
the
stale
bugs
cleanup
initiative
that
we
went
through,
which
was
something
that
quality
helped
with
to
try
to
get
rid
of
stuff.
That
was
old
because
we
found
issues
that
were
like
here's
a
bug
from
four
years
ago
that
no
one's
ever
commented
on
since
then.
We
probably
don't
need
to
keep
that
open
and
track
it.
So
so
we
cleaned
up
a
bunch
of
stuff
there
too.
A
So
I
think
that
kind
of
is
the
back
background
there
and
jason
asked
for
my
recommendations
and
based
on
kind
of
what
I've
seen.
I
think
I
wrote
the
things
that
I'm
I'm
recommending
here.
A
First
thing
is
optimized
for
the
key
metrics
the
business
is
focused
on
future
gmail
is,
is
a
thing
we're
talking
about
a
lot
if
you,
if
you
weren't,
able
to
attend
a
group
conversation
yesterday,
the
ops
group
conversation
there's
there's
some
good
discussion
there
with
sid
and
kenny
about
about
this
and
how
we
think
about
it
and
future
gmail
is
future
group
monthly,
active
users.
So
we
we
look
at
where
we
think
we
will
see
the
best
return
on
our
investment
in
terms
of
future
development
and
focusing
on
this.
A
This,
like
increase
of
group
monthly,
active
users,
this
kind
of
goes
to
what
sam
said,
which
is:
if
we,
if
we
get
people
into
ci,
we
know
that
they're
more
likely
to
continue
with
git
lab
and
use
other
other
components
of
git
lab.
So
so
focusing
on
that
is
sort
of
like
the
the
top
level
thing.
I
want
our
teams
to
organize
so
that
we
can
execute
independently
and
holistically
own
customer
facing
features,
so
this
whole
thing
that
we're
working
on
we
should
be
able
to
to
own
the
customer
experience
for.
A
I
think
this
means
this.
This
means
it's
easier
for
product
and
ux
to
to
work
and
think
about
the
whole
thing.
The
whole
experience
with
the
customer
and
and
not
have
to
like
hand
off
between
different
groups
and
then
where
we
are
today,
is
just
to
start
we'll
learn
more
as
we
start
working
this
way,
and
then
I
said
I
would
optimize
for
moving
or
better
defining
future
areas
over
moving
folks
around
teams.
So
I
don't
want
people
to
be
shifting
teams.
A
I
would
rather
say
like
we
think
this
thing
should
move
over
here,
or
this
thing
maybe
needs
to
be
better
defined
and
and
and
we
can,
we
can
do
that
as
we
as
we
get
into
it
a
little
bit
more.
So
that's
kind
of
the
the
recap
there
does
anyone
have
any
questions
specifically
related
to
that.
G
G
So
my
first
question
was
in
terms
of
the
cia
graph,
which
I
saw
was
it
was
kind
of
split
in
between
ordering
nci
and
kind
of
like
it
was
starting
in
the
category
and
moving
to
another
and
to
me
that
makes
not
really
a
lot
of
sense
because
well,
first,
the
graph
is
a
representation
of
your
pipeline
and
so
making
that
being
owned
by
other
rings
to
me
makes
more
sense
and
that
the
ci
group
or
interaction
would
use
that
graph
and
add,
as
an
extension
statuses
and
like
things
that
he
didn't
care
about.
G
But
the
basic
of
the
graph
would
make
more
sense
to
be
owned
by
one
group
and
then
one
just
build
their
extension
on
top
of
it,
and
if
one
has
to
own
it,
then
it
makes
more
sense
for
honoring,
and
I
I've
made
my
whole
point
in
in
the
issue
that
I
have
linked
in
the
agenda.
But
for
this
recording
I
can
go
over
quickly
and
it's
just
like.
Even
for
a
back-end
perspective.
G
It
would
be
weird
that
the
back-end
of
other
on
the
graph,
but
then
the
front-end
of
interaction
like
our
ci,
owns
this
graph,
and
then
it
becomes
a
constant
crossteam
collaboration
and
also
one
the
big
advantage
of
having
one
team
own
more
like
like
one
all
in
the
same
piece
of
code
is
better
and
two.
The
othering
team
seems
more
oriented
toward
graphical
visualization,
which
means
that
you
can
build
an
expertise
of
people
who
write
graphical
visualization
for
a
living.
And
then
you
don't
have
to
split
that
and
then
collaborate
all
the.
G
E
I
don't
think
it
was
ever
intended
that
in
the
example
you
escaped
when
you
summarized
your
comment
there,
I
don't
think
it
was
ever
intended
that
if
authoring
team
created
the
feature
to
modify
your
yaml
file
through
the
graphical
representation
that
another
team
would
own
the
front
end
part
of
it,
it
would
all
be
one
team
owning
that
feature
in
the
same
way
that,
if
we're
making
a
change
to
merge,
request
behavior,
because
a
ci
setting
affects
it,
we
would
own
that
entire
feature.
E
G
So
but
the
graph
we're
building
for
the
yaml
is
going
to
be
used
in
the
term
like
in
couple
of
milestone,
will
be
used
by
the
the
ci
team
to
show
the
status
of
the
running
pipeline
job,
and
so
there
was
talk
of
like
then
do
we
transition
that
graph,
because
it's
in
the
running
state,
but
then
the
choreograph
would
be
the
same,
and
so
one
team
has
to
own
the
core
and
one
has
to
build
extension
for
it.
G
E
J
Been
saying
that
like
over
and
over
and
over,
but
I
just
wanted
to
double
up
on
fred's
thing
that
it's
been
architected
to
work
that
way
so
it's
sort
of
under
flight
in
that
structure.
So
I
do
think
this
is
a
really
good
point.
E
Maybe
maybe
we're
thinking
of
two
different
things:
sarah,
I
know
that
you've
been
saying
that
the
work
like
that
was
being
done
to
visualize.
The
dag
would
eventually
be
built
into
our
current
standard
pipeline
graph
view.
I
did
not
so
I
understand
that
part
that
that
that
work
on
the
dag
will
find
its
way
there.
I
did
not
know
that,
and
maybe
we
were
talking
about
two
different
things.
E
F
J
No,
that's
just
that.
We
don't
need
to
get
into
the
deals,
but
yes,
it's
doing
that
because
we
needed
to
rewrite
the
thing
and
so
the
way
to
rewrite
the
thing,
while
also
continuing
to
get
work
done
on
some
of
the
features
we
want
to
do.
Is
this
method
but
and
like
that's?
The
way
it
should
work
is
that
it
should
be
the
same
graph.
D
And
I'll
just
jump
in
there
and
say
thanks
for
watching
out
for
that
kind
of
thing,
because
I
think
that
will
most
likely
be
common
in
this
type
of
split.
I
mean
this
team
has
split
multiple
times
before
many
teams
have
so
I'm
sure
some
of
you
have.
You
know
experienced
that.
D
But
you
know
this
is
really
about
being
able
to
break
acro
apart
those
goals
and
focus
around
time
to
first
green
versus
you
know
the
rest
of
ci
and
and
there's
going
to
be
lots
of
details
where,
like
then
at
a
technical
level,
you
know
you
probably
say:
oh
well,
these
things
aren't
that
easy
to
separate.
Maybe
on
those
lines,
as
you
know,
maybe
it
seemed
from
a
different
level,
and
I
think
that's
really
where
we
need.
D
You
know
smart
engineers
like
looking
at
that
thinking
about
it,
and
you
know
we
can
over
time
shift
things
around
or
continue
to
evolve
things,
but
but
yeah.
It's
really
important
that
we're
watching
for
that
and
avoiding
as
much
as
we
can
cases
where
in
order
for
one
team
to
do
something,
the
other
team
has
to
do
something
and
that
gets
just
kind
of
complicated
to
manage
and
usually
slows
things
down.
So
that's
the
goal.
G
Well,
I
mean
we,
we
talked
about
how
we
don't
know
but,
like
I
think
I
think.
Essentially,
if
is
no
strong
objection.
It
seems
even
in
the
comment
that
most
people
agree,
that
it
should
be
owned
by
pipeline
authoring
period,
and
then
the
ci
team
would
use
that
graph
and
like
collaborate
to
like
how
they
integrate
with
each
other.
But
the
graph
should
be
owned
by
othering
and
not
by
ci.
G
G
So
in
the
term
of
how
we
did
the
split,
there
was
one
thing
that
I
was
curious
about
about:
why
we
did
it
this
way
and
it's
where
to
me,
I
was
expecting
the
split
to
be
centered
around
yes
pipeline
ordering
versus
interaction
of
the
ci,
but
also
a
bit
higher
level
of
where
part-time
ordering
will
also
include
anything.
That's
about
metadata
and
the
reason
why
I
was
thinking
that
and
miguel.
G
I
think
like
summed
that
up
pretty
well
in
this
comment,
where
we're
targeting
different
user
groups,
so
the
person
who
will
be
targeted
by
pipeline
ordering
is
someone
who's
more
in
devops
or
like
organizational
and
they're
structuring
their
data,
and
they
want
they
care
about
metadata
they
care
about
how
efficient
is
their
pipeline.
How
many
minutes
is
our
being
runs?
G
And
then
the
ci
group
focus
on
like
your
daily
running
the
pipeline
and
here's
what
you
need.
What
it
doesn't
mean
you
don't
have
access
to
information
or
statistics,
but
it
should
be
more
like
you,
like
your
pipeline,
what's
happening,
what?
How
is
my
code
running
not
like
here's,
the
organizational
information
so
to
me
that
should
move
to
othering,
but
obviously
we
can
have
that
conversation
now
and
see
if
that
makes
sense.
E
Hey
fred
on
the
on
the
ci
graphs
and
analytics
bucket
of
issues
I
actually
had.
I
actually
at
one
point
had
it
as
ci
graphs
and
then
ci
analytics
separately,
and
when
I
was
done
labeling
some
of
the
issues
they
were
such
small
buckets
that
I
thought
I
made
one
too
small,
but
I'm
beginning
to
think
that
those
are
two
unrelated
things
under
that
label.
The
analytics
is
not
something
that
you're
wanting
to
have
as
part
of
authoring,
but
the
graphs
you
would
so
that's
one
way
that
we
can
address
this.
G
I'm
curious,
though,
because
like
analytics,
it
depends,
I
think,
maybe
analysts
can
like
compound
multiple
things
as
well.
So
maybe
that's
why?
Because
for
me
it's
even
like
the
your
average
number
of
of
runtime,
for
example
like
hey
this
month
and
this
project
you
have
like
500
minutes
of
runtime.
That
happened.
I
think
that
should
be
uttering
as
well,
because
you're
seeing
the
metadata
of
the
project,
it's
the
label,
that's
confusing,
because
then
we're
telling
authoring
versus
ci
so
we're
like
well.
G
This
is
ci
because
it's
a
number
of
runtime,
but
I
think
the
labels
are
confusing.
I
think
the
pipeline
authoring
is
more
about
because
even
pipeline
ordering
is
about
metadata.
It's
about
the
structure,
the
architecture.
So
what
for
me
it's
like
one
is
about
architecture
of
ci
and
the
other
is
about
execution
of
ci,
and
I
think
that's
where
this
get
might
get
confusing.
But
that's
that's
how
I
saw
it
because
it
to
me.
G
It
makes
sense
that
the
team
that
owns
the
the
pipeline,
editing
and
the
metadata
and
like
here's,
we're
targeting
the
people
who
are
going
to
write
the
architecture
of
this
project
and
we're
going
to
give
them
all
the
information
they
need.
And
then
ci
targets
the
engineers
and
the
people
who
run
the
pipeline
and
that
that
needs
the
artifacts
and
all
that
kind
of
stuff.
E
Except
that
ci
is
intended
for
more
than
the
engineers.
It's
also
intended
for
personas
that
are
outside
of
the
team
that
maybe
is
managing
I'm
optimizing
performance
across
projects
across
across
groups.
They
would
be
the
ones
that
would
also
we
that
would
be
a
persona
that
we're
targeting
in
ci
to
service
with
analytic
tools
and
features.
G
G
If
you
want
to
optimize
your
pipeline
you're,
going
to
go
edit,
your
your
lambo
file
right,
you
can't
optimize
your
pipeline
by
just
running
the
pipeline.
You
need
to
go
in
the
yaml
file
and
change
the
needs,
job
or
change
the
architecture
of
how
your
pipelines
are
running
or
add
a
new
job,
so
that
falls
in
bothering
because
you're
optimizing,
and
so
that
would
mean
that
ci
no
longer
targets
the
people
who
optimize
the
bill.
That
would
be
all
the
room.
E
I
think
just
because
you're
making
use
of
the
data
you
get
from
the
analytics
feature
doesn't
mean
that
you
need
to
be
the
one
building.
Those
features,
though,
that
expose
the
analytics
an
author
of
a
pipeline.
I
have
to
think
about
that.
Yeah.
D
I
have
a
clarifying
question
that
I
think
is
kind
of
embedded
in
in
fred's,
and
I
think
is
maybe
the
next
question
also,
but
does
this
split
represent
a
split
in
personas?
I
hadn't
necessarily
thought
that
that
was
the
case
like
are
these
teams
targeting
different
users
or
are
they
just
targeting
different
parts
of
the
experience?
For
you
know
largely
the
same
users.
E
I
think
it's
targeting
the
experience
of
how
they
use
our
how
they
around
just
ci
in
general
and
pipeline,
but
there
is
a
question
later
in
the
agenda
of
what
is
the
primary
personas
targeted
for
each
team.
I
think
it's
miguel's
question
number
one.
D
It's
basically
the
same
question.
I
think
it's
the
next
question
my
question
too,
but
miguel,
maybe
you
should
voice
it.
I
keep
talking
over
physio
sorry.
I
E
I
I
I
guess,
can
you
hear
me?
Yes,
I
I
guess
the
reason
I'm
asking
is
because
I
would
like
to.
I
would
like
to
know
more
about
what
each
of
the
teams
are
going
to
focus
on.
It
makes
it
easier
for
me
to
understand
what
the
work
is
going
to
be
about,
if
I
can
think
of
a
bit
more
about
who
are
the
target
users.
I
A
So
can
I
make
a
suggestion?
I
I
think
I
think
in
this
this
sort
of
discussion
it
could
be.
It
could
be
helpful
to
do
a
follow
up
with
product
to
to
maybe
more
clearly
clarify,
like
you
know
like.
A
I
think
we
have
a
lot
of
user
personas
and
these
these
features
kind
of
hit
all
of
those
folks,
but
there's
there's
probably
going
to
be
one
type
that
is
more
prominent
than
another,
and
and
so
so
perhaps
what
we
can
do
is
is
go
back
and
and
work
to
better
clarify
the
the
personas
and
kind
of
the.
A
I
don't
know
some
some
like.
Maybe
there's
a
couple
issues
here.
Maybe
there's
one
about
personas
and
there's
one
about
fred's
earlier
question
about
the
like:
the
visualization
ownership
and,
and
so
we
could
we
could
take.
We
could
take
those
on
as
follow-ups
and
maybe
just
open
issues
for
those
or
mrs
to
to
clarify
that.
Does
that
make
sense
to
you
tao?
A
Does
anyone
else
have
have
other
suggestions
on
how
we
can
handle
that?
I
think
this
is.
This
is
probably
like
a
a
more
in-depth
conversation
and
we
want
to
make
sure
that
we
can
kind
of
like
drive
to
those
conclusions
that
way
without
trying
to
kind
of
rush
something
in
a
sinkhole.
K
Okay,
I
actually
have
some
points
of
suggesting
later
on,
related
to
to
say
similar
points,
but
yeah
we
can
go
later
on:
okay,
okay,.
D
Yeah
does
that
go,
I
think
that
makes
sense,
but
but
that
we
shouldn't
not
ask
the
question
that
all
this
stuff
should
make
sense.
I
think
the
you
know
key
point
in
terms
of
like
how
do
we
get
excited
about
this?
How
do
we
really
like
want
to
work
on
this
stuff?
Is
you
know,
understanding
the
vision,
understanding
like
why
it
matters?
D
You
know
why
it's
helping
you
know
developers
helping
people,
so
you
know
we
probably
don't
have
time
to
get
to
the
bottom
of
that
on
every
you
know
every
point
here,
but
but
you
know
that
that
work
should
continue.
I
think.
B
F
Oh
yeah,
thank
you
for
making
sure
that
got
said
yeah.
So
this
is
more
of
like
a
label
thing
like
that
kind
of
ties
with
ci
graphs
and
analytics.
F
I
kind
of
think
wherever
ci
graphs
and
analytics
is
ci.
Dag
should
follow
the
group,
and
even
maybe
we
can
tie
that
together
in
one
label.
F
Ci
graphs,
I
mean
the
ci
graphs
and
dag
are
pretty
tightly
coupled,
but
and
let's
just
kind
of
just
use
for,
like
tracking
purposes,
to
see
how
many
issues
we
have
for
dag
versus,
like
the
normal
hybrid
graph,
I
think
kind
of
like
if
I
haven't
been
working
in
ci
for
a
while,
like
coming
out
and
in
I
would
expect
gag
to
fall
into
a
graph
category,
because
it
is
a
visualization
in
a
graph.
E
I
agree
with
everything
you
said
peyton.
I
think
one
thing
that
I
would
need
to
create
a
separate
feature
label
for
is
included
currently
in
that
ci
graph
and
analytics
there's
two
kinds
of
reference
of
graphs,
the
graphs
of
our
pipeline
and
then
graphs
that
are
showing
unrelated
to
pipeline
per
se.
It's
just
showing
data
about
ci
in
general.
A
Okay,
so
I
think
I
think
we
can
capture
this
as
part
of
the
follow-up.
Is
that
that
makes
sense
not
that
I
want
to
cut
this
off.
I
want
to
make
sure
we
get
to
everything.
So
miranda
had
a
point
on
here.
If
we're
okay,
with
jumping
ahead
naming,
is
hard.
Have
we
considered
other
name
pairs
for
the
two
categories,
to
make
them
more
messy
foo
and
there's
a
link
there
to
what
that
means.
I'm
splitting
ci
into
authoring
nci,
but
those
two
ucis
don't
mean
the
same
thing.
A
A
E
So
now
that
there
is
a
separate
pipeline
authoring
group,
you
may
not
even
need
that
it
now
also
has
its
own
backlog
and
you
wouldn't
need
to
have
that
ci
authoring
scoping
label
to
distinguish
that
as
a
backlog.
For
that
team.
Does
that
make
sense?
We
probably
need
to
just
clean
that
up.
G
And
I
think
also
for
the
other
one,
the
first
one.
It
means
that
ci
and
pipeline
ordering
might
be
inherently
bad
naming.
Maybe
it's
like
pipeline
ordering
and
pipeline
interaction.
I
don't
know
but
like
having
one
key
being
ci
means
that
one
has
a
global
name,
so
everything
can
fall
in
ci
by
default.
If
you
just
think
of
the
name,
because
our
planet
othering
is
part
of
ci,
so
it
feels
like
ci
is
like
the
encompassing
group
and
then
it's
gonna
be
harder
to
kind
of
just
map
visually
like
okay.
This
is
this.
B
F
Yeah,
technically,
that's
how
it's
happened
in
the
past
when
we
did
our
first
split
when
we
split
from
just
everything
to
ci
and
then
to
testing.
It
was
just
like
completely
like
out
of
ci.
At
that
point,.
G
Yeah
testing
is
not
ci
right,
like
they're,
not
related,
like
you
can
understand
why
they
touch
multiple
areas
of
the
platform,
but
pipeline
ordering
is
just
part
of
ci
right.
It's
helping
you
build
continuous
integration,
so
maybe
in
this
sense
it
makes
little
sense.
I
don't
know
like
maybe
ci
has
to
become
a
group
like
encompassing
group,
and
then
you
have
two
subgroups
like
I
don't
know,
but
it
I
think
it
will
be
confusing.
G
H
E
Now
it
is
going
to
be
verify
pipeline
offering
you
can
see
from
the
direction
page
at
the
top
with
the
agenda
to
the
path
there
is
verify
pipeline
authoring
yeah.
I
I
hear
what
you're
saying
fred,
maybe
part
of
it
is
also
for
us
to
get
used
to
the
idea,
because
I
think
I
could
see
the
same.
E
G
Well,
the
only
option
would
be
to
have
sub
groups,
but
if
that's
a
concern
it
would
be
ci
pipeline
of
the
ring
and
ci
something
else.
And
then
that's
it
like
you.
You
have
this.
You
still
have
ci,
but
you
have
subdivision
and
then
we're
different
group,
but
we
both
work
in
ci.
Just
because
it's
true
right,
we
both
testing,
is
different,
like
I
said,
because
they
don't
just
work
in
ci
anymore.
G
They
split
because
they
had
other
it's
just
testing
in
general
and
that's
they
plug
in
ci,
but
they
plug
on
other
things
as
well.
They're
in
merge
requests,
but
part-time
ordering
you're
not
going
to
be
in
merge
requests
you're
not
going
to
be
in
another
part
of
the
application.
But
at
this
point
we
can
take
that
offline
and
continue
the
discussion
somewhere
else.
D
D
D
There's
a
lot
to
do
there
there's
a
lot
of
you
know:
people
reporting
bugs
people
using
it
people
depending
on
it,
and
so
you
kind
of
end
up
with
what
maybe
sometimes
feels
like
a
grab
bag
of
like
things
that
need
worked
on,
I
think,
with
pipeline
authoring,
you
know:
we've
the
pms
have
done
a
great
job
of
kind
of
articulating.
Well,
here's
a
subset
of
that
that
can
be
focused
on
that's
important.
D
It's
really
around
this
time
to
green
and
that
authoring
experience
I
think,
ci
ci
is,
you
know,
verified
ci
is
still
a
little
bit
it
not
not
necessarily
like.
We
have
to
fix
it
right
now,
but
it's
a
little
bit
more
nebulous.
You
know
like
it's
not
as
chris.
You
know.
We
all
know
what
ci
is,
but
in
terms
of
what
is
this
group
you
know
of
people
like
what's
the
kind
of
mission?
D
What's
the
charter,
you
know
that
it's
it's
still
a
little
fuzzy
and
I
think
that's
being
worked
on
and
you
know
that
it
might
make
sense
at
some
point
to
say:
well,
it's
not
a
ci
team,
it's
something
else,
but
of
course
naming
is
hard
and
you
know,
and
and
the
real
goal
is
to
you
know,
be
able
to
ship.
You
know
ship
valuable
stuff,
improve
the
product,
not
necessarily
come
up
with
the
the
perfect
team
structure.
D
A
So
fabio
has
been
waiting
patiently
to
bring
up
his
comments,
so
I
want
to
make
sure
we
get
to
those
too
so
fabio.
Do
you
wanna
you
wanna
jump
in.
K
Yeah,
so
thank
you
so
I
I
have
yeah
some
comments
and
suggestions
at
the
same
time.
So
so
I
noticed
that
the
way
we
are
splitting
the
team
we
have
in
one
side
we
have
pipeline
authoring
and
another
side
pipeline
processing,
but
the
editing
editing
a
pipeline
configuration
has
two
main
side
effects.
K
Because
one
typical
example
is
the
dag,
so
changing
the
dag
structure
in
the
gitlab
siamo
has
a
behavior
change,
and
so
I
feel
by
combining
these
two.
K
I
think
it
makes
sense
with
the
point
that
we
discussed
before
from
from
both
peyton
and
fred,
where
we
say
the
dag,
even
from
a
graphic
perspective,
should
belong
to
pipeline
authoring,
and
I
agree
with
that,
because
it's
both
behavior
and
also
the
way
we
represent
the
pipeline
structure
and
the
both
the
I
think
they
should
be
owned
by
a
single
team
may
not
be
split
across
the
different
ones
and,
and
the
same
would
be
the
the
point.
Sorry.
K
But
something
I
can
kind
of
recall
now,
but
yeah
it
was
was
mentioned
before
so
I
I
did
actually
did
provide
a
link
there,
where
I
didn't
want
to
step
on
nanitos,
but
I
kind
of
tried
to
move
some
labels
around
some
features
that
make
sense
from
an
engineering
perspective
and
and
and
I
feel
like
well,
I
came
up
with
something
interesting
where
we
could
move
things
together.
That
makes
sense
from
from
my
perspective,
and
those
like
definitely
are
like
altering
and
and
processing.
K
Definitely
they
belong
together,
but
there's
some
certain
things
that,
in
my
opinion,
they
don't
belong
to
specific
category
and
like
pipeline
permissions.
I
think
these
are
generic
generic
features.
That
really
depends
on
what
kind
of
feature
we
are
implementing.
Is
it
about
trying
to
run
a
pipeline,
try
to
create
if
somebody
wants
to
edit
gitlab
see.
I
am,
let's
all
speak
about
permission,
that
that
is
something
that
belongs
to
altering.
K
If
it's
something
related
to,
I
don't
know,
handling
artifacts
and
permission
about
a
handling
artifact,
then
it
may
be
something
related
to
the
other
team.
So
I
feel
there
is
certain
things
that
we
could
do
with
moving
the
future
levels
around,
but
this
is
something
we
could
follow
up
offline
if,
if
we
have
any
question
on
that,
but
the
other
point
that
there
was
was
about
the
metrics.
K
So
the
fact
that
we
considered
pipeline
authoring
the
main
metrics
to
be
the
first
time
to
green
green
pipeline
and
time
to
first
win
pipeline.
Sorry,
I
think
that
not
only
contains
the
includes
the
pipeline
authoring,
but
also
the
pipeline
processing,
because
we
have
to
wait
for
the
pipeline
to
finish,
and
that
means
you
can
optimize
your
pipeline
in
terms
of
dag,
etc,
and
that
can
affect
also
your
your
performance
of
the
pipeline.
K
So
I
think
even
moving
these
two
things
together
makes
sense
from
a
point
of
view
of
of
the
main
metric
that
we
want
to
use.
So
any
questions
on
this
I
actually
explained.
E
K
Yeah
so
they're,
like
the
way
I
was
thinking
is,
we
can
have.
One
team
would
be
pipeline,
altering
an
execution
and
another
team
will
be
pipeline,
reporting
and
settings
just
which
basically
is
anything
to
do
with
artifacts,
with
anything
that
happened
before
after
a
pipeline
is
run
and
even
before,
like
you
want
to
set
up
variables
and
and
settings
on
the
ci.
A
One
thing
one
thing
I
wanted
to
mention
on
your
comment:
fabio
about
the.
I
think
the
permissions
feature
area
that
we.
E
A
So
as
we
talk
about
like
moving
moving
areas
around
and
maybe
better
clarifying
some
of
these
areas,
I
think
it's
also
important
to
keep
in
mind
that
maybe
an
area
doesn't
need
to
exist
like
to
your
point.
If
it's
kind
of
a
generic
thing,
that's
just
implied
as
part
of
everything
that
we're
doing,
maybe
maybe
that
isn't
a
feature
area,
because
it's
just
you
know
it's
like
it's
like
air,
it
just
exists
and
then
we
have
to
yeah,
you
know,
and
so
we
can
totally
like
get
rid
of
labels
too.
E
E
Separate
groups
yeah,
but
have
you
thought
about
statuses?
Is
that
something
that's
really
part
of
processing
that
should
be
merged
in.
K
K
The
other
point
I
had
was
about
the
the
size
of
the
split,
so
looking
at
the
the
two
different
categories-
the
two
different
possible
groups-
we
have
on
one
side.
We
have
three
times
the
number
of
issues,
then
the
the
pipeline
across
the
pipeline
authoring
group-
and
so
I
was
wondering,
are
we
going
to
allocate
resources
three
times
more
in
ci
then?
But
it
looks
like
it's
50,
50
split.
K
To
be
in
the
end,
but
if
we
have
ci
that
includes
solving
technical
debts
and
something
a
lot
of
bugs
there,
we
definitely
are
going
to
see
a
slower
progress
for
their
nature
of
this
kind
of
issues
slower
progress
in
that.
If
we're
going
to
have
less
people
than
the
counterpart
pipeline
authoring,
then
it
means
one
team
is
gonna,
perform
slower
than.
E
K
E
Define
the
group
so
that
it
would
evenly
distribute
the
issue.
It
was
based
on
something
that
you're
mentioning
in
your
comment
here
about
the
the
the
the
tech
that
dividing
it
in
a
way
where
may,
if,
even
though
one
group
may
have
fewer
issue,
the
complexity
of
the
the
issues
would
make
them
would
kind
of
justify
having
it
owned
by
one
group.
Does
that
make
sense.
A
I
think
I
think
the
way
that
the
way
that
I've
kind
of
looked
at
this
is
it
like
like.
If
anything
we
do
like
this
there's
going
to
be,
it's
never
going
to
be
a
perfect
balance
of
how
we
define
divide
these
things.
But
it's
you
know
if
we
go
back
to
our
sort
of
key
metric
in
this,
like
future
future
gmail
as
being
the
the
top
priority.
A
That
means
that
we're
making
a
deliberate
decision
to
say
we're
going
to
invest
in
this
one
group,
because
we
feel,
like
that's
the
most
important
thing
to
the
business
and
we're
going
to
de-prioritize
the
investment
in
in
this
other
area
like
de-prioritizes,
is
maybe
not
the
the
right
word
but
like
it's
not
going
to
be
like
we're
not
going
to
expect
the
same
amount
of
progress
in
this
area,
because
we've
we've
decided
that,
like
intentionally,
we
want
to
put
more
focus
here,
and
that
means
that
you
know
these
some
of
these
issues
in
the
backlog,
we're
just
going
to
sort
of
accept
them
and
and
realize
that
we're
making
a
choice
to
to
work
on
them
later.
A
So
that's,
I
think
I
think
that's
the
the
important
thing
to
keep
in
mind.
I'm
you
know
I'm
an
engineer
and
I
want
to
get
rid
of
all
the
bugs
and
all
the
tech
that,
but
there's
there's
always
the
balance
between
between
that
and
then
like
what.
What
pushes
the
the
business
forward,
and
where
is
the
you
know
where?
Where
are
areas
for
growth
and
what
drives
us
to
to
kind
of
the
next
level
and
to
to
compete
with
our
competitors
effectively.
A
D
I
I
thought
you
two
captured
it
pretty
well
yeah.
We
did,
I
mean
so
that
definitely
was
discussed.
I
mean
I
personally
brought
up
that
point
and
you
know
I
think
you
can
look
at
it
in
terms
of
you
know
yes
spreading
capacity
or
you
can
look
at
it
in
terms
of
like
desired
investment,
and
I
think
that
the
thinking
you
know
really
from
I
think
kenny
and
jason
here
from
the
product
team
was
that
these
are
two
areas
that
we
want
to
be
investing
in.
D
D
Pointing
out
here
that
we're
not
doing
this
because
of
like
an
engineering
team
structure
issue-
it's
not
like.
Oh,
the
teams
are
too
big,
and
so
we
need
to
split
them.
For
that
reason,
or
you
know,
there's
some
kind
of
engineering
management
rationale
for
this.
It's
really
about
aligning
individuals
with
the
product
direction
in
these
different
areas,
and
so
so
it
really
again
goes
back
to
those
product
goals.
Much
more
than
this
is
an
even
way
to
distribute
issue
counts
but
yeah.
D
Ideally
it
will
work
out
where
you
know
there's
it
makes
sense
to
be
investing
equally
in
both
those
areas
and
like
darby
said
there
may
be
some
things
that
you
know
like
always
can't
get
done,
but
hopefully
this
makes
it
easier
to
kind
of
focus
on
you
know
the
important
things
and
and
removes
you
know
some
of
the
obstacles
that
you
know,
speed,
bumps
we've
hit
in
the
past.
F
With
that
50
50
team
split,
my
next
point
on
c2
was:
when
do
we
need
to
figure
out
our
preferences?
I
heard
we're
gonna.
Maybe
do
like
a
dry
run
in
early
13.5.
F
What
like,
when
exactly
like?
Do
we
need
to
get
that
situated
and
let
our
ems
know.
A
Yeah,
so
I
think
I
think
what
we'll
do
you
know?
We've
got
a
few
takeaways
here
that
we've
talked
about
in
terms
of
clarifications
and
maybe
getting
a
bit
more
refined
with
some
of
the
organization.
A
The
next
step
would
be,
I
think,
we'll
just
do
like
a
like
a
google
form
or
something
where
we
can
put
in
first
preference,
second
preference
and
and
other
sort
of
comments,
and
things
like
that,
and
you
know
I
think
that
that
will
come
at
a
point
where
we
feel
like
we've,
we've
kind
of
addressed
some
of
these
things,
so
hopefully,
in
the
next
couple
days
or
something
we'll
we'll
have
we'll
have
that
out
and
then
and
then
people
can
put
that
in
there
you
know
like
13.5
is,
is
in
progress.
A
Now
it
started
today.
So
we've
we've
got
our
work
to
work
on
you
know,
but
but
from
the
product
perspective
like
we
have
two
pms
things
that
things
are
already
moving
down
this
path.
So
as
we
as
we
work
towards
this
we'll,
you
know
we'll
figure
out
at
some
point.
A
Maybe
next
week
you
know
if
things
are,
if
things
are
clear
to
everybody,
then
then
we
can
make
assignments,
and
then
you
know
like,
as
you
pick
up
work
for
this,
milestone,
look
for
that
area,
realizing
that
things
are
carrying
over
and
we've
already
started
like.
A
I
don't
want
to
move
any
work
in
flight
for
anyone
like
if
you
started
on
something
we're
not
going
to
say
like
oh,
you
got
to
go
hand
that
off
to
someone
else,
because
that
wouldn't
make
any
sense,
so
this
is
going
to
be
kind
of
a
transitional
milestone.
A
A
Cool
all
right,
jose
had
a
question:
is
it
possible
again
an
overview
of
the
two
teams?
Just
a
quick
reference
guide
from
there
can
look
at
the
handbook
and
look
it
more
in
depth
that.
A
A
Yeah:
okay,
if
there's
other
clarifications,
though,
for
for
jose,
send
them
send
them
to
me
or
to
tao
and
we'll
we'll
work
to
get
those.
A
Okay,
yeah
cool
and
then
fred,
I
think,
you're
you've
got
one
more.
A
J
He
always
freezes,
he
always
freezes
when
he
feels
like
it's
actually
been
addressed,
we've
discussed
so
it's
probably
he
was
about
to
say
it's
all.
That's
because
yeah.
G
A
Well,
I
think
that's
the
end
of
the
agenda,
so
I
I
I
think
if
there
are
any
other
questions
we
can
talk
continue
to
talk
now.
I
know
we've
been
here
a
while,
so
I
want
to
let
people
you
know
get
on
with
their
day
if
anyone
has
additional
follow-ups,
feel
free
to
ping
me
or
your
em
or
or
tower
dove
too.
So
thanks
everyone.
This
has
been
a
really
great
discussion.