►
From YouTube: Simplify Groups and Projects Working Group - 2020-07-09
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
So
alex
I'll,
let
you
kick
it
off,
since
you
have
the
first
one,
actually
a
little
preamble.
I
extended
this
session
mike
reached
out
to
me
and
thought
it
might
be
useful
to
spend
some
of
the
time
together,
sort
of
sketching
and
digging
into
some
of
that
solution.
Validation,
so
y'all
can
drop
when
we
get
to
that
point.
If,
if
you
have
other
things
but
since
we're
all
here,
it
might
be
nice
to
do
that
together.
A
So
all
that
might
lead
that
part,
but
but
we
can
start
with
the
top
of
the
agenda,
so
alex
you're
up.
B
Sure
yeah,
it's
pretty
much
what
it
says
there
in
the
meeting
notes.
I
just
haven't
had
enough
time
this
week,
but
I
hope
to
look
at
what
git
lab
maybe
look
like
if
we
were
to
start
from
scratch,
but
yeah
I'll
have
that
for
next
week.
Hopefully.
C
D
Yeah,
that's
quick
cool.
Some
of
you
have
already
been
in
an
inception
before
I'm
gonna
run
us
through
kind
of
a
lightning
inception,
because
yeah
the
main
purpose
is
to
propose
solution
ideas
and
to
discuss
each
one,
the
value
of
it,
the
the
merits
of
the
solution
and
then
we're
going
to
do
it
on
a
mural
board.
So
we
have
kind
of
a
better
like
visual
representation
of
our
what
we
talked
about
the
last
few
weeks.
D
I
think
it's
easier
to
it
can
be
easier
to
look
at
a
mural
board
and
go
okay.
This
is
where
we're
headed
for
in
terms
of
a
decision
than
to
try
to
do
the
long
scroll
through
a
google
doc,
and
it's
honestly
just
like
easier
to
follow
when
it's
more
visual.
So
I
put
an
invite
link
into
the
doc
here.
If
that
invite
link
doesn't
work,
please
please
do
chime
in.
D
I
see
gabe
justin
and
myself
so
far.
D
D
Settings,
what's
your,
can
you
put
your
email
address
in
the
zoom
chat?
C
G
D
I
imagine
you'll
get
an
email
shortly
or
you
can
just
try
refreshing
if
you
signed
in
with
your
gitlab
email
address.
You
might
be
able
to
refresh
that
button.
Yeah.
Oh
liam,
I
see
liam,
I
feel
like
one
of
those
like
children's
television
show
hosts.
I
see
liam
and
I
see
justin
and
I
see
kristin
and
like.
G
D
G
D
Yeah,
please
send
your
email
address
in
the
slack
just
copy
paste
it.
I'm
really
good
at.
D
D
Oh,
you
already
remember:
were
you
able
to
when
you
open
the
lake
melissa,
were
you
able
to
see
the
mural
you.
D
Well,
it
says
you're
already
a
member
when
I
add
you
as
a
yeah
when
I
put
your
email
address
in
it,
says
you're
already
a
member.
So
that's
weird:
how
did
other
folks
log
in
did
you
use
octa
or
or
just
straight,
google.
A
D
D
Yeah
sorry
about
that
melissa,
I
think,
given
that
your
icon
is
in
there,
I
think
if
you
refresh,
you
might
be
good,
it's
weird,
just
a
second
I'm
going
to
change
the
access.
I
I
D
Funny
yeah,
that
was
the
flicker
story
too,
and
slack
and
slack
yeah.
Oh
my
gosh,
like
wait.
We
need
to
make
money.
Okay,
so
again,
like
this
will
kind
of
be
a
lightning
round
for
some
of
the
folks
that
were
in
the
board's
inception,
you
might
be
nervous
that
this
is
going
to
take
a
while,
but
I'm
actually
just
going
to
I'm
going
to
take
some
liberty
here
and
if
I
type
anything
wrong,
you
can
actually
just
change
it
or
duplicate
it
and
change
it.
D
If
you
don't
feel
comfortable
stomping
on
me,
but
I'm
going
to
kind
of
go
through
these
pretty
quickly
and
probably
in
kind
of
an
analog
way,
because
going
linear
is
a
bit
longer
where
we
really
want
to
end
up.
Are
the
activities
and
workflows
and
that's
where
I'll
ask
to
for
people
just
to
put
note
cards
in
the
activities
and
workflows
area
where
it's
just
a
solution
idea
like
it
could
be
one
to
ten
words
and
then
we'll
discuss,
but
first,
let's
try
to
slog
through
this
really
quick.
D
D
So
we'll
come
back
to
that.
If
anyone
has
any
ideas
about
a
non-gold
go
ahead
and
just
start
typing
in
one
of
these
boxes
or
one
of
these
note
cards
and
then
I'm
going
to
fly
over
to
risks.
D
D
G
D
Looks
like
we
have
some
goals
that
are
popping
up,
and
I
was
wondering
if
melissa,
you
could
maybe
say
out
loud
the
one
that
you
just
wrote.
G
H
Know
that's
very
high
level,
but
in
talking
to
solutions,
architects,
basically
they
have
ex
told
me
that
they
spend
a
considerable
amount
of
time,
basically
explaining
how
things
work
and
all
the
nuances
of
groups
versus
projects
and
sharing
versus
members
different
roles
right
like
they
spend
a
lot
of
time
explaining
that
to
people,
because
it's
not
immediately
intuitive.
H
D
Cool
and
that
you,
your
goal,
is
informed
by
some
conversations
you've
had
with
solution,
architects
and
that
that's
kind
of
their
their
desire.
G
H
D
D
All
right
keep
codebase
maintainable
who'd
like
to
voice
that
one.
E
Yeah,
I
added
that
maybe
this
is
more
of
a
risk
like.
If
you
don't
do
this,
the
code
base
will
become
less
maintainable
but
yeah
like
just
generally
like
every
time.
You
duplicate
something.
It's
just
that's
to
the
overhead.
It
makes
everything
more
complex.
H
G
H
A
slightly
different
version
of
that
is
that,
from
the
product
side,
every
time
we
introduce
a
new
feature.
We're
like
is
this
at
the
project
level
at
the
group
level,
at
the
instance
level,
and
that's
like
a
whole
conversation
that
if
things
were
easier
like
that,
wouldn't
be
a
conversation
right,
it
would
just
be.
H
I
I
wrote
one
that
was
make
gitlab's
organizational
structure
is
more
accessible
to
support
the
variety
of
how
org
structure
things
like
right.
Now
we
really
only
support
mono,
repos
or
like
projects
where
all
the
project
management
happens,
and
this
is
inside
the
same
project
where
the
code
base
lives
and
that's
not
the
reality
of
how
organizations
structure
their
teams
and
their
code,
and
so
it
leads
to
things
that
are
confusing
and
hacky
and
workarounds,
and
all
that.
G
E
D
Okay,
yeah,
I
think
that's.
I
recall
that
coming
up
pretty
frequently
in
past
conversations
in
this
group,
what
are
some
of
the
risks
who
wants
to
voice
a
risk?
I'm
sorry
a
non-goal.
A
I
put
that
first
one
and
I
we
can
debate
this
one,
but
I
put
it
as
a
non-goal
to
figure
out
a
solution
and
a
path
that
allows
us
to
migrate
all
existing
customers
and
name
spaces
to
that
new
model.
A
A
You
know,
instance
of
gitlab.
Let's
you
know,
pursue
this
new
model
and
create
a
version
of
it
that
that
works
that
meets
all
the
goals
versus
understanding
the
I'm,
assuming
numerous
upgrade
paths
and
migration
paths
that
would
have
to
exist
to
support.com
and
to
support
large
existing
namespaces
as
an
mvc.
Obviously
like
this
adds
no
value.
If
we
can't
move
existing
customers
over
or
gitlab.com.
I
We
don't
know
what
the
nbc
is
yet,
but
I
I
also
would
think
that,
like
one
of
the,
maybe
this
is
a
goal
or
an
outcome
is
it
has
to
be
something
that
can
be
iteratively
incrementally,
like
a
path
to
incrementally
iteratively
move
our
existing
functionality,
because
what
we
don't
want
to
do
is
what
jira
did
with
next
gen,
where
they
have
like
a
they
branched,
their
code
bases
between
self-managed
and
cloud,
which
was
a
big
mistake
and
they're
paying
for
it,
and
then
they
branch
their
code
base
again
between
next-gen
and
classic,
and
it
it
makes
it
even
more
confusing.
A
C
Or
setting
yeah
like
setting
a
realistic
goal
post,
but
we
can't
achieve
yeah.
D
I
love
that
book
by
the
way,
getting
real,
a
realistic
goal
post.
I
G
D
A
C
G
D
Yeah,
that
is
one
of
the
purposes
of
the
working
group,
like
justin,
said
I
think,
being
open
and
inclusive
in
our
decision.
Making
process
is
always
good.
It's
going
to
be
messy,
but
sometimes
people
just
like
to
have
a
voice
and
be
heard,
and
that's.
G
D
E
E
D
Yep
get
them
excited
boy,
let's
go
to
risks
who
would
like
to
voice
the
changes
touch
a
broad
swath.
A
D
H
That's
me,
I
know
this
is
a
really
big
change
right
and
there's
like
a
bajillion
edge
cases
and
things
to
consider
right.
So
I
just
worry
that
we're
just
gonna
like
focus
on
all
those
things
right,
which
I
think
we
should
think
through
all
of
them
right,
but
I
guess
not
forget
to
try
to
act
on.
G
D
Okay,
here's
the
fun
part,
do
you
think
analysis
paralysis,
so
many
edge
cases
to
consider
is
that
kind
of
in
conflict
with
that
our
our
non-goal
is
that
we're
not
gonna
fix
individual
features.
H
I
think
I
think,
because
this
is
something
so
general
right
like
how
do
you
structure
things
right?
There's
a
essentially
is
what
we're
saying
right
like
how
do
you
create
hierarchies
within
gitlab
and
what
tools
do
we
give
you
to
do
that?
There's
a
a
lot
of
different
ways.
People
want
to
create
hierarchies
right.
Some
of
them
are
in
the
eighty
percent.
H
Some
of
them
are
in
the
twenty
percent
and
I
think
if
we
can,
if
we
try
to
solve
for
like
a
straight
forward,
easy
I'll
call
it
right
like
way
that
people
may
organize
things.
H
D
Okay,
who
wants
to
voice
the
executing
on
this.
G
D
And
then
I
think
we
talked
about
confusing
existing
users
who
are
used
to
the
current
model.
Anyone
else
have
a
risk
to
voice
before
we
move
to
a
bit
of
a
conversation
about
which
persona
we're
targeting.
D
How
about
donald
or
let's
see,
who
haven't
we
heard
from
yet
is
donald
still
on
here
I
can't
see
everybody
there
we
go
donald
or
alex.
Do
you
have
any
or
liam
any
ideas
for
risks
risks
around
this.
G
I
don't
have
any
additional
ones.
Sorry,
I'm
kind
of
in
listen
mode,
because
I
have
to
hop
in
three
minutes.
It's
all
good.
Okay,.
A
I
think
I'll
add
one
and
I
can
type
it
there's,
probably
a
risk
in
how
we
think
about
tackling
this
work
and
sequencing
it
if
it's
something
that
requires
a
lot
of
hands
to
jump
in
and
work
on
it
across
teams
that
it
sounds
to
me
like
it
would
be
much
harder
to
schedule
and
prioritize
than
if
we
can
find
ways
to
incrementally
iterate
against
it.
A
And
then
eventually
there
will
be
a
bunch
of
work
that
individual
teams
will
need
to
go
follow
through
on,
but
they're
not
inventing
the
work
themselves.
Hopefully,
hopefully,
we've
done
our
job
in
in
defining
those
patterns
and
defining
the
the
actual
solution.
So
it's
clear
if
we
do
need
to
ask
a
team
to
go,
make
changes
to
their
features
or
what
have
you.
D
A
D
I
I'm
going
to
go
out
on
a
limb
and
say
that
it
sounds
like
a
system.
Administrator's
job
is
on
the
hook
for
this
working.
Anyone
want
to
debate
that.
D
Or
not
debate
it
that's
kind
of
combative,
but
you
know
anyone
have
other
opinions
about
which
persona's
job
is
on
the
line.
If
this
doesn't
work
well
or
whose
job
is
currently
on
the
line,
because
it's
very
confusing
who
do
we
hear
the
most
complaints
from
and
consternation
from
because
of
the
way
it
currently
works?
I
think.
A
Is
the
way
I
think
about
this?
From
my
perspective
is
when,
when
there
is
more
stage
adoption,
this
problem
becomes
much
worse,
which
is
why
I
put
all
personas
with
a
smiley
face,
because,
as
you
try
and
traverse
plan
and
create
and
secure,
and
all
these
different
pieces
of
functionality
in
the
application,
it
becomes
harder
to
manage
that
in
your
head
and
understand
the
relationships
between
resources
and
name
spaces.
A
G
I
Yeah,
I
see
it
is
like
because
of
the
current
constraints,
some
personas
have
to
make
tradeoffs
about
their
ideal
workflow
and
not
being
able
to
ever
attain
it
within
gitlab
because
of
the
constraints,
if
that
makes
sense,
whether,
like
you
choose
to
structure
your
groups
and
projects
in
a
way
that
it
optimizes
for
project
management
or
team
planning,
and
that
sort
of
thing
you
have
to
make
trade-offs
on
where
your
repos
are
stored
and
like
there's
just
there's,
it
basically
does
impact
everyone
from
sales
calls.
It's.
I
It's
primarily
been
the
executive
level,
folks
that
won't
buy
gitlab
for
planning
because
of
the
current
constraints.
C
And
I
think
sorry,
the
people
who
need
the
information
rolling
up
the
pms
the
executives,
even
though
they
may
not
have
been
the
system
administrator
and
set
it
up,
they're
the
ones
in
the
most
pain
trying
to
grok
everything.
F
And
then
a
lot
of
what
is
that?
Sorry
and
oh
okay?
I
think
I
I
agree
with
that,
but
I
think
that
also
kind
of-
and
this
probably
is
covered
in
one
of
the
risks
already,
which
is
about
confusing
existing
users
who
are
used
to
a
current
model
and
if
we're,
if
we're
able
to
come
up
with
this
flexible
model,
where
anyone
can
do
anything
by
its
nature,
it
becomes
quite
complex
right.
F
There's
like
a
million
different
ways
to
achieve
the
same
thing
and-
and
I
think
we
do
run
the
risk
of
alienating
users
or
make
it
hard
making
it
harder
to
support
the
system,
making
it
harder
to
debug
and
maintain
the
system
and
we've
been
having
a
conversation
the
last
few
days
in
access
about
how
the
inheritance
permissions
work
and
it
is
fairly
rigid
at
the
moment.
But
it's
simple
by
the
fact
that
it
works
in
in
one
way.
F
D
All
right:
well,
thanks,
thanks
for
going
through
that.
That
was,
I
think,
that's
really
important
to
get
out
in
the
open
on
this
kind
of
one
one
view
I'm
going
to
skip
the
jobs
to
be
done,
because
I
think
some
of
the
jobs
to
be
done
will
emerge
from
a
solution
of
solution
generation
or
solution
proposal
type
of
session
that
we're
going
to
jump
into
now.
D
And
for
that,
like
we're,
really
flexible
here,
I
I
think
you
know,
there's
quite
a
bit
of
quite
a
bit
of
space,
we're
looking
at
this
whole
area.
That
is,
in
my
view,
right
now
and
so
so
be
kind
to
your
neighbor.
But
definitely
you
could
put
screenshots
in
here.
You
could
put
links
to
issues.
D
So,
even
if
you
just
put
a
note
card
with
one
to
ten
words,
that's
that's
fine,
because
we're
gonna
land
on
it
and
talk
about
it
and
the
time
boxes
are
gonna,
be
a
little
more
rigid
in
this
portion.
It's
like
five
minutes
to
quietly
generate
and
get
your
thoughts
on
the
board
and
and
then
about
three
to
five
minutes
per
person
to
articulate
and
and
maybe
even
share
your
screen.
If
you
want
to
when
we
get
into
the
sharing
portion.
So.
D
G
D
That's!
Okay,
that's
all
good
yeah!
So
again,
this
is
really
free
form.
Just
you
know
be
kind
to
your
neighbors.
Don't
don't
use
the
whole
space
if
you're
kind
of
uncertain
you
could
just
pick
a
corner
or
pick
a
wall
and
it
won't
work
inward,
but
you
can
put
screenshots
note
cards
links
to
issues
the
note
card
could
be
like
one
to
ten
words.
You
could
put
multiple
ideas
in
here
and
I'm
going
to
set
a.
D
D
D
If
that
makes
sense,
so
you
could
copy
the
url
to
an
issue
or
whatever
and
then
just
paste
it
on
here
and
it'll
generate
a
little
card
for
you.
You
could
also
take
portions
screenshots
of
a
portion
of
a
screen
and
paste
it
on
here.
You
can
drag
and
drop
files
onto
it.
Most
almost
any
image
file
works,
pdfs,
work.
G
D
D
D
D
D
There's
about
about
30
seconds
left,
if
you
feel
like
you're
done,
could
you
put
a
comment
in
zoom
and
just
say
done
and
then,
if
you
feel
like
you
need
more
time
put
in
the
con
put
in
the
comments
more.
D
D
D
Yes,
pencils
up
everyone
I
like
that,
brings
back
some
bad
memories,
that's
cool!
So
if
you
need
more
time,
it's
okay,
I'm
happy
to
add
like
another.
You
know
two
or
three
minutes.
D
We
also
could
do
another
round.
I
think
one
of
the
benefits
of
this
of
doing
it
time
boxed
is
if
we
each
only
take
about
you,
know
three
to
five
minutes
to
talk
through
a
solution
idea.
Then
we
can
do
another
round
and
we
end
up
seeing
a
kind
of
convergence
in
a
round
two,
and
that
would
be
really
great
to
get
to
that
today.
D
So
I'm
going
to
be
a
bit
of
a
bully
about
the
time
here
and
there
I
apologize.
If
I
sound
gruff,
I'm
also
going
to
ask,
I
think,
I'm
going
to
see
liam
I'm
going
to
use
yours
as
an
example.
D
E
Okay,
okay,.
D
G
E
G
D
How's
everybody
feeling
so
far.
I
know
this
can
be
tedious
if
it's,
if
you're
not
used
to
mural
or
used
to
a
facilitator,
telling
you
what
to
do.
D
Okay,
I'm
gonna
go
alphabetically,
so
I
think
that
oh
one
more
thing
does
anyone
need
to
drop
within
the
next
45
minutes
or
you
know
before
the
end
of
this.
Do
you
have
to
leave
before
the
end
of
this,
like
in
the
next
15
minutes
or
anything,
I've.
D
Okay,
let's
start
with
the
knowledge
group,
then
marcus.
Could
you
talk
us
through
what
you
came
up
with
yeah.
E
So
this
is
pretty
much
from
the
engineering
perspective.
One
is
just
allow
sub
projects
so
make
projects
hierarchical
like
as
a
way
to
tackle
this.
I
guess
and
there's
actually
an
issue
that
somebody
opened
before
we
opened
our
epic,
which
suggested
this,
and
maybe
this
could
be
an
approach
like
basically
make
projects
hierarchical
and
then,
at
the
end,
just
replace
groups
with
projects
somehow.
E
And
then
the
other
one
would
be
like
pick
one
feature:
that's
only
available
on
the
project
level
and
try
to
brought
it
to
the
group
level,
but
without
duplication,
and
I'm
not
sure
if
that's
actually
possible.
But
it
could
just
be
like
an
experiment
that
it
might
take
a
while.
I
guess,
but
like
try,
basically
the
same
with
doing
like
for
groupings
right
now,
but
like
try
to
do
it
in
a
cleaner
way,
where
it's
not
really
coupled
to
either
project
or
group,
but
like
the
namespace,
for
example.
D
D
D
E
I
mean
it
will
probably
turn
into
an
epic
already
with
multiple
issues.
So
maybe
experiment
is
not
the
right
one.
It's
more
like
a
like
a
spike,
maybe
or
something,
but
probably
at
least
a
week.
Maybe
I
don't
know
strictly
maybe
it'd
also
be
good,
if
maybe
more
than
one
person
would
work
on
it,
and
I
think
the
goal
should
not
be
to
actually
get
something
merchable,
but
just
to
explore
how
how
feasible
this
actually
would
be.
But
I'm
not
sure
okay.
B
I've
found
there's
different
cases
depending
on
what
you
want
to
port
to
the
group
level
yeah,
it's
kind
of
there's
various
cases,
I'm
not
sure
I
like
the
idea
of
just
taking
a
run
at
it,
but
I
think
there's
various
cases,
so
it
would
only
apply
to
each
specific
case.
E
D
C
Yeah,
so
I
was
kind
of
thinking
along
the
same
lines
as
marcus,
and
I
was
trying
to
break
it
down
into
what
is
the
smallest
thing.
We
could
do
that
we
could
also
verify
and
check
to
see
if
it
works,
and
so
what
I
ended
up.
I
kind
of
had
two
areas
at
the
top.
C
I
was
on
the
track
of
there's
two
things
I
see
like
one
is:
let's
have
groups
and
projects
behave,
the
same
ways
like
similar
settings,
similar
functionality
on
the
name
space
and
then
the
lower
track,
which
I
didn't
get
into,
is:
let's
create
a
new
type
of
connection
that
allows
entities
to
report
to
each
other.
So
like
one
is
the
access
side
and
like
the
rolling
up-
and
the
other
is,
I
just
said
duping
settings
between
the
two.
C
What
I
was
thinking
is
potentially
dupe
all
non-resource
settings.
First,
like
look
at
the
settings
panel
for
a
project
in
a
group.
C
The
smallest
thing
we
could
do,
maybe
is
to
have
those
be
identical
other
than
like,
adding
on
resources
like
mrs
or
designs
or
things
like
that,
and
then
move
into
kind
of
as
marcus
was
saying,
choose
one
thing
like
either
enabling
integrations
at
group
level
or
designs
at
group
level,
or
something
that
we
could
bite
off.
That's
small.
The
first
step
with
a
resource
would
be
the
next.
C
C
E
C
C
That
would
be
a
resource
setting
that
I
would
say
we
wouldn't
touch
immediately
like
moving
mrs
to
the
group
level,
but
a
setting
like
visibility
or
more
like
I
guess
the
more
generic
settings
would
be
brought
together.
So
they're
the
same
before
we.
D
Okay
and
again,
you
know,
if
you
think
of
a
question
later,
you
can
come
back
to
this
board
and
drop
it
in
just
if
you
do
you
can
in
I'm
in
I'm
sharing
my
screen,
but
you
know
you
can
say
at
kristen
and
then
kristen
will
get
notified.
D
That's
cool,
okey-dokey,
okay,
marcus
and
kristen.
I
appreciate
you
going
first
before
we
move
on
so
mark,
marcus
and
kristen
have
to
drop
very
soon.
Does
anyone
have
any
questions
or
feedback
from
marcus
or
kristen
before
we
move.
D
D
F
Perfect
and
yeah,
so
some
of
my
ideas
were
around
simplifying
groups
and
projects
by
making
them
back
by
the
same
implementation.
This
is
something
we've
spoken
about
in
a
bit
of
detail
on
already
and
so
that
implementation
would
probably
be
what
we
call
name
spaces
at
the
moment,
but
we
wouldn't
necessarily
reveal
that
term
to
users,
and
once
you
create
this
namespace,
if
it's
a
group
or
project,
you
can
easily
add
resources
to
that.
F
When
I
say
resources,
only
things
such
as
wikis
issues
repositories
even
and-
and
you
can
kind
of
like
configure
them
as
you
as
you
wish-
actually
have
complete
control,
and
ideally
I
guess
you
would
probably
want
some
sort
of
like
wizard
or
template
on
creation,
which
helps
you
choose
the
correct
resources
for
what
it
is
you're
trying
to
achieve.
Are
you
trying
to
create
a
software
project?
Are
you
trying
to
create
a
support
repository?
F
I
mean
what
are
you
doing
and
therefore
it
will
just
automatically
give
you
like
a
base
of
what
should
be
included,
and
I
I
also
think
that
there'll
be
value
in
introducing
the
term
teams
and
just
to
like
make
it
clear
to
users
the
difference
or
at
least
kind
of
like
the
theoretical
difference
between
your
project
hierarchy
and
your
like
organizational
team
hierarchy
and
how
that
is
implemented
is
an
open
question
that
could
also
be
backed
by
name
spaces.
F
So
it
could
be
backed
by
the
same
things
that
groups
and
projects
are,
but
ultimately
it
would.
It
would
be
a
distinct
term.
I
think
users
would
know
about
to
kind
of
like
change
the
way
that
they
think
about
our
group
hierarchy
and
also,
I,
I
think
that
I
I
haven't
heard
like
strong
reasons
so
far
like
why
our
permissions
hierarchy
wouldn't
remain
the
same
as
it
does
today
in
terms
of
it's
kind
of
top
down,
and
I
think,
where
possible,
we
I.
F
I
think
it
would
be
best
to
keep
that
because
it
simplifies
a
lot
of
things
rather
than
kind
of
like
having
this
matrix
matrix
based
permission
system
where
people
could
still
see
stuff
across
hierarchy.
I
think
that
starts
to
make
things
quite
quite
tricky,
so
yeah
there's
some
of
my
thoughts.
I
I
shared
some
of
this.
I've
got
a
minute
left,
I'm
gonna
be
able
to
do
a
quick
screen
share.
I
like
I'll,
add
more
time.
William,
don't
worry.
D
G
G
F
So
I
won't
go
into
an
immense
amount
of
detail
on
this.
I
shared
it
in
the
channel
before
and
it
was
a
good
discussion
with
with
gabe
around
this,
but
this
is
kind
of
like
a
basic
idea
of
how
things
could
look
so
like
the
whole
hierarchy
is
just
based
by
everything
being
a
namespace
and
we
introduce
the
concept
of
teams.
F
So
you
create
your
people
as
as
teams
and
team
members
and
access
is
granted
still
by
membership,
and
you
can
add
teams
as
members
to
different
areas,
and
you
can
basically
decide
given
what
your
namespace
is.
You
can
decide
what
you
want
switched
on
and
switched
off,
and
so
it
might
be.
For
some
reason
I
don't
know
you
don't
want
issues
in
one
particular
area.
It
might
be
in
a
in
another
scenario.
You
do
want
issues
to
be
enabled,
and
in
this
case
as
well.
F
I
also
show
an
example
of
how
you
can
maybe
like
share
a
particular
issue
with
like
a
user
like
somebody
outside
your
group.
So
it
shows
how
maybe
you
can
override
how
how
permissions
works,
but
yeah
I'll
probably
stop
with
the
detail.
At
that
point,.
D
Okay,
I
think
I
put
a
link
to
the
correct
slack
conversation
on
your
work
area.
There.
D
Could
you
would
it
be
possible
liam?
Oh
actually,
what
I'll
do
is
this
okay,
I'll
stop
blabbering?
Does
anyone
have
any
questions
or
feedback
for
liam.
E
F
Yeah,
I
think
that
was
kind
of
like
the
open
question,
and
I
think
that
maybe
is
where
you
do
need
a
bit
of
that
sort
of
like
matrix
permission
system.
So
you
can
see
stuff
across
across
sibling
and
I
think
that's
something
worth
like
drilling
into
more
more
detail
on.
I
think
we
also
discussed.
I
think
the
introduction
of
teams
isn't
like
an
absolute
hard
requirement
to
make
all
of
this
work,
because
you
can
kind
of
introduce
the
same
by
just
having
a
group
at
the
moment,
which
is
a
list
of
members.
F
And
I
ran
into
a
real
issue
last
week,
but
we
now
have
the
manage
stage
set
up
in
gitlab
like
by
the
organizational
hierarchy,
and
I
wanted
to
create
an
issue,
and
I
just
was,
I
spent
about
two
minutes
looking
to
see
how
I
could
create
an
issue
in
a
group.
Now
I've
used
gitlab
for
18
months
nearly
two
years,
and
I
still
that
just
wasn't
intuitive
to
me
immediately
and
then
I
realized
I
had
to
create
a
general
discussion
project
so
that
we
could
actually
start
having
a
discussion
as
a
team.
So
it's
just.
G
D
Let's
see
we
have,
we
have
a
link
to
a
slack
conversation
and
we
have
a
grab.
I
took
a
screen
screen
grab
of
your
diagram.
Are
there
any
epics
or
issues
related
to
this
approach
that
we
could
also
share
in
here.
F
I
don't
I
don't
know
if
we
have
much
by
way
of
like
the
team
set
up.
To
be
honest,
I
I
think
there
probably
is
some
stuff.
Well
there
definitely
some
stuff
that
alex
has
been
working
on
around
some
some
work
to
kind
of
condense,
everything
down
to
to
a
name
space.
B
Sure
can
you
zoom
in.
I
can't
see
that
excellent
sure
thanks.
So
so,
mine
are
sort
of
two
ends
of
the
same
spectrum.
One
is
that
we
we
aggregate
projects
and
groups
into
one
big
entity
in
the
same
way
that
you
sort
of
operate
with
jquery
if
anyone's
familiar
with
jquery,
where
in
jquery
everything
is
sort
of
a
jquery
object.
So
you
make
a
query.
B
You
call
a
method
on
this
jquery
object
and
it
just
sends
you
back
another
jquery
object
and
you
just
keep
going
and
you
can
you
can
change
calls
really
easily
and
and
it's
sort
of
in
a
similar
sense.
If
we
combine
groups
and
projects
you
kind
of
just
get
both
of
the
features
from
groups
and
projects
in
the
one
sort
of
super
blob.
B
And
on
the
other
end
of
that
spectrum
is
that
we
destruct
groups
and
projects
where
you
take
all
those
sort
of
resources
off
projects,
and
you
turn
them
into
their
own
things,
which
I
think
is
sort
of
similar
in
line
with
what
liam
just
went
through
and
you
sort
of
toggle
various
bits
and
pieces
on
and
off
as
you
need
them
and
connect
them
up
to
the
various
sort
of
teams
or
groups
as
you
need
them.
B
I
think
at
the
moment
the
the
current
architecture
of
groups
and
projects
kind
of
is
in
this
gray
area,
where
it's
we
sort
of
have
features
in
some
bits,
sort
of
behaviors
in
in
projects
that
we
want
in
groups
and
behaviors
of
groups
that
we
want
in
projects
and
we
kind
of
duplicate
them
and
we're
kind
of
in
between.
I
think
that
if
we
went
one
way
or
the
other
way,
either
aggregate
everything
or
destruct
everything
deconstruct
everything.
D
All
right,
and
did
you
say,
alex
that
this
idea
to
destruct
to
drop
projects
and
decouple
entities
is
similar
to
what
liam
proposed.
B
Yeah
similar,
but
but
for
me
it's,
I
guess
liam
sort
of
has
a
specific
solution
there,
whereas
I'm
sort
of
more
general
just
along
that
sort
of
that
axis
of
aggregating
versus
destructing.
On
the
other
end,
really
I'm
sort
of
more
general
in
that
I'm
not
exactly
sure
what
shape
that
would
take,
but
sort
of
just
the
general
principle
of
taking
the
wikis
off
taking
the
labels
off
issues,
merge
requests
whatever
else
and
turning
them
into
their
own
things,
and
that,
for
me,
is
sort
of
the
key
bit
of
that
card.
D
D
Oh,
did
he
okay
yeah?
Oh
that's
right
because,
yes,
kristen
and
marcus
dropped,
okay,
so
I'll
kind
of
the
reason
I
asked
marcus,
that
is,
he
proposed
a
sort
of
experiment,
method
and
exploration.
D
Have
have
we
done
an
exploration
on
on
this
concept?
You
know
either
from
from
where
you're
you're
looking
at
it
alex
or
from
where
for
liam's
from
where
liam's
approaching
it
have
we
spiked
on
any
of
that.
D
B
I
don't
think
so.
I
know
that
marcus
has
started
to
port
the
wiki
from
projects
into
groups.
I've
got
a
conversation
lined
up
with
him
next
week.
I
think
that
it
sort
of
might
lend
some
ideas
as
to
whether
we
can
sort
of
pull
it
out
into
its
own
thing.
B
Yeah,
that's
right
so,
like
a
wiki
is
the
most
obvious
for
me.
So
a
project
has
a
wiki,
but
then
you
could,
a
group
could
have
a
wiki
or
a
user
could
have
a
wiki
or
there's
a
whole
bunch
of
different
purposes,
and-
and
I
think
that's
sort
of
a
lot
of
that
problem
that
we're
finding
where
we
want
things
to
go
from
projects
to
groups.
It's
actually
like
it's
actually
just
this
generic
resource
that
can
be
pinned
to
anything.
It
just
depends
on
the
context.
I
think
they
are
kind
of
standalone.
F
F
B
Yeah
resources
is
pretty
generic,
I
think
just
when
I
was
looking
at
I
am.
I
am
today
from
aws.
They
use
resources
to
sort
of
refer
to
what
we're
referring
to
resources
as.
B
Yeah,
I
mean
it
sort
of
has
to
encompass
so
many
different
things
that
it
kind
of
becomes
so
generic
yeah.
So
just
just
very
quickly,
as
I
went
through
the
project
model
today
and
listed
some
things
that
I
thought
we
could
carve
off
into
sort
of
that
might
be
candidates.
I
didn't
give
much
thought
to
this,
but
you
know
so.
A
project
has
a
repository
issues.
D
When
you
say
they
can
fall
into
their
own
stand
along
stand-alone
objects,
can
you
tell
us
a
bit
more
about.
B
That
yeah,
so
so
a
project.
I
don't
really
know
what
a
project
is.
A
project
is
kind
of
a
aggregation
of
of
all
those
resources
that
sit
underneath
the
project,
but.
B
I
think
at
one
time
a
project
would
have
just
meant
maybe
a
repository
with
some
issues
and
it's
kind
of
grown
from
there.
So
something
like
a
repository.
Why
do
I
need
a
project
to
have
a
repository?
I
just
want
various
repositories,
I
want
to
add,
maybe
some
people
to
it
that
they
can
commit,
or
they
can
pull
code.
B
Liam
liam
and
I
discussed
earlier-
or
he
mentioned
in
this-
call,
actually
that
he
wanted
issues
on
a
group
so
group
specific
issues.
You
know
why
do
I
need
a
project
for
an
issue?
I
think
the
assumption
at
the
time
would
have
been
that.
Well,
the
project
has
a
repository
because
we're
talking
about
code
because
it's
gitlab
and
then
we
want
some
issues
associated
with
that
repository,
but
we've
kind
of
moved
on.
From
that
point
labels
labels
are
used
already
in
various
places
and
they're
kind
of
just
polymorphic
by
nature.
F
All
and
another
example
there
I
know
we've
discussed
this
before
alex
is
how
issues
belong
to
projects
and
they
belong
to
projects,
because
description
templates
come
from
the
repository,
so
there's
quite
a
lot
of
coupling
between
how
an
issue
is
related
to
a
project
which
has
a
repository
which
might
have
some
markdown
files
in
it,
which
generate
your
issue.
Descriptions
now
you
can
argue,
there's
value
in
how
that
works.
But
if
we
start
separating
things
out,
I
think
we'd
need
to
think
about
those
details
and
well
those
things
in
a
bit
more
detail.
I
For
what
it's
worth,
we
already
want
to
decouple
those
out
and
not
have
templates.
I
mean
because
we
want
group
level.
People
want
group
level
templates,
they
want
epic
templates,
they
want
workflow
templates
and,
like
there's
an
issue
I'll
try
to
dig
up
somewhere
and
add
to
the
comments
about
that,
but
yeah.
I
I
think
them
it's
wonky
right
now,
when
I
go
into
settings
and
like
I
want
to
set
my
insights
for
my
top
level
group
and
I
have
to
pick
a
project-
that's
like
way
down
stream,
because
that's
where
the
ammo
file
is,
you
know
like
that's
just
I
don't
know
it
is
unnecessary
decoupling.
I
think,
in
a
certain
fashion,
but.
F
D
Made
okay
all
right,
let's
keep
moving,
so
everyone
has
been
heard:
let's
go
to
melissa,
you're
up,
melissa.
H
So
a
lot
of
my
stuff
is
the
same
things
that
alex
and
liam
have
been
talking
about.
I
actually
think
a
lot
of
the
complexity
comes
from
just
sort
of
using
groups
for
a
lot
of
different
things
right
and
when
you
do
that
it
sort
of
becomes
complicated,
to
explain
and
manage
right,
because
a
group
is
not
just
for
one
thing:
it's
for
you
know
like
six
seven
different
things
today,
so
I
think
part
of
simplifying
groups
and
projects
is
sort
of
pulling
out
pieces
of
functionality.
H
That
groups
serve
today
into
their
own
kind
of
smaller
object
and
that
kind
of
goes
into
a
little
bit
of
what
liam
was
saying,
like
teams
for
like
permissions
and
people
groupings
right
having
that
be
its
own.
Very
small
single
purpose
thing
right
same
thing,
with,
like
a
top
level
container
right
to
kind
of
delineate
what
an
orga
is
right.
H
Having
that
be
its
own
standalone
thing
that
we
use
groups
for
today
and
then
once
you
do
that
what
you're
left
with
for
groups
and
projects
is
managing
resources
right
then
you
can
make
them
very
specialized
for
that
and
basically
making
it.
So
you
can
manage
resources
within
groups
and
projects
the
same
and
stack
them
right.
H
If,
if
you
want
them,
if
you
want
to,
for
you
know
hierarchical
purposes,
to
display
your
or
whatever
reason
you
want
to
do
that
for
and
then
basically
being
able
to
turn
on
and
off
certain
parts
of
groups
and
projects.
If
you
want
and
then
I
think
that
makes
it
a
lot
easier
to
understand
what
things
are
for
right
and
I
think
it'll
also
help
in
just
kind
of
like
customers
intuitively
knowing
what
to
do
versus
someone
having
to
explain
it
because
you
have
more
objects
but
they're,
each
smaller
and
more
specialized.
D
Okay,
I'm
I'm
seeing
a
pattern
of
this
like
deconstruct
things,
so
that's
good
just
want
to
call
that
out.
There's
a
sort
of
convergence
happening,
any
questions
for
melissa
or
feedback
before
we
go
to
get.
G
F
Let's
say
obviously
we're
in
agreement.
There
reminds
me
of
another
conversation
we
I
had,
I
think
with
gabe
when
I
shared
my
diagram
around
like
gitlab's,
take
on
small
primitives
and
I
think
generally
that's
a
good
concept
like
using
one
thing
or
multi-purposing
one
thing
to
get
as
much
value
out
of
it
as
possible,
and,
having
said
that,
I
think
it
gets
to
a
point
where
it
might
do
more
harm
than
good.
F
So,
like
user's
understanding
of
what
a
group
is,
if
you
then
want
to
create
kind
of
member
management,
you
also
have
to
create
a
group
and
also
kind
of
a
group
represents
an
entire
company.
It
represents
software
projects,
so
I
think
identifying
those
areas
where
maybe
those
small
primitives
in
the
background
could
all
still
be
those
small
permanent
primitives
which
maybe
are
a
name
space,
but
knowing
the
right
areas
where
we
need
to
say
hey.
F
Actually,
we
need
to
call
this
out
explicitly
as
something
else
the
customer
such
as
an
organization
such
as
a
team.
I
think
it's
quite
important
for
simplicity,.
B
D
Is
that
sort
of
a
solution
proposal
alex
is
to
like
first
see
what
we
can
change
on
the
ui
and
see
if
we
can
achieve
this
goal
of
familiarity
rather
than
trying
to
make
some
big
refactoring
on
the
back
end?
Is
that
kind
of
what
you're
proposing.
B
It
might
be
part
of
the
solution
yeah.
I
think
that
I
think
that
teams-
you
could
just
sort
of
re-label
groups,
as
teams
at
the
moment
and
you'd
sort
of
make
a
lot
of
progress.
H
B
H
B
Yeah
and
I
think
perhaps
a
lot
of
that
at
least
the
first
step
just
happens
in
the
ui.
I
I
think
you
can
do
a
lot
of
that.
I
think
you
could
do
a
lot
of
that,
but
only
once
you
have
the
namespace
and
some
things
merged
into
a
namespace,
and
then
you
can
reuse
the
namespace
and
have
like
different
ui
things,
because
I
think
part
of
the
core
problem
is,
if
you
just
use
groups-
and
you
call
those
teams-
you
still
have
you
can't.
The
team
can't
do
issue
management
at
the
team
level.
I
Like
can
what
leave
was
saying
like
you
have
to
create
a
project
just
to
hold
issues,
and
then
you
still
have
the
disconnect
between
like
epics
at
the
team
level
and
issues
at
the
project
level
and
like
the,
but
I
think,
once
you
put
all
the
entities
or
resources
in
the
single
name
space,
then
you
can
use
that
namespace
to
have
like
a
team's
ui
thing
and
the
project
management,
ui
thing
and
an
assets
ui
thing.
I
F
B
F
As
you
said,
gabe
like
it
would
be
probably
confusing
if
you
just
created
a
team
right
now
and
it
looked
exactly
the
same
as
a
group
and
it
was
limited
as
a
group
is,
but
if
you
could
create,
if
the
first
situation
was
to
create
a
team
which
is
back
by
namespace
and
has
this
new
functionality
that
it
has
limited
resources
in
it.
So
it
only
has,
for
example,
members
and
issues,
and
maybe
that's
a
good
first
way
to
say.
F
D
Approach,
I
I
heard
someone
say
like
a
road
map
to
get
to
where
we
want
to
be
part
of
part
of
this.
The
solution
generation
is
to
get
ideas
like
the
one
that
I
think
we
just
converged
on,
and
it's
actually
somebody
could
write
on
a
post-it
like
what
that
convergence
just
was
that
would
that
would
be
really
helpful.
D
What
where
what
we
want
to
do
with
these
ideas
is
actually
do
what
someone
just
mentioned,
which
is
like
create
sort
of
a
road
map
like
first.
We
do
this
so
that
then
we
can
do
this,
and
each
step
is
an
mvc.
D
I
want
to
get
us
to
a
point
where
we
can,
where
we
can
do
some
prioritization
by
user
value
and
level
of
effort,
and
so
we
would
take
these
ideas
and
we'd
probably
have
to
do
some
kind
of
voting
or,
like
maybe
generate
some
more
post-its
and
put
them
on
here
and
then
axis
where
we
can
talk
about
level
of
effort
and
user
value,
and
ideally
we
would
prioritize
the
things
like
in
the
top
left
that
have
high
user
value
and
over
to
the
right
of
less
effort.
D
D
I
think
breaking
that
down
into
smaller
steps
and
prioritizing
would
be
a
good
next
step,
and
I
don't
think
we
have
time
for
that
today,
but
I
think
now
that
we
have
this
mural
board.
We
have
some
some
like
continuity.
I
think
where
we
could
theoretically
do
that
next
week
and
theoretically
do
it
within
the
half
hour
that
we
usually
have
allocated
for
this.
D
So
but
before
we
go,
I
want
to
make
sure
everyone
gets
a
voice
and
that
gabe
gabe
gets
a
chance
to
talk
through
stuff
too,
and
I
apologize
gabe
that
we're
like
right
up
we're
pushing
it
really
hard,
but.
D
I
Really
fast,
okay,
I
think
it's
kind
of
building
on
a
lot
of
what
we've
talked
about
already,
but
it's
it's
like
a
configurable
workspace
that
can
be
used
to
store
any
type
of
resource.
Then
we
have
one
click
templates,
basically,
that
let
you
configure
your
workspace
based
on
use
cases
and
use
your
use.
I
Cases
like
I
want
to
use
this
for
project
management,
and
maybe
it's
like
a
little
wizard
that
you
answer
a
few
questions
and
then
it
sets
up
your
workspace
with
all
the
resources
that
you
would
likely
need,
and
then
you
can
always
go
enable
them.
If
you
want,
I
was
suggesting
doing
that
within
the
namespace
as
well,
because
I
did
explore
graphql
api
a
little
bit
and
trying
to
solve
another
problem
and
realize
that
we
had
namespaces
in
there.
I
We
have
groups
and
we
have
projects
and,
like
I
just
didn't
understand
why
everything
wasn't
under
a
name
space.
To
begin
with,
I
thought
that
was
really
confusing
and
then,
like
the
the
workspace,
is
like
I
kind
of
take
a
people
first
approach
and
believe
that
resources
or
entities
should
be
structurable
in
an
accessible
way.
Just
like
people
structure
themselves
and
how
businesses
structure
themselves
so
like
you
could
have
a
a
graph
model,
but
also
some
inheritance
properties,
and
if
you
click
on
that
link,
it's
right
there
like
I.
I
I
use
this
a
lot
in
understanding
or
like
I'm,
I'm
an
organizational
theory
geek
to
a
certain
degree
and
there's
like
nine.
I
think
primary
organizational
structures,
the
way
that
companies
work
and
if
you,
if
we
think
about
being
able
to
allow
this
name
space,
to
be
configured
in
a
way
that
maps
to
these
nine
and
supports
these
nine
different
organizational
types.
Then
then
we're
sort
of
like
if
it's
flexible
enough
to
be
able
to
do
that,
then
it's
gonna
meet.
I
You
know:
100
percent
of
use
cases
basically
or
at
least
more
than
80
percent
of
how
people
want
to
set
up
git
lab
and
like
allow
them
to
create
like
this
organizational
structure
for
their
people
and
if
you
solve
it
for
the
people,
then
you're
also,
naturally
going
to
solve
it.
For
the
the
other
resources
that
you
want
to
have.
Maybe
like
is
a
separate
part
of
it
or
separate
nodes.
I
I
So
in
a
name
space
I
want
to
be
able
to
trigger
a
workflow
in
a
subname
space,
one
that
then
triggers
workflow
in
a
subname
space
too,
like
thinking
about
the
flow
of
information
and
how
different
actions
and
different
name
spaces
can
more
or
less
trigger
things
happening
in
other
places,
not
just
within
like
ci
cd,
but
also
in
like
things
like
issue,
management
or
dependency
management
or
whatever.
I
So
I
think
it's
a
good
model
when
I
think
about
what
I,
how
I
want
to
organize
name,
spaces
and
sub
name
spaces
and
have
relationships.
I
think
we
should
look
to
how
companies
organize
themselves.
I
D
That's
that's
really
helpful
article
I'm
going
to
go
back
and
read
that
in
detail.
Also,
do
you
think
liam's
is
sort
of
a
hybrid
right
of
of
what
teams
and
divisions
or
would
you
characterize
it
in
another
way.
I
No,
I
I
think
it
is,
I
think,
as
long
as
you
have
like,
the
namespace
can
have
things
that
are
turned
off
and
on
right,
because
I
could
also
see
some
teams
are
going
to
want
to
have
their
own
repo.
They
might
want
to
have
their
own
pages.
They
might
want
to
have
like
some
of
these
different
things
within
the
team
itself,
just
for
that
team
right,
and
they
might
also
have
issues
that
they're
working
on
for
a
product
area
that
are
part
of
that
product.
I
But
just
I
think
that's
why
it's
important
to
have
the
kind
of
graph
model
so
that
you
can
see
things
that,
like
there
is
a
single
source
of
truth
for
everything
that
your
team
is
working
on
and
like
that
is
within
your
team
right,
but
also
being
able
to
surface
that
in
the
places
where
you're,
making
these
changes
and
making
it
so
that
other
people
can
collaborate.
I
guess,
but.
D
F
I
also
feel
there
might
be
value
as
a
group
in
going
through,
like
some
detailed
scenarios
of
what
gabe
just
spoke
about
in
terms
of
how
matrix
organizations
expect
this
to
work
like
as
we've
spoken
about
before
how
people
want.
Maybe
visibility
from
sibling
groups
in
the
in
the
hierarchy
and
how,
whatever
solution,
we're
coming
up
with
how
it
will
solve
that
problem.
D
Okay,
I'm
going
to
put
that
as
a
next
step
and
it
seems
like
the
size
of
the
globe
all
right
next
step
possible
next
step.
This
isn't
set
in
stone
research
with
customers
to
see
which
type
of
org
structure
they
generally
follow,
and
in
order
to
research
this
do
we
have
any
assumptions
that
we
can
test
around.
This
idea
really
quick
like
what
type
of
work
structure
do
we
believe
customers
generally
follow,
which
or
which
one
do
you
think
we
could
support
with
an
mvc?
I
I
would
say
that
the
hierarchical
structure
is
the
most
dominant
and
large-scale
organizations.
I
think
they
might
actually
be
yeah.
I
I
know
that
that's
the
case
and
then
I
think
the
matrix
structure
is
probably
the
second
most.
D
I
think
we
have
hierarchical
with
the
mind
managers
and
then
matrix
structure.
D
Okay,
yeah
I'll
put
it.
Let's
put
a
pin
in
that
just
because
of
time,
not
because
it's
unimportant
okay,
so
we
have
a
couple
options
for
when
we
come
back
together,
one
is
we
could
we
could.
I
Justin
either,
what's
that
I
was
saying
just
justin
put
some
stuff
down
and
we
shouldn't
forget.
A
Is
mostly
duplicative
of
what
we've
already
discussed,
so
I'm
I'm
excited
that
we're
coalescing
anyway.
I
also
put
some
comments
in
case
people
read
async,
but
I
we
can
skip
me.
I
don't
there's
nothing
of
unique.
A
D
Good
and
trying
to
rush
sorry
about
that.
It
happens
when
we
rush
things.
Okay,
so
one
one
possible
next
step
is
to
break
this
down.
D
And
prioritize
what
we
broke
down,
we
could
we
could
do
that
and
then
we
could
also
talk
more
about
this
path
of
validating
types
of
org
structures.
This
type
of
talk
about
more
about
what
type
of
word
structures
we
want
to
support,
I
think
maybe
like
offline
like.
Maybe
a
small
group
of
people
could
decide
the
next
step
or
we
could
talk
about
it
in
slack.
A
D
A
great
idea
all
right
again
sorry
about
the
rush
toward
the
end
here.
Thank
you,
everybody
for
tolerating
me
and
participating.