►
From YouTube: Dev-Manage/Plan/Ecosystem UX Design Review - 2021-04-05
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).
B
All
right,
we
can
just
jump
right
into
the
agenda.
C
B
So
I
was
talking
with
sam
white
and
sam
kerr
the
other
week,
and
the
compliance
team
is
releasing
a
feature
around
integrating
an
enforced
pipeline
and
sam
brought
up
some
really
good
feedback
that
he
just
identified
this
one
that
I
hadn't
thought
about.
Why
initially
designed
the
feature
essentially
you're
to
like,
simplify
this
as
much
as
I
can
you're
forcing
a
pipeline
to
show
up
in
all
of
your
projects
that
have
a
specific
compliance
framework
assigned
to
them.
So
that's
a
very
powerful
feature
that
a
lot
of
customers
are
excited
about.
B
What
I
could
see
being
confusing
about
this
to
users
is
when
you
look
at
a
pipeline
itself,
you
won't
be
able
to
easily
distinguish
what
came
from,
like
maybe
your
project's
yaml
file
versus
this,
like
compliance
yaml
file.
So
I
was
thinking
through
just
some
simple
ideas
that
we
could
do
to
try
and
differentiate
the
components
from
each
other,
just
so
that
there's
some
sort
of
recognition
for
the
user
to
know
that
it
didn't
come
from
their
project,
but
rather
it
came
from
this
authoritative
source
that
enforced
it,
and
I
was
curious.
B
If
anybody
had
any
other
ideas
of
ui
components,
I
could
use
or
a
different
way
to
differentiate
what
pipeline
came
from
a
project
or
what
pipeline
came
from
this
compliant
source.
I
was
thinking
we
could
use
a
label
because
it's
system
generated,
but
then
that
takes
up
more
ui
space
and
these
like
little
pill
objects
in
the
pipeline,
aren't
exactly
the
most
flexible
in
terms
of
that.
So
it's
a
pretty
narrow
feedback
request,
but
I
was
curious
if
anybody
had
any
other
ideas
there
and
to
answer
mike's
question.
B
Yes,
this
is
the
initial
problem
we're
trying
to
solve
it's
the
parent
epic,
for
how
this
compliance
pipeline
configuration
works.
So
there's
a
lot
of
things
in
there,
but
this
kind
of
shows
how
that
compliance
yaml
file
combines
with
this
yaml
file,
and
then
it
shows
up
here,
but
users
probably
won't
know
why
it
shows
up
there
today.
A
C
A
Agenda
but
I
see
your
question
about
some
other
ways
to
differentiate
versus
labels
versus
icons,
and
I
came
in
right
about
the
time
that
you
were
talking
about
the
little
pills
and
how
they're
not
super
flexible.
Do
you
mind
just
recapping
a
little
bit
I
apologize
yeah
yeah.
B
So
I
think,
what's
easiest
to
illustrate
this
is
when
your
pipeline
runs,
you
have
some
compliance
specific
jobs
that
are
forced
in
there.
So
example.
Are
these
two?
The
only
way
you
know
that's
because
someone
labeled
them
with
the
word
compliance
in
front
of
it.
So
I
was
thinking
of
introducing
a
ui
element
to
try
and
distinguish
which
of
these
pipeline
jobs
came
from
that
specific
file,
that's
different,
so
this
is
like
your
project
one.
B
This
is
your
group
defined
one
essentially,
and
that
way
users
know
when
I'm
reviewing
pipelines
which
jobs
are
enforced
and
which
ones
do
we
have
control
over
and
thought
about
this
problem.
Initially,
when
I
was
designing
the
solution,
but
another
pm
brought
back
the
feedback
they're
like
hey,
this
is
confusing
these
jobs
just
showed
up
in
the
pipeline.
I
had
no
idea
why.
B
Kind
of
we're
trying
to
help
them
distinguish
the
the
yaml
file
that
they
can
define
within
their
own
project
versus
the
ammo
file
that
is
enforcing
new
jobs
in
their
pipeline.
B
B
You
know,
I
think
I'd
have
to
ask
vitica
about
that.
I
think
she
handles
the
pipeline
design,
at
least
like
the
visualization
of
it
and
stuff.
I
don't
really
know
why
it's
like
it.
A
D
It's
realized
that
so
this
kind
of
requires
a
lot
of
knowledge
of
how
ci
is
set
up
in
gitlab.
So
you'd
have
to
know
that
if
you
want
to
see
the
ci
configuration,
you'd
have
to
go
to
the
repository
and
go
to
the
dot,
got
whatever
yaml
file.
What
is
it
pipeline.yaml?
D
That's
it.
So
I
just
realized
that
this
might
be
an
opportunity
to
make
it
easier
to
navigate
to
view
the
pipeline
configuration
and
then
we
don't
have
to
distinguish
whether
it's
a
compliance
pipeline
or
not
on
with
an
icon.
We
could,
we
could
have.
D
I
don't
know
some
way
to
view
the
yemo
file
that
defined
that
pipeline,
and
so,
if
you,
if,
let's
say
it's
a
drop
down,
I
don't
I
don't
know
what
it
would
be,
but
you
click
it
and
it
would
actually
be
able
to
read
compliance
dot,
gitlab,
ci,
dot,
yaml,
and
you
know
I
think
that
provides
more
visibility
into
how
these
pipelines
are
constructed
and
what's
happening
under
the
hood
and
see.
I'm
just
saying
this
might
be
an
opportunity
to
improve
that
whole
experience
around
finding
the
configuration
for
a
pipeline.
B
Yeah
because,
like
you'd,
have
to
figure
out
where,
where
did
website,
build,
come
from
versus
compliance
test.
In
this
scenario
and
you're
saying
it
would
be
useful
to
directly
see
which
file
it
came
from,
maybe
a
drop
down
or
some
form
of
like
pop
over
or
something
that
highlights
where
that
specific
thing
was
ran.
Yeah.
D
D
Why
is
it
important
to
distinguish
that?
It's
compliance
related
pipeline.
B
So
what
will
potentially
be
confusing
to
a
developer
that
is
managing
the
pipeline
itself?
Is
they
might
not
understand
why
these
jobs
have
appeared,
because
if
they
go
to
their
projects
like
get
lab
ciamo
that
they
have
access
to,
they
can
see
all
the
jobs
to
find
in
there,
but
those
jobs
won't
be
listed
in
there.
The
one
like
these
other
ones,
those
are
listed
in
a
different
project
in
this
special
ci
file,
and
then
they
get
merged
together.
So
they
might
not
understand.
Why
are
these
houses
in
a
pipeline.
B
It
became
a
problem
to
solve
because
there
were
project
maintainers
or
really
a
group
owners
that
needed
to
enforce
a
requirement
in
their
teams.
The
only
way
they
could
really
enforce.
Something
today
was
put
like
a
pipeline
template
in
for
projects
and
then
just
hope
that
developers
wouldn't
circumvent
it,
except
then
people
did
start
circumventing
it.
So
then
it
became
a
hassle
to
try
and
manage
every
project's
ci
file
to
make
sure
that
they're,
including
these
important
jobs,
whatever
they
may
be.
They
can
vary
greatly
by
organization
and
company.
C
Yeah,
so
I
had
similar
questions.
I
guess
that,
and
you
answered
this,
but
just
verbalizing.
The
main
problem
is
that
someone
who's
working
on
a
change
will
see
some
pipelines
appear.
They
don't
know
why,
and
I
imagine
if
they
have
issues
with
them
right
like
if
they're
failing,
they
also
would
need
to
know
like
how
does
these
fit
in?
Who
can
answer
questions
about
whatever
is
happening
here?
That's
failing
right.
That
would
be
another.
B
C
Of
the
workflow,
and
then
I
asked
the
question:
why
would
someone
need
to
know
where
a
pipeline
came
from,
but
I
think
it's
related
to
that
too
right,
especially
in
case
of
failures
or
questions.
They
need
to
know.
B
C
Where
to
go
so
I
really
like
mike's
idea
of:
can
we
tie
this
closer
together
to
where
the
source
is
in
some
way?
Maybe
it
doesn't
need
to
be
within
a
specific
pill,
but
maybe
there's
something
that
just
like
literally
has
the
url
to
where
these
different
files
are.
B
Yeah
and
I'll
have
to
look
into
how,
like
the
permissions,
would
play
out
with
that
too,
because
to
like
get
this
feature
to
work,
we
had
to
use
some
principles
to
allow
us
to
just
create
this
isolated
project,
and
I
don't
know
who's
going
to
be
able
to
have
access
to
read
these.
So
I
think,
if
an
organization
sets
this
compliance
project
to
be
private
and
they
might
be
able
to
keep
people
from
seeing
what
this
file
is,
which
would
be
very
annoying.
D
Depends
on
a
lot
of
things,
so
we
a
lot
of
the
reason
why
gitlab
works
so
well
is
because
of
transparency
that
things
are
open
by
default.
So
we
know
we
could
learn
at
some
point
through
solution,
validation,
that
compliance
managers
are
in
fact
going
to
block
or
lock
that
down.
So
people
can't
see
it.
It
would
be
interesting
to
know
you
know
again
if
that
is
a
problem
to
solve,
or
if
it's
okay,
to
know
that
your
build
is
constrained
by
a
sox
compliance
rule
or
whatever.
B
Yeah
totally
and
I'll
recognize.
This
is
not
a
blocking
issue.
It
was
more
just
some
initial
feedback,
we're
hearing
as
we're
starting
to
roll
out
the
feature
itself
from
customers
and
rpms
interfacing
with
different
customers
that
they're
getting
a
little
bit
confused.
So
I
was
just
trying
to
explore
some
ideas:
how
we
could
primitively
try
and
solve
them
with
some
minor
changes,
while
we
think
about
a
bigger
solution
to
improve
the
entire
like
customer
journey
or
user
journey
around
this
whole
feature,
because
I'll
totally
acknowledge
it.
B
D
I
just
want
to
ask
melissa
a
question.
Really
quick
is
someone
who
has
familiarity
with
like
access
preferences
in
organizations?
Could
you
see
an
organization
wanting
to
block
that
someone
can
see
a
configuration
like
that,
like
a
compliance
related
configuration
or
something.
C
Definitely
editing,
but
I
would
hope
people
would
want
everyone
to
be
able
to
see
it
right,
especially
if,
like
I
said
in
case
of
investigating
failures,
I
would
hope
they
would
want
people
to
be
able
to
self-serve
with
basic
level
troubleshooting
right,
which
includes
being
able
to
see
what's
happening.
C
D
A
No,
no,
that
is
totally
fine.
I'm
hoping
that
mine
will
be
I'm
hoping
that
it'll
be
kind
of
a
simple
conversation,
but
it
might
be
more
complex.
I'm
looking
for
some
feedback
on
some
icons
and
I'll
go
ahead
and
share
my
screen
just
to
kind
of
show,
specifically
where
we
are
in
this
conversation,
we're
looking
to
do
issue
types.
A
Can
you
all
see
my
screen
perfect?
Thank
you.
So
we're
looking
to
offer
issue
types.
We
already
have
some
issue
types.
A
A
So
we've
kind
of
the
three
of
us
been
collaborating
on
it,
but
the
foreign
question
that
we
were
looking
at
initially
were
features
enhancements,
technical
debt
and
bugs
bugs
we
already
had
an
icon,
for,
though,
I'm
not
sure
exactly
how
we're
using
those
yet
so
that's
another
reason
they
pulled
in
jeremy
feature
enhancement
and
technical
debt,
though,
are
the
ones
that
are
a
little
bit
more
in
question.
So
I
spent
a
lot
of
time
looking
at
how
other
people
are
representing
these
icons
and
these
concepts
and
various
products.
A
And
after
talking
with
mike
nichols
who
was
my
former
ux
buddy,
he
said
that
he
liked
how
slack
did
a
little
gift
to
indicate
a
feature,
and
I
kind
of
liked
that
as
well.
It
felt
like
more
of
a
kind
of
positive
proposal
that
something
new
has
been
created
and
we
did
a
lot
of
research
with
users
in
terms
of
what
the
specific
verbiage
is
that
we're
using
for
these
and
to
them
a
feature
could
be
either
something
new
or
it
could
be
adding
on
to
something
existing.
A
In
other
words,
an
entirely
new
thing
or
adding
on
enhancement,
however,
was
always
obviously
adding
on.
So
I
went
with
a
little
present
for
feature
kind
of
a
bar
chart
showing
an
upward
arrow,
in
addition
to
the
lines
for
enhancement
and
then
technical
debt.
There
was
a
lot
of
a
lot
of
struggle
with
this
one,
and
this
is
the
one
that
we're
stuck
on
the
most.
So
in
this
case
I
went
with
our
little
weight,
icon
and
kind
of
a
little
scale.
A
Tipping
down
where
this
has
gone
is
jeremy
has
proposed,
maybe
some
additional
ways
to
explore.
I
think
this
was
for
feature
feature
he's
proposing
the
star,
an
enhancement,
maybe
a
magic
wand.
I
love
the
magic
wand,
the
star
I
told
him.
I
struggled
with
a
little
bit
because
there
are
so
many
different
ideas.
Already
tied
to
the
icon
of
a
star
in
terms
of
ratings
and
favorites,
and
things
like
that
that
I
kind
of
struggle
with
that
one
and
then
emilia
was
showing
some
screens
from
jira.
A
I
believe,
and
then
I
created
this
one
as
just
I
had
seen,
someone
else
had
done
something
kind
of
similar
for
technical
debt,
and
we
had
some
discussion
surrounding
concerns
with
that
one
and
maybe
for
some
folks
it
might
feel
a
little
a
little
anxious
almost
because
you've
got
this
kind
of
symbol,
so
we
are
still
talking
through
that
amelia
had
suggested,
maybe
something
with
code,
and
this
was
another
idea
that
I
had
had
originally
of
the
code
symbol
kind
of
weighing
something
down,
and
then
these
were
the
last
two.
A
It
looks
like
she
had
proposed
on
friday
just
to
further
explore
that.
But
it's
tricky,
because
technical
debt
isn't
a
positive
thing
and
we
don't
necessarily
want
to
promote
it
as
such.
It's
something
that
you
know
it's
dead.
That's
not
always
a
good
thing.
It's
something
that
we
need
to
clarify
as
being
potentially
problematic.
However,
we
want
to
be
sure
that
we're
doing
it
in
a
way
that
you
know
is
thoughtful,
and
that
makes
sense
to
to
the
majority
of
our
users
and
is
small
and
simple
and
can
be
fit
into.
D
B
B
So
I
added
a
screenshot
of
that,
but
to
me,
because
these
are
usually
used
in
small
spaces
like
probably
staying
16
by
16
pixels,
maybe
24
by
24.
The
largest
simple
just
works
the
best
here,
and
maybe
even
things
that
don't
necessarily
correlate
perfectly
like
a
just.
A
circle
for
a
bug
could
be
totally
fine,
so
maybe
it
doesn't
have.
B
So
it
uses
multiple
formats
to
communicate
something
so
they're
using
a
combination
of
color
and
iconography
to
communicate
something
with
the
ability
to
then
look
into
it
and
find
out
specifically
what
it
is.
But
I
loved
all
the
creative
ideas
that
I
saw.
I
think
some
of
them
maybe
were
just
a
little
too
much
for
something
so
tiny.
You
know
yeah,
which
I
think
is
great.
You
have
jeremy
in
there
and
he'll
definitely
help
you
find
something
way.
More
simple
he's
been
great
about
that.
A
Yeah
he's
very
good
at
it,
and
I
have
a
tendency
to
to
over
complicate
those,
because
I'm
trying
to
think
of
it's
ironic,
because
I'm
trying
to
think
of
the
most
simple
way
to
present
it
and
yet
I'm
over
complicating
it
while
trying
to
simplify
it.
But
that's
again:
it's
not
my
strong
suit,
it's
his
strong
suit.
So
that's
why
I
pulled
him
up,
but
thank
you
for
that
feedback
austin.
That
is
great
feedback
and
to
mike's
point.
I
completely
agree
that
I
don't
want
to
just
show
an
icon.
A
I
want
to
show
some
other
way
to
also
clearly
read
so
we're
not
just
showing
visuals
or
color
to
differentiate
between
the
different
types
of
things,
but
also
showing
a
clear
label
as
well.
So
maybe
we
could
go
even
more
simple
and
small.
Keeping
that
in
mind,
we'll
just
need
to
be
sure
that
we're
also
addressing
the
different
ways
that
we
can
show
a
label
in
addition
to
the
icon
in
the
various
places
in
the
product,
with
the
board
again
being
the
number
one
concern
just
because
it's
already
so
full
of
stuff.
A
C
No
yeah,
I
actually
had
a
more
probably
unrelated
question,
but
is
there
somewhere?
I
can
see
the
definitions
for
each
of
these,
like
what
is
a
technical
debt,
what
is
etc.
I
look
I
clicked
around
and
I
couldn't
really
find
it.
I
don't.
A
Think
it's
in
that
particular
issue,
there's
a
separate
one.
Let
me
see
here
and
I'm
happy
to
put
it
in
the
agenda.
A
I
think
it
is
maybe
in
this
one
I'll
find
it
and
put
it
in
the
agenda,
but
we
do
have
one
yeah.
We
do
have
one
I'll
put
it
in
there
thanks.
C
Thank
you,
of
course,
and
then
maybe
y'all
will
throw
tomatoes
at
me,
but
I'll
say
like
yes,
it's
important
to
pick
an
icon
that
is
initially
kind
of
you
know
indicative
of
what
it
is.
But
I
agree
if
you
put
the
text
next
to
it
and
also
it's
something
that
people
get
used
to
whatever
we
give
them
right.
C
So
it's
important
to
sort
of
like
at
first
glance
and
some
of
them
like
having
text
next
to
it
a
lot
of
times
hover
over
so
that
you
see
like
what's
behind
it
right,
but
I
kind
of
feel
like
people,
it's
something
that's
learnable
right.
So
that's
my
perspective.
D
C
D
Let's
the
inverse
treatment
threw
me
off.
I
had
to
really
squint
to
decipher
it,
yeah,
just
extra
extra
shapes
that
convey
extra,
meaning
that
my
brain
has
to
process,
and
since
I
have
a
really
slow
moving
brain,
I
have
the
advantage
of
being
able
to
observe
it
in
real
time.
So
that
was
my
experience
around
it.
D
D
I
mean
if
you
look
at
the
top
of
the
google
doc
next
to
people's
faces.
Oh.
D
Yeah,
honestly,
that's
not
a
great
icon
choice,
but
my
point
is
the
treatment
it's
easier
just
to
see
the
shapes
when
they're
on
a
positive
background.
Instead
of
inverse.
A
Agree
that
was
actually
something
I
took
from
the
original.
So
let
me
scroll
up
to
the
top.
Originally
amelia
had
created
these
three,
which
we
decided
not
to
move
forward
with
feature
flags
for
now,
so
that
one
can
be
discarded.
But
in
her
research
she
had
an
inverse
option
and
I
honestly
assumed
that
that
was
something
that
we
had,
maybe
in
our
template
to
start
creating
these
kinds
of
icons.
A
But
that's
a
good
point
because
I
agree
with
you.
I
mean
I
find
I
find
the
items
on
the
left
to
be
a
lot
easier
to
kind
of
process
than
the
items
on
the
right
and
it
becomes
more
complex
from
a
design
perspective
because
you
have
to
think
through,
like
what
does
the
inverse
of
this
look
like,
and
does
it
still
make
sense?
I
don't
know
if
there
are
places,
though,
that
we
are
using
one
versus
the
other.
A
A
I
was
wondering
that
too
perhaps
and
that's
I.
C
A
Yep
well,
thank
you
all.
This
has
been
super
helpful
feedback
and
I
think,
there's
value
in
exploring
maybe
some
other
ways
that
we
can
continue
to
simplify
these
and
just
be
sure
to
include
the
labels
in
the
various
places
that
we
show
it
and
I'll
find
that
issue
melissa
and
put
it
in
the
agenda
as
well.
D
A
B
B
C
I
have
a
presentation
with
the
cab,
so
I'm
looking
forward
to
that.
I
haven't
done
one
yet
since
I've
been
here.
B
Oh,
that's
a
good
one.
I
have
a
few
coffee
chats
this
week
that
I'm
looking
forward
to
I'm
gonna
catch
up
with
daniel
and
emily,
who
are
some
of
our
more
recent
product
designers,
detecting
on
how
they're
going.
D
Cool
I'm
looking
forward
to
yeah.
I
know
right
can't
just
ask
and
then
not
participate.
I'm
hoping
I
can
get
a
more
finalish
draft
of
the
competitive
evaluation
guide
that
I
want
to
put
in
the
handbook,
so
I'm
hoping
to
have
that
more
solidified
like
by
tomorrow
or
wednesday.
So
I
can
do
a
handbook
contribution
draft
to
make
it
feel
more
like
real,
rather
than
just
kind
of
a
kitchen
sink
of
ideas.
D
I
got
a
lot
of
feedback
last
week
and
I
need
to
just
dive
in
and
look
for
patterns
there
yeah
great
yep,
but
I
mean
you
can
still.
If
you
have
ideas,
feel
free
to
hop
in
there.
I
don't
have
the
link
handy,
but
it's
in
the
agenda
from
last
week's
ux,
weekly,
okay,.