►
From YouTube: Development Group Conversation (Public Stream)
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
Good
morning,
good
afternoon,
good
evening,
git
lab,
I
am
christopher
levels.
I
am
the
vpd
responsible
for
the
development
department,
and
this
is
the
development
group
conversation.
It
is
march,
2nd
2021.
A
Please
please
look
into
the
agenda
document
for
adding
questions.
There
should
be
two
links
in
there.
One
is
to
a
video
if
you
want
to
listen
to
that
in
fast
forward
mode
quickly,
while
we're
talking
you
can
be
free
to
do
that
and
there's
as
well
slide
deck,
where
we
have
information
around
that.
So
I'm
looking
forward
to
your
questions
and
because
we
believe
in
iteration
we
iterated
overnight
and
tim
added,
a
couple
slides,
which
is
awesome.
So
the
first
question
is
from
actually
me
tim.
B
Yes,
happy
to
do
so
and
yeah
as
I
wrote
it,
I
was
a
little
bit
excited
about
the
results
that
we
just
got
in
from
the
measurements,
and
so
I
simply
added
them,
as
I
didn't
want
to
wait
for
another
couple
of
weeks
to
share
them
in
a
brighter
wider
perspective.
And
so
what?
What
are
those
results?
The
results
are
simply
a
little
bit
of
research.
B
That
happened
over
the
last
couple
of
weeks
of
simply
combining
multiple
ideas
that
were
going
on
here
and
there
over
the
last
couple
of
months
into
one
poc
to
figure
out
what
would
be
some
results
that
we
would
be
getting
out
of
implementing
some
ideas
in
the
near
future
and
as
I
really
wanted
to
know
that
we
started
with
a
clear
focus
on
measuring
workflows,
because
I
strongly
believe
we,
we
have
really
focused
over
the
last
year,
a
lot
on
the
loading
performance
which
is
really
important,
because
if
you
can't
see
anything,
you
can't
click
anything.
B
C
B
Improving
step
by
step,
the
workflows
that
users,
so
you
and
me,
and
also
all
our
customers
are
doing
on
a
daily
basis,
improving
them
step
by
step.
This
can
be
either
be
done
through
ux,
so
really
improving
how
to
find
stuff
how
stuff
is
going
on,
but
on
the
other
hand,
and
that's
the
development
part,
is
really
bad
actual
application
performance
and
that's
what
this
research
was
about.
B
So
we
started
to
build
a
framework
of
measuring
a
full
workflow,
and
this
is
really
the
base
definition,
as
especially
the
repository
browser
is
quite
easy
to
really
start
off.
Measuring.
Okay,
you
go
to
a
project.
You
go
two
directories
deep.
You
click
on
a
file,
you
go
back
and
you
click
on
another
file.
How
long
does
the
whole
process
take
and
how
long
would
this
compare
to
a
new
solution?
The
new
solution
is
combining.
B
Currently
we
have
two
different
one
view
app
and
one
non-view
app,
and
we
are
basically
switching
back
and
forth
and
the
idea
is
to
combine
both
into
one
and
through
that
we
can
use
some
tricks.
Some
optimization,
some
magic
tricks
to
simply
do
a
little
of
preloading.
So
something
that
we
were
talking
about
actually,
if
we
we
touched
this
topic
already
like
one
and
a
half
years
ago
in
one
of
those
group
conversations
is
mouse
over
preloading.
B
So
this
is
something
we
can't
do
really
at
the
moment
due
to
our
caching
and
how
everything
is
set
up.
But
what
we
are
trying
to
leverage
is
the
fact
that
if
you
mouse
over
a
link
or
anything
that
you
click,
your
brain
still
takes
some
time
to
actually
tell
your
finger
to
click
on
the
mouse
and
then
if
this
goes
through
etc.
So
this
is
in
on
average
like
250
milliseconds,
I
believe
so.
B
The
next
idea
is
integrating
the
monaco
editor
that
we
are
already
using
in
the
web
ide
and
in
the
single
file
editing
to
use
that
for
showing
code,
because
then
we
have
a
unified
experience
and
the
big
advantages
we
are
offloading
all
the
line,
highlighting
all
the
code
from
which
is
pretty
heavy
on
our
back
end
to
the
front
end
to
the
client,
where
we
are
already
doing
this.
This
was
something
that
we
never
had
a
couple
of
years
back.
That
was
doing
proper
line
highlighting,
but
this
is
highly
optimized.
B
That
is
the
same
editor
that
vs
code
is
using.
That
github
is
using
in
all
their
applications.
So
this
enables
us
to
load
really
huge
files.
Everyone
who
has
ever
added
a
team
yammer.
This
now
literally
takes
400
milliseconds
to
go
from
the
click
to
actually
seeing
the
30
000
line
file,
and
then
this
is
the
next
advantage.
We
can
then
take
and
integrate
their
signified
editing
experience.
So,
as
we
already
have
the
editor
on
the
screen,
we
just
switched
from
read
only
to
right
mode.
B
So
the
switch
to
editing,
I
think,
takes
literally
100
milliseconds
and
those
things
were
measured
and
the
results
are
basically
from
the
pc
of
measuring
this
locally.
So
this
is
not
final
numbers.
We
even
hope
that
the
final
numbers
might
be
better.
So
what
we
have
seen
is
that
we
are
28
faster
in
some
experience.
It
was
even
faster
on
just
navigating,
through
the
whole
thing,
on
opening
a
large
file,
so
the
team
yammer
file
was
57
faster
overall
and
editing
a
file
so
really
going
until
you
can
edit.
B
The
thing
was
38
faster
and
all
the
the
research
that
we
are
doing.
There
is
also
something
that
we
want
to
take
and
take
also
over
to
some
more
focused
workflows,
like
plan
plan
is
also
you
are
most
probably
switching
back
and
forth
between
your
board
and
your
detail.
Page
you're,
switching
most
project
back
and
forth
between
your
mr
list
and
your
mr
as
an
engineer,
and
those
are
things
that
we
could
combine
and
preload
already
in
a
quite
intelligent
way
in
predictive
ways,
some
stuff,
so
that
the
whole
experience
feels
more
instant.
B
If
you
click
on
the
links
of
the
the
comparison
videos,
you
can
even
see
basically
the
current
version,
how
it
compares
to
the
new
version
and
stuff
like
that.
That
can
give
you
more
insights
and
yeah
epic
is
written.
I
handed
it
off
to
the
engineering
team
of
source
code.
They
are
going
to
start
looking
at
it
and
weighing
what
what
is
actually
needed
to
get
this
to
production,
hopefully
as
soon
as
possible.
A
Thanks
tim
and
late
breaking
changes,
our
inputs
is
always
accepted.
The
only
request
I
have
is
that
actually
the
slide
deck
is
editable,
so
the
only
request
I
have
is
that
you
don't
delete
the
slide
deck,
but
we
believe
in
you
know
real
time,
iteration
and
collaboration,
so
it's
always
welcome
to
get
inputs
sam.
You
have
a
point
want
to
make.
D
Yeah,
I
just
that's
really
great
tim
and
thanks
for
walking
us
all
through
that.
I
was
wondering
if
you
had
any
kind
of
thoughts
or
expectations
about
how
it
may
or
may
not
affect
the
sus
score,
the
ux
score
that
we
run.
I
know
performance
in
there
has
been
a
theme.
B
Yeah,
I
think
that
this
is,
I
would
say,
50
percent
of
the
sus
experience
that
flows
into
there
is
is
simply
loading
and
the
other
part
is
the
action.
So
if
you
click
on
something-
and
there
is
just
a
loading
circle
for
20
30
seconds-
you
have
no
clue
if
this
is
actually
going
to
work
or
how
long
this
takes
etc.
B
This
is
a
pretty
bad
experience
and
anything
that
we
can
do,
especially
if
browsing
through
files
if
browsing
for
chrome
version
quest.
This
is
your
main
work
during
the
day,
all
those
major
workflows.
If
we
are
really
focusing
on
on
those,
I
think
that's
where
we
can
make
also
the
biggest
impact
on
the
underscore,
because
that's
what
what
will
stick
with
the
user
after
they
have
used
gitlab
they
can,
if
they
click
on
a
link
once
a
month
or
so
for,
set
editing
some
admin
settings
somewhere
yeah.
I
think
they
will
forget
this
quite
soon.
B
If
this
takes
10
or
15
seconds,
but
your
daily
tasks,
everything
that
we
can
improve,
if
you
just
combine
it,
if
we
make
this
one
minute
faster
over
your
whole
day,
this
is
already
like
a
couple
of
minutes
per
week
and
per
month,
etc,
and
this
this
really
multiplies
and
and
combining
this
also
with
everything
that
ux
is
working
on
on
making
stuff
easier
and
making
stuff
more
easier
to
access
and
and
more
streamlined,
especially
around
the
things.
E
I'll
just
jump
in
and
say
I
agree
tim,
you
and
I
have
worked
really
closely
together
for
a
couple
of
years
now
and
your
focus
on
ux
is
so
very
valuable.
Performance
is
one
of
the
key
negative
themes
in
sus,
which
is
why
it's
part
of
our
shared
okr.
This
quarter,
users
do
care
about
this
and
they
do
think
about
it
in
the
context
of
user
experience.
So,
like
tim,
I
expect,
as
we
continue
to
make
these
improvements.
E
We
should
see
a
positive
impact
on
our
sus
score
and
I
think,
frankly,
you
know
our
sus
score
from
last.
Quarter
was
better
than
previous
quarters
in
that
we
declined
way
less
than
we
had
so
last
quarter.
We
effectively
were
flat
previous
quarter
to
that.
We
declined
by
0.6
points
a
quarter
before
that
it
was
a
full
point.
So
actually,
what
we
are
seeing
is
an
uptick
in
the
trend,
and
I
suspect
that
performance
improvements
were
part
of
that.
B
Thanks
christy
and
yeah,
I'm
we
will
keep
pushing
on
that,
because
I
really
believe
that
this
is
something
we.
We
really
can
also
focus
with
the
data
team
with
the
telemetry
everyone
that
is
involved.
What
are
the
major
workflows?
What
is
everyone
doing
and
define
personas
to
net?
Not
only
get
this
as
input
for
product
on
what
features
to
build
and
what
to
prioritize,
but
also
get
this
to
engineer
to
rather
focus
on
okay,
let's
prioritize
this
part,
we
can.
B
We
can
stream
like
this
thing
or
get
also
more
feedback,
because
performance
in
my
experience
is
not
only
about
the
actual
thing,
and
sometimes
you
can't
make
stuff
faster,
but
it's
about
the
perception.
So,
if
something
that
we
were
discussing
around
real
time,
I
strongly
believe
in
is
if
we
can
have,
for
example,
all
the
stuff
that
is
currently
happening.
B
If
you
click
the
merge
button
and
can
display
this
to
the
user
and
say
hey
by
the
way,
what
we
are
doing
right
now
is
we
are
taking
this
branch
and
taking
that
stuff
and
we
have
927
changes
and
we
have
already
300
done
and
now
400
times.
This
is
a
much
much
much
better
experience
than
this
current
fire
and
forget,
where
you
click
and
it's
like
spin
spin
spin,
and
I
think
that
those
are
really
where,
where
all
those
energy
parts
can
come
together.
E
I,
like
tim,
that
you,
you
made
a
really
clear
connection,
so
we
do
have
two
themes.
We're
focused
on
for
the
shared
okr.
One
is
visibility
of
system
status
and
the
other
is
performance,
but
what
you're
doing
is
drawing
a
really
clear
line
saying
to
users.
It's
all
performance
visibility
of
system
status
is
this
close
to
actual
back-end
front-end
performance,
and
that
is
a
beautiful
call
out
from
you.
D
One
more
question
I
heard:
there's
some
discussion
of
creating
a
working
group
focused
on
front-end
observability.
Any
thoughts
on
are
there
gaps
there?
Are
there
ways
that
more
observability
and
instrumentation
in
the
front
end?
What
could
help
accelerate
or
maintain
this.
B
B
Your
browser,
plugins,
are
actually
messing
one
to
one
with
the
code
that
you're
running
right
now,
so
this
mean
if
there
is
grammarly
jumping
in
right
when
you
are
trying
to
post
some
comments
over
to
the
server
and
it's
changing
something
in
between,
and
this
is
throwing
an
error,
then
you
will
see
this
in
right
away
in
the
in
the
in
the
century.
So
I
think
if
we
want
to
do
this,
let's
get
started.
That
was
also
my
recommendation.
B
Let's
get
centrally
running
up
again
and
have
some
dedicated
people,
it's
a
fantastic
tool,
but
it
takes
a
lot
of
input,
especially
on
front-end
side,
to
make
something
meaningful
out
of
the
data
and
out
of
everything
that
comes
out
of
the
production.
But
I
I
totally
agree
it's
it's
important.
A
Thanks
for
that
detailed
explanation,
tim
as
well
as
answering
questions
around
that
we
finished
item
one.
Are
there
any
other
questions
we
want
to
cover
as
item
two?
Is
certain
still
blank?
But
if
you
would
like
to
throw
in
a
question
right
now
feel
free
to.
C
B
Do
you
mean
the
performance
work
in
general
or
just
this
poc
thing
right
now,
so
that
performance.
B
Performance
work
in
general
is
is
a
very
combined
area
at
the
moment,
so
we
have,
I
would
say,
five
to
six
different
initiatives
that
are
running
anyhow
right
now
that
are
running
in
general.
B
So
this
is
like
the
ongoing
work
by
simply
engineers
jumping
we
have
a
dri,
so
one
specific
frontend
engineering
manager
is
basically
the
person
driving
that
and
pushing
that
forward
and
then
other
engineers
jump
in.
Sometimes
they
are
super
easy.
We
had
something
that
took
us
six
to
seven
months,
which
were
the
font,
awesome
icons,
and
sometimes
this
is
now
really.
B
To
a
specific
area
where
we
are
now
really
now
in
the
next
step,
focusing
just
on
specific
tasks
in
depth,
and
but
we
we
really
want
to
share,
especially
and
that's
why,
where
we
try
to
invent
also
more
tools
of
measuring
that
is
to
leverage
all
the
knowledge,
and
that,
I
think
is,
is
also
another
bigger
problem
at
the
moment.
Not
a
problem,
but
a
big
task.
B
Attempt
to
share
that
knowledge
of
everything
that
is
coming
out
of
the
different
groups
and
what's
going
on
to
share
this,
especially
in
the
right
meetings,
agendas,
so
that
everyone
knows
about
it
and
yeah.
C
A
About
yeah
in
particular,
I
would
say
if
you
look
at
most
of
our
okrs,
we're
still
working
on
doing
this
more
formally
throughout
the
department.
But
if
you
look
at
particularly
at
the
higher
levels
in
the
organization,
you'll
see
a
cross
organization
okrs
and
typically
we
have
between
two
to
three
krs
spread,
usually
between
the
the
arr
and
the
product
themes
of
the
okrs.
So
so
yeah.
A
It
feels
like
it
feels
like
the
teams
are
doing
a
pretty
good
job
of
making
sure
that
we're
prioritizing
appropriately,
though
we
do
have
some
additional
initiatives
and
works
around
that,
as
we
had
the
amas
last
week
to
kind
of
talk
about,
how
do
we
better
prepare
for
the
upcoming
quarter
so
that
we
have
oak
cares
aligned.
A
Excellent,
this
will
be
the
longest
one
question
group
conversation
originally,
I
was
gonna
make
the
joke.
That
was
gonna,
be
the
shortest
group
conversation,
but
it's
actually
we've
gotten
pretty
long
on
the
first
question
so
love
to
hear,
if
there's
any
other
questions,
if
folks
have
any
feedback
for
me
about
content,
they'd
like
to
see
also
I'd,
be
welcome
to
that
as.