►
From YouTube: 2020-05-12 Manage:Compliance 13.1 Final Planning
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
All
right,
thank
you,
see
I'll
go
through
13,
one
real,
quick,
see
if
we're
in
agreement
on
that
and
then
do
a
quick
status
update
on
30,
no
cuz
I
just
want
to
make
sure
that
all
my
feature
blocks
are
in
order.
So
for
thirteen
one.
This
is
the
the
third
or
like
final
piece
to
the
merge
across
approval
settings
that
we're
delivering
as
a
holistic
solution.
Today,
tan
raised
concern
that
the
second
of
the
three
issues
might
are
became
more
complex
than
he
originally
thought,
and
so
let
me
actually
pull
that
one.
A
Because
I
don't
know
if
there's
a
special
consideration
or
process
around
this,
but
he
basically
said
that
we
can
put
everything
as
it
stands
today
behind
a
feature
flag
so
that
it's
as
if
the
feature
was
never
released,
because
this
particular
change
will
essentially
break
it.
And
so
then,
why
have
it
in
production?
I'm?
Ok
with
that
I
just
don't
know
if
there's
anything
I'm
supposed
to
do
to
inform
users
about
that.
B
So
for
30,
no,
you
know
because
it's
a
major
upgrade.
We
do
have
a
list
of
breaking
changes,
this
one's
so
minor
and
it's
been
out
for
such
a
short
period
of
time.
I,
don't
know
that
we
need
to
like
try
to
go
sneak
that
in
there,
because
I
think
it
may
have
already
released
it.
I
think
we
could
add
it
in
after
the
fact.
Well,.
B
I'm
not
too
concerned
about
it
being
a
breaking
change
actually
talked
to
tan
about
this.
Yesterday
afternoon.
You
know:
I'm
not
too
concerned
about
this
I,
really
like
the
idea
of
just
putting
the
whole
package
behind
a
feature
flag.
This
was
tans
idea
and
you
know
putting
the
whole
thing
behind
a
future
flagon
and
you
know
just
kind
of
iterating
behind
the
future
flag
for
now,
yeah.
A
A
A
He
didn't
say
this
would
bump
to
13
1
unless
the
schedule
is
he
rolled
out
as
a
complete
solution,
13.
So,
okay,
so
I
think
maybe
that's
what
he's
referring
to
is
like
we'll
have
the
whole
solution
in
13,
1
and
maybe
I
just
misunderstood,
so
I'll
wait
for
his
async
feedback,
but
it
has
a
case
that
sounds
good
to
me.
Okay,.
B
Good
I
think
you
know
I
think
he's
hopeful.
He
can
move
quickly
here,
but
at
this
point
we
have
a
series
of
em
ours
that
need
to
be
executed
in
the
next
week
and
a
half
before
the
end
of
the
milestone
and
it
like
we're
real
serious
risk
of
slippage
here,
like
you
know,
it's
not
a
guarantee,
but
you
know
it's.
It's
50/50
at
best,
I
would
say
yeah.
A
B
Yeah
yeah,
so
he'll
be
able
to
continue
work.
You
know
he
doesn't
have
to
wait
for
the
M
are
to
be
merged
to
continue
work,
so
he
can
kind
of
get
ahead
of
the
game.
So
as
soon
as
some
kind
of
merge,
he
can
get
review
going
on
the
next
one.
I
could
actually
even
get
review
going
before
that
for
that
matter.
Okay,.
A
Yeah
that
sounds
good
I'll
see
what
he
says
as
far
as
confidence
and
then
maybe
update
the
customers
depending
on
that
so
cool.
So
it's
that's.
The
one
I'm
also
trying
this
new
thing
just
for
my
own
sanity,
of
adding
the
weights
and
assignees
here
as
I'll
update
this
after
this
call,
even
though
it's
a
little
bit
of
administrative
overhead
I,
find
it
helpful.
So
I
can
see
everything
in
aggregate
but
open
to
feedback.
If
you'll
have
suggestions
there.
So
a.
B
A
B
A
All
I'll
experiment
that
today,
because
that
sounds
like
a
good
idea-
let's
see
so
this
one
was
adding.
So
this
was
a
follow-on
to
a
previous
feature
or
update
to
audit
events,
which
was
adding
changes
to
mergers,
approval
rules
so
the
previous
one.
We
added
audit
events
for
if
authors
or
committers
were
allowed
or
denied
from
approving
in
Mars,
and
we
also
captured
the
number
of
required
approvers.
A
So
if
it
changed
number
of
numerical
value,
the
missing
piece
was
audit
entries
for
the
approval
groups
themselves
when
they're
added
or
removed-
and
that
was
a
specific
ask
from
one
customer
in
particular,
but
kind
of
closes
the
loop
on
that
audit
event
and
I
think
this
was
probably
the
last
one
we
were
doing
so
as
not
to
continue
to
compound
the
audit
events.
Refactor
work,
yep.
A
A
A
Understood
that
to
still
be
in
design,
because
we
hadn't
committed
to
a
specific
solution
on
it.
Okay,
which
is
why
I
slotted
this
one
in
because
the
expectation
from
leadership
is
that
in
q2
we
get
Auto
reports
to
minimal,
and
this
felt
like
it
was
the
lowest
hanging
fruit,
I'm.
Okay,
to
change
that.
If
you
feel
that
export
events
as
CSV
is
in
a
good
place,
because
that's
less
supplemental
work,
I
needed
you
to
synchronize
as
a
direction
page
right.
B
A
It
was
Leon
thinking,
we
were
I
agree
and
that's
the
same
memory
I
have
I.
Just
don't
recall
us,
like
I,
saw
him
and
post
the
proof
of
concept,
but
I
don't
remember
there
being
a
decisive
like
this
is
what
we're
doing
I
understood
the
proof
of
concept
to
be
like
well,
here.
Here's
the
proof
of
concept.
Do
we
agree
on
this
and
to
me
that
left
it
ambiguous
gotcha.
B
B
A
B
B
A
B
A
So
there
are
two
separate
reports,
so
the
export
autodefensas
CSV
is
for
the
audit
events
at
the
instance
level
to
export
that
as
a
CSV
and
then
this
custom
API
endpoint,
is
for
a
user
access
report,
which
was
we
created
the
epoch
for
ultimately
getting
to
a
point
where
a
customer
could
click
on
the
next
for
to
download
all
users
and
their
group
and
project
memberships
got
it.
I
thought.
A
B
I'm
still
thinking
about
how
the
refactoring
fits
into
this,
because
you
know
like
how
do
we
want
to
display
this
stuff
and
and
maybe
it'll
it'll
kind
of
help
inform
how
we
want
to
go
about
the
refactoring.
But
you
know
what
do
we
want
to
present
to
users?
So
we
certainly
don't
want
to
present.
What's
in
the
details,
column
in
the
database
cuz,
that's
it's
a
little
wacky.
B
Just
because
this
refactoring
is
kind
of
an
emerging
thing
at
developing
conversation,
I'm,
not
exactly
sure.
So
let
me
let
me
get
a
little
further
with
that,
I
mean
so
alright,
let's
go
ahead
and
leave
this
as
a
stretch
goal
like
you're
talking
about,
and
let
me
try
to
get
a
little
bit
farther
with
the
back
end
team
in
terms
of
that
refactoring
yeah.
A
B
A
A
It's
these
are
the
two
issues
that
are
tied
into
the
filtering
audit
events.
These
are
the
two
I
think
front,
end
ones:
I
don't
have
any
back-end
work
involved
and
then
the
two
with
back-end
work,
I
think
I,
just
I,
don't
know
what
I
did
with
those
I
think
they're
down
here
yeah
these
two
so
I'll
incorporate
those
into
thirteen
two
or
whatever
milestone
whenever
they're
no
longer
blocked
but
yeah.
These
two
are
already
being
tackled
by
Robin,
Yan,
I,
think,
respectively
yeah.
C
I
guess,
in
terms
of
just
discussing
what
front-end
can
do
I
mean
I,
guess
we
have
to
figure
out
with
capacity
planning,
how
much
work
back
in
teams
we're
gonna
be
working
on,
but
Robin
Jana
both
discussed
interests
and
helping
out
with
some
of
the
back
and
stuff.
It's
awesome
we're
happy
to
help.
We
can
cool.
A
So,
let's
see
yeah
I
think
this
is
just
another
bug
fix,
but
tie
it
into
the
notifications
about
expiring
tokens
because
it
included
impersonation
tokens
but
sounds
like
that.
I'll
just
be
picked
up
whenever
engineer
has
time,
for
it
is
that
right,
yeah
I,
think
so.
Okay,
so
I
think
we're
at
a
total
of
eighteen,
three,
six,
nine,
twelve
yeah
so
I
think
we're
told
of
eighteen,
which
I
think
I
understood
that
to
be
within
the
range
of
what
we
expect
capacity
to
be.
Is
that
right,
I
think.
A
A
I
think
it
was
actually
this
particular
issue,
the
MVC
that
yeah
yan
talked
about
being
interested
in
it
like
I
I.
Imagine
they
meant
on
the
front
end,
but
if
there
was
interest
in
supporting
back
end,
maybe
that's
the
balance
so
that
we
can
still
explore
the
instance
level
audit
event
export
as
CSV
in
addition
to
this
one.
But
what
do
you
think
I
have.
C
A
Naoko
I
appreciate
that
clarification
yeah
other
than
that
I'm,
okay,
being
a
little
bit
light
unless
there's
any
proposals
for
something
to
fill
that
void.
But
it
sounds
like
my
takeaway
is
to
add
that
export.
That
is,
this
level
audit
event
export
to
the
stretch
goal
for
now
and
then
Dan
you
and
I
async
can
figure
out
if
we
should
swap
that
around
in
the
next
couple
of
days
or
so
yeah.
C
C
A
C
A
So
let
me
share
real
quick,
so
this
is
what
I'm
aware
is
still
outstanding:
the
impersonation
events,
which
I
think
tan
already
has
an
open,
mr
for
it,
and
we
had
confirmation
from
customers
on
the
last
remaining
implementation
detail
which
is
basically
do
we
want
maintain,
errs
and
group
owners
to
see
the
impersonation
events
in
their
respective
audit
logs,
and
the
answer
was:
yes,
that's
fine,
so
I
think
that's
on
track,
but
I
know
Dan.
If
you
have
any
other
insight.
A
C
C
I
need
to
follow
up
on
this.
One
I
thought
this
was
done,
but
now
this
is,
it
sounds
like
this
is
an
issue
that's
being
Resta
mated
to
five.
They
asked
me
what
I
felt
about
it
and
if
I
we
estimating
it
while
it's
in
review,
that's
kind
of
conflicting,
okay,
yeah
I'll
ping
in
the
channel
just
to
get
some
eyes
on
it
sounds.
A
C
A
Okay
and
then
the
on
deck,
it
seems
like
we
got
to
that
I
believe
were
taken
to
a
point
where
they
were
sufficiently
broken
down
or
we
had
like
an
MVC
outcome.
So
I'm
happy
with
that
I
feel
like
two
is
a
reasonable
expectation,
each
milestone,
given
how
busy
everyone
is.
So
if
maybe,
we
can
use
that
as
the
benchmark
for
13:1
and
strive
to
get
two
more
broken
down
in
some
way,
which
I
think
we're
already
on
track
to
have
one
of
them
broken
down
things
to
rob
at
least
for
the
front
end.
C
At
the
same
time,
let's
see
if
we
could
maybe
push
for
more
I
mean
part
of
it
is
also
understanding
how
much
time
we're
able
to
have
in
those
or
individual
contributors
to
actually
refine
these
issues.
So
if
we
can
push
for
maybe
degree
and
then
see
if
and
then
measure
how
much
time
we're
spending,
maybe
we
have
a
better
idea
of
like
okay,
we
should
start
formally
appropriating
some
time
for
issue.
We
find
that
that
make
sense
yeah.
B
I
mean
one
of
my
concerns.
There
is
context.
Switching
you
know
like
these
are
very
technically
complex
kind
of
feature
proposals
and
they
take
a
lot
of
mulling
over
like
these
bigger
ones,
so
yeah
to
Dennis.
This
point,
I'm
I'm
kind
of
thinking
about,
like
maybe
we
should
be
setting
aside
dedicated
time
for
that
you
know
just
so
there's
not
so
much
like
you
know,
in
the
middle
of
your
day,
completely
switch
your
context
to
something
else.
A
Yeah
I'd
be
interested
in
feedback
from
the
engineers
as
well,
because
I
totally
understand
that
and
I
want
to
I
want
to
support
whatever
workflow
works
for
the
both
of
you
and
them.
If
it
were
me,
I
would
probably
welcome
the
context
switch
as
a
break
from
what
I'm
currently
working
on,
but
that's
just
me
and
that's
probably
not
everyone
but
yeah
I'd
love
to
hear
what
you
and
they
think
and
figure
out
what
process
y'all
prefer,
whether
it's
like
that
dedicated
time
or
like
whatever
that
looks
like
please.
Let
me
know.