►
From YouTube: Manage Group Conversation, 2019-02-21
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
Hey
friends:
I've
got
the
top
of
the
hour.
Some
Jeremy
Watson
I'm
product
manager
here
on
the
manage
team,
excited
to
have
a
group
conversation
here
about
manage
or
working
on
now
and
we're
going
in
the
future.
So
before
we
dig
into
any
discussion
or
questions,
I'll,
throw
it
over
to
Liam
and
Dennis.
The
engineering
managers
also
had
managed
to
introduce
themselves
Dennis
over
the
year.
Oh
thanks,
Jeremy.
B
C
Thanks
Dennis
I'm
Liam
on
the
backend
engineering
manager
for
the
for
the
manage
team
follow
on
from
Dennis's
theme
there.
In
two
days
it
will
be
my
six
months,
I'm
not
quite
experienced
but
I'm
catching
you
up,
Dennis
and
likewise.
Likewise,
on
the
other
questions
and
apologies,
we
we
tried
to
and
we
very
just
updated,
two
slides
on
the
event
usual
minutes
ago:
the
apologies,
if
not
everyone
had
as
much
time
to
circulate
as
they
would
like
and
but
yeah
I
mean
well
we're
happy
to
take
any
any
questions
or
comments
that
that
then
maybe.
D
E
D
H
D
I
was
gonna
say
that
I've
noticed
that
there's
interest
both
in
in
making
them
and
maybe
I'll
just
advertise
again.
The
same
thing
I
did
on
the
company,
call
that
if
anybody
knows
how
to
make
a
project
that
demos,
some
technology
stack
or
language
or
whatever
I
can
pretty
easily
now
convert
those
into
project
templates.
The
other
thing
that
came
up
that
was
really
interesting
is
the
idea
that
companies
may
be
interested
in
so
for
Adele,
for
example,
or
some
other
company
you
could
have
like
the
Dell.
D
You
know
template
for
development
in
this
department
and
they
could
create
those
themselves
and
then
publish
them
out
to
their
own
engineering
organizations.
It's
something
it's
a
interesting
idea
and
it
could
help
ensure
that
teams
at
companies
like
that
large
enterprises
are
doing
more
consistent
development.
So
I
just
wanted
to
pass
that
on.
I
know.
C
You
guys
are
already
aware
thanks
thanks,
sorry,
isn't
it
Jason?
It's
actually
on
my
to-do
list
to
reach
out
to
you
directly
I've
been
spending
a
bit
of
time
over
the
last
few
days.
Looking
at
the
implementation
of
project
templates
and
I
saw
your
merge
request
and
you
seem
to
have
a
good
idea
of
how
they
work.
One
of
the
questions
I
was
gonna.
Ask
you
directly
was
and
then
I
said,
I
found
of
a
revival
recently
in
terms
of
I've
seen
them
mentioned
a
lot
more.
It's
functionality,
that's
been
there
for
a
while.
C
D
The
reason
honestly
is
that
nobody
had
worked
on
it
for
a
while
I.
Don't
know
why
that's
the
case,
but
I
had
an
issue
where
we
wanted
to
add
some
pages
templates,
because
we
wanted
to
make
pages
easier
to
use.
So
I
went
in
and
added
a
few
pages
templates
and
then
I
was
like
wow.
You
know
we
can
do
a
ton
with
this
feature.
D
C
Awesome
that
sounds
scary
as
I
said:
that's
something
that
is
on
my
to-do
list
at
the
moment,
I'm
hoping
in
this
milestone.
We
can
make
good
progress.
Jeremy's
spent
a
bit
of
time
updates
in
the
contribution
guidelines,
and
obviously
we
want
to
make
a
few
improvements
there
and
we're
going
to
have
a
dedicated
maintainer
in
the
team
as
well
to
make
any
additions
and
changes
easier.
E
I
D
C
E
D
The
way
that
I'm
doing
the
Android
and
iOS
ones
is
just
going
to
the
Android
and
iOS
developer,
getting
started
documentation
and
taking
the
you
know,
hello,
world
apps
and
getting
those
working.
So
it's
actually,
even
if
you
don't
know
yet,
you
might
be
able
to
make
the
dotnet
one
if
you're,
if
you're
in
in
general,.
E
G
Another
option:
another
option
might
be
I
mean
at
work.
Well,
we
don't
have
to
wait
for
the
next
one,
but
I'm
the
last
one
that
you
organized.
We
have
the
set
of
priority
issues
where
we
pointed
people
to
do
to
participate
to
participate,
or
my
people
I
mean
members
from
the
wider
gilad
community.
So
perhaps
we
can
make
this
somewhat
more
visible
as
well.
E
The
managed
team
is
also
responsible
for
psychoanalytic
cycle
analytics
the
main
benefit
for
selling
with
gif
file,
but
the
metrics
have
been
kind
of
almost
unusable
for
us
and
I.
Haven't
you
heard
any
customer
using
them,
and
there's
I've
seen
a
lot
of
ideas
on
how
to
improve
them,
but
they
all
seem
to
assume
a
big
refactor
as
needed.
Is
there
a
way
to
just
make
a
bit
of
progress,
a
tiny
bit
of
progress
that
is
not
does
not
need
a
lot
of
engineering
time.
A
A
The
first
thing
that
we
want
to
fix
is
we
just
simply
want
to
fix.
What's
already
there,
there
are
a
number
of
calculations
that
are
being
calculated
incorrectly
and
will
result
in
the
user,
seeing
not
enough
data,
which
makes
the
feature
kind
of
like
unusable
and
very
unhelpful
for
our
customer
I
think.
A
J
Slide
number
8:
you
mentioned
that
you're
going
to
be
working
on
improving
the
way
we
externalized
strings
and
making
that
easier
for
everybody
to
contribute
to
and
I'm
wondering
if
there's
also
plans
for
the
other
side
of
the
of
the
story
where
community
contributors
put
strings
and
Crowden.
But
it's
still
quite
a
manual
and
the
time-consuming
process
to
get
those
in
and
get
those
in
a
release,
get
those
validated
and
so
on.
And
is
there
any
progress
on
that
being
made.
A
So
you're
late,
Bob
it'sit'sit's
there's
two
problems:
I'm
gonna
fix.
We
want
to
make
it
easy
for
four
contributors
to
externalize
screens
and
also
be
able
to
track
the
progress
of
that
progress,
but
you're
right
that
there
are
also
improvements
that
we
need
to
make
on
our
own
processes
to
make
this
easier
to
integrate
on
our
side.
I.
The
the
current
plan
is
to
focus
on
the
first
problem.
For
now,
which
is
we
don't
we
simply
at
the
moment?
A
Don't
have
a
good
sense
of
the
number
of
strings
that
are
left
to
externalize
and
get
loud.
So
we
want
to
solve
that
by
ideally
flagging
those
strings
that
we
need
to
that
we
need
with
possibly
with
lint
or
so
that
we
can
at
least
build
a
robust
set
of
feature
of
issues
that
categorize
all
the
areas
and
views
that
we
need
to
external
eyes.
A
I
think
what
that
will
enable
us
to
do
is
ideally
organize
a
community
hackathon
to
be
able
to
both
work
on
both
the
externalization
of
these
strings
and
also
some
of
those
technical
debt
issues
that
we
need
to
fix,
that
you
just
point
it
to
and
then
well
ideally,
we'll
get.
You
know
we'll
get
assistance
for
the
community
like
we
do
for
all
of
our
other
features
here
at
github
and
then
we'll
schedule
the
rest
kind
of
kind
of
appropriately,
but
as
China
kind
of
because
more
a
little
bit
more
of
a
focus
for
us.
A
We
definitely
want
to
make
externalizing
all
strings.
We
then
get
lab
and
making
that
a
very
easy
problem
for
us
to
be
able
to
follow
with
future
feature.
So
you
don't
fall
behind
in
the
future
again
and
make
it
a
very
easy
system
to
maintain
so
you're
right.
It's
two
parts
I
think
we're
gonna
focus
on
the
first
problem.
First
and
hopefully,
as
part
of
the
community
hackathon,
we
can
include
some
of
those
tech
debt
issues
that
we
can.
We
can
ideally
work
on
in
partnership
with
the
community.
C
I've
linked
so
I've,
linked
through
to
an
issue
in
the
in
a
group
conversation
doc,
which
is
about
automating.
That
process,
which
is
open
the
best
part
of
a
year
ago,
and
if
you've
got
any
kind
of
feedback
to
ever
that
still
relevant
or
if
there's
any
other
ways.
We
could
be
doing
that,
then
any
contributions
would
be,
would
be
good.
J
E
Hey
I'm,
sent
me
straight
here
that
there
was
a
person
I
think
three
years
ago
who
translated
all
of
gitlab
just
by
himself
fully
to
four
years
ago
now,
and
so
I
still
have
this
idea
that
it's
just
not
a
lot
of
work
to
just
externalize
all
the
strings,
but
I'm
probably
wrong.
But
can
someone
kind
of
talk
about
like
what
we're
running
into
like
it's?
Not
it's,
not
just
a
big
operation
on
the
codebase
and
things
like
that,
and
maybe
we
should
find
that
person
and
try
to
try
and
engage
your
baby
Peter
person.
E
J
J
J
Think
I
think
right
now
the
idea
is
a
little
bit
like
what
we've
done
in
the
past
is
like
you
know,
we
don't
have
a
good
solution
for
that
now,
so
we'll
just
get
it
move
it
forward
like
this,
and
we
might
end
up
with
a
weird
strange
somebody
is
going
to
create
an
issue
for
it
and
then
we're
going
to
think
about
improving
that,
but
there's
also
like
sometimes
security
applications
that
we
need
to
think
about
because
we
mix
HTML
in
those
strings.
So
then
we
need
to
yeah.
B
Just
comparing
from
you
know
three
or
four
years
ago,
however
long
it
was
I
think
there
are
a
lot
of
other
places
now
we're
exposing
these
strings
and
got
the
various
layers
from
the
front-end
also
with
translatable
strings.
So
that's
why
we're
trying
to
introduce
these
linters
from
both
the
Ruby
side,
so
we
cover
the
API
and
the
backend
airs
and
also
introduced
on
the
front-end
side.
So
that's
just
more
automated
and
not
just
like.
Please
make
sure
you
externalize
strings
in
your
merge
request.
B
So,
but
then
that's
also
part
of
the
challenge,
with
accounting
for
how,
knowing
sorry,
understanding
the
coverage
of
externalization,
because
there
are
these
other
places
that
we
have
to
grab
towards
and
the
implementation
is
not
always
the
same.
It
makes
sense
thanks
for
explaining
why
it's
harder,
I.
H
Can
add
a
little
bit
of
color
that
too
I
worked
for
two
years
in
the
enterprise
localization
industry,
and
once
we
solve
all
these
technical
problems
for
enterprise
customers,
especially
there's
the
linguistic
quality
problem,
which
is
arguably
much
harder
to
solve
than
the
externalized
string,
get
translation
sort
of
thing.
And
so
we
may
have
to
find
a
way
to
involve
a
localization
service
writer
or
find
ways
to
you.
H
Don't
have
to
be
the
product
of
one
person
but
find
a
way
to
get
linguistic
reviews
happening
to
make
it
a
localized
product
that,
for
instance,
large
Japanese
corporations
are
doing
to
consume.
Some
cultures
are
extremely
sensitive
to
industry
terms,
linguistic
terms
and
things
like
that,
and
we
only
really
even
sort
of
bumped
into
those
issues.
Yet.
J
A
H
Typically
want
professional
translators
who
speak
your
source
language
in
this
case,
English
as
their
second
language
and
your
target
language
Japanese
as
their
first
language,
and
they
should
be
in-country
because
there's
lots
of
cultural
aspects
that
you
don't
get
from
an
academic
understanding
of
language,
and
you
obviously
want
you
know
low
bus
factors.
So
you
want
multiple
translators
that
get
your
application
take
time
to
learn
the
industry
terms
and
save
the
reviewers.
You
don't
want
someone
out
like.
Oh,
you
don't
want,
someone
are
doing
their
own
translations.
H
Localization
industry
is
because
it's
sort
of
commoditized
people
think
in
terms
of
pennies
per
word,
and
that's
not
a
good
pricing
model
for
software
companies,
so
most
of
the
money
will
go
into
the
types
of
stuff
that
we're
gonna
do
ourselves.
The
software
work
the
externalization
of
strings.
That's
where
you
end
up
paying
these
vendors
a
lot
of.
A
Yeah,
that's
a
great
great
call-out.
What
we
did
at
a
mobile
gaming
company
when
I
was
when
it
was
running
product
there
was.
We
would
just
analyze
based
off
of
her
the
the
statistics
that
we
got
from
the
user
devices
and
understand
where
paid
customers
were
where
we
had
the
greatest
kind
of
conversion
rate
and
the
most
free
users
and
then
just
prioritize
like
the
top
ten
languages
and
then
find
the
localization
company
that
could
help
us
with
that.
A
There
might
be
a
similar
analysis
that
we
could
do
kind
of
based
off
of
the
usage
statistics
that
we
get
based
off
of
various
countries
and
various
languages
that
we
have
now
to
say.
Maybe
we
prioritize
Chinese
Korean
Japanese,
and
then
you
know
a
few
others
in
areas
that
we
think
might
be
worthwhile.
So
yeah.
H
H
E
Just
want
to
make
sure
like
right
now,
like
number
one
get
all
the
strings.
Externalized
like
not
the
linker
is
not
the
technical
constructs,
not
getting
it
perfect,
but
like
have
like,
let's
iterate
and
not
have
perfect,
be
the
enemy
of
good
like
having
right
now
we're
half
translating
the
application.
That's
obviously
like
the
worst
situation
to
be
in
so
we
need
to
get
out
of
that
situation
ASAP.
H
Right,
that's
that's
considered
unprofessional
by
the
people
consuming
it.
So
that's
definitely
this
first
problem
and
well
there's
I'll
talk
with
Christopher.
If
that's
not
already
in
our
definition
of
done.
You
know
if
you're
writing
a
feature
externalize
the
strings.
We
can.
We
can
add
that
in
just
so
we're
not
creating
new
debt
as
we
go
yeah.
A
Yeah
and
Gabriel
I
think
that's
a
great
idea
and
that's
kind
of
what
we're
planning
I
think
the
first
step
is.
We
at
least
need
to
have
a
comprehensive
set
of
issues
that
people
can
work
on,
so
they
can
actually
know
which
parts
the
application
and
externalize
so
I
I
know
necessarily
care
about.
Having
like
perfect
understanding
over,
you
know,
we
have,
you
know
X
number
of
strings
to
externalize
that
we've
externalized
Y
in
them
I
I'm.
A
Finally,
just
like
a
list
of
views
that
people
can
just
you
know,
the
contributor
can
just
take
off
of
a
stack
and
then
just
immediately
start
trying
start
externalizing.
So
I
think
that
we
need
some
way
of
being
able
to
present
that
for
the
community
before
we
can,
a
staff
of
you
know
schedule
a
hackathon,
which
is
why
I
think
that
the
linters
can
could
help
us.
You
know
help
us
with
that,
but
I
personally,
just
just
want
a
list
of
issues
that
the
contributor
can
just
continue
and
burn
down.
B
And
just
truck
burning
it
down
that
way,
but
I
don't
think
it
might
get
any
connection
to
the
port.
I.
Can
you
know
yeah,
okay,
so
Luke's
created
a
bunch
of
issues
to
start
going
through
the
views
like
app
and
views
folder,
but
I
think
we
just
need
to
go
and
comb
through
the
rest
of
the
code
base
to
see
where
we
might
actually
have
strings
otherwise,
like
for
API
responses,
and
things
like
that.
So
there
should
be.
E
H
Think
that's
a
great
first
step
and
that'll
catch
like
80
or
85
percent
of
stuff
and
then
there's
there's
always
video
ways
to
avoid
winters,
which
is
why
I
suggest
the
definition
of
done.
There's
always
ways
to
write
strings
in
JavaScript
to
catch,
but
that'll
that'll
open
the
floodgates
of
issues.
H
A
B
F
Sure
actually
were
in
the
middle
of
dating
the
process
and
Orsat
as
well.
So
we
are
wondering
what
would
be
the
best
the
best
option,
and
that
seems
to
be
a
quite
nice
process
that
you
have
there.
So
we
will
probably
experiment
with
that.
The
problem
that
we
have
now
is
mostly
to
follow
progression
so
to
see
where
we
are
between
the
responsible
to
work
on
an
issue
and
ensure
is
done.
We
have
nothing
in
the
middle
because
we
don't
have
any
progression
in
the
issue.
F
I
don't
want
to
read
all
documents
on
daily
basis,
just
know
that
and
I
have
the
feeling
that
splitting
issues
in
small
smaller
issues
that
to
date
were
at
least
a
kind
of
progression,
because
you
can
see
that
on
five
issues,
for
example,
you
have
found
three,
and
that
means
you
probably
have
done
more
than
that
for
the
the
global
issue.
I'm
just
curious
about
your
your
feedback
on
this,
this
experiment
and
if
you
see
any
gasp
and
you
wars
and
the
traps
that
we
should
avoid
new
security,
yeah.
B
So
I
mean
we
really
just
kicked
this
off
for
eleven
nine
and
I
mean
as
far
as
our
initial
results
I
think
it's
been
really
positive.
What
I
mean
by
that
is-
and
one
thing
I
want
to
rate-
is
like
we
are
waiting
these
things,
but
these
are
not
the
end
result
that
we're
going
after
or
we're
looking
for.
By
doing
this
estimation
is
to
just
kind
of
encourage
more
conversation
because
of
all
those
times
we
have
these
main
issues
and
there's
UX
back-end
and
fun,
and
then
we're
not
really
sure.
B
Okay,
we've
got
some
labels.
The
KTX
is
ready,
but
then
back
and
might
be
happening.
But
then
you
have
all
this
this.
These
comments
and
discussions
happening
in
one
issue,
so
breaking
it
out
and
then
kind
of
understanding
that
there's
these
dependencies
and
then
knowing
that
we
have
to
estimate
it
kind
of
already
started
having
these
conversations
and
that
already
actually
contributed
to
the
following.
The
progression
one
example
I
can
give.
Is
that
like
right,
now
we're
working
on
being
able
to
improve
the
assaut
flow
and
so
there's
a
front
end
ticket?
B
B
So
then
we
have
it,
maybe
not
the
fullest
level
of
confidence,
but
at
least
we
have
some
confidence
to
be
able
to
say
this
is
how
big
I
think
it
is
and
if
it's
hitting
8
or
so
then
we
can
break
it
down.
But
what's
coming
up,
what's
what's
happening
is
that
we
have
front-end
engineers
going
in
and
checking
in
on
that
UX
issue
and
seeing
okay.
B
Where
are
we
at
and
you
know
which
we
get
closer
to
the
first,
we
may
have
to
ask
like
hey,
UX
designer,
what's
your
feeling
on
this
one
of
the?
Maybe
we
can
also
follow
up
on
the
progression
of
that
issue
itself
and
we
can
see.
Ok,
the
UX
isn't
ready.
Yet
then,
should
we
think
about
moving
from
then
out
to
the
next
release
or
things
like
that.
B
But
then,
in
addition
to
that,
we've
started
asking
more
questions,
because
we
know
that,
because
we
see
this
progression,
we
might
have
questions
ourselves,
because
one
thing
we
were
we
in
front
and
we're
doing
is
like
digging
deep
enough
into
the
code
to
understand
like
how.
How
much
do
we
have
to
do
how
much
work
is
actually
involved,
and
so
by
seeing
that
progression,
we
were
like
able
to
ask
for
questions
and
things
like
that.
So
I
don't
know
to
kind
of
summarize
it
all
up
it.
C
I
think
it
which
is
more
of
kind
of
a
velocity
metric,
that's
something
we
can
determine
in
a
couple
of
milestones
down
the
line
once
we've
gathered
a
bit
more
data
and
I
think
yet
on
Dennis,
this
point
that
wasn't
necessarily
the
main
intention.
But
if
it's,
if
it's
a
side
effect
and
that
could
be,
that
could
be
positive
to
help
with
planning
in
the
future.
F
Just
to
rub
up
on
this,
it's
going
to
save
one
of
the
problems
that
we
spotted
and
I
am
talking
to
my
team
right
now.
There
are
watching
this.
The
last
thing
I
want
is
a
customer
following
an
issue
and
the
saving
the
notifications,
because
we
are
talking
too
much
about
estimation.
This
is
really
noisy
for
the
customers
and
it
will
be
really
pissed
off
if
we
are
adding
a
lot
of
comments
before
the
iteration,
because
they
are
just
following
that.
So
having
a
different
issue
for
each
domain
is
going
to
solve
that
problem
directly.