►
From YouTube: Plan Team Weekly 2020-10-14
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
welcome
all
planned
stage.
Weekly
october
14th
looks
like
gabe,
you
have
the
first
topic.
B
B
There's
at
least
I
know
within
project
management
and
there's
a
pretty
clear
patterns
that
are
emerging
in
terms
of
like
things
that
are
important,
that
we
need
to
focus
on
right
now,
we
kind
of
have
it
spread
across
many
different
epics
and
kind
of
dumped
into
a
spreadsheet,
just
the
titles
to
like
talk
about
them,
but
I
think,
like
the
way
that
we
go
about
building
these
like
there's
overlap
with
each
other,
and
I
don't
know
it's
just
how
what's
the
best
way
that
we
can
get
engineering
involved
in
like
making
decisions
and
influ
and
helping
influence
the
road
map
and
prioritization
trade-offs
like
earlier
on.
B
B
That
sort
of
thing
you
know-
and
I
was
curious-
what's
the
best
way,
we
can
start
doing
that
because
I
think
it
would
help
everyone
in
the
stage
kind
of
understand
where
we're
going
and
be
able
to
influence
architecture
and
also
proc
decisions
in
a
way
that,
like
makes
sense
from
an
engineering
standpoint
and
usually
I've
found
when
the
earlier
on,
we
engage
engineering
and
being
involved
in
proc
decisions.
The
better
the
outcomes
are
across
the
board.
A
Yeah,
I
think
those
are
all
good
ideas
that
we
could
possibly
do
I'd
love
to
have
a
section
of
our
of
this
meeting,
dedicated
to
like
not
really
long
term
but
longer
than
the
next
iteration
or
milestone,
look
ahead
into
larger
features
so
yeah.
Maybe
we
dedicate
every
week
to
talking
through
one
new
largest
feature.
A
I
also
commented
that
I'd
love
to
see
these
or
I'd
love
to
see
us
dog
fooding
our
roadmap,
a
little
bit
more
within
our
stage.
A
So
if
we
can
include
these
epics
or
get
a
view
of
these
epics
within
our
roadmap,
I
think
that'd
be
awesome.
You
asked
well
you
want
to
ask
your
question:
hello,
yeah,.
B
This
is
like
a
good
point
for
dog
fooding,
in
that,
when
I
I
found
that
I
could
build
out
an
epic,
but
it
or
it's
very
rarely
accurate
unless
I
manually
set
the
date
for
something
that's
far
ahead,
and
so
should
we
just
like
sort
of
do
that
and
then
take
a
first
dab
at
staging
like
big
features,
and
then
that
could
be
like
a
good
conversation
point
being
like
hey,
you
know
here's
this.
B
Does
it
make
sense
to
do
this
before
this,
and
do
you
think
it
high
level
will
take
two
months
or
like
six
months
or
that
sort
of
thing
and
it's
not
holding?
I
guess
it
at
some
point:
we'll
have
to
switch
back
to
doing
inherited
dates
if
we
want
an
accurate
roadmap,
but
that's
like
the
weird
thing
I
found.
A
Yeah,
I
think,
for
now
we
set
big
states.
Maybe
we
do
like
I
don't
know.
Maybe
we
try
to
plan
like
by
the
quarter
and
just
have
really
loose
like
quarter
dates
within
the
epics
just
so
we
have
like
an
even
higher
level
prioritization
list.
That
makes
sense.
C
Yeah
I
mean
like
technically,
though,
to
try
and
find
the
technically
like
path
of
least
resistance
to
each
of
these
features,
though
right
like
so
like,
for
example,
should
we
do
like
custom
fields
and
issues
like
implement
that
before
we
start
adding
our
own
fields,
because
technically
it
would
be
easier
for
us
to
extend
something
that
we've
already
extended
right?
That's
kind
of
a
bad
example,
but
that's
the
point
here
right:
it's
not
so
much
that
that
these
things
are
the
most
in
demand
at
this
exact
moment.
But
it's
that's.
C
The
purpose
right
is
to
try
and
identify
which
makes
sense
from
a
technical
perspective,
to
do
first.
B
Yeah,
that's
one
of
the
reasons
yes
and
like
a
good.
A
good
example
is
one
of
our
little
customers
is
wants
to
move
away
from
jira
self-managed,
and
so
I've
done
a
gap.
Analysis
with
them,
and
I
know
a
list
of
you
know
five,
five
big
things
that
we
need
to
get
done,
but
we
can
get
them
done
in
any
order
and
we,
but
we
need
to
get
them
done
by
like
next
summer
or
a
late
spring
right.
So,
given
this
bucket
of
things
that
we
know,
we
need
to
do.
B
B
C
Yeah,
even
even
from
the
another
perspective
would
be
like
take,
for
example,
service
desk
to
core.
It
makes
a
lot
of
sense
to
do
that
sooner
rather
than
later,
because
it
encourages
wider
community
involvement.
So
we
can
have
the
wider
community
kind
of
burn
in
dying
issues
that
they're
really
interested
in
seeing
in
service
desks,
so
that
by
the
time
we
actually
get
to
solve
the
problem
that
we've
prioritized
for
one
or
more
customers
like
a
lot
of
the
a
lot
of
the
technical
path
has
already
walked.
C
B
Cool,
I
think
the
next
logical
step
mark
and
I
will
and
mark
I'm
volunteering
you
too,
because
you
know
we'll
work
out
on
building
out
the
road
map
with
epics
and
then
maybe
like.
We
can
review
that
next
week
or
two.
B
Yeah,
I
think,
okay,
we're
gonna,
have
amazing
too
for
sure,
but,
like
I
think,
that's
where,
like
sometimes
it's
hard
to
have
efficient
async
conversations
about
theoretical
things
that
are
vague
and
opaque.
So
I
agree.
A
Oh
well,
I
think
you're
next
cool
demo
time,
so
I'm
gonna
demo
for
scott
because
he's
out
this
week
there's
an
issue
around
improving
the
some
parts
of
the
ux
for
drop-down
selections.
Holly
can
probably
speak
to
this
a
little
or
much
better
than
I
can,
but
essentially
one
of
the
feedback
we
were
receiving
from
users
was
that,
on
after
a
user
clicks
edit
on
a
drop
down
for,
say
assignees,
they
select
different
users.
A
There's
no,
like
the
button,
still
says
edit.
There's
no
essentially
call
to
action
to
actually
save
the
save
your
assignees.
A
So
the
first
iteration
proposal
for
this
share
was
to
just
change
that
the
edit
button
to
to
say
apply,
and
it's
not
required
for
a
user
to
click
on
that.
But
it's
just
a
helpful
helpful
again
call
to
action
to
to
actually
save
what
they've
changed.
So
hang
on
one.
Second,
let
me
refresh.
A
A
And
this
was
just
merchant
today,
so
it
should
be
on.com
later
on
today
or
tomorrow,
but
we
have
assignees
here,
I'm
going
to
click
edit,
I'm
going
to
add
an
assignee,
and
you
see
how
it's
updated
to
apply
here.
A
D
D
I
think
it's
a
simple
way
that
will
hopefully
add
a
little
clarity
and
to
your
point,
donald
we're
not
changing
any
existing
functionality.
Necessarily,
they
can
still
click
away
and
it
saves
it,
but
it
gives
a
little
bit
more
clarity
to
the
user
as
to
how
to
manage
that
control.
So
I'm
excited
great
job.
E
Yeah,
so
we
recently
added
support
for
descriptions
and
requirements
earlier
we
were
only
allowed
to
have
a
title
for
a
requirement,
but
now
we
can
basically
have
descriptions
just
like
issues,
epics
and
all
the
other
places.
So
when
you
click
on
new
requirement,
you
will
now
see
both
the
title
and
the
description
field
and
yeah.
So,
let's,
let's
create
one
with
the
description.
E
Created
and
so
now
we
have
two
points
of
interactions
within
the
list
earlier.
These
individual
items
were
not
clickable,
they
were
not
interactive.
You
could
either
edit
a
requirement
or
an
archive
requirement,
but
now
the
entire
requirement
itself
is
clickable.
So
if
you
click
on
requirement,
you'll
see
that
it
has
the
title
and
description
rendered
and
there
is
an
edit
button.
Next
to
it,
it
is
similar
to
how
issues
work
today,
where
clicking
on
edit
would
make
the.
E
With
the
description
and
title
in
place,
and
then
you
can
see
all
the
changes
and
it
gets
updated
in
place
and
closing
this
will
basically
close
the
drawer
edit
action
is
still
in
place.
So
if
you
want
to
edit
it
right
away
without
having
to
first
view
it,
then
you
can
just
click
on
edit
and
it
will
open
the.
E
So
yeah
and
clicking
on
cancel
will
show
that
how
it
looks
while
in
view
mode
and
you
can
close
the
drawer
and
it
goes
away
so
yeah.
That
was
the
change
here.
F
This
looks
great
crucial,
just
a
minor
question:
we
don't
support
linking
requirements,
yet
I
mean
you
can
link
other
resources
from
a
requirement
description,
but
you
cannot
link
requirements
from
other
resources,
but
do
we
plan
show
show
url
specific
url
once
we
support
linking
the
requirements
we
will
need,
we
will
need
to
specific
link,
not
in
the
not
linking
the
index
page
as
we
do
now.
F
E
Not
a
permalink
in
place
for
individual
requirements
and
that's
a.
E
Up
with
the
drawer,
expanded
by
default
or
have
a
dedicated
page
for
individual
requirements,
but
that
is
more
of
a
ux
conversation.
Although
right
now
the
markdown
field
that
we
have
for
adding
the
description
doesn't
support
any
kind
of
autocomplete,
for
the
specific
reason
that
we
do
not
allow
referencing
any
external
entity
into
the
requirement
description.
E
But
if
the
backend
does
support
creating
a
prettier
links
like
if,
if
I
can
copy
a
link
to
an
existing
issue
and
put
it
in
the
description
and
if
backhand
can
handle
it,
then
the
markdown
field
will
render
it
as
you
would
expect,
but
yeah
right
now.
There
is
no
way
to
have
a
permalink
for
individual
requirements.
B
B
I
think
they
actually
call
their
test
cases
the
long-running
requirements,
and
so
in
our
in
gitlab,
it's
a
little
bit
different,
but
I'm
just
curious
about
the
vision
for
linking
those
things
together
and
having
like
the
kind
of
pulling
in
metadata
from
each
other.
Basically,.
G
G
We
want
to
build
a
link
from
an
mr
that
adds
to
code
or
changes
code
and
be
able
to
link
to
a
requirement
and
then
add
the
ability
to
say
this
is
implemented
or
not
implemented,
and
then
the
third
step
in
that
is
to
be
able
to
link
your
test
cases
in
the
same
way.
So
when
you
check
into
test
cases,
when
you
link
your
test
cases,
we
want
to
have
the
ability
to
have
requirements,
point
down
to
test
cases
and
test
cases,
point
up
to
requirements
and
have
that
bi-directional
linking
established.
G
So
if
you're
coming
from
the
requirement
view,
you
could
then
say:
oh
what
tests
test
this
requirement
and
see
those
tests
linked
or
everybody's
first
that
we
want
to
say
okay,
this
test
case,
what
requirements
does
it
cover,
so
we're
still
working
through
the
mechanism
of
that?
I
think
that
the
shorter
putt
for
us
right
now
is
to
link
the
implemented
not
implemented
aspect
by
linking
through
mrs
implement.
You
know
change
code
and
that's
why
that's
first
and
that's
actually,
where
a
lot
of
people
have
asked
for.
G
Currently,
that's
because
most
of
the
standards
don't
require
you
to
trace
from
your
test
cases
and
your
requirements
together.
They
expect
all
of
your
test
cases
to
cover
all
of
your
requirements,
so
most
companies
can
get
around
that
if
they
don't
have
that
functionality,
what
they
can't
get
around
is
not
having
the
functionality
linked
to
where
it's
implemented.
G
B
Yeah,
would
it
make
sense?
I
guess
like
one
of
the
things
I
think
we
got
feedback
on
is
there's
not
a
way
to
link
requirements
to
issues
and
if
issues
are
sort
of
the
thing
that
you
plan
to
when
you
plan
to
implement
a
requirement,
we
also
need
to
add
a
better.
I
guess
more
official
link
between
merge
requests
and
issues
because
yeah
for
various
reasons,
because
we
eventually
want
to
refer
the
infer
the
release,
tag
of
a
specific,
mr
and
attribute
that
to
the
issue
and
all
this
other
stuff.
B
B
G
G
The
difficulty
with
that
is
to
your
point.
Mrs
issues
still
have
a
loose
linking
which
causes
issues
from
a
certification
side
and
a
lot
of
people
want
to
link
to
issues
not
requirements.
G
Question
as
well
is
how
people
are
using
things
and
that's
where
this
gets
a
little
bit
tricky,
but
I'm
very
open
to
collaborating
on
that,
because
I
agree
if
there's
a
fast
path
there,
let's
see.
If
we
can
get
something
out
minimally,
it
will
allow
users
to
experience
it
and
then
get
further
feedback.
C
Okay,
the
next
one.
This
is
just
a
quick
reminder
that
product
shadowing
is
available
for
all
engineers
who
would
like
to
understand
more
about
the
pm
role
or
would
like
to
know
more
about
our
customers.
Their
needs,
how
they
use
the
products
different,
agile,
styles,.
C
C
The
first
successful
pilot
was
between
charlie
and
keenan
in
july,
and
they
actually
followed
up
with
some
guidance
in
the
handbook
which
I've
linked.
It's
really
easy
to
set
up.
You
just
create
an
issue
we're
using
the
template,
and
once
you
find
a
pm
that
would
have
the
time
for
you
to
to
shadow
you
put
put
an
mrn
for
the
team
page
and
there's
a
short
survey
at
the
end,
and
that's
about
it.
C
B
Well,
I
think
I
have
the
next
one
there's
more
and
more
teams
and
community
members,
even
that
want
to
add
things
to
issues
like
things
in
the
sidebar.
An
example
would
be
real
release.
B
Management
wants
to
add
the
ability
to
associate
an
issue
directly
to
a
release,
tag
there's
also
another
proposal
out
there
for
adding
a
button
to
the
sidebar
that
lets
you
create
a
cve
id
or
request
a
cvd,
cve
id
be
created
and
a
lot
of
other
things
and
like
it's
all
kind
of
getting
stuffed
into
the
sidebar
or
proposed
to
be
stuffed
in
the
sidebar,
and
I
think
we've
talked
a
little
bit
about
extensible
issues
and
the
idea
of
like
eventually
moving
towards
like
if
we
have
issue
types
and
if
we
have
like
custom
field
type
things
we
allowing
the
end
user
to
eventually
be
able
to
have
some
control
over
what
fields
are
on
what
kinds
of
issues-
and
I
think
we
kind
of
talked
a
little
bit
about
converting
some
of
the
stuff
in
the
sidebar
into
kind
of
standalone,
widgets
or,
and
a
good
example
would
be
like
mrs-
have
reviewers
right
now.
B
But
we
want
that
on
issues
too,
but
it's
tied
to
the
merge
request
model
I
think,
instead
of
to
like
the
issuable
model,
so
we
would
have
to
refactor
that
out
into
the
issuable
model,
so
we
didn't
duplicate
anyway
for
the
greenfield
stuff,
it
seems
like
it
would
make
sense
to
help
folks
or
give
folks
direction
on
how
to
implement
like
issuable
widgets
instead
of
issue
specific
things,
because
I
think
that's
in
line
with
our
longer
term
goals-
and
I
was
curious-
I
I
randomly
ping
engineers
and
oftentimes
jake
to
help
out
with
that.
B
G
Yeah,
I
can
just
verbalize
it
right
there
I
talked.
I
started
working
on
this
or
trying
to
like
put
together
some
talks,
and
I
realized
that
you
know
it
just
got
away
from
me.
John
pointed
out
that
the
info
team
has
this
library
that's
kind
of
linked
from
their
handbook
page
that
sort
of
just
details
like
the
decisions
they
made
or
or
how
they
approach
certain
problems
and
they've
got.
You
know
a
couple
dozen
of
them
in
there
which,
given
the
breadth
of
what
we
work
on
in
plan,
it
seems
like
having.
G
That
would
be
great
now
the
path
to
like
from
today
of
not
having
that
to
having
a
fully
fledged
set
of
like
docs.
That
provide
guidance
is
unclear,
but
I
definitely
think
having
some
sort
of
like
reference
material
that
you
know
doesn't
mean
that
every
time
somebody
needs
to
work
on
issues
or
somebody
needs
to
work
on
anything
within
plan.
You
know
they
have
to
have
like
a
a
an
engineer
from
plan
or
or
something
like
working
through
it
with
them.
They
could
just
kind
of
reference.
G
A
Yeah,
I
also
agree
that
it's
a
good
idea
to
have
the
some
tech
technical
implementation
details
documented
somewhere.
I
think
that
was
the
original
plan
with
extensible
issues
and
there's
a
lot
of
there
are
a
lot
of
technical
details
within
that
issue.
I
think
a
lot
of
it
is
just
taking
some
of
that
and
johnning
it
down
in
our
handbook
or
transferring
it
to
our
handbook
so
jake
we
should
probably
go
through
and
see
if
we
can
or
dedicate
some
time
to
transferring
some
of
that
over.
A
C
Yeah,
I'm
just
I'm
a
bit
out
of
the
loop
on
extensible
issues,
but
I'm
wondering
has
any
part
of
the
issue
been
sort
of
widgetized
in
a
way
that
we
would
provide
as
an
example
for
for
people
to
copy.
I
know,
for
example,
we
looked
at
labels,
but
labels
are
particularly
tricky
like
because
of
the
way
they're
applied
in
two
different
three
different
ways
through
the
api,
and
then
you
also
have
enterprise
edition
code
mixed
in
for
scoped
labels
and
so
on.
B
I
think
the
health
team
did
a
severity
widget,
so
they
behind,
like
we
have
issue
types
now:
a
column
and
the
issues
model
or
whatever
and
there's
now
an
incident
type
and
they
created
a
severity
widget
and
I
think
at
first
they
created
the
datum,
a
separate
incident
data
model,
something
along
those
lines
to
store
all
this
severity
info.
B
But,
like
there's
other
issue
types
that
we'll
want
to
use
severity
on,
like
example,
if
we
have
a
bug
type
right,
you
might
want
to
have
a
severity
on
that,
because
that's
what
we
do
now
gitlab.
So
I'm
not
sure
how
far
they
got
in
reverting
that
back
to
like
the
ideal
shape
or
implementation
path.
But
that's
where
I
think
like
they.
We
didn't
give
them
a
lot
of
good
guidance
and
they
were
the
first
they're
kind
of
blazing
the
trail
here.
B
So
this
is
bound
to
happen,
but
I
think
it's
at
the
point
now
where
like,
for
example,
releases,
they
haven't
started
any
of
the
work
yet,
and
I
I
told
them.
If
you
build
this,
please
build
it
as
an
issuable,
widget
first
and
then
they're
like
what
does
that
mean
right?
B
So
I
think
we
should
look
at
how
they
how
the
severity
widget
was
implemented
and
then
sort
of
like
tweak
that
to
match
an
ideal
and
use
that
as
like
a
starting
point,
because
it's
just
a
simple
drop
down
with
options
in
it
right.
So
it's
not
super
complex.
I
think
there
will
be
more
complex.
Widgets,
like
relationships
is
one
that
is
on
the
roadmap,
but
you
know
we
can
start
with
simple
examples.
C
So
like
this
is
for
the
incident
issue
type
right,
so
you
can
only
use
severity
if
you've
set
the
issue
type
to
be
incident
is
that
right.
B
Right
now
yeah,
but
that
that's
sort
of
like
I
think
it
was
implemented
that
way,
but
we
really
want
it
to
be
like
let's
say
I
wanted
to
add
severity
to
issues
tomorrow,
just
standard
issues.
I
should
be
able
to
do
that
with
without
duplicating
a
bunch
of
stuff
that
is
specific
to
incidents
right.
It's
almost
like
the
goal
is
to
make
it
so
that
some
of
the
the
widgets
store
their
own
data
and
then
can
be
easily
dropped
into
any
issuable
right,
like
a
good
example,
is
merge.
B
Requests
don't
have
linked
for
formal,
linked
issues
or
linkedin,
mrs
or
any
of
that
stuff
and
that's
sort
of
a
relationship
there.
B
You
can't
do
block
by
or
any
of
that
stuff
they
have
a
different
ui
ux
there
epics
have
you
can't
do
epic
dependencies,
but
you
can't
on
issues,
and
so,
if
we
were
to
abstract
like
the
blocks
in
this
block
by
out
into
its
own
widget
and
then
made
that
work
across
all
issuables
as
sort
of
standard,
we
wouldn't
have
to
duplicate
the
feature,
basically
to
get
it
at
epics
and
merge
requests.
So
I
think
that's
the
kind
of
long-term
goal.
How
we
get
there
technically
is
totally
up
to
engineers,
but.
C
Yeah
cool,
so
if
I
mean
if
I
was
a
wider
contributor,
wider
community
member
contributing
to
gitlab
like
I
might
look
at
the
way,
things
are
implemented
currently
and
assume,
that's
the
way
to
build
it.
You
know
rather
than
look
at
this
case,
so
we
should
probably
in
the
documentation,
put
this
in
front
of
people
and
say:
hey
look
from
now
on.
All
new
things
need
to
be
developed.
This
way.
B
Yeah
and
it's
even
even
for
merge,
requests
things
that
like
it
would
have
been
helpful
like
if
they
would
have
implemented
reviewers
and
approvers
at
the
issuable
level
and
set
the
merge
request
level.
Then
we
could
have
turned
on
for
issues
with
minimal
work.
I
mean,
I
don't
think
it'll
be
terrible
to
move
it
up
to
the
issuable
level
so
that
we
can
consume
it
within
issues
itself.
B
But
it's
still
the
mindset
of
saying
like
we
want
to
build,
build
widgets
and
things
that
are
will
work
across
all
issuables
with
minimal
effort,
because
then,
eventually,
you
can
get
to
the
point
where
people
like
you
can
have
a
library
of
all
these
widgets
that
you
could
use
some
might
be
forced
or
required
by.
You
know
our
own
features,
but
if
you
get
to
allow
user
users
to
customizing
issue
types,
you
can
say
hey.
I
want
to
create
this
issue
type.
B
I
want
to
pull
these
widgets
into
my
thing
and
it
can
just
work
because
it
was
designed
that
way.
So
it's
almost
like
building
extensible
issues
based
on
demand
from
the
community
is
how
I'm
approaching
it
and
letting
helping
the
community
to
contribute
to
it,
since
we
have
a
ton
of
stuff
on
our
plate,
and
so
it's
like
taking
the
position
of
let's,
let's
guide
and
coach
everyone
to
like
contribute
towards
the
vision
that
we
want,
I
think,
is
the.
B
A
Yeah,
so
my
comment
here
was
primarily
around
not
so
much
on
the
widget
ecosystem,
where,
with
different
issue
types
you're
using
different
widgets,
but
more
so
on,
adding
adding
components
or
adding
features
to
the
actual
issue
page
and
if
it
makes
sense
to
have
some
type
of
process
to
adding
things
to
that
so
like
releases,
for
example.
Severity
is
probably
a
bad
example
because
I
don't
think
we're
going
to
at
least
for
a
while
I'll
take
that
into
the
issue,
issuable
type,
but
something
like
releases
where
we
would
want
to
do.
A
We
want
to
like
if
another
team
wants
the
proposed
release
to
design
it,
create
it
as
an
extensible,
widget,
extensible,
issuable,
widget,
and
then
add
it
to
the
issue
type.
At
what
point
do
we
want
to
set
up
a
process
for
adding
that
to
issues,
because
I've
seen
this
in
the
past,
with
some
other
widgets
that
we've
or
components
that
we've
added
that
we
haven't
had
a
say
on
until
it
was
released
and
that's
not
necessarily
a
bad
thing,
but
I
feel
like
we
should
have
a
process
in
there
or
some
regulation
in
there.
B
Yes,
I
think
that's
where
I
I
asked
jackie
porter
who's
the
pm
for
release
management,
as
I
said,
would
you
consider
making
it
a
requirement
that
you
build
this
as
an
extensible,
issuable
widget,
when
you
do
and
she's
like?
That's
fine
and
she
put
that
as
a
acceptance
criteria
on
the
proposal
right.
So
I
think
that
sort
of
thing
like
I
and
that's
where
the
health
team
did
a
really
good
job,
collaborating
with
us
and
designing
something
in
a
way
that
would
work.
B
I
think
we
should
have
some
sort
of
like
formal
process
for
adding
things
to
issues
that
we
asked
folks
to
go
through
it's
sort
of
logical
right,
because
that
will
also
help
lower
the
barrier
to
entry.
A
B
Correct,
yes,
I
think
that
makes
sense
eventually
hopefully
like
in
a
year
from
now.
We
don't
have
like
a
base
issue
in
the
ui
we
have.
We
have
like
basically
different.
You
create
a
new
thing.
Maybe
it
is
an
issue,
but
you
select
the
type
and
then
kind
of
the
types
almost
take
on
more
of
a
impact
to
ux
than
just
it
being
a
standard
issue
right,
because
we're
going
to
want
to
have
bugs
we're
going
to
want
to
have
security
issues.
B
It's
basically
taking
all
the
things
that
we
use
labels
for
to
identify
what
type
of
issue
the
issue
is
and
making
that
like
a
first-class
issue
type.
But
then
you
can
have
the
fields
that
you
want
on
that
type
of
issue
and
not
the
ones
you
don't
need
and
that
sort
of
thing
but
yeah
whatever
process
we
want
to
have
from
an
engineering
standpoint
I
support
and
from
a
product
standpoint.
I
support.
C
I'm
wondering
like,
should
we
have
a
page
for
extensible
issues
in
the
handbook,
because
you
know
like
bugs
a
great
example
bugs
probably
do
need
severity
at
some
point
and
if
we
have
an
idea
on
the
page,
this
simple
table
of
what
we
have
now
what
we
intend
to
support
in
the
future
like
if
I'm
creating
an
incident
issue
type
and
I
need
severity,
then
I
can
see
that
project
management
needs
severity
in
the
future,
and
I
can
you
know,
build
that
to
be
extensible,
and
you
know
tick
that
off
right,
because
I
suppose
the
way
I'm
thinking
here
is
like
you
get.
C
So
you
know
you
don't
build
something
as
a
widget
because
you're
in
a
different
team,
and
you
don't
get
that
that
it's
beneficial
for
it
to
be
a
widget
right,
but
if
we
have
a
visible
somewhere
where
like
yeah,
if
I'm
building
severity
and
that
project
management
can
use
it
give
me
another
example
like
if
you're
building
in,
I
don't
know
like
the
ability
to
satisfy
a
test
case
in
requirements
that
another
issue
type
might
use
that
down
the
road.
C
But
that
won't
happen
if
it's
all
different
teams,
unless
there's
some
visible
place
where
you
can
see
what's
planned
in
the
future
yep
where
in
the
handbook
will
you
put
that?
Do
you
think
I
don't
know
like?
I
was
thinking
the
plan
category
page
somewhere
like
link
it
from
there
or
do
we
make
extensible
issues
like
like
a
topic
from
the
links
off
of
the
plan
page
because
it
like
touches
so
many
other
groups.
B
There's
this
let's
see
here,
this
is
in
our
dots
now,
so
there
is
something
like
in
there
about
issue
types,
so
we
could
either
put
it
in
the
handbook
or
we
could
put
it
in
a
our
public
documentation
so
that
wider
community
members
don't
have
to
dig
through
our
handbook
or
know
where
to
look
right
and
then
we
could
cross-link
it
from
our
handbook.
If
we
wanted
to
do
that,
that's
sort
of
it's.
B
Basically,
we
need
to
update
this
anyways
because
it's
out
of
date,
it's
not
accurate
anymore,
because
we
do
have
an
issue
type
column
and
all
that
stuff.
So.
A
Holly
or
alexis,
because
I
see
this
somewhat
similar
to
our
gitlab
ui
components
like
I
think
the
end
vision
is
just
to
have
all
these
extensible,
which
is
essentially
a
library
of
widgets
that
anyone
can
add
to
or
work
on,
which
is
somewhat
similar
to
pajamas.
A
How
has
gitlab
ui,
because
for
documentation
there
we
have
essentially
a
separate
site
outside
of
docs,
and
our
handbook
have
you
all
seen
like.
Has
the
community
used
gitlab
ui,
the
gitlab
ui
documentation?
Have
they
used
gitlab
ui?
Have
they
contributed
there?
How
has
that
how's
that
work.
D
Personally,
I
haven't
seen
any
community
contributions
to
the
getlab
ui
that
I
recall
it's
all
been
internal
work,
but
I
want
to
just
touch
on
something
really
quickly
to
clarify.
When
we
talk
about
extensible
issues.
Are
we
talking
about
extensible
issues
as
issue?
Is
a
concept
or
extensible
widgets,
which
could
be
shared
across
many
issuable
types,
such
as
merge
requests.
B
Correct,
like
there's
the
idea
where
we
could-
I
mean
I
don't
know
from
technical
sample,
but
right
now,
epics
are
a
different
thing.
That
use
issuables.
Merge
requests
are
a
different
thing
that
use
issuables
and
then
there's
issuables
issues
and
what
we
really
want
to
get
to
is
being
able
to
easily
like
have
us,
basically
the
same
ux
and
the
same
expectation
of
how
something
works
across
all
the
issuals,
because
it's
weird
that
you
have
to
edit
an
issue
to
make
another
merge
request
blocking
an
emergency
quest
right.
B
D
Think
that
makes
sense.
I
just
want
to
be
sure
that
that
we're,
including
all
the
right
people
that
are
affected
by
those
various
parts
as
part
of
the
conversation
but
alexis,
do
you
want
to
give
your
thoughts
on
donald's
question.
H
Yeah,
I'm
curious:
what
are
you,
why
are
you
asking
donald?
What
are
you
envisioning?
I
haven't
seen
a
lot
of
contributions
to
pajamas.
I
think
you
know
in
the
threads
when
we're
discussing
opponent
component,
I
see
some
we've
actually
had
people
using
our
figma
files,
which
is
pretty
cool.
But
what
are
you
envisioning,
donald.
A
I'm
trying
to
determine
the
best
place
to
encourage
contribution
or
the
best,
the
the
best
place
for
outside
collaborators,
to
discover
to
discover
documentation
or
assistance
or
guidance.
H
Yeah,
I
think
pajamas
would
would
be
great.
I
think
we're
working
on
expanding
our
docs
a
whole
lot
within
that
and,
like
specifically
interactions
for
components
which
I
think
is
good,
so
I
think
that
that
would
be
the
right
place
to
put
it.
If
that's
the
question.
A
Yeah,
so
I'm
not
so
sure
like
within
the
pajamas,
but
in
a
similar,
as
in
like
pajamas,
is
its
own
separate
thing
that
we
link
to
within
our
docs
and
our
handbook
like
if
we
want
to
create
something
separate
like
that
or
if
we
want
to
add
this
to
the
handbook
or
if
we
want
to
add
this
to
our
our
docs.
A
Personally,
I
think
the
best
place
for
it
is
within
docs
and
it
looks
like
we
already
gave
link
to
a
page
that
we
kind
of
already
have
there.
It's
all
yeah.
We
can
add
it
to
all.
A
Yeah
I
mean
for
now:
do
we
just
want
to
go
off
of
that
page?
That's
already
been
created
in
the
docs
and
start
with
start
with
that.
B
I
think
that
would
be
great,
I
think,
dollars.
Won't.
We
need
to
make
sure
that
we're
covering
issuables
like
widgets,
should
work
on
all
issuables
and,
what's
like
is
a
little
duplication
as
possible,
and
then
we
can
also
talk
about
issue
types,
because
those
are
a
real
thing,
so
it'd
be
great
to
go
off
what
we
have
and
we
can
expand
it,
and
I
don't
see
why
not
and
then
cross-link
it
from
the
handbook.