►
From YouTube: Plan | Weekly Sync
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
Okay
cool
plan
weekly
meeting
24th
of
April
Gabe
over
to
you
first.
C
Cool
I
just
want
to
take
a
second
to
kind
of
walk
through
what
we
are
communicating
externally
in
terms
of
our
roadmap
for
the
year,
you
can
check
out
the
slide.
Deck
I
won't
go
through
all
the
things,
I
think
we're
well
aware
of
it,
but
we're
definitely
focused
on
work
items.
C
We've
already
introduced
tasks,
which
is
great
we're
working
on
okrs,
which
is
going
to
be
awesome
and
I.
Think
one
of
the
major
themes
is
sort
of
representing
workflow.
We
did
a
great
ux
research
project
on
mental
bottoms
for
work
items
in
general,
or
you
know
how
these
relationships.
These
different
planning
artifacts
go
together
and
learned
a
lot
there
that
we
want
to
continue
to
carry
forward
and
then
I
think.
C
Ultimately,
we
want
to
get
to
some
flexible
playing
templates,
not
sure
what
this
is
going
to
look
like
yet,
which
is
why
we
just
have
boxes,
but
there
are
lots
of
different
agile
methodologies
that
different
organizations
use,
and
we
want
to
make
it
easy
to
use
git
lab
for
those
methodologies
out
of
the
box
with
as
few
as
little
configuration
as
possible.
So
we're
going
to
continue
to
explore
what
that
looks
like
over
the
long
run
and
then
we're
also
investing
a
lot
in
value
stream,
analytics
and
door.
Four
metrics
value
stream
dashboards.
C
C
We
also
High
them
open
a
great
issues
for
boring
flow
metrics,
which
is
a
common
thing
across
a
lot
of
those
agile
methodologies
and
then
we're
investing,
of
course
in
AI,
assist
workloads
but
I
think
the
great
kind
of
summary
of
it
all
is
what
we're
working
on
now
and
what
we
want
to
get
done
by
the
end
of
the
calendar
year.
I
think
we
want
to
be
able
to
migrate
ethics
to
work
items
that
framework.
C
We
want
to
start
working
on
the
status
field,
which
we
kind
of
talked
a
little
bit
about
and
making
that
a
first
class
thing
in
the
product.
So
we
can
move
away
from
having
to
use
like
labels,
for
that
which
is
going
to
be
a
huge
customer
win.
It
also
is
going
to
be
the
foundation
for
workflows
and
other
things
we
want
to
build
next
year
and
then
another
thing
that
we
need
to
do
in
terms
of
competing
with
some
of
the
other
players.
C
The
marketplace
is
custom
fields
and
I
think
we're
looking
at
that.
Maybe
is
using
data
tables
or
something
along
those
lines.
Definitely
none
of
the
solutions
are
finalized,
but
these
are
just
the
problems
that
we
want
to
tackle
during
the
year
and
then
we
want
to
eventually
migrate
issues
to
using
work
items
as
well
fully
and
then
make
some
improvements
to
road
maps.
Another
problem
playing
team
is
really
interested
in
moving
the
kind
of
save
using
queries
to
work
forward.
So
that's
going
to
be
exciting
too
and
then
value
stream,
analytics
and
deliverables.
C
They're,
optimizing
is
doing
some
great
work
around
AI
adeable
workflows
for
predictive
forecasting,
which
is
cool
and
then
I
think
we
want
to
consolidate
some
of
the
different
analytics
pages
and
make
those
more
kind
of
dashboardy
type
things,
so
they
can
be
kind
of
tailored
to
what
metrics
different
teams
or
different
stakeholders
are
interested
in
looking
at
even
time
in
terms
of
Snapchatting
and
then
adding
more
business
value
metrics
and
then
extending
the
VSA
Integrations
to
support
data
from
external
playing
tools
and
or
collaboration
platforms.
C
So
a
high
level
I
think
these
are
the
most
important
things
where
we
talk
about
later
they're
the
things
we
want
to
get
done
by
the
end
of
the
calendar
year.
We
need
to
push
hard
to
do
that
and
I
guess
I
just
wanted
to.
Let
everyone
know
that
this
slide
that
exists.
C
This
is
what
at
least
product
is
using
to
communicate
externally
and
to
internal
stakeholders,
and
so
in
terms
of
things
that
we
are
committing
ourselves
to
it's
what's
outlined
in
these
slide
decks
and
then
everything
else
is
going
to
be
sort
of
based
on
what
we
have
capacity
for
and
what
we
learned
as
we
progress
through
the
year.
C
So
I
just
wanted
to
highlight.
That
is
a
big
picture
thing
John!
You
have
the
I
guess
other
thing
is
you
started
learning
your
thoughts
or
push
back
to
the
scope
or
kind
of
what
we're
focused
on
feel
free
to
comment
and
John.
You
have
a
fresh
response.
A
Yeah,
it's
not
pushback.
I
was
just
wondering
about
work
items,
requirements
as
work
items
because
it's
still
listed
as
a
priority,
but
yeah
I
thought
with
the
the
spanning
of
the
certified
team.
The
intention
was
to
actually
take
capacity
away
from
doing
anything
with
work
items.
So
what's
the
status
there?
Is
that
a
mistake
or
just
something
that's
left
over
or
is
it
intentional
that
I
guess
the
product
planning
team
would
work
on
this
in
Q2.
B
Yeah
product
planning
is
working
on
it,
we're
actually
working
on
it.
Now
there's
been
some
work,
I
think
we're
trying
to
do
just
the
bare
minimum
right
and
I
think
the
back
end
is
already
completely
migrated
and
it's
just
the
front
end.
That's
not,
and
not.
I
haven't
scheduled
that
yet
for
the
next
two
Milestones,
so
I'm
guessing
like
64
65.
C
That
would
is
on
the
requirements
roadmap
already
in
terms
of
multi-level
requirements,
breakdowns
and
all
the
things
that
already
exists
in
the
work
or
will
exist
that
work
on
framework,
so
I
think
once
we
migrate
requirements,
we
don't
have
to
invest
enough
to
add,
continue
to
add
value
to
that
those
use
cases
from
the
warcraft
framework
as
a
whole.
If
that
makes
sense.
A
Yeah
and
just
from
the
engineering
standpoint
like
I,
would
be
supportive
of
finishing
it,
because
I
think
in
just
in
terms
of
efficiency
like
having
that
Tech
debt
removed
will
make
us
faster
and
all
the
other
things
that
we're
doing
around
work
items
I
think
in
around.
We
might
run
into
this
thing
with
requirements,
and
if
we
don't
work,
you
know
if
we
don't
complete
the
work
that
we
started.
It'll
slow
us
down
in
other
areas.
A
I
was
just
surprised
to
see
it
there
like,
because
I
thought
that,
from
a
product
point
of
view
like
we
didn't
want
to
invest
in
this
anymore
like,
but
I
am
happy
to
see
it
from
an
engineering
perspective.
B
A
A
D
Oh
mine
was
just
to
say,
I
think
we
should
complete
it
complete
the
orc
for
all
the
reasons
everyone
stated
and
if
I
purposely
left
it
they
yes
to
like
next
and
later
right.
But
if
you
all
think
that's
not
the
right
bucket,
we
can
shift
it.
So,
just
let
me
know
I'm
in.
A
All
right
so
after
the
next
one
as
well
so
two
interesting
features
that
I've
heard
before
at
least
one
of
these
I've
heard
before
but
I
didn't
say
anything
about
Gabe.
You
mentioned
one
there.
A
So
first
one
was
saved
filters
and
Views
and
then
the
second
one
is
I,
haven't
really
seen
it
all
before,
but
I
think
would
be
interesting
is
embeddable
views
so
like
just
neither
I'm
aware
of
the
wiki
and
Pages
a
little
bit
more
and
what
we
need
to
do
like
competitively
in
terms
of
competing
with
like
Confluence
or
something
is
we
need
to
be
able
to
embed
these
views
and
embed,
filtered
views
and
things
like
that
into
the
wiki.
A
So
is
this
something
we've
looked
at
before,
or
is
it
on
our
roadmap
anywhere.
C
I
think
for
the
save
views.
I
know,
ux
is
doing
a
lot
of
exploration
here
as
part
of
the
ux
okr
for
this
quarter
and
then
I
know
that
we,
a
product
planning,
is
going
to
be
driving
us
forward.
So
I
think
you
know
from
a
critical
path
standpoint:
getting
ethics
migrated
to
work
items
as
quickly
as
possible,
then
open
up
the
rest
of
the
year
for
them
to
prioritize
work
towards
the
kind
of
vision,
prototype
and
the
direction
we
want
to
go
and
yeah
so
I'll.
B
D
Yeah
I'll
just
take
a
minute.
I
put
this
slide
together.
This
is
meant
to
be
external
right,
like
shared
with
customers,
so
I
included
things
that
are
more
baked
things
that
are
more
certain
and
because
this
is
definitely
somewhere.
We
want
to
go,
but
as
far
as
I
know,
there
hasn't
been
any
kind
of
like
technical
feasibility
design
right
like
it's
very
early,
so
it
wasn't
included,
but
I
think
once
we
get
through,
like
Amanda,
said
the
bulk
of
migrating
items
to
work
items,
and
we
have
more
time
to
focus
on
this
I
know.
D
C
I'm
just
going
to
add
in
there
I
think
one
of
the
challenges
with
like
embeddable
using
things
like
that
and
markdown
or
in
the
content.
Editor,
is
the
fact
that
we
have
two
different
editors
right
now
we
have
the
content
editor,
which
is
based
on
Tip
Tap,
and
then
we
have
the
markdown
editor,
which
price
has
been
working
in
my
career.
C
I
can't
remember
what,
but
that
like
adds
a
whole
layer
of
complexity
when
we
think
about
doing
like
embeddable
things
into
content
areas
like
that,
because
we
either
have
to
duplicate
the
effort
and
do
it
with
the
content
editor
and
the
marked
editor,
but
we've
also
even
found
just
having
the
two
is
a
lot
of
overhead
from
I
guess
like
a
technical
perspective
and
it
even
running
the
experiment
with
AI.
C
Where
you
generate
summary
comments,
you
know,
like
I,
don't
think
the
button
to
do
that
was
on
the
content
editor,
but
was
on
the
marked
editor
and
you
end
up
getting
like
this
sort
of
drift
between
the
two
I've
talked
to
Donald
a
little
bit
about
this,
but
I
think
we're
gonna
figure
out
how
to
figure
out
as
a
stage
how
to
navigate
that,
because
it's
just
it
adds
a
whole
lot
of
complexity,
especially
when
you
think
about
getting
into
embeddables
and
then
even
real-time
collaboration
and
that
editor,
so
I
don't
know
what
the
solution
is.
C
A
All
right
cool,
if
that's
everything,
then
yeah
on
you
for
the
next
point.
E
Yeah
this
one
is
more
I
can
specific
I
edit
a
link
to
PLC,
which
I
worked
on
recently,
it's
a
POC
about
generating
a
rest
wrapper
on
top
of
our
graphql
API.
The
reason
is
that
our
long-term
strategy
is
to
use
graphql
as
a
primary
API.
F
E
At
this
point,
we
have
rest
API
completely
separated,
so
any
increase.
The
API
at
this
point
means
developing
just
a
separate
API,
so
this
attempts
to
generate
a
rest
wrapper
on
top
of
graphql.
This
one
is
a
little
bit
different
than
previous
attempts,
because
it
works
like
generating
static,
called
I,
mean
API
definition
instead
of
trying
some
Dynamic
magic.
So
it's
more
like
what
we
do
with
graphql
documentation,
Generation
generation
of
graphical
documentation.
E
So
if
you
have
some
thoughts
or
ideas
or
concerns,
please
leave
their
feedback
or
whatever
you
think
about
it,
because
so
far
it
seems
that
there
are
no
Road
roadblocks
which
couldn't
be
solved
so
I
plan
to
create
a
blueprint
for
this
and
then
see
if
if
it
would
be
accepted
or
approved
by
principal
Engineers,
so
we
could
go
with
it.
A
Yeah
I
was
just
interested
in
what
the
primary
concerns
of
the
working
group
are
given
that,
like,
like
you
said,
it's
been
attempted
a
couple
of
times,
and
this
I
mean
there
may
be
no
perfect
way
to
do
this
right
to
like
wrap
the
graphql
API
for
rest
API,
and
this
seems
like
the
solution
with
like
the
least
problems,
the
least
number
of
problems
so
yeah.
What
were
the
issues
that
were
raised
by
the
working
group.
E
Yeah
so
I
think
that
pretty
much
feels
which
were
discussed
was
as
different
application
strategy
because
photographql
we
allowed
to
duplicate
something
after
six
months
and
then
remove
it
with
the
next
major
version,
which
is
not
the
case
with
rest
API,
where
we
rely
on
major
versioning.
So
breaking
changes
can
be
removed
when
we
increase
the
major
version.
G
E
Actually,
haven't
happened
in
last
five
years
or
all
the
time
I
work
at
GitHub,
so
so
this
is
quite
not
very
deprecation
friendly,
or
at
least
we
are
very
conservative
in
bumping
issue
versions.
I
think
that
there
is
no
simple
solution
for
this.
I
was
hoping
that
if
you
want
to
use
it
at
least
for
new
endpoints,
we
could
just
Mark
the
new
endpoints
as
experimental
or
mark
them
as
some
graphical
specific
deck.
E
The
another
problem
was
machination
where
in
the
rest,
API
we
use
offset
in
in
graphical,
we
use
key
Set,
and
this
still
seems
to
be
a
concern.
But
that
mentioned
or
pointed
me
to
to
graphical
code,
which
probably
should
make
this
possible
without
too
much
effort.
So
I
want
to
try
this
out
to
see
if
it
will,
if
it
would
work
and
another.
E
Yeah
okay,
so
if
the
outcome
is
that
this
wouldn't
be
possible,
then
we
will
have
to
decide
whether
it's
acceptable
to
mix
both
paginations
or
if
we
would,
if
we
would
need,
for
example,
two
bump
the
major
version
and
introduce
key
sets
for
rest,
API
or
separate
World
completely.
E
But
personally
I
would
expect
that
for
new
endpoints
it
would
be
still
acceptable
for
acceptable
to
use
key
set
pagination
for
new
endpoints
in
combination
with
offset
position.
But
I
think
that
this
is
probably
not.
There
is
no
consensus
about
this.
Yet
so
trying
to
implement
offset
in
graphql
would
be
primary
or
primary
goal
for
now.
E
But
the
point
is
that
if
you
will
try
to
fetch,
for
example,
on
the
ID
or
Eid
or
some
other
basic
attributes,
then
I
was
getting
quite
scenario
numbers
if
I
compare
both
or
if
I
compare
this
with
the
prepper
so
yeah.
E
The
point
is
that
graphical
might
should
be
able
to
be
equally
fast
as
rest
API,
but
we
will
have
to
decide
whether
we
want
performance,
better
resource
perform
on
very
Source
permission,
checking,
which
I
think
we
want
in,
even
if
it's,
if
the,
even
if
the
price
is
worth
performance
or
if
we
really
need
to
do
some
optimizations
yeah.
So
these
were
so
far
the
major
concerns
which
were
discussed
and
yeah.
If
you
think
or
if
you
know
about
some
others,
it
would
be
best
to
think
about
these.
E
C
Yeah
I'm
just
gonna,
say
that's
something:
I
thought
we
should
do
for
a
long
time
either
one
way
One
Direction
the
other,
so
we
don't
have
drift
between
the
apis,
which
we
do
now
and
a
lot
of
customers
are
frustrated
with
that.
So
I
think
this
is
awesome.
I
think
you
highlight
this,
but
my
only
concern
is
that
the
performance
of
graphql,
you
know
if.
C
E
E
Regarding
this
I
would
love
or
I
think
that
it's
important
for
this
rapper
to
be
first
used
in
combination
with
existing
endpoints
I
mean
I
would
love
to
avoid
trying
to
do
replacement
of
everything,
with
rather
being
able
to
use
this
wrapper
in
combination
with
our
existing
Crest
endpoint.
So
we
could
test
it
in
production
on
some
new
endpoints,
where
some
performance
degradation,
if
any,
is
not
critical
yeah.
E
So
so
we
could
first
slowly
introduce
it
and
iteratively
edit
four
new
endpoints
and
then
iteratively
migrate,
some
old
endpoints
to
the
new
ones,
with
the
new
version
of
major
API
version,
so
yeah,
but
I
I
can
imagine
that,
for
replacing
existing
endpoints
or
performance
degradation
might
be
a
problem
and
it
would
require
some
performance
performance
investigation
of
problems,
foreign.
D
I
want
to
say,
I'm
glad
to
see
the
plan
stage
contributing
to
this
I
know.
This
has
been
a
long
time
in
the
works
with
the
working
group
and
the
idea
in
general,
and
it's
good
to
see
be
on
the
Forefront
of
like
the
first
actual
endpoint
being
implemented.
So
thanks,
Amanda
and
Jan
for
taking
this
on.
E
F
F
But
that's
you
know,
I
mean
it's
it's
kind
of
a
hybrid
approach
and
maybe
the
ultimate
solution,
but
that
might
be
one
way
of.
E
Yeah
yeah
yeah,
I,
agree
and
yeah.
You
are
I'm
on
the
same
I
agree
with
you
and
for
this
reason,
I
think
it's
important
that
this
rapper
could
be
used
in
combination
with
this
native
rest
endpoints
on
the
other
side
from
long
term
point
of
view,
if
we
know
that
one
of
my
contributors
of
this
performance
degradation
is
extra
resource
permission
check,
then
the
question
is
okay.
C
Well,
yeah,
so,
as
we
sort
of
introduce
time
boxes
to
work
items,
we
have
the
ability
to
sign
iteration
or
a
milestone
into
a
issue
or
to
a
task.
C
We
did
some
initial
solution,
validation
on
the
expected
Behavior
here,
but
as
we
eulian's
been
working
on
this,
some
of
the
other
questions
have
raised
like
everyone's
raised
some
great
questions
about
how.
How
does
this
extend
to
things
where
you
might
have
three
levels
or
four
levels
and
I
think
there's
a
proposal
that
kind
of
fast
follows
the
NPC
for
preventing
double
counting
on
time
box
reports.
C
But
one
of
the
sticking
points
was
like:
how
do
you
handle
like
I,
think
with
weights
where
we're
picking
you
know
the
aggregate
weights
from
all
the
leaf
nodes?
And
that's
what
shows
up
but
tasks
or
account
is
a
little
bit
different,
because
if
you
assign
you
know
a
time
box
to
let's
say
what
is
today
an
epic
directly.
C
Does
that
count
is
one
thing
on
your
burn
up
or
burnout
charts,
or
does
that
you
take
accounts
of
all
the
children
items
or
do
you
use
this
same
approach
with
just
the
leaf
nodes
and
only
count
the
leaf
nodes
of
all
the
items,
because
it
might
not
make
sense
if
you
have
an
epic
that
has
five
issues
in
it?
That
has
each
issue
has
five
tasks
to
count
that
as
just
one
thing,
while
you're
counting
the
aggregate
weight
of
all
the
tasks.
C
If
that
makes
sense,
if
it's
present
so
I
was
curious
on
what
y'all
thought
would
be.
You
know
in
terms
of
consistency
here
and
then
I
would
love
to
consolidate
that
with
next
round
of
kind
of
customer
Discovery.
So
I'm
curious.
If
you
have
any
thoughts,
but
this
I
brought
up
here
because
it
does
impact
I,
think
all
this.
You
know
planning
hierarchies
all
that
good
stuff,
so
it's
worth
kind
of
getting
aligned
as
a
stage.
A
One
thing
that
I
remember
is
that
one
of
our
like
larger
customers,
wanted
to
sign
a
way
to
epics
as
a
kind
of
Target
weight
or
a
kind
of
upper
limit,
and
then
when
they
would
wait
issues
underneath
they
would
have
like,
like
basically
an
idea
of
like
oh,
we
thought
this
would
be
a
hundred
points.
It's
actually
120.
Can
we
get
rid
of
some?
A
You
know,
and
that's
so
to
me,
like
they
were
two
completely
different
things
almost
like
there's
a
signed
weight
and
there's
roll-up
weight
and
we
want
to
show
them
both
and
treat
them
both
differently.
But
then
I
don't
know
how
that
translates,
then,
to
like
a
burned
down
chart
where
you
know
like
say:
you're,
looking
at
a
bunch
of
issues
and
some
have
tasks
and
some
don't
and
some
of
the
tasks
have
weights
and
some
have
real
issues
of
roller
blades
and
some
have
assignment
like
I.
A
C
I
think
right
now
we're
what
we
validated.
The
customers
expect
it's
most
intuitive
for
customers
expected
if
there's
an
s
parent,
a
wait
on
a
parent
and
then
there's
weight
on
the
children
you
use.
The
aggregate
way
of
the
children
is
the
thing
you
report
on,
but
you
within
the
new
work
I
view
we
want
to
show
the
weight
on
the
parent
side
by
side
with
the
weight
on
the
roll
plate,
so
you
can
see
like
here's,
the
estimate
actual
estimate.
Basically,
so
you
can
learn
from
that
I
think
lots
of
customers
are
interested.
C
That
is
a
great
data
point
on
getting
feedback
for
themselves
on
how
well
they're
doing
those
sort
of
like
higher
level
estimates,
and
so
that's
where,
like
a
lot
of
the
validation
that
we
did
was
focused
on
weights,
but
we're
sort
of
now
thinking
about
counts
and
accounts
should
follow
the
same
pattern,
because
that's
one
things
we
didn't
touch
on
as
heavily
in
the
customer
interviews
that
we
had
for
validating
the
weight
roll
up.
If
that
makes
sense,
so.
E
I
I
I
I,
don't
use
the
noun
charts.
My
first
thought
is
that
just
summary
of
leaf
notes
to
make
most
sense
like
if
I,
if
I
have
epic
or
issue
which
is
broken
down
into
subtasks
I,
would
expect
that
the
total
count
is
just
summary
of
all
its
sub,
all
its
children
or
subtasks
or
whatever,
but
yeah
I
can
imagine
that
it
doesn't
match
all
the
use
cases
in
just
first.
So.
F
F
You
know
it's
it,
it's
not
it's
not
broken
down
at
all
and
even
breaking
it
down
into
tasks
might
not
be
complete.
So
now
would
you
might
you
might
say?
Okay,
you
don't
understand
the
full
scope,
you
break
it
down
in
a
couple
tasks,
because
these
things
have
to
be
done.
They're
both
weighted
one,
but
in
general
the
issue
is
a
five,
because
it's
I
don't
know.
That's
it's
a
tough.
It's
a
tough
question.
B
That's
a
thing
Brett
like
at
the
higher
level.
People
want
to
retain
their
estimates
as
well
like
at
the
Epic
Level
before
anything's
broken
down,
and
then
they
want
once
the
work's
in
progress
to
see.
What's
the
estimate
versus
the
actual
shift
what's
new
or
wasn't
planned
all
of
those
things,
so
there's
a
lot
of
granularity
and
I.
Think
Melissa's
point
is
valid.
This
should
be
something
we
should
take
online
as
a
bigger
discussion.
C
H
I
mean
I
I
think
there's
a
lot
of
other
questions
around
like
like
because
we
don't
have
weight
on
epics
and
we
don't
have
the
ability
to
assign
another
book
to
a
time
box
today
and
like
what
is
I
mean
wait.
It's
part
of
that
consideration,
but
like
really
what's
the
expected
like
if
I
can
add
something
to
them,
I
also
like.
Why
am
I
doing
that
and
what
do
I
think
is
going
to
happen
to
all
the
child
issues
and
Etc
like
there's,
there's
a
broader
question.
There
I
think.
C
Yep,
you
can
do
that
with
objectives
now,
though,
where
you
can
sign
those
to
Milestones,
so
those
that
you're
likely
show
up
I
think
that's,
let's
have
a
separate
mean
to
sort
out
what
we
want
to
research
and
validate
and
we
can
go
from
there.
G
D
D
E
Just
for
more
context
about
this
discussion,
we've
made
some
counts,
I
Rise,
this
question:
whenever
we
win
the
match
request
and
also
we
don't
support
epics
at
this
point,
we
do
have
objectives
and
look
nine
levels
of
objectives
and
key
results
which
are
now
displayed
in
in
the
issue
list
of
Milestone
I.
Think
and
this
will
be
displayed
there.
So
I
was
wondering
how
this
would
work
together
with
this.
E
But
if
the
plan
is
for
now
to
just
restrict
these
two
issues
and
tasks,
that's
possible
too,
but
then
I
was
wondering
if
it
isn't
confusing
that
users
see
also
objectives
and
key
results
in
the
list
of
Milestone
issues,
but
these
are
not
reflected
in
the
burnout
chart.
But
if
you
want
to
restrict
these
two
issues
and
tasks
for
now,
that's
entirely
possible
too,
but
there
will
be
this
inconsistency.
What
we
show
in
the
list
versus
what
we
show
in
the
chart.
C
Makes
sense:
okay,
I'll,
take
it
all
action
to
get
some
more
important
questions
and
schedule
meeting
I
think
I
had
the
next
one.
C
This
is
more
of
like
something
that's
upcoming,
because
I
know
the
service
desk
category,
which
is
owned
by
the
respond
group
and
monor
stages,
exploring
maybe
potentially
adding
a
new
work
item
type
called
ticket
details
and
all
that
stuff
is
still
to
be
determined.
But
I
wanted
to
ask
the
engineers
like.
C
Are
we
the
place
from
an
architecture
standpoint
where
we
can
add
a
newer
kind
of
type
to
the
database
and
not
have
to
rely
on
like
the
enums
and
hard
coding
stuff
and
all
those
things
we
are
trying
to
move
away
from
with
more
kind
of
types.
E
Cript
check
his
points,
but
as
far
as
I
know,
we
are
not
done
with
others.
Technical
Labs,
we've
using
specific
work,
item
types
or
issue
type
I
think
we
still
use
it,
but
we
know
how
to
actually
use
it
for
a
new
code
like
use.
E
I,
don't
think
there
is
a
specific
talker
with
introducing
a
new
type
depending
how
specific
or
difference
it
would
be,
but
yeah
I'm
not
aware
of
locker
itself.
It
only
concern
would
be
that
still
some
missing
bits
will
have
to
be
developed,
so
if
they
need
something
extra
special
one
thing
which
I
think
we
don't
have
soft
is
permission
checking
or
pair
type
or
you
have
some
specific
work
item
type
checks,
but
I'm
not
sure.
If,
if
it's
very
consistent
to
this
point
but
yeah
I,
don't
know
about
Locker
itself,.
F
For
breath,
I
I
do
think.
Mario
probably
has
a
better
overall
or
certainly
has
an
opinion
on
it.
I
know
he's
been
working
recently
to
try
to
move
forward.
The
complete
removal
of
the
issue
type
in
favor
of
the
work
item
type
so
and
I
do
because
of
the
work
with
with
objectives
and
key
results.
I
do
think
that
we've
got
most
of
it
in
there
to
be
able
to
add
another
type,
but
I'm
I'm,
not
100
on
that.
So
yeah
Mario
might
have
a
better
opinion
on
that.
C
Cool
thanks,
yeah
I'll
wait
to
get
the
proposal
from
respond
on
what
follow
the
ticket
look
like
and
I'll
collab
with
Mario
async
on
that
stuff,
I'm,
Loop
and
anywhere
else.
That
wants
to.
C
We
can
do
the
5B
offline.
I
was
just
curious
like
how
Engineers
decided
to
which
issues
to
pick
up
next,
and
where
do
you
all
look
and
what's
the
decision
making
process
that
sort
of
thing?
But
we
can
do
that.
I
think
I
think
I'm
more
Curious
to
talk
about
the
next
thing,
which
I
just
happen
to
have
coffee
chest
to
be
engineers
and
plan.
C
Lately
did
all
sort
of
like
independently
shared
feeling
a
bit
isolated,
which
and
I'm
we'll
bring
this
up
in
the
Retro,
probably
too,
to
discuss
async
but
I'm
curious.
If
one
has
any
ideas
for
how
we
can
like
become
a
bit
more
like
team
Centric
or
something
along
those
lines,
it's
really
easy
to
get
lab
to
feel
isolated.
I've
felt
it
myself
frequently
just
where
you
know
you're
going
about
your
daily
work
and
you're
working
on
your
own
things
and
then
all
of
a
sudden.
C
You
do
that
long
enough
and
you
feel
disconnected
from
everyone
and
then
that
sort
of
then,
like
kind
of,
is
a
hit
to
motivation
and
kind
of
a
job.
Satisfaction,
a
bunch
of
other
things.
So
I
was
curious.
If
anyone
had
any
ideas
for
how
we
can
actively
combat
that
sort
of
from
setting
in
that
makes
sense,.
G
Comes
from
Engineers,
we
had
a
nice
experience
within
project
management
with
the
pupar
programming
session
and
debugging
sessions,
so
it
feels
more
like
a
teamwork,
at
least
for
front-end
Engineers,
that
we
have
and
also
I,
think
we
should
encourage
people
asking
questions
and
getting
answers
in
public
channels
as
well.
Let's
personally
I
have
a
fair
share
of
DMS,
normally
daily
and
given
answers
and
while
I'm
encouraging
people
to
go
public
with
the
questions.
B
Yeah
I
was
just
going
to
say,
I
think
when
folks
demo
in
this
meeting
it's
very
successful,
but
maybe
we
could
back
it
up
and
as
Engineers
are
taking
work
that
could
affect
all
groups,
mention
it
before
you
even
dive
in
in
this
call
to
kind
of
elicit
or
solicit
rather
collaboration
among
other
people,
ideas
and
things.
I
I
It's
not
the
same
kind
of
demo
as
engineering
work,
but
one
thing
that
I'm
going
to
be
working
on
is
trying
to
share
more
often
with
this
group,
because
some
of
the
research
we're
doing
would
affect
a
lot
of
the
different
groups
and
especially
Downstream
so
I
think
it's
also
just
a
good
reminder
that
the
space
could
be
that
we
can
share
a
lot
of
different
types
of
things
here
and
just
like,
plus
one
on
the
sentiment
of
sometimes
feeling
isolated.
A
F
And
I
guess
I
just
like
to
say
that
it'd
be
nice
to
see
I'd
like
to
see
more
mentions
in
the
in
the
actual
slack
channel
on
the
plan.
Select
Channel,
not
just
in
here,
because
I
don't
feel
like.
We
can
it'd
be
neat
to
discuss
in
the
channel
a
little
bit
more
or
at
least
just
see
more
awareness
of
it.
A
Yeah
so
I
don't
know
about
you,
but
I
find
the
Q4
team
day,
pretty
awesome,
so
I
think
Amanda.
You
mentioned
before
that.
You
would
like
to
repeat
this,
and
it's
probably
on
one
of
us
to
organize
it.
So
if
people
think
it
would
be
valuable,
yeah,
oh
awesome,
yeah
I'll,
sign
it
to
you,
Santa,
Amanda
and
I.
Don't
have
to
do
anything.
A
Awesome,
yeah,
that'll,
be
great
and
then
also
like.
If
you
remember
before
the
last
one
folks
were
already
volunteering,
a
couple
of
ideas
for
sessions
or
anything.
So
if
you'd
like
to
do
that,
that
really
helped
us
organize
it,
because
then
we
could
figure
out
like
how
long
to
make
the
sessions
and
we
knew
that
it
wasn't
gonna
just
fall
on
its
face,
like
I,
don't
know
about
you,
but
I
personally
make
a
much
better
Hollandaise
sauce
since
the
last
team
day.
A
So
and
it
was
worth
it
you
know
just
for
that
alone,
so
yeah
any
ideas
for
sessions
and
also
like.
Maybe
we
can
just
open
the
issue
and
just
check
with
people
what
time
works
for
them
and
we'll
Target
it
in
Q2
at.