►
From YouTube: WG Groups and Projects 2020-06-25
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
C
C
C
That
that
is
not
the
best
thing
to
do
to
call
them
teams
just
because
it
limits
what
they
are
and
also
kind
of,
is
pointless,
I
guess
not
quite
as
but
not
necessary
for
merging
groups
and
projects
together.
So
maybe
Melissa.
You
can
talk
a
little
bit
more
about
what
specifically,
we
would
do
for
this
issue.
If
this
is
just
like
the
cross
sharing
stuff
that
we
were
talking
about.
A
Yeah,
so
basically,
this
is
the
I
think
part
of
the
complication
of
like
why
groups,
projects
and
it's
all
kind
of
conceptually
difficult
right
is
because
there's
multiple
use
for
groups
right.
So
we've
talked
about
the
concept
of,
can
we
kind
of
enable
workflows
where
people
create
groups
and
then
tell
us
what
they're
for
right
and
whether
that
be
there
for
team
management
or
there
for
source
code
management
right
or
there
for
project
management?
A
Please
stop
doing
something
like
that
right,
like
where
you
create
a
group-
and
you
say
what
is
this
for,
and
in
this
case
it
would
be
like
it's
for
groupings
of
people
and
we
just
present
them
with
a
view
of
a
group.
That's
smaller,
it's
not
the
full
scope
of
everything
that
a
group
can
do
right,
but
we
started
to
kind
of
tailor
it
towards
a
specified
use
case.
Now.
We've
talked
about
this
for
like
project
management
right
and
for
kind
of
like
having
your
repos
and
all
your
technology
stuff.
A
So
that's
where
I'm
coming
from.
As
far
as
like
how
it
relates
back
to
this
workgroup
in.
D
A
C
Think
the
problem
there's
two
two
problems:
one
is
the
we
do
things
at
the
group
level
that
you
can
only
do
at
the
project
level.
I'm,
probably
vice-versa,
so
like
that's,
consolidating
things
together.
Groups
by
themselves
are
not
useful
to
be
a
team
thing
until
they
can
have
issues
and
like
wiki's
and
all
like
all
this
stuff
merge
together,
because
I
can't
manage
my
I
can't
do
project
management
at
the
group
level
because
issues
don't
live.
E
C
The
group
level
does
that
make
sense
and
I
think
like
that's
where
I
it
feels
like
the
best
path
is
to
figure
out
technically
how
to
have
parity
between
groups
and
projects,
and,
while
like
doing
that
on
the
backend
do
a
bunch
of
I'm.
Sorry
Michael
is
serving
a
solution,
validation
and
UX
work
to
figure
out
what
the
user,
how
these
would
want
to
assume
that
and
set
it
up
or
use
it
if
that
makes
sense,
it.
A
C
C
A
I
think
going
back
right
separating
out.
Basically
how
you
manage
permissions
from
how
you
manage
resources
would
be
good
from
the
access
right
from
our
perspective
of
like
I
know.
It
doesn't
help
you
for
a
plan
right,
but
it
would
help
us
from
the
access
perspective
of
just
making
things
simpler
of
like
these
are.
A
To
manage
permissions
right
and
you
share
them
over
to
these
resources.
It
starts
to
make
things
a
lot
more
cleared
and
then
I
think.
Once
we
have
that
anchor
of
like
groups
of
people,
we
can
build
on
that
to
basically
use
them.
However,
you
need
to
for
planning
project
management
and
I
do
think.
It
makes
sense
to
separate
all
of
these
out,
because
that's
kind
of
like
what
people
are
doing,
except
we're
not
giving
them
good
tools.
F
I'm
wondering
can
we
have
we
do
we
have
the
concept
of
setting
permissions
at
a
certain
level
or
namespace
in
that
whole
hierarchy
and
then,
like
permissions,
rolling
down
or
something
like
that,
we
clear
on
those
rules,
as
you
could
say
already
at
the
top
and
then
build
as
much
as
you
want
underneath
and
they
would
all
consume
one
permission
setting
from
the
top
or
something
like
that.
Yeah.
A
F
D
Okay,
you
spoke
about
and
the
advantage
of
condensing
everything
down
to
one
thing
as
we
spoke
about
before
routes
and
projects
becoming
namespaces,
you
can
attach
resources
to
them.
Does
that
also
solve
the
problem
that
you
shared
your
video
about
last
Friday,
whereby
you
basically
want
people
to
view
stuff
like
from
there?
Maybe
sibling
groups
within
that
hierarchy?
Yeah.
C
That's
a
that
does
not
solve
that
problem.
What
we
talked
about
in
slack
was
the
permissions
problem
so
like
the
first
step
would
be.
If
you
consolidate
all
resources
and
they're
available
in
namespace,
you
can
turn
them
on
or
off
they're
isolated
from
one
another.
Such
that
like
it
is,
is
easy
to
disable
or
enable
certain
resources
that
are
available
within
a
specific
place.
C
Then
the
next
step
would
be.
How
do
you
assign
a
maybe
maybe
this
is
limited,
only
certain
resources
that
are
assignable
like
an
epoch
or
an
issue
or
a
merge
request.
But
how
do
you
assign
a
resource
to
a
sibling
group
right,
our
sibling,
namespace?
That's
what
was
called
for
now,
so
that
it
shows
up
both
in
the
sibling
namespace
as
well
as
in
the
canonical
name.
Spacer
was
created,
so
that's.
C
It's
working
based
on
what
customers
have
said
that
they
would
like
to
do
or
see
they
more
or
less
want
to
be
able
to
have
a
single
resource
show
up
into
sibling
namespaces
right.
So
if
you
have
a,
if
you
use
a
namespace
for
a
team
and
you
use
a
namespace
for
repo
the
the
chain,
the
like
the
repo
might
have,
many
teams
working
on
it
or
namespace
is
contributing
to
it.
C
So
you
would
want
the
issue
to
be
there,
but
since
the
change
is
happening
against
that
repo,
but
then
you
would
also
want
to
be
in
the
team's
namespace,
so
they
could
associated
to
an
iteration
they
could
track.
You
know
their
capacity
playing
and
do
all
that
stuff
against
that
issue
within
their
own
namespace,
without
having
to
like
context
which
out
yes,.
D
D
Band
members
get
removed
from
from
groups,
and
can
we
can
we
solve
the
same
problem
but
more
in
like
a
way
that
would
be
familiar
with,
like
our
existing
commission
structure,
so
I
I
won't
go
into
detail
because
it
will
probably
get
to
gets
too
complicated
by
talking
about
groups,
but
I.
Think
one
of
the
things
we
suggested
in
slack
last
week
was
instead
of
assigning
the
group
that
you
want
to
share
with
to
an
issue.
C
Problem
with
that
is,
is
think
about
the
use
case
of
our
own
team,
where
we
have
the
gate
lab
project.
I
have
my
issue
board
at
the
top
level
group,
but
in
the
proposed
namespaces.
The
way
it
would
work
is
we
have
all
of
our
issues
and
they
get
that
project
in
a
separate
namespace
tree
I
have
my
team,
which
is
like
the
project
management
team.
C
I,
don't
want
to
see
the
40,000
issues
that
are
in
to
get
lab
project
or
in
the
get
lab
group
right,
even
though
my
team
has
would
technically
have
permission
to
see
them
all.
I
want
to
see
things
that
my
team
is
responsible
for
doing,
because
a
lot
of
things
are
like
just
noise
and
it
also
slows
down
search,
there's
a
lot
of
things
that
aren't
applicable
to
my
team
and
so
just
like
having
all
that
stuff
show
up.
C
Even
though
my
team
has
access
to
it
and
permissions
to
view
those
things
somewhere
else,
does
it
doesn't
really
help
like
the
concept
of
you,
we
basically
still
have
to
rely
on
labels
for
team
assignment.
That
makes
sense
and
I
think
that's
where
what
we're
trying
to
get
around
or
solve
for
is
how
can
we
have
the
concept
of
a
team?
Have
the
team
see
the
things
that
only
they
need
to
be
working
on
or
scheduling
and
and
not
see
everything
else
yeah
if
they
have
permissions
yeah
like
in
their
team
space.
A
C
D
I
think
that
sorry,
I
gotta
get
the
point.
Ok,
that
makes
sense,
but
I
also
feel
that
assignment
still
doesn't
feel
like
the
way
to
solve
that
problem.
To
me
in
that,
it's
quite
restrictive
in
that
you
only
see
things
you're
assigned
to
now.
I
guess,
there's
also
a
use
case
whereby
you
would
want
to
create
a
board,
which
is
all
of
the
things
that
you
have
visibility
or
responsible
for
it
isn't
in
directly
in
the
project
that
you're
in
at
that,
like
given
point
in
time.
So
imagine.
D
Imagine
like
me
me,
individually,
so
I'm
the
engineering
manager
for
for
access
and
import
now,
if
it
would
be
nice
if
I
could
create
if
they
were
kind
of
two
different
to
different
groups,
I
would
like
to
have
like
single
visibility
of
both
of
those
but
I
don't
want
to
have
to
be
assigned
to
every
single
issue
in
the
other
group
just
to
show
it
to
me.
I
would
like
to
basically
be
able
to
create
a
board
which
just
gives
me,
which
is
just
basically
scoped
to
those
two
to
those
two
different
groups.
E
Wouldn't
that
just
be,
instead
of
having
it
sort
of
a
group
label
in
you're
sort
of
filtering
of
the
board,
wouldn't
it
just
be
instead
of
a
group
labor,
it
would
be
like
a
group.
You
would
have
some
sort
of
like
like
primitive.
That
meant
this
group
and
everything
that's
sort
of
owned
by
that
group.
C
C
F
A
C
But
that
means
that
we
could
never
we
we,
it
wouldn't
solve
our
problem
because
we
have
an
open
core
business
model
and
I
know
like
we're
unique
in
this.
But
it's
still
the
same
kind
of
thing
of
we
have
to
have
the
issues
live
in
a
project.
So
it's
easy
for
a
shared
project.
So
it's
easy
for
the
water
community
to
contribute
and
see
what's
going
on
right.
C
D
F
A
C
If
you
look
at
the
team
in
isolation
and
think
about
the
use
case
of
well
just
let
the
team
create
issues
in
their
own
namespace
and
then
we
could
optimize
for
like
linking
issues
in
that
namespace
to
a
sibling,
merge
requests,
but
it
still
doesn't
solve
the
problem
of
even
like
we,
wouldn't
it
wouldn't
be
valuable
to
me.
You
didn't
get
loud
right
if.
F
B
A
But
what
I
will
say
is
like
if
you
look
competitively
at
the
enterprise,
agile
tools
right
most
of
them
have
a
concept
of
a
team
and
the
team
space
and
a
list
of
users
that
are
a
team
right
metrics
around
those
people.
So
that's
something
to
be
aware
of.
Actually
JIRA
does
not
have
this
and
that's
a
big
customer.
Ask
Abdera
and
they've
now
started
to
kind
of
build
some
of
that
framework.
A
C
You
know
the
reports
will
work
is,
if
you
create
your
top
level
group
and,
let's
say,
there's
a
subgroup
and
a
project,
and
then
you
have
an
issue
that
can
be
assigned
to
this
iteration
right.
If
it's
a
sign
of
that
iteration,
the
iteration
is
gonna,
show
up
down
in
this
project
and
be
scoped
to
just
the
issues
that
are
associated
to
the
iteration
from
the
project's.
So
like
this,
you
could.
You
could
basically
get
a
team
level
report
here
if
the
issues
were
to
live
here
but
like
for
me
as
a
product
manager.
C
What's
not?
Which
ones
do
we
want
to
track
velocity
against
them?
Which
ones
do
we
not,
and
it
gets
a
lot
simpler
if,
like
I,
can
just
have
my
team.
My
issues
that
my
team
is
responsible
for
in
one
place
so
that
I
can
look
at
one
report
and
not
have
to
do
a
bunch
of
filtering
I
know
that
it's
just
my
team,
but
we
can't
have
that
in
get
lab
unless
we
a
change.
C
C
Just
that,
like
that's,
where
the
community
would
have
to
go,
look
for
issues
right.
They
wouldn't
be
able
to
go.
Look
at
the
get
lab
project.
They'd
have
to
go.
Look
at
you
know
and
I
think
this
is
like
the.
The
crux
of
the
problem
is:
where
you
have
you
have
one
group
of
people
who
are
looking
at
repo
and
the
issues
that
are
gonna
be
changing
things
on
that
repo,
which
would
be
like
the
water
community.
E
So,
instead
of
now,
where
you're
assigned
a
label
of
like
a
group
label
to
an
issue,
if
somehow
behind-the-scenes,
that
actually
meant
that
you
assign
that
issue
to
a
group,
and
so
the
group
took
some
sort
of
ownership
of
that
issue.
And
then
you
had
like
the
gitlab
project
which,
as
we've
been
talking
over
the
weeks
that
it's
somehow
magically
is
a
group
project,
sort
of
being
one
one
sort
of
Union,
and
that
is,
it
has
sort
of
kind
of
all
these.
C
Yes,
so
that's
I
mean
that's
sort
of
within
this
issue.
What
I
was
exploring,
and
this
is
where
I
might
be
messy.
We
talked
at
length
and
slack
but
like
if,
if
I
have
my
top
little
name
space,
let's
say
this
is
the
gate,
lab
or
name
space
right,
and
then
let's
say
that
this
over
here
this
xam
name
space
is
the
gitlab
project
that
has
the
repo
in
it,
and
it
has
all
the
issues
and
the
issues
live
there
right.
E
D
There's
I
think
there's
two
different
problems
here
that
it
seems
to
me.
One
is
like
sharing
resources
across
siblings
and
then
another
one
is
what
gave
described
in
terms
of
team
reporting,
possibly
with,
like
the
gate
lab
setup,
where
all
issues
are
in
a
single
assumable
project
and
then
I'm
wondering
if
so,
I
think
the
assign
it
to
an
issue
assigning
a
team
to
an
issue.
It
makes
sense
from
a
reporting
point
of
view.
I
think
it
could
solve
that
problem
by
don't
think
that
in
itself
souls
the
sibling
problem.
D
So
imagine
in
the
example
you've
got
I,
don't
even
get
to
screen
share
that
I've
got
okay,
okay,
where
if
in,
for
example,
I
I
am
the
owner
of
X
B,
Y,
namespace
and
I
want
to
create
a
issue
board.
That
shows
me
everything
in
that
namespace,
but
everything
also
in
X
am
namespace,
but
not
just
stuff.
That's
assigned
to
me.
I
just
want
visibility
of
all
of
it.
I
don't
want
to
have
to
go
into
X
a.m.
and
assign
everything
to
my
team.
D
Equally,
you
don't
want,
to
give
me
permission
to
view
everything
for
X
namespace,
because
then
I'm
going
to
be
able
to
see
everything.
So
it
feels
like
what
you
would
need
to
do
is
you
would
need
to
do.
You'd
need
the
ability
to
create
an
issue
board
somewhere,
presumably
in
my
own
namespace
X
B
Y,
where
I
could
scope
that
issue
board
to
various
groups.
I'm
interested
in
so
I
could
say.
Fullest
issue
will
show
me
all
issues
from
X,
B,
Y
and
also
all
issues
from
X
a.m.
D
C
That
would
solve
50%
of
it
and
I
think
it's
something
that
folks
talked
about
wanting,
which
is
scoping
issue
boards
or
boards
as
a
whole,
two
different
projects,
so
that
makes
sense
and
I
think
that's
a
step
in
the
right
direction.
So
I
don't
disagree
with.
That
is
a
is
an
MVC,
but
then
the
next
question
is
like:
are
we
gonna
force
users
to
always
rely
on
a
heavy
use
of
filters
in
order
to
scope
things
to
just
the
things
that
they
want
to
see
when
they
have
resources
shared
like
in
that
manner?
E
C
Whether
that's
issues
issue
board
epics
roadmap
I,
have
to
add
in
filters
to
make
it
meaningful
because
there's
so
much
stuff
which,
if
that,
if
that's
what
we
decide,
we
have
to
do,
then
the
solution,
I
think
Kristen.
You
said
like
well,
let's
just
create
some
safe
filters
capability,
so
you
can
save
it
and
apply
it
globally
and,
like
that's,
also
something
to
have
been
talking
about
so
I'm,
not
opposed
to
any
of
those
things.
I
think
it
would
really
come
down
to.
C
This
is
where
I
was
proposing
and
we're
running
out
of
time,
like
I
would
like
to
start
doing
some
usability
and
UX
solution,
research
on
what
wouldn't
be
the
best
thing
for
the
end
users,
because
I
think
we'd,
like
determined
that
we
can
merge
groups
and
projects
into
a
namespace
and
have
all
the
resources
live
there.
Is
that
correct?
C
So
if
they
go,
we
if
we
know
we
can
technically
do
that.
That's
that
that's
a
technical
feasibility
piece,
I
think
and
then
the
next
piece
is
well.
What's
the
ideal
user
experience
and
if
we
were
to
just
do
that
blanket
sharing
like
from
X
am
into
X
X
py
and
let
you
scope
all
erased
reports
of
the
groups
that
you
have
shared
access
to.
Would
that
be
sufficient
for
users
and
I?
Think
that's
I
would
really
like
to
work
with
you
Mike
figure
out
how
we
want
to
do
that.
Research
and.
A
Yeah
I
think
one
other
piece
that
I'm
curious
about
is
some
of
these
problems
that
we
have
right,
where
we
have
too
heavy
heavily
use
filters,
because
we
have
like
one
big
group
that
we're
all
in
and
all
our
stuff
is
there
I
wonder
if
that's
a
unique
problem
to
sort
of
that's
the
problem
for
customers
right,
because
maybe
the
solution
is
easier.
If
people
have
things
more
divided
than
us.
B
Yeah,
it's
a
great
question,
so
I
was
also
gonna.
Ask
if
it
feels
more
painful
to
us
because
of
the
way
get
lab
structured
like
we
have
to
do
that
and
there's
a
lot
of
heavy
filtering.
We
do,
but
my
assumption
I'd
like
to
validate
that
other
customers
in
other
tools
face
the
same
problem
so
for
our
customers
that
are
using
get
lab
for
SCM
and
see
OCD,
but
JIRA
for
project
management
cheers
the
same
way.
You
have
to
use
a
lot
of
filtering.
They
kept
jaql
as
a
portable
object
to
let
you
filter.
B
B
C
C
But
we
still
that's
like
a
real,
tangible
problem
and
the
duplication
of
like
the
first
thing
we
can
change
and
we
don't
have
to
necessarily
change
the
core
user
experience
at
this
point
for
that,
just
making
those
resources
available
at
each
place
and
then
doing
something
behind
the
scenes
to
the
of
them
use
the
same
basic
shared
construct.
So,
okay.