►
From YouTube: Simplify Groups and Projects WG - 2020-08-21
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,
so
I
stole
the
first
spot
because
I
wanted
to
start
us
off
with
a
discussion
of
a
little
bit
of
process
and
how
we
move
forward
as
efficiently
as
possible.
A
Keeping
in
mind
that
I
think
we
should
still
stick
to
our
goal
of
of
having
a
proposal
sort
of
like
a
solution,
validation,
update
to
opportunity,
canvas
and
a
proposed
mvc
and
path
forward
by
you
know
mid
to
late
october,
and
so
I
was
wondering
like
if
there's
a
more
efficient
way
for
us
to
work
towards
that
and
an
observation
I've
had
is
that
it.
A
It
feels
like
we
struggle
making
progress
30
minutes
at
a
time
each
week,
oftentimes
we'll
run
out
of
time
and
there'll
be
a
deeper
discussion
that
we
need
to
have
about
a
particular
issue
or
component
of
this,
but
we'll
butt
up
against
time.
And
then
I
think
everyone.
Maybe
this
is
happening
and
I'm
not
aware,
but
I
think
everyone
kind
of
has
their
normal
job
right,
they're
going
back
to
and
work
to
do
or
go
to
bed
if
you're
alex
and
then
all
of
a
sudden.
A
It's
it's
the
next
thursday
right,
and
so
I
don't
have
a
specific
solution.
You
know
I'd
love
to
talk
about
this
and
see
how
others
feel.
A
But
one
thing
I
was
thinking
of
was
you
know
we
could
transition
this
meeting
into
more
of
a
of
a
check-in
and
then
ask
a
few
of
the
core
folks
who
I
think,
are
really
key
to
coming
up
with
that
solution
to
maybe
either
spend
time
together,
synchronously
or,
if
possible,
sort
of
commit
to
commit
time
to
sort
of
move
things
forward,
asynchronously
so
that
in
a
given
thursday
meeting
we're
reacting
and
reviewing
content
that's
been
prepared
prior
to,
instead
of
just
having
an
open-ended
discussion
each
week.
A
So
that's
that's
like
abstract,
but
I'd
love
to
hear
everyone
else's
thoughts
and
if
there's
a
way
we
can
make
this
as
efficient
as
we
possibly.
A
B
I
agree
with
that.
B
I
I
think
I
would
like
to
mean
we
need
to
commit
more
time
to
it
to
figuring
out
like
what
what
the
actionable
things
are
both
like
for
an
ideal,
end
state
and
then
also
the
envy's,
like
the
first
few
mvcs
that
we
would
want
to
take
to
get
there.
It's
basically
what
you
have
to
fill
out
on
the
opportunity.
Canvas
anyways
like
what
is
the
solution?
B
What's
the
smallest
first
step,
you're
going
to
do
what
are
you
going
to
do
in
three
months
that
basic
sort
of
thing
and
then
like
what
would
be
the
go-to-market
strategy
for
that?
And
I
also
think
there's
a
sense
of
urgency
on
this,
because
I
got
off
with
one
of
the
customers
that
I've
been
sharing.
Videos
with
and
they've
decided
to
halt
adoption
get
lab
until
we
solve
this
problem.
B
Basically
like
how
do
you,
how
do
you
get
roll
up
reporting
and
how,
where
I
have
a
team
member
who's
working
across
many
top
level
groups,
and
I,
as
a
project
manager,
I
don't
have
visibility
into
that
in
one
central
place.
So
it's
starting
to
it's
been
naturally
coming
up.
As
like,
a
pretty
big
block
or
two
adoption
folks.
B
C
C
I
agree
that
that
if
the
thursday
meeting
is
essentially
a
catch
up
and
then
we
are
trying
to
spend
more
time
actually
working
outside
of
the
general
weekly
meetings
and
like
gabe
says,
there's
a
sense
of
urgency
at
this
point,
where
the
the
deadline
for
the
working
group
sort
of
creeping
up
pretty
quickly
so
yeah,
I
feel
like
we
sort
of
spent
three
months
or
so
spinning
our
wheels
a
little
bit
exploring
it's
probably
time
to
start
trying
to
get
something
down.
B
I
do
know
that
daniel
said
that
he'd
be
open
to
some
synchronous
time,
but
he
also
is
not
sure
how
much
capacity
he's
going
to
have
in
the
future
because
he's
starting
the
category
of
maturity,
stuff,
which
I
do
think
you
know.
He
said
that
mike
you
had
talked
and
provided
some
feedback
that
the
work
there
would
be
helpful
and
the
solution
for
this-
and
I
agree
quite
a
bit
so
I
did
like
I
think
that
would
be
a
very
valuable
input.
B
D
Yeah
yeah,
I
think
part
of
the
problem
is,
maybe
I
don't
know
I
don't
I
think,
generally,
we
don't
know,
or
we
can't
all
picture
in
our
heads
the
same
top
problems
that
people
have
and
why
like,
if
our
objective
is
to
simplify
groups
and
projects,
I
think
like
not
knowing
the
specific
problems
and
how
to
incrementally
start
to
approach.
Those,
I
think,
is
one
of
the
gaps
and,
personally
my
knowledge
right
now,
and
I
think
the
category
of
maturity,
scorecard
validation
will
help
uncover
top
problems
that
we
can
incrementally
approach.
D
Some
of
the
brainstorming
I've
seen
is
like
recommending
some
pretty
big
changes
and
there's
a
risk
in
that
too.
Right.
B
B
Validation
issue,
the
problems
that
have
to
be
solved
and
there's
really
just
two
that
come
down
to
two
core
things,
and
so
at
least
that's
what
I
synthesized
from
talking
to
customers,
the
last
three
months
and
reading
things
and
having
people
be
upset
with
us
and
all
this
other
fun
stuff
which
you
know
is
life,
but
I'm
happy
to
walk
through
that.
If
that
would
help,
because
the
thing
is
also
is
like
there's
so
many
different
possible
solutions.
B
This,
I
think,
is
the
other
challenging
aspect
of
this,
like
there's
lots
of
different
ways
to
solve
it,
and
I
I
don't
want
to
be
like
too
prescriptive,
because
I
want
to
based
on
what's
going
to
provide
the
best
user
experience
and
what's
going
to
be
the
best
from
a
long-term
engineering
standpoint.
So
do
you
want
me
to
share
my
screen
and
just
like
talk
through
those
things?
Yeah
that
that'd
be
great
cool?
B
Go
for
it
so
like
as
part
of
this
validation,
this
is
sort
of
like
what
we
need
to
answer
before
we
put
together
the
opportunity,
canvas
and
flesh
it
out.
It's
like
you
know:
business
viability,
technical
feasibility.
We
talked
about
stuff,
the
these
are
all
real
customer
use
cases
like
written
in
the
words
of
the
customer
directly
from
the
customer
in
most
cases.
So
I
it's
not
me,
like.
I
guess
like
like
trying
to
create
some
abstract
job
story.
B
This
is
straight
up
the
use
case,
and
it's,
it's
really
is
interacting
with
objects
across
top
level
groups
or
sibling
hierarchies,
and
not
just
like
interacting
by
having
them
be
shareable
across
roll
up
into
that
sort
of
thing.
So
this
use
case
was-
and
this
is
from
the
customer
that
is
pausing.
Gitlab
adoption
need
to
track
multiple
milestones
across
multiple
ethics
that
may
or
may
not
be
related
and
may
or
may
not
be
in
the
same
top
level.
B
Group
customer
proposed
solution
was,
if
I
could
have
an
epic
board
that
shows
all
epic
sub
fx
milestones
on
a
gantt
chart
along
with
percent
complete
or
how
much
has
been
accomplished
and
ability
to
drill
down
into
issues
tied
to
milestones,
and
this
is
a
self-managed
customer
who
like
if
we
built
this
at
the
instance
level,
then
that
that
would
be
a
it
could
work,
but
it
it
wouldn't
work
for
com
and
I
think,
we're
trying
to
find
a
solution
that
would
work
in
both.
C
This
next
one,
okay,
so
sorry
guys,
what's
the
issue
with
that
one,
just
to
sum
it
up
for
me
because
it's
nearly
10
o'clock
at
night.
B
Sure
they
have
consider
this-
I
put
this
down
here.
They
have
these
top-level
groups
they're
his
team
works
across
these
top-level
groups
and
there's
issues
across
these
top
level
groups
and
epics
and
milestones
and
there's
no
way
for
him
to
project
manage
in
one
place
where
there
are
these
things
across
these
top
level
groups
right
so
he's
like.
I
want
to
be
able
to
see
a
roll-up
of
all
the
issues
and
my
entire
team,
but
because
those
things
are
in
these
different
places,
you
can't
have
one
worldview
and.
B
That
that's
what
they
could
do,
but
in
their
self-managed
they
basically
have
set
it
up
so
that
they
have
15
different
top-level
groups
that
represent
their
their
value
streams
or
their
lines
of
business.
And
so,
like
our
solutions,
saying
hey
like
stuff
all
these
into
one
top
level
group.
They
don't
like
that
because
they
want
to
provide
least
privileged
access
to
things
and
so
like.
B
You
could
also
do
that
within
the
top
level
group,
but
it's
sort
of
it
defeats
the
purpose
of
ever
having
more
than
one
top
level
group
within
self
management.
Since,
if
that's
what
the
solution
is
right,
which
maybe
that
that's
the
case
but
yeah-
and
let's
see
here,
this
is
more
like
labels,
but
we
have
the
same
labels
across
groups
like
again
all
the
same
labels
across
all
type
level
groups
that
they
have
to
have
to
keep
in
sync
with
one
another.
B
They
were
all
within
one
top
level
group
that
would
solve
the
problem,
probably
as
well,
and
this
is
where
we
get
into
pull
up
a
board
that
has
every
developer
in
my
team
across
all
groups,
not
just
top
level
group
they
align
to.
B
B
Roll
it
up
into
one
thing:
ability
to
have
others
see
the
same
information
who
may
not
be
developers
I.e,
non-technical
project
managers.
B
This
is
where
he
was
saying
he
used
tfs
at
one
point,
and
he
there
was
this,
like
extension,
that
let
you
build
a
data
layer
and
model
on
top
of
the
tfs
data
and
visualize
it
in
a
more
agile
way.
So,
instead
of
like
sharing
things,
it's
almost
like
a
super
super
set
data
data
model
view
for
building
out
the
reports
you
wanted,
which
is
an
interesting
idea.
B
B
How
can
we
have
them
align
or
track
work
against?
One
milestone,
same
milestone,
issue
board,
multiple
groups
or
project
scopes.
We
have
three
top
level
groups
slips
procs
customer
related.
There
are
issues
I'm
assigned
to
in
subgroups
subprojects
in
each
of
those
top-level
groups.
My
manager
wants
to
see
my
workload
in
a
board
and
those
are
the
colleagues
of
course.
So
this
gets
the
heart
of
sort
of
what
this
problem
is
up
here
too,
and
this
is
from
a
separate
customer.
B
B
This
is
another
one
and
the
wii
field
is
paid
acutely
gitlab,
especially
for
the
non-technical
folks
or
the
non-r
d
folks,
who
span
whose
work
spans
across
the
get
lab
com
and
the
git
lab
or
group
their
top
level
groups.
You
can't
have
an
issue
from
the
or
group
be
assigned
to
an
epic
in
the
dot
com
group.
B
You
can't
even
have
it
assigned
across
like
sibling
groups
within
the
same
top
level
group.
B
This
is
from
one
of
our
huge
customers,
a
different
one,
one
epic
tie
to
two
upcoming
releases,
so
this
would
be
milestones,
but
I'm
assuming,
which
makes
sense,
and
we
can
do
that
now.
But
then
you
have
two
features
across
two
application:
domains:
a
and
b
each
app
has
its
own
git,
lab
instance,
projects
or
top
level
group.
I'm
guessing
what
instances
first
feature
for
app
a
basically
saying
like
how
do
you
link
all
this
stuff
together
when
it
spans
these
different
domains?
B
So
that's
why
this
theme
for
this
problem
to
solve
is
interacting
with
objects
across
topical
groups,
sibling
hierarchies
or
rolling
things
up
together
into
a
consolidated
way
to
view
that
report
or
view
that
information
and
then
the
second
big
problem
to
solve
is
one
that
we've
talked
about
is
removing
friction
and
duplication
between
groups
and
projects,
so
both
from
a
usability
standpoint
and
from
a
wasted
effort
standpoint.
This
is
a
pretty
big
one
like
we
need
issues
at
the
group
level.
We
need
epic
project
level.
We
need
iterations
the
project
level
group
wikis.
B
We
need
those.
We
need
group
level,
issue
templates,
group
level,
snippets
group
level,
integrations
group
level,
design
management,
design,
management
and
epics
itself.
So
like
it's
the
sort
of
thing
where
the
lines
are
becoming
increasingly
blurred,
but
we're
duplicating
effort,
it
makes
it's
led
to
a
copious
amount
of
defects
for
getting
to
pass
the
right
path
between
a
group
in
a
project
or
like
having
to
write
two
different
queries
for
groups
and
projects.
B
Instead
of
one
query
that
gets
you
like:
all
the
descendants
and
a
confusing
user
experience,
because
people
don't
know
what
a
group
is,
they
don't
know
what
a
project
is.
I
was
had
to
explain
what
a
project
was
to
another
customer
this
week
and
they're
like
what's
a
project.
B
I
was
like
well
it's
where
your
repo
is,
and
it's
also
where
your
issues
are,
and
it
was
just
a
very
confusing
thing
to
them,
because
it
wasn't
their
definition
of
a
project
either.
But
I
won't
even
go
into
the
proposal
below,
but
are
these
like
mike
alex?
Do
these
make
sense
or.
D
They
they
do.
I
I
think
where,
where
you're,
proposing
a
solution
validation,
I
think
it's
really
important
actually
look
at
the
proposal,
because,
if
I
understand
it
correctly,
you
and
daniel-
and
maybe
even
marcus,
also
are
proposing
something
very
similar
just
with
different
names,
but
conceptually
it's
a
space
or
what
daniel
has
called
a
namespace
container
in
some
of
his
flows.
D
I
think
the
gap
in
my
understanding
right
now
is
like
how
to
take
what
we
have
in
the
current
product
and
introduce
this
new
concept
in
a
way
that
doesn't
just
add
more
more
more
confusion,
more
usability
problems,
which
I
think
a
lot
of
the
confusion
around
groups
and
projects,
is
basically
usability
issues
in
the
current
product.
But
have
you
looked
at
daniel's
proposal?
Did
you
see
similarities
between
what
you're
proposing
and
what
he's
proposing
and.
B
Yeah
I
opened
it
up
and
it
is
it's
a
similar
proposal
like
and
that's
where,
like
I
don't
know,
if
introducing
teams
or
this
other
construct
would
be
helpful
or
more
problematic
on
top
of
groups
and
projects,
I
could
see
if
we
had
spaces
and
then
adding
teams
and
teams
or
like
the
way
you
get
permissions
in
the
spaces,
because
I
was
on
a
demo
with
another
customer
this
week,
where
they
have
one
whole
hierarchy.
That
is
just
their
permissions
like
levels
and
they're
different
teams
and
basically
they.
B
They
then
use
group
sharing
to
share
the
groups
that
need
explicit
access
into
the
hierarchy,
this
other
hierarchy
that
has
all
of
their
their
content
and
the
repos
and
stuff
in
it,
so
that
that's
essentially
like
a
the
way
github
approaches
teams,
but
the
the
his
proposal
didn't
really
touch
on.
Like
the
the
first
thing,
which
is
like,
how
do
you
do
the
the
sharing
right
like?
How
do
you
get
things
to
roll
up?
You
know
if
I'm
looking
at
this
and
let's
say
that
at
some
point
we
do
have
spaces.
B
D
Think
that
that's
the
concept
of
the
org
that
he's
proposing-
maybe
it's
not
super
clear
in,
like
the
the
workflow,
I
think
the
workflow
is
kind
of
like
thinking
through
how
to
get
it
set
up,
because
if,
if
somebody
can
reason
about
how
to
set
it
up,
they
can
reason
about
how
the
structure
works,
how
the
permission
structure
works.
But
the
idea
is
that
an
org
is
a
collection
of
spaces
and
you
can
have
shared
resources
across
spaces
or
I
think
what
he
called
a
name
space,
but.
B
Yeah
the
space
that
would
that
would
work,
and
then
you
would
still
have
to
have
like.
If
you
wanted
to
have
things
like
a
board
right
everything
roll
up
to
a
board,
then
you
would
have
to
have
the
the
organization
be
able
to
own
some
of
these
resources
too,
and
so
I
think
that's
where
really
like.
What
that
is
is
just
pushing
that
up
to
another
level
of
like
are:
are
we
basically
just
pushing
it
up
to
another
organizational
construct?
That
then,
has
limitations
right?
B
What
happens
when
you
have
when,
when
a
company
has
two
organizations
they're
like
hey,
I
work
across
these
two
organizations
and
I
can't
see
my
data
roll
up
right
like
what
do
you
do
at
that
point,
then,
because
I
know
that
that
will
happen
and
so
like.
If,
if
that
is
the
the
most
logical
solution
and
the
easiest
to
implement,
then
that's
fine.
I
know
sid
recently
proposed
the
like
pushing
some
of
the
instance
level
admin
settings
into
the
top
level
like
some
sort
of
a
top
level
group.
B
So
that
way,
there's
not
disparity
between
self
manage
and
sas,
and
then
sas
groups
would
have
more
flexibility
in
terms
of
configuring,
their
everything
downstream.
So
that
could
work,
and
I
think
that's
where,
like
in
terms
of
getting
there,
I
I
almost
like
sort
of
want
to
there's
two
options:
one
we
can.
B
We
can
introduce
this
new
thing
and
these
new
constructs
or
the
other
option
is
we
look
at
this
and
we
we
fix
this
duplication
problem,
basically,
so
that
behind
the
scenes
there
is,
there
is
no
difference
between
groups
and
projects
and
in
the
user
experience
there
is
no
difference
between
groups
and
projects,
and
then
you
can
just
change
the
name
and
say
now.
These
are
all
spaces,
because
there
is
no
difference.
If,
if
literally
you
have
the
same
features
and
functionality
at
the
group
level,
you
have
the
project
level.
B
The
only
difference
is,
you
would
be
able
to
maybe
control
some
things
for
inheritance.
You
know
of
how
things
roll
down
some
shared
configuration
for
things
that
you
know
roll
down,
but
that
would
be
the
same
in
all
like
all
places.
That's.
D
Another
option:
yeah:
do
you
know,
do
you
know
some
of
the
problems
that
github
users
might
run
into
with
how
that
permission
structure
works
like
does
it
have
flaws
and
yeah
just
wondering
what
do
we
know
about
github's
permission
structure
and
how
people
use
it.
B
It
works
because
all
it
is
is
permissions,
it's
nothing
else.
So,
like
you
don't
have
like
you
can
create
a
team
of
admins.
You
can
create
a
team
of
whoever
and
they
get
certain
access
levels
to
the
projects
they
get
added
to.
But
there
is
no
in
github
there
is
no
aggregated
roll
up
across
projects.
There
is
no.
I
want
to
see
all
of
my
issues
across
all
the
projects
that
I
belong
to,
like
the
projects
at
least
the
last
time
I
use
github
they're
they're
very
siloed
right
from
one
another.
B
E
D
Yeah,
I
think
my
the
key
I'm
trying
to
find
to
unlock
the
doors
like
what
what
are
the
small
changes
we
can
make
to
our
current
experience?
Is
it
adding
a
another
layer
on
top
of
it,
an
org
layer
that
groups
can
roll
up
to
or
don't
we
already
do
that
like
what?
What's?
What
do
you
think
gabe
is
like
the
first
step
we
can
take
to
get
something
working
based
on
the
the
problems
that
you
had
stated
up
above.
B
Like
technical
approaches
there,
the
the
one
thing
that
would
change
is
if
we
rolled
out
organizations,
I
would
assume
that
all
of
the
namespaces
for
all
things
below
it
would
also
have
to
be
updated
or
changed,
which
would
impact
pretty
much
everyone
to
the
point
where,
depending
on
how
many
like
things
rely
on
where
our
namespace
is
and
all
their
code,
it
would
basically
require
massive
overhaul
to
everything.
B
It's
the
same
reason
why
we
haven't
merged
in
our
dot
com
group
into
our
dot
or
group,
because
it
would
be
catastrophic
admin
for
the
hundreds
of
projects
in
one
of
them.
So
I
see
that
being
a
problem.
There
might
be
a
way
to
solve
that,
but
it's
also
like
is
that
is
that
easier
or
less
of
a
lift
than
figuring
out
how
to
assign
an
object
from
like?
Let's
say
I
have
an
issue
in
subgroup
four,
and
I
want
to
assign
that
issue
to
subgroup
d.
B
B
Four
can
have
resources
assigned
like
issues
assigned
to
them
or
have
issues
from
this
be
attachable
to
epics
from
this,
but
that's
also
sort
of
a
pandora's
box
for
a
whole
different
set
of
reasons.
C
Yeah,
I
think
we
need
to
make
it
much
more
generic,
something
like
that
sounds
like
it.
It
might
work
for
issues
or
fx,
but
then
it's
not
going
to
work
for
every
other
type
of
resource
that
we
have.
You
know
you'd
have
to
go
through
individually
and
sort
of
solve
it
for
each
of
those
specific
examples.
Whereas
if
you
bake
it
into
the
sort
of
the
group
and
the
project
structure,
sort
of
the
membership
structure,
you
can
potentially
solve
all
those
problems
with
the
one
solution.
C
D
B
I,
if
I
yeah,
I
think,
that's
where
I
agree
with
that
and
if
I
were
to
look
at
it
one
like
one
problem.
I
think
this
whatever
the
solution
is
we'll
solve
this
one
problem,
but
this
one
problem
will
focus
the
solution,
which
is
how
do
I
solve
this
one
right
here,
like
we
have
three
top-level
groups,
there
are
issues
I'm
assigned
to
in
subgroups
subprojects
in
each
of
these
top-level
groups.
My
manager
wants
to
see
my
workload
in
the
board
and
those
of
the
colleagues,
of
course,.
C
So
I
think
I
think
it's
what
it's
what
we've
spoken
about
before
gabe
in
our
call,
where
it's
just
that
dag
it's
the
directed
cyclical
graph,
where
essentially
there's
a
whole
bunch
of
things
in
our
system
that
essentially
depend
on
other
things
and,
like
I
said
before,
epics
depend
on
sub-epics,
which
depend
on
sub-epics,
etc.
C
There's
all
that
type
of
thing
where
you've
got
this
nested
sort
of
graph
set
of
relationships,
and
I
think,
if
we
sort
of
try
to
structure
around
that
concept,
I
think
we
can
solve
these
sorts
of
issues.
I
think
there's
sort
of
the
bones
of
a
solution.
There.
C
A
This
is
too
much
to
ask
in
a
week,
so
maybe
it's
a
two-week
time
horizon,
but
like
the
two
of
you
and
maybe
daniel,
if
he
has
time,
spend
time
outside
of
our
weekly
this
to
refine
what
y'all
were
just
talking
about
like
and
and
sort
of
come
to
an
alignment
between,
especially
the
two
of
you
on
what
that
proposal
could
look
like
and
and
spell
it
out
in
a
little
bit
more
detail
and
then
propose
it
or
share
it
back
to
this.
A
The
bigger
group
here
that
would
require-
and
the
ask
I'm
making
here
to
be
plain
and
clear-
is
that
you're
probably
going
to
need
to
whether
you
do
it
singularly
or
not
like
spend
more
time
between
now
and
next
week
or
now
and
two
weeks
from
now
to
hammer
that
out
and
make
that
clear
and
as
detailed
as
necessary.
B
Yeah,
I
think
it
is.
I
think
that
the
to
mitigate
the
risk
like
this
is
where
the
for
for
this
solution,
it's
the
technical
feasibility
risk
that
I
would
flag
the
organization
like
adding
an
organization
on
the
top.
That
was
like,
probably
a
usability
business.
Viability
like
it
would
be
frustrating
for
a
lot
of
customers.
B
This
would
require
very
little
like
change
from
the
customer's
user
experience,
so
I'll
find
some
time
for
us
to
catch
up
alex
it
may
be
tomorrow
morning
when
you
wake
up,
that's
on
your
calendar
and
you
have
free
time,
yeah.