►
From YouTube: Plan | Refactor Party Kickoff
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
context
is
there.
Let
me
know
if
you
have
any
other
questions
about
it.
I
did
put
in
some
considerations
that
I
just
wanted
to
highlight
real
quick.
I
don't
think
any
ideas
should
be
off
the
table
at
this
point.
A
I
think
everyone
can
contribute
and
should
I
think
the
goal
over
the
next
weeks
is
to
iterate
experiment
and
get
as
many
feedback
cycles
as
possible
so
that
we
can
set
ourselves
up
for
basically
a
smooth
transition
into
focusing
on
refactoring
and
sort
of
these
strategic
goals
that
involve
lots
of
refactoring
and
then
I
also
would
say
think
big
in
terms
of
ideals.
A
I
think
we
can
work
backwards,
identify
and
remove
constraints
and
think
about
like
how
to
mvc
our
way
towards
the
ideal,
but
sometimes
we
think
justin
like
nbc
and
not
the
end
goal,
and
I
think
we
need
to
balance
both
of
those,
as
we
kind
of
discuss
this
and
then
sort
of
there's
some
blockers
that
I
kind
of
notified.
I
think
one
of
the
goals
is
to
as
quickly
as
possible
get
epics
migrated
to
issue
types,
because
I
think
kristin.
A
If
you
want
to
drop
that
this
kristen's,
not
here
well,
she
put
together
this
spreadsheet.
Basically
that
has
all
the
fields
on
issues
all
the
fields
on
epic's
requirements
and
basically,
where
there's
this
duplication
and
we
sort
of
want
to
reach
parity
as
quickly
as
possible.
B
Trying
to
yeah
it's
in
here.
A
Thank
you,
so
I
don't
want
to
hog
the
the
conversation.
I
think
I
just
wanted
to
start
out
with
some
questions
and
then
let
the
team
kind
of
drive
first.
Like
do.
We
agree
on
the
working
hypothesis
that
I
kind
of
laid
out
above
that
if
we
spend
a
few
milestones,
focusing
solely
on
these
three
things,
we'll
be
more
efficient,
responsive
in
the
future
in
terms
of
delivering
value.
Do
we
agree
with
that
hypothesis
and
is
there
anything
else
to
add.
C
A
You
see
here
if,
if
I
were
to
like
step
back
for
a
second
and
look
at
what
we
would
do
over
the
next
year,
if
we
didn't
move
forward
this
approach,
I
kind
of
laid
out
this
like
iteration
path
of
like
how
I
see
things
playing
out
based
on
how
I've
watched
just
evolve
over
the
last
18
months.
We
basically
would
end
up
doing
a
lot
of
duplicated
work
between
all
the
different
plan
objects.
A
Whether
that's
epics,
like,
for
example,
epics
need
assignees
right,
epics
need
the
ability
to
assign
milestones
directly
to
them
right
and
maybe
the
issues
below
them
inherit
them.
There's
like
a
lot
of
different
things
where
epics
don't
have
a
certain
thing
that
an
issue
has
an
issue
has
something
that
an
epic
doesn't
have
a
requirement.
I
need
something
or
test
case,
and
we
end
up
like
doing
mvcs
like
lots
of
small
nvc's
across
the
world,
but
it
ends
up
just
sort
of
like
duplicating
things.
A
Another
good
example
would
be
like
epic
boards,
like
we
had
to
go,
create
a
whole
new
like
model
for
that
and,
like
all
these
other
things,
just
support,
so
we
could
have
epics
on
boards
and
whereas,
if
we
had
issue
types
at
the
time
and
epics
is
a
basically
work
item
hierarchy
of
issue
types,
we
wouldn't
need
to
go
off
and
do
all
this
extra
work
just
to
have
an
epic
board.
I
think
it
also
makes
iterating
a
lot
faster.
A
The
other
is
that
we
we
do
need
to
refactor
the
issue
view
to
be
more
performant
to
support
real
time,
and
so
we
can
either
refactor
that
with
our
current
ux
or
if
we're
going
to
have
to
be
rebuilding
out
anyways
as
a
single
view
app,
we
have
the
opportunity
to
address
some
under
underlying
ux
challenges
that
we
need
to
solve
and
then
also
building
a
consistent
sort
of
like
ux
system
for
extensible
issues
will
make
it
easier
to
add
future
capabilities.
A
Whether
we
want
to
layer
on
new
little
like
fancy,
widgets
or
integrate
things
from
other
parts
of
the
product
into
issues
itself.
Vulnerabilities
is
a
good
example
where
they
want
to
kind
of,
have
vulnerabilities
linked
directly
to
issues
and
there's
a
design
proposal
for
that,
and
it
looks
a
lot
like
licking
issues
to
one
another
in
terms
of
relating
them,
but
it
was
also
slightly
different.
So
how
can
we
have
like
sort
of
consistent
pattern
that
other
teams
can
integrate
their
proc
features
and
issues
as
well?
A
D
A
Yeah
it
does,
I
sort
of
think
about
some
of
those
things
as
new
features
like
an
example
of
like
scope,
labels
versus
workflow
s's,
we
have
an
epic
which
I
link
down
in
one
b.
I
I
guess
on
that,
where
we
want
to
allow
for
customizable
issue
statuses
down
the
road
right
which
would
sort
of
negate
the
need
for
scope,
labels
to
denote
workflows
how
far
we
want
to
go
with
this.
A
A
What
is
our
current
system
and
and
put
it
into
this
new
extensible
like
kind
of
plan
object,
so
that
we
can
get
epics
down
to
that
level,
knowing
that
as
soon
as
we
want
to
start
adding
new
features,
we're
going
to
be
adding,
you
know,
customizable
issue,
statuses
issue
types
will
be
customizable
down
the
road
and
and
some
of
those
other
things.
So
it's
almost
like
laying
the
foundation
for
doing
that
work
in
the
future.
If
that
makes
sense,.
A
C
Yeah,
just
the
specific
timeline,
so
I
saw
in
the
description
above
it
mentioned
14-1.
Is
this
going
to
be
for
just
that
time
frame
that
we
kind
of
want
to
make
this
the
primary
focus,
and
then
I
can
see
alexis
and
I
and
mike
are
all
kind
of
articulating
questions
surrounding
priority
during
this
time.
A
Yeah,
I
would
say
that
it
does
largely
because
we
want
to
get
epics
converted
to
type
of
issues
quickly
as
possible,
so
that
we
can
basically
have
a
single
view
that
we
iterate
on.
We
want
to
be
able
to
pay
down
that
technical
debt
as
quickly
as
possible
for
having
these
like
kind
of
duplicated
objects,
and
then
the
other
thing
that
we
want
to
like
set
ourselves
up
for
is
that
pushing
the
consolidation
or
simplification
of
groups
and
projects
where
we
want
to
make
issues
available
to
group
level.
A
Now
we
only
have
to
do
that
one
place.
Instead
of
making
issues
available
to
group
level
and
then
epics
available
at
the
project
level,
we
basically
would
be
able
to
reduce
the
amount
of
work
we
would
have
to
do
there,
the
faster
that
we
can
get
towards
the
faster
we
can
realize.
I
guess
the
the
kind
of
strategy
that
we're
taking
here
so.
C
C
A
I
will,
I
will
basically
say
gabe
managers
of
one
at
gitlab
so
like
this
is
a
goal
that
I
think
we
should
have
as
a
stage
how
you
balance
your
work
and,
like
other
demands
like
I
trust
everyone
to
be
a
good
manager
for
themselves.
So
that's
kind
of
how
I
approach
it.
I
think,
in
terms
of
like
product
priorities,
I
would
put
this
highest
to
the
list,
but
in
terms
of
your
day-to-day
and
how
you
get
your
job
done.
That's
your
call.
C
So
not
to
push
back
a
little
bit
more,
but
that
for
me
that
makes
me
a
little
anxious,
because
I
don't
feel
that
I'm
properly
understanding
and
addressing
expectations
by
the
team
does
anybody
else
feel
that
way,
or
is
that
just
me?
If
so,
I
can
work
on
it
within
myself,.
C
C
D
So
I'll
share
that
I
have
anxiety
about
that.
Also,
maybe
not
so
much
within
the
team
level,
because
I
feel
like
us
as
a
group
or
us
in
the
larger
stage,
can
work
together
to
get
aligned
on
the
approach
we
want
to
take
here.
I'm
more
concerned
with
getting
buy-in
or
working
with
teams.
Other
stages,
especially
because,
like
so
many
other
teams
are
dependent
on
issuables.
C
And
that
actually
kind
of
goes
back
to
my
question
of
what
we're
looking
to
have
accomplished
by
the
end
of
this.
If
it's
just
kind
of
a
large
spike
where
we're
just
researching
and
investigating
and
brainstorming,
then
maybe
we
aren't
necessarily
committing
ourselves
to
anything.
But
if
we
are
looking
to
have
something
maybe
coded
and
committed
by,
then
I
agree
with
you
donald
I
have
I
have
that
concern
as
well.
A
The
first
eight
weeks
is
is
not
we.
This
is
why
I'm
not
going
to
dictate
what
we
do
we
might
want
to
code
at
the
same
time,
along
with
ux,
I
think
engineering
needs
to
be
involved
in
whatever
we
do
from
a
ux
standpoint,
just
for
collaboration
providing
guidance.
But
the
goal
in
this
next
eight
weeks
is
say
like
if
we
were
to
start
from
scratch
and
rebuild
the
issue
to
support
what
we
have
today.
A
What
what?
What
should
it
be?
Basically
right,
because
it
has
to
support-
and
I
kind
of
put
this
into
like
the
blockers-
to
convert
epics,
basically
to
a
work
item
harvey-
is
we
we
sort
of
need
a
revamped
issue,
view
ux
system
right
now?
A
There's
some
problems
with
it
that
I
kind
of
outlines
like
there's
too
much
scrolling
it's
hard
to
collaborate,
it's
hard
to
take
accomplish
my
tasks
as
an
issue
maintainer,
basically,
because
it
involves
like
lots
of
scrolling
back
and
forth
lots
of
losing
my
place,
lots
of
opening
new
tabs
and
other
things
like
that.
We
also
want
to
have
issues
viewable
on
boards
without
having
to
navigate
away
from
that
which
the
easiest
way
to
do
that
is
have
a
single
view.
App
there's
also
where
I
think
tim
dahlman,
converted
the
repo
into
single
view.
A
App
was
like
hey
here's
all
these
performance
benefits
we
get
from
doing
this,
so
we
issued
fast
follow
on
the
issue
view
as
well.
So,
like
there's
lots
of
things
there,
but
the
first
eight
weeks
is
really
what
what
defining
what
we
need
to
change
about
it,
so
that
we
can
have
an
effective
road
map
from
starting
in
14.1,
from
an
engineering
standpoint
of
tackling
the
the
refactoring
in
the
efficient
way
as
possible
right.
A
So
we
basically
have
eight
weeks
to
run
design,
sprints
and
kind
of
get
feedback
from
the
organization
we
can
decide
whether
or
not
we
want
to
include
merge
requests
in
this
or
not.
I
was
working
with
or
talking
with
kai,
and
he
said
that
the
the
create
team
doesn't
have
a
huge
appetite
for
refactoring.
A
Merge
requests
into
a
single
view
app,
but
they
sort
of
like
are
doing
that
anyways
with
I
think
code
review,
maybe
and
some
other
stuff.
So
we
also
have
an
okr
in
q2
to
improve
the
performance
of
discussions
on
merge
requests,
which
is
also
shared
with
tissues.
So
it's
sort
of
like
I
think
we
should
drive
towards.
Ideally
merge
requests
would
be
supported
in
this,
but
if
they
opt
not
to,
then
we
can.
Basically
we
don't
have
to
have
parody
with
merch
plus.
A
F
Merger
requests
satisfy
very
different
jobs
and
use
cases
than
the
the
issue
tracking
and
product
planning
stuff
anyhow,
and
I'm
happy
to
sort
of
from
the
sidelines
help
people
understand
that
they're
different
and
they
don't
need
to
be
consistent
unless
we're
talking
about
like,
maybe
that
some
elements
of
the
top
bar
ought
to
be
in
the
same
place,
we
expect
to
find
it.
You
know
small
things
like
that,
but
I
I
personally
don't
think
that
mrs
need
to
be
deeply
involved
of
with
this
change
to
the
planning
capabilities.
E
I
think
the
the
main
risk
there
is
just
in
places
where
they're
like
intrinsically
linked
from
a
code
perspective,
so
like
discussions,
anything
we
do
with
you
know
game
mentioned
like
the
scrolling
of
discussions
and
like
that
that
whole
thing
being
sort
of
painful
right
now
on
issues,
that's
sort
of
a
direct
overlap
with
with
merge
requests
and
anywhere
else.
Where
there's
notes
so
we're.
E
I
guess,
like
we
have
to
scope
the
changes
that
we
intend
to
make
there
in
a
certain
way
to
like
we
can
make
changes
in
the
way
that
they're
rendered,
possibly
or
like
we
could
make
drastic
changes.
But
at
any
time,
if
we're
gonna,
you
know
sort
of
drastically
overhaul
the
discussions
end
point,
which
is
what
loads
comments
and
things
like
that.
Then
that's
where
we
have
to
collaborate
across
stage,
because
otherwise,
we'll
you
know
just
break
stuff
elsewhere,.
F
What
about
what
about
for
this?
You
know
this
first
go
this
these
first
iterations.
We
don't
touch
discussions
at
all.
Would
that
work
for
you,
gabe.
A
It
would
work
for
me
to
the
extent
we're
still
going
to
have
to
refactor
discussions
into
being
view
based
and
using
subscriptions
endpoint
instead
of
the
real,
basically
the.
What
is
it
the
real
time
endpoint
that
we
use
now
for
polling,
so
there
there
are
going
to
be
some
technical
changes
there,
but
I
think
that,
given
we
want
to.
A
We
basically
don't
have
to
change
the.
U,
let's
put
it
this
way,
we
don't
have
to
change
the
ux
of
discussions
right
now,
necessarily
like
how
the
how
they're
rendered
and
how
they
look.
I
think
there's
some
things
that
I
would
want
to
change
about
where
they're
placed
on
the
view.
Maybe,
but
I'm
fine,
not
tackling
that's
changing
it
significantly.
A
There's
also
the
thing
where
what,
if
we
decide
to
rebuild
discussions
as
part
of
the
bigger
view
app,
we
can
make
the
discussions
its
own
view
app.
It
slips
within
the
bigger
view
app,
and
then
we
realize
that
the
change
we're
making
are
these
huge
performance
wins,
then
that
can
be
like
adapted
into
merge
requests
eventually
too.
A
So
I
think
you're
right
about
the
awareness
is
important
and
participation,
maybe
would
come
next,
but
for
the
the
this
next
eight
weeks,
I
think
that's
where
we
can
tease
out
what
exactly
we
want
to
change
and
then
decide
what
level
of
involvement
we
would
need
from
someone
else
or
from
the
great
team.
Does
that
make
sense,
because
right
right
now,
we
don't
even
know
what
we
would
want
to
change.
G
G
They
don't
plan
to
refactor
it
to
graphql
anytime
soon,
maybe
in
like
next
six
months,
they
are
not
touching
refactoring
to
graphql,
because
I've
been
discussing
this.
So
it's
a
view
application,
it's
good!
It's
rest!
It's
not
good.
The
only
thing
that
we
can
do
is
to
include
it
into
the
global
state
of
the
page,
and
this
is
doable
we're
already
doing
it
with
widget.
A
Well,
we
eventually
is
it
correct
in
assuming
that
we
eventually
want
to
see
the
notes,
app,
consume,
graphql
and
not
rest.
E
Sorry,
I'm
raising
my
desk,
so
you
might
hear
some
noise
yeah.
I
mean
in
in
the
sense
that
we
want
to
move.
You
know
as
much
functionality
to
graphql
as
possible.
I
would
think
the
answer
is
yes.
There
again
like,
I
think
it's
a
much
more
complicated
change,
because
it
requires
sort
of
the
collaboration
across
stages.
There's
also
like
discussions
in
general
is
a
major
performance
concern
like
not
touching
it,
as
part
of
this
is
sort
of.
E
I
guess
because,
like
it's
also
an
area
where
the
it's
it's
currently
one
of
the
main
things
that
makes
issues
slow
and
painful
or
or
lots
of
stuff,
slow
and
painful,
so
the
opportunity
to
refactor
it
both
to
use
graphql,
potentially
using
graphql
subscriptions
and
then
also
to
just
improve
the
performance
of
it,
is
appealing,
and
we
need
to
get
to
that.
But
if
that
feels
like
a
very
large
scope
in
its
own
right,
that
might
be
separate
from
part
of
this.
I
guess.
A
I
would
say,
then
gabe
right
now
keep
it
in
scope,
at
least
for
like
the
next
we're
we're
basically
exploring
our
ideas
for
the
next
eight
weeks
to
basically,
I
would
hopefully
go
through
a
series
of
diverge
converge,
experiments
to
figure
out
what
the
issue
experience
should
be.
You
know
at
the
end
of
this
eight
weeks,
at
which
point
we
can
then
break
things
down
into
buckets
of
work
and
tackle
it,
because
I
do
agree
like
we
have
to.
A
A
I
don't
want
to
limit
that,
even
if
it
is
a
big
chunk
of
work
like
let's
just
be
honest
about
what
it
is
and
see
if
we
can
figure
out
how
to
sequence
things
in
a
way
that
makes
sense,
because
we
could
also,
through
this
discovery
that
refactoring
things
to
use
subscriptions
and
going
graphql
first
and
doing
some
of
the
change
we
want
to
do
is
also
going
to
achieve
our
q2
okrs.
For
the
mr
discussions,
performance
improvement
right,
we
just
we
don't
know
right
now,
so.
F
That
segways
into
point
number
two
gabe,
I
you
said
something
that
addressed
point
number
two
and
I
tried
to
capture
it-
is
that
pretty
accurate
diverge
converge
for
the
next
eight
week,
tweak
some
ways
that
we
can
address
the
top
usability
issues.
Yep.
A
F
C
I
think
I'm
still
a
little
bit
fuzzy
as
to
who
all's
going
to
be
involved
in
this
initially,
but
I
mean
alexis
feel
free
to
jump
in.
I
would
say
you
and
I
probably
would
need
to
just
start
figuring
out
kind
of
what
that
plan
needs
to
look
like.
C
I
know
we
had
talked
about
having
three
demos
a
week,
so
we
can
kind
of
figure
out
what
that
starting
point
needs
to
be
and
what
we
want
to
initially
demo
and
then
can
communicate
that
to
the
team
in
the
manage
meeting
earlier
today,
pedro
made
a
good
point
about
new
processes
and
documenting
them.
So
I
have
created
an
issue
or
I'm
in
the
process
of
creating
an
issue.
I've
got
the
new
issue
view
up
where
we
can
kind
of
document
this
experience
and
how
it
goes
in
the
event.
A
I
will
say
if
it's
helpful,
there's
sort
of
two:
I
can
stop
sharing
my
screen
segment.
There's
there's
kind
of
two
big,
I
guess
blockers
and
one
is
the
the
ux
system-
is
what
I'm
calling
it
for
the
issue
view
or
issueable
view
which
there's
an
issue
for
that,
and
then
there's
the
other
big
thing
to
solve,
because
if,
basically,
if
we
want
to
convert
epics
to
a
type
of
issue,
it
sort
of
is
going
to
end
up.
Looking
something
similar
to
this.
A
Where
you
have
this
workout
entry
right
and
everything
above,
like
a
user
story,
for
example,
is,
is
it
technically
an
epic?
And
this
is
how
our
customers
right
now
are
using
epics
like
they
will
call
it
a
capability
and
then
an
epic
and
then
a
feature,
then
they'll
break
that
down
in
visual
issues
their
user
stories.
A
At
the
same
time,
there's
also
like
long-lived
system
designs,
which
are
requirements
that
are
going
to
have
different
levels
of
requirements,
management,
and
so
this
is
where
like
getting
issues
since
requirements
are
now
being
converted
to
a
type
of
issue.
Getting
issues
at
the
group
level
is
part
of
a
separate
work
stream,
but
will
be
important
because
it
will
sort
of
enable
this
kind
of
multi-level
work
breakdown
across,
like
your
groups
of
group
hierarchy,
but
requirements
have
their
own
levels
too,
and
then
you
also
when
you
look
at
quality
management.
A
You
have
like
test
sessions
and
then
you
have
test
cases,
and
these
are
based
on
issue
types
too,
and
so
there's
these
different
kind
of
trees
of
work
items
and
each
serve
sort
of
a
different
job
to
be
done,
but
they're
all
related
to
or
ought
to
be
related
to
each
other
in
one
way
or
another.
A
So
that's
where
I
see
like
the
the
view
itself,
but
then
this
like
relationships,
experience
of
how
you
define
a
work
item
hierarchy
and
then
how
you
manage
those
relationships
across
to
other,
basically
other
levels
or
issue
types
or
whatever
in
different
work
item
hierarchies.
So
like
th.
Those
are
two
big
buckets
of
things.
I
don't
know
how
we
want
to
tackle
them,
but
I
just
thought:
I'd
lay
them
out
that
helps
it's
for
a
conversation.
E
I
just
read
in
there
something
that
might
be
helpful
as
we
think
about
like
how
we
organize
this
work
is,
if
we
kind
of
think
about
the
bucket
of
work
that
can
be
done.
E
You
know
essentially
like
around
ux
and
the
front
end
and
stuff
that
we
can
do
without
drastically
overhauling
back-end
architecture
or
the
way
that
models
are
structured
and
related
to
each
other
versus
things
that
you
know
need
like,
for
example,
changing
epic
to
a
type
of
issue
is
that's
a
holistic
change
that
requires
backing
changes
only
because
I
only
say
that,
because
we
are
seriously
resource
constrained
on
back
end
and
I'm,
you
know
practically
being
able
to
get
much
done
on
top
of
the
performance
and
sort
of
like
rapid
action,
stuff
we've
been
dealing
with
lately,
yeah
and
okay.
E
That
sounds
right.
I
just
want
to
make
sure
that
we
kind
of
have
that
in
mind
that
we're
not
getting
setting
grand
plans
that
then
fall
apart,
because
we
don't
have
the
the
resources
to
complete
them
and
by
resources
I
mean
people.
A
There
will
be
things
like
outside
of
our
control,
like
incidents
and
rapid
action
stuff,
but
heinrich
should
be
back
by
14.1,
hopefully
or
14.2
is
the
latest
we
have,
I
I
don't
know
20
other
engineers
in
plan
that
should
be
able
to
contribute
to
this
as
well.
So
I
I
definitely
think
we
we
want
to
like
sequence
stuff
out,
so
we
aren't
blocking
each
other,
but
we
we
are
gonna,
have
to
make
some
bacon
changes.
So
I
mean
it's
gonna
be
what
it's
gonna
be.
D
Yeah,
I'm
wondering,
though,
as
we're
as
we're
going
through
the
process.
I
I
think
it'll
be
helpful
to
maybe
not
so
much
estimate
it
out
and
figure
out
what
the
level
of
effort
is
going
to
be
on
these
things
on
the
back
end.
But
we
do
want
to
make
sure
that
we're
providing
input
on
the
feasibility
technically
of
things.
So
if
we
we
go
and
design
something
that
just
it's
impossible
to
implement
on
either
the
back
end
or
the
front
end.
D
D
Three
times
per
week
might
be
a
bit
much
for
like
if
we
want
everyone
outside
of
designers
to
attend
that
and
get
provide,
provide
input
on
feasibility.
D
Could
we
do
maybe
like
a
weekly
thing
during
maybe
plan
weekly
of
presenting
what
you
all
have
talked
about
during
the
week,
and
then
we
can
provide
the
technical
feasibility
during
those
meetings.
Was
that
how
does
that
sound?.
C
F
The
reason
I
I
picked
three
per
week
was
to
be
honest,
it's
out
of
it's
out
of
a
place
of
fear,
so
it's
probably
not
really
warranted.
I'm
worried
that
we're
fearful
that,
if
it's
only
once
a
week,
we
won't
make
progress.
G
F
F
A
Well,
I
think,
there's
I
I
agree
with
all
everything
that's
been
said
and
because
we're
at
time
right
now-
and
I
want
to
be
respectful
of
people's
time-
why
don't
we?
How
do
we
break
this
up
to
continue
async?
A
All
I
was
gonna
say
we
could
have
one
meeting,
basically,
where
we
do
the
plan
weekly
to
get
technical
input
from
everyone
on
the
team,
but
we
can
also
have
some
async
updates,
also
some
updates
with
just
maybe
like
interactions
with
product
and
design
kind
of
before
we
get
to
the
technical
piece,
so
we
can
kind
of
balance
it
out.
But
how
do
we
want
to
split
up
right
now,
moving
forward
next
steps
in
terms
of
process?
A
Do
we
need
to
have
another
meeting?
What
are
you
all
thinking.
C
I
I
created
an
issue:
it
needs
to
be
updated
and
tweaked-
probably
I'm
just
kind
of
dumping
stuff
in
as
we're
talking,
but
we
can
always
use
that
as
kind
of
a
continuation
point.
If
we
need
to,
I
put
it
in
the
agenda.
B
Could
you
create,
like
a
issue
just
like
from
a
product
perspective
around
like
objectives,
for
I
guess
kind
of
like
this
agenda,
but
like
a
tldr
of
it?
What
is
the
objectives
of
ux
of
dev
engineering
from
a
product
perspective
like
what
are
the
timelines
y'all
are
thinking
of,
and
then
we
can
maybe
collaborate
on
that
further
as
well.
A
Yeah,
I
will
create
that
this
afternoon
and
then
more
or
less
like,
if,
if
we
make
healthy
progress
async
on
that
this
week,
then
great-
if
not
I'll-
probably
try
to
schedule
another
time
first
to
synchronously,
make
a
decision
next
monday.
So
we'll
we'll
take
a
scene
and
see
if
we
can
move
things
forward
there
and
if
not,
then
we'll
get
back
together
secretly.
But
I
will
create
that
issue
in
an
hour.
So.
A
Okay,
thanks
for
the
time
everyone
I
will
upload
this
youtube
distributed
also
attached
to
that
issue,
cross
link
to
holly's
issue
that
she
created,
if
not
repurpose,
that
issue
or
add
to
it.
If
it
has
what
we
need
on
already
feel
free
to
repurpose
all
right
thanks
for
the
time
and
please
right
now
open
mind
and
ideas.
So
we
don't
need
to
limit
ourselves
too
much.
Let's
get
creative.