►
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
I
think
that'll
be
the
easiest
way
to
go
about
soliciting
some
feedback.
So
initially
my
team
was
adding
a
feature
to
the
approver
section
in
projects.
So,
instead
of
having
human
approvers,
you
could
have
a
essentially
like
a
service.
Do
an
approval
of
the
merge
request,
so
some
sort
of
like
api
call
and
to
us
it
made
perfect
sense
of
like
okay.
The
action
of
what
this
performer
is
doing
is
approving
a
merge
request.
A
A
I
got
from
kai
and
pedro
was
this:
approvers
is
meant
to
be
more
like
human
driven,
which
I
didn't
know
necessarily
when
I
was
designing
on
the
onset
of
introducing
this
feature,
since
we
had
some
other
other
types
of
approvals
in
the
mix
like
vulnerability
checks
and
license
checks,
which
I
now
better
understand,
but
they
weren't
as
fully
fleshed
out
back
then,
when
I
was
initially
designing
the
feature,
and
so
the
pain
point
I'm
running
into
now
is
like
we've
already
started.
A
Development
on
the
feature
and
source
code
was
essentially
worried
about
this,
impacting
the
experience
of
a
merge
request
which
has
a
lot
of
active
users.
So
it's
very
high
priority
and
we
don't
want
to
impact
it
negatively,
so
they
were
asking
us
to
kind
of
stop
work
and
you're,
saying
no.
We
don't
really
want
to
stop
work
on
this.
Necessarily.
We
still
think
like
our
direction
is
okay.
The
one
area
that
I
was
considering
pivot
was.
A
We
wanted
to
add
this
into
initially
the
approver
section
so
there'd
be
like
human
approvers
and
then
your
virtual
approvers,
through,
like
these
approval
gates
and
I'm
conceding
to
say,
I
think
it
would
be
okay
to
at
least
pivot
to
moving
this
into,
like
the
merge
request.
Widget
section,
I
think,
is
how
this
is
referred
to
so
instead
of
having
it
here,
you
have
it
appear
here
as
like
an
optional
check
for
your
merge.
A
My
struggle
is
like
what
what
do
you
all
do
when
you
run
into
situations-
and
maybe
it
doesn't
happen
as
often
for
your
group,
but
where
you're
impacting
something
downstream
and
the
other
group's
like?
No,
I
don't
want
you
to
do
that.
You're,
like
hey,
I
tried
to
engage
you
early,
but
we
didn't
really
come
to
a
fruitful
decision
a
while
back,
so
it
seems
kind
of
late
in
the
game
to
bring
it
up.
B
I
think
in
this
case,
I'd
want
to
know
what
their
complaint
is
against
it.
I
think
the
need
for
it
is
important
and
if
it's
impacting
whatever
they're
saying
is
like
well.
Yes,
that's
your
point.
It's
there
to
stop
rule
and
mars
from
going
through
without
the
check,
and
it
only
applies
in
the
case
where
the
check
is
needed.
It's
not
just
a
global
thing.
That's
automatically
done
so
if
a
non-compliant-minded
organization
doesn't
need
it
they're
never
going
to
see
this
right,
I
think,
but
also
backing
up
too.
B
I
think
at
least
from
when
I
was
working
in
compliance.
The
idea
was
not
just
for
an
individual
person,
but
for
like
automated
systems
or
bots
as
individual
approvers
or
checks
in
the
line
to
help
with
that,
not
necessarily
a
specific
person.
I
don't
know
if
that's
changed
since,
but
just
in
terms
of
like,
I
don't
think,
there's
much
difference
between
this
or
any
other,
the
checks
that
exist
currently
in
the
mr
process.
So
I'm
not
sure
what
the
complaint
is
from
them
so
which
I
don't
understand
why
they
would.
You
would
need
to
pivot.
A
Yeah,
I
think
it
mostly
stemmed
from
maybe
more
attention
to
the
merge
requests,
page
itself
and
its
performance
aspects.
There
were
questions
around
it
being
a
confusing
user
experience.
A
What
we
were
trying
to
do
was
extend
the
functionality
of
an
existing
feature,
whereas
their
opinion
was.
This
is
not
applicable
to
this
feature
at
all.
It
should
be
its
own
thing,
so
I
still
see
it
like
you
said
valuable
as
like
a
an
iteration
that
we
can
introduce
into
the
product,
because
it
does
give
the
users
functionality
to
actually
bring
these
checks
into
gitlab,
because
they're
happening
just
externally
now,
so
I
think
it's
still
a
valuable
change.
A
C
I
appreciate
it,
but
actually
after
hearing
the
situation,
maybe
my
response
isn't
quite
as
applicable
as
it
was
when
I
just
kind
of
read
the
question
and
threw
an
answer
out
there.
Of
course
it
was
just
about
understanding
risk
of
not
completing
the
request
versus
the
complexity
that
might
be
associated
with
implementing
it,
but
it
sounds
like
maybe
there
was
a
communication
opportunity
that
was
lost
or
you
know
not
potentially
properly
addressed.
C
Daniel,
I
think
I
don't
know
if
that
was
austin
typing
out
your
response.
A
Yeah
I
was
putting
in
some
thoughts
by
daniel
but
yeah.
He
was
saying
like
ask
why
better
understand
like?
What's
the
reasoning
for
like
stopping
the
work
which
we
did,
we
did
get
to
a
good
discussion
point.
A
I
think
some
of
the
problem
did
lie
on
the
fact
that
my
previous
pm
hadn't
coordinated,
super
well
across
the
groups,
even
though
I
was
like
coordinating
with
pedro
a
bit,
and
so
I
think
just
continuing
to
keep
that
in
mind
the
future
that
we
should
have
to
what
mike
is
saying
in
his
point
I'll.
Let
him
discuss
it,
but
tying
in
more
earlier
on
with
other
groups
to
better
understand
the
problem
that
we're
trying
to
solve
together
could
prevent
these
pain
points
in
the
future.
D
So
I
know
that
pedro
has
done
a
great
bit
of
work
on
mapping
the
object
model
of
the
of
the
mr
and
the
different
types
of
interactions
and
functions
that
come
along.
For
the
specific,
mr
and
I
wonder
with
this
exercise
whether
you
can
sort
of
reflect
on
the
content,
that's
been
shared
and
documented
within
that
object,
model
and
think
what
was
what?
What
could
this
have
informed?
The
decision
making
process
a
little
bit
more
upfront?
D
Could
it
have
aided
with
communication
in
any
way
and
if
not,
what
information
was
lacking
that
could
have
been
there
in
order
to
sort
of
ensure
that
this
didn't
work?
This
didn't
go
the
way
that
it
that
it
has
now.
It
seems
like
from
from
like
at
the
high
level
from
from
what
you
talked
about.
D
There's
like
a
misalignment
in
like
the
narrative
of
or
like
figure
out
the
the
feature
that
you're
posing
the
extension
of
the
feature
you
were
posing
didn't
align
with
the
narrative
that
that
pedro
had
in
mind
for
that
particular
feature.
So
I
wonder
whether
there
is
a
gap
there
that
could
somehow
be
documented
for
for
future
cases
where
this
may
happen.
A
Yeah,
I
think
that's
a
really
great
articulation
of
it
nick
and
I
would
even
say
probably
when
we
first
were
discussing
this
feature,
which
I
think
this
was
like.
Maybe
last
august
or
september
we
were
talking
about
it
that
might
not
even
have
been
defined
yet,
and
then
it
was
like,
as
they
went
down,
did
more
research
into
the
architecture
of
a
merger
request
and
then
started
to
put
parameters
around
too,
like
what
do
each
of
these
things
mean
like
what
does
the
approver
section
mean?
A
What
did
mr
widgets
mean
that
hadn't
necessarily
gotten
around
to
me
thinking
about
like
okay?
Maybe
that
should
impact,
how
we
introduce
this
feature
either.
So
you
know,
as
pedro
was
thinking
about
it
more
and
working
through
with
kai
on,
like
defining
these
things,
to
help
people
better
contribute
to
merge
requests
themselves.
A
D
Definitely
understand
your
challenge,
though,
because
mrs
the
the
majority
of
usage
for
mrs
sort
of
comes
within
the
realm
of
source
code
management
and
all
this
sort
of
stuff,
so
as
a
team
is
trying
to
kickstart
a
feature
off
which
requires
an
interaction
from
an
mr,
it's
quite
difficult
to
iterate
in
a
small
way
on
it
without
impacting
the
broader
interface.
So
finding
that
right
balance
is
incredibly
difficult.
So
I
can
empathize
with
you.
A
I
appreciate
that
yeah.
I
think
the
other
thing
that
we
struggle
with
too
is
how
do
we
enable
things
with
feature
flags
or
not?
A
We
opted
to
not
use
or
to
not
have
on
by
default,
so
we
are
requesting
that
users
turn
on
a
feature
flag
in
order
to
use
this
specifically,
knowing
that
it's
probably
going
to
be
going
under
some
revisions
in
the
future
and
getting
some
select
customers
to
actually
use
it
because
they've
been
demanding,
it
would
be
helpful
for
understanding
how
is
it
actually
getting
incorporated
into
their
workflow
and
not
hypothetically
incorporated
into
their
workflow?
A
A
Luckily,
we
hadn't
actually
do
it
built
or
planned
anything
yet
for
the
merge
request
page
but
as
I
was
kind
of
like
showing,
we
had
already
built
the
ability
to
create
it.
So
just
like
okay,
how
does
it
render?
We
can
affect
that,
but
this
part's,
maybe
a
little
bit
too
late
to
back
out
of
for
this
milestone.
A
Mike
did
you
want
to
talk
more
about
your
concept
of
like
a
kickoff
issue
before
I
hunt
it
over
to
holly.
E
E
I
don't
know
of
any
rituals
that
are
documented
in
the
handbook
or
that
we
practice
consistently
and
one
of
the
one
of
the
rituals
that
I've
seen
work
well
in
the
past
is
a
kickoff
and
normally
you
know
in
a
in
an
office
environment
where
everyone
shows
up
in
their
snazzy
as
clothes
and
their
hair
is
groomed
and
they
all
get
into
a
big
room
and
there's
a
lot
of
energy.
E
Kickoffs
are
really
fun,
but
it
can
also
be
really
time
consuming,
and
so
I
think
we
have
unique
advantage
to
go
synchronous
first
and
really
just
make
a
kickoff
issue,
and
I
guess
in
the
kickoff
issue,
you
know
we
want
to
make
sure
that
stakeholders
have
voiced
something
other
than
a
thumbs
up
reaction,
that
stakeholders
have
voiced
any
concerns
or
potential
risks.
E
E
A
A
Where
did
this
discussion
happen
would
be
useful
to
make
sure
we
have
a
way
to
backtrack
and
say:
okay,
where
did
we
come
up
with
these
decisions,
because
right
now
it
kind
of
gets
interspersed
as
a
bunch
of
comments
on
like
designs
that
get
uploaded
to
gitlab
and
then
like
threads
in
the
issue
itself
and
then
yeah,
I
think,
having
at
least
a
single
source
of
truth
for
that
cross
stage.
Collaboration
would
be
good.
I
like
that
idea.
C
I'll
just
jump
in
unless
mike
has
anything
else.
He
wants
to
add
to
that
and
say
that
I
love
this
idea
as
he
was
talking,
though,
about
the
meeting
where
everybody
comes
in
and
they're
all
dressed
up,
I
did
feel
a
sense
of
there
is
one
thing
that
I
like
about
that,
and
that
is
that
it
makes
that
setting
feel
a
little
bit
more
celebratory,
a
little
bit
more
unified
and
there's
a
bit.
C
More
of
a
sense
of
this
is
something
that
we
all
need
to
have
on
our
radar,
whereas
just
a
traditional
issue,
it
tends
to
kind
of
get
lost
in
the
flow
a
little
bit
for
me.
So
I
love
the
idea
if
we
did
pursue
something
like
this
of
just
having
like
kickoff
in
the
title
or
something
that
helps
to
kind
of
separate
it
a
little
bit,
so
it
doesn't
kind
of
feel
like
it
gets
lost,
and
maybe
a
label
could
be
another
way
to
do
it.
C
I
don't
know,
but
but
I
love
the
idea
of
doing
that.
That
would
be
my
only
thought
about
going
with
something
like
that
for
an
issue.
A
D
When
would
you
spin
up
a
kickoff
issue,
as
opposed
to
just
commenting
within
the
context
of
an
issue
that
you're
working
on
currently
so,
for
example,
you
yeah,
you,
you
and
your
team
have
been
discussing
the
the
approvals
gate,
which
sounds
like
watergate,
almost
approvalsgate
thing
and
like
in
I
think
in
this
instance,
you
just
like
put
a
comment
in
there
and
say:
look,
this
is
what
we
are
thinking.
Could
you
review
the
designs
in
the
context
of
this
issue
or
or
whatever?
A
Personally,
I
would
say
once
you
have
a
problem
defined
well,
if
you
have
something
in
problem,
validation
and
you
want
to
start
moving
into
workflow
design-
and
you
know
it's
cross
stage,
you
should
at
least
start
having
that
kickoff
discussion
there,
because
then
that
other
group
you're
working
with
could
better
help.
You
identify
existing
solutions
that
might
already
exist
to
help
solve
the
problem
or
better
help.
You
scope
the
solutions
that
you're
starting
to
design
and
that
at
least
creates
that
tie
into
it.
D
D
I
can
see
some
cases
where
having
it
just
in
the
scope
of
the
issue
that
you'd,
like
your
initial
idea,
was
in
yeah.
Potentially
there
it
is
it's
equivalent
to
like
having
design
issues
almost
like
sometimes
having
an
independent
design.
D
Issue
is
good
because
you
could
document
more
detail,
sometimes
just
having
the
design
in
the
context
of
the
broader
issue
is,
is
more
useful,
so
I
think
experimenting
probably
provides
a
little
more
context
as
to
rules
of
thumb
as
to
when,
when
it's
good
to
do
that
versus
when
it's
good
just
to
have
a
comment
or
something.
A
Yeah,
I
agree
and
I'll
I'll
definitely
tie
it
up
here
and
we'll
jump
over
to
holly's
point.
So
we
have
some
time
to
discuss
it,
but
definitely,
I
think,
for
merge
request
at
the
very
least
because
it
is
such
a
impactful
feature
to
the
gitlab
experience.
E
It
and
one
more
thing,
which
is
issues,
have
different
intentions.
Right.
You
create
an
issue
to
elevate
a
problem.
We
create
an
issue
to
track
the
progress
of
defining
that
problem.
We
create
an
issue
to
track
who
we're
recruiting
to
validate
that
problem
in
this
case
would
be
an
issue
to
gain
alignment.
E
So
you
know,
rather
than
put
it
trying
to
gain
alignment
in
a
comment
thread
of
an
issue
intended
to
explore
a
design
to
create
an
issue
to
gain
alignment.
C
Thank
you.
This
is
just
kind
of
a
question
that
came
about
from
a
conversation
with
another
designer.
Last
week
we
were
kind
of
having
a
coffee
chat
and
I
asked
them
how
their
day
was
going
and
they
said
they
were
feeling
a
little
discouraged
because
they
feel
like
they
don't
always
have
the
time
to
do
all
the
things
that
they
need
to
do
in
a
day,
and
I
kind
of
echoed
that
sentiment
at
that
particular
moment.
C
C
How
did
I
not
know
that
I
needed
to
be
doing
that
or
how
did
it
slip
off
my
radar
and
I
feel
like
some
folks,
do
this
really
really
well,
so
I'm
just
curious
what
maybe
techniques
you
know,
some
of
you
use
to
stay
on
top
of
all
the
things
that
are
not
related
to
feature
work.
C
I
know
I
had
spoken
with
marcel
about
this
a
few
months
ago
and
he
said
he
very
intentionally
blocks
off
time
each
week
to
dedicate
to
certain
things
that
are
not
necessarily
feature
or
even
okr
work
and
I'm
curious.
If
anyone
else
does
anything
like
that
or
if
there
are
any
other
methods
that
you
use
to
ensure
that
these
things
don't
slip
off
of
your
radar.
B
I
try
and
just
give
myself
like
one
hour
of
the
week
to
look
at
other
things,
just
throw
it
on
my
calendar,
other
work,
pajamas
time
or
whatever
just
so,
I'm
intentionally
doing
it.
I
don't
always
succeed.
I
don't
actually
produce
something
all
the
time,
but
at
least
I'm
thinking
about
and
looking
about
it
see
how
I
can
get
to.
E
It
now
every
every
role
has
you
know
the
top
things
that
you
need
to
do
daily.
That's
a
daily
operation
to
keep
things
moving
smoothly.
E
The
reason
I
put
the
eisenhower
matrix
up
there
is,
I
know
that
sometimes
where
our
time
is
driven
by
our
calendar
or
our
time
is
driven
by
whose
attention
who's
who's,
the
squeakiest
wheel
and
the
eisenhower
matrix,
helps
us
put
those
things
into
context
and
and
prioritize
accordingly,
and
that
could
you
could
use
it
on
a
day-to-day
basis
or
a
weekly
basis
or
a
monthly
basis,
but
the
important
thing
is
that
the
most
important
things
get
done
first
and
in
the
product
designer
responsibilities,
I
believe
giving
the
feedback.
E
Yeah,
so
if
that's,
if
that's
the
thing,
that's
kind
of
pushing
our
attention
it
could
I
could
see
how
it'd
be
frustrating
that
you
don't
find.
You
have
time
for
other
things
like
let
alone
career
growth
right
like
doing
courses
in
linkedin
learning
or
whatever
you
prefer
to
learn,
see.
I'm
I'm
just
saying
I
would
love
to
hear
other
people's
tactics
on
how
they
do
that.
I
think
austin.
You
were
next.
A
So
I'm
just
really
focused
on
feature
work
and
like
really
diving
into
research
and
then
there'll
be
like
a
stretch
of
time
where
I
just
have
more
space
to
fit
in
some
contributions
to
the
handbook
or
feedback
with
other
designers,
and
that
feels
that
feels
better
to
me.
So
when
I
can
go
back
and
look
at
the
responsibilities
for
a
designer,
as
I
look
for
like
evidence
of
doing
those
things,
I
think.
Oh,
I
haven't
done
anything
for
pajamas
in
six
months.
A
I
should
really
prioritize
something
this
quarter
to
start
doing
something,
because
that
is
part
of
my
responsibilities
and
I
either
neglected
to
do
it
or
rather
have
been
prioritizing
other
things
over
it
to
say,
I'm
going
to
do
a
little
bit.
This
quarter
really.
Isn't
that
much
of
a
ask
I
would
say
so.
A
Whatever
works
in
your
schedule,
without
being
like
overly
prescriptive
of
I'm
only
going
to
work
on
pajamas
one
hour
a
week
on
wednesdays,
because
it's
just
not
always
feasible
for
at
least
the
way
that
I
work
to
fit
that
in
as
much
as
I
love
structuring
my
days.
Sometimes
that
can
feel
too
too
rigorous.
C
Do
you
literally
have
a
reminder
system
though,
or
do
you
just
it's
just
kind
of
in
the
back
of
your
mind,
always
and
you
just
say
not
right
now,
but
when
I
get
time
I
will.
A
So
one
thing
that's
been
useful
for
me:
is
I've
been
doing
these
like
asynchronous
ux
office
hours,
I'm
kind
of
reviewing
what
I
did
on
a
weekly
basis
and
I
can
kind
of
feel
the
trend
of
I
spent
a
lot
of
time
merge
requests
this
week.
I
spent
a
lot
of
time
in
pajamas.
I
spent
a
lot
of
time
on
features
and
just
over
time
I
can
kind
of
feel
what
is
like.
B
C
E
Feedback
nick
shared
a
quarterly
planning
issue
that
it's
really
cool
if
you
pop
it
open
and
then
daniel
you
try
to
set
aside
an
hour
a
time
each
week
to
dedicate.
D
Soon
enough,
we
should
be
able
to
measure
the
distribution
of
your
work
within
the
product
as
well
holy
like
based
on
the
issue
types
thing
that
you're
doing
right
now.
You
could
effectively
have
like
an
issue
type
for
for
your
product
planning
and
seeing
the
distribution
of
where
you're
allocating
your
time
as
a
designer
we're
doing
that
in
value
stream.
D
So
you'll
be
able
to
create
a
personal
value
stream
based
on
the
different
types
of
work
items
that
you're
working
on
and
you'll
see
a
distribution
of
where
you're
spending
your
time
week
by
week.
So
you
can.
You
can
work
that
at
different
levels,
from
personal
all
the
way
to
the
team
level
and
beyond.
C
C
F
No,
I
was
in
well,
our
last
stop
was
vegas,
and
so
I'm
I'm
kind
of
like
out
of
it
from
a
dune
buggy
crash.
But
hey
I'm
here.
This
is.