►
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
B
B
C
A
C
C
A
B
C
B
And
I'll
share
I'll
put
it
on
unfiltered
as
soon
as
it's
done.
Processing.
C
Well,
I'll
jump
into
my
agenda
item,
I
was
hoping
to
get
some
design
feedback
from
y'all,
so
I
wanted
to
show
how
this
feature
works
today,
to
give
context
of
why
I
think
another
iteration
on
this
feature
would
be
useful
in
the
security
compliance
tab.
When
you're
in
a
group,
you
can
go
to
the
compliance
dashboard
and
today
it's
only
showing
you
the
most
recent
merge
request
for
each
project
within
that
group.
I
don't
think
it
shows
projects
that
are
in
subgroups.
C
I
think
it's
just
for
once
in
that
room
group,
but
there's
a
button-
that's
not
so
much
tied
to
what's
in
this
table.
So
this
button
allows
you
to
take
out.
These
merge
commits
into
a
csv
file
and
you
could
even
look
for
specific
merge
commit
sha,
and
so
that's
all
you
can
do
with
it.
It's
useful
because
there
are
auditors
that
will
ask
for
specific
data.
That
rel
relates
to
a
specific,
commit
and
you'll
have
to
go
in
and
find
that
data.
So
without
having
this
functionality,
you
have
to
go.
C
Look
for
the
merge
request,
then
look
for
those
specific
attributes
within
a
merge
request
that
have
that
commit
shot
which
could
be
kind
of
just
hard
to
discover,
but
I
don't
really
love
the
fact
that
this
button
has
kind
of
nothing
to
do
with
this.
Oh
then,
these
are
merge
requests
and
these
are
merge
commits.
C
So
what
I
was
aspiring
to
do
was
create
a
dedicated
page
that
has
that
csv
data
in
it
essentially
there's
a
separate
tab
for
merge
requests
violations,
which
is
what
we're
currently
building
so
to
the
screenshot
to
the
left
of
it.
That's
what
that
dashboard
is
going
to
turn
into
so
this
will
be
more
about
merge,
requests
that
have
made
compliance
violations
and
then
the
one
next
it
would
be
a
what's
known
in
the
industry
as
a
commit
custody
report.
C
So
this
is
how
you
can
see
who
handled
specific,
commits
what
the
outcome
of
the
pipeline
was
from
that
commit
so
on
and
so
forth.
What
project
it
associates
with
we
heard
from
a
specific
customer
that
they
will
like
divvy
up
the
responsibility
to
investigate,
commits
so
they'll,
say
all
right
person
a
you
got.
These
30
commits
person
b.
C
B
A
C
Yeah
and
the
query
today
is
fine,
for
so
we
kind
of
like
offload
the
service
and
it
runs
and
pulls
it
back
once
and
puts
in
a
file
for
you
and
sends
it
to
you
in
your
browser.
So
this
is
already
happening
today,
like
I
can
hit
export
and
it's
going
to
save
to
my
computer.
C
I
think
the
issue
is,
and
we
haven't
been
able
to
fully
validate
it
yet
because
backend
hasn't
really
looked
into
it,
but
when
you're
trying
to
actually
pull
the
data
results
back
into
a
table,
potentially
even
one
that
you
can
do
sorting
or
filtering
on
it
might
not
be
performant
where
we
don't
have
those
same
performance
constraints
we're
just
like
creating
a
file.
C
So
I'm
not
positive.
Ideally,
if,
like
back
ends
like
yeah,
we
can
do
a
table
and
we
can
filter
by
specific,
commits
and
like
great
yeah.
We
can
go
that
way,
because
I
can
then
tie
the
export
button
to
what
the
table
showing.
So,
if
we're
showing
all
all
the
commits,
then
you
can
grab
all
of
them
or
if
you
look
up
a
specific
one,
then
we
could
export
that
specific.
Commit
number
or
that
list
of
them.
C
C
It's
not
very
discoverable,
so
yeah.
C
To
say
like
maybe,
if
it's
a
smaller
organization,
they
might
just
get
all
the
commits,
but
if
it's
a
really
big
one,
they
probably
are
going
to
go
after
specific
ones.
B
C
Yeah
I
mean,
I
think,
generally
speaking,
if
they
can,
people
are
going
to
grab
all
the
data
because
it's
it
gives
them
the
most
flexibility
right.
People
love
pulling
out
data,
throwing
it
in
excel,
creating
their
pivot
tables
and
being
able
to
sort
and
find
data
that
way.
A
B
That's
kind
of
what
I'm
thinking
too,
because
for
mvc
it
seems
like
you
can
offer
everything
and
then
let
them
filter
it
out
and
then
learn
from
there
if
they
need
to
have
the
option
to
drill
in
a
little
bit
more.
I'm
glad
you're
doing
this,
though.
That
button
feels
very
odd
to
me
and
I'm
curious
if
it's
just
me,
but
it
says
list
of
all
merge
commits
and
it
doesn't
feel
like
that's
what
happens
when
you
click
it.
B
It
downloads
a
list
correct
like
I
would
almost
expect
when
I
click
that
for
it
to
somehow
filter
or
change
this
view.
But
it's
an
export
and
the
icon
helps
with
that,
but
from
an
accessibility
standpoint,
you
may
not
necessarily
get
that,
although
we
do
have
the
tooltips.
If
that
helps,
but
but
yeah,
I'm
glad
you're
revisiting
the
button.
C
C
B
C
Well,
I
think
it's
two
separate
things.
It
is
a
problem
to
get
all
commit
data
versus
just
a
versus
just
the
merge
commits
data,
then,
on
top
of
that,
it's
it's
easier
to
just
find
a
specific
commit
versus
all
of
them,
but
it
all
depends
on
how
big
things
are
so
we're
expressing
there's
a
file
limitation
of
15
megabytes
which
isn't
like
super
helpful,
because
how
many
how
much
is
15
megabytes?
You
probably
have
no
idea
how
much
your
group
has
of
data
in
it,
but.
C
But
yeah,
I
think
what
we
communicate
in
docs
is
that
it's
going
to
truncate
your
file
after
you
reach
that
limit,
so
we'll
give
it
to
you,
but
just
know
there
might
be
truncation
if
you
get
everything
so
you're
a
really
big
organization.
You've
existed
for
a
really
long
time.
Potentially
it's
going
to
be
far
more
than
you
possibly
would
want.
C
Yeah,
I
mean
it's
definitely
like
less
than
ideal,
but
we're
at
least
trying
to
acknowledge
the
constraints
of
what
we're
working
with.
I
think
this
happens
in
other
areas
too.
I
may,
if,
if
alexis
was
here,
she
might
be
able
to
speak
more
to
how
it
works.
When
you
export
issues,
I
think
at
some
point
you
might
even
experience
truncation
there,
depending
on
how
big
things
are.
I'm
not
I'm
not
positive,
though,
but
yeah.
I
think
I
was
trying
to
keep
the
same
functionality
so
still
being
able
to
export
all
of
your
commits.
C
All
of
your
merge
commits
to
a
csv
or
grab
a
specific
one,
and
I
wasn't
really
sure
how
I
should
delineate
that,
with
buttons
or
illustrations
or
ways
to
help
make
that
more
obvious.
So
my
initial
idea
was
to
have
a
button
specific
for
all
the
commits
and
then
a
button
specific
for
picking
a
commit.
C
This
would
bring
up
a
a
modal
dialogue
which
you
could
then
search
for
the
things
you're,
looking
for,
probably
very
similar
to
what
this
is
showing
here.
C
C
So
it's
well,
you
would
know
from
a
merge
request
the
commit
I
id
so
an
example.
We
could
look
at
a
specific
merge
request.
A
C
They
might
they're
trying
to
look
specifically
just
for
a
specific
commits
data.
They
want
to
know
that
ben
did
this
commit
versus
the
administrator.
Who
did
this
commit?
Because,
even
though
administrator
did
this
whole
merge
request,
ben's
responsible
for
adding
a
new
row
and
column
which
maybe
they
the
way
they
went
about,
injecting
that
code
into
the
code
base
was
not
good
whatever
that
good
means.
C
C
C
But
also
it
shouldn't
be
on
this
page
because,
like
yeah,
this
page
is
showing
you
merge,
requests
that
have
essentially
violations
ideally
has
nothing
to
do
with
specific
commits,
which
is
more
for,
like
probably
more
of
an
auditing
perspective,.
C
A
Well,
the
reason
I
bring
it
up
is
because
I'm
trying
to
think
of
what
would
make
it
more
logical
to
put
in
here
would
just
renaming
it
make
it
more
logical
to
be
in
here
would
actually
reach
changing
the
architecture
or
the
behavior
of
the
button
like
instead
of
this
merge
commit
export,
commit
custody
report
button.
If
it
did
something
else
entirely,
then
I
guess.
C
C
Yeah
they
couldn't
it
couldn't
find
it
so
it
just
brings
back
nothing.
I
guess
I
think
it
knows
it's
a
commit,
but
it's
not
a
merge
commit,
so
the
problem
would
be.
C
C
These
features
are
not
tied
together
and
I
want
them
to
better
understand
the
data
that
they'll
be
getting
before
they
commit
to
a
decision
just
so
they
can
quickly
identify
things
like,
for
example,
I
had
to
put
in
that
commit
information
and
try
and
get
the
file
and
then
open
the
file
before
I
even
knew
if
it
was
what
I
wanted.
C
So
I
would
love
to
be
able
to
just
have
entered
in
that
commit
number
here,
and
then
it
show
me
that
data
and
go
great.
This
is
exactly
I'm
looking
for
export.
My
file.
I
know
where
this
needs
to
go,
or
even
just
being
able
to
know
like
what
data
comes
in
the
file
would
be
great.
Before
I
hit
export.
A
C
A
C
Yep,
I
think
that's
where
I'm
sitting
like
I.
I
think
this
would
be
great
if
backhand
says
we're
cool
with
that,
but
maybe,
if
it's
not
trying
to
explore
a
way
to
use
illustration
or
more
details
on
the
page
to
provide
that
context
in
the
page,
but
still
keeping
the
functionality,
so
users
can
at
least
still
do
the
same
actions,
but
maybe
making
it
more
clear.
So
I'm
not
tucking
everything
behind
a
drop
down.
C
B
I
think
it's
kind
of
a
pop
over
because
it's
not
something
that's
activated
on
hover
and
it
doesn't
go
away
when
you
mouse
off,
but
by
clicking
remains
until
you
click
to
remove.
I
think
at
what
point
does
the
performance
problem
come
into
play?
Is
that
when
you
try
to
load
all
of
those
on
the
page
or
when
you
try
to
actually
do
an
export.
B
Because
I
was
looking
at
how
we
do
it
with
issues
and
issues
you
do
have
if
you're
just
exporting
a
list
of
issues,
it
does
have
obviously
everything
on
the
list
view
already.
But
when
you
go
to
do
the
export
it
does
this
email
process
and
says
we're
building
this
list
and
we'll
email
you
when
it's
done,
which
seems
like
a
good
way
to
try
to
manage
some
of
the
performance
from
that
perspective,
but
not
from
the
loading
perspective.
I
think
we
are.
B
We
have
definitely
at
least
been
talking
about
doing
infinite
scroll
for
the
issue
list,
so
we
haven't
moved.
I
don't
think
toward
that.
Just
yet,
let
me
be
sure
yeah,
it's
still
pagination,
but
that's
something
I
know
gabe
really
wants
and
we've
been
looking
into
the
pros
and
cons
of
the
different
kinds
of
pagination
and
loading
for
that.
So.
C
Yeah,
I
think
at
least
what
I've
heard
from
you
both
that
it
reinforces
the
concept
that
I
need
to
move
away
from
this
drop
down
button
ui
and
at
least
expose
it
as
equally
weighted
actions
for
now
and
then
look
for
ways
to
improve
presenting
the
data,
as
is
performant
to
our
requirements.
But
so
I
guess
I'll
take
it
from
there.
A
C
Yeah
absolutely
I
plan
on
opening
an
issue
today
to
get
some
more
feedback
from
engineering.
It's
like
one
of
those
cases
where
it's
like.
I
don't
really
feel
like.
There
needs
to
be
a
ton
of
solution,
validation
per
se,
it's
more
just.
We
haven't
built
out
the
user
experience
that
we
wanted,
because
we
had
some
limitations
on
the
data
side.
A
A
C
B
I
have
started
working
on
a
so
if
you
saw
my
ux
showcase
last
week.
We
have
this
large
project,
which
we
have
now
started
to
try
to
scale
down
a
little
bit,
but
what's
come
out
of
it.
For
me,
particularly
in
particular,
is
we
have
this
feature
object
that
we're
looking
to
create
and
I'm
going
to
be
working
to
make
it
mobile
friendly
first,
so
I've
started
doing
a
competitor
analysis.
B
So
my
question,
out
of
all
of
that,
is
related
to
the
fact
that
I'm
testing
their
apps
from
a
competitor
perspective,
even
though
I
know
we're
looking
to
offer
a
mobile
web
experience,
and
I
know
that
there
will
be
pros
and
cons
to
a
native
app
that
we
won't
have
as
part
of
our
mobile
web
web
portal,
but
any
concerns
anything
that
you
all
can
think
of
that.
I
might
need
to
keep
in
mind
in
addition
to
that,
when
exploring
this
app
as
a
competitor
or
these
apps
versus
the
mobile
web.
A
B
A
A
Back
to
what
I
was
saying
about
how
the
scope
of
them,
what's
the
projects
that
people
are
using
for
these
apps,
the
ones
that
they
have
rave
reviews
on
everything
right?
Are
they
using
it
for
like
checking
one
thing,
and
it's
like
okay?
Well,
that
doesn't
necessarily
make
any
sense
either
as
a
comparative,
because
it's
not
the
right
thing
right.
B
B
But
potentially
now
it
seems
that
it's
that
it
is
a
complex
flow.
But
when
you
try
to
just
transfer
it
to
a
mobile
environment
from
the
desktop,
it
still
feels
complex.
But
if
you
can
customize
it
and
sort
of
streamline
it
line
it
to
just
be
that
mobile
experience.
Only
you
know
and
have
it
tailored
to
fit
that
environment,
then
maybe
it's
a
better
experience.
I'd
like
to.
A
Tell
you
more
about
why
I
don't
think
if
you
defined
well
as
you
just
described
it,
it
doesn't
sound
like
a
complex
experience
at
all.
Actually,
if
you're
only
talking
about
an
issue,
viewer
and
reply
and
comment,
you're
talking
about
email,
you're
talking
about
the
chat
app
great
point,
that's
true.
If
you
say
let
me
distill
this
whole
experience
down
to
an
email
or
chat
messaging
system
and
remove
all
the
features
that
we
have
like
labels
and
milestones
and
all
this
other
stuff.
It's
like
nope,.
C
B
Well,
we
would
still
have
all
of
the
meta
information
and
the
ability
to
edit
it,
but
the
way
that
they
are
presenting
it,
at
least
in
the
cases
I've
seen
so
far,
has
been
pretty
pretty
simple.
I
know
we're
over
and
austin.
You
were
about
to
say
something.
So
if
you
want
to
maybe
close
this
out,
you're
welcome
to
with
that
comment.
C
Yeah
my
subjective
opinion
on
it
is,
I
think
we
try
and
take
everything
from
our
full
desktop
experience
and
put
it
in
a
375
with
screen
yeah.
B
C
Probably
more
lightweight
so,
for
example,
when
you're
editing
a
comment,
maybe
not
squeezing
the
whole
wysiwyg
editor
into
the
screen
and
just
letting
them
write
just
straight
into
the
text
box
or
maybe
daniel's
saying,
maybe
not
showing
every
label,
and
we
hide
all
labels
when
you're
on
the
desktopics
or
the
mobile
experience,
I
would
say
trying
to
reduce
could
be
very
helpful
in
those
ways
because,
like
you
said
when
people
are
on
their
phones,
they're
probably
doing
just
communication
for
the
most
part,
they're,
probably
not
writing
the
code,
at
least
I'm
not
also
from
my
experience
with
other
teams.
C
C
Right
yeah,
like
the
descriptions,
usually
really
short,
they're,
not
usually
really
long
threads
going
on
in
the
issues.
That's
something
very
unique
to
us,
because
we
so
heavily
focus
on
the
async
portion
of
our
work.
B
C
So
for
other
teams
just
being
able
to
go
in
and
comment
and
tag,
people
is
like,
probably
all
they
need.
So
as
much
as
you
can
reduce
and
clutter.
I
think
that
would
be
best.
I
don't
know
if
we
really
ever
talked
about
that
with
foundations
of
like
yes,
we
try
and
make
buttons
the
right
touch
size,
which
is
great.
I
love
that
we
have
all
these
components
but,
as
we
start
compressing
the
viewport,
we
don't
talk
about
removing
elements.
B
That's
a
great
point,
I
I
have
a
checklist
item
in
my
research
issue
to
evaluate
what
we
have
currently
in
place
in
relation
to
mobile
in
pajamas
and
talk
with
the
team.
So
that's
a
great
point.
I
think
a
progressive
disclosure
approach
could
be
a
good
way
to
go
just
to
like
what
can
we
show
initially
that's
going
to
provide
value
and
then
what
can
we
kind
of
hide
away?
And
again,
that's
some
of
the
stuff
that
I'm
finding
through
the
competitor
analysis.