►
From YouTube: Simplify Groups and Projects Working Group - 2020-10-15
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
this
is
what
is
it
october
15th,
and
this
is
the
simplify
gripson
projects
working
group
marcus.
It
looks
to
give
the
first
agenda
item.
A
B
B
Like
we
are
proposing
to
introduce
this
new
lab,
but
then
what
could
happen
is
that
new
features
are
built
around
this
lab,
and
so
it
becomes
permanent
basically,
but
I
think
our
plan
is
to
get
rid
of
it
again
at
some
point,
so
it's
just
like
a
temporary
facility.
Otherwise
we
just
have
a
duplication
between
projects
and
labs.
B
B
B
C
That
has
to
sort
of
work
on
the
code
or
perhaps
within
our
sort
of
the
product
managers
within
our
sort
of
working
group,
and
so
we
we'd
use
it
under
the
hood
and
then
eventually,
I
envisaged
that
I
think
gabe's
along
this
line
as
well,
that
that
we'd
sort
of
we'd
supersede
projects
and
groups
with
something
else
and
and
it
would
sort
of
involve
a
slight
restructuring
of
sort
of
the
hierarchy.
C
I
think
it's
like
the
broader
picture
is
also
pulling,
in
instance,
level
groups
as
they've
been
being
referred
to
and
sort
of
organization
level
groups.
That
kind
of
thing
sort
of
a
much
broader
picture
around
that
but
kind
of
trying
to
trying
to
create
more
of
a
uniform
interface
across
all
those
levels.
B
A
Do
you
think
semantics
are
sort
of
how
we're
been
naming
things
maybe
adds
to
some
of
the
confusion
like
we've
had
labs
spaces
we've
named
it
different
things,
and
it
can
be
confusing
to
kind
of
think
through
that.
I'm
just
asking
in
general
right
as
we
communicate
this
out
to
a
broader
audience
like
making
sure
we're
consistent
in
what
we
call
it
and
how
we
explain
it.
C
E
I
I
I
get
that
a
good
conversation
going
on
now.
It's
like
do
you
have
a
permanent
lab
that
you
port
features
into
or
use
that
temporary
so
that
you
can
eventually
pour
everything
into
either
a
group
or
project
and
then
delete
the
other
thing,
and
I
would
say,
like
the
trade-off
there,
it's
an
implementation
decision
so
entirely
engineering,
I
think,
for
the
most
part,
but
from
a
product
sample.
E
I
would
say,
like
what
are
some
of
the
things
that
are
broken
about
projects
and
groups
right
now
that
would
that
would
benefit
if
we
did
have
sort
of
like
a
a
new
approach
to
doing
that
like
would
it
improve
access
or
permissions
or
like
any
of
these
other
things,
that
kind
of
are
a
little
bit
wonky
between
projects
and
groups.
Right
now-
and
I
guess
that's
kind
of
like
where
I
would
ask-
is
like
what
are
the
pros
and
cons
of
each
and
then
go
from
there,
but.
C
I
think
also
it's
worth
noting
that
I
know
that
sid
and
perhaps
jeremy
watson
coming
from
sort
of
the
the
top
of
the
system
down
in
terms
of
the
instance
level
groups,
they're
kind
of
referring
to
things
as
groups
where
I've
at
least
me
and
gabe,
I
think,
have
been
referring
to
the
same
concept
in
terms
of
labs.
C
A
I
completely
agree,
as
I
always
have
been
communicating
this
sort
of
planting
seeds
for
us
to
get
approvals
or
or
buy
in
across
the
organization.
Communicating
it
that
way.
Helps
people
understand
it
a
lot
faster.
A
So
if
you
could
have
explained
to
someone
like
hey
imagine
in
a
year,
you
know
there
won't
be
anything
there
won't
be
any
projects
and
all
the
resources
that
belong
to
projects
today
will
just
belong
to
groups
and
then
you'll
have
groups
and
you
can
have
organizations
can
create
their
group
structure.
A
However
they'd
like
to
but
they'll
have
those
resources,
availability
of
those
resources
at
every
level,
no
matter
what
how
they
want
to
design
it
right
that
that
clicks
with
people
really
easily
and
they
understand
the
concept
without
having
to
introduce
them
to
something
new,
I
mean
I,
you
still
have
to
explain
that
you're
adding
this
object
right,
but
I
agree
and
we
can
yeah.
We
can
talk
about
it
later,
but
I
I
would
encourage
us
to
pick
something.
A
E
I
think
that's
fine
with
me.
That's
where
I
I
talked
with
liam
a
little
bit
because
he
wasn't
gonna
be
able
to
come
to
say
just
about
how
to
approach
the
engineering
organization
as
well
like
dz
and
whatnot
and
sid,
and
how
we
can
kind
of
loop
in
with
the
instance
group
proposal,
because
I
think
this
this
sort
of
like
is
that
just
with
some
other
things,
part
of
it
that
make
that
solve
some
of
the
other
problems
as
well.
E
So
I
was
gonna
respond
to
dz
in
that
issue
and
try
to
like
get
his
feedback
and
input
on
our
proposal.
So
if
we
think
we
should
use
the
term
group,
we
can
use
the
term
group
and,
like
basically
like
you
said
at
the
a
year
from
today,
everything
will
be
a
group.
There
will
be
no
projects,
there
will
be
no
differences
and
the
inheritance
stays
the
same.
C
C
Alex
how
how
we
approach
so
so
I
don't
know
do
should
I
should
I
mention
my
point.
It
kind
of
bleeds
into
it
a
bit.
C
Okay,
so
what
my
gender
item
is
just
referencing,
my
post
in
the
working
group,
where
I
said
that
I
think
that
we're
at
the
end
of
the
current
phase
of
the
working
group-
and
we
should
think
about
the
next
phase-
and
I
think
the
next
phase.
C
Just
in
summary
of
that
that
slack
message
is
that
we
should
step
tentatively
and
and
slowly,
and
I
think
at
least
from
the
engineering
side,
we
have
some
sort
of
infrastructure
type
work
to
sort
out
before
we
go
and
start
trying
to
pull
in
like
major
features
and
lots
of
features
at
the
same
time
and
trying
to
communicate
with
other
sort
of
groups
on
what
we're
doing,
and
so
now
going
back
to
what
we're
just
talking
about.
I
think
yeah
we
as
part
of
that
next
phase.
C
C
You
know
we
have
some
sort
of
idea,
but
we
don't
know
exactly:
there's,
there's
engineering
problems
and
there's
there's
product
type,
problems
and
communication
and
so
on,
and
so
as
part
of
that
next
phase,
we
should
solve
the
technical
problems
of
the
infrastructure,
bits
and
pieces
that
we
need
to
sort
out
before
we
can
actually
roll
it
out
in
a
significant
way,
but
also
kind
of
the
communication
components
and
whatever
else
product
things
they
need
to
sort
out
before
we
sort
of
roll
out
to
other.
B
C
Okay,
yeah,
I
think
yeah,
because
part
of
the
problem
is
going
to
be
that
in
terms
of
like
the
next
phase
in
terms
of
getting
things
merged
every
time
you
push
a
merger
quest
through
you're,
going
to
have
to
explain
what
you're
doing,
why
you're
doing
it
and
that's
going
to
be
awful.
C
So
we
we're
going
to
have
to
sort
that
out
and
and
part
of
that
it's
going
to
be.
You
know,
at
least
we
can
point
to
some
document
and
say
this
is
in
reference
to
this
work
that
we're
doing
go.
Read
that
document
it
sort
of
sums
up
what
we're.
A
A
I
can
speak
over
what
I'm
typing
so
alex.
I
agree
with
you
as
part
of
communication,
and
I
get
your
input
on
this,
like
I
think,
to
conclude
phase
one.
We
had
originally
talked
about
sort
of
documenting
our
work
in
an
opportunity.
Canvas
review
just
gave
to
the
first
one
which
initiated
this
working
group,
which
was
focused
mostly
on
problem.
A
The
second
one
would
be
problem
plus
solution.
No,
it
doesn't
have
to
be
these.
These
canvas
reviews,
if
you've
never
seen
one
like
they,
don't
have
to
be
detailed
and
prescriptive
in
the
solution.
A
But
if,
if,
for
example,
we
want
to
talk
about
the
concept
of
a
lab
or
call
it
groups
like,
we
should
have
some
clarity
there
and
figure
that
out,
but
in
my
opinion
at
least-
and
you
all
can
disagree,
we
can
talk
about
it
like
I'd
like
to
do
that
before
we
completely
move
into
phase
two,
because
it
will
give
us
that
a
little
bit
more
buy-in
and
engagement
from
other
leadership.
A
A
You
know
like
the
epics
and
issues,
and
then
you
schedule
a
review
conversation
that
includes
like
typically,
it's
scott
williamson
christie,
a
noop
and
then
an
engineering
leader
of
some
flavor,
either
leaf
or
eric
johnson,
depending
on
who's
interested
and
how
far
we
want
to
go
with
it.
So
it
doesn't
have
to
be
like
explicit.
It
doesn't
need
to
be
like
here's,
our
very
specific
steps
to
build
the
solution,
but
a
high
enough
level
concept
where
they
can
understand
it
and
get
feedback
or
support.
You
know.
A
Would
call
this
the
outcome
primarily
a
internal
communication
and
like
stakeholder
buy-in
kind
of
outcome,
so
I
don't.
I
wouldn't
expect
us
to
get
sort
of
really
deep
or
technical
or
product
feedback
per
se
here
in
at
this
point,
it's
more
about.
A
Do
people
that
haven't
the
six
of
us
have
been
spending
a
lot
of
time
on
this
right
and
then
people
adjacent
to
us.
You
know
who
have
been
working
on
related
things
are
aware
and
have
details,
but
scott
williamson
doesn't-
and
I
doubt
christy
does-
and
I
can
say
differently-
you
know
life
probably
doesn't,
and
so
it
helps
us
communicate
in
in
a
simple
and
clear
way.
Here's
what
our
solution
is
and
we'd
like
to
continue
to
move
forward.
A
Now
we
necessarily
need
explicit
approval
from
them
right,
but
we
we
do
want
to
get
engagement
and
contribution
from
more
than
the
six
of
us
right.
If
we
ever
hope
to
be
successful
here
we
need
more
than
than
two
engineers
three
product
managers
and
one
design
manager
working
on
it
right
and
so
that
that
is
a
mechanism
to
sort
of
communicate.
The
plan
or
the
the
solution
get
them
excited
about
that
and
get
them
to.
A
C
Yeah
yeah,
I'm
good
with
that
and
some
sort
of
formal
closure
to
the
first
phase.
I
think
that
I
had
a
chat
with
liam
about
this
earlier
in
the
week
and
we
kind
of
discussed
you
know.
Originally,
we
were
sort
of
looking
to
to
get
the
higher-ups
involved
and
try
to
sort
of
dictate
direction,
and
so
on
and
and
liam
raised
the
point
that
it's
not
really
necessary.
C
It's
not
necessarily
the
way
things
are
done
at
gitlab
anyway,
and
we've
kind
of
got
a
lot
more
power
in
our
own
hands
to
to
make
this
stuff
happen
anyway.
So
we
may
as
well
just
just
use
that
power
in
that
direction,
so
I
kind
of
feel
like
the
next
phase
or
two
may
not
require
or
involve
people
outside
of
the
group,
whereas
maybe
yeah
we're.
Probably.
C
I
think
we
might
be
a
bit
away
a
bit
off
getting
other
people
involved
just
just
for
the
record,
but
okay,
definitely
definitely
obviously
part
of
the
plan.
Eventually.
A
We
don't
need
the
higher-ups
approval
right
like
we
can
continue
on
it's
more
just
the
the
communication
and
overall
acceptance
and
buy-in
and
excitement
so
that
they're
they're,
supportive
in
conversations
and
helping
like,
for
example,
steer
sid
if
sid's
looking
at
instance,
level
groups
and
pushing
really
hard
on
that
like
they
can
help
make
sure
that
the
sort
of
disparate
projects
that
may
come
out
of
things
around
groups
right
are
collaborating
and
communicating
consistently
with
each
other
right.
E
I
think
it's
it's
also
so
that
other
product
managers
don't
do
inefficient
work
right
so,
like
there's
a
whole
table
in
the
update
issue
about
all
the
stuff
that
people
want.
E
The
group
level
and
people
can
go
on
and
do
that,
or
they
could
say
like
hey
like
this,
is
go
we're
solving
for
this
and
you'll
get
it
so
go,
invest
in
something
else,
and
then,
when
we're
ready
for
you
to
contribute
and
help
which
we
should
try
to
get
to
that
point
as
quickly
as
possible,
because
I
think
we'll
move
faster
but
like
when,
when
we're
ready
for
you
to
be
involved,
then
you'll
be
able
to
be
involved
and
you'll
be
able
to
contribute
in
a
way
that
will
build
towards
the
vision
instead
of
just
like
duplicate
work,
that's
sort
of
like
what
I
told
matt
gonzalez
and
he's
like
yeah
we're
happy
to
contribute.
E
Just
let
us
know
how
right
we
don't
mind
doing
some
of
the
work
just
tell
us
what
we
need
to
do.
So
I
think
that's
that's
another
reason
why
it's
just
so
that
we
do
get
folks
aware
and
not
operating
a
silo.
C
E
I
will
talk
about
it:
every
single
product,
weekly
product
meeting
as
a
bullet
point
item,
and
I
will
post
it
in
product
every
single
week,
the
slack
channel.
I
will
maybe
have
office
hours
for
this,
so
that
we
can
let
people
come
and
talk
to
engineers
or
whoever
is
interested
like
that's
this
kind
of
thing
where
you
you,
you
broadcast
through
many
many
channels
repeatedly
over
a
period
of
time
and
the
providers.
F
We
also
have
the
weekly
product
meeting
right,
there's
a
where
leadership
makes
announcements
about
stuff
right,
so
it
doesn't
have
to
be
just
us
and
going
back
to
like
basically
putting
words
in
your
mouth
alex.
What
you're
asking
like
what
is
getting
like
leadership
bias,
get
us
right
like
also
in
the
ideal
world
right.
It
would
get
us
funding
right.
So
that
way,
there's
a
seed
planted
in
their
minds
right
and
when
they're,
making
decisions
about
hiring
and
team
allocation
and
stuff
like
that
right.
F
If
they
know
that
there's
this
big
effort
right
that
they
believe
in
at
the
leadership
level
right
they're
bought
in
at
the
problem
they're
bought
into
the
solution.
They
have
a
general
understanding
that
it's
something
that's
underfunded
right.
We
have
a
better
chance
of
you
know
in
the
future
having
a
team
built
around
it
versus.
If
we
try
to
build
it
ourselves,
grassroots
right,
that's
not
something!
That's
ever
going
to
be
possible.
F
F
But
yeah,
I
think
overall,
I
agree
that
if
we
should
try
like
yes,
we
should
get
buy-in
and
the
general
concept
of
like
merging
groups
and
projects
together
right
and
that's
going
to
fix
these
issues,
and
we
should
start
with
something
very
small.
I
liked
your
idea,
alex
of
basically
starting
with
plan
specific
issues
right
because,
like
that's,
why
we
formed
this
group
right
like
at
the
end
of
the
day,
gabe.
That's
a
big
part
of
why
you
want
to
solve
this.
F
So
if
we
start
with
plan
and
work
out,
all
the
kinks
of
basically
how
this
is
going
to
work
right,
both
from
the
design
perspective,
like
development
perspective
right
and
if
we
do
have
like
a
nice
packaged
way.
I
know
it
won't
be
like
super
easy
like
that,
but
if
we
have
like
at
least
guides
right
of
like
hey,
when
your
stage
is
transitioning
to
this
new
model,
this
is
the
kind
of
stuff
that
you'll
need
to
do.
F
This
is
how
long
we
think
it
will
take
based
on
you
know
how
we
did
it
with
other
stages.
I
think
that's
a
much
easier
cell
than
trying
to
like
convince
everyone
at
once
and
do
everything
at
once.
D
I
think
there's
a
small
small
risk
in
asking
for
permission
on
getting
a
yes
before
we've
actually
done
a
proof
of
concept,
you
know
in
say
like
with
epics
or
wiki
or
something
because
I
think,
like
leadership,
has
a
hard
time
saying
yes
to
something
that
they
don't
totally
understand.
So
I
think
the
first
thing
is
we
just
socialize,
it
make
sure
people
understand
and
do
the
first
perfect
concept
and
make
it
work
and
ship
it,
and
we
don't
need
yes
at
all.
D
Honestly,
we
just
need
to
keep
socializing
because
there's
going
to
be
more
capabilities
beyond
that.
First
capability
that
need
this
correction
and
how
the
model
works.
So.
A
Yeah
I
like
I
agree,
I
don't
think
we
need
or
should
expect
a
formal
yes
from
that
opportunity,
canvas
review.
It
is
just
socializing
right
and
in
this
case
it's
socializing
with
leadership,
which
requires
usually
a
meeting
and
a
formal
document.
You
know
get
them
to
look
at
something
right.
We
don't
need
their
like
official.
F
But
we
should
make
sure
we're
directionally
aligned
that
at
least
there's
awareness.
I,
like
the
part
that
you're
talking
about
just
like,
I
feel
like
we
keep
trying
to
solve
this
problem
like
50,
different
ways
right
like
there's
a
new
issue
every
couple
weeks
that
is
sort
of
trying
to
solve
this
right,
and
it
would
be
nice
if
we
at
least
had
alignment
of
like
okay.
This
is
a
team.
That's
trying
to
fix
it
that
larger,
like
data
architecture
issue.
F
A
Yes
and
that's
part
of
my
bullet
e,
like
suggestion
or
tactical
recommendation
here,
is
that
we
give
some
finality
to
the
effort
like
the
last
four
months
or
whatever,
so
that
you
can
point
to
the
like
working
group
page
and
say
and
see
us
listed
under
like
solved
problems
working
groups
right,
not
to
say
that
we've
completely
cracked
it,
but
it
it
makes.
So
we
don't
have
to
relitigate
this
again,
like
melissa,
said
every
time
something
else
comes
up.
E
Do
we
want
to
ask
for
do
we
want
to
open
a
new
working
group,
or
how
do
we
feel
about
that?
I
feel
like
if
we
don't,
we
won't
get
anything
done.
Maybe
maybe
we
will.
I
don't
know,
but.
A
A
F
I
was
just
going
to
ask
what,
in
your
mind
what
would
having
another
working
group
achieve
that
we
wouldn't,
if
we
didn't
have
it.
E
E
A
Alex
mentioned
it
earlier
but
like
I
think
it
also
depends
on
how
much
you
do
like.
Do.
We
realistically
think
we'd
get
a
staff
engineer
immediately
and,
like
let's
say,
phase
one
ends
next
week
like
if
we're
focused
on
moving
issues
to
the
group
level,
and
it's
really
going
to
be
work
from
alex.
Maybe
marcus
contributes
into
a
couple
plant
engineers
like?
Do
you
really
expect
that
phase
to
get
contributions
from
staff
engineers.
A
It
would
help-
I
don't
disagree
with
you,
I
it
absolutely
would
help,
but,
like
I'm
just
being
pragmatic
like
I
don't,
I
don't
think
we
would
right.
So
I
I
talked
to
brinkman
about
this
a
little
bit
this
week
and
because
it's
even
if
marcus
wants
to
do
some
things
here,
it's
self-contained
within
dev
right.
So
I
don't
know
if
we
need
the
formality
to
achieve
the
same
outcome.
Assuming
he's
on
board.
A
Assuming
you
know,
tim
zalman's
on
board
mike
you're
on
board
like
and
the
six
of
us
are
still
fully
committed,
plus,
hopefully
a
couple
other
engineers
from
plan
or
access.
Then
I
think
phase
two
would
be
successful
regardless
my
opinion,
I
might
be
wrong,
but.
E
A
Well,
I
will,
I
will
raise
an
mr
to
resolve
the
at
least
the
phase,
one
working
group,
and
we
can
collaborate
there
and
then
gabe.
Let
us
know
how
we
can
contribute
and
help
complete
that
solution,
validation
or
the
the
rest
of
the
opportunity.
Canvas.
Okay,
we
can
jump
in
async
sounds
good.
Okay,
good
to
see.
Y'all
have
a
good
rest
today,
but.