►
From YouTube: [2022-07-20] Next Architecture Workflow
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
Good
I,
we
are
desperately
rushing
around
to
get
the
second
dedicated
customer,
onboarded
and
so
I
might,
depending
on
what.
If
people
ping
me
I
might
have
to
jump
off,
but
we'll
see.
A
B
It's
one
of
those
deadliney
type
situations.
B
Today,
no
it's
it's!
It's
actually
Friday,
but
really
tomorrow
and
you
know,
as
is
always
the
case,
then
today
we
just
discovered,
like
some
nice
fat,
bugs
that
we
need
to
fix,
which
are
great
and
the
the
you
know.
The
thing
well,
as
you
know
like
with
this
terraform
stuff,
if
there's
a
bug
in
what
you've
provisioned
it's
much
harder
because
then
you
need
to
be
able
to
kind
of
take.
B
B
A
A
All
right
since
we're
at
time,
I'll
go
ahead
and
start
things
off.
The
the
first
question
I
had
was
to
anybody
who
participated
in
the
previous
architecture.
Kickoff
working
group
does.
Does
anybody
know
where
the
recordings
for
those
meetings
ended
up
because
I
haven't
been
able
to
find
them
on
on
YouTube
or
Google
Drive.
A
Okay,
I'll
I'll
keep
digging
then,
but
if
anybody
like
stumbles
across
them,
just
let
me
know
async,
because
that
would
be
great
there's
like
a
couple
of
the
meetings
that
I'd
like
to
catch
up
on
after
reading
the
notes
and
I
I
can't
find
them.
A
So
on
to
two
last
week,
we
discussed
alignment
on
problem
statements
and
Eric
in
particular,
brought
up
under
I,
think
it
was
one
B
last
week
the
the
importance
here
and
I
quoted
something
that
he
had
mentioned
down
below,
but
the
the
highest
impact
thing
we
can
do
is
looking
at
how
we
can
incorporate
into
the
next
prioritization
process
and
I
100
agree
that
that's
the
main
problem
that
we
should
focus
on
solving
here,
at
the
same
time,
like
I
I,
think
if
we
hyper
focus
on
that
problem,
that
would
be
a
great
solve
and
that
would
be
super
effective.
A
But
there's
a
couple
things
that
I
wanted
to
make
sure
that
we
still
captured
so
I've
tried
to
Define,
like
the
the
proposed
problem
statements
that
I'd
like
to
add
to
the
handbook
page
after
this
meeting
under
2C.
A
The
the
two
things
I
didn't
want
to
leave
off
the
table
were
the
consolidation
of
Downstream
processes
with
the
blueprint
process.
So
that
would
be
like
production,
Readiness
reviews
and
apps
reviews,
I.
Think
I.
Think
by
like
following
the
architecture,
Evolution
process
and
producing
a
blueprint,
you
should
be
able
to
get
a
lot
of
that
for
for
free
and
anything.
We
do
to
to
streamline
that
process.
A
I
think
bolsters
the
the
point
about
prioritization,
because
if
the
process
is
is
more
efficient
than
taking
advantage
of
it
as
part
of
the
next
prioritization
become
becomes
even
better
and
the
third
one
is
a
bit
more
forward-leaning
Eric
mentioned
that
you
know.
Creating
some
sort
of
like
unified
road
map
is
not
something
that
we're
going
to
solve
in
in
the
short
term
and
I
agree
with
that
as
well.
A
A
You
know
compare
what
we
want
to
get
done
versus
what
product
wants
to
to
get
done
in
any
sort
of
like
cohesive
manner
that
allows
us
to
pit
new
feature
development
against
architecture,
changes
or
or
other
maintenance
activities
that
we
want
to
execute
on,
so
that
that
one's
sort
of
just
to
plant
a
flag
in
the
sand.
I
think
you
know.
Ideally,
we
would
still
unify
those
road
maps
at
some
point
in
the
future.
A
But
as
far
as
this
working
group
goes,
I
think
I
think
we
can
look
to
enhancing
the
blueprint
process
and
making
it
the
the
means
for
defining
engineering's
overall
roadmap
across
all
all
departments.
C
I
I
guess
I,
don't
I,
don't
just
screw
the
result,
but
like
the
way
I.
Think
of
it
is
like
the
the
closest
thing
we
have
to
like
engineering's
roadmap
right
is
essentially
the
it
emerges
from
this
engineering
allocation
meeting
where
here
we
status
the
big
sort
of
like
engineering
driven
projects
that
we're
doing
at
any
given
time.
C
If
you
were
to
lay
these
things
out
on
a
Gantt
chart,
that
would
be
a
road
map,
so
we
could
probably,
as
just
thinking
in
terms
of
smaller
durations,
we
could
figure
out
a
way
to
kind
of
like
produce
that,
like
just
take
each
one
of
these,
get
the
best
idea
of
start
and
end
dates
from
the
dris
and
just
put
them
on
a
cant
chart
or
even
better
yet
like.
C
If
we
build
epics
around
them
and
we
could
power
our
portfolio
management
feature
set,
it
would
be
in
gitlab
and
then
we
have
you
know.
Then
then
we
have
something
and
then
we
can
I
think
that
helps
you
know
armis
for
the
for
the
conversations
about
like
how
to
Advocate
that
these
projects,
you
know
a
lot
of
these
projects-
are
very
cross-functional
right,
so
thinking
back
to
and
we
eliminated
sub
transactions
from
the
the
code
base.
That's
something
that
would
have
hit
many
many
different
teams.
So
what
we'd
have
to
do?
C
So
it's
a
very
cross-team
cross-functional
project
and
that's
really
important
to
get
right,
because
the
the
PMS
are
very
functionally
oriented
right
so
like
they
only
think
in
terms
of
their
feature
set
right,
and
that's
one
of
the
reasons
why
historically,
it's
really
hard
to
get
something
like
hey
PM,
like
just
understand
the
value
you
need
to
like
delay,
some
features
because
you
have
to
remove
all
sub
transactions
from
your
thing
that
totally
disrupts
their
their
product
roadmap,
which
makes
sense
it's
not
their
view
into
the
same
information,
but
it,
but
so
I
I
think
we're
closer
to
having
a
roadmap
than
it
than
it
maybe
appears,
and
we
could
just
if
we
just
visualize
this.
C
I,
don't
think
everything
I,
don't
think
everything
in
this
engineering
allocation
dock
requires
a
blueprint
to
action.
It
I
think
some
some
certainly
do
like
functional
decomposition
of
CI
is
something
that
would
be
screened
for
this
type
of
work
right.
Other
things
are
kind
of
a
different
character
of
work.
So
I'd
say,
like
you
know,
there's
there's
some
overlap,
but
not
complete
overlap
in
the
Venn
diagram
of
of
engineering,
maintenance
or
engineering
allocation
projects
and
things
requiring
blueprint
up
front
Okay.
A
The
the
the
reason
I
think
it
would
be
good
to
Define
them
as
blueprints
or
or
or
some
sort
of
like
lighter
weight
proposal
that
that
is
still
like
managed
as
code.
In
the
same
way,
it
is
just
that
it's
a
it's
a
good
communication
tool
and
it
and
like
you,
you
could
do
that
with
issues
and
ethics
too,
except
that,
like
I,
think.
A
C
Yeah
issues
and
issues,
epics
and
blueprints
are
not
mostly
exclusive
right,
so
like
we
have
to
have,
we
have
to
track
work
items
and
that's
the
issue
in
epics
are
for
and
the
blueprint
is
really
where,
like
the
the
technical
vision
is
so
what
I
would
do
is
if
someone
could
take
an
action
to
kind
of
like
go
through
the
the
latest
engineering
allocation
agenda.
C
Put
it
into
a
Gantt
chart
view
you
can
use
a
spreadsheet,
you
can
use
a
Gantt
tool,
you
can
try
to
use
their
own
portfolio
management,
feature
kind
of
dealer's
Choice,
and
then
we
can
look
at
these
things
next
meeting
and
say:
okay,
like
this
is
the
subset
that
deserves
Blueprints,
and
then
you
know,
if,
if
you
want
to
make
it
a
big
push
to
go
back
and
retroactively,
do
blueprints
for
all
of
them.
That's
a
valuable
exercise.
A
Okay,
I'll
I'll
take
that
action,
and
this
this
may
not
be
the
best
example,
but,
like
the
one
I
had
in
mind,
was
it
but
like
when
we
look
at
stuff
like
like
pods.
A
But
even
something,
that's
that's
a
bit
smaller
than
that
that
that
requires
like
the
same
sort
of
like
change
in
mindset
or
or
or
change
in
engineering
culture,
I
think
is,
is
important
to
document
in
the
form
of
a
blueprint
just
so
when
people
are
building
new
functionality,
they
they
have
the
future
state
in
mind.
Right
like
today,
we
shouldn't
be
building
anything
new.
That's
not
going
to
fit
nicely
in
a
pod
architecture.
A
Right
so
like
people
should
be
thinking
of
things
as
like
decomposed
by
default
right
horizontally,
scalable
out
of
the
box
ability
to
run
stuff
in
a
pod
like
architecture
right,
but
we
we
don't.
We
don't
have
a
blueprint
for
pods.
So
there's
nothing
for
us
to
like
I
mean
aside
from
pointing
to
the
deck,
there's
nothing
that
we
can
point
to
so
that,
like
when
people
are
engineering
solutions,
they
know
they
need
to
engineer
it
to
this
future
spec
to
some
degree
right.
C
B
It's
also
Eric
a
lot
of
the
examples
you
used
were
around
like
technical
debts
and
I
think
you
know,
particularly
with
sub
transactions,
it's
kind
of
like
a
task
that
everyone
needs
to
share
and
kind
of
break
up
and
and
do
and
to
some
degree
it's
kind
of
by
Road
task,
like
everyone
just
needs
to
go
through
the
code
base
and
stop
using
sub
transactions.
B
But
then
there's
a
lot
of
places
where
actually
you
want
a
blueprint
for
like
an
idea
for
new
feature
or
something
some
new
part
of
the
of
the
product.
Obviously
I'm
working
on
dedicated
at
the
moment
and
everything
we're
doing
is
new
and,
and
we
always
start
those
that
it's
not
technical
debt.
B
And
then
you
know
other
things
like
cars
or
like,
let's
adopt
websockets
for
real-time
updates,
like
those
are
things
that
are
they're,
not
really
featured
or
they're,
not
dead,
but
they're
features,
but
it's
still
really
good
to
use
some
architectural
blueprints
as
a
way
of
syncing
across
the
organization
and
then
the
last
kind
of
example
I
wanted
to
use
just
one
more
is
is
things
that
we
don't
really
have
yet
and
on
brilliant
engineering
allocation,
but
maybe
should
be
in
and
I
haven't,
attended
engineering
allocation
for
a
while.
B
C
And
so
yeah
I
think
that's
I
think
that's
a
good
way
to
think
of
it
like
if
we
were,
if
we
don't
have
a
great
definition
of
what
deserves
a
blueprint.
What
does
it
now
like
that
new
forward-looking
feature?
Is
it's
a
it's
a
good,
a
good
way
to
think
of
that
so
I
think
like
there's,
there's
I
care
about
getting
all
the
maintenance
stuff
wired
up
to
the
cross-functional
prioritization
process,
there's
a
subset
of
that.
That
is
what
you're
talking
about
Andrew
and
what
you're
talking
about
Marshall.
C
That
also
requires
blueprints
right,
so
I'm
trying
to
serve
many
goals
at
the
same
time,
but
but
yeah
there's
so
yeah.
Let's,
let's
look
at
it
and
see
like
okay,
what's
based
on
what's
in
the
engineering
allocation
agenda
today,
what
does
a
Gantt
chart?
C
Look
like
which
ones
don't
have
blueprints
that
you,
you
all
think
should
have
Blueprints
and
then,
let's
see
you
know
what
we
do
next
from
there
do
we
go
back
and
create
them
all,
or
is
there
some
other
source
of
projects
that
are
being
thought
about,
like
I,
assume
the
dedicated
stuff?
Isn't
an
engineering
allocation
so
I
might
want
to
go
and
and
call
other
types
of
projects
as
well
and.
A
If
I,
if
I
just
look
at
like
I,
see
the
last
one
is
from
the
19th,
does
the
latest
engineering
allocation
meeting
represent
the
full
current
state
or
do
I
need
to
go
back
a
couple
weeks
to
get
all
the
items.
C
Everything
that's
currently
outstanding
should
be
in
that
July
19th
update,
okay,
great!
If
you,
if
you
go,
if
you
wanted
to
assemble
a
longer
Gantt
chart
and
go
back
in
time,
you
could
go
down
the
agenda
and
there
would
be
projects
that
have
are
now
closed.
That
would
have
been
opened
at
a
previous
Point
time.
A
I
I
think
the
discussion
we
were
just
having
is
a
good
segue
into
three,
where
I
think
we
could
use
I
think
it'd
be
useful
to
have
better
terminology
than
than
architecture,
because
I
think
a
lot
of
folks
have
a
different
opinion
on
on
what
architecture
means
and
to
to
Andrew's
point
I.
Think,
there's
things
that
we
wouldn't
not
categorized
as
architectural
changes
that
require
a
similar
level
of
of
coordination,
but
but
aren't
like
new
features
either
like
I
I.
Think
another
good
example,
aside
from
the
ones
Andrew
mentioned,
is
like.
A
If
we
were
to
look
at
migrating
the
JavaScript
code
base
to
typescript
right.
That's
certainly
something
that
I
would
expect
to
follow
the
Evolution
process
and
and
have
a
blueprint
around
and
would
probably
consider
it
maintenance.
A
But
but
to
me
it
doesn't
architecture,
isn't
the
right
term
to
describe
that.
I
mean
I.
I,
think
you
can
easily
shoehorn
the
term
architecture
to
to
Encompass
most
things
but
I.
Think
in
terms
of
communication.
It's
it's
not
clear
amongst
folks
what
an
architecture
blueprint
is
or
what
it's
for.
C
And
I
I
think
by
most
folks
the
entire
world
is
not
clear,
consistent
about
how
to
use
the
term
architecture
right.
One
thing
I
put
in
there
is
that
I'm
certain
that
people
always
use
that
word
right,
so
that
I
think
you
you
meaningfully
ball
agree
like
we
should
have
clear
terminology
or
no
controversy
there
I'm
on
the
fence
about
whether
or
not
we
should
just
use
the
term
and
own
it
and
Define
it
rather
than
try
to
ban
it,
and
then
people
will
use
it
anyway
and
it'll
just
keep
adding
to
the
confusion.
A
The
I
think
the
the
risk
is
that
I
I,
so
the
front-end
Engineers
have
a
sort
of
like
RFC
process
where
they
hash
things
out
and
I
I'd
love
to
see
like
I,
think
I
think
the
risk
is
if,
regardless
of
how
we
Define
it,
if
people
take
a
glance-
and
they
say
oh
architecture-
blueprint
well
that's
much
bigger
than
than
what
I'm
proposing
or
like
what
I'm
proposing
is
not
an
architecture,
change
that
they
would
go
and
and
and
create
their
own
process
or
or
use
issues
in
epics,
where
a
blueprint
would
would
be
more
ideal,
so
I,
basically
I
just
I,
don't
want
to
I
think
there's
risk
in
scaring
people
off
to
to
not
following
the
process
and
that
that's
where
I
think,
like
some
looser
terminology,
might
might
be
helpful.
D
Yeah
I'm
sometimes
trying
to
avoid
using
the
term
architectural
blueprint,
because
I
know
that
some
for
some
people
it
might
be
a
bit
scary
instead
I
sometimes
decide
to
use
the
the
term
design
document
or
architectural
design
document,
because
it's
like
feels
a
bit
more
lightweight
than
architectural
blueprint.
So
we
can.
We
can
probably
use
that
Terminator.
A
Generally
and
a
lot
of
times,
I
just
use
the
term
blueprint
right
like
just
dropping
the
architecture
prefix
I
think
is
is
is
also
better
and
that
would
be
a
a
relatively
small
change.
I,
don't
know
what
we
would
do
about
the
overall
process.
It's
called
the
architecture,
Evolution
workflow,
but
I.
Think
I.
Think
like
blueprints,
are
a
good.
A
good
word
like
I.
Don't
see
anything
that
you
couldn't.
C
Yeah
design
has
its
own
name
Collision
right,
so,
like
those
other
design
artifacts
in
the
design,
Department
ux
design
and
all
that
stuff,
you
know
Jerry
kind
of
initiated
the
blueprint
term
years
ago.
At
this
point
so
like
it
exists,
if
we
all
committed
to
kind
of
like
owning
it
and
reinforcing
it,
then
that
you
know,
then
we
have
a
shot
of
just
kind
of
making
that
understood
and
make
that
the
boring
solution.
So.
C
C
C
A
B
I
I
was
just
looking
through
those
friends
in
rfcs
quickly
and
they
seem
to
have
quite
a
good
process
going
there
and
I
like
the
collaborative
way
that
they
they're
working
I
just
noticed
that
there's
no
front-end
engineers
in
in
this
group-
and
maybe
there
should
be
because
they
can
probably
bring
some
experience,
expertise.
That's
a
good
company
now.
B
It
actually
looks
like
it
might
be
typescript
according
to
that
to
that,
but
no.
C
We're
involving
our
community
if
we're
going
to
do
that
right.
That's
a
good
decision.
B
I
does
anyone
know
who
sort
of
LED
that
that
that
RFC
process,
because
they're,
probably
the
right
person
to
I'll,
ask
I'll,
ask
around
see
if
we
can
invite
someone.
C
Tim
is
always
a
good
entry
point
into
anything
front
end,
although
he's
on
vacation
for
a
couple
weeks,
so
maybe
Martin
I
think
is
one
of
his
kind
of
close
managers.
A
Yeah,
okay,
I
want
to
say
I'll.
Ask
him
like
I.
Think
Chad
told
me
how
all
that
got
started,
but
I
forgot.
So
he
might,
he
might
know
as
well.
Okay,
I
have
trouble.
B
Okay,
I'll
I'll
ask
around
thanks.
D
Yeah
I
have
the
next
point
in
the
agenda:
I
wanted
to
touch
it
before
we
run
out
of
time.
We
are
working
on
this
interesting
architectural
blueprint.
We
we
are
calling
that
there's
a
working
group.
We
are
collaborating
in
with
some
it's
about
building
the
next
rate,
limiting
architecture
or
the
next
application
limiting
framework,
and
it's
by
its
nature,
very
cross-functional
again
and
part
of
the
problem
statement
here
is
in
this
working
group-
is:
how
do
we
get
very
cross-functional
initiatives
eventually
implemented?
D
What
what
tools
and
processes
should
we
use
like
the
next
prioritization
process
to
get
it
done
so
I
think
it
might
be
very
interesting
mental
exercise.
How
do
we
actually
get
this
blueprint
implemented
as
it's
done?
It's
still
very
early
in
writing
and
we
will
refine
it
in
the
next
couple
of
weeks
and
once
we
have
it
merged
and
approved,
and
we
know
that
we
want
to
come
into
building
a
better
rate
limiting
framework.
How
do
we
actually
Implement
that.
D
D
Blueprints
like
that
usually
get
stuck.
We
have
the
graphql
blueprint.
We
have
never
been
able
to
make
progress
on
it.
We
have
the
object,
storage
blueprint
and
we
could
not
make
any
kind
of
tangible
progress
with
it
either.
So.
C
It
is
up
to
us
to
kind
of
like
demonstrate,
articulate
the
business
value
of
these
things
in
the
form
of
availability,
resiliency
security,
whatever
the
whatever
the
different
angles
are.
But
that's
why
I
want
to
make
sure.
Amongst
the
other
things
we
do
we're
we're
meeting
that
interface,
because
that's
for
the
rubber
we'll
hit
the
redness.
D
I
think
that,
in
case
of
the
next
prioritization
framework,
it
might
be
easy
when
you
have
a
set
of
issues
like
let's
say
that
there
are
10
or
20
issues
you
distributed
amongst
groups
and
PMs
can
actually
schedule
them
and
get
them
assigned.
How
do
we
get
something
done
where
in
situation
where
we
don't
have
this
backload,
this
roadmap
describing
issues
and
epics?
And
it's
it's
something
that
requires
a
bit
more
Focus
than
you
know?
One
person
picks
this
issue.
C
D
C
C
Generally,
the
approach
should
be
like
we.
We
have
to
sort
of
propose
that
project
right.
It's
like
we
do
have
to
turn
it
into
issues.
We
I
think
it's
been
effective
in
the
past
to
sort
of
like
phase
things
and
dedicated
as
an
example,
they
clearly
articulated
phases
right,
I.
Think
some
of
the
Challenger
articulator
requires
like
a
like
a
dedicated
team
of
people
that
are
going
to
do
something
who
really
can
just
kind
of
own
it.
C
They
live
with
the
project
the
whole
time,
then
other
aspects
in
each
phase
need
to
be
farmed
out
to
the
other
development
teams
that
need
to
be
picked
up
as
maintenance
in
the
cross-functional
prioritization
workflow
process,
and
so
you
know,
maybe
one
of
the
other
things
we
need
to
think
about
here
is
how
we
have
maybe
we're
a
little
bit
more
fluid.
You
know
like
for
for
pots
like
we're
going
to
have
a
potting
team
and
whatnot,
and
that's
not
controversial.
We
have
the
sharding
team
to
do
functional
decomposition.
C
Maybe
there's
a
way
for
us
to
use
some
of
the
hopefully
Flex
time
we
have
amongst
our
senior
ACS
to
just
kind
of
like
self-organize,
and
do
these
teams
and
it'd
be
like
we're
going
to
focus
on
this
together,
regardless
of
like
forming
a
team
and
naming
it
or
putting
the
same
manager
just
so.
We
have
that,
like
consistent
ownership
over
the
life
of
of
something.
A
Again,
I
I
think
for
the
for
the
initiatives
that
would
only
take
a
couple
of
months
like
working
groups,
aren't
a
bad
organizational
structure
to
do
that,
and
they
would
be
more
effective
if
EMS
were
like
dedicating
engineering
resources
towards
them
like
one
of
the
biggest
problems
is
that,
like
is
an
ad
hoc
group
of
people
that
that,
like
are
not
committed
to
implementing
the
exit
criteria.
The
working
group
they're
just
working
on
it,
given
the
time
that
they
have
so
yeah.
C
C
Combination
never
could
before,
like
EMS,
didn't,
have
the
bandwidth
of
dedicated
Engineers
all
that
all
that
was
prioritized
by
PM
right
so,
but
under
in
under
the
cross-functional
prioritization
process
within
maintenance,
they
will
be
able
to
do
that
and
then
we'll
be
able
to
get
that
sort
of
like
consistent
participation
that
totally
agree
has
been
has
been
missing.
It's
made
it
hard
to
drive
these
things.
Yeah.
C
And
and
skill
ability
in
in
infrastructure
for
some
for
certain
things
would
fit
their
Charter
yeah.
C
C
So
then,
so
scalability
as
part
of
platform
mayor's
initial
Insight
was
like.
We
just
can't
get
some
of
the
stuff
done.
So,
let's
put
back-end
Engineers
that
are
normally
a
development
department
in
the
infrastructure
department,
so
they're
no
longer
under
the
auspices
of
the
product
prioritization
framework,
and
then
they
could
do
whatever
you
know.
We
wanted
them
to
do
so.
C
That
was
a
strong
move
and
it
was
effective
and
we've
kept
that
cross-functional
prioritization
is
meant
to
kind
of
like
formalize
the
official
prioritization
of
this
stuff,
while
having
just
say
we're
pulling
people
out
of
the
awards,
so
you're
not
in
charge
of
them
anymore,
because
we
want
to
make
sure
that
we're,
collaborating
and
and
we're
adaptable.
C
D
So,
okay,
so
I
think
that
it
means
that
if
we
want
to
implement
the
next
rate
limiting
architecture,
we
will
probably
need
to
find
the
engineers
in
organizations
that
are
interested
in
working
on
that
and
then
trying
to
allocate
their
time
through
the
next
prioritization
framework
in
a
way
that
we
can,
they
can
maintain
Focus.
So
presumably
they
would
focus
that
on
on
this
effort,
full
time,
if
it's
possible,
if
it's
not
possible,
then
it's
not,
but
is
that
something
that
we
are
thinking
about
Eric
to
get
things
like
that
implemented?
Yeah.
C
I
think
you
know
maybe
based
on
the
the
time
frame.
You
know
whether
it's
a
working
group
or
some
other
way
for
senior
issues
like
you're
such
kind
of
like
coalesce,
and
provide
that
stability
for
the
project.
Then
you
can
go,
get
the
interest
to
people
I
think
finding
the
interested
Engineers
is
a
part
of
it
right,
but
like
relying
on
volunteerism
just
doesn't
work
you
get
that
from
your
community,
but
once
you
work
at
gitlab,
you
know
you're
scheduled
right.
So
that's
where
you
have
to
work
with.
C
We
have
to
work
through
the
new
prioritization
method,
and
you
know
if
that's
identified,
then
you
know
whoever's
up
gets
that
issue.
It's
always
better.
If
someone
is
doing
the
issue,
is
someone
who's
aware
and
passionate
about
it
right?
So
that's
where
it's
like
it's
a
nice
to
have
to
do
what
you
said,
but
we
still
have
to
solve
the
something
needs
to
officially
be
carved
out
amongst
our
development
department.
Bandwidth.
A
And
along
those
lines
here,
do
you
think
that
we
should
look
to
defining
some
sort
of
process?
That's
that's
analogous
to
the
current
engineering
allocation
process.
So
to
like,
be
the
glue
for
this,
like
multi-em
coordination,
because,
like
one
thing
that
I
want
to
make
sure
that
we
that
we
don't
fall
into
is
like
like.
A
If
an
em
has
a
relatively
small
maintenance
backlog
for
their
team
right,
they
they
don't
have
to
allocate
any
percentage
of
Engineers
towards
maintenance
right
so
like
for
the
for
the
larger
scale,
initiatives
that
require
resources
from
from
multiple
teams
or
or
aren't
discreetly,
within
associated
with
any
particular
set
of
teams,
making
sure
that
we
have
some
mechanism
to
encourage
EMS
to
allocate
their
Engineers
time
towards
those
initiatives.
Even
if
their
team
isn't
isn't
directly
impacted.
C
This
should
never
happen
again,
so
what
I
would
say
is
like,
let's
just
let's
just
use
what
we've
got
and
use
like
whatever
the
next
one
is,
whether
it's
graphql
or
or
something,
let's
use
the
working
group
for
that
get
the
people
who
can
afford
to
spend
their
time
on
it
and
provide
stability
throughout
the
project
and
those
people
create
my
create
phases
of
a
project,
create
the
issue
backlogs
and
then
get
it
into
cross-functional
prioritizations
like
that.
C
Next
release
we're
going
to
execute
phase
one
together,
it's
going
to
involve
that
group
of
people
in
the
working
group
and
then
the
teams
that
are
committed
to
it
and
and
then
we're
go
and
then,
if
all
the
teams
deliver
we're
done
with
phase
one,
if
one
of
the
team
misses
that
team
was
the
long
poem
the
tent.
A
delayed
phase,
one
right
but
I-
think
that's
how
the
project
sort
of
has
to
be
managed.
A
Makes
sense
I've
listed
the
action
items
coming
out
of
this
meeting
below
I
I
think
I
captured
everything
but
feel
free
to
follow
up
async.
If
anybody
wants
to
add
more
detail
to
those
I'll
I'll
take
point
on
most
of
them,
I
think
Andrea
was
going
to
run
down
the
front
end
RFC
process,
I'll
I'll
plan
on
taking
everything
else.