►
From YouTube: GMD.Weekly.Hangout.December.19.2018
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
Let
me
check
this
is
this
is
basically
a
sorry,
an
issue
open
by
a
child
and
if
he
was
proposing
well
in
this
case,
and
now
he
split
that
into
two
use
cases,
so
I'm
working
with
him
in
trying
to
find
them-
and
my
impression
is
that
he
is
still
understanding
how
we
define
use
cases,
because
he
was
bit
upset
about
me
asking
for
questions
instead
of
going
directly
to
matrix,
basically
I'm
working
with
him
on
that,
except
that
they
have
any
comment.
I
have
nothing
specific
footage,
then
number
60
is
goals
for
next
year.
A
B
A
I
know
I
was
I
was
looking
at
the
other
recording
and
I
made
some
suggestions
in
the
in
the
course
itself.
My
impression
is
that
we
are
close
to
it.
There
are
some
changes
source
of
today,
and
maybe
we
can
just
accept
it
or,
but
but
let's
go,
let's
go
to
it.
If
you
want
so
it's
it's
pull
request,
I'm
going
to
pull
requests,
it's
number
11,
try,
Namek
number
58
and
in
factories
came
and
updated,
and
so
I,
basically
man.
C
Yeah
shun
give
me
instructions
like
last
time
and
help
how
to
address
the
issue.
Mm-Hmm
yeah
and
the
structure
was
done
now.
The
thing
was
the
content,
because
I
was
not
very
familiar
with.
The
like
I
was
not
at
very
beginning
to
understand.
That's
why
I
said
I
mean
the
content
of
what
should
go
on
like
to
fill
the
introduction
and
that
background
thing.
Ok,.
A
No
that's
fine.
What
I
was
asking
for
was
how
the
different
changes
were
addressed,
because
otherwise
it's
difficult
to
find
out
which
ones
can
be
closed,
because
this
is
just
the
general
note
on
how
to
work
with
rapists.
So
when,
when
somebody
comes
and
open
a
revision,
usually
we
made
a
comment,
and
we
say
I
would
like
to
see
this
fixed,
for
example,
and
your.
A
C
A
A
If
we
can
close
some
comments
and
the
usual
way
of
proceeding
is
basically
you
as
the
submitter
see
a
comment
by
the
reviewer,
then
usually
you
decide
whether
you
want
or
you
can
address
it
or
not,
and
we
just
comment
on
what
you
are
doing
and
what
you
are
doing.
Maybe
I
cannot
fix
this
I'm
sorry,
but
they
can
not
I
need
help
or
or
I,
don't
agree
with
you.
It
can
also
be
a
feasible
answer.
They
don't.
C
A
A
A
A
This
is
another
use
case
by
call
this
is
the
other
one,
so
I'm
working
with
him.
So
nothing
else
to
say
number
four.
If
refine
code,
the
block
on
focus
area
here,
I
have
a
new
pool
records
that
they
can
tell
you
right
now,
because
they
just
uploaded
it.
I
didn't
have
time
before
that,
I'm
sorry
for
to
being
so
close
to
the
meeting.
So
alright.
C
A
We
can
rebuild
it
in
a
moment,
so
the
next
one
use
case
with
with
Ray
what
efficiency.
Basically,
we
are
moving
forward
reasonable
requesting
good
to
show
you
it
now
to
and
then
the
last
to
use
issues
I
think
we
can
forget
about
them
for
now.
So
if
you
don't
have
questions
about
issues,
we
can
move
to
pull
requests
now.
A
A
Okay,
then,
then,
let
me
check
just
a
second,
so
you
said
they
do
were
close
in
ok,
the
refining,
co-development,
Focus,
RS,
okay,
perfect
yeah,
so
it
just
a
comment
when
I
was
trying
to
do
it.
What
I
found
is
that
in
the
current
structure
that
we
have
now
so
if
you
look
at
the
file
and
you
look
at
the
changes
that
I
did
I-
think
first
of
all
that
we
need
tags.
A
We
need
something
like
observations
from
notes
or
something,
because
we
need
to
put
a
context.
For
instance,
in
the
case
of
this
goal
we
need
a
time
period.
We
need
to
specify
we're
referring
only
little
code
and
so
on.
So
this
is
a
new,
let's
say
section
or
whatever,
but
we
didn't
have
in
the
template,
but
maybe
we
should
include
it
for
all
the
focus
areas.
B
A
B
A
A
So,
for
instance,
instead
of
commits
ambition,
changes
because
that
could
better
apply
to
our
system
that
maybe
I'm
not
using
commits,
but
any
other
thing
all
for
tracking
changes,
so
I'm
trying
to
use
a
nickname.
So
this
can
have
an
impact
on
the
names
on
the
name
in
that
we
are
using
for
all
the
metrics.
A
So
something
similar
happens
with
code
reviews,
for
instance,
because
I'm
talking
about
proposals
instead
of
merge,
request
or
put
request
or
or
pads,
which
are
the
different
name,
is
that
they
use
in
github,
gitlab
and
anchor
it
so
think
of
it
about
different.
All
of
you,
because
my
impression
is
got
that
for
the
names
of
the
metrics.
We
should
keep
a
generic
names
and
then
in
the
mapping
section
of
in
symmetric,
saying
if
this
is
for
github
discourse,
poster
project
was,
for
instance,
if
this
is
for
grid
lab.
A
A
A
B
A
The
plus
signs
I
mean
things
that
I
added
you
can
see
how
for
a,
for
instance,
for
efficiency
I'm
using
as
the
name
of
the
metric
proposal.
Duration.
If
you
look
at
the
corresponding
metric
that
we
have
now
in
the
list
of
metrics,
that
is,
there
is
a
very
similar
metric,
which
is,
let
me
remember,
it's.
A
B
B
A
A
In
the
question
dude,
you
say
it
tells
it
considering
proposal
for
changes,
which
is
the
usual
way
that
developers
refer
to
them,
but
I
agree
that,
maybe
maybe
people
don't
realize
that
it
corresponds
to
people
requesting
it
have,
for
instance.
So
maybe
what
we
can
do
is
to
include
in
the
question
itself
the
name
for
instance,
for
example,
in
the
case
of
kidnap,
this
is
a
good
request
so
that
we
keep
the
generic
name.
C
A
E
I've
heard
this
many
times
a
request
for
this:
hey
sirs,
so
I
mean
I.
Appreciate
you
doing
this.
I
also
I
also
think
that
going
towards
the
generic
names
is
a
better
idea
than
those
specific
to
github
and
then
specifying
what
that
generic
name
is
in
Garrett
or
github
or
get
lab.
So
I
fully
agree
with
you,
I
guess
that's
what
I'm
trying
to
say,
and
we
have
members
right.
We
have
members
of
this
community
from
gitlab.
C
A
Okay,
so,
and
the
other
thing
that
I
wanted
to
take
your
attention
to,
is
basically
the
structure
of
the
question
and
metric
section.
As
I
said
it,
it
is
now
hierarchical,
so
its
base
it
on
the
list
of
calls
for
each
of
the
goals,
the
list
of
questions
and
for
each
of
the
questions,
the
list
of
metrics,
so
that,
in
the
end
we
would
have,
we
would
always
have
a
metric
in
a
context
so
that
we
no
longer
have.
A
If
you
look
at
the
legacy
metrics
below
you
can
see
that
before
this
we
have
at
metric
and
the
question
for
the
metric,
so
this
basically
makes
it
the
other
way
around.
So
the
important
thing
is
the
goal
and
the
question
and
then
base
it
on
a
specific
goal
in
question.
We
get
a
list
of
metrics
and
not
the
other
way
long.
So
this
is
should
be
consistent
with
the
top-down
approach
that
way
and
diversity
and
inclusion
are
using.
E
A
Instead
of
happy
it's
very,
if
you
go,
if
you
look
at
the
pad
at
the
bottom
of
the
pad,
you
can
unfold
the
old
version
where
it
starts
with
legacy
metrics
in
questions.
You
have
an
icon
on
the
left
or
well.
You
can
unfold
and
see
the
previous
version,
and
if
you
look
at
the
previous
version,
what
we
had
in
a
table
was
the
name
of
the
metric
and
the
question
for
that
metric
right.
What
I've
done
now
is
doing
it
the
other
way
around.
A
E
E
A
A
B
A
Good
then,
we
have
another
worse,
multiple
requests
that
I
see
that
she
note
radius
if
it
is
just
a
matter
of
a
structuring,
this
is
number
64
is
s.
The
matter
of
Istra
are
trained
repositories
right,
we
are
paid
so
nothing
to
say
and
then
for
the
two
that
are
still
open.
The
first
one
is
trying
to
add
matrix
to
the
array
use
case
and
the
again
this
is
important,
because
it's
the
first
thing
that
we
are
adding
matrix
to
a
use
case.
So
there
is
no
need
of
talking
about
this
now.
A
E
A
Quite
similar,
but
it's
not
exactly
the
same
I
mean
we
can
go
to
the
door
to
the
other
question,
but
the
thing
is
in
it:
usually
they
deduce
cases
are
going
to
have
only
one
goal,
maybe
more,
but
it's
more
useful
that
they
have
just
one
goal
when
they
have
several
goals.
Usually
the
goals
are
interrelated,
because
the
the
person
proposing
the
use
chains
doesn't
need
to
do
the
let's
say
that
the
the
thought
process
of
trying
to
find
out
what's
different,
what's
the
same
and
so
on.
A
A
A
To
some
extent,
I
think
so.
I
agree
with
that.
My
impression
is
that
we
shouldn't
be
too,
let's
say
demanding
on
the
use
cases
so
that,
even
if
they
are
not
very
well
formulated
or
something
like
that,
questions
should
be
accepted
from
the
point
of
view
that
we
need
people
would
submit
in
use
cases
if
they
are
understandable.
That's
that's
good
enough.
Maybe
we
can
try
to
refine
the
question
into
something
more
specific
or
something
like
that
when
we
are
dealing
with
that
into
the
focus
area.
Okay,.
E
D
E
A
Okay,
and
the
only
thing
is
that
if
we
very
clearly
see
okay,
it's
a
better
way
of
saying
this
like
this
or
something
like
that,
we'll,
of
course
we
can
suggest,
but
that
would
be
only
only
from
the
point
of
view
of
making
the
question
smoothly
you're,
not
necessarily
of
making
them
aligned
with
the
questions
that
we
have
in
in
in
the
in
the
focus
areas.
Enough.
E
A
So
nothing
else
to
say,
with
respect
to
this
pull
request,
step
to
have
a
look
at
it
and
if
you
agree
with
it,
we
can
start
to
use
also
it
as
the
template
will
for
the
next
cases
and
then
the
other
one
is
the
structural
changes
to
the
readme
that
we
already
talked
about.
So
nothing
else
from
my
cyan't
about
food
requests
or
issues
I.
A
B
B
A
And
there
is
the
document
with
the
goals
for
next
year.
Yes,
so
in
any
case,
just
in
summary,
as
I
said
in
the
in
the
comment
in
the
issue,
I
already
agree
with
the
main
goals,
and
so
what
I
was
proposing,
in
fact,
was
maybe
to
fill
in
the
the
problem
statement
mission
in
risks.
If
you
want
and
propose,
this
is
a
pull
request
so
that
we
can
include
that
intro
file
into
the
repository
to
have
it
there,
so
that
everybody
knows
as
a
kind
of
a
road
map
or
something
for
the
next
year.
B
Those
are
the
sort
of
two
specific
objectives
under
goal
to
I
like
because
they
give
us
timelines
and
priorities.
Mm-Hmm
I'd
like
to
know
a
little
bit
more
before
I
mean
I,
guess
so.
I
have
some
questions
about.
How
do
I
think
we
should
elaborate
on
some
of
the
goals?
I'm
good,
with
doing
the
problem
statement.
First,
mm-hmm.
A
So
from
from
my
point
of
view
for
them
for
the
the
first
focus
are
L,
which
is
the
one
that
we
are
trying
to
commit
to
the
fo
for
for
the
next
milestone.
That
would
be
called
development
and
I'm
trying
to
push
it
so
right
now
we
are
discussing
questions
and
metrics.
So
hopefully
we
can
finish
the
discussion
on
the
general
structure
of
costanera
matrix
or
during
the
next
week.
Oh
yeah.
C
A
D
B
B
I'm
just
gonna
start
like
trying
to
iterate
while
we're
sitting
here,
problem
statement
and
I,
don't
know,
I
would
characterize
the
problem.
As
there
are
I
mean
in
the
returning
decline
space.
There
are
a
number
of
metrics
that
are
widely
used
and
understood,
but
they
lack
they're
implemented
in
various
nuanced
and
difficult
to
navigate
ways
and
so
I
think
one
of
the
the
principal
problem
statement
for
our
group
is
to
Shepherd
existing
metrics
and
growth
maturity
and
decline
and
create
standard
definitions
of
them
and,
where
possible
or
necessary,
elaborate
new
metrics
for
growth.
B
E
Yeah
yeah,
so
I
think
one
of
the
things
that
needs
to
come
of
2019
is
and
I
clearly
articulating
what
the
GMB
space,
what
I
mean
in
telling
people
that,
if
there's
a
new
metric
that
needs
to
be
tossed
and
telling
them
to
go,
take
a
hike
it
doesn't
fit.
This
isn't
the
this,
isn't
the
current
scope
of
GMD,
and
so
that
was
kind
of
my
thought.
A
A
A
A
E
B
E
Goal
I
don't
know,
let's
just
do
maybe
it's
kind
of
a
goal
for
me:
yeah,
like
a
top
level
into
a
sources
point
we
can.
You
know,
still
capture
the
conversation
of
things
that
may
reside
in
GMD,
but
that's
just
not
where
we're
at
right
now.
That's
just
not
the
current
focus.
I
think
that
was
your
point
issues
so.
A
It
would
be
good
enough
to
say
this
is
the
bit:
they
ordered
a
decorated
for
the
different
goals,
and
probably
that
should
be
then
I
mean
support
for
the
different
focus
areas
and
from
a
point
of
either
speed
am
base
it
on
the
interests
of
the
people,
participated
in
the
working
group
and
that's
it.
So
if
somebody
else
can
same
proposes
a
new
focus
area
and
the
focus
area
seems
sensible,
we
can
accept
it,
but
we
can
at
the
same
time
say:
okay,
that's
fine!
A
B
Although
I
think
risk
is
going
to
need
to
create
a
working
group
meeting
time
focused
on
that
emphasis
area
for
later
in
the
day,
so
that
the
Asian
continent
can
participate
so,
but
I
would
like
to
not
necessarily
split
off
and
create
a
new
working
group
administration
like
I,
think
it's
good
to
have
the
risk
working
group
in
a
separate
part
of
the
repository,
maybe
at
some
point
and
have
the
actual
development
of
those
metrics
emerge
in
a
related
area.
At
some
point.
B
A
Happy
with
having
risk
having
a
separate
meeting
or
something
that
that's
needed,
the
only
thing
is
if
we
are
going
to
be
in
the
same
repository
and
in
the
same
let
see
general
idea.
We
need
to
discuss
the
the
structure
and
stuff
like
that,
but
nothing
else
which
can
be
completely
autonomous.
Probably
at
some
point.
That's
something
that
the
system
to
be
done.
We
need
to
decide.
A
How
is
the
consensus
would
be
ensured
they
had
all
of
us
agree
with
reading
in
all
the
subs
area,
but
for
now,
I
see
more
this
as
a
problem
of
writing
things
and
not
of
let's
say
reviewing
things
because
up
to
now,
what
we
need
is
the
the
14-2
structure
in
and
all
of
that,
and
not
necessarily
in
doing
the
review
that
that
can
come
later.
Yeah.
B
A
Now,
thinking
again
about
the
goals,
I
would
like
to
make
they're
getting
more
use
cases
as
an
a
specific
goal,
because
right
now
I
realize
it's
not
the
could
be
related
to
their
goal.
Number
four,
but
maybe
it's
good
to
have
it
as
a
separate
goal
so
that
it's
it's
it
more
splitted
that
we
won't
use
cases.
So
what
do
you
think.
B
A
I
I
didn't
write
that,
but
they
assume
that
that
means
that
when
we
are
getting
more
and
more
use
cases,
we
should
be
keeping
an
eye
on
them
to
make
sure
that
the
focus
area
are
consistent
with
them.
I
mean
they
are
delivering.
What
the
use
cases
need
to
some
extent.
I
think
that
but
I
didn't
write
that
so,
maybe
so.
D
B
A
D
A
To
be
a
structure,
it
should
be
much
more
thought
they
should
be
well-defined.
So
that's
why
I
think
that
use
cases
should
inform
how
we
write
that
the
focus
areas,
but
there
is
no
direct
mapping
between
them,
so
we
can,
for
instance,
ignore
a
use
case
if
within
it
doesn't
fit
a
focus
area
for
some
reason.
A
On
the
other
hand,
we
should
consider
them
and
not
yes,
not
just
ignore
them,
because
we
want,
but
just
because
there
is
a
reason
for
that,
but
I
see
them
at
two
different
spaces,
so
use
cases
are
in
the
real
world
somehow
and
that's
where
people
specifically
want
or
are
doing
with,
metrics
and
and
the
our
structure.
What
tries
to
do
is
to
structure
the
space
of
jmd
by
saying
these
are
the
metrics
you
know
usually
goes
should
be
consistent
with
use
cases,
but
but
not
necessarily
so,
but
that
does
my
my
view.
B
C
B
We
have
I
think
there
are
several
use
cases
that
are
relevant
under
that
area,
and
so,
when
I
say
make
scan
the
focus
areas
consist
with
these
cases.
It's
actually
to
me
kind
of
the
question
is
how
to
make
the
use
cases
be
how
to
identify
what
use
cases
fall
under
the
umbrella
of
each
focus
area,
and
so,
if
I
was
taking
a
focus
area
and
wanting
to
sort
of
create
a
boundary
around
it
and
try
to
understand
it
and
explore
it.
B
A
But
then
I
need
to
go
to
my
lab
and
I
start
doing
a
hierarchy
of
species
or
whatever,
and
that's
how
I
structure
everything
that
I
saw
in
that
room.
So
the
use
cases
are
like
what's
happening
in
natural,
what's
happening
the
reality
and
then
we
need
to
structure
that
into
a
hierarchy.
That
makes
sense,
and
that
means
that
we
need
to
have
use
cases
into
account.
But
that
doesn't
mean
that
you
use
cases
come
directly
into
our
hierarchy
of
those
codes.
So.
B
I
also
say
that
another
example
is
I
know
a
certain
number
of
things
that
exist
that
are
inside
of
my
category
of
a
use
case,
so
I
use
so
I
think
what
you're
saying
is
the
use
case
doesn't
need
to
be
bounded
in
a
focus
area
that
can
emerge
in
the
wild.
Like
a
scientific
observation
does
and
then
be
classified
under
a
focus
area.
Once
it
becomes
clear
what
focus
area
it
belongs
to
I
think
it's
also
true
that
we
know
which
trees
are
deciduous
in
which
trees
are
not
know.
B
A
That's
fine,
so
that's
why
I
said
in
many
cases
we
already
know
about
use
cases,
even
if
no
real.
Let's
say
we
on
user
chem
scintilla
us,
because
we
have
been
working
in
the
field
floor
for
a
while,
and
we
know
the
kind
of
questions
that
many
people
need
for
the
prison,
so
I
completely
weight
with
writing
your
sketches
of
ourselves
in
those
cases
and
I'm.
Probably
those
kids
are
going
to
be
very
much
aligned
with
the
focus
areas,
because
we
know
about
the
folks
I
rescue
and
we
can
start
to
the
the
use
case.
A
B
B
B
A
B
A
But
the
Patera
that
both
things
are
helpful
in
the
sense
that
the
reference
implementation
is
going
to
be,
let's
a
pretty
basic.
But
in
the
case
of
a
guru
and
goomar
lab,
you
can
see
the
metrics
in
a
context
where
it's
are
some
of
the
metrics
and
stuff.
So
every
would
poor
things.
So
maybe
we
can
say
concrete
implementations
of
cost
metrics
in
in
in
our
goal
and
dream
or.
A
A
A
D
D
A
Don't
mind
that
man
so
the
easiest
model,
if
some
people
cams
and
on
CDs,
maybe
it's
better
that
they
see
first,
the
number
the
call
number
two,
because
it
says
more
clearly
what
we
are
going
to
do.
Of
course,
it's
also
in
the
context
of
goal
number
one
so
really
I
I'm
not
going
to
make
an
issue
of
this,
so
whatever
you
may
prefer
I.
B
Think
I
think
yeah
I
mean
I.
Think,
let's,
let's
put
go-to
up
above,
go
on
and
change
their
numbers.
I
agree
with
that.
I
was
just
trying
to
understand
it.
I
wasn't
I
wasn't
like
singing
it
like
questioning
it
like.
It
was
a
good
idea
or
not.
It
was
more
wanting
to
make
sure
I
understood
what
we
were
trying
to
do
and
now
I'm
getting
it.
C
A
A
D
A
A
B
A
C
A
A
A
A
Maybe
not
the
matrix
completely
implemented,
but
a
number
of
the
matrix
should
be
implemented
and
the
general
structure
should
be
complete
so
that
we
can
discuss
and
hopefully
approve
it.
And
then
we
can,
for
the
next
of
the
month,
work
in
the
matrix
themselves,
so
that
we
can
announce
at
the
cows.
Can
the
first
version
of
the
of
a
focus
area
which
is
sort
of
complete.
Okay,.