►
From YouTube: Quality Department project management overview
Description
In this video we went over the department list of projects and roadmap page.
https://about.gitlab.com/handbook/engineering/quality/project-management/
https://about.gitlab.com/handbook/engineering/quality/roadmap/
A
Cool
so
Amex
I
lead
the
quality
engineering
department
and
we
have
on
the
call
Vincey
and
Johanna
Vincey
is
the
quality
engineer
manager
for
her
growth
and
joanna
is
the
collodion
a
Manticore
for
absence
the
ICD.
So
this
meeting
is
about
a
run-through
of
the
overall
project
management
process
that
we
have
here
at
good
lab
and
just
to
provide
more
materials
into
the
onboarding
process
for
our
department.
We
are
going
over
two
main
pages:
the
project
management
page,
which
puts
all
the
projects
and
also
one
more
for
roadmaps.
A
Now
this
page
I
set
it
up
almost
a
year
already,
so
it
could
use
feedback
on
how
we
on
how
we
can
do
things
better.
What
I
did
was
I
essentially
lists
all
the
projects
and
then
showcase
the
default
board
to
that
set
up
for,
for
those
call
them
legacy.
Teams
at
the
teams
that
already
have
managers
at
this
point
and
then
I'll
leave
it
to
each
manager
said
they
wanted
improve
on
this
or
have
their
own
boards
have.
Additional
is
totally
up
to
up
to
the
manage
to
do
this.
A
So,
let's
start
with
some
the
list:
let's
go.
Let's
go
straight
down
and
the
first
one
on
this
list
is
under.
This
is
the
big
group.
So
if
it's
most
of
our
projects
is
not
all
are
under
key
level
org,
so
when
you,
those
who
people
had
come
under
key
lot
like
combat,
so
if
you'll
have
an
org
this
fraud,
this
group
is
essentially
where
all
our
work
is
stored.
A
The
keel,
a
QA
project,
is
essentially
the
runner
Orchestrator
per
se
and
we
out
sources
or
we
publish
this
to
a
gem
called
Calaca
way
so
that
our
customers
can
even
download
this
gem
and
run
the
tests
on
their
good
lab
instances.
Hence
it
is
a
separate
project.
A
lot
of
people
confuse
this
with
the
QA
project
and
we've
done
a
lot
of
clean
up
where
the
test
cases
and
test
scenarios
we'll
put
in
this
project
it
shouldn't
be,
it
should
be
in
the
main
project.
A
A
So
it
works
in
coordination
with
the
QA
project
in
the
main
repo,
so
this
runner
kind
of
it
kicks
off
the
test
in
that
in
that
folder,
so
think
of
it
as
an
as
an
orchestration
tool
going
back
to
the
list
insights,
this
should
be
removed
soon.
As
a
historical
background.
When
I
first
started,
we
didn't
had
any
dashboards,
so
we
built
one
really
fast,
and
this
is
the
code
that
powers
the
legacy
dashboard
and
you
can
see
the
rates
of
bug
creation.
A
This
was
the
first
iteration
of
essentially
the
engineering
metrics
that
it's
now
the
developer
development
cake
yeah
that
we
have
today.
We
were
the
first
that
built
this
and,
as
you
can
see,
it's
really
slow,
so
we're
leaving
it
here
for
historical
reasons
likely
that
kya
will
execute
the
end-of-life
process
for
this
project
sometime
in
February,
because
we'll
be
moving
into
periscope
and
we've
actually
built
this
feature
in
ticket
lab
ourselves.
A
B
A
Question
so
there's
a
directional
issue
here:
the
deprecation
plan,
so
what
we
want
to
do
is
slowly
switch
out
periscope,
where
we
can.
Let
me
show
you
what
the
feature
looks
like.
So
this
is
the
deprecation
plan.
You
can
see
all
the
other
lists
of
tasks
here.
It's
a
really
cool
feature.
You
can
figure
this
at
the
group
level
and
also
at
the
project
level.
If
you
have
a
cute
lab
inside
yamo
file,
you
can
essentially
configure
a
chart
that
renders
a
very
similar
capability
here
right
inside
get
lab.
A
The
UI
is
a
bit
rough
right
now
on
the
edges,
because
our
values
of
iteration
it
works
it
to
a
certain
degree,
but
it's
not
as
it
won't
be
polish
our
perfect,
but
the
links
work.
You
can
switch
dashboards
and
your
the
URL
updates.
So
you
can
essentially
deep
link
charts
one
of
the
things
that
I
think
Kyle's
looking
at
right
now
is
in
to
entice
trends
and
failure.
So
we
just
gonna
use
this
one.
A
It
can
read
our
data
on
mosh
requests
and
Amar's
on
a
time-series
axis.
That's
one
dimension,
the
other
dimension,
our
issue,
so
really
simple
issues:
labels
merge,
request
labels
and
then
you
can
slice
the
data
that
way
there
are
documentation
in
the
in
our
Doc's
on
how
to
configure
this
yellow
file.
Let
me
see
if
I'm
I
can
point
you
to
some.
Actually,
the
access
request
project
by
the
security
team
is
actually
using
it
pretty
actively.
A
So
all
the
audits
are
the
baseline
access
they're
using
this
to
measure
how
much
work
is
being
done
and
etc.
And
if
you
look
at
the
repository,
it's
a
good
lab
folder
and
there's
an
inside
KML
file.
So,
for
example,
you
can
you,
when
you
create
a
chart,
give
a
title:
what
it
what
it
is
to
type
the
chart.
You
can
pick
between
stack
bar
and
it's
like
a
just
a
bar
chocolate
line.
A
So
yeah
it's
just
really
forward-looking,
because
this
is
an
example
of
engineers
in
the
Quality
department
contributing
to
features
which
is
a
very
different
than
other
companies,
where
maybe
even
QA
engineers
they're
only
writing
test
plans.
We're
not
that
so.
This
is
a
great
growth
factor
for
engineers
and
the
team.
At
all
questions.
C
A
A
One
thing
that
we
haven't
done
and
we
should
be-
is
measuring
the
the
output
of
our
team
and
we
might
need
some
new
labels,
a
quality,
:
opposites.
Yes,
the
quality,
:
growth
for
you
Vincey,
you
might,
you
might
have
to
create
another
project
like
the
customer
portal,
to
see
how
how
many
like
you
want
to
see
how
many
tests
or
how
many
emoji
cuts
with
tests
and
use
a
label.
A
B
A
So
for
the
overall
roll
up
its
Kyle
and
that's
that
is
in
periscope,
the
single
source
of
truth
is
periscope,
because
that's
where
our
execs
are
looking
at
the
data
management
team
is
looking
in
the
data.
The
strategy
that
we
will
do
is
it
and
have
some
of
the
data
in
insights.
We
can
create
an
API
or
integrated
periscope,
so
it's
reflected
so
the
single
source
of
truth
gets
pulled
directly
from
khilafat
comm
through
insights
and
we
provide
either
an
adapter,
an
API
that
periscope
can
ingest
and
then
render
it
there.
A
There
are
charts
in
periscope
that
are
just
powered
by
CSV
files
and
they
just
upload
CSV.
This
is
kind
of
similar
to
that
where
the
rendering
presentation
is
there,
but
we
can
line
on
the
source
of
data
and
then
ensure
that
we
dog
food
and
and
improve
our
product.
That
way.
There's
an
answer,
your
question,
so
that's
it
for
insights.
Let
me
close
it
out
and
then
let's
go
back
to
this
deal
at
charge.
A
This
is
the
triage
engine
which
the
the
engineers
in
the
engineer,
predatory
team,
has
been
working
on
for
a
long
time
already
this
powers
a
lot
of
the
box
that
you
see
like
all
labeling
issues,
moving
milestones
when
a
mouse
and
Cole
is
equivalent
to
close
close
sprint
and
move
tickets
to
the
next
sprint
that
type
of
work.
This
is
a
free
tool
that
we
open-source
to
customers
at
lab
as
well.
So
there
are
customers
that
actually
use
this.
A
It's
a
supplemental
tool
that
takes
care
of
process,
automation
and
housecleaning
for
lack
of
a
better
term.
So
if
you,
if
you
hear
a
good
lab
triage,
this
is
the
project
that
powers
all
that,
and
this
is
its
own
separate
thing.
There's
other
initiatives
to
actually
make
this
a
feature
inside
get
lab
as
well.
A
A
We
configure
it
for
our
use
here
in
the
charge-offs
project,
so
the
trash
operations
pools,
kidnap,
charge,
I,
say
library
or
our
dependency
and
all
the
rules
that
we
have
are
in
here
like
move
pass
on.
So
this
is
this
is
a
usage
and
you
can
see
we
have
logic
to
close
report.
There's
things
to
test
dry
run,
ensuring
that
default
labels
have
set
as
a
hygiene
tests
move
milestones.
A
The
tribe
results
charge
report
is
being
generated
here.
So
this
is
our
use
case,
but
this
is
the
the
engine,
so
you
won't
see
any
logic,
fear
that
is
related
to
our
use
case,
but
it's
like
the
the
clients,
the
API
to
provide
or
for
users
to
call
does
that
make
sense.
Mmm-Hmm
sorry
I
should
use
that
term.
Any
questions
is
it
clear.
A
Okay,
ask
me
questions
any
time,
and
I
would
never
be
annoyed
if
a
week
from
now
like
what
is
this
project
happily
to
answer,
do
not
be
afraid
to
ask
questions
so
that
takes
care
of
the
charge
and
charge
ops.
Oh
boy,
this
is
really
outdated
so
before
we
had
good
lab
Community
Edition
and
get
lab
Enterprise
Edition
now
this
has
changed
a
lot
because
we
have
moved
to
a
single
repo,
so
get
lab.
C
II
has
been
moved,
slash
renamed
to
get
like
foss
foss
stands
for
a
km
m2f
for
this
full
open-source
software.
A
Something
auto
finds.
This
is
the
code
for
the
CEO.
Should
that
we
publish
no
work
is
being
done
here
anymore.
What
we
do
is
we
work
on
only
one
repo,
because
there
was
a
lot
of
costs
in
managing
two
different
repositories
when
engineers
had
to
create
two
Amar's
every
time
they
work
on
a
feature
like
one,
mr
for
the
enterprise
code
base,
one
mr
for
the
open-source
code
base
and
there's
like
if
else
in
between
so
now.
A
Sorry
as
if
else
now
in
this
code
that,
if
Enterprise
license
enable
this
code,
if
no
license
you
fall
back
to
the
other
piece
of
code
before
there
was
it
just
merge,
conflicts
everywhere
and
code
and
the
same
folders
look
different
in
two
repos
and
that
was
detrimental
to
our
productivity.
Now
is
only
one
repo
and
everything
gets
get
some
gets
put
in
this
there's
code
at
the
end
of
the
relief
cycle
that
removes
enterprise
specific
code,
which
is
now
in
folders
already,
and
it's
just
copied
and
pushed
here
for
transparency
reasons.
B
I'm,
just
a
bit
confused
any
bed
in
here
you
clearly
so
I
do
understand
that
this
is
just
for
the
the
other
one
market
left
for
other.
What
is
the
enterprise
code
base,
which
has
already
licensing
features
and
everything,
and
if
there
is
a
feature
it's
not
required
for
enterprise,
we
put
the
first
eight
when
I
will
come
back
to
this
one.
But
if
that
is
a
case,
why
are
we
maintaining
two
different
repos
still
or
are
we
just
trying
to
duplicate
this
one
eventually
so.
A
We
need
to
provide
it
for
transparency
reasons,
because
people
run
the
the
open
source
code
base
right
that
they
install
the
the
CD
version.
So
in
order
to
determine
what's
going
wrong,
I
don't
want
to
see
the
flow
of
the
code.
This
needs
to
be
made
available
and
there
are
some
limitations
in
the
in
our
enterprise.
A
B
A
B
A
A
Can
I
show
you
what
happens?
This
is
essentially
the
triac
ox.
So
what
we
do
is
we
auto
close
the
issue,
move
it
to
the
main
repo.
So
we
just
like:
hey,
hey
folks,
this
project
issue
tracker
no
longer
be
booked
that
follow
the
new
project.
This
is
your
new
issue.
Go
there
instead
and
we
just
automate
the
cleanup
of
this
I
think
it's
by
per
week.
A
So,
for
example,
this
one
if
we
ramadas
closed,
moved
open
by
this
person
and
when
you
click
on
moved,
it
has
a
exact
clone
of
his
thing
and
with
the
comments
already
copied
over-
and
you
can
see
that
this
is
the
audit
event
like
post
the
bot.
Everything
should
happen
here
and
hopefully
okay.
He
he
came
here.
Any
other
is
his
comment.
So
it's
it's
being
notified
actively,
and
this
is
charge
operations
in
the
works.
A
A
This
is
essentially
I
don't
want
to
use.
Essentially,
this
is
like
oh
yeah.
This
is
this
is
just
like
when
you
you
have
your
JIRA
ticketing
system
or
Bugzilla
or
whatever.
So
this
is
the
task
tracker
for
the
team,
I'm
still
polishing
how
we
can
draw
the
line
there
sometimes
I
have
to
remind
people
hey.
This
is
a
cross-cutting
work
with
your
counterpart
team
go
and
open
in
the
main
repo,
because
you
will
get
like
the
dev
ops
label
staged
labels
counterpart,
but
dragging
and
tagging
all
that
stuff.
A
This
is
more
like
it's
evolved
more
into
like
internal
housekeeping
tasks.
Non-Technical
process
changes
that
we
need
to
discuss
some
framework
things.
It
needs
to
be
done
here
like
improved,
tooling
I'm,
leaving
it
I'm,
giving
some
space
for
for
flexibility
here,
but
yeah
it's
it
can
be.
It
can
be.
There
are
improvements
that
we
can
do.
I'll
just
leave
it
at
that,
going
back
to
nightly
stairs.
I.
Think
we
talked
about
this
already.
A
Oh,
these
are
these
are
already
created,
so
I
need
to
probably
look
into
this,
so
I
think
we
touched
on
this
already.
Holly
has
a
bunch
of
environments
into
thick
projects.
That
is
essentially
the
CI
configuration
think
of
it,
like
a
folder
for
your
CI,
a
there's
tests
for
pre
prod
test
for
production,
test
for
canary
test
for
staging
and
Knightley's,
with
the
exception
of
Knightley's.
A
Everything
gets
run
in
another
separate
ox
instance,
because
if
it
love
icon
goes
that
way
to
ensure
that
the
release
and
test
process
is
still
up
and
running
so
the
test
and
CI
are
running
in
a
different
instance
and
what
what
we
do
is
the
project
here
gets
married
over
to
that
instance.
So
the
definition
of
the
CI
jobs
are
being
made
here.
Hence
there's
some
yeah.
You
see
most
requests
activities
here.
However,
you
want
to
see
any
pipeline
activities.
Oh
there
is
interesting.
Okay,
it's
probably
not!
A
A
A
I'm
surprised
it
still
running
some
some
some
pipelines
here,
but
it's
likely
that
these
are
not.
These
are
not
critical
pipelines.
So
this
is
like
a
month
ago
on
one
month
ago,
two
weeks
ago,
so
I
think
it's
correct,
maybe
go
to
the
ops
instance.
You
test
around
every
like
five
to
ten
minutes
and
it's
really
active
there
and
that
it's
what
you
see
in
the
QA
and
the
score
staging
channel
key.
We
underscore
night,
leaves
channel
here
and
the
score
production,
so
it
Maps
directly
to
to
to
these
projects.
A
Good
question
night
lease
is
the
package
that
we
ship,
so
the
omnibus
package,
omnibus
the
installer
for
good
lab
so
nightly,
is
just
test
the
young
installation
packages
every
every
night
and
we
maintain
that
with
coordination
with
the
distribution
team
because
they
are
in
charge
of
making
sure
all
the
district
8
lab
are
up
and
running
like
Susie
Ubuntu
Windows,
all
the
flavors
that
we
allow
users
to
install
that
is
that
works
hand
in
hand
with
the
night
lease
and
staging
is
stating,
and
so
what
different
acute
Labatt's.
We
do
not
have
a
develop
branch.
A
We
have,
we
merge
directly
to
master
and
we
enforce
a
testing,
it's
being
done
in
your
feature
branch.
Hence
we
give
you
a
review
app
or
a
test
environment
for
every
feature,
branch
and
make
sure
that's
the
case,
so
it
gets
merged
directly
to
master
and
staging
gets
deployed.
I
think
every
day,
multiple
times
today
on
staging
and
once
deployment
time
comes
in
if
any
green.
When
deployment
window
comes
in,
we
pick
the
the
green
deployment
from
staging,
which
we
have
smoke
tests
and
soon
to
have
full
end-to-end
tests.
A
I'm
guarding
it
gets
picked
and
deployed
to
canary
canary
is
essentially
a
subset
of
production
which
a
number
of
us
are
are
using
and
like
the
internal
gibla
projects,
they
are
all
in
canary
because
we
want
to
ensure
that
we
are
in.
We
get
the
code
first
before
it
gets
released
to
the
general
public
and
catch
any
edge
cases
there
once
canary
is
soaked
in
for
a
while,
then
gets
promoted
to
production
and
then
finally,
the
general
public
gets
gets
the
code
base,
that's
being
deployed,
so
I
think
canary
and
production
are.
A
They
are
the
same
environment
but
different
different
parts
of
the
cloud
for
lack
of
a
better
term,
and
we
want
to
make
it
clear
that
this
is
running
against
a
canary
section
of
the
cloud
and
then
production
runs
against
once
against
the
rest.
Does
that
answer
the
question
cool
this?
This
needs
to
be
updated.
Don't
you
a
failures,
this
is,
this
has
been
deprecated,
I.
Think,
okay,
I!
Think
we
changed
it
already.
So
these
are
the
we
used
to
had
a
project
to
document
all
the
flaky
tests.
A
Right
now
we
just
use
quality
bug
and
then
we
label
them
it's
a
bit
of
a
the
best
room
for
improvement,
so
I
think
we
need
to
use
another
label
for
this
like
we
have
quality,
flaky
test
label,
I
think
we
should
ensure
that
the
team
use
with
that
so
yeah.
This
is
essentially
CI
pipeline,
bugs
that
we
own.
A
A
A
We
have
a
label
for
it
now,
if
you
look
at
the
like
found
on
staging,
but
these
are
not
bugs
in
regards
to
the
pipeline,
so
it's
not
there
but
like
if
it's
found
on
staging,
we
should
have
I
see.
The
bees
are
essentially
think
that
we
should
be
should
be
looking
into.
One
thing
we
can
do
is
call
the
improvement
is
ensure
that
these
labels
are
added
by
the
by
the
box
on
our
side.
If,
if
it's
a
flaky
test,
we
should
label
it
with
on
this
label,.
A
A
So,
okay,
it's
being
used,
though
it
hasn't
been
recently,
and
most
of
these
are
closed
because
there's
no
opening
shoes
I
think
that's
like
the
next
iteration
to
ensure
that
the
team
ISM
is
a
is
not
too
many
things
clearly
and
by
our
roadmap
and
the
DevOps
way
of
doing
things.
Flaky
test
is
the
highest
priority.
Hence
you
see
them
as
s1p
ones.
A
C
B
A
Yes,
all
the
issues.
Add
labels
for
this
I've
done
a
lot
of
groundwork
to
have
this
to
introduce
these
labels.
I
think
what
I
need
help
I'm
on
the
mat
is
going
forward
is
ensure
that
we
implement
it
and
if
there's
any
overhead
and
paperwork
or
red
tape
that
we
don't
need
I
hate
this
label,
it's
duplicate
with
this.
A
A
A
So
I'm
showing
this
page
issue
workflow,
so
there's
a
number
of
things
that
are
listed
here
so
like
what
types
of
label
to
be
used
over
all
throughout
the
whole
company
actually
and
master
flaky
staged
labels.
Group
labels
I've
done
so
many
iterations
on
this-
that
sometimes
it
can
be
fatigue,
changing
it
back
and
forth,
but
for
good
reasons
we
iterate
all
the
time.
You
only
hope.
B
C
A
B
A
A
A
A
Let's
see
often
see
incb
team,
the
top
call
the
top
level
I
configure
here
is
for
for
managers
to
see
what
is
being
scheduled
on
their
team.
For
the
like,
the
current
snapshot
in
time
like
how
how
many
is
on
there,
how
many
on
their
plate
what's
the
size
of
it,
and
then
you
can
switch
them.
You
can
switch
the
milestones
here
to
see
hey
it's
a
if
they're,
overloading
this
milestone
or
not
I
think
we
should
be
amusing.
A
B
A
So
this
board
is
at
the
group
level.
So
it's
the
same
issue
so
that
one
issue
can
appear
in
many
boards
depending
on
what
label
you
specify.
So
it
could
be
a
good.
A
good
yeah,
like
Dan,
is
working
on
quality
work
for
configure
an
orchestration,
so
it's
clear
off
the
bat
yeah,
what
a
team
at
which
group
it's
being
yes.
C
A
A
Privatization,
so
you
can
put
P
1
to
P
fours
and
then
you
can
like
what
goes
in
first
sorry,
a
priorities,
yes
and
then
schedule
you
can
put
so
ins
on
them.
Some,
like
the
wink
you
as
a
manager,
you
can
configure
hey
I
wanna.
This
is
my
grooming
board
and
back
while
cooling
boards
can
configure
hey
this
column
at
the
back,
there's
a
backlog
and
then
which
issue
is
going
to
water.
Then
you
can
also
filter
by
by
people
as
well.
A
A
A
A
A
Great,
how
do
you
support
so
this
is
this
is
me
taking
our
documentation
in
a
bit
far
so
I
I?
This
is
the
mermaid
chart
for
that,
so
they
can
see
which
environments
go
into
which
which
group
and
then
which
project
falls
into
what
and
then
like.
This
is
the
top-level
Department
scheduling
and
prioritization
like
that,
can
happen
here.
A
A
It's
pulling
from
customers
like
give
a
comm,
which
is
your
project,
so
I
suggest
you
have
both
levels
because
you
may
want
to
know
if
your
team
is
contributing
to
another
project
and
if
you
have
the
growth
team
and
quality,
you
will
be
aware
of
it
and
then
you
can
have
if
you
want
another
board
just
for
that
project,
and
only
like
you,
you
know
you
can
only
put
the
backlog
ruling
board
there
and
the
prioritization
board.
That's
how
you
groom
it
at
that
level.
A
A
What
link
so
everything
is
here,
top
level
board
priority
scheduling
and
all
that
I
think
somebody
updated
my
top
level
board.
I'm
gonna
go
try
to
find
dev
team,
oh
I,
think
Rama
took
over
okay,
so
it
looks
like
it.
Obviously,
yeah
Rama
had
to
go
with
this
board
already.
Endicott
pick
a
link
here,
but
this
is
her.
Team's
board
looks
like:
can
you
see,
there's
a
fakie
test
or
for
her
team?
She
was
checking
cricket
and
test
pilot,
and
this
is
the
things
that
our
team
are
working
on.
B
A
A
We
haven't
been
updating
this
port,
yet
so
there's
something,
but
we
should
look
into
with
feedback
from
other
engineering
managers.
The
way
I
defined
this
is
we
have
five
tracks,
I'm,
actually
looking
to
collapse
it
into
four,
because
I
think
releases
and
coverage.
It's
kind
of
the
same
thing,
but
an
overview
of
this
coverage
track
is
work
to
improve
the
overall
coverage.
Most
of
the
stuff
will
be
under
here.
A
The
and
you
see
it
so
many
so
many
things
we
could
do
ideas
that
we
haven't
done
yet
the
one
that
doesn't
have
links
hot
links
or
we
don't
have
a.
We
should
have
an
epic
appear
to
have
an
issue
to
track
it
good.
If
you
scroll
down
efficiency
track,
so
work
to
increase
efficiency
and
productivity,
so
fall
tolerances.
It's
like
framework
improvements
and
pipeline
improvements
or
pass
through
execution,
making
the
test
pyramid
lean,
and
it
is
wire
any
extra
eyes,
I,
think
disks,
probably
removed
and
put
it
in
coverage
track
just
like
that
school.
A
A
Seven
with
these
five
projects
so-
and
you
want
to
show
your
test
coverage,
make
sure
you
update
those
users
and
we
just
maintain
the
whole
test
data
model
and
it's
the
same
across
all
environments,
productions,
18,
that's
nice,
yeah
and
then
like,
and
it's
the
same
with
a
unit
test
as
well
so
like
when
the
updated
test
data
model
it
propagates
everywhere.
The
test
gets
changing
who
and
you
run
tests
in
production,
everything
scream.
So
that's
where
that's
where
I
come
from
and
I
think
we
should
be
doing
some
of
that
here.
A
That's
one
test
results,
test,
readability
a
tries
track.
This
should
probably
go
into
efficiency.
I!
Think
that's!
Where
I'll
put
it
because
this
is
making
sure
we
try
things
that
come
in,
we
have
boxes
that
auto
charge
things
and
then
measure
Travis,
metrics
and
then
release
trackers
the
interval
each
process.
Now
we
have
a
pixel
get
lab,
so
this
is
a
kicker.
All
of
these
five
tracks
is
an
applicant
get
lab.
A
A
These
are
essentially
everything
in
the
project
that
we
have
scheduled.
Our
engineers
have
ideas
for,
or
something
that's
being
in
there
just
like
they
actually
see.
What's
the
status,
the
really
high
level
view
what's
in
backlog
or
scheduling
in
what
what
milestone
and
what
not,
and
if
you
expand
all
these,
it
actually
goes
down
to
the
issue
level.
So
you
can
see
the
progress
improvement
when
coverage
I
think
we
like
halfway
done
and
once
things
get
closed
out
everything
it's
updated
reflected
at
this
top
level.
So
this
is
a
single
source
of
tools.
Oh.
A
A
So
if
you're
adding
an
epic
to
a
parent,
it
should
fall
in
one
of
these
five
tracks
and
any
epic
you
add
here
should
contain
any
other
downstream
epics.
It
should
only
be
issues
so
ensuring
that
the
structure
is
flattened
and
you
don't
get
an
unlimited
nested
structure.
We've
been
in
that
mess
before,
where
hey
there's
an
epic
with
two
issues,
which
contains
also
an
epic
with
five
issue
and
then
an
epic
there
with
one
issue
and-
and
it
was
really
messy,
really
confusing.
A
B
Thing
that
we
have
enjoyed
rice,
you
have
initiatives,
that's
like
your
main
I
love
a
goal,
and
then
you
have
epics,
and
then
you
have
stories
or
tasks.
However,
you
want
to
do
it
yeah.
Is
there
a
reason
why
we
haven't
thought
about
those
three
layers,
because
we
see
we're
actually
honestly
using
three
levels
here:
yeah.
A
So
did
lab
product
direction.
I
I
think
gia
has
his
own
pain
as
well.
I
think
it's
too
rigid.
Yes,
you
have
to
use
initiatives
where
sometimes
I
just
need
an
itch
and
an
epic
with
five
issues
and
you're
done
with
it.
As
you
use
get
lot
more,
you
will
see
the
power
of
simplicity
and
flexibility,
because
you
can
you
can
fit
it
any
way.
You
want
to
fit
your
own
workflow
not
to
bash
on
any
of
our
competitors.
A
D
B
A
Apparent,
but
it
is
why
I
want
to
limit
down
to
these,
so
we
have
only
four
epics.
The
first
one
is
the
the
grandfather,
epic
mm-hmm.
The
second
one
is
the
parent
epic,
which
is
the
road
map
tracks.
Okay
and
you
have
the
normal
epics,
which
is
like
work
within
two
or
three
milestones,
and
you
have
issues.
That's
it
like
there's
no
more.
A
A
Okay,
now
the
cool
thing
when
the
show
not
being
looked
at
by
a
lot
of
managers
right
now,
there's
a
road
map
view,
and
this
is
why
you
see
the
nested
epics,
really
powerful,
that
you
can
render
the
time
the
time
on
the
issues
directly
here
the
number
is
doesn't
roll
up
yet,
but
the
cool
thing
is,
you
can
just
go
into
an
epic
I'm
going
to
the
cover
track.
I
pick
now
you
can
move
up
to
the
ancestor,
so
this
is
almost
like
a
built-in
folder
structure.
A
You
just
reverse
it
once
you
grab
on
to
one
of
our
epics,
you
can
just
go
anywhere
in
a
tree.
A
note,
and
this
view
is
slide
everywhere.
So
you
can
see
where
the
progress
are.
As
long
as
your
team
is
scheduling
milestones,
you
can
plan
ahead.
You
can
have
unlimited
insights
on
how
you
want
to
structure
this
and
the
dates
roll
up
from
the
issue
level
up
to
them.
A
A
A
Yeah
and
once
we
talk
about
okay,
ours,
it's
a
bit
I,
don't
want
to
disconnect
it,
but
there's
tracking
two
places
right
now:
one
is
in
the
Oh.
Claire's
are
being
tracked
at
this
level,
which
is
under
king
calm,
and
there
are
no
epics
here
to
tracker.
It's
only
issues
at
the
engineering
management
level,
so
these
are
just
like
one
issue
describing
he,
okay
are
what
we've
done
in
the
past
is
we
have
issues
that
are
created
in
Google,
Apple
org?
A
So
that's
where
this
is
a
high-level
management
tracking
roll
up
to
the
company
page,
and
this
is
the
issues
that
are
actually
in
our
boards
and
where
you
can
link
to
roadmap.
So
it's
almost
like
there's
you
me
the
you
need
to
work
doing
here.
That's
a
dotted
line
to
the
Khilafat
comm
project
like
the
okay,
ours
and,
like
you
can
actually
it
there's
a
missing
box
here
where,
like
there
are
no
epics
or
there's
no
there's
no
place
to
drop
them
into
the
coverage
track.
It's
a
lot
of
them
paperwork.