►
From YouTube: GitLab Plan - Tasks Sync with Marshall
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,
thanks
y'all
for
being
here,
Marshall
I,
scheduled
this
meeting
after
you
left
some
comments
on
an
issue
about
tasks
and
I.
Just
thought
it'd
be
easier
to
talk,
synchronously
and
also
selfishly
the
questions.
You're
asking
are
ones
that
we've
been
asked
by
others.
So
I
thought
it
would
be
helpful
to
talk
about
it
on
YouTube
like
and
record
it
so
that
we
can
share
this
out
with
other
people
when
they
have
similar
questions.
B
Yeah
this
looks
this
looks
good.
The
I
I
want
to
preface
everything
by
like
the
the
most
important
thing.
That
I
want
to
understand
is
just
like
the
overall
direction
of
work
items
because,
like
I,
I
I
thought
I
understood
where
we
were
headed
with.
All
of
that
and
the
the
sub
tasks
on
issues
seem
to
be
like
different
from
the
from
the
overarching
direction
that
I
thought
we
were
headed
with
with
work
items.
B
So
it
was
like
that
sort
of
juxtaposition
that
that
I
want
to
understand
better
because
because
like
where
I
the
the
direction,
I
thought
we
were
headed
with
work
items
was
that,
rather
than
having
all
of
these
discrete
entities
that
are
sort
of
based
on
this
issuable
markdown
description
model
right
that
we
were
going
to
have
one
overarching
entity
called
a
work
item
with
various
implementations
of
that
in
the
form
of
epics
issues.
Incidents
alerts
all
all
that
stuff,
that's
sort
of
based
on
that
issueable
model
today.
B
But
but
then,
when
I
saw
the
the
tasks
effort
it,
it
seemed
to
to
deviate
in
the
sense
that,
like
it's,
it's
it's
not
a
full-blown
issue
right
or
at
least
in
in
this
current
iteration
it
it
doesn't,
have
all
the
metadata
associated
with
it.
Labels
assignees
a
status
in
the
same
way,
and
so
it
seemed
like
a
departure
from
a
work
item
rather
than
a
a
step
in
that
direction.
C
I
think
it
might
be
helpful
to
start
with,
where
we're
going
is
exactly
what
you
said
so
there's
not
any
difference
there.
C
The
reason
why
tasks
don't
look
like
issues
and
don't
look
like
epics
is
because
we
sort
of
have
had
to
figure
out
how
to
do
a
lot
of
things,
sort
of
sequence,
a
lot
of
different
things
in
a
way
that
allowed
us
to
be
iterative
to
reach
that
ideal
insight,
and
so
one
of
the
things
that
we
want
to
do
with
work
items
is
making
sure
that
they're,
extensible
and
and
by
that
I
mean
not
just
like,
were
our
teams
are
hard
coding,
the
behaviors
right
for
these
different
things,
but
it's
like
actually
a
framework
that
we
can
then
expose
to
the
end.
C
Customers
say
like
hey:
you
want
to
use
work
items
for
these
use
cases
and
you
can
install
these
apps
for
these
widgets.
You
can
turn
them
on
and
off
and
like
to
do
that.
To
kind
of
reach
that
ideal
end
State,
we
sort
of
have
to
have
a
different
API
than
we
have
for
issues.
So
we
had
to
figure
out
how
do
we
write
an
incrementally
and
it
really
like
write
this
new
API
that
supports
the
extensibility
we
want.
How
do
we
also
build
a
new
front
end?
C
We
would
either
have
to
refactor
the
existing
issue
front
end
because
right
now
the
tech
that's
powering,
that
is
super
fragmented
and
all
over
the
place
like
we
have
a
bunch
of
handle
stuff.
We
have
a
bunch
of
like
old,
older
view
stuff.
We
have
a
bunch
of
new
review
stuff.
We
have
a
bunch
of
apolograph
ql
stuff.
There
is
no
standard
set
of
apis.
That's
powering
the
single
view.
There's
no
way
to
even
get
all
the
system.
C
Events
in
a
single
API
point
right
now
like,
and
so
we
we
sort
of
have
to
pay
down
that
technical
debt
and,
along
with
that
sub-proc
debt
right,
because
if
we
think
about
extensibility
the
sidebar
and
the
way
the
issue
layout
and
all
that
stuff,
it's
not
scalable
and
it
just
like,
doesn't
work,
and
so
we
have
to
figure
out
a
ux
pattern
that
supports
like
use.
Cases
like
we're
on
incidents
is
that
there's
different
tabs
on
epics.
There's
a
couple
different
tabs
tabs
aren't
necessarily
in
the
cell
scalable
like
so
what's
the
interaction
model?
C
Look
like
for
these
more
complex
like
we're,
calling
them
apps
or
whatever
or
widgets,
that
can
be
embedded
and
enabled
for
work
items,
and
then
you
have
the.
How
do
we
unify
the
data
model
to
get
like
epics
migrated
onto
the
issue
data
model,
which
is
the
future
workout
data
model?
How
do
we
do
that
like?
Because
we
would
have
to
then
add
parent-child
relationships
to
the
issue
data
model?
C
C
Work
items
are
powered
by
the
issue
data
model,
so
you
could
theoretically
add
in
and
we've
disabled
tasks
from
the
rest
API
for
right
now,
you
could,
via
the
the
API
admin
assignee
to
a
task,
or
previously
before
we
disabled,
that
and
I
think
what
what
our
plan
is
is
as
we
sort
of
build
and
refactor
each
of
these
widgets
within
the
new
API
for
work
items
we're
not
like.
C
We
also
have
to
do
some
model
splitting
things
like
that
to
support
the
extensibility
at
some
point,
but
we've
kind
of
deferred
that
a
little
bit
we're
slowly
going
to
enable
these
things
for
tasks.
Then,
once
we
have
parity
with
what
is
now
at
the
Epic
Level,
so
discussions
and
notes
and
labels,
and
then
issues
are
also
made
available.
B
So
so
the
the
like
having
a
parent
trial
relationship
on
work
items,
which
is
a
prerequisite
to
having
epics
and
issues
based
on
work
items
right
that
that's
to
me,
seems
like
the
same
thing
as
as
tasks
right.
The
only
difference
being
that,
like
we,
we
Define
a
parent-child
relationship
between
work
items
as
an
epic
is
the
parent
and
issues
are:
are
the
children
so
I,
I,
guess
I,
don't
understand
like
in
that
future
state,
where
you
can
define
a
parent-track
relationship
between
between
work
items?
B
C
Different,
it's
the
same
thing
so,
but
if
you
think
about
in
the
future
too,
where
sort
of
tasks
or
I
guess
work,
item
types
are
user
defined
right,
so
we're
going
to
ship
with
a
default
like
hierarchy
based
on
what
we
heard
from
customers
where
that
might
be.
You
know,
capability
or
theme,
capability,
Epic,
feature
user
story
and
then
task
right,
that's
the
most
common.
We
hear
which
maps
saved
and
that's
all
sort
of
we're
doing
is
right.
Now
we're
hard
coding.
C
The
type
task
is
the
lowest
child,
but
in
the
future,
people
can
rename
that
to
whatever
they
want,
they
can
name
it
food,
they
can
name
a
bar
and
then,
when
you
get
into
multi-level
epics
right
now,
the
confusion
comes
with
the
fact
that
you
can't
add
have
specific
types
on
those.
So
it's
almost
like.
We
tell
customers
right
now,
okay!
Well,
if
you
want
this,
then
you
have
to
use
the
lowest
level.
C
Epic
is
your
story
and
then
use
your
issues
as
tasks
or
sort
of
like
making
that
so
you
don't
have
to
do
it,
and
you
don't
have
to
split
that
across
a
group
in
a
project
because
most
the
time,
the
team
that
writes
the
stories
also
breaks
it
down
in
tasks
which
usually
happen
within
the
same
project,
but
sometimes
not
that
instance.
So
all
a
task
is
is
a
hard-coded
lightweight,
parent-trial
relationship
and
it's
the
same
thing:
the
same
mechanism
that
we're
going
to
use
for
epics
to
type
issue.
You
know.
B
Yeah,
okay,
I
think
that
makes
sense
like
I
I
I,
really
like
the
way,
the
direction
that
GitHub
is
going
with
their
plan
tooling,
and
that
is
in
alignment
with
what
they're
doing
right
like
they.
Don't
they
don't
have
the
concept
of
epics
they're
working
with
they're,
creating
hierarchical
structures
with
a
based
on
a
flat
list
of
issues,
essentially
right,
yep
and
and
like
the
next
step
for
them,
is
to
allow,
like
their
project
planning
thing,
to
support
those
parent-child
relationships
between
issues
and
so
like,
like.
B
That
makes
a
ton
of
sense
to
me,
because
people
like
I
think
the
problem
with
that
people
have
with
epics
is
that
the
term
epic
doesn't
map
to
some
concept
within
their
organization
right,
correct,
which
is
why,
having
just
one
primitive
type
that
everything
is
implemented
on,
like
organizations
can
Define
what
a
root
level
object
means
to
them.
Right
like
it
can
be
an
okr,
and
then
they
can
have
all
their
KRS
underneath
that
right,
but
everything's
just
an
issue.
Yeah
yeah.
C
It
feels
weird
to
say
that,
like
epic
is
a
type
of
issue,
and
so
instead
of
I
guess
like
a
task
being
a
relationship
type
in
in
our
world
like
a
task
is
just
a
work
item
type
and
then
you
can
Define
the
relationships
between
your
different
workout
and
types
and
saying
this
is
a
parent-child
relationship
type
like
and
then
you
can
kind
of
build
out
whatever
reporting
hierarchy
you
want
and
we'll
of
course,
ship
with
defaults
like
we
might
even
have
a
git
lab
default
right
and
we
might
have
a
safe
default
or
whatever
that
Maps
these
methodologies.
C
So
when
people
on
board
to
get
loud,
they're
like
this
is
what
we're
this
is
a
process
for
falling
and
they
can
do
a
single
click
like
get
everything
generated
and
start
it
out
really
easy.
But
then
they
have
the
the
controls
to
go
in
and
kind
of
tweak,
some
of
the
knobs
and
dials.
As
they
see
fit,
but
it
is
all
based
on
the
same
primitive
right
object.
A
Yeah,
so
I
actually
am
really
interested
to
see
where
GitHub
is
going
if
they're
gonna,
formally
Define
types
instead
of
having
everything,
be
an
issue,
because
that's
something
we
hear
very
often
from
customers
like
they
want
to
be
able
to
just
quickly
filter
on,
like
these
objects
are
this.
They
have
these
properties
on
them,
and
this
is
like,
for
example,
a
product
manager
only
looks
at
features.
They
don't
necessarily
care
that
much
about
like
tasks
right.
A
B
Regarding
the
the
types
of
of
issues
I
I
expect
I
I
completely
expect
that
they're
gonna
leave
that
entirely
and
and
user
land,
because
the
the
like
they
have
this
distinction
that
we
don't
have
between
a
repository
and
a
project
plan
right
like
like
they
have
this
whole
top
level
concept
of
a
of
a
project
which
is
how,
like
one
or
more
repositories,
get
rolled
into
I
mean
it's
sort
of
analogous
to
like
our
our
hierarchical
group
structures
right,
but
I,
I,
I,
suspect,
they're,
going
to
keep
share
issues
that
the
repository
level
and
then
whatever,
like,
whatever
you
want
to
do
at
the
at
the
project
level
like,
however,
you
want
to
organize
those
issues
into
higher
level.
B
Constructs
I.
A
C
That's
interesting
that
why
we
do
get
larger
organizations
that
want
to
use
git
love
planning
instead
of
GitHub
because
of
the
hierarchy,
and
it
has
like
these
crazy
inherent
complexities
that
come
with
it
so
I'm
interested
to
see
how
they
solve
that
too,
and
so
I
I
think
in
the
future,
I
sort
of
see
us
moving
towards
a
sort
of
a
model
where
we
also
have
the
same
flexibility
like
right
now,
issues
only
live
at
project
level
and
epic's
only
11
at
the
group
level,
but
like
work
items
live
in
namespaces
and
they
can
be
related,
have
some
form
of
relationship
to
other
work
items
in
any
other
namespace
right,
and
so
that
way
you
can
kind
of
go.
C
C
B
Like
an
arbitrary
thing
right
because,
like
it's
just
totally
dependent
on
like
how
you're
doing
like
your
project
management
right
like
whether
you
have
like
a
separate
issues,
only
like
project
in
that
group
versus
issues
in
every
project
versus
like
only
using
epics,
you
know
what
I
mean,
like
there's,
been
a
a
bunch
of
ways
to
work
around
that,
but
nothing
quite
as
clean
as
just
doing
whatever
you
want
at
the
group
level.
I.
C
Agree
yeah,
it
was
an
arbitrary
decision
and
that's
sort
of
where,
like
I
wish,
we
had
never
built
epics
honestly
I
wish
we'd,
never
build
groups
also
so
we're
trying
to
like
reverse
some
of
that
and
go
back
to
the
simpler
ways
and
and
learn
as
we
go.
I
think
also
just
to
speak
to
some
of
your
questions
and
your
comments
that
I
read
about
like
well.
Why
do
we?
Why
are
we
going
with
the
widget
instead
of
just
markdown?
C
We
started
the
markdown
route
and
then,
as
we
went,
it
sort
of
got
more
and
more
complex
in
terms
of
like
how
you
do
the
syncing
and
then
also
what
the
user
experience
is
like
and
discoverability
like
I
think
it's
great
for
existing
gitlab
users,
who
might
want
to
just
convert
an
existing
checkdown
list
item
into
like
a
task.
You
know
and
have
it
be
a
first
class
thing,
but
then
you
quickly
get
into
the
syncing
problem.
C
What
happens
if
you
edit
the
description
and
remove
the
reference
to
the
task,
then
it
sort
of
like
lost,
and
you
have
to
go,
find
it
from
the
issue
list
and
then
what
happens
if
you
like,
interject,
a
bunch
of
text
in
between
the
references
in
the
markdown?
How
does
that
impact
the
syncing
and
those
are
all
things
I
think
we
can
work
through,
but
it
also
I
think
we
just
made
a
decision
to
keep
things
simple:
we're
not
going
to
remove
that
functionality.
C
We
just
disabled
behind
the
feature
flag
until
we
can
work
out
a
lot
of
the
nuances,
but
what
ends
up
happening
and
I
think
people
added
the
light.
Somebody
add
the
lightweight
tasks
like
for
markdown
and
put
that
and
treat
that
as
like
a
first
class
thing
in
the
API.
Do
a
certain
degree
in
terms
of
tracking,
and
we
slowly
want
to
like
remove
that
and
kind
of
relying
on
the
markdown
checklist
task.
Numbering
is
your
progress
and
rely
more
on
the
formal
parent-child
relationship
items?
B
A
B
C
A
Way
that
they
have
it,
it's
not
a
formal
relationship,
it's
more
of
a
reference,
it's
kind
of
the
equivalent
of
us
kind
of
like
putting
an
issue
in
the
description.
There's
some
lightweight
like
progress
reporting,
but
it's
not
as
formal
of
a
relationship
as
I
think
our
customers
would
expect
based
on
the
President,
also
that
we
have
with
ethics
and
issues
right
where
it's
like.
It
is
a
very
tightly
coupled
parent-child
relationship.
B
Yeah
well
and
I
I
know
they're
working
on
like
discrete
parent-child
relationships,
so
it'll
be
interesting
to
see
how
they
map
the
markdown
thing
to
to
that,
but
certainly
like
when
you're.
It's
definitely
like
a
bi-directional
relationship
like
the
the
task
issue
in
GitHub
is
aware
of
the
fact
that
it's
associated
with
a
parent
issue.
You
know
what
I
mean
and
I
think
like
that
sinking
of
the
check
boxes
based
on
the
status
is
like
one
of
those
features
that
I've
wanted
in
both
GitHub
and
gitlab.
B
For
like
six
years,
you
know
what
I
mean
like
I,
think
there's
a
ton
of
value
in
in
that
working
the
way
that
people
would
expect
it
to
work.
Even
if
there's
like
caveats,
but
the
yeah
like
I,
I,
I,
I
I,
don't
have
a
good
answer
for
how
it
Maps
back
to
the
more
formal
relationship,
but
but
along
those
lines
like.
B
Like
another
point
of
confusion
from
my
perspective
was
that
this
was
introduced
as
like
a
completely
separate
widget,
when
we
already
have
like
a
widget,
that's
responsible
for
the
relationships
between
issues
and
merge,
requests
and
whatnot
that,
like
like
I,
it
just
felt
odd
that
we
didn't
just
call
that
a
parent-child
relationship
between
issues.
You
know
what
I
mean
because,
like
I
find,
the
the
I
find
the
whole
experience
of
like
what
a
task
is
right
now
more
complicated
than
if
they
were
just
both
represented
as
issues
regardless
of
all
the
markdown
stuff.
B
You
know
what
I
mean
like
if
we
had
just
introduced
a
new
parent-child
relationship,
and
we
had
said
that
this
issue
relates
to
this
issue,
because
this
one
is
apparent
and
this
one's
a
child
right.
You
can
show
that
in
and
both
on
the
parent
and
the
child
side
I
feel
like
everybody
would
have
been
like.
There
would
have
been
a
lot
less
push
back
to
that
approach,
because
that
that
is
is
directly
in
alignment
with
what
my
understanding
of
the
future
plans
are
right
to
be
fair.
B
I,
don't
know
like
what
you
all
are
thinking
in
terms
of
like
relating
issues
together
versus,
like
relating
our
hard-coded
epic
concept,
to
an
issue
right,
but
I
suspect
we're
just
trying
to
like
get
rid
of
all
the
distinctions
over
time
right
like
if,
if
somebody
wants
to
associate
an
issue
with
an
issue,
we're
not
going
to
stop
them
from
doing
that.
Just
because
this
thing's
called
an
issue,
not
an
epic
right,
yep,
okay,.
C
I
I
think
there's
room
to
improve
on
that,
because
to
me
it
is
just
a
different
relationship
type
to
everything
else,
where
you
have
blocking
blocked
and
I,
don't
think
you
should
be
able
to
have
a
linked
issue
or
linked.
Work
item
also
be
a
parent
work
item
which,
right
now
you
can
do
so
I'll
leave
that
in
Melissa's
Court.
That's
her
her
area
response.
A
Yeah,
there's
a
there's:
a
lot
of
content,
I
actually
looked.
One
is
like
I
looked
overall
in
the
industry
like
what
people
are
doing,
there's
both
implementations
where
they're
like
separate
and
together
sort
of
thing,
but
I
think
also,
if
you
think
about
blocking
relationship,
a
related
relationship,
they're,
very
different
they're,
not
hierarchical
right.
It's
just
like
you're,
pointing
from
one
thing
to
another
versus
a
parent-child
relationship,
is
very
different
right.
A
There's
a
lot
of
more
nuance
and
enforcement
that
has
to
go
along
with
that,
like
we
even
discussed
in
the
back
end,
are
they
together
or
different
and
they're
separate
they're
not
treated
as
the
same
just
because
there's
a
lot
more
complexity
and
rules
around
a
hierarchy
versus
kind
of
relating
which
is
just
sort
of
pointing
to
each
other?
So
that's
why
they're
separate
as
far
as
the
UI
goes,
I
think
that's
definitely
something
that
we
can
iterate
on
right
and
I
would
say.
A
I'll
point
you
to
the
latest
version
of
this
in
our
test
stage,
so
you
can
give
us
feedback
on
what
you
see
there,
because
we're
still
working
through
a
lot
of
the
ux
stuff.
From
this
and
I
do
want
you
to
see
the
latest
and
give
us
feedback
on
that
and
tell
me
if
that's
more
clear.
B
C
Can
do
that
now,
I
think
hopefully,
I've
been
on
vacation
and
I
just
got
back,
but
they
were
working
on
making
tasks
show
up
in
the
issue
list
and
be
filterable
there
and
all
that
stuff.
The
only
thing
we're
sort
of
putting
an
artificial
constraint
on
is
what
data
we
show,
because
we're
trying
to
build
out
the
new
API
and
then
the
UI
at
the
same
time
and
make
some
changes
to
usability
there.
C
So
we
need
some
form
or
place
to
do
that
incrementally
and
iteratively
otherwise
like
if
we
would
have
split
it
out
just
at
the
parent-child
relationship
and
then
tackle
the
UI
and
the
API
later.
We'd
have
to
put
that
behind
the
super
super
long
live
feature
flag
and
only
enable
the
new
UI
when
it
was
had
a
complete
parity
with
the
old
UI,
and
so
this
since
we're
introducing
this
new
concept
of
a
child
to
an
issue
which
is
a
task
which
is
the
same
thing
as
an
issue.
C
If
you
could
think
about
that
at
work
item
we're
sort
of
gating
what
data
can
be
added
when
so
that
we
can
build
out
compatibility
with
the
Legacy
issue
UI
if
that
makes
sense,
but
okay
in
a
new
in
a
new
way,
yeah.
A
But
I
also
think
like.
If
you
look
at
what
a
task
is
like
a
task
is
supposed
to
be
something:
that's
like
a
couple
of
hours
of
work
right
like
if
you
look
at
the
agile
Frameworks
and
if
you
look
at
tools
out
there
like
they
are
very
simplistic
right,
so
I
think
By,
Design,
not
gonna,
be
exactly
the
same
as
an
issue
or
an
epic,
but
in
the
future,
like
you
said,
if
somebody
wants
to
like
Point
issues
to
each
other,
they
can
right
like.
A
B
B
B
Right,
like
I,
think
the
parent-child
relationship
between
issues
could
be
powerful
in
the
sense
that,
like
I,
can
Define
metadata
at
the
top
level
issue
and
have
it
automatically
propagate
down
to
the
child
tasks
that
are
associated
with
it
right
so
like
if
I
label
an
issue,
and
that
issue
has
children
that
label
Cascades
down
to
all
the
other
children
which
is
sort
of
like
the
opposite
of
what
we
do.
With
this.
C
Is
one
of
the
reasons
why
we're
doing
we're
doing
all
this
on
the
issue?
Data
model
and
rebuilding
it
a
little
bit
of
time,
because
we're
building
that
the
proper
cascading
is
it's
not
inheritance
up,
it's
cascading
down
and
then
also
how
things
roll
up
and
making
that
work.
The
way
that
it
should
and
not
sort
of
backwards.
That
works.
B
Yeah
and
I
think
for
organizations
like,
depending
on
the
the
direction
that
you
Cascade,
whether
it's
up
or
down
like
that,
gives
you
a
ton
of
flexibility
for
using
that
same
thing
as
either
a
task
or
more
like
a
unepic
right,
like
cascading
down,
sounds
like
a
task.
Cas
getting
up
sounds
like
an
epic
right
and
I
think
that's
good
that
both
those
could
be
modeled.
The
same
way
and
I
to
me
is
a
case
for
why
we
shouldn't
introduce
like
the
artificial
constraints,
because
you
know
just
let
people
use
it.
A
So
we're
over
time,
but
I
did
want
to
end
in
like
I
think
in
the
end,
State
we'll
be
somewhere
where,
like
your
use
case,
will
be
met.
We're
gonna
be
kind
of
like
more
opinionated
in
the
front
end.
I
will
call
it,
but
in
the
back
end
it
will
like
what
we're
building
will
be
able
to
like
mix
and
match
and
basically
use
the
system.
A
However,
you
want
some
of
that
stuff,
maybe
in
higher
tiers
for
kind
of
like
giving
you
that
configuration,
but
I
will
say
that,
like
our
customers
want
us
to
be
more
opinionated
right
like
right
now,
the
flexibility
with
epics
and
like
nesting
is
confusing.
So
they
want
things
to
be
more
like
defined
and
labeled
in
specific
ways
right
and
that's
what
we're
taking
as
sort
of
like
the
out
of
the
box
default.
But
we
build
the
system
in
a
way
that
it
can
be
configured
to
change,
depending
on
like
different
people's
workloads,
cool.
B
And
I
want
to
be
respectable
time,
but
just
the
last
thing,
I'm
curious
about
is
like
another
thing
that
I
like
about
GitHub
projects
is
the
way
they're
enabling,
like
different
teams,
to
basically
have
different
views
of
reality
right
like
because
the
the
custom
metadata
that
they
allow
you
to
associate
with
what
they
call
like
project
items
I
think
is
on
a
per
project
basis.
B
C
Yeah
so
I'll
link.
This
is
under
six
I've
spent,
probably
a
better
part
of
a
year,
trying
to
figure
out
how
to
see
in
working,
good,
lab
and
I.
Think
I
figured
it
out
with
the
help
within
some
Engineers.
Of
course,
they
were
very
smart
about
it,
but
sort
of
building
in
a
new
sharing
model-
and
the
complexity
here
is
that
we
also
want
to
figure
out
how
this
plays
in
with
the
work
that
workspaces
is
doing
and
how
they're
going
to
rebuild
sort
of
like
right.
C
Now
we
have
a
really
bad
problem
with
how
things
inherit
down
and
flow
up,
and
it's
not
consistent
across
different
objects
and
then
there's
not
consistency
between
how
our
project,
our
group
project
hierarchy,
works
and
how
group
sharing
works
when
you
give
access
and
permissions
via
group
sharing.
So
those
two
things
like
in
this,
this
is
workspaces
domain,
but
those
two
things
need
to
become
the
same
mechanism,
sort
of
like
what
we're
doing
with
epic
issues,
which
I
think
they're,
aware
of
and
depending
on
how
that
works
out.
C
We
sort
of
want
to
either
take
what
they've
built
there
and
and
apply
it
to
Resource
specific
things.
Instead
of
like
a
namespace,
you
can
share
a
work
item
with
multiple
different.
You
know
groups
or
projects,
and
then
they
all
show
up
there.
Depending
on
what
access
controls
you
have
to
the
different
projects,
it
determines
what
visibility
you
have
for
the
metadata
that
is
basically
Associated
to
that.
To
that
work
item
so
I
think
we
know
how
it's
going
to
work.
C
We
just
need
to
build
it
and
we
haven't
started
building
it
until
we
have
the
Consolidated
work
item,
because
when
you,
if
we
were
to
do
this,
we'd
have
to
do
this
for
build
this
like
same
mechanism
for
issues
and
then
for
epics
and
then
for
requirements,
and
so
we're
trying
to
like
get
that
primitive
and
consistent
thing
down,
and
once
we
have
that,
then
it
sort
of
makes
more
sense
to
to
take
on
the
work
for
for
kind
of
making
a
workout
I'm
kind
of
extend
across
multiple
namespaces,
because
that
sort
of
already
happens
right
now.
C
C
Not
formalizing
away,
and
so
what
I've
written
down
in
this
proposal
is,
is
a
mechanism
that
we
have
to
build
to
make
it
more
formal.
If
that
makes
sense,
so
it
would
work
very
similar
to
what
GitHub
does
now
and
I
actually
modeled
a
lot
of
this
off
of
Asana
before
GitHub
did
what
they
did
with
their
projects,
beta,
so
cool.