►
From YouTube: 2020-06-17 Manage Frontend Engineering Weekly
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
Cool
this
is
originally
read
only
but
I
just
want
to
vocalize
it
because
I
know
some
of
you
have
left
feedback
on
it.
Thank
you,
Michael
and
Rob
for
leading
some
some
thoughts
and
notes
on
the
workflow
handbook.
Merge
requests,
so
you
might
have
already
seen
it
you
might
have
not,
on
the
manage
monthly
call,
I've
been
working
on
a
merger
quest
to
try
to
capture
basically
our
existing
workflow
and
how
we
can
try
to
have
that
handbook
page.
A
Our
page
page
there's
a
reference
guide
for
how
we
do
different
things
in
terms
of
process,
breaking
down
issues
and
planning
and
so
on.
So
this
is
kind
of
that
final
call,
because
I
am
really
pushing
hard
to
have
this
merge
this
week.
So
thank
you
for
those
that
have
already
put
feedback.
Others
don't
feel
like
you
are
compelled
to,
but
this
is
your
chance
to
like
get
it
in
the
first
iteration.
B
B
C
D
B
B
And
one
thing
I'll
point
out
is:
if
you
do
go
down
the
route
using
the
new
components,
you'll
often
see
the
syntax
where
we
use
GL
new.
Whatever
name
is
Vishal
made
a
really
good
point
about
aliasing
the
imports
aliasing
it
in
the
way
that
it
should
appear
one
for
final
component
busy,
and
this
just
kind
of
helps
reduce
the
amount
of
code.
The
application
you
can
play.
A
C
I
was
just
saying
that
that's
really
cool
nice
work
on
jQuery
I
know
how
much
of
a
pain
that
could
be
to
get
rid
of.
So
that's,
that's,
really.
Cool
I
have
some
experience
with
doing
migrations
using
wow
I'm
blanking
on
the
name
right
now,
but
basically
a
structured
programming
way
of
doing
migrations.
I
forget
what
it's
called
right.
Now
it's
been
a
while.
So
it's
not
just
code
mots.
Thank
you.
C
C
A
C
A
Had
used
at
one
point,
Amelia
from
import
I
had
use
it
at
one
point:
I,
don't
I
can't
recall
exactly
for
what,
but
it's
good
that
we
have
fun
matters
to
people
with
experience
with
it.
So
that's
that's
one
thing
to
consider.
I
don't
know,
I
would
appreciate
if
someone
could
find
perhaps
there's
if
there's
an
epic
to
some
stuff,
some
of
these
components
and
then
perhaps,
if
not,
if
not
create
an
epic
to
track
such
a
thing
and
then
propose
something
like
code
mods
to
as
a
strategy
for
getting
us
closer
I'm.
B
D
A
A
A
D
I
remember:
we
wanted
to
introduce
linters
for
enforcing
in
the
shorthand
syntax,
for
example,
for
slot
name
slots
and
other
parts
in
the
code
base.
There
was
a
while
ago,
but
then
we
ran
into
issues
with
updating
oil
interests
and
we
went
down
the
rabbit
hole
where
we
would
have
to
update
like
a
whole
bunch
of
dependencies
and
then
I
think
this
effort
stopped,
but
I'm
not
sure
it
probably
we
already
updated
them
so
might
be
worse
to
pick
it
up
again.
A
A
Cool
so
as
of
earlier
today,
this
morning
or
evening,
depending
on
what
time
zone
you're
in
I,
think
we
launched
the
first
experiment
and
managed
definitely
an
import.
So
we
have
an
experiment
running
right
now
in
production,
for
50%
of
the
audience
to
show
a
new
project.
Creation,
UI
and
I
could
share
my
screen
and
show
you
that
so
we'll
do
that
right
now.
So.
A
Thumbs
up,
if
you
can
see
my
screen
cool,
thank
you
so
new
career.
So
the
idea
is
that
these
tabs
don't
perhaps
surface
or
bring
the
best
discovery
in
turn
into
the
different
options
you
have
when
creating
a
project,
and
so
we
have
given
it
much
more
visually
appealing
treatment
to
it,
and
so
we
actually
have
this
running
as
an
experiment,
meaning
that
we
can
a
be
test
stuff,
which
is
something
I'm
very
happy
about
very
passionate
about
to
be
able
to
experiment
and,
more
importantly,
have
data
to
actually
influence
our
decisions.
A
Of
course
you
don't
want
to
be
completely
data-driven,
but
it's
it's
very
important,
I
think
to
to
have
some
data
that
maybe
a
little
bit
more
telling
than
complaints
via
issues
and
things
like
that.
But
what's
really
cool
about
this
there's
an
experimentation
guide
if
you're
that
I've
linked
to
in
the
agenda.
That
goes
into
more
detail
about
this,
but
it
gives
us
some
really
cool
things
in
terms
of
like
percentage
segmentation
where
you
can
expose
this
experiment,
or
this
new
feature
to
10%
of
the
entire
audience,
a
specific
group,
whether
it's
get
lab
order.
A
Some
perhaps
customer
that
wants
to
try
something
out
on
get
lab,
comm
and
also
one
thing.
That's
also
cool
here.
Is
that
because
I'm
not
getting
this
experiment,
you
can
actually
force
it
with
the
query,
parameter
using
the
experiment
key.
So
if
I
do
query
parameter
for
experiment
equals
new,
create
project,
Y
you'll
actually
be
able
to
go
to
that
that
be
version,
and
so
this
is
what
that
looks
like.
So
the
hypothesis
is
if
we
can
bring
more
discovery,
some
more
visibility
about
the
other
options
you
can
use
to
create
new
projects.
A
Will
they
will
users
engage
more
with
important
projects?
So
the
idea
is
that:
can
we
can
we
encourage
more
users
to
import
projects,
perhaps
instead
of
creating
blank
ones
and
then
perhaps
like
doing
a
git
push
to
a
new
remote
which
would
be
this
blank
repository,
so
the
flow
beyond
that
is
exactly
the
same.
You
just
go
from
one
panels
to
the
other.
A
I
was
a
little
hesitant
at
first,
because
now,
when
you're
creating
a
blank
project,
which
is
my
typical
use
case,
you
now
another
screen
away
from
that,
because
you
have
to
click
into
it.
But
again
we'll
see
what
the
data
looks
like
if
the
experiments
only
been
live
for
a
few
hours,
so
I'm
currently
right
now,
building
the
periscope
science
dashboard
to
track
these
events,
and
so
I've
included
a
little
screenshot
of
what
that
looks
like.
A
Hopefully,
you
can
see
the
agenda
but
or
I
can
just
show
this
dashboard
itself.
No,
it's
so
you
can
see
here,
obviously,
there's
more
friction
on
the
experimental
group
creating
blank
projects,
because
you
now
have
one
extra
screen
so
that
that's
already
being
in
a
very
apparent
behavior,
but
what's
also
interesting,
is
that
you
are
seeing
more
down
here
any
experimental
groups.
They
are
importing
a
bit
more
as
well.
Of
course,
it's
very
early
to
tell
you'd
want
to
leave
this
open
for
at
least
a
couple
of
weeks
to
get
just.
A
Oh,
my
god,
statistical
significance
before
drawing
conclusions,
but
I'm
more
I'm,
just
really
excited
that
we
have
this
capability
now
to
be
able
to
get
data
on
and
track
what
users
are
doing
to
be
able
to
see
for
what
we're
improving,
what
we're
doing
exactly
having
a
real
effect
on
things.
So
I
just
wanted
to
share
that,
because
it's
personally
exciting
for
me,
but
also,
if
you
feel
compelled
or
if
you
feel
like,
there's
certain
features
or
things
you're
working
on
that
might
benefit
from
being
an
experiment.
A
D
It's
definitely
interesting,
especially
for
the
analytics
group
I
guess,
because
we
recently
talked
a
lot
about
a/b
testing
and
what
options
we
would
have
in
this
regard.
So
thanks
for
sharing
that
that's
really
interesting
and
super
exciting
I
think
we
had
one
use
case,
but
we
didn't
really
follow
up
on
that.
We
recently
implemented
the
horizontal
navigation
for
Valley
Stream,
a
latex,
but
then,
on
the
other
hand,
we
decided
hey
but
like
what's
the
thing
like,
what's
the
the
KPI
that
we
would
like
to
measure
and
it's
just
the
UI
element.
D
So
for
us
this
was
not
the
perfect
use
case,
so
we're
still
looking
for
a
first
use
case
that
makes
sense
for
us
to
implement,
but
it's
great
that
we
have
the
infrastructure
in
place
to
actually
implement
it,
and
the
other
thing
I
really
like
about
this.
This
change,
or
this
first,
this
first
experiment
that
you
implemented
and
elia
participated.
I
guess
really
was
doing
most
of
the
front-end
work
here.
D
This
BAM,
ideally
I'd,
really
like
to
draw
some
attention
to
the
mr,
because
I
think
it
really
did
a
really
great
job
in
terms
of
going
for
the
boring
solution,
because
he
managed
to
reuse
a
lot
of
functionality
from
the
previous
version,
which
is
not
written
in
view.
So
he
was
kind
of
mixed
in
the
old
Hamill
you
implementation,
which
doesn't
seem
like
the
perfect
fit
in
the
long
run,
but
since
we
want
to
or
eventually
we
might
want
to
steer
back
and
don't
implement
the
new
version
at
all.
C
A
Definitely
discussion
on
how
much
work
we
wanted
to
invest
in
it
and
you'll
see
it
in
the
experiment
guide
as
well,
that
you
may
have
to
communicate
this
to
your
maintainer,
especially
because
it's
an
experiment
because
you
are
you-
are
building
well
I
like
to
think
we.
We
do
this
anyways,
but
perhaps
labeling
it
as
an
experiment,
helps
to
and
I
know
we're
over
time.
So
hopefully
we're
okay
to
go
over
a
little
bit.
But.
A
I
think
my
framing
as
an
experiment
saying
like
we're
just
this
is
a
temperate.
We
don't
know
yet
if
we
want
to
invest
the
full
effort
into
that
full
final
polished,
MVC
and
I
know
polish
and
NBC
may
not
go
perfectly
well
together,
but
basically
could
we
save
a
little
bit
of
time
and
effort
not
going
for
the
hundred-percent
feature
and
do
most
of
it
and
see
if
users
even
like
it
or
engage
with
it,
and
if
that's
the
case
like,
then
we
could
invest
further
into
it
right.
A
That's
kind
of
the
idea
about
around
a/b
testing.
Of
course,
smaller
changes
don't
really
apply
as
much
all
right
if
we
can
so
when
you
frame
that
when
you
put
your
merge
request
up
for
review,
you're
gonna
have
to
say
hey,
this
is
an
experiment
like
the
code
isn't
going
to
be
the
cleanest,
and
that
was
the
same
conversation
that
Ilya
and
I
were
having
in
terms
of
you
know,
do
we
copy
the
controllers
entirely?
Do
we
create
new
controllers
entirely?
A
Do
we
create
view
components
out
of
it,
and
the
idea
is
that
no
we
want
to
if
anything,
this
is
more
important
to
make
it
more
NBC
and
with
minimal
changes
to
the
code
itself,
so
that
we're
not
investing
too
much
time
for
something
that
we
know
is
more
temporary
ephemeral
and
that
type
of
thing.
But
thanks
Martin
for
flinging
to
that
merge,
request
and
yeah.
A
C
That's
a
really
interesting
way
of
working
with
this
I'm
I,
just
branched
over
the
documentation
that
you
link
to
seems
fairly
straightforward.
Yeah
I'll
definitely
be
looking
a
little
bit
more
into
that
to
try
to
understand
how
much
goes
into
it
and
maybe
looking
at
that
Mercer
dress.
If.
A
It
were
okay,
because
I
know
we
have
a
couple
more
points.
I
can
give
you
a
quick,
TL
DR
on
it.
The
it
functions
exactly
the
same
as
feature
flags,
because
it's
built
on
the
same
flipper
gem
that
we
use
for
feature
flags.
It's
just
a
different
portion
of
that
and
to
give
you
a
little
bit
of
brief
history.
This
is
totally
not
a
Tod
right
now,
but
I'm
gonna
explain
a
little
bit
of
the
history
behind
it,
because
I
think
it's
important.
A
We've
always
had
the
capability
to
do
a/b
testing,
but
we've
been
slowly
piecing
it
together
because
we
had
flipper,
but
we
didn't
have
chat,
ops
enabled
for
the
percentage
setting.
We
didn't
have
a
good
way
of
like
labeling
experiments,
so
every
experiment
actually
has
experiment
percentage
repented
to
the
feature
flag.
Key
we
implemented
snowplow
and
Martin
and
team
spent
a
lot
of
time
implementing
tracking
events,
but
they
were
going
in
somewhere,
but
we
couldn't
exactly
pull
all
the
data
and
actually
report
on
it
and
then
what's
periscope
cup
introduced.
A
Then
we
had
that
kind
of
last
piece
to
be
able
to
do
so,
and
so
you
know
shout
out
to
growth
for
helping
to
connect
it
all
together,
but
basically
you
to
implement
it
in
the
code.
It's
very
similar
to
instead
of
feature
enabled
it's
experiment
enabled
and
most
of
the
most
of
the
functionality
works
very
similar
to
feature
flags,
in
addition
to
pushing
feature,
front-end
feature
flags
to
the
global
object.
So
if
you,
if
you
know
how
to
do
feature
Flags,
he
can
do
experiment
flags
and
then
to
can
finish
connecting
it.