►
From YouTube: Working Group: Simplify Groups and Projects - 2020-08-27
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
B
Yeah,
so
I
think
we're
we're
in
a
point
where
daniel
was
suggesting
that
he
didn't
want
to
influence.
I
guess
the
prototype
too
much
before
we
start
getting
feedback,
but
I
think,
is
part
of
validating
the
solution
which
we
have
to
have
done
by
the
end
of
september.
Basically,
we
need
to
pretty
aggressively
show
the
prototype
and
gather
feedback
daniel.
B
I
know
you're
have
a
lot
of
competing
priorities,
so
I'm
happy
to
like
help,
take
the
prototype
and
record
videos
of
me
showing
it
to
people
and
getting
feedback,
if
also
like.
You
have
a
script
or
questions
that
you
want
me
to
ask,
or
if
you
do
have
the
bandwidth
to
run
that,
like
I'm,
happy
I'd,
love
to
just
like,
be
a
fly
on
the
wall
and
listen
as
you
want
to
work
through
that
process.
B
B
How
do
you
give
the
end
user
more
control
over
what
things
get,
what
actual
like
resources
get
shared
from
one
to
another?
So
we
can
like
talk.
We
can
do
the
demo
or
you
can
do
the
prototype
first,
but
I
want
to
be
really
intentional
about
putting
together
that,
like
that
validation
plan,
so
that
we
don't
lose
steam
on
it
in
the
next
few
weeks.
C
Yeah,
so
right
now,
my
I
guess,
workflow
or
wireframe
that
I
did
is
really
rough
and
just
I
was
hoping
to
see
like
what
we
could
rule
out
or
what
doesn't
work
or
what
doesn't
make
sense.
So
in
terms
of
using
that
as
a
guide
for
end
users
or
testers
would
be
fine,
you
know
it's.
I
think
it's
easier,
smarter
to
rule
out
what
doesn't
work
than
to
try
and
come
up
with.
C
B
D
C
D
B
The
problem
got
scott
and
a
new
blessing
to
do
the
working
group,
and
then
we
need
to
do
the
solution,
validation
and
then
based
on
like
what,
whether
we
validate
the
solution
or
not,
we
would
have
to
get
their
approval
and
probably
sids
as
well
to
move
forward
like
actually
doing
it,
but
that
we
kind
of
set
the
target
date.
I
think,
at
the
end
of
september,
isn't
that
right,
justin.
A
Yes,
that
was
what
we
said
so
that
we
can
be
prepared
to
go
into
like
q4
if
we
want
to
pitch
teams
starting
to
work
on
on
the
validated
solution,
because
we
think
it's
a
cross-team
cross-stage
cross-group
effort
to
do
this.
And
it's
not
something
like
one
stage
or
even
one
group
could
prioritize
by
themselves.
B
E
B
Well,
that's
that's
where
we
can
recruit
people
that
way
or
we
can
recruit
people
like
the
old-fashioned
way
of
saying
hey
customer
I've
talked
with
you
several
times
about
this
pain
point.
Let
me
show
you
this:
can
you
provide
some
feedback?
You
know
type
thing
and
I
think
there's
there's
a
healthy
dose
of
both
but
like
we
basically,
I
would
like
to
do
it
that
way
and
then
also
do
with
the
formal
like.
B
Let's
do
some
blind
tests
do
recruit
some
people
that
have
you
know
no
super
intimate
knowledge
of
gitlab
and
see
like
how
it
works
with
them.
We
can
also
consider
doing
some
usertesting.com
things
where
we
basically
give
people
some
of
the
jobs
that
they
need
to.
Do.
They
don't
know
anything
about
git
lab
and
give
them
the
prototype
and
see
if
they
can
complete
it
I'm
open
to.
However,
we
want
to
tackle
this,
I
just
yeah.
If
we
need
to
start
recruiting
today,
we
should
do
that.
E
B
Cool
and
then
whoever
we
can
pull
them
into
the
working
group.
And
if
we
can't
find
anyone,
then
I
guess
we're
gonna
like
go
old,
school
and
I'll
like
wireframe
some
stuff
up
and
maybe
pull
in
my
ux
designer
to
see.
If
she
wants
to
collaborate
on
this.
So
that,
like
we're
doing
things,
the
way
that
we
should
be
okay
for
ux,
stuff,
cool.
B
C
C
C
C
They
would
pick
the
type
of
object
and
then,
in
this
case
we
will
just
say
I'm
going
to
start
by
creating
our
code
repo
and
then
just
copy.
The
content
that
we
currently
have.
The
functional
piece
still
exists,
and
I
don't
think
it
needs
to
change
much
so
now,
we've
saved
that
we'll
have
our
repo
assigned
next
we'll
want
to
create
a
new
team.
C
C
C
C
This
would
be
the
screen
that
dev
would
see.
They
wouldn't
have
any
additional
stuff.
They
would
just
strictly
have
objects,
they
need
for
their
day-to-day
tasks,
and
this
needs
further
investigation,
you
know,
are
to
do's
merge
requests.
Are
these
part
of
a
flat
object?
Are
they?
Are
they
part
of
the
repo?
C
So
now
looking
at
nested
objects
and
further
sharing
the
ideas
that
we'll
look
at
how
a
qa
team,
for
example,
would
work
on
this?
So
I'll?
Look
at
the
repo
or
it's
email,
qas
support
team
so
from
here
the
support
team
doesn't
necessarily
have
access
to
anything,
but
they
exist
in
tandem,
so
the
repo
would
actually
have
the
team
members
underneath
it
and
the
epics
and
issues
would
be
shared
across
and
that's
sort
of
where
I
stopped.
C
C
C
Brought
that
up
earlier
in
the
chat-
and
I
agree-
I
don't
like
the
word
object,
but
I'm
also
hesitant
on
calling
it
team
or
workspace
or
lab
or
anything
at
this
point,
because
I
don't
want
to
say
if
we
call
it
something
that
would
guide
or
influence
what
we
wanted
to
do
or
solutions
it
could
offer
I'm
open
to
changing
it
or
calling
whatever.
I
just
don't
want
to
have
any
sort
of
direction
or
influence
on
it.
So
I
mean
like
namespace
or
container,
makes
sense.
E
C
E
The
only
thing-
and
I
don't
know
the
answer
to
this
right-
I'm
just
thinking
out
loud-
it's
like
within
a
workspace
or
whatever
I
end
up
calling
it
would
you
ever
want
to
have
two
of
one
thing
right.
I
guess
that
doesn't
if
you
have
toggles
it's
just
like,
can
I
use
it?
It's
not
a
one
necessarily
right.
C
Yeah
and
the
other
thing
regarding
the
the
toggle
behaviors,
I
wasn't
certain
how
you
would
want
to
want
to
work
with
nested
objects.
So
when
you
create
the
object-
and
you
toggle
the
features
you
want
in
the
object,
what
if
what
a
feature
be
to
add
an
additional
nested
object,
that's
sort
of
where
the
idea
that
I
had
to
kind
of
separate
that
so
that
it
was
more
like
nesting,
was
logical.
B
Yeah
the
way
that
I
was
thinking
about
it
is
you
create
your
your
thing:
whatever
you
call
it
object
now
and
then
you
could,
you
could
toggle
which
features
you
wanted
there,
but
then
you
could
like.
You
could
basically
create
a
new
object
within
that,
like
sort
of
so
that
way,
we're
not
like
taking
users
too
far,
but
it's
almost
like
creating
a
new
subgroup,
but
what
what
we're
doing
is
just
setting
up
the
dag
relationship
behind
the
scenes
between
the
two.
B
Well,
yes,
the
the
use
case
right
now
is
like
why
you
have
to
have
people
want
issues
at
the
group
levels
because
they
have
many
repos
underneath
them
and
they
want
to
do
their
issue
management
in
one
place,
not
in
like
a
project
within
the
subgroup.
They
just
want
to
do
it
here
and
they
want
to
manage
the
code
down,
and
this
is
here
right
or
a
case
in
point.
B
E
Wonder
if,
like
a
good
first
step
right,
because
I
know
anecdotally,
you've
heard
some
of
this
I've
heard
some
of
this
game
about
like
oh,
like
people
want
to
organize
things
some
ways,
and
they
can't
do
it
right.
I
wonder
if
a
if
maybe
just
like
having
a
formal
inventory
right
of
these
use
cases
would
be
helpful
right
of
just.
D
E
Hey
like
this
is
what
their
org
structure
looks
like.
This
is
what
they're
like
tech
stack
looks
like
this
is
how
they
would
wanna
like
represent
things,
and
then
that
way,
it's
not
so
like
theoretical
and
whoever
works
on.
The
design
has
like
this
test
cases,
basically
that
they
can
run
designs
against.
B
Have
you
seen
the
solution
issue
that
created
now
drop
it
into
this
working
group,
yeah
solution
issue?
So
that's
sort
of
what
I
did
here
in
this
issue.
I
went
through,
and
I
basically
said
like
here
and
I
pulled
the
verbatim
customer
in
their
own
writing,
use
cases
so
like
needing
to
track
multiple
milestones
and
multiple
epics
across
objects.
B
Basically
like
pull
up
a
board
that
has
every
developer
in
my
team
across
all
my
objects,
not
just
top
level
objects
they
align
with,
and
so
like.
I,
I
kind
of
put
all
those
weird
use
cases
about
how
people
want
to
structure
the
relationships
of
things
based
on
their
own
words
and
then
under
there's
another
other
problem
which
is
more
in.
I
guess,
like
you
know,
we
need
all
these
capabilities
at
the
group
or
project
level
and
the
you
know,
duplication
of
it
deduplication
of
it.
So
do
we
need
more
than
that.
B
B
D
C
D
C
B
B
So
if
you
were
to
mash
them
together,
we
we
basically
would
have
to
make
sure
that
the
permissions
between
the
group
and
the
project
were
identical
right.
So
that
way
like,
if
you
were
to
have
one
thing,
they
would
all
have
the
same
like
that
one
permission
table
just
become
one
permission
table,
not
two
separate
ones.
So
I'll
finish,
the
audit
of
that
I
started
a
spreadsheet
and
I
I
will
post
it
in
our
our
slack
channel
whenever
I'm
done
with
it
later
today.
B
That
was
the
only
the
only
real
concern
that
I
would
have
and
then,
of
course,
there's
like
the
ux
things
of
like
lots
of
lots
to
figure
out.
You
know
how
the
ux
should
work
in
certain
things
like
settings
and
and
whatnot,
where
there
are
some
discrepancies,
but
other
than
that
there
is
no
functional
difference
that
I
could
tell.
C
That's
what
it
felt
like
from
my
initial
tinkering
with
this
and
again.
The
only
reason
I
kind
of
stepped
back
from
it
was
the
description
that
we
had
in
our
last
meeting,
where,
like
you're,
basically
mashing,
all
the
bad
stuff
together
that
we
don't
want
to
do
it'd
be
better
and
easier
to
start
from
a
clean
slate.
C
Which,
which
I
don't
mind,
I
think
the
clean
slate
would
be
a
fantastic
opportunity
to
give
us
more
room
for
flexibility
and
to
rethink
everything
but
then
going
backwards.
You
know
just
as
an
argument
for
mvc's
sake
like
smooshing.
The
tooth
objects
together
might
make
the
most
sense,
because
then
you
have
the
features
that
people
are
asking
for.
I
want
stuff
at
the
group
level
or
I
want
stuff
across
the
organization,
but
the
only
feedback
pushback
that
I
heard
initially
was,
as
you
described,
putting
band-aid
on
a
problem
right.
C
Yeah
again,
that
was
my
only
that
was
my
only
concern
was
just
because,
as
you,
the
way
you
described
it
is
that
it
might
be
problematic.
But
if
you're
saying
that,
perhaps
it's
not
so
ugly,
we
just
squish
them
together,
like
maybe
that's
the
first
step,
as
we
can
spend
more
time
on
this
trying
to
come
up
with
a
new
object
or
new
container
or
a
new
proposal,
and
we
can
get
feedback
around
that.
If
we
do
the
code
smush.
D
D
D
So
hopefully,
that
comes
through
okay.
This
is
how
I
would
sort
of
migrate
this
hierarchy
into
what
I
consider
to
be
like
the
lab
structure
or
the
container
structure,
whatever
we
want
to
call
it
essentially
every
every
group,
so
I've
left
sort
of
the
colors
and
the
names
intact
to
sort
of
try
to
demonstrate.
What's
moved
what
hasn't.
D
So
if
you
somehow
managed
to
navigate
to
one
of
these
two
things,
you
know
like
like
my
project
in
the
url,
it
would
redirect
into
rendering
this
lab
view
and
same
thing
for
for
like
a
group,
so
that
they
kind
of
we
just
layer
on
this
facade
of
a
lab
where
this
is
a
lab
is
an
actual
thing.
But
it's
really
just
this
very
thin
veneer
over
a
group
and
a
a
sort
of
a
shadow
project,
or
vice
versa.
D
D
So
we
try
to
sort
of
pull
things
back
to
that
sort
of
generic
namespace
type
idea,
but
I
think
you
know
that
the
working
group
sort
of
goal
is
quite
ambitious
and
I
think
there's
going
to
be
several
significant
steps
to
get
to
that
end
goal.
So
I
think
this
being
the
first
I
think
is
is
it
leaves
me
optimistic?
B
Yeah,
I
mean,
I
think,
it's
great
and
I
think
that's
where,
like
we
don't
have
to
have
everything
solved,
but
at
least
saying
like
this
is
the
first
step
and
then
the
future
like
ideal
and
say
this
is
where
we
would
be,
and
we
don't
have
to
get
into
solving
that.
I
think
that's
where
we
would
want
to
get
other
engineers
involved,
like
staff
engineers
and
have
other
people
help
out
with
some
of
those
things
after
we
get
this
mvc
done.
B
So
I
think
this
is
awesome
and,
and
then
I
think,
that's
where
the
only
other
thing
to
figure
out
from
a
ux
standpoint
and
daniel
started
working
on
this
was
just
like
the
sharing
of
things
right.
So
in
this
new
model,
if
we
were
using
the
the
dag
relationships
instead
of
like
a
hierarchy,
all
you're
really
doing
is
saying
you
know,
lab
2
has
a
traversal
id
to
lab
5.
Basically,
that's.
D
Right,
the
relationship-
that's
right
under
the
hood,
it's
all
sort
of
somehow
magically
handled
through
this
this
group.
So
when
we're
saying
are
these,
these
two
labs
are
related,
whether
we've
created
this
hidden
sort
of
group
or
it's
something
that
somebody
had
previously
created.
For
example,
it
also
magically
just
works
as
one,
but
under
the
hood,
it's
actually
just
infrastructure
that
we
already
have.