►
From YouTube: WG: Groups and Projects 06-18-2020
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
Cool,
so
it
is
june
18th-
and
this
is
the
groups
and
projects
simplify
groups
and
projects
working
group,
so
yeah
we
can.
We
can
jump
right
in
filling
out
the
agenda
in
real
time.
B
Sure
yeah,
I
haven't
had
a
lot
of
time
this
week
to
look
into
it,
but
marcus
is
away
this
week,
but
the
knowledge
team
is
currently
moving.
The
wiki
from
projects
into
groups
and
they've
gone
quite
a
way
into
that
process.
B
So
I'll
chat
with
marcus
next
week
about
how
he
actually
implemented
that
went
through
that
sort
of
process
and
sort
of
the
mechanics
of
his
actions
and
I'll
see
if
there's
some
sort
of
generalizations
we
can
take
out
of
that,
but
he's
part
of
this
working
group
that
is
away
this.
B
A
Is
it
worth
on
that
note?
Is
it
worth
looking
at
similar?
You
should
probably
already
have
but
similar
efforts
in
the
past.
I
think
from
last
week
you
mentioned
that
it
seems
like
a
lot
of
code
was
just
duplicated,
as
teams
opted
to
move
features
from
the
project
level
to
group
level.
B
Yeah
yeah,
it's
definitely
worth
starting
to
go
through
the
code
and
looking
for
those
sort
of
duplications,
I
have
looked
just
at
a
very
high
level.
Looking
for
file
names
that
are
kind
of
replicated
across.
You
know,
project
and
group
hierarchies
and
there's
quite
a
few.
There
yeah,
but
I
haven't
gone
through
them
in
detail.
C
Hey
yeah,
so
I
linked
in
this-
I
I
don't
think
I've
sure
shown
this
yet.
I
know
alex
commented
on
it
and
I
won't
share
my
screen,
but
you
can
kind
of
just
jump
in.
C
I
think
this
is
where
melissa
since
you're
here,
I
think
you
created
this
issue
originally
to
explore
using
groups
for
teams,
and
I
want
to
just
kind
of
show
like
how
this
could
work
and
also
highlight
why
we
should
be
thinking
about
this
as
well,
so
we're
about
to
release
iterations
into
gitlab
as
a
like
planning
feature,
and
we
put
it
at
the
group
level
for
now,
because
it
makes
the
most
sense
it'll
have
the
biggest
reach.
C
I
guess,
even
though
it's
like
some
folks
would
want
at
the
project
level.
But
all
that
to
say
is
like
my
team
has
issues
and
there's
no
way
to
like
view
a
like
just
my
team's
issues
in
the
iteration
report,
because
it's
at
the
group
level
and
we
could
add
filters
and
a
bunch
of
other
hacky
things
to
solve
for
that.
But
this
is
where
like.
C
If
we
had
a
separate
hierarchy,
that
was
just
like
teams
and
then
you
could
assign
an
issue
that
was
created
in
one
group
or
one
project
to
a
sibling
group
or
project.
Then
that
issue
would
also
show
up
there.
You
could
like
more
or
less
decouple
all
of
these
problems,
just
by
letting
people
like
form
a
group
and
then
have
issues
or
whatever
work
items
assigned
to
that
group.
They
would
show
up
within
that
group
as
well.
B
D
Yeah,
it's
a
kind
of
that's
how
we
would
get
to
something
like
that
in
my
mind,
right
where
right
now,
it's
sort
of
all
mixed
together
right,
like
all
of
the
different,
I
call
them
like
applications
of
groups,
but
it
sounds
like
gabe
you're
kind
of
going
back
to
the
conversation
of
like
hey.
We
rethought
what
groups
were
right
and
how
they
were
used
for
plans.
D
C
It's
like
just
it's
a
weird
experience,
so
yeah
this
would
be
sort
of
like
if
we
were
to
merge
the
two
things
together,
which
I
think
makes
the
most
sense
and
then
the
like
after
they're
merged.
You
also
look
at
now.
How
can
I
share
assign
an
object
from
one
group
to
a
sibling
group,
and
it
also
show
up
within
that
group
so
sort
of
like
how
you
can
share
a
group
with
another
group
or
a
group
or
project
with
another
group,
and
then
they
have
permissions.
C
D
Yeah,
it's
sort
of
like
what
I've
seen
some
issue
old
issues
around
like
assigning
issues
to
groups
right
to
teams
right
so
in
this
case
would
be
like
two
teams
working
on
that
issue
right
essentially,
and
it
would
just
show
up
both
places.
C
Sure
yeah,
so
I
think
like
if
you
merge
groups
and
projects
together
in
one
thing,
they're
they're
sort
of
like
they
can
be
whatever
you
want
them
to
be.
They
can
be
a
a
team
right.
C
They
can
be
a
repo,
they
can
be
a
wiki
and
only
that
they
could
be
just
a
you
know,
design
management
workspace,
so
I
think
that's
kind
of
where,
instead
of
like,
if
you
have
all
the
resources
available
within
one
container,
then
you
give
the
end
user
the
like
ability
to
customize
that
workspace
for
what
jobs
they
wanted
to
solve,
whether
that's
managing
issues
as
a
team
or
doing
any
other
things
that
you
could
do
so
it
provides
a
lot
more
flexibility
in
that.
From
that
standpoint,
if
that
makes
sense,.
D
D
But
for
them
actually
teams
are
a
whole
separate
thing.
D
C
Yeah
I
mean
you,
we
could
eventually
create
separate
teams,
but
they're
sort
of
like
if
you,
if
we
go
down
the
road
of
where
we're
going
with
this
working
group,
you
would
have
a
collection
of
people
that
are
already
inside
of
this
group
right
and
you
could
maybe
you
just
toggle
something
on
to
say
like
this.
Is
a
team
right.
C
Because
I
think
it
would
give
you
the
ability
to
pretty
much
do
whatever
you
want
to
do
from
the
end
user
experience
and
that's
kind
of
like
where
I
like
the
fact
that
we
could
maybe
implement
this
on
the
back
end
and
merge
the
two
together
without
really
changing
anything
in
the
end
user
experience,
because
it
gives
the
most
flexibility
then
for
product
ux
to
go
and
be
like.
C
Okay,
what's
the
best
user
experience
we
can
create,
knowing
that
we
have
this,
this
underlying
extensible
thing
that
can
solve
all
these
different
jobs
right
so
anyway,
that's
a
thanks
for
sharing
that
that's
good,
I
think
jira
next
gen
has
something
similar
to
with
those
toggles.
So.
B
Okay,
okay,
just
going
back
to
what
you
were
saying
previously,
you
mentioned
it
sort
of
sounded
like
you
wanted,
a
feature
that
could
sort
of
be
pushed
back
up
into
another
group.
B
B
So
you
know
in
terms
of
like,
if
you're
looking
at
some
kind
of
I
don't
know,
roll
up,
metrics
or
kind
of
some
higher
level
view
of
this
group
here,
then
you
get
some
access
to
that
issue.
Is
that
correct?
B
B
C
Yeah
we'd
have
to
figure
that
out
it.
The
way
that
I
was
envisioning
is
like,
if
you
look
at
issue
or
merge,
requests
are
epic,
you
know,
epics,
don't
have
a
signage,
but
you
have
assignees
and
you
can
assign
people
to
an
issue
right
and
it
would
be
similar
to
where
you
would
have
a
team
field
or
a
group
field
or
whatever
what
a
thing
and
you
basically
select
which
group
you
want
to
assign
it
to.
C
So,
if
you
assign
it
to
that
group,
it
will
live
where
it
was
created
in
that
list,
and
it
will
also
show
up
where
the
within
the
group
where
that
is-
and
you
might
want
to
say,
let's
maybe
do
consider
rolling
that
up
and
making
that
available
up
top
or
maybe
not.
But
I
think
the
value
in
from
a
reporting
standpoint
is
even
though
it
was
created
here.
It
was
completed
by
the
team
over
here.
C
What
some
folks
want
largely
in
bigger
companies,
because
you'll
have
the
engineers
or
the
it
team-
that's
working
closer
to
the
repos,
and
they
want
to
be
close
to
their
issues,
and
you
might
have
like
your
planning
team
that's
over
here,
and
maybe
they
want
to
look
at
issues
across
lots
of
different
projects
and
like
plan
things
holistically,
and
so
this
is
actually,
we
lost
a
really
big
opportunity,
because
we
didn't
support
this
because
the
basically
said.
C
B
C
Yeah,
but
you
wouldn't
want
to
share
all
the
resources
you
will
want
to
make
it
so
that
they
could
be
assigned
right
because,
like
take
take
us
for
an
example
like
let's
say,
we
want
to
have
a
manage
group
and
a
plan
group
right,
and
then
we
have
our
gitlab.org
group
or
project
over
here
and
it's
it's
like
they're
kind
of
siblings,
and
I
want
to
assign
just
the
issues
that
have
the
group
project
management
label
to
the
planning
group.
C
D
Yeah,
this
is
fairly
common,
too,
for
teams
like
in
large
enterprises
that
have
like
platform
services,
and
things
like
that
right,
where
it's
like
by
design.
One
team
won't
own
the
full
scope
right
like
there
will
be
other
teams
that
work
on
the
whole
deliverable
and
people
need
to
have
views
into
like
the
whole
thing.
B
C
Yeah,
I
I
was
thinking
instead
of
like
shared
into
you.
Have
you
could
have
access
to
the
resources
right
so
like
right
now
we
can
do
that
where
I
can
share
one
group
with
another
group,
which
means
I
can
then
click
into
this
other
group
to
see
the
things
there
right.
But
in
order
to
see
the
resources
there,
I
have
to
move
from
group
a
into
group
b,
and
so
I
think
what
we
want
to
figure
out.
How
to
do
is.
If
I
work
in
group
a.
D
Yes,
I'd
like
to
put
an
example
right,
like
let's
say
in
an
org
right,
there's
like
a
billing
team
right
and
they
do
everything.
Billing
and
gabe's
team
is
creating
a
feature
that
requires
changes
to
the
billing
team
to
the
billing
system
right.
D
C
D
I
think
probably
controversial,
but
actually
I
think
all
of
this
becomes
much
easier
if,
like
groups
of
people
are
different
from
groups
of
resources,
because
then
you're
not
mixing
like
two,
I
feel
like
it
gets
more
complicated
where
it's
like
well,
but
a
group
is
a
collection
of
resources
that
or
a
group
is
a
collection
of
teams
like
if
we
just
said
we
have
this
thing,
that's
a
collection
of
people
right
and
that's
what
you
assign
to
an
issue
in
this
team's
field
or
whatever.
C
C
B
B
I
think
we
can
do
what
you're
saying
gabe
but
and
like
you
say
we
can
do
it
through
the
ux,
where
we
kind
of
just
we
use
the
back
end
infrastructure,
but
then
we
just
we
tap
into
a
finer
grain,
so
maybe
snippets
we
create
a
group
and
then
wiki.
We
create
a
group
and
it's
all
a
bit
behind
the
scenes.
It's
not
the
nicest
thing,
but
we
could
probably
do
it.
B
Is
that
what
you're
saying
where
you
could
kind
of
it
kind
of
feels
like
this,
like
I
said
before:
the
decoupling
issue
of
decoupling
people
from
resources
and
the
group
hierarchy
and
so
on,
but
also
like
this,
this
decoupling
of
ownership
that
that
it's
not
just
a
group
that
can
own
something
or
it's
a
user
that
can
own
something.
That's
like
this
sort
of
an
issue
could
belong
to.
Many
different
things
or
an
epic
could
belong
to
many
different
things.
C
Well,
I
I
think
you
could
say
the
canonical
place
where
it
was
created
owns
it
right,
so
you
would
never
it's
not
like
you're
moving
the
issue
like.
If
I
create
an
issue
in
project
a
project,
a
will
always
own
it
under
the
hood.
You
can
just
assign
it
more
or
less
to
another
group
where
it
would
show
up
there,
and
I
think
there
are
certain
things
that
you
wouldn't
do
that
with
like.
I
don't
think
you
would
assign
a
wiki
right,
there's
there's
nothing
that.
B
Like
right,
but
but
what,
if
you
wanted
to
move
the
wiki
to
another
group
and
the
wiki
is
because
it's
part
of
a
group,
it
also
sort
of
comes
with
all
this
baggage
of
like
these
issues
and
this
this
repository
and
so
on,
and
so
on.
Like
you
can't,
can
you
take
the
wiki
and
then
like
just
move
it
to
another
group
and
leave
everything
else
in
that
group,
because
you
kind
of
have
to
move
the
whole
group
to
a
through
the
hierarchy.
You
can't
just
take
the
wiki.
D
C
C
Incidents,
I
think
that's
where
we
were
working
on
this
idea
of
having
like
similar
to
what
we're
doing
with
groups
and
projects
but
with
issuables
themselves
and
making
it
so
issuable
can
be
a
little
bit
more
extensible
to
support
like
incidents
more
properly
and
things
like
that.
So
there's
opportunity
to
change
some
behavior
there,
but
I
would
also
say,
like
we
don't
have
to
do
this
solution.
C
If
there's
a
better
one
or
a
better
way
to
solve
it
or
not,
using
groups
I
more
or
less
was
pushing
to
merge
the
two
together
because
it
seemed
like
we,
the
smallest
primitive.
We
could
reuse
to
accomplish
lots
of
things,
but
please
like
if
there's
a
better
way
to
solve
the
product,
needs.
C
E
I'm
coming
from
this
from
like
an
outside
perspective,
since
mike
kind
of
added
me
second
at
the
last
minute,
but
is
there
any
reason
why,
like
this
can't
be
done
like
graphically
or
as
like
a
flowchart
like?
I
want
to
connect
these
two
objects
and
I'll
just
draw
a
link
to
them
or
maybe
draw
multiple
objects
until
it
connects
these.
These
objects
are
groups
or
wikis
or
issues,
and
then
you
just
organize
them
categorically
like
this.
E
D
So
maybe
what
we
need
to
do
is
just
like:
do
some
really
rough,
like
mock-ups
or
like
activity,
charts
of
the
things
that
we
want
people
to
do
right
and
then
that's
what
we
talk
about
next
week
right,
I
was
just
like
hey.
This
is
what
we
want
to
do
right.
This
is
how
we
would
want
it
to
work
and
sort
of
like
leave
behind.
I
don't
know
if
that
exists
already
gabe,
but
like
leave
behind
what
we
can
do
today
and
and
that's
how
we
can
figure
out
like
how
we
do
it.
C
Yeah
I
can
share
this
again.
This
is
from
the
opportunity,
canvas
that's
linked
in
the
top
of
the
document
and
it's
worth
reading
through,
just
if
you
haven't
yet
this
is
the
problem
validation
we
did
for
this,
but
like
today,
this
is
what
it
is
like
if
you,
if
for
for
a
team
that
wants
to
practice
safe,
not
everyone
does,
I
don't
have
first
class
support
for
safe
but
you'll
get.
The
point
is,
like
you
have
this
group
that
holds
some
things.
C
You
know
so,
I
think,
like
that's,
where
there's
so
much
diversity
in
how
teams,
structure
and
organize
themselves
that
for
us
to
say,
like
you
have
to
do
it.
This
way
like
it's
on
the
screen
would
be
wrong,
because
you
might
also
have
the
the
case
where
you
have
this
team
one.
That's
all
it
is,
and
it
has
like
a
bunch
of
services
underneath
it
right
or
who,
who
knows
what
they
are,
but
I
it
kind
of
like
at
the
end
of
the
day.
D
Yeah,
so
the
part
I
get
this,
the
part
where
I'm
getting
lost
is
the
whole
like
sharing
issues
like
I
can't
picture
that
in
my
mind,
so
maybe
that's
the
part
that
I
feel
like
could
be
more
clear.
A
Yeah
I've
been
wondering
if,
as
we've
been
discussing,
if
this
is
just
a
like,
if
all
users
exist
at
that
top
level,
gabe
show
your
thing
again.
You're
the
last
screen
yeah
like
if
all
users
exist
at
that
top
level.
So
then
they
have
permission
to
access
and
do
things
to
all
of
the
child
entities
below
it.
A
And
then,
whatever
your
collection
of
resources
are
like
the
yes
they're
owned
by
their
parent
group,
but
that
doesn't
preclude
the
relation
like
relating
issues
to
other
issues
that
are
in
different
groups
or
allowing
users
to
do
things
to
issues
that
or
see
reporting
of
issues
and
things
that
are
in
groups
that
they
don't
normally
work
in.
A
I
don't
know
if
that's
like
a
more
complicated
because
then
you're
allowing
users
to
access
all
the
things,
and
you
don't
have
as
much
like
protection
against
resources
like
if
you
don't
want
a
certain
group
of
people
to
access
issues
in
one
group
or
something
like
that
right.
D
Yeah,
so
it's
kind
of
like
how
sso
works
today
accidentally,
I
would
say
so,
like
everyone
gets
added
to
the
top
group
as
guest,
if
you
have
sso
enabled
and
actually
like
customers,
don't
like
that
very
much
because
of.
D
There's
like
specific
people
that
should,
for
reporting
purposes.
C
So
yeah
I'll
show
this
a
little
bit
too
just
to
think
about
it
like
this.
This
is
kind
of
how
I
was
thinking
about
it.
So
if
we
have
this
namespace
and
there's
an
issue
gets
created
here
it
and
then
it
gets
assigned
to
this
namespace.
It
will
still
show
up
in
this
issue
list
and
is
issueless,
but
it
will
also
show
up
in
the
xby
issue
list
right.
D
C
C
It
would
be
the
it
would
be
the
group
where
it
was
created
right,
let's
say
like
if
I
create
an
issue,
will
automatically
be
assigned
to
the
the
place
where
it's
created,
but
then
I
could
like
assign
it
here
because
this
way
then
like,
if
I'm
depending
on
somebody
over
here
and
be
like
okay,
your
team
needs
to
take
care
of
this,
but
my
project
is
dependent
on
it
or
whatever.
It
is
so
that
way
like
it
can
be
tracked
in
both
places,
which
I
I
I
know
it
makes
it
more
complicated.
C
Yeah
but
I've
I've
also
gotten
requests
or
we've
gotten
a
request
to
have
assignees
on
epics.
C
Not
a
sibling
group
no,
but
you
can't
have
any
issue
that
is
built
downstream
and
any
subgroup
or
sub-project.
A
We're
about
out
of
time
I
wondering
if
it's
still
useful
to
maybe
maybe
this
is
an
ask
for
pms,
but
to
do
what
melissa
had
suggested
where
we
try
to.
I
don't
know,
culminate
this
a
little
bit
more
cleanly
in
a
single
diagram
between
now
and
next
week,
and
then
we
can
continue
this
discussion.
Then
I
think
that's
worthwhile.
C
Yeah,
would
it
be
useful
also
just
to
maybe
step
back
from
it
and
write
job
stories
or
jobs
to
be
done
like
without
looking
at
what
the
solution
is
just
saying
what
what
needs
to
happen
right,
because
I
I
want
to
give
latitude
to
engineering
to
come
up
with
the
best
way
to
solve
it.
If
that
makes
sense,
if
this
is
in
it,
so.
A
C
I
will
I
will
work
on
those
things.
Async
I'll,
create
an
issue
under
this
epic
just
to
track
those
things
and
I'll
do
that
after
this
call.