►
From YouTube: UX Showcase Verify GitLab DAG Pipeline Viz
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
A
A
Let
me
start
off
with
a
little
view
on
the
on
a
team
lots
of
these
slides
in
this
presentation
or
more
for
viewing
purposes
afterwards.
So
I'm,
probably
going
through
a
lot
of
these
slides
pretty
quickly,
but
it's
kind
of
nice
to
point
out
the
team.
If
you're
interested
I
have
a
little
arrow,
where
I'm
in
within
this
blurb
of
information,
but
feel
free
to
check
it
out,
there's
lots
of
people
involved
and
there's
a
part
for
me
and
then
before
I
begin.
A
Still,
all
other
jobs
depend
on
all
other
jobs
being
finished
as
well.
So
this
can
create
unnecessary
bottlenecks
that
if
we
skip
back
to
the
previous
slide
real
quickly,
we
can
see
that,
for
example,
a
job
in
the
future
will
already
be
able
to
begin
if
all
of
its
dependencies
already
successfully
succeeded
so
kind
of
circumventing
that
potential
bottleneck
problem
going
on
a
little
bit
of
the
timeline.
What
has
happened
in
12?
We
as
a
done
implementation
within
get
lab.
That
kind
of
allows
for
this.
A
For
this
tag
to
already
happen
in
the
background,
the
visualization
has
not
kept
up
with
that,
though,
so
we
have
done
a
visualization
problem.
Validation
like
hey.
What
are
the
issues
the
current
a
user
is
facing?
Is
it
necessary
for
us
to
dive
into
this,
and
it
is
I,
can
give
you
a
can
give
you
that,
and
after
that
rule,
we've
done
an
ideation
phase
on
that,
and
the
current
phase
in
12
10
is
just
starting
right.
Now
is
going
on
into
the
technical
ideation,
that's
together
with
from
then,
because
this
is
heavily
impacting.
A
You
know
the
visualization
model
of
the
pipeline
to
all
things
going
on,
and
there
are
also
some
concepts
to
be
tested
out
and
hopefully,
internally
I
validate
it
as
well,
13
that
there
will
hopefully
be
the
implementation.
The
last
time
I
showed
this
graph
in
a
different
video.
We
had
a
different
milestone
assigned
to
this,
but
we'll
be
getting
to
that
soon.
A
Let
me
see
so
the
MVC
solution,
which
was
proposed
in
12
to
those
Rebecca
is
here.
It
already
has
an
effect
on
our
visualization
that
it
can
mean
that,
even
though
our
current
pipeline
visualization
only
features
stage
based
pipelines,
it
basically
means
that
no
multiple
jobs
in
different
stages
will
already
begin
running
regardless
of
the
stage
based
visualization
model.
So
it
doesn't
really
feature
or
visualize
well,
what's
actually
happening,
it's
kind
of
blurs
the
partition
on
the
pipeline
itself,
so
we
set
out
to
do
research.
A
We
wanted
to
understand
how
you
know
we
want
to
visually
bridge
that
grab
that
that
graph
between
different
pipeline
models
and
how
we
can
potentially
approach
the
hybrid
AG
model,
where
we
both
have
jobs
that
depend
on
a
stage
based
approach,
but
also
jobs
that
depend
fully
on
a
dag,
based
approach
and
basically
avoid
confusion.
You
know
in
that
in
that
situation,
so
the
hypothesis
is
that
you
know
we're.
A
Currently
confusing
users
pipeline
is
not
sufficient
in
terms
of
like
being
able
to
troubleshoot
failures
being
able
to
see
what
is
going
on,
and
you
know
the
that
we
have
the
idea
that
we
can
showcase
all
the
different
pipeline
models
within
one
my
model
and
don't
need
to
have
multiple
teeth
to
showcase
that
going
on.
We
have
a
few
different
personas.
We
need
to
take
into
mind
with
the
DevOps
engineer
persona,
which
is
our
implemented
persona.
Those
will
be
troubleshooting
the
pipeline
ourselves.
Well,
the
user
personas
are
mostly
interesting.
A
Going
on
and
I
think
there's
some
highlights
to
point
out.
The
order
of
the
jobs
is
most
important
to
know.
Tendencies
should
be
made
visible.
This
is
currently
impossible
in
the
current
pipeline
visualization.
You
know
you
see,
pipelines
are
starting
at
the
same
time
as
jobs
in
other
stages.
That's
the
only
way
to
kind
of
know
that
you
know
a
job
is
a
bad
job
instead
of
a
stage
based
job,
so
we're
currently
not
providing
the
necessary
information
towards
the
user.
Both
the
status
and
the
progress
are
important.
A
A
Let
me
see
the
current
workaround
I
think
it's
kind
of
interesting
now,
if
you
want
to
find
out
if
a
job
blocks
other
jobs,
yes
or
no,
it's
you
have
to
rely
on
scanning
Jaya,
alongs,
reviewing
execution
time
etc,
is
a
very
convoluted
way
to
find
out
these
kind
of
dependency
lines
when
we're
not
showing
them
and,
lastly,
low
logical
groupings
of
jobs
makes
more
sense
index.
I
think
that
one
is
also
very
interesting
with
our
stage
based
prose.
A
We
have
manually
inserted
these
kind
of
models,
but
then
we
are
limiting
ourselves
and
creating
unnecessary
bottlenecks.
We're
DAGs.
We
have
lots
of
opportunities
there
to
group
jobs
together
based
on
generations
of
execution,
for
example,
or
in
other
ways
which
potentially
make
up
future
pipeline
visualization
models,
but
let's,
let's
not
dive
too
deep
there
right
now,
so
we
need
to
support
both
HBase,
pure
dag
and
the
hybrid
model.
A
I
think
it's
kind
of
interesting
to
point
out
the
last
point
here
that
we
do
not
support
this
yet,
but
we
can't
think
about
this
in
the
future
and
it's
kind
of
ideal
if
the
stage
or
if
the
pipeline
model
already
would
support.
This
is
that,
for
example,
if
that
jobs,
so
jobs
that
they
can
depend
on
any
other
job
can
depend
on
stages
itself.
So
even
so
that
would
mean
that
a
job
does
not
depend
on
all
the
jobs
within
that
stage
in
a
way
it
will.
A
But
then
we
can
link
within
our
gearbox
llamó
directly
to
the
stage
itself.
Instead
of
naming
each
job
independently
kind
of
cleaning
up
the
gate,
lopsy
IMO
in
a
way
a
potential
future
material,
though
I'm
grown
over
this
quickly,
because
we're
not
be
touching
all
of
these
visualizations
in
the
MVC,
which
is
gonna,
be
most
important
there,
but
the
pipeline
model
will
have
an
effect
on
both
the
pipeline
graph,
as
well
as
the
mini
pipeline
graph,
which
is
showcased
in
multiple
views.
A
There's
a
loads
of
information,
we're
gonna
need
to
present
the
MVC
will
dial
it
down
a
little.
Let
me
see-
and
this
is
I
think
a
very
interesting
slide
to
go
to,
though
what
is
what
is
the
characteristics
were
looking
for
right.
The
dependency
line
should
have
a
clear
and
expected
structure,
and
that
is
a
kind
of
thing
with
the
dag
jobs
or
with
that
pipeline
visualization,
a
pipeline
can
grow
very
quickly,
very
and
become
very
blurry
very
hard
to
read,
but
it's
a
it's
one
of
the
I
think
key
characteristics.
A
We
need
to
keep
in
mind
when
wanting
to
showcase
our
pipeline
in
gate
lab.
We
have
a
pretty
huge
pipeline,
but
at
the
same
time
it
should
make
sense
for
smaller
ones
and
perhaps
even
bigger
ones,
and
especially
with
those
huge
graphs.
It
should
be
easy
to
read
to
quickly
find
out.
You
know
how
to
troubleshoot
your
pipeline,
there's
a
clear
direction:
kind
of
referencing
back
to
the
dag,
directed
acyclic
graph,
so
the
direction
should
be
clear
from
the
graph
itself.
A
A
You
can
quickly
see
how
some
jobs
are
all
getting
together
and
I
want
to
point
out
here
a
little
bit
in
the
in
the
next
slide,
and
let
me
see
so
I'm
going
to
come
back
here
to
logical
groupings,
so
stage
base
grouping
is
limiting
to
Dax
because
they're
kind
of
creating
these
bottlenecks
and
one
thing
that
always
is
true,
even
in
a
hybrid
model
or
dagger,
a
suppose
or
state-based
process
kind
of
this
execution
order.
Discovery
saw
the
order
of
execution
and
it
kind
of
creates
these
generations.
A
So
I'm
going
here
quickly
through
these
a
bit
I
think
I
need
to
hurry
up
my
my
presentation
a
little,
but
regardless
of
that
I
think
it's
interesting
to
show
that
in
these
both
these
crafts,
it's
kind
of
interesting
to
see
that
we
can
group
them
logically
by
execution.
So,
for
example,
this
job
depends
on
one
generation
before
that,
and
the
next
one
general
on
at
least
two
prior
generations
of
execution
is
a
little
bit
of
a
hard
concept
to
grasp.
A
But
eventually,
every
craft
can
kind
of
be
cut
down
these
kind
of
execution
generations,
and
in
that
way
it
makes
sense
to
visualize
them
so
to
go
on
there's
a
little
bit
of
some
ideation
done
by
me
like
how
I'm
going
to
showcase
this.
What
what
kind
of
things
do
we
have
here
and
let
me
see
lots
of
things
we
can
show,
there's
lots
of
information
to
show
how
we're
gonna
keep
it
sane
by
playing
around
with
that
is
very
important
and
when
you're
gonna,
you
know
play
around
the
with
bigger
models.
A
In
that
case,
it's
gonna.
You
know
it's
gonna,
be
time
intensive
to
create
these
models
and
find
out
if
your
structures
gonna
work.
So
it's
kind
of
like
going
into
the
next
to
the
next
slide.
I,
there's
the
need
to
iterate
and
prototype
faster
I
found
this.
This
is
one
of
a
multitude
of
tools,
these
days
available,
where
we
can
play
around
with
code
and
procedurally
generate
these
kind
of
graphs
so
taking
this
along.
A
These
are
some
examples
found
on
the
internet
created
and
observable,
and
eventually
I
found
these
to
be
kind
of
the
right
direction.
In
terms
of
what
I
was
looking
for,
it
has
a
clear
direction
and
it
kind
of
points
out
similar
to
a
metro
map
which
jobs
are
more
important
because
they
have
other
jobs
depend
on
them.
If
those
jobs
fail,
you
immediately
know
like
hey.
A
These
are
very
important
for
future
jobs
to
succeed,
faster
or
succeed,
more
often,
for
example,
going
on
these
kind
of
like
adjusting
the
the
graph
played
around
with
it
and
and
created
these
kind
of
generations,
which
makes
sense
for,
for
our
use
case
the
about
two
minutes
left
that
makes
sense
almost
at
the
end,
though.
So,
let's
skip
ahead
here.
We
see
a
little
bit
of
a
simpler
model
that
represents
the
same
data,
but
the
script
is
failing.
So
let's
get
ahead
and
then
I'm
gonna
show
you
some
things
here.
A
So
there's
a
proposal
of
like
how
we
can
showcase
some
of
the
elements
within
the
future.
What
we're
gonna
do
here
is
in
the
MVC
scope,
we're
gonna
create
a
dag
pipeline
tab
which
is
going
to
showcase
just
the
dag
pipeline.
This
way
we're
gonna
alleviate
any
risk
worth
altering.
The
current
pipeline
visualization
slowly
make
this
better
over
time.
It's
gonna
focus
solely
on
the
dag
visualization,
but
it
will
feature
any
somebody
both
stage
based
as
well
as
dag
jobs,
and
then
I
can
kind
of
showcase.
A
What
is
up
next
so
currently
we're
busy
with
technical
ideation
in
13
and
over
there
will
be
implementation
and
there's
some
need
in
terms
of
like
what
came
out
of
the
research
for
performance,
optimization
and
different
logical
groupings
would
have
talked
about
before
and
there's
some
other
things.
You
know
somewhat
refused.
We
need
to
support
in
the
future
as
well,
and
then
we
go
to
a
little
sneak
peek
of
how
this
then
would
look.
For
example,
in
the
left
one.
A
We
see
a
simpler
view
where
you
can
see
like,
for
example,
that
the
jobs
in
this
in
the
second
stage
depend
on
this
one's
job
in
the
first
stage,
and
this
is
better
visualized
in
the
second
view,
where
you
can
see
those
jobs
kind
of
growing
in
size,
the
more
jobs
depend
on
it,
and
this
is
kind
of
like
the
idea.
With
the
MVC
approach.
A
We're
just
gonna
show
the
ID
information
of
the
job,
the
status
and
its
dependency
lines
and
we'll
be
shown
that
a
side
of
the
normal
pipeline
graph
kind
of
giving
us
an
option
to
alleviate
risk,
but
also
internally,
validate
this
and
and
build
upon
from
there.
So
these
are
the
things
busy
we're
busy
with
for
the
tech
visualization.