►
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
A
I
open
an
issue
in
pajamas
to
discuss
extending
the
guidelines
on
labels
because
in
pajamas,
if
we
look
at
the
actual
component
for
a
label,
the
main
differentiation
that
we
make
between
a
label
and
a
badge
is
that
a
user
generates
a
label,
whereas
the
gitlab
system
would
generate
a
badge.
A
So
when
we
were
creating
compliance
frameworks,
we
just
used
a
label
next
to
the
compliance
for
to
illustrate
a
compliance
framework
because
users
were
creating
the
compliance
framework.
So
we
just
copied
the
form
that
we
use
for
the
traditional
labels
that
you
would
see
in
issues
in
epics
and
mrs,
including
the
scoped
label,
attribute.
A
B
A
Yeah,
I'm
kind
of
learning
a
little
bit
more
on
it.
So
I
guess
what
I've
discovered
is
that
scope
labels
were
initially
created
for
labels,
feature
themself
to
create
some
exclusivity,
so
you
can
only
apply
one
scoped
label
to
an
issue
or
an
epic.
At
a
time
I
mean
currently
with
the
compliance
framework,
you
can
only
associate
one
compliance
framework
with
a
project,
but
that
could
change
in
the
future.
Maybe
you'll
be
able
to
associate
multiple
and
what
annabelle's
bringing
up
is
like.
A
That
could
be
confusing
that
you
could
put
on
multiple
scope,
skip
labels
here,
and
I
guess
part
of
my
like
tension
is:
do
we
just
tie
ui
elements
to
functionality
in
gitlab?
It
seems
too
specific
to
me,
like
I
don't
see
what
necessarily
is
wrong
with
just
using
a
label
to
add
flair
to
your
project.
A
C
You're
talking,
I
think
daniel
has
the
first.
Oh,
I
didn't
see
daniel
join
cool
yeah.
He
has
the
first
response
in
that
agenda.
A
B
C
Now,
let's,
let's
try
to
document
our
responses
in
the
agenda,
we
don't
have
to
take
totally
thorough
notes,
but
that
way,
when
somebody
wants
to
see
what
you
know
what
happened
in
the
meeting,
we
have
some
documentation
about
it.
Even
though
we've
got
a
recording
yeah.
A
Multiverbalize
also,
if
you
have
an
opinion
on
the
matter,
I'd
love
any
input
on
the
actual
issue
itself.
D
So
one
question
I
have
for
you
is:
what
was
the
particular
topic
or
use
case
that
you
want.
You
wanted
to
specifically
use
these
types
of
things.
What
what
was
the
thing
that
spurred
this,
this
pajamas
issue.
A
Compliance
frameworks
are
using
the
label
component
currently
and
we're
we
reuse
the
same
form
so
to
try
to
do
a
boring
thing.
We
reuse,
the
labels
component
itself
came
with
regular
labels
and
scoped
labels,
and
now
that's
kind
of
created
some
confusion
around.
Why
are
scope
labels
appearing
somewhere
else
in
the
product
that
isn't
on
issues?
Epics
merge
requests
primarily
project
planning?
A
This
might
be
the
first
time
we've
tried
to
extend
the
label
component
elsewhere.
So
I
could
see
this
coming
up
again
with
things
like
topics
which
are
another
user
generated
like
categorization
item.
But
currently
you
don't
get
any
customization.
You
can't
make
the
tag
that
goes
next
to
your
project,
a
different
color
or
change
the
flare
on
it
at
all.
So
I
guess
my
question
is
like
what's
wrong
with
using
it
for
visualization
player,
does
it
have
to
be
tied
to
a
functionality
which
has
meant
for
project
management
exclusivity?
A
E
Okay,
let's
try
this
just
to
catch
up,
so
I
think
what
I
was
saying
is
that
previously
the
labels
when
I
was
looking
at
them
even
before
compliance,
I
was
trying
to
get
an
understanding
of
how
to
use
them,
and
I
I
think,
just
from
what
I
was
looking
at,
that
the
way
that
they're
implemented
is
tied
to
only
the
specific
objects
of
issues
and
epics.
E
But
if
like
what
you're
describing
is
detaching
them
or
having
them
not
associated
to
a
specific
object,
I
think
would
make
more
sense
because
they
give
more
usability.
But
I
understand
that
the
problem
that
annabelle
was
bringing
up.
My
argument
was
that
I
don't
understand
the
the
confusion
or
the
aspect
of
the
confusion
if
we
designate
them
for
the
mirror
phrase
that
if
organizations
designate
you
labels
per
their
own
organization
right.
E
So
in
our
case,
perhaps
we
can
define
rules
and
say
you
can
only
use
labels
for
these
parameters
or
whatnot
and
other
people
can
define
their
own
rules.
So
that
would
allow
the
flexibility
as
you
would
want,
but
also
confusion
would
be
tied
to
whatever
the
organization
has
defined
it
as
we're
kind
of
artificially
imparting
structure.
That's
not
necessarily
needed
so
to
speak.
A
From
my
perspective,
I
thought
this
was
an
okay
component
to
use
because
it
was
in
our
component
options.
So
when
we
initially
released
compliance
frameworks,
they
were
these
general
ones
that
you
could
assign
to
a
project
and
they
would
get
a
randomly
assigned
color
and
label,
and
so,
as
we
wanted
to
extend
the
functionality
of
compliance
frameworks,
we
thought
oh
well
might
as
well.
Just
include
the
scope
label
set
and
allow
users
to
customize
it.
However,
they
want
to
why.
Why
should
we
restrict
them.
D
Me
neither
I
agree
with
you.
I
think
labels
are
a
one
of
us,
the
smallest
primitives,
that
we
have
and
to
confine
it
to
a
particular
part
of
the
product,
especially
when
that
particular
part
of
the
product
might
not
be
used
by
every
every
other
sort
of
type
of
persona
who's.
Also
using
it.
We
should
be
working
with
the
system
that
that
gives
us
much
sort
of
no,
I
suppose
what
I'm
saying
is.
D
I
agree
with
you.
I
think
it's
worth
it's
worthwhile
sort
of
bringing
this
up,
and
I
think
it's
worthwhile
sort
of
taking
the
learnings
from
the
discussions
and
arguments
that
we're
having
here
in
order
to
like
basically
apply
it
to
the
philosophy
of
the
the
broader
design
system,
because
yeah,
just
reducing
labels
to
purely
product
management
activities
is
probably
not.
E
A
E
Just
to
kind
of
expand,
I
guess
is
like
I
think
this
is
probably
a
fair
opportunity
just
to
throw
out
a
research
proposal.
Saying
hey,
what's
the
expectations
or
what's
the
user
requests
from
a
user
level
saying
like
if
we
could
expand
the
feature
or
take
apart
the
limitations,
would
you
prefer
that
or
does
it
not
help
you
so
to
speak.
A
Yeah,
that's
fair
and
I
think
at
the
very
minimum
right
now.
I
need
to
at
least
make
sure
in
the
documentation
that
there's
a
separate
descriptor
for
what
happens
with
a
compliance
framework
right
now,
it's
linking
to
a
scope
label
set
from
project
management.
That's
no
good!
It's
definitely
not
clear,
but
yeah
I
mean
I
guess
I
guess
a
research
effort
could
help
us
with
user
expectations.
Although
I
guess
one
part
of
me
feels
skeptical
that
we'll
get
the
insights,
we're
looking.
B
A
B
Yeah
thanks
nick,
I
think
overall,
I
agree
with
sort
of
the
sentiment
of
what
you're
describing
austin,
that
a
component
should
be
tied
to
the
problem.
It's
solving
right,
not
to
a
specific
part
of
the
system
or
an
object
right
and
in
the
case
of
labels,
it's
sort
of
a
solution
for
metadata
associated
to
an
object.
That's
more
free
form
right.
B
That
was
the
original
intent
of
what
it
was
built
for
issues
right
because
of
custom
fields,
but
really
that
concept
can
apply
to
anything
in
git
lab
right,
and
I
think
it's
a
natural
sort
of
like
next
step
that
it
will
be
added
to
more
and
more
things
right,
as
it's
needed
to
have
more
of
this,
like
rich
data
that
you
can
now
slice
and
dice
by.
B
A
A
A
A
A
All
right,
yeah,
I
see,
I
see
your
question
alexis
about
they're,
currently
being
used
just
for
visual
flair,
all
right.
So
when
we
initially
launched
compliance
frameworks,
if
you
assigned
anyone
to
your
project,
it
would
just
give
you
a
badge
or
a
label
or
whatever
you
want
to
call
the
ui
component.
I
think
technically,
in
this
case
it
should
be
called
a
label
because
it's
well,
I
guess,
in
this
case,
there's
a
badge
as
we
grew
the
feature
and
made
it
so
that
users
could
define
what
these
compliance
frameworks
are
called.
A
A
A
A
F
F
F
Compliance
frameworks
or
something
like
that
or
like
group
them,
then
I
think
label
would
make
sense,
probably,
but
I
would
see
scoped
people
making
sense
unless
you're
for
some
reason
saying
like
I
want
to
use
this
compliance
framework
until
a
certain
something
happens,
and
then
it's
automatically
going
to
switch
to
a
different
compliance
framework.
I
wouldn't
I
wouldn't
understand
why
that
would
happen.
I
don't
know,
but.
F
A
Yeah
I
mean,
I
guess
it
technically
could
be.
I
think,
where
I've
like
kind
of
been
confused,
why
it
has
to
be
limited
to
a
workflow,
is
like
let's
say
I
wanted
to
create
a
compliance
framework
for
socks
in
an
environment
like
aws.
A
I
wanted
to
do
this,
but
didn't
understand
why
things
were
not
letting
me
do
it.
I
didn't
understand
why
gitlab
people
were
putting
colons
in
their
labels,
I'm
like.
Why
are
you
doing
this?
This
is
super
weird.
Just
let
me
like
put
a
scope
label
here
and
then
I
came
to
learn
that
that's
a
premium
feature
and
that's
why
it
wasn't
working
for
me.
F
That's
that's
like
when
I
joined
gitlab
I
was
like
and
then
I
think
that
we're
going
to
be
called
like
family
labels
or
something-
and
that
was
my
first
thing
and
I
was
like
I
don't
know
what
that
means.
So
what
I'm
kind
of
hearing
I
don't
know
correct
me
if
you're
wrong
or
if
I'm
wrong,
like
maybe
we
can
have
different,
like
variations
of
badges
and
think
about,
like
user
generated
badges,
how
those
might
like
look,
how
to
make
them
easier
to
read.
F
You
know
like
differentiate
different
parts
of
the
way
that
they're
used
to
labeling
them.
Can
we
have
that
kind
of
scope,
styling
for
something
other
than
scoped
and
then
maybe
scope?
Those
need
to
be.
You
know,
like
the
design
of
them
needs
to
be
different,
like
we
could
iterate
on
that
right
and
then
somehow
the
scoped
styling
could
be
extended
to
badges
or
places.
A
A
So
that's
why
I
guess
I
was
surprised
to
find
out
that
there
was
an
opinion
that
it
should
be
only
for
like
project
management
purposes.
If
that's
the
case,
and
we
should
just
document
it
and
then
extend
badges
to
figure
out
how
to
accommodate
when
other
people
would
want
to
do
something
like
that.
But
but.
E
That's
that's
sort
of
what
the
I
guess.
The
question
is
right
is
that
what's
the
difference
between
badges
or
labels
or
scoped
labels
right,
it's
they're
all
categorization
organization
systems.
So
again,
going
back
to
what
I
was
saying
is
that
maybe
we
should
ask,
is
there
a
better
way
of
doing
all
of
this,
and
not
just
say,
oh,
we'll
make
a
different
version
of
the
same
thing.
A
Totally
and
I've
I've
brought
this
up
in
the
foundations
meeting
their
office
hours
and
I've
talked
with
jerick
and
jeremy
from
time
to
time.
Just
about
show
us
a
label
here.
Should
I
use
a
badge
and
generally,
they
would
tell
me
we're
using
a
label
if
the
user
created
it
we're
using
a
badge
if
the
system
created
it.
A
A
D
I
have
a
proposal
yeah
how
about
we
in
we
think
about
potentially
integrating
badges
tags
and
and
labels
into
one
component.
D
We
can
document
their
different
use
cases,
but
those
different
use
cases
could
be
documented
through
our
object
within
our
like
our
la
or
how
we,
how
we
describe
objects
within
within
git
lab
within
our
design
system.
So,
right
now
in
our
in
pajamas,
I
can
share
my.
I
can
share
my
screen
if
you
like,
that
makes
it
easier
sure,
but.
D
I'll
share
my
screen:
okay,
so
we
have
labels
when
I'm
looking
at
labels
here,
I'm
reading
this
content-
and
it
really
seems
to
me
to
be
describing
the
particular
interaction
of
the
feature,
rather
than
particular
ways
that
this
this
component
is
actually
being
used.
And
if
you
look
at
label
versus
badge
look
very
similar.
D
I
mean
why,
wouldn't
these
just
be
different
variants,
and
then
we
have
this
section
within
within
our
design
system
now,
which
is
starting
to
talk
a
little
bit
more
about
objects
and
how
objects
should
should
interact
and
and
all
that
sort
of
stuff.
So
to
me
it
seems
like
we
could
potentially
disambiguate.
D
We
could
integrate
those
three
components
together:
badges
tags
and
labels,
and
then
we
can
disambiguate
the
information
which
is
talking
about
how
badges
how
labels
should
work
within
a
within
like
the
project
management,
context
and
document
it
in.
In
sort
of
this.
This
object
section
sort
of
talking
about
what
the
interaction
should
be.
Maybe
that's
a
way
of
going
about
like
how
we
divvy
up
this
information.
B
Yeah,
I
agree
nick
to
jump
in
here
as
someone
who's,
not
in
the
weeds
of
our
ui
components.
All
the
time
right,
I
just
realized
there
are
completely
different
things
in
the
back
end
and
I'm
learning
a
lot
in
this
call
about
the
nuances
of
each
and
basically
how
they're
different.
So
I
expect
our
end.
Users
probably
don't
understand
that
either
and
they
are
surprised
by
some
of
the
differences
right.
A
Yeah
fair
point:
I
I
think
I've
maybe
run
this
point
to
the
ground,
though
so
I
don't
know
if
any
more
discussions
necessarily
productive
here,
although
I
really
love
like.
A
C
Like
it,
if
alexis
could
vocalize
what
she's
feverishly
typing.
F
Yeah
I,
like
my
brain,
is
working
better
when
I
type
today,
because
I
see
more
coffee,
I
think
yeah.
I
was
just
saying
I
like
that
idea.
I
think
scoped
labels
as
they're
called
today
would
be
only
maybe
just
in
my
gut,
I'm
feeling
that
might
be
a
little
bit
different
or
a
little
weird
to
lump
in
with
everything
else,
just
because
it's
like
about
automating
workflows,
but
maybe
we
call
it
something
different
than
a
label,
maybe
it's
just
maybe
it
could
be
a
different
variant.
F
I
just
think
we'd
do
maybe
a
little
bit
more
research
there,
otherwise
yeah.
I
think
that's
a
cool
idea
and
like
how
could
we
just
kind
of
scope,
everything
back
and
just
have
like
one
little
object
and
kind
of
get
feedback
on
that
like
what
happens
if
badges
and
labels
are
the
same,
what
would
that
look
like
so
yeah?
Thank
you
mike
you
like
my
morning,
puns
anyway,
thanks
for
bringing
it
up
austin.
This
is
a
it's
a
fun
rat's
mess.
I
think.
A
A
Labels
like
they
solve
a
problem
for
a
workflow
and
project
management,
and
so
I
hadn't
really
thought
about
keeping
that
feature
just
to
that
area
in
terms
of
just
using
a
ui
component,
because
when
I
look
at
the
gitlab
ui
like
interface
itself,
if
I
was
building
a
website,
I
would
probably
use
the
scope
label
for
some
other
reason.
A
F
I'm
glad
you
talked
with
annabelle
too,
because
she
basically
designed
that,
like
I
said
my
first
one
of
my
first
projects
here
and
she
was
working
on
that
and
doing
a
great
job,
so
she'd
have
a
lot
of
history
there
but
yeah.
I
know
you
know
in
doing
the
jobs
to
be
done.
Research
and
just
in
general,
that's
like
one
of
the
biggest
pain
points
is
keeping
things
updated
right
like
as
you're
working
and
as
things
move
through
workflows
and
that's
the
intention
of
scoped
labels,
so
we'll
see
yeah
excited
for
this
yes
makes.
A
Before
that,
in
some
form
or
fashion,
I
think.
A
D
C
Variety
of
in
our
product
is
the
noun
tag
used
anyway,.
A
Yes,
this.
C
Releases
of
course,
I
knew
that
yeah
we're
kind
of
out
of
nouns
aren't
we
that's
why
I
brought
up
tags
because
it
would
be
nice
if
we
could
use
that.
But,
of
course
the
tag
are
released.
A
C
A
A
We
could
definitely
remove
it
from
the
form
without
the
functionality
itself,
not
a
problem,
it's
purely
being
used
just
to
help
make
it
more
identifiable.
I've
asked
a
few
people.
Why
are
you
putting
this
on
your
project
because
it
didn't
have
any
functionality
before
it's
like?
Oh
because
I
just
do
gdpr
in
this
project,
and
it
just
helps
visually
make
it
distinct
from
all
my
other
ones.
A
So
today,
like
it's
purely
being
used
for
visual
flair,
and
I
haven't
necessarily
discovered
a
need
for
a
specific
scoped
version,
although
we
know
that
there
is
a
differentiate,
their
aws
from
their
google
cloud
platform
and
their
different
compliance
frameworks,.
A
C
Mute
he's
got
it,
I
think
somebody
probably
told
him
all
right.
So
if
we
roll
back
how
we
got
here,
the
annabelle
who
designed
scope
labels
saw
that
you
were
using
scope,
labels
in
compliance
and
was
concerned
that
people
might
be
confused,
because
that's
a
workflow
thing
and
now
we're
using
it
for
visual
flair.
And
this
other
thing
is
that
the
only
the
only
concern
we've
had
about
this
problem
not
to
diminish
annabelle's
perspective
at
all.
But
I
just
want
to
know
if,
like.
C
So
that
I
think
that's
maybe
an
interesting
step
would
be
to
validate
that
it's
a
problem
with
with
people.
I
don't
know
what
you
call
it:
teams
that
are
comprised
of
pms
and
compliance
people
and
if
pms,
are
stumbling
across
this
object
and
going.
C
A
I'll
also
say
that
you
can't
we
aren't
going
to
run
into
license
issues
either
because
to
get
compliance
frameworks,
you
have
to
be
at
least
premium
and
premium
spare
scope
labels.
So
that's
not
an
issue
for
now.
At
least
I
thought
about
that.
Randomly
okay,
at
least
that's,
not
something.
That's
going
to
be
a
problem
here
like
we're
not
giving
scope
labels
to
someone,
that's
on
free
or
something
so.