►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Yeah,
so
I
came
up
with
a
couple
ideas:
valerie
had
happened
to
ask
for
issues
to
look
at
to
provide
feedback
last
friday,
so
I
had
asked
for
her
thoughts,
but
my
first
idea
was
use
the
component.
Basically
just
as
is
maybe
change
up
the
button
variant
slightly,
and
so
it
would
be
something
like
you
click
it.
You
can
enter
your
destination
url.
This
would
be
the
same
like
component.
You
do
for
adding
an
issue
link
essentially
hit.
A
Add
you
get
a
list
of
items,
you
can
add
status,
symbols
in
there
or
badges
for
the
response
that
we
get
back
and
it
would
go
back
to
its
default
state
so
essentially
just
out
of
the
box
how
it
works
today
for
related
issues,
but
the
problem
is
for
me:
I'm
like
well,
users,
don't
actually
know
what
to
do
with
just
this
empty
streams
component,
so
my
first
thought
was
well,
let's
add
the
ability
to
have
like
an
empty
state,
since
the
whole
page
is
dedicated
to
this
anyways
I'll.
Let
that
load.
A
So
something
like
this.
I
mean
this
is
definitely
not
like
a
finalized
design
by
any
means,
but
valerie's
feedback
on
this
specifically
was
there's
some
unboxing
opportunities
here,
which
I
like
agree
with,
but
the
struggle
with
a
shared
component
if
we
were
both
using
it
like
for
streaming
audit
events,
but
also
for
related
issues,
is
where
we
impact
the
design
for
one
area
will
also
impact
the
other.
A
So
just
trying
to
weigh
the
pros
and
cons
of
that.
I
was
also
considering
putting
it
all
into
a
single
page,
but
I
really
didn't
like
how
this
kind
of
like
overloads
the
user
in
terms
of
there's
no
specific
focus.
It's
just
a
lot
of
content
all
at
once
I'll
give
a
figma
a
quick
second
to
load
here,
yeah.
So
it's
just
like
I
could
have
both
things
on
the
same
page,
but
it
just
feels
like
a
lot
of
content
to
be
sharing
and
for
what
it's
worth.
A
I've
seen
other
sites
break
this
up
against
a
tabular
view
as
well,
so
I'll
pause
there
and
ask
alexis
like
what
are
your
thoughts
about
me?
Encouraging
the
use
of
the
related
issues,
input.
B
Yeah,
I
think
I'd
have
to
look
more
into
the
flow
of
what
a
user
is
trying
to
do
here
like
every
single
like.
Are
they
adding
like
creating
new
objects?
Are
they
like
managing
them
and
deleting
them
often,
I
would
think
not,
but
just
fyi.
That
is
something
not
like
super
soon,
but
we're
looking
into
improving
this
little
widget
to
make
it
kind
of
more
like
the
epic
tree.
So.
C
B
D
A
A
B
But
like
near
term,
I
think
that
could
make
sense
just
to
kind
of
test
this
out,
and
I
agree,
like
a
million
percent,
that
an
empty
state
is
needed
if
it
needs
to
be
shared,
maybe
something
a
little
bit
more
generic
right.
A
Yeah
yeah,
that's
a
great
question
about
like:
are
they
gonna
be
adding
and
removing
things
frequently?
So
no
none
of
this
is
technically
stored
in
gitlab
per
se.
It's
more
like
creating
a
logical
destination
point,
so
I
guess,
what's
locally
stored
would
be
just
the
connection
and
then
the
fact
that
these
things
are
connected
and
they
should
be
sending
data
to
it.
I
think
they
would
want
more
functionality
eventually
like,
for
example,
like
web
hooks,
you
can
send
different
payloads
to
test
how
it's
currently
receiving
stuff.
A
This
view
component
would
give
us
a
lot
of
the
interactive
states
that
we
would
need
just
to
get
the
foundation
in
place
essentially,
but
then
we
run
to
the
issue
of
well,
eventually,
it's
more
more
than
likely
that
the
way
that
issues
relate
to
their
other
issues
or
epochs
have
their
child
relationships
will
be
different
than
the
way
people
want
to
manage
streams.
But
you
know
is
that
a
problem
that
we
solve
a
different
day
and
we
stick
with
the
boring
solution
now
and
just
use
the
shared
component.
B
A
Yep,
that's
exactly
how
it's
done
the
api
right
now.
We
ask
them
for
two
things:
they
need
a
destination
point
and
they
need
to
know
their
group
id.
So
this
eliminates
the
need
to
know
your
group
id
because
you
would
be
adding
it
from
the
group
that
you
want
to
send
the
events
from.
So
all
we
need
to
know
is
where
you
want
this
to
go.
E
B
A
Yeah
so
I've
talked
to
our
front
end
and
our
front-end
team,
but
our
back-end
to
try
and
get
some
instrumentation
in
place
to
check
how
teams
are
doing
it
today.
I
think
I'm
gonna
go
off
top
my
head.
I
don't
think
we're
seeing
teams
use
more
than
five
destinations,
so
it's
probably
going
to
be
more
like
an
average
of
like
one
to
three
is
what
probably
most
people
are
doing.
So
I
don't
think
things
like
sorting
are
going
to
be
really
important.
I
think
it's
going
to
be
more
just.
B
A
A
So
I
one
of
the
things
I
highlighted
when
you're
adding
it
is
a
warning
that
you're
going
to
be
getting
all
of
your
audit
event,
data
which
can
be
either
sensitive,
personal
identifiable
information
potentially
or
it
could
be
really
high
data
volume
load
like
git
events,
can
be
really
heavy,
so
they
might
not
want
everything.
They
might
only
want
something
very
specific.
A
Because
we
do
technically,
we
do
log
a
number
of
things.
The
reason
why
we
introduce
like
the
streaming
feature
in
the
first
place
is
there
are
data.
Heavy
events
like
I
was
mentioning
like
git
events
like
git
push,
pull
clone.
That
can
be
very
transaction
heavy
that
we
can't
support
in
our
database.
So,
instead
of
telling
users
hey,
you
can't
have
this
data
at
all,
we're
saying
hey,
you
can
have
it
just
you
got
to
go,
take
care
of
the
data.
We
can't
manage
it
for
you.
Our
infrastructure
can't
scale
to
that
level.
A
Oh
just
to
be
clear,
this
was
like
an
alternative
design
that
I
don't
really
want
to
go
with.
I
was
just
using
this
to
jump
to
the
page
where
you
could
see
all
the
there's
a
event
table,
so
what
you're,
maybe
not
noticing
here
is
there's
a
log
page
and
a
streams
page.
So
log
page
would
be
your
data
table
of
all
the
events
that
get
lab
captures
automatically
and
can
show
you
in
the
ui.
Your
stream
would
be
where
you
send
all
of
your
event,
data
to.
A
You
know
I
it's.
I
was
also
debating
that,
like
oh
man,
just
they
want
to
probably
go
in
and
edit
the
url
slug
real
quickly,
because
you
don't
get
that
technically
right
now
with
related
issues,
you
gotta
just
delete
it
and
re-add
it.
I
think
that
would
be
fine.
I
think
in
the
api
right
now.
You
have
to
basically
do
the
same,
delete
it
and
re-add
your
destination.
A
E
A
Yeah
so
I'll
reframe,
my
feedback,
one
more
time,
maybe
I'll,
give
you
a
chance
to
jump
in
right
now.
The
event
data
that
is
captured
by
gitlab
is
presented
in
the
table,
but
it's
it's
missing
some
of
the
events,
because
our
infrastructure
can't
handle
them
so
we're
sending
that
date
we're
allowing
users
to
send
that
data
elsewhere.
This
has
been
made
available
through
our
api,
but
we
haven't
made
it
possible
to
set
up
that
destination
endpoint
in
the
in
the
ui.
A
A
Nope,
it's
sending
it:
okay,
yeah
we've!
It's
all
documented
in
our
well,
it's
document
in
the
docs,
but
yeah
there's
several
different
formats
in
which
you
can
send
data
outside
of
gitlab,
and
that's
outline
interdock.
E
You're,
basically
setting
up
a
connection
between
services,
ours,
yeah
and
wherever
it's.
I
I'm
reminded
when
you
were
talking
about
this
in
the
office
hours.
I
think
yeah
like
given
my
background,
a
credit
card
like
you're
sure
you
are
currently
sharing
your
data
with
mint
and
it's
you
know
I
set
that
connection
up
cool,
I'm
good.
E
Those
two
services
are
talking,
for
whatever
reason
I've
set
up
for,
but
but
when
you
were
talking
about
this,
like
my
I
I
like
the
I
like
the
the
boring
solution.
Honestly,
I
think
that
it's
it's
a
great
way,
at
least
in
an
nbc
sort
of
like
in
the
first
generation
like
like
that's
where
we
can
go
with
it.
E
A
Yeah
yeah,
you
could,
I
think,
that's
where
my
my
tension
lies
in
is,
I
think,
I'm
maybe
a
little
bit
scared
to
use
a
shared
component
in
such
a
different
context,
because,
hey
if
you,
if
unknowingly
the
project
planning
team,
makes
a
change
to
that
component,
it
will
impact
us,
and
so
that's
that's,
maybe
where
my
hesitancy
comes
in,
but
I
also
like
well,
we
already
built
this
whole
shared
component
in
view
today.
Why
would
we
not
reuse
something?
That's
basically
doing
the
same
thing,
at
least
as
mvc?
C
Are
there
always
going
to
be
multiple
decimate
destinations
that
you
send
it
to?
Could
an
mvc
just
be
like
a
single
one.
A
C
C
Like
my
instinct,
but
then
again,
I'm
biased,
coming
from
from
analytics
and
and
from
workspaces
is
just
to
whack
it
in
an
inline
editable
table.
It
doesn't
need
to
be
fancy
like
in
that
table.
You
can
just
have
the
the
you
know:
the
input
destination,
url
input,
components
and
then
like
rows,
and
then
you
can
press
the
button
and
it
just
adds
a
row.
I'm
sure
like
it
should
be
relatively
easy
to
configure
that,
since
we
have
the
table
as
a
component
already
as
well,
the.
A
Scene,
we
do,
we
do
have
the
table
component,
but
I
have
not
found
anything
in
storybook
to
suggest
that
we
can
edit
input
fields.
We
could
do
like
toggles
and
buttons,
but
there
hasn't
been
anything
with
input
fields
and
it
got
kind
of
messy
to
try
and
manage
the
like,
save
and
cancel
buttons
for
each
row.
A
C
C
You
look
at
value
stream
if
you
go
to
value
stream
and
then
the
the
edit
button
in
value
stream.
C
Here
to
do
that
at
the
sorry
at
the
at
the
group
level.
C
And
then
it
takes
you
to
the
group
overview
page
rather
than
the
actual
value
stream
page
yeah
you
go
to
edit.
So
this
experience
right
here
is
sort
of
a
little
bit
similar.
C
You
wouldn't
need
any
of
like
the
the
the
craziness,
but
you
could
basically
just
in
that
add
another
stage
and
then
it
yeah
it
gives
you
that,
and
you
can
add
another
stage
you
can
remove
that
like
you
can
just
make
a
form
on
the
page
which
effectively
does
that
sort
of
thing,
and
then
that
would
unbox
it
quite
a
bit.
A
A
Sweet
I'll
I'll
cook
it
over
to
you,
then,
because
I
think
you
have
the
next
point.
C
Sure
so
I
have
been
working
a
little
bit
on
the
hellscape,
that
is,
navigation
for
getlab
and
I've
been
doing
a
little
bit
of
thinking
and
basically
I've.
C
I've
sort
of,
I
think
I've
pinpointed
what
the
problem
with
navigation
is.
So
I'm
going
to
quickly
pitch
to
you
from
my
perspective
why
our
navigation
is
so
frustrating
to
so
many
users,
and
then
I'm
gonna
pitch
to
you
a
little
solution
which
I'm
not
necessarily
tied
to,
but
just
just
to
get
like
tangibly
like
how
we
may
approach
this
across.
C
Has
stuff
in
the
way?
Okay,
so
we
in
get
lab
have
two
dimensions
of
navigation.
We
have
the
dimension
of
the
sidebar
or
in
other
words,
the
the
features
that
gitlab
has
and
then
we
also
have
the
dimension
of
the
the
actual,
like
name
spaces,
the
containers
which
pretty
much
fit
within
this
menu.
C
So
if
you
think
about
it,
we've
really
optimized
our
navigation
to
allow
users
to
go
across
features
as
easily
easily
as
possible.
So
there's
everything
just
one
or
two
clicks
away
at
most.
C
However,
we
haven't
made
it
all
that
easy
to
navigate
across
namespaces.
You
need
to
go
into
this
if
you're
lucky
it'll
be
infrequently
visited,
but
that
changes
all
the
time
and
then
like.
Maybe
you
go
into
the
your
projects
section
and
then
you
can
navigate
through
all
these
sort
of
you
can
filter
by
name
or
you
can
go
to
your
starred
projects.
C
Basically,
it's
very
easy
to
navigate
through
features,
but
it's
not
so
easy
or
not
so
quick
to
navigate
through
namespaces
and
if
you
think
about
it,
users
tend
to
have
probably
a
small
subset
of
namespaces
that
they're
particularly
interested
in
compared
to
all
the
namespaces
that
are
available
for
them
in
their
broader
organization
or
instance
or
whatever.
That
may
be.
So,
for
example,
me
a
designer
within
gitlab,
I'm
in
stress
interested
in
gitlab.org
gitlog.com,
pajamas,
gitlab
ui,
this
sort
of
stuff.
C
So
this
is
my
hypothesis:
by
making
namespace
navigation
equal
priority
to
feature
navigation,
we'll
be
able
to
reduce
wayfinding
confusion.
So
I
think
a
lot
of
people
get
confused
as
to
where
they
actually
are
what
container
they're
they're
in
and
also
to
speed
up
across
namespace
workflows,
and
this
in
turn
should
help
to
have
a
tangible
impact
on
sus,
because
navigation
and
discovery
is
is
a
key
thing
here.
C
So
I'll
pause
there
at
the
sort
of
problem
statement
and
hypothesis
and
and
see
if
there's
any
questions
or
comments.
Anything
like
that.
A
I
definitely
would
say
I
experience
this
pain,
maybe
more
so
in
my
last
role
or
while
really
my
last
company,
I
should
say
I
primarily
get
loud
by
mostly
just
operating
gitlab.
There
are
rare
occasions
where
I
have
to
go
to
like
the
get
lab
design,
project
or
ux
research
project-
it's
rare,
but
it
was
more
painful.
A
My
previous
organization
was
like
every
single
app
that
we
worked
on
had
like
multiple
projects,
and
I
was
mostly
due
to
annoying
bureaucratic
rules
that
were
like
only
the
true
developers
could
have
access
to
the
project
with
the
code
repository
in
it.
They
couldn't,
they
didn't
want
the
designers
to
be
in
that
project.
F
A
Yeah
yeah
anyways,
I
was-
I
was
going
to
cap
that
off
by
just
saying
I
don't
know
if
it's
necessarily
an
issue
with
the
navigation
or
if
it's
users
trying
to
work
around
the
organization
of
the
product,
like.
I
wonder
if
one
is
causing
the
problem
of
the
other,
and
I
was
curious
if
you
thought
like
namespaces,
for
example,
or
rather
with
workspace,
if
that
would
resolve
some
of
the
navigational
challenges,
if
we
weren't
so
driven
by
having
to
go
into
different
groups
to
find
that
subgroup.
C
Okay,
let
me
try
it
I'll
pick
that
so
I
I
think
I
don't
have
all
the
information
I've
been
trying
to
look
for,
but
I
think
the
reason
that
we're
so
I
mean,
obviously
our
information
architecture
originated
with
just
like
the
project.
So
everything
just
sort
of
like
the
project
was
the
original,
like
the
original
organizing
construct
for
everything.
And
then,
since
there
were
like
oh
we'll
tack
on
some
groups
and
then
we
can
organize
some
projects
together.
C
So
the
challenge
that
emerged
by
creating
groups
separately
is
that
groups
have
different
features
than
than
projects,
and
that
means
that
there's
no
easy
way
to
like
have
a
consistent,
sidebar
or
a
consistent
set
of
features
between
projects
and
groups,
and
so
I
think
the
solution
was
to
hide
projects
and
groups
in
their
own
menu
and
then
from
there.
C
You'd
have
a
be
able
to
like
pick
up
a
different
sidebar
if
that
sort
of
makes
sense
so
with
namespaces
what's
useful,
is
we
now
have
this
opportunity
where
projects
groups
everything's
going
to
be
collapsed
into
one
thing,
and
then,
therefore
we
should
have
consistent
navigation
across
each
and
every
container.
That
may
be
slightly
restricted,
based
on
what
users
configure
their
their
name
spaces
to
actually
contain,
but
there's
a
level
of
consistency,
that's
afforded
by
namespaces
that
we
didn't
have
before.
C
So
that
means
that
we
can
bring
forward
namespace
based
navigation
to
be
like
a
first
class
navigation
right
alongside
features,
and
that
should
make
life
a
lot
easier
for
people
who
are
working
with
multiple
projects
whatever
it
may
be,
moreover,
because
namespaces
can
be
nested
within
each
other.
That
means
that
each
namespace
that
is
sort
of
a
parent
of
the
child,
one
aggregates
content
up
from
their
children,
meaning
that
you
can
see
a
lot
of
the
content
coming
up
from
the
child
child
name
spaces
alongside
one
another
and
I'll
dive
in
I'll.
C
C
Where,
like
I'm
in
issues
right
now,
and
then,
if
I
click
into
gitlab.org,
like
I'm
no
longer
in
issues,
it
just
takes
me
to
the
overview
page
so
and
then
it's.
C
C
So
in
this
case
we
have
the
feature
menu
as
we
know,
and
love
and
I've
moved
the
the
workspace
menu
over
to
the
side
here.
So
you
basically
have
namespace
times
features
equals
the
content
that
you're
seeing
here,
but
I'm
not
I'm
not
wedded
to
the
visual
design
at
all,
and
what
we
can
get
here
is
we
can
have
the
all
git
lab
view,
which
is
effectively
the
top
level
workspace
and
this
aggregates
all
the
content
up
from
from
from
the
name
spaces
below
it.
C
We
have
a
little
collapse
thing
going
on
here
as
well,
but
effectively.
What
we've
done
is
we've
sort
of
allowed
users
to
quickly
keep
the
context
of
the
feature
that
they're
in
so,
for
example,
gitlab
overview
and
switch
between
the
spaces
that
are
actually
important
for
them.
So
this
gives
you
all
the
all.
The
content
that
you
have
access
to.
This
gives
you
the
content
that
you
have
access
to,
which
is
starred,
and
this
is
the
specific
container.
C
So
this
is
making
it
a
little
bit
easier
to
navigate
across
these
things
and
then
change
the
scope
of
the
namespaces
that
you're
actually
interested
in
whilst
keep
keeping
this
context
of
the
features
going
on
so
and
like
by
clicking
on
thing
like.
So
you
can
add
namespaces
just
like
to
this
bar
right
here.
These
would
be
your
favorite
ones,
I'm
assuming
at
the
moment
that
there
may
be
10
namespaces.
C
C
So
far
and
I'd
love
to
get
your
feedback
sort
of
just
on
the
on
whether
I've
pinpointed
the
the
problem
with
the
two
different
types
of
navigation
and
what
you
think
of
like
the
proposed
solution
of
having
like
bookmarked
favorites.
For
for
users
as
well,
I
mean
the
visual
design
here
is
pretty
scrappy.
So
I'm
not
too
concerned
about
like
feedback
on
styles
and
that
and
like
polishing,
that
up
more
in
like
layout
and
concepts.
A
Yeah,
I
was
gonna,
say
the
same
player
about
discord,
but
not
focusing
too
much
on
the
the
ui
component.
My
my
only
last
thought
nick
is,
I
think
you
did
address
my
question,
which
was,
I
think
workspaces
should
help
by
not
creating
such
a
separation
between
groups
and
projects,
which
is
this
whole
intent.
So
there's
less
things
that
you
should
have
to
navigate
to
to
find
that
sub
thing
you
care
about,
so
I
mean
I
think
it.
A
It
makes
sense
from
that
perspective,
if
we
can
truly
reach
that
that
goal
of
our
architecture,
I
think
the
struggle
will
still
be
like.
I
don't
know
if
you
can
necessarily
get
away
from
still
needing
to
go
two
clicks
to
get
to
the
gitlab
orgs
value
stream
versus
git
labs,
but
I
I
think
that's
just
when
workspaces
kind
of
evolves.
It
might
take
care
of
that
itself.
So.
C
Yeah,
I
think,
what's
what
what
may
be
useful
here
is,
if
you,
you
read
the
the
workspace
jobs
to
be
done,
that
I
document
that
I
created
and
that
sort
of
talks
about
cascading
stuff
down
aggregating
stuff
up,
and
this
basically
means
that
it's
a
little
bit
easier
and
creates
less
constraints
by
having
to
navigate
the
folder
structure
of
git
labs
groups
and
projects.
F
Also,
I
did
see
the
prototype
earlier
and
I
think
it
made
sense.
I've
seen
the
idea
of
the
slack
workspace
switcher
as
a
way
of
doing
it.
I
think
twitter
has
the
same
behavior
like.
If
you
have
multiple
profiles,
you
can
switch
them
on
the
left,
but
yeah.
I
think
the
idea
and
the
direction
is
sound
because
it's
similar
to
other
environments,
you
know
drew
mentioned
blue
player,
mentioned
discord.
C
Cool
yeah
I
mean
this
is
this:
is
one
part
of
the
exploration
I'm
just
baking,
basically
taking
some
some
different
ideas
from
companies
and
using
those
as
a
jumping
off
point
and
and
and
just
doing
some
different
explorations
that
way
being
being
divergent,
so
I'll
take
a
look
at
discord
and
I'll
do
some
other
stuff
as
well.
I
think
figma
is
quite
interesting,
because
figma
has
those
two
dimensions
of
navigation
as
well
in
terms
of
pages
and
and
and
layers.
So
potentially
we
could
stack.
F
One
thing
that
I
had
feedback
on,
or
at
least
just
from
other,
like,
for
example,
the
system
usability
score.
The
the
navigation
in
general
is
too
much
there's
just
too
many
features
that
people
don't
use
or
never
use.
So
I'm
curious
how
much
you'll
be
able
to
reduce
that
as
part
of
this
work
to
help
the
navigation
concerns
that
you're
having.
C
Yeah,
so
I'm
going
to
follow
that
up
in
a
separate
issue
and
I'm
going
to
call
it
like
feature
navigation
rather
than
namespace
navigation
and
I'll
I'll
have
a
think
about
how
we
could
potentially
create
simpler,
simpler
features
and
or
how
we
can
maybe
bundle
stuff
together.
C
What
I'd
like
to
do
is
ask
the
question:
where
are
the
clusters
of
pages
that
people
tend
to
navigate
between
and
how
might
we
cluster
those
together?
C
The
wrong
button
there,
for
example,
if
I
go
into
git
lab
here,
we
have
issues,
and
that
is
well
how
I
define
that
as
project
planning,
and
then
we
have
like.
C
Oh
this
is
this
again.
This
highlights
the
confusion
so
yeah
we
have
like
labels
within
group
information,
even
though
sort
of
labels
potentially
should
exist
within
like
the
likes
of
issues
and
and
epics
and
stuff.
So
I'm
thinking
whether
using
like
objects
as
the
the
key
feature
navigation
item
is,
is
the
correct
thing
here
or
whether
we
start
to
cluster
them
together
into
something
like
say:
dev,
second,
ops
or
whatever.
C
That
may
be,
obviously
I'm
not
the
biggest
expert
in
each
and
every
one
of
these
things
so
I'll
be
working
with
the
likes
of
alexis
and
all
the
other
teams
and
stage
groups
to
to
help
me
out
with
that.
But,
first
of
all
I
want
to
get
the
data
from
the
team
to
see
whether
there's
a
like
sort
of
a
affinity
map
we
can
create
for
all
these
features
together
and
whether
we
can
organize
them
in
a
slightly
different
way.
Optimize
it
a
bit.
E
Just
wanna
we're
we're
not
quite
at
a
time
yet.
I
just
want
to
say
in
particular
that
this
was
I
found
very,
very
useful,
very
and
great
just
goes
to
show
how
awesome
the
plantage
team
is
honestly,
like
very
backgrounds,
and
I
love
the
feedback.
E
Let's
make
sure
that
this
recording
gets
socialized
somehow,
because
I
think
that
this
would
be
extremely
helpful
for
for
other
stage
groups
as
well.
We're
kind
of
talking
on
the
very
micro
level
with
with
austin's,
talk
and
then
they're
the
very
macro
level
that
affects
everyone
on
the
nick.
Well,
sorry
interrupt,
but
someone
else
has
more
feedback
there.
B
Oh
yeah,
I'm
just
saying
like
it
would
be
helpful
for
me
to
just
see
like
like
a
flow
or
like
a
scenario
how
a
user
would
be
navigating.
I
mean
you
said
this
is
rough
nick,
just
you
know
seeing
how
they'd
navigate
that,
maybe
like
the
group
project
issue
or
like
how
to
make
epics
more
discoverable
using
this
new.
You
know
workspaces
set
up
something
like
that.
That
would
help
me
wrap
my
head
around
this
a
little
bit
better
and
how
also
some
of
those
like
cascading
up
issues.
We
have
sure.
A
Maybe
a
question
for
my
future
self:
how
can
the
foundations
group
help,
or
rather
is
there
anything
that
you're
expecting
of
them
in
this
area,
since
they
technically
have
navigation
settings?
Is
there
a
group
or
category.
C
I
think,
like
the
I'm,
not
I'm
not
I'm
not
the
the
biggest
expert
on
visual
design,
so
taking
some
of
the
concepts
that
I've
I've
I've
put
out
here,
some
of
the
rough
things
and
actually
putting
a
polish
on
them.
So
they
don't
look.
Look
terrible
would
be
a
great
help.
C
C
And
like
behaviors
that
happen
between
levels
of
hierarchy,
all
very
abstract,
so
yeah,
I'm
gonna,
try
and
prototype
out
as
much
of
this
as
possible.
So
people
can
understand
what
I'm
talking.
E
C
I've
just
been
stuck
in
an
information
architecture
land
for
a
while.
A
Yeah,
I
think
I
think
you're
fighting
with
us
not
like
contentiously,
just
we
all
have
our
biased
mindsets
around
how
gitlab
works
today.
So,
at
least
for
me,
I
have
a
roadblock
of
envisioning.
If
there
wasn't
this
separation
of
features
between
groups
and
projects,
what
would
navigating
that
experience?
Look
like.