►
From YouTube: GMD.Hangout.November.28.2018
Description
GMD.Hangout.November.28.2018
A
C
B
C
C
B
C
D
B
E
B
I
think
that
in
I
don't
recall
if
you
were
on
the
call
yesterday,
but
we
discussed
that
our
group
should
start
doing
some
planning
for
2019,
not
with
the
goal
of
finishing
it
today,
but
to
include
that
on
our
agenda
and
I'm
happy
to
include
it
after
we
do
our
regular
agenda
or
before,
depending
on
your
craft
right.
So
it
doesn't
matter
to
me.
Okay,.
E
E
E
B
E
And
try
during
the
process,
of
course
sorry
I
didn't
notice
yeah,
so
we
have
number
551,
which
is
for
preparing
the
google
Summer
of
Code
proposal.
I,
don't
know
if
this
should
be
better
in
the
governing
repository,
but
it's
okay
here
awesome.
We
can
have
it
any
way,
but
nothing
to
do
with
it
now.
I
think
so.
The
other
one
was
15,
which
is
the
use
case
for
Community
Managers
I
think
this
is
pending
until
you
think
handwriting
I
saw
the
the
blog
post,
so
I
think
it's
related
to
that
right.
E
E
E
A
E
C
B
D
E
Area,
which
is
the
other
thing
that
we
that
the
thing
that
we
decided
to
go
top-down
like
the
diversity
and
interesting
team?
Is
them
so
the
idea,
if
you
will
to
go
through
all
the
TEDx
description
of
the
focus
areas
and
try
to
write
the
descriptions
so
in
this
issue,
I
read
from
Putin
I
was
proposing
some
goals.
If
you
find
them
reasonable,
I
can
just
reduce
the
Google
APIs
for
that
and
go
there.
B
C
E
E
A
E
B
C
E
E
B
B
A
E
A
E
B
E
B
A
E
E
So
now
we
can
discuss
that
because
maybe
you're
right,
maybe
in
the
book
records
there,
is
something
broken
okay,
then
let's
move
to
33,
which
is
that
the
use
case
submitted
from
but
by
way-
and
this
is
pending
the
the
review
of
the
pull
request.
So
now
we
can
talk
about
it
and
the
other
two
are
all
issues
that
we
still
need
to
deal
with
some
point,
but
they
are
more
generic,
defining
what
is
organizational
sub
and
sub
projects
in
some
multi
matrix,
but
for
now
I
feel.
B
E
E
E
If
we're
talking
about
a
pull
request,
number
47,
first
draft
of
code
honey
when
your
contributors,
so
this
was
be
a
question
on
the
issue
and
in
fact
we
had,
as
you
say,
seen
a
full
discussion
in
the
in
the
issue.
So
what
I
tried
to
do
was
took
all
that
into
Apple
Records
within
a
specific
text,
and
it
follows
you
are
good.
The
only
thing
that
we
can
do
is
to
merge.
A
E
E
B
A
B
E
B
B
Separate
from
our
working
group,
I
start
I
looked
at
the
this
is
sort
of
related
I,
looked
at
the
slide
for
the
software
committee
and
added
updates
on
each
of
the
pieces
of
software,
including
prospector,
which
I
just
loved
as
a
listed
item.
Mm-Hm
I
think
that
maybe
we
want
to
discuss
the
role
of
prospector
and
if
there
is
a
champion
or
advocate
that
wants
to
continue
to
develop
it.
B
E
B
E
E
C
Yes,
the
chaos
project
overall
as
a
large
umbrella,
would
really
benefit
from
having
the
work
groups
to
find
their
goals
so
that
those
goals
can
be
expressed
at
the
project
level.
Clearly,
and
so
that's
kind
of
it
kind
of
the
bottom-up
approach.
I
think
will
work
very
well
here,
as
opposed
to
the
chaos
project
telling
the
work
groups
what
to
do,
because
that's
just
not
the
structure
we've
had
so
far.
So
that's
the
request.
The
reason
for
the
request.
Okay,.
E
So,
from
my
point
of
view,
the
the
idea
would
be
to
produce
some
of
the
metrics,
if
possible,
for
the
next
Kallstrom,
which
is
in
two
months
from
now.
I
would
like
to
have
a
date
on
one,
if
possible,
two
of
the
focus
areas,
at
least
with
a
draft
for
a
proposal,
but
honestly
I,
don't
know
it's
going
to
depend
at
the
pace
we
can
work
during
the
next
few
weeks
and
for
the
rest
of
the
year.
E
I
would
like
to
go
through
all
the
focus
areas
make
them
consistent
with
the
use
cases
that
we
can
get
during
this
time,
so
basically
investing
in
having
more
use
cases
more.
The
tailor,
the
use
cases
and
in
the
top-down
approach
thread
by
the
PI
summer,
or
something
like
that.
We
may
have
a
formal
release.
E
Let's
say,
of
all
the
focus
areas,
at
least
with
the
first
version
of
the
matrix,
so
that
we
can
really
produce
something
because
we
have
been
you
know
for
a
while
for
a
while
doing
this
and
we
still
didn't
produce
even
the
first
version
of
the
matrix.
So
that
would
be
my
goal.
I,
don't
know
exactly
the
schedule,
but
maybe
for
some
or
something
like
that.
Yeah
yeah,
please
would
you
say
just
DC
in
the
chat
window.
B
C
C
D
E
My
main
concern
math
is
that
we
have
been
talking
about
metrics
and
all
of
these
for
more
than
one
year
and
we
still
didn't
deliver
anything
bad.
On
the
other
hand,
we
have
clear
ideas
at
this
and
some
of
the
focus
areas
and
some
of
the
of
the
metrics
in
there
because
both
same
is
implementing
them
and
some
people
are
finding
them
useful
and
we
are
implementing
them
into
more
lab
and
some
other
people
are
finding
them
useful
as
well
yeah.
E
C
C
E
What
I
mean
is
if
we
can
produce
a
document
like
this
one
quickly
and
without
a
lot
of
discussion?
Yeah
I
mean
it's
not
the
very
document
in
the
world,
but
it
is
good
enough,
so
I'm
happy,
but
this
is
going
to
include
a
lot
of
discussions
and
this
is
going
to
prevent
us
and
work
in
another
staff
for
both
weeks.
What
I
would
prefer
to
focus
on
the
metrics
honestly
I
see.
C
E
E
B
Think
maybe
we
could
start
at
Google
back
and
draft
it
together.
One
of
the
one
of
the
thoughts
I
had
is
that,
because
we
have
a
lot
of
metrics
enumerated
and
have
a
lot
of
people
have
a
good
conceptual
understanding
in
our
working
group,
but
we
haven't
fully
defined
them
yet
I
think
there's
a
for
each
metric
that
falls
under
a
use
case,
there's
kind
of
a
natural
workflow
of
listing
the
metric
describing
it
and
enumerated
how
to
implement
it
and
then
from
there.
B
There
can
be
one
to
end
different
software
implementations
of
that
metric
and
I
think
it
would
be
good
because
of
the
nature
of
this
workgroup
to
have
I.
Don't
use
the
word
dashboard.
But
we
all
know
what
that
means,
but
some
kind
of
dashboard
or
area
where
you
can
see
the
status
and
progress
of
the
development
of
this
fairly
large
collection
of
discrete
metrics
that
were
working
towards
in
the
context
of
each
of
these
focus
areas.
B
A
D
B
E
It
does
to
me:
go
ahead,
answer's!
No
from
my
point
of
view,
I'm
not
saying
that
your
approach
is
not
is
not
about
protection,
but
may
be
complimentary
to
that.
I
would
like
to
focus
on
having
at
least
one
of
the
focus
area
fully
implemented
from
the
goals
to
the
questions
to
the
metrics
into
the
implementation
of
the
metrics
as
soon
as
possible,
so
that
people
can
really
follow
the
whole
process,
because
my
impression
is
that
people
who
could
may
be
interested
in
in
contributing
right
now
find
this
a
bit.
E
E
B
E
So
that's
what
I
would
all
like
to
for
engaging
people,
not
not
that
much
interested
in
the
group
I
I
would
like
to
produce
us
I
mean
to
to
let
people
who
use
use
cases.
Anyone
can
really
produce
bad
for
their
specific
delivery
of
the
group.
We
need
to
work
on
the
focus
areas
and
give
you
all
the
process,
at
least
for
one
of
those.
B
E
Don't
know
if
that
can
be
in
a
specific
goal,
but
one
of
our
goals,
I
think,
should
be
towards
the
group,
because
right
now
there
is
just
a
50s
within
and
it's
important
because
I
think
there
are
many
people
in
care
that
can
contribute,
but
maybe
they
don't
really
know
how
to
do
that
and
they
may
became
a
gap
created
because
they
don't
see
the
results
of
their
contributions.
I.
E
B
Getting
that
getting
that
first
set
of
focus
area
goal
getting
the
first
focus
area
fleshed
out
by
chaos.
Con
in
early
February
I
think
serves
that
role
of
enlarging
the
group
like
I,
think
it
make.
It
will
make
it
easier
people
to
understand
how
to
engage
and
contribute
to
this
working
group.
That.
E
C
E
A
D
A
B
A
A
E
E
E
I'm
in
concern
is
whether
we
can
extreme
like
the
process,
because,
right
now
we
are
a
British
law
and
my
impression
is
that
we
are
still
done
half
less
out
the
process
completely
okay,
once
we
have
them
if
it
works,
I
think
we
can
do
that,
but
that's
going
to
depend
on
whether
the
process
works
and
people
can
contribute.
You
know
in
a
way
that
it's
flexible
enough
and
all
of
that,
okay.
C
E
E
E
E
B
E
G
I
wanted
to
say
something:
I
didn't
want
to
say
before.
Yes,
because
I
didn't
want
to
add
more
noise
in
the
discussion,
but
I
sent
an
email
to
the
mailing
list.
Clearly
talking
about
an
issue,
I
have
opponent
in
Ramallah,
because
I'm
starting
building
some
dashboards
in
Havana
on
top
of
Ramallah,
to
implement
some
of
the
metrics
we
have
in
the
co-development
area
focus
area,
so
I
will
be.
G
It
would
be
good
if
you
could
have
a
look
at
the
issue
and
comment
if
you
have
something
to
say:
I,
try
and
try
to
start
simple,
so
I'm
trying
to
implement
a
simple
metric
for
protest
work,
because
just
starting
with
this,
there
are
a
lot
of
things
that
I
think
it
is
worth
to
discuss.
For
instance,
I
started
with
a
pull
request.
G
Merge
metric
and
one
thing
I
realize-
is
that
on
github
you
cannot
be
sure
if
a
pull
request
is
virtual
or
not
relying
on
the
API,
because
times
if
you
were
based
upon
request
and
then
you
merge
the
per
request.
The
API
says
that
the
they
they
request
is
closed,
but
not
Mert.
So
what
this
is
a
description?
Not
work
here
but
for
the
issue,
but
it
will
be
great
if
you
could
help
me
to
define
how
we
can
identify
these
kind
of
things.
B
Language,
there's
even
a
there's,
even
a
more
complex
case
that
you'll
find
with
full
requests
that
are
closed
but
not
merged.
So
sometimes
the
pull
requests
are
closed,
not
merged
and
then
opened
again
later
and
merged
and
I
think
one,
and
we
I
think
you
soon.
I
have
discussed
something
like
this,
maybe
not
around,
for
requests
but
around
issues
where
what
we
want
to
do
is
look
at
the
state
within
whatever
window.
It
is
we're
looking
at
so
if
the
time
window
we're
looking
at.
B
If
this
pull
request
is
closed
but
not
merged,
and
that's
how
it's
reported
at
debt
at
the
end
date
of
that
window,
even
though
its
state
might
be
different
later
and
closed
and
not
merged
I
think
we
and
I
don't
we
haven't
discussed
this,
but
in
order
we've
interpreted
that,
as
somebody
made
a
full
request,
somebody
who
is
in
charge
of
the
project
a
committer
usually
has
said
this
is
not
a
pull
request
that
we
want
to
merge.
At
least
at
this
time.
Maybe.
E
E
The
perming
here
seems
to
be
that
when
you
up
those
in
the
pull
request,
you
cannot
know
if
we
do
was
closed
with
Mertz.
That
was
a
waste,
so
it's
in
fact
an
accepted
worse
than
merch
or
one
that
was
declined
because
in
both
cases
you
have
a
closed,
will
request
and
no
reference
to
the
commit,
because
I
think
that's
because
of
the
relation,
because,
usually
you
have
one
commit
in
the
pool
request.
But
if
you
reverse
the
hands
for
the
commit
changes
and
the
API
is
not
prevailing
both.
B
B
B
E
But
this
is
the
kind
of
discussion
I
would
like
to
have
with
respect
to
how
to
actually
implement
in
the
other
issues.
So
this
located
does
the
same.
So
if
you
don't
mind,
go
to
the
issue
and
comment
in
this
because,
for
instance,
if
this
is
something
lurking
both
with
version
4
of
the
API,
that's
something
that
we
should
say
clearly
in
the
implementation.
References
for
the
metric.
B
A
E
E
Thank
you
so
in
fact,
I
taught
the
bird
to
open
the
issue
in
the
hideous
repository,
which
is
where
he
is
implementing
the
dashboards.
But
maybe
we
cannot,
in
a
companion
issue
in
the
working
group
just
to
discuss
the
details
of
how
to
implement
the
metric
in
general,
not
not
in
this
specific
case
of
jamala,
but
these
things
that
you
said
seen
about
something
about
this
something
being
supported
in
version
4
and
not
version
3
of
the
API.
That's
quite
interesting
for
the
implementation
for
the
reference
implementation,
yeah.
B
B
These
get
into
these,
and
this
is
more
of
a
medic
question,
but
these
kinds
of
questions
get
into
so
we're
up
to
this
point.
We've
talked
mostly
about
how
we
want
to
define
them,
providing
reference
implementations
using
the
tubular
notebooks
rather
means
now
we're
also
talking
about
how
we
might
source
data
from
from
different
places,
and
this
has
come
up
in
the
augur
discussions
when
we
think
about
our
back-end,
we're
working
towards
a
little
bit
more
clarity
about
the
source
of
the
data,
because
you
can
get
you
actually
get
different
answers
by
mining.
B
C
B
B
A
E
E
B
E
E
Remembered
and
in
the
description
of
the
metric,
we
should
have
something
like
implementation
notes
or
something
where
we
should
write
down.
They
recommended
way
of
end
of
implement
in
the
metric
I'm,
throwing
something
let
me
that
may
apply
in
the
case
of
gate
ham.
Please
use
version
four
of
the
API
because,
with
Perkins
reunification,
these
problems
that
we
have
prevalent.
E
B
I
think
I
think.
Ultimately,
these
kind,
like
some
kind
of
index,
managed
set
of
issues
like
this,
so
I
suggest
Kevin.
The
thing
that
you
could
do
right
now
is
create
an
issue
category
or
tag
or
label
that
can
be
applied
to
issues
like
this.
So
when
later,
we
want
to
go
and
aggregate
them
for
the
project
they're
easier
to
access,
because
I
think
I
think
doing
it
at
the
Kaos
project
level.
With
questions
like
this
will
increase
people's
trust
in
what
the
metrics
mean
their
consistency
across
implementations,
how
to
interpret
them.
B
A
E
E
That's
fine
I
agree,
so
anything
go
for
I
mean
in
any
collection
that
we
do
of
this
kind
of
the
communication
is
going
to
be
very
interesting
because
these
issues
are
going
to
pop
up
once
again
in
any
implementation
of
the
metrics.
So
it's
better
that
it's
that's
a
centralize
it
in
some
way
within
all
that
space
is
easily
accessible
by
anyone,
so
yeah
I
agree.