►
From YouTube: Frontend Plan kickoff for 12.4
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
All
right,
everyone
see
cool,
ok,
so
no
security
issues
for
12:4.
It's
exciting
we've
got
a
couple
in
12
3
that
we
are
working
on,
but
this
should
be
finished
fairly
soon.
So
move
on
to
the
bugs.
There
also
isn't
any
major
bugs
the
highest
priority:
prioritized
bugs
are
P
trees
and
s
threes.
There
is
one:
that's
getting
a
little
bit
larger
this
one
I
know
a
couple
of
you
have
noticed
this
kinda
pocket
just
commented
on
it.
A
It
seems
to
be
hitting
more
people
more
often
so
I
think
I'm,
gonna,
move
it
into
12
4
and
see.
If
we
can
take
a
look
at
it,
I
don't
know
because
nothing's
changed
I
think
it's
an
issue
with
with
the
newest
version
of
WebKit.
So
we
first
saw
this
on
the
edge
dead
stream
and
then
it
made
it
into
the
chrome,
but
now
that
it's
in
chrome,
it's
happening
a
lot
more.
A
A
Not
so
much
better
at
being
predictable,
but
just
getting
a
better
handle
on
expectations
we
can
set
with
our
customers.
That
being
said,
let's
move
on
to
the
technical
bits
lash
backstage
stuff.
The
first
one
we
have
here
is
one
that
cushaw
was
already
working
on.
It's
you
scratched
you
out
for
a
road
map
we're
already
well
Chris.
All
you
want
to
talk
through.
Yes,.
B
So
it
basically
converts
the
road
map
app
to
use
graph
QL
because
in
other
places
like
if
you
load
up
a
paper
today
and
once
we
enable
the
epic
crease
feature
flag,
the
tree
tab
that
you
would
see
loads
the
data
biographical.
So
you
want
to
unify
all
the
places
where
epic
data
is
fetched
and
we
want
to
move
all
the
requests
to
graph.
So
it
is
around
the
roadmap
and
once
we
have
both
road
map
tab
and
epic
tree
using
graph
QL,
which
is
the
second
issue
in
the
technical
debt.
B
What
we'll
do
is
that
we
will
combine
both
the
network
requests
so
when
the
page
loads
and
then
when
you
are
viewing
any
existing
epic,
both
the
data,
both
the
tabs
are
data,
be
it
a
factory
or
the
road
map,
will
be
loaded
biographical
and
will
be
doing
only
single
file.
So
it
is
basically
foundational
work
for
the
road
map
part.
So
once
that
is
done,
we
can
work
on
this.
Unify
API,
call
solution.
A
This
is
kind
of
the
first
step,
ideally
because
we
want
to
eventually
start
experimenting
with
with
real
time
on
the
sidebar
and
there's
also
a
whole
bunch
of
sidebar
improvements
that
are
upcoming,
which
we'll
see
a
little
bit
later
and
one
that
Scott
is
doing
also.
But
as
far
as
this
one
goes,
all
you
want
to
talk
through
this
a
little
bit.
Also,
yes,.
B
So
currently,
when
you
look
at
the
right
sidebar,
where
we,
where
we
see
basically
assignee
information
label,
suffix,
milestone,
etc.
So
this
sidebar
currently
has
three
implementations
across
this
lab.
One
that
we
have
now
is
the
Hamel
one
which
you
are
seeing
right
now
like.
If
you
visit
any
issues
or
modulus,
the
right
sidebar
is
implemented,
so
the
wrapper
itself
is
implemented
by
a
Hamel,
but
there
are
parts
of
it
which
are
implemented
in
view
like
the
epic
drop
down
the
labors
drop
down
miles
from
drop
down.
B
Those
are
all
scattered
in
jsn
view,
so
it
is
like
a
fusion
of
Hamel
J's
and
view
across
the
places,
and
if
you
visit
the
epic
page
itself
there,
the
entire
sidebar
is
implemented
in
view,
and
if
you
open
issue
boots
there,
if
you
click
on
any
card
and
the
right
side
bar
is
revealed
so
that
sidebar
implementation
is
also
done
in
view.
So
we
are
kind
of
unifying
all
the
different
approaches
and
making
a
single
sidebar
implementation
that
is
available
across
gitlab,
so
that
will
help
us
getting
rid
of
a
lot
of
technical
debt.
B
Because
currently,
if
you
want
to
modify
sidebar,
then
there
are
multiple
cases
where
you
would
have
to
touch
and
do
the
changes,
and
it
is
not
very
maintainable
to
be
also
will
basically
unify
all.
The
approaches
will
create
a
single
side
bar
wrapper
in
view,
and
hopefully
will
do
the
data
fetch
using
rough
QL,
and
maybe
we
would
use
either
WebSockets
in
vanilla
or
we
would
do
graph
to
your
subscription.
But
that
is
that
comes
later.
B
First
part
is
to
create
the
wrapper
first
so
that
all
the
sidebar
implementations
are
a
consistent
across
Kaitlyn
and
we'll
start
by
working
on
this
behind
feature
flag,
and
we
would
implement
the
common
parts
which
are
shared
by
issues
multi,
quests
and
epics,
so
that
we
have
all
the
things
available
biographical
and
in
the
later
releases
we
would
add
specific
items
for
specific
context,
because
idler
needs
to
be
context.
Aware,
like
not
all
the
items
that
you
see
in
the
issues.
A
Where
is
the
one
here
all
right,
so
this
one
is
our
first
new
sidebar
in
a
while,
ideally
we'd,
use
that
that
shared
sidebar
once
it's
done
yeah.
So
here
has
a
few
new
components
that
we
have
and
that
we
don't
use
in
other
places
like
the
work-in-progress
limit,
and
we
may
be
able
to
share
components
here.
B
I
think
it
would
be
wise
not
to
combine
this
sidebar
item
or
the
wrapper
itself
with
the
actual
sidebar
that
we
are
working
on,
because
this
is
very
specific
to
issue
boards
and
I
think
it
would
be
easier
to
maintain
this
sidebar.
If
we
do
not
plan
to
add
additional
items
in
the
sidebar
like
I
can
see
that
there
is
this
label
list,
but
are
we
planning
to
change
label
from
here
like?
B
If
someone
decides
to
change
the
label
for
an
entire
list,
then
would
it
be
possible
I,
don't
see
how
one
would
do
that,
because
that
would
lead
to
a
lot
of
changes
like
all
the
issues
within
the
list
would
be
changed
with
a
different
label.
So
if
that's
not
the
case,
then
I
think
it
makes
sense
to
have
the
sidebar
entirely
separate
from
the
rest
of
the
implementation
that
we
are
planning.
Okay,.
A
Okay,
cool
this
just
added,
it
is
the
so
now
that
we've
started
to
finish
with
the
first
three
phases
of
moving
stuff
over
to
get
lab
UI,
which
we
did
for
a
label
component
last
release
or
the
release
before
now.
We
want
to
start
the
implementation
step,
we're
actually
using
those
get
lab
UI
components
in
the
majority
of
places
in
get
lab
the
product.
So
this
is
that
this
is
a
step
in
that,
for
labels
will
start
with
scope
labels
just
because
there
are
quite
a
few
places
where
we
want
to
change
scope.
A
Labels,
scope,
scope,
labels.
We
want
to
change
the
UI
of
like
the
question
mark
and
really
the
only
the
easiest
way
to
do.
That
is
to
get
every
place
using
the
single
shared
component.
That's
what
this
one's
for.
It
might
be
higher
than
a
weight
to
another
dot,
you're,
probably
the
expert
on
scope
labels.
How
many?
How
many
places
use
scope,
labels.
D
A
We'll
have
to
figure
that
out
also
because
we,
the
way
we
used
utility
classes.
The
idea
was
that
we
could
just
add
the
component
styles
as
a
utility
class
and
then
be
able
to
use
it
in
Hamill.
In
reality,
I
don't
know
if
that
works
at
so
maybe
three
for
now,
and
then,
if
we
discover
that
it's
more
than
that,
we
can
change
it.
A
We
should
get
to
those
now,
because
there
are
also
a
few
component,
a
few
places
where
we
want
to
update
the
drop
down
drop
down
component,
and
we
can't
really
do
that
until
that
has
been
that
has
been
finished
in
get
lab,
UI,
so
Scott's,
taking
both
of
these
nicely
done,
Scott
he
is
going
to
be
our
new
get
lab.
Ui
expert
after
at
the
end
of
this
release
is.
C
C
A
B
A
A
C
B
C
B
I
think
so
there
are
a
couple
of
four
things
here
like
if
we
plan
to
show
on
the
so.
The
reader
proposal
that
Hannibal
had
was
that
we
should
be
able
to
show
total
count
of
issues
and
epics
available
in
the
entire
tree.
That
means
that
all
the
children
items
are
also
considered
in
the
counting.
That's
not
the
case
right
now.
If
you
currently
expand
any
of
the
node,
and
if
it
reveals
more
items,
then
we
update
the
counter.
So
that's
a
problem
there,
because
then
the
number
would
be
dynamic.
B
A
Yeah,
so
it
sounds
like
we
still
need
to
do
a
little
bit
of
thinking
through
that,
a
little
bit
of
research
into
that.
So
it's
blocked
right
now
once
it
because
I
don't
really
think
it
is
blocked,
because
it
is
just
by
the
feature
flag
like
we
can
technically
start
working
on
it
I
think
I'm
gonna
move
it
back
to
planning.
So
we
can
start.
We
can
think
through
some
of
those
issues
before
we
actually
get
to
work
on
on
development
of
it.
A
A
Okay,
this
one
is
already
in
rugby.
You
I
think
it
just
got
moved
back
we're
just
waiting
on
some
of
the
back
and
review
I.
Think
on
this.
So
this
one
we
don't
even
really
have
to
go
through
next
one
create
issue
from
epoch:
that's
the
one!
When
he's
working
on
its
just,
then
we
had
a
little
bit
of
a
conversation
around
it
last
week
around
where
to
put
this
it'll
essentially
be
in
the
new
tree
view.
It's
just
adding
the
ability
to
create
an
issue
from
within
an
epic.
A
A
A
C
A
A
A
A
Okay,
wait
in
progress
information
in
roadmap,
epoch
bars,
so
this
is
not
in
UX.
Oh
looks
like
it
was
just
updated
to
being
UX
ready,
so
this
is
showing
a
little
progress
bar
comparing
weights
to
or
weights
come
up
issues
completed
versus
weight
of
issues
inside
of
that
total
weight
inside
of
that
epic,
or
of
issues
inside
of
that
epic.
A
Okay,
so
this
is
the
same
issue
for
both
back-end
and
front-end
I,
don't
think
that
is
available
in
the
API
yet
so
this
should
probably
be
a
little
bit
higher
than
a
two
also,
but
that
is
a
three
for
now
make
sense.
Everyone,
though,
cool
all
right,
hi
labels
from
issue
board
cards.
We
are
currently
doing.
This
was
UX
ready,
and
then
we
decided
to
do
a
little
bit
more
UX
research
on
it.
A
I
need
to
see
where
we're
at
as
far
as
the
research,
but
it's
just
a
kind
of
convenience
toggle
here
because
like
for
us
when
we,
where
we
have
a
lot
of
labels,
it
can
get
pretty
pretty
overwhelming
with
all
the
labels,
so
this
just
turned
off
the
the
labels.
So
you
view
just
the
titles
essentially,
but
this
is
still.
This
is
not
ready
to
be
worked
on
yet
because
again,
I
need
to
see
where
red,
as
far
as
the
research
side
of
things.
A
Okay,
these
last
two
ones
are
just
updates
to
a
couple
places
where
we
currently
use
an
alert
to
switch
that
to
using
the
collab
UI
modal.
The
gate
lab
UI
modal
is
not
complete.
Yet
that
was
last
time
I
checked,
which
was
the
end
of
12
3.
It
was
very
close,
I
think
within
the
week
within
probably
this
week,
we'll
be
done
or
able
to
use
the
modal
in
git
web
UI
so
hold
on
this
until
until
next
week,.
A
A
C
I'd
sorry
I
had
a
question.
Yep
I
was
muted
now
sake,
so
witty
had
added
some
tickets
around
refactoring
them.
The
board
list
I
believe
her
board.
There's
there's
some.
It
didn't
have
to
do
with
graph
QL,
but
it
was
like
decoupling
from
our
existing
like
boards
store
and
using
our
board
service
for
visors.
Is
that
something
that
we
need
to
start
pulling
into
just
given
we're
touching
a
lot
of
that
code?
I
am
yeah.
A
A
A
You
yeah
what
else?
Okay!
Well
it's
great,
seeing
you
all
have
a
good
thanks
for
actually
joining
on
the
late-night
for
some
and
early
morning
for
others
and
right
at
my
ideal
time.
So
we
do.
We
should
figure
out
what
we
want
to
do
for
other
releases,
because
now
we
don't
really
have
like
an
optimal
time
that
everyone
can
that
everyone
can
join.
So
maybe
and
that's
where
Michelle
was
talking
through
that
demo
that
demo
video,
but
if
we
could
figure
out
maybe
an
async
way
of
doing
this.