►
From YouTube: WG: Simplify Groups and Projects - 2020-09-03
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,
it's
simplified
groups
and
projects
working
group
on
september,
the
3rd.
It's
like
gaby
of
the
first
one.
If
you
want
to
kick
us
off.
B
We
talked
with
mike
just
about
how
we
want
to
proceed
from
ux
standpoint
and
the
basic
gist
is:
there's
a
strong
desire
to
finish
the
groups
or
subgroups
category
maturity
scoring
which
is
more
or
less
doing
problem
validation,
exposing
problems
with
subgroups
through
a
highly
research
driven
ux
process,
and
once
we
do
that,
then
I
think
it
will
help
daniel
get
more
up
to
speed
with
the
problem
space
and
ultimately
lead
to
a
better
solution.
B
B
It
it
means
that
we'll
need
to
likely
adjust
to
self-imposed
deadlines,
but
if
anything,
I
think
like
we
shouldn't,
we
shouldn't,
at
least
on
the
engineering
side,
let
up
on
the
sense
of
urgency.
C
B
It
should-
and
I
think
that's
where
marcus
was
doing
some
good
work
on
technical
discovery.
I
think
if
we
get
a
little
further
along
in
collaborating
on
that,
it
looks
like
natalie's
here
too,
and
even
thinking
about
front
end
and
how
we're
gonna
deal
with
the
front
end
for
things
and
merging
everything
together
like
just
a
cohesive
technical
strategy.
I
think
the
solution's
not
going
to
change
much,
but
it
could
so.
B
That
cool,
so
I'm
trying
to
find
the
issue
that
I
created
for
my
next
bullet
point:
it's
in
this
epic,
I'm
gonna
grab
it
and
link
it
right,
quick,
but
I
created
this
issue
good.
This
is
basically
like
sticky
points.
So
when
we
look
at
you
know,
we
talked
about
creating
these
or
organizational
structure,
archetypes
that
we
could
use
in
thinking
about
developing
features
and
stuff
sticky
points
like
one
of
the
things
that
I
immediately
thought
about
like
if
you
let
some
object
show
up
in
a
lab.
B
B
I
think
of
a
given
issue,
and
if
you
share
a
issue
across
a
top-level
namespace
with
another
one,
it
shows
up
in
the
other
top
level
name
space.
Then
you
would
break
the
relative
position,
which
is
like
the
manual
sorting
of
issues
and
the
board,
and
also
the
manual
sort
and
the
issue
list.
So,
like
I'm
trying
to
start
thinking
through,
like
all
the
things
that,
like
don't,
are
going
to
be
like
problem
areas
and
trying
to
document
them
in
one
place,
so
at
least
we
can
think
through
it.
That's.
B
I
wouldn't
I
would,
I
would
agree
in
the
grand
scheme
of
things
we
would
have
to
figure
out
a
way
to
handle.
It
is
all
I'm
saying
right
because,
because
if
you
you
have
a
certain
say,
you
have
one
two
three
and
one
project
and
you
have
one
two
three
and
another
project,
and
then
you
share
issue
two
to
this
other
project.
Then
how
do
you
know
what
the
relative
position
ought
to
be
in
the
context
of
a
different
place.
C
Well,
yeah,
I
mean
it's
from
an
engineering
perspective.
You
just
have
to
extract
into
you
just
need
to
keep
a
second
copy
of
the
ordering.
C
B
Yeah,
I
guess
so
just
trying
to
think
through
it,
because
one
of
the
things
that
I
was
coming
across
in
iterations-
I
don't
know
if
you
watched
the
video
that
I
recorded
my
ux
designer,
but
the
the
basic
idea
is
like
if
you,
instead
of
like
the
the
inheritance
behind
the
scenes
being
explicit
about
saying
this
group
is
synced
with
this
other
group's
iterations,
and
then
I'm
was
thinking.
B
That
was
a
viable
solution
for
all
the
problems
that,
like
I
talked
about
in
that
issue,
but
I'm
wondering
like,
if
there's
a
way
to
basically
say
which
thing
should
be
the
canonical
owner
of
certain
things,
that
we
don't
have
to
create
a
ton
of
duplicate
tables
for
everything.
Okay,
so
that's
all
I'm
saying
I
would
like
to
not
add
a
bunch
of
technical
debt
and
simplify
the
system
as
much
as
possible.
B
C
C
Okay,
so
I've
mentioned
a
few
times
in
the
last
month,
or
so
that
I
wouldn't
mind
as
part
of
this
working
group,
putting
out
some
sort
of
list
of
recommendations
on
how
to
how
to
not
make
the
same
sort
of
mistakes.
Again.
C
How
to
you
know,
maybe
part
of
the
solution
that
we
come
up
with
is
not
necessarily
a
technical
solution,
but
it's
a
set
of
guidelines
on
how
to
create
your
next
feature
or
potentially
how
to
adjust
your
your
set
of
features
so
that
they
can
work
between
groups
and
projects
or
whatever
across
instance,
instance
level
as
well.
So
I
don't
know,
I
don't
know
if
it's
probably
not
worth
going
into
the
specific
of
the
example
that
I've
linked
to.
C
A
potential
way
where
we
could
sort
of
provide
a
a
solution
to
a
set
of
problems.
That
applies
probably
in
many
many
cases
and
across
all
sorts
of
different
features.
C
Specifically
around
sort
of
you
know
how
we
share
the
how
we
share
membership
and
how
we
share
ownership
and
access
to
various
entities,
and
you
know
it's
the
same
sort
of
problems
that
I
see
all
over
the
place
for
various
features
and
if
we
can
create
sort
of
a
set
of
cookbook
style
solutions.
You
know
this
is
the
problem.
This
is
what
it
looks
like,
and
this
is
the
solution.
C
It's
probably
going
to
make
a
lot
of
people's
lives
a
lot
easier
and
sort
of
solve
the
like
the
at
least
from
my
world
from
the
manage
access
world.
It's
going
to
solve
those
problems
for
those
people,
which
is
a
big
problem
for
a
lot
of
a
lot
of
designers
and
sort
of
product
managers
and
so
on,
developing
features
which
leaves
them
with
just
dealing
with
sort
of
the
domain
problem
of
how
do
we
create
an
on-call
schedule?
C
D
Yeah,
so
I
created
an
issue
to
basically
start
prototyping
based
on
the
discussions
with
alex,
and
it's
almost
pretty
much
the
same
approach
that
alex
presented
last
week
in
this
diagram,
below
which
I
only
saw
today,
but
you
already
discussed
about
this
earlier,
like
just
trying
to
mush
them
together.
As
you
said
last
week,
and
see
how
far
it
can
go.
D
Basically-
and
one
thing
I
noticed
like
last
week,
we
discussed
about
the
ux
differences
between
projects
and
groups,
and
the
main
difference
I
saw
is
that
the
landing
pages
are
different,
like
projects
show
the
code
repository
by
default
and
group,
so
like
all
the
subgroups
and
subprojects
so
like,
you
need
to
find
a
way
to
combine
them,
and
it's
also
like.
If
the
project
only
has
the
issue
feature
available.
C
C
B
Yeah
we
would,
we
would
work
on
that
as
part
of
the
solution.
Validation.
It
would
depend
on
what
features
you
want
to
enable
like.
You
know
if
we
end
up
finding
a
much
simpler
solution
and
then
mushing
things
together,
then
great,
but
in
either
way
right
now,
the
the
usability
of
the
finding
out
that
you
can
change
what's
on
the
home
page
of
your
project
and
then
not
being
able
to
configure
it
to
look,
have
something
that
you
want
to
be
your
homepage.
B
So,
like
I
think
I
don't
know
if
you
can
set
wiki
to
be
your
homepage.
But
if
I
disa
disable
my
issues
and
my
repo,
then
I
think
wiki
automatically
becomes
a
home
page
or
something
like
that
so
like
we
want
to
make
it
at
a
minimum
more
flexible.
So
people
can
pick
whatever
home
pages
they
want
to
start
at.
B
In
the
long
run,
it
would
be
more
of
like
a
dashboardy
type
thing
that
also
maybe
could
be
customized
based
on
the
person
or
the
user
role
or
what's
important
for
them
to
see
when
they
go.
C
Yeah,
I
I
think
you'll
find
that
I
mean
I'm
taking
a
wild
step
here,
but
I'd
imagine
that
people
are
going
to
use
these
workspaces
for
specific
purposes.
So
they
may
very
well
just
enable
the
repository
and
maybe
issues
and
something
else
and
there's
probably
going
to
be
an
implied
kind
of
obvious
use
for
that
workspace,
and
I
think
that
we
could
like,
like
you
say,
go
where
you
know
if
you
disable
various
bits
and
pieces
at
the
moment.
Well,
it
sort
of
assumes
that
you
want
it
for
something
else.
C
I
think
you'll
get
the
same
sort
of
behavior
with
with
the
workspace.
It's
just
that
we
kind
of
you
know
if
there's
nothing
enabled
and
there's
a
bunch
of
people.
Well
then
it's
just
a
collection
of
members
and-
and
maybe
you
sort
of
show
the
members
and
the
subgroups
or
the
sub
containers
whatever.
B
Yeah,
I
think
that's
where
ux
will
be
able
to
help
a
lot
with
research
and
if
we
can
tailor
it
to
personas,
basically
so
that
you
can
have
a
different
view
per
persona,
because
I
know
product
managers
that
I've
talked
to
especially
less
technical
ones.
They
want
to
go
into
a
lab
or
a
workspace
or
whatever,
and
they
just
want
to
see
the
burn
down
chart
for
the
current
iteration.
The
issues
that
they
need
to
triage
do
just
that
without
having
to
click
navigation
anywhere
else
and
then
like
get
out
as
quickly
as
possible.
B
B
E
Another
thing
we
could
also
investigate
too,
is,
if,
like
a
lot
of
apps
when
you
land
in
them,
will
always
show
you
what
was
last
done
in
descending
order
in
that
project,
and
it's
like
that
way,
you're
seeing
what
you
did
last,
what
your
team
did
last,
so
I'm
sure
that's
something
else
that
research
could
figure
out
if
a
unifying
experience
like
that
that
ex
exposes
the
activity
and
is
very
common
across
get
lab,
regardless
of
what
you've
put
in
your
project.
That's
another
thing
to
consider.
B
Yes,
absolutely
that's
where
I
actually
said
what
I
wanted
on
my
home
page
for
git
lab
was
an
activity
feed
because
there's
somebody
doing
a
ux
research
on
it.
I
was
like,
I
really
want
to
see
an
activity
feed
and
I,
like
all
the
things
that
I
want
to
see
on
my
global
gitlab
homepage,
but
if
you
figure
that
out,
you
can
have
something
similar
that
is
scoped
to
just
like
a
given
workspace
too.
That's
all
stuff
that
I
don't
yeah.
B
B
C
C
So
yeah
mark
it's
just
just
to
sort
of
show
you
where
I'm
thinking
in
the
bottom
left
here
is,
is
kind
of
a
new
construct.
What
you've
called
the
workspace
I've
called
a
lab
and
the
lab
extends
it
specializes
on
the
namespace,
where
I'm
assuming
the
namespace
is
like
the
core
structure
of
the
hierarchy
and
a
lab
consists
of
a
a
group
and
a
project
and,
and
that
is
the
aggregation
and
so
last
week
I
did
you
watch
the
video
last
week,
marcus.
C
C
So
every
every
group
has
a
project.
Every
project
has
a
group,
but
ideally
they're
kind
of
hidden.
We
only
have
to
do
it
this
way
to
sort
of
retrofit
the
system
into
this
new
sort
of
idea,
and
so
then
I've
created
like
a
lab
projects,
controller
which
is
really
just
an
extension
of
the
project
controller
and
the
labs.
C
So
as
an
example,
so
wherever
I've
got
a
groups
route,
I
kind
of
intercept
it
and
put
this
facade
over
a
lab
groups.
So
every
time
you
access
the
group's
controller,
I
kind
of
jump
in
the
middle
and
go
here's.
My
is
my
lab
controller
I'm
going
to
take
over
and
for
everything
that
I
don't
want
to
handle.
C
I
just
pass
through
through
inheritance
to
the
to
the
group's
controller
and
likewise
for
for
the
project,
so
I
kind
of
override
from
the
project
controller
I
override
with
my
lab
projects,
controller
and
the
intention
there
is
the
same
but
I'll
just
sort
of
so.
If
you
create
a
new
group,
normally,
let's
say
it
goes
through
the
labs
that
it
would
normally
go
through
the
groups
controller.
C
It's
now
going
to
go
through
my
lab
groups,
controller
and
in
that
action,
I'm
just
going
to
go
and
create
a
project
as
well
and
attach
it
into
the
I'm
going
to
create
a
new
lab,
create
the
group
that
it
requested
and
I'm
going
to
create
this
implied
project
and
stick
it
into
the
the
name
space
hierarchy
at
that
location
where
it's
been
requested
and
so
we'll
see.
But
the
hope
is
that
that's
all
sort
of
kind
of
works
transparently
and
the
the
inheritance
structure
is
all
sort
of
maintained
through
the
the
name.
C
B
C
C
I
think,
but
yeah
we
will
have
to
make
sort
of
a
determination
at
the
kind
of
the
feature
level
or
whatever,
whatever
we
want
to
call
a
lab
or
a
workspace.
What,
however,
we
want
that
to
sort
of
actually
operate,
because
there's
no
there's
no
longer
a
concept
of
a
group
or
a
project,
so
we
kind
of
have
to
make
that
decision
anyway.
B
How's
the
best
way
to
document
that
so
there
I've
put
been
putting
off
some
of
the
duplication,
duplicate
duplicative
issues
to
put
things
at
the
group
or
the
project
level
to
see
how
this
would
shake
out
like
one
example,
is
prioritized
labels
they're
at
the
project
level,
but
not
at
the
group
level.
So
that's
a
huge
request
right
and
so
in
that
instance,
I
would
want
to
say
since
they're
already
the
project
level.
B
Let's
use
project
labels
as
like
the
label
feature
right
so
that
we
can
have
the
get
the
priority
for
free
without
having
to
rebuild
it.
Is
that
the
right
way
to
think
about
it?.
C
Well,
when
you
say
both
are
active,
like
I
say
so,
where
am
I.
C
C
Get
all
this
hard
in
the
way.
I
can't
do
anything
so
this
this
diagram
below,
like
that.
I
showed
last
week
where
I
showed
that
essentially
so,
if
there's
an
existing
project
say
project
two,
when
we
migrate
to
a
lab
structure,
project
two
will
get
this
second
group,
that's
kind
of
a
tightly
coupled
to
it
and
it
won't
it'll,
just
be
it'll,
just
be
there
for
the
sake
of
creating
the
lab.
C
B
That
does,
and
that's
where
I
was
suggesting
that
like
it
that
doesn't
solve
the
problem,
then
of
having
to
not
duplicate
things
at
the
group
level,
if
that
makes
sense
right
so
in
in
this
example,
if
you
look
at
lab
4
or
lab
2,
it's
almost
like
you
know
that
p2
has
can
create
labels.
B
You
know
that
g
dot
p2
can
create
labels,
because
it's
group,
the
labels,
behave
slightly
different
because
we
haven't
brought
parity
to
the
group
level
labels
so
technically
the
the
p,
the
project
labels
behavior,
is
more
advanced
than
the
group
level
labels.
So
we
would
want
to
pick
that
to
be
like
the
canonical
thing.
So
when
I
created
lab2
I'd
want
the
project
like
that
lab
to
use
the
project
labels
and
not
the
group
labels.
Does
that
make
sense.
C
Yeah
yeah,
it
does
yeah
I
mean,
is
that
is
that
partly
a
migration
issue?
I
think
once
when
we
create
a
lab
construct,
we're
gonna
have
to
pick
one
to
to
be
the
one
that
we
work
with
so
again,
you
know
it's
just
going
to
be
easy
to
say
whenever
you
create
a
label
in
a
lab,
we're
actually
just
going
to
make
a
label
in
a
project
in
in
the
labs
project.
C
B
I
think
it's
I'll
take
on
the
task
of
looking
at
the
overlap,
but
if
the
ultimate
goal
is
to
then
down
the
road
extract
each
feature
from
a
group
or
project
so
that
those
contracts
go
away,
we
should
think
about
as
we're
exploring
this
canonically
pitching
picking
which
feature
from
which
group
or
project
you
want
to
standardize.
On
that.
That
way,
you
can
like
start
extracting
that,
like
the
first
step
to
extracting.
B
That
would
be
removing
that
feature
from
the
other
construct
and
relying
just
on
that
one
if
it's
in
a
group
or
project
and
then
after
that
would
be
extracting
it
into
the
like
out
of
the
project
and
it
could
be
in
the
lab
or
where,
wherever
we.
C
E
I
have
a
question:
I'm
just
wondering
if
we'd
ever
considered
just
the
concept
of
having
global
labels
or
something
like
stop,
calling
them
group
but
like
there
could
be
ecosystem
labels
that
are
kind
of
everywhere
and
available,
and
then
project
specific
ones.
E
And
I'm
just
thinking
that,
because
a
lot
of
times
organizations
want
to
set
up
global
concepts.
Labels
workflows
things
like
that.
B
Yeah
people
want
to
create,
have
talked
about
creating
labels
at
the
instance
level,
which
would
be
when
we're
thinking
about
the
organization
level.
The
other
way
that
I
thought
about
solving
this,
though,
is,
if
you
let's
say
you,
create
a
lab,
and
it's
just
your
configuration
for
things.
B
It's
your
labels,
it's
your
templates,
it's
your
whatever
you
want
it
to
be,
and
then
you
share
that
lab,
like
you,
basically
check
a
box
and
say
share
this
by
default
with
all
other
labs
in
my
organization
right
so
from
one
lab,
you
basically
can
set
the
configuration
all
the
other
labs
inherit
without
adding
another
feature
like
at
the
top
level
yeah.
That's
where
I
don't
know
from
a
ux
standpoint
and
we'll
figure
out
solution,
validation,
if
that's
ideal,
but
that
fits
the
pattern
of
what
I've
seen
lots
of
people
want
where
they're
like.
B
E
E
But
if
an
organization
wanted
to
set
their
company
with
global
labels
in
a
really
simplified
way,
any
non-technical,
trello
user
or
someone
who's
just
wanting
to
create
somewhere
to
track
things,
they
created
it.
It
would
be
set
up
the
way
the
organization
intended
and
they
wouldn't
have
to
even
be
asked
these
questions.
B
C
Did
you
see,
I
pretty
sure,
a
couple
days
ago
I
wrote
a
comment
around
these
labels
and
how
they
sort
of
just
like
the
semantic
issue
around
you
know.
I
think
I
used
the
example
of
curry
where
you've
got
indian
curry.
You've
got
tight
curry,
we
just
call
it
curry,
but
they're,
both
quite
different
and
the
semantic
sort
of
difference
matters.
C
So,
if
you're,
just
in
a
lab-
and
you
have
a
set
of
labels
and
you
share
them
out
to
everybody,
if
you
just
end
up
with
like
10-
carry
labels
it,
I
don't
know
how
useful
is
that
you
could
still.
You
know,
I
think
I
said
in
that
comment.
We
could
filter
by
just
the
string
value,
if
that's
all
we're
talking
about.
If
you
just
care
about
the
string
just
filter
by
curry.
Well
then,
you
just
list
the
unique
strings
and
just
filter
as
though
they
were
like
tags.
E
B
E
Of
the
yeah,
the
global
labels
that
we
always
have
as
pm's
like
the
knowledge
team,
create
stage
like
I
wouldn't
want
to
delete
duplicate
those
in
every
project
they
made.
Those
should
just
be
set
and
I
would
always
go
from
there,
but
I
might
want
to
add
a
new
design,
ready
tag
that
only
my
team
knows
about
or
in
my
project
and
the
rest
of
gitlab
doesn't
need
to
see
that,
because
it's
not
in
their
main
workflows.
B
Yep,
I
think
that's
where
like,
but
I'm
working
to
make
it
so
that
you
can't
have
duplicated
labels
in
any
name
space
hierarchy,
and
I
like
we
could
look
at
doing
that
in
the
organization
level.
But
I
think
the
same
would
be
true
like
if
you
had
a
lab
that
was
your
labels
and
configuration
type
thing
that
you
auto
shared
with
all
the
other
labs.
B
They
would
all
basically
be
able
to
see
those
labels
within
their
own
labs
and
we
would
like
have
the
same
rules
where
you
can't
produce
a
duplicated
label,
but
you
can
the
way
that
I'm
looking
right
now.
You
can
create
your
own
unique
design
label
in
your
lab
right
and
then,
if
the
the
lab,
where
it
has
all
the
labels,
the
global
labels,
it
tries
to
create
the
same
thing.
B
It
will
be
notified
or
the
user
will
be
prompted
that
that
label
already
exists
in
another
lab
that
is
shared
with
and
offering
to
promote
it
and
or
something
like
that
or
maybe,
because
the
labs
are
shared.
That
label
would
automatically
show
up
in
the
lab
that
has
all
the
label
configurations
too.
C
E
C
E
B
Yeah,
the
the
only
tricky
thing
is
the
inverse
of
that
is,
if
you
have
a
a
lab
that
has
a
unique
tag:
that's
our
label
is
not
global
and
then
the
global
lab
tries
to
add
that
yeah.
We
need
to
like
invalidate
that
as
well
and
allow
them
to
basically
promote
that
into
the
global
labs.
Yes,
the.
F
Not
on
the
last
bullet,
actually
I've
been
sitting
here
thinking
I
have
a
quick
thing
to
say:
I'm
looking
at
the
issue,
I'm
sorry
it's
two
one,
eight
three,
three,
three,
the
one:
the
simplified
groups
and
project
solution,
validation
and
I'm
wondering
if
we
could
actually
do
a
what's
called
like
almost
like
a
sprint
planning
exercise
where
we
generate
basically
issues
or
user
stories
around
problem
set
one
because
it
is
big
in
scope
but
like
we
also
need
to
talk
about
just
I
mean
this
whole
conversation.
F
B
B
Good
exercise
to
do
as
soon
as
it
sounded
like
alex
said
we're
a
little
ahead
of
him,
but
maybe
not
just
in
like
the
actual
technical
implementation
of
how
do
you
mush
the
things
together
and
then
maybe
maybe
we
don't
worry
about
that
right
now.
We
just
do
it
based
on
the
prioritized
jobs.
The
solution-
I
don't
know
but
yeah.