►
Description
Agenda: https://docs.google.com/document/d/1-uH7Ta6JBcAeFumzBV-dqa0OnFEaFEVsr9Khfdwe61o/edit?usp=sharing
Discussed issue: https://gitlab.com/gitlab-org/gitlab/-/issues/15622
A
So
I
just
wanted
to
see
if
there
was
sort
of
a
boring
solution
that
we
could
come
up
with
that'll,
let
us
ship
something
in
13
for
and
then
we
can
iterate
on
it
and
shift
the
actual
thing
that
we
want
to
ship.
You
know
going
forward
so
a
couple
of
questions.
I
had
to
begin
with:
there's
actually
no
back-end
engineers
here
so,
but
do
we
have
everything
we
need
from
back
end
to
get
this
done?
If
that's
a
no,
then
obviously
we'll
need
to
get
someone
from
back
end
involved.
C
C
Just
taking
like
the
if
we're
just
taking
the
stage
name
and
the
job
name,
that's
rendered
and
showing
that
that's
in
the
yaml
file.
So
then
we
don't
need
a
back-end
engineer,
because
we
can
get
that
and
I
believe
it's
in
the
dom
anyway
and
translate
that
into
json
and
then
use
the
json
to
draw
the
graph.
And
that
should
be
fine.
If.
B
Yeah
that
what
you
described
as
just
not
ex
expanding
things-
and
I'm
glad
you
explained
what
you
meant
by
expanding
then
that's
all
we
want
for
the
very
first
iteration
and
but
we
I
did
have
a
there-
is
a
thing
about
expansion
that
I
want
to
ask
about
later.
But
maybe
it's
going
to
be
moot
based
on
agenda
item
number
two
of
the
second
suggestion,
but
I
think
so
the
answer
to
your
question.
Sam
is:
we
do
have
everything
we
need
with
no
additional
back
back-end
work
to
be
done.
C
B
C
E
B
C
Well,
and
not
necessarily
including
jobs
that
are
included
through,
includes
which
I
know
I
just
said,
included
like
eight
times
but
right
like
if
you
look
at
the
get
lab
ui
yaml
the
get
lab
ci
like
our
yaml
for
the
gitlab
project.
You
can
see
that
we
actually
don't
have
like
a
list
of
jobs
and
stages.
We
just
have
all
of
these
includes
so.
C
It
would
probably
just
show
the
stages,
and
then
we
can
see
what
we
can
show
so
that
it's
not
like
total
like
right.
We
might
be
able
to
show
the
stages
in
just
something
that
says
it
includes
this
file
and
not
expand
that
and
then
because
that's
in
the
yaml
file,
so
basically
we
cannot
commit
to
showing
anything
that
is
not
as
it
is
exactly
written
in
the
yaml
file.
E
B
E
B
E
B
C
B
C
B
Okay-
and
I
want
to
I
want
to-
let
me
share
my
screen,
because
I
have
a
question
for
you
by
that
about
that,
and
I
totally
think
that
makes
it
even
simpler
for
the
very
first
iteration
is
it?
Does
it
make
it
harder?
It
does.
It
add
complexity
to
attitude
like
if
we
had
this,
the
the
yaml
as
the
first
tab
and
another
tab
is
adding
tabs
to
a
page
like
this
difficult
do.
We
know.
C
In
this
case,
I
do
not
believe
so.
There
might
be
pages
where
there's
hidden
difficulty,
but
it's
usually
not
like.
We
have
a
view
component
that
the
cases
it
would
be
complex
is
if
it
only
has
haml
for
some
reason
if
the
code
causes
a
problem,
but
otherwise
we
have
a
tab
component
that
we
can
put
in
and
that
handles
all
the
switching
between
it.
So
it
should
not
be
a
lot
of
work.
D
A
B
Okay,
right
and
then
the
alternative
is,
is
it
is
another
option?
That's
not
a
lot
more
complex
linking
giving
them
a
link
to
go
see
it
because
I
could
well.
I
guess
they
could
open
the
tab
open
the
same
page
in
two
windows
and
then
have
one
with
that
with
either
tab
display.
What
about
what?
I
think
that
would
work?
F
Yeah,
I
think
it's
perfectly
fine,
because
since
we
are
not
going
to
move
ahead
with
the
same
editor
and
we
would
want
to
move
to
web
ide,
so
this
duplication
of
efforts-
I
mean
it
would
just
increase
the
work.
So
I
agree
I
mean
we
can
work
on
a
work
around
for
this
regular
view
like
a
tab
or
I
think
a
tab
should
be
fine
because
they
can
easily
toggle
between
the
two.
B
C
Okay:
okay,
although
it's
not
if
you
have
a
bunch
of
other
stuff
on
your
plate
like
if
we're
green,
it's
gonna
be
a
tab.
This
is
also
the
kind
of
thing
that,
like
there
are
other
bigger
plans
that
are
more
important
than
you
drawing
me
a
picture
of
it
with
a
tab.
I
can
also
you
know,
do
a
tab
and
send
you
a
screenshot
and
feel
like
like
we
can
do
that
smaller
iteration
too.
If
you
have
bigger
things
to
work
on,
that's
like
totally.
B
C
Don't
see
why
I
don't
see
why
not
and
if,
when
fred
comes
back,
I
pass
it
off
to
him.
I
can
handle
the
communication
on
our
team.
That's
not
a
big
deal.
Okay,
I
did
the
whole
dad
graph
and
he
had
done
a
bunch
of
work
on
it.
So
if
he
really
wants
to
work
on
this,
I
might
pass
it
to
him
next
week,
so
he
can
have
fun
laying
things
out,
because
I
know
he
likes
to
do
that,
but
I
will
make
sure
that
this
is
communicated.
B
B
B
Avitika,
actually
we
talked
about
that
before
and
there's
there's
a
couple
reasons
why
I
didn't
want
to
create.
I
was
going
to
actually
promote
this
to
an
epic
and
create
some
smaller
issues
under
it.
I
think
there's
and
simply
because
there
was
going
to
be
a
lot
of
feedback
added
to
this
issue.
That
is
not
going
to
pertain
to
the
the
mvc,
and
so
there
are
a
couple
reasons
why
I
didn't
want
to
do
that.
The
there's
a
lot
of
folks
watching
this
one
and
based
on
the
up
votes
too.
B
C
I
don't
think
we
need
to
redirect
everyone
to
that
issue,
but
a
newer
issue
just
talking
about
what
we're
making
would
be
helpful.
I
I
realize
this
is
like
a
certain
tension,
but
like
there's
also
the
understanding
about
like
what
page
this
was
on
and
what
exactly
it
was
entailing,
and
a
lot
of
that
is
because
this
is
like,
I
feel
like
this
issue
is
trying
to
do
too
much
yeah,
so
I
think
making
a
new
one
and
linking
it
to
be
like
hey.
This
is
where
we
are
literally
making
the
most
boring
solution.
C
B
Yeah,
the
the
yeah,
the
other
thing.
Sarah,
is
this
issue
this
first
iteration
we're
probably
not
going
to
continue
building
on
it.
If
I
knew
this
had
a
future
after
a
first
iteration,
because
it
I'm
gonna,
guess
we're
gonna
eventually
do
future
iterations
in
the
web.
Ide
editor
and
not
continue
this,
and
I
don't
want
this
to
continue
to
be
built
out
with
a
an
epic
and
a
lot
of
sub
issues
like
it's
going
to
have
a
life
of
its
own.
B
But
really
it's
it's
a
interim
solution
that,
but
so,
let's
figure
out
what
we
want
to
do
for
the
initial
iteration
and
I'll.
Look
through
this
issue
because
you're
right,
there's
so
many
ideas
in
this
and
most
of
the
ideas
that
we
got
from
the
feedback
is
not
going
to
go
into
this
simple
editor
at
all.
So
it's
yeah
and
if
I
made
this
into
an
epic
it
might
it
takes
away
from
the
other
epic
for
building
things
out
in
the
web
ide,
which
already
exists
with
its
own
set
of
issues?
B
B
So
I
will
list
out
in
the
proposal
that
it'll
be
a
not
a
side-by-side
view
as
the
design
shows,
which
will
be
reworked
but
a
separate
tabs
view.
The
other
thing,
the
other.
I
had
another
question:
if
we,
if
you
actually
look
at
the
design,
this
page
two
of
the
design,
the
latest
one
we
did
mention
okay,
so
we
do
scope
number
four.
B
Other
than
simplifying
it
by
not
having
a
side-by-side
view,
which
also
by
the
way,
does
away
with
our
question
about
you,
the
slider
adjustment
we
won't
need
that
feature.
Is
there
anything
else
we
can
do
to
make
it
simpler?
Is
it
showing
the
visual
connection
between
two
jobs
that
has
one
dependent
on
the
other
because
of
the
needs
key
work?
Does
that
make
it
any
more
complex?
Sarah.
C
F
C
I
think
that's
okay.
I
am
sort
of
keeping
in
mind
the
designs
from
there
so
like
one
of
my
ultimate
hopes
for
this
project
as
well.
Is
that
right
now,
the
pipeline
pages
that
big
pipeline
graph,
as
we've
seen
in
some
other
css
stuff
lately,
is
like
this
fixed
layout?
That
makes
it
super
super
brittle
and
you
like
sneeze
on
it
and
it
breaks,
and
so
my
goal
is
that
by
building
up
this
version,
which
will
be
a
more
relative
layout,
we
can
eventually
use
that
to
create
the
new
version.
C
So
the
goal
in
like
doing
this
code
isn't
to
create
something
entirely
different,
but
to
like
rework
what
we
can
so
that,
like
I'm
thinking
about
how
we
can
make
all
of
these,
how
we
can
make
that
a
unified
view,
because
in
the
end
it
is
right,
it's
the
same
view
with
different
functionalities.
So
we
won't
be
showing
like
job
statuses
in
one,
but
we
should
like
be
fundamentally
under
the
covers
making
them
the
same
thing.
B
F
B
F
C
B
F
C
B
You
know
when
I
look
at
this
one,
it
does
looks
like
okay,
yeah,
okay,
understood
all
right
and
then
one
last
question
I
have
for
you,
sarah
is,
is
one
of
the
elements
of
the
design
for
the
issue.
We're
talking
about
has
a
different
background,
like
it
looks
grayed
out
when
it's
a
stage
without
any
jobs
which
requires,
I
guess
the
front
end
code
to
to
go
through
the
entire
yaml
file
to
figure
out
which
ones
don't
have
is.
Is
that
making
more
complex?
F
F
I
think
for
visualization
that
would
not
be
required,
because
when,
when
users
are
looking
at
this
visualization
under
the
pipeline
start,
they
would
perform
different
set
of
interactions.
So
they
would
want
to
know
the
dependencies
and
all
of
that,
but
they
wouldn't
be
using
the
same
interactions
when
they're.
Creating
the
file
is
what
I
believe.
F
C
So
I
think
what
tao
was
asking
is:
do
we
for
this
version
of
the
visualization
which
is
static?
Do
we
need
to
show
that
some
can
we
and
do
we
need
to
show
that
some
of
the
stages
don't
have
jobs,
and
I
there's
two
things
that
I
don't
know
so
one
I
don't
know
if
it's
possible
to
make
a
ci
file
that
has
a
stage
with
no
jobs
in
it.
I'd
have
to
check.
If
that
would
pass
our
lint,
I
mean
it.
Might
it
might
not?
B
B
C
Yes,
but
to
draw
it,
we
need
to
know
if
there's
jobs
underneath
it
so
assuming
it's
possible
to
have
a
stage
with
no
jobs,
then
making
that
on
the
front
end,
isn't
really
a
problem,
because
we
have
to
know
to
draw
it
so
like
we
can
essentially
just
be
like.
Does
this
group
have
children
or
not,
then
it
should
be
fine.
B
B
We
will
show
active
stages
that
have
jobs
will
be
a
darker
background
than
stages
that
don't
have
jobs,
but
we
won't.
I
would
like
that
we
don't
hide
the
stages
that
don't
have
jobs
to
display
them
somehow,
and
then
I
think
you
said
sarah,
it's
it's
doable
to
have
a
connector
between
dependent
jobs.
C
I
believe
so
that
is
definitely
a
next
layer,
so
we
will
make
it
its
own,
mr
yeah,
so
that
we
can
ship
the
first
thing
and
then
ship
the
next
thing.
That's
the
thing
that
I'm
like.
I
cannot
tell
you
right
now:
a
hundred
percent
will
go
in
thirteen
four,
but
we'll
see
what
we
can
do
about
it
and
separate
them
off.
So
it
doesn't
hold
up
everything
else.
B
C
Right
and
then
regarding
the
web
ide,
as
I've
mentioned
before,
I
got
dennis
who's
working
on
it
to
schedule
a
deep
dive
about
the
new
stuff.
That's
coming
up
because
he's
working
on
making
it
easy
for
people
to
plug
in
visualizations
like
this,
also
to
like
render
markdown
and
a
bunch
of
other
stuff.
So
we
started
working
on
what
that's
going
to
look
like
from
an
engineering
perspective
so
that,
when
we're
ready
to
work
on
it,
we
like
understand
the
ground.
B
Sounds
good
and
this
initial
version,
I
know
we've
gotten
a
lot
of
feedback
already,
but
this
initial
version
will
let
us
kind
of
learn
some
things
about
this
and
then
really
start
to
take
off
on
the
making
the
feature
even
better
in
the
next
in
the
web
editor
and
the
web
id
editor.
Okay,
I'm
good!
I
don't
have
any
other
questions,
anything
for
me.
301.