►
From YouTube: [2022-08-02] 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
C
B
A
A
F
E
Readiness
review:
okay,
that's
infrastructures.
Okay,
so
is
it?
Is
it
fair
to
say
looking
so
thanks
for
doing
this
right?
This
is
this
is
awesome.
Is
it
fair
to
say
like
as
a
heat
map,
aside
from
the
white
squares,
which
looks
like
they're
intentionally
not
filled
in
because
they
wouldn't
apply
that
we
would
hope
that
this
whole
thing
would
be
green
and
that
and
that,
if
so,
making
it
this
process
we're
doing
in
this
working
group
should
help
achieve
totally
green
heat
map
in
the
future.
F
E
F
E
F
F
But
I
think
he
was
on
board
with
the
idea
of
tying
all
this
stuff
to
a
singular
document
right.
So
even
if
it
can't,
even
if
the
investment
case
stuff
can't
be
included
in
the
blueprint
initially,
we
would.
We
would
follow
a
similar
process
and
link
it
to
the
blueprint
and
then
maybe
once
that
feature
has
shipped
we,
we
can
go
back
and
make
the
investment
case
stuff
public
and
merged
into
the
same
blueprint
as
well.
E
Yeah,
I
think
I
agree
with
that.
I
think
like
business
value
is
business
value,
so
we
don't
need
two
separate
artifacts
to
describe
that
sort
of
stuff
and
and
product
needs
their
own
kind
of
understanding
of
it,
so
whether
they
derive
insights
from
their
market
analysis
or
customer
conversations
or
whether
we
derive
it
from
our
technical
instincts,
you
should
work
towards
the
same
type
of
form.
So
everybody
understands
it
like
a
like
an
interface
yeah.
F
Exactly
that
was
the
part
that
resonated
with
him
in
particular.
Was
that,
like
you
know,
engineering's
producing
data,
that's
valuable
for
products,
interpretation
of
of
the
feature
or
or
change
right
and
likewise
products
doing
the
same
thing,
but
because
we're
not
documenting
them
in
the
same
place
or
in
the
same
format
or
or
converging
around
the
same
general
structures
it
that
information
sometimes
gets
gets
lost
or
sort
of
telephoned
and.
E
F
E
The
the
other
thing
we
should
be
aware
of
is
like,
as
as
we're
working
through
like
the
and
just
for
clarifications
like
the
next
prioritization
working
group.
That's
a
purposely
generic
name,
because
one
of
the
outputs
was
pick
the
name
for
the
process,
so
the
process
was
named.
That's
going
to
be
cross-functional
prioritization,
but
next
prioritization
is
just
the
name
of
a
temporary
working
group.
E
How
can
we
help
to
make
sure
a
pm
is
kind
of
local
to
their
area
and
is
just
focused
on
like
user
adoption
or
driving
revenue
or
certain
types
of
features
that
are
really
important
to
the
mission
of
that
group?
How
can
they
understand
the
relative
importance
of
like?
Well,
we
need
you
to
spend
20
of
your
bandwidth
for
two
milestones:
removing
sub
transaction
queries
like
it's,
it's
not
a
sexy
sort
of
thing,
but
they
do
have
to
happen
for
reasons
that
I
think
we
all
we
all
take
for
granted.
E
F
Yeah-
and
I
think
like
like
having
having
a
mechanism
where
there's
some
overlap
between
those
two
things
might
also
be
valuable,
because
I
think
there's
many
cases
where,
like
an
effort,
starts
off
being
purely
functional
right.
But
when
you,
when
you
float
that
proposal
out
or
or
as
you
work
through
the
implementation,
you
realize
that
it
can
be
connected
to
these
other
pieces,
and
that,
like
that,
may
not
happen.
F
E
Yeah-
and
I
think,
like
we've,
we've
done
this
in
the
past
under
duress
for
emergency
items,
like
the
examples
I
have
are
like,
like
systems
on
fire.
Remove
sub
transactions,
like
that's
very
hard
to
argue
with
what
we're
hoping
to
be
able
to
do
with
this
process
is
like
the
types
of
things
that
jay
gorsh
and
yourself
have
proposed,
that
are
a
little
bit
more
kind
of
strategic
and
forward-looking,
and
about
maintaining
the
code
base
and
stuff
like
that.
E
Much
harder
to
make
the
argument
when
thing
when
there
isn't
a
fire
to
put
out
for
those
types
of
things
so
need
to
make
sure
it
works
for
those
kind
of
like
long-term
architectural,
almost
like
preventative
measures,
as
opposed
to
reactive
measures
to
problems
and
then
one
quick
question
on
this
list.
I
put
together
there's
blueprint
production
readiness,
review,
abstech
review
and
then
there's
one
called
done.
What
is,
does
it
mean
the
project
whether
it
was
done
or
not?
So
I
can
remove
that
one
here.
F
E
F
G
Yep,
thank
you
for
asking
so
normally
rfc
is
something
that
frontend
uses
instead
of
blueprints,
because
I
cannot
remember,
on
top
of
my
mind,
any
blueprint
that
provided
from
the
frontend
team
and
it's
a
bit
different
from
the
blueprint,
because
rfc
is
a
request
for
comments.
While
blueprint
is
a
formalized
decision
and
plan
of
implementation,
rfc
is
just
an
idea,
and
but
it
comes
with
a
few
important
things.
It
started
in
2019.
G
I
started
by
me
by
the
way
I
just
joined
and
I
was
not
sure
what
we're
using
for
state
management
and
it
came
with
the
three
main
points
for
rfc,
which
would
be
pros
cons
and
proof
of
concept.
So
there
should
be
a
project
that
implements
it
for
front
end.
It's
easier
to
write
down
the
implementation,
so
we
made
it
a
requirement.
G
Rfc
normally
involves
the
discussion.
That's
why
it's
request
for
commands.
So
you
write
down
your
rfc,
the
proof
of
concept.
You
request
your
fellow
colleagues
to
leave
some
comments
on
the
implementation
and
if
we
achieve
the
consensus
it
happens,
sometimes
we
just
label
it
as
we'll
implement
and
proceed
if
we
don't
achieve
the
consensus.
Sometimes
we
just
ask
ems
to
join
because
normally
the
discussion
goes
between
individual
contributors
without
involving
engineering
managers
at
all
now
the
outcomes
normally
ems
are
not
involved
in
the
implementation
phase
as
well.
G
The
dri
is
the
individual
contributor
that
opens
the
rfc.
This
brings
us
the
skin
and
the
game
concept.
So
people
won't
open
the
rfcs.
They
don't
plan
to
implement,
which
happened
sometimes
in
the
past.
So
we
added
this
and
then
this
individual
contributor
can
involve
engineering
managers,
but
cannot
it
depends
on
the
scale
of
the
rfc
if
it's
relatively
small,
so
we
had
an
rfc,
for
you
know,
adding
state
machines
to
the
front
end.
G
The
ic
just
implemented
the
first
and
the
only
finite
state
machine
himself.
If
it's
a
big
scale
rfc.
So
there
is
an
rxe
for
typescript,
for
example.
So
if
we
come
to
the
conclusion
of
adding
the
typescript,
this
would
involve
not
only
em,
but
I
think
it
will
be
some
kind
of
development,
white,
ocr.
F
G
I
think
I
don't
remember
if
we
added
apollo
migration
to
rfcs,
it
wasn't
discussing
the
rfc
itself,
but
it
involved
it
was
promoted
to
development
wide
ocr
and
I
was
organizing
it
being
in
all
the
teams.
Basically,
all
the
teams
were
involved
on
the
check-in
phase,
especially
because
we
needed
to
ensure
that
we
didn't
break
anything,
and
we
can't
fully
rely
on
our
end-to-end
tests.
For
this.
D
G
I
think
that
should
be
at
least
medium
size
feature
and
the
medium
size
I
mean
it
should
involve
new
tool,
new
concept,
new
architecture
to
some
extent.
So
if
you
just
want
to
implement
some
component,
that's
not
the
point,
but
if
you,
for
example,
want
to
change
our
gitlab
ui
and
just
remove
bootstrap
view
from
it
and
just
rewrite
it
to
our
standalone
implementation.
That
would
definitely
require
an
rfc
something
that
involves
definitely
more
than
one
team.
F
G
I
think
if
we
involve
discussion
phase
doing
it
on
issues
is
fine,
because
we
have
notifications.
We
have
threats
and
it's
easy
to
track
the
points,
especially
if
we
create
a
threads
with
a
title,
and
you
can
just
follow
the
same
thing
we're
missing
here.
I
think
it
was
discussed
on
the
previous
meeting
that
that
when
I
wasn't
involved
and
it
was
brought
by
andrew,
we
need
some
kind
of
a
final
comment
on
every
rfc,
maybe
just
in
the
description
that
shows
the
example
of
implementation.
G
A
I
think
my
preference
would
probably
be
I
I
think
you've
got
a
really
good
process
to
start
with,
but
I
think
like
more
widely,
I
think,
having
something
that
ends
in
a
merge
request.
You
know
that's
what
we
use
the
production,
readiness
and
that's
what
we
do
on
dedicated
and
there's
a
whole
bunch
of
them.
A
The
the
thing
that's
great
about
it
is
that,
at
the
end
of
the
day,
you've
got
a
really
clear
kind
of
documents
without
the
the
threads
and-
and
you
know,
if
you're
time
pressed
it's
much
easier
to
kind
of
scan
through
that,
and
you
can
see
the
changes
and
you
can
kind
of
understand
how
it
evolved
over
time.
That's
just
my
preference,
but
you
know
not
disputing
that.
The
process
that
you've
got
for
rfcs
that
works
for
you
in
in
the
front
end
teams
really
well.
F
And
I
think,
like
lucas,
had
a
good
question
last
week
that
we
didn't
get
to,
but
he
he
was
talking
about
like
best
practices
for
sort
of
like
socializing
blueprints
and
making
sure
there's
enough
eyes
on
him
to
where,
like
good
discussion
happens
and
good
decisions
are
are
made.
I
I
assume
that
that's
you'd
have
a
similar
problem
with
the
rfcs.
Are
there
any
like
tricks
to
that?
Do
you
have
like
a
slackbot
automation
that
posts
them
somewhere
or
anything.
G
No,
there
is
no
slack
bot
automation,
but
it's
a
great
idea
to
add
by
the
way,
thank
you
normally,
we
localize
them
in
the
protein
channel
on
the
front
and
calls
because
we
have
shared
fronted
calls
every
single
week.
So
if
you
create
an
rfc,
it's
pretty
normal
to
bring
into
the
proton
call
and
advertise
it
there
and
big
part
of
the
frontend
team
is
also
subscribed
to
the
issues
on
the
rfc's
repository.
C
To
point
out
that
there's
the
front
end
engineers
seem
to
have
a
much
greater
cohesion
like
they
have
that
weekly
call
and
you
know
they
subscribe
and
the
back
end
engineers
do
not
seem
to
have
that.
I
think
there's
like
a
back
end
engineering
meeting
on
the
calendar
I
showed
up
once
I
don't
think
anybody
ever
shows
up
for
it.
Maybe
they
do
now,
but
you
know
that's
that's
the
data
point
on
the
ease
of
which
to
get
everybody
pulling
and
rowing
in
the
same
direction.
G
G
Sometimes
we
just
bring
notification
about
migrations
and
everything-
or
sometimes
we
just
ask
for
help
too,
because
there
are
some
shared
frontend
tasks
that
we
want
to
do
as
a
team
like
migrations,
for
example,
just
migration,
or
something
like
that,
and
there
is
also
a
social
aspect
of
these
calls.
We
have
themed
meetings.
B
G
So
normally
this
decision
goes
to
the
gri,
so
would
be
authored
of
the
rfc.
I
don't
remember
that
it
had
any
kind
of
critical
rfcs.
I
think
it's
against
the
nature
of
the
rfc.
If
we
have
something
that
needs
to
be
implemented,
we
don't
discuss
it.
We
implement
rfc,
says
more
of
the
ideas.
For
example,
typescript
right
we
can
operate
on
javascript.
Just
fine
typescript
is
not
in
the
priority
list
and
rfcs
rarely
have
this
priority
list
in
general.
It
just
I
want
to
improve
something,
so
I
bring
it
there.
B
Yeah,
I
just
wonder
because
when
you
contribute
and
rfc
you
you,
you
know,
submit
this
request
for
comments.
It
means
that
the
thing
you
want
to
discuss
might
be
important
and
at
the
end
of
the
day
you
may
have
like
many
items
right
and
and
then
perhaps
you
have
not
seen
the
situation
yet
in
the
end
team.
But
I
think
on
the
back
inside
or
architectural
side,
it's
quite
common
that
there
are
many
important
items
and
it's
difficult
choice
which
one
we
should
start
with
and
given
the
constraints
and
the
capacity
limits.
G
E
G
I
think
of
important
ones,
not
just
preferences
we
had
around
80
percent
implemented
already
and
the
rest
of
them
are
of
the
preference,
so
frontend
is
doing
pretty
good,
but
again
important,
sometimes
is
very
subjective
term
back
to
typescript
some
people
consider
like.
I
cannot
live
without
this
there's
some
people
like,
I,
don't
see
the
benefits
of
it.
B
And
that's
interesting
because
I
think
that
making
it
less
subjective
and
more
objective
is
also
very
important,
and
this
is
what
we've
been
struggling
with
in
on
the
architectural
side,
how
to
make,
for
example,
ci
partitioning
more
objective.
How
do
we
quantify
the
outcomes,
the
benefits
of
that
or,
like
you
know
how
to
be
more
objective
than
subjective
in
this
case.
G
D
G
Normally,
we
don't
involve
back,
and
this
is
like
purely
front-end
implementations.
Even
for
craftql,
we
only
front
discussed
craft
kill
part
and
it
doesn't
involve
backhand.
I
would
be
happy
honestly
to
involve
backhand
or
like
having
similar
kind
of
process.
I've
been
asking
a
few
bacon
engineers.
Do
they
have
an
rfc
process
that
we
could
maybe
propose
something,
but
it
seems
there
is
nothing
like
this
in
place,
but
I
believe
frontend
team
would
be
happy
to
share
the
same
repository
with
backhand.
If
we
need
to
discuss
something
that
involves
both.
F
Whether
it's
a
real
barrier
or
an
artificial
barrier,
I
think
there's
still
some
buried
entry
with
the
blueprint
process,
because
it's
it's
really
easy
for
anybody
to
go
and
create
a
front-end
rfc
issue
right.
But
our
our
document
documentation
tells
you
that
you
need
a
architecture,
evolution,
coach
and
you
need
to
formulate
things
in
a
google
doc.
And
then,
when
it's
a
in
a
certain
state,
then
we
convert
it
to
a
merge
request.
F
So
I
think
that
those
are
the
sort
of
optimizations
that
we
need
to
make
to
have
a
unified
process.
We
just
like,
I
think,
I
think
in
general,
we
the
we
need
to
have
a
more
iterative
philosophy
when
it
comes
to
blueprints
and
just
get
something
out
in
a
markdown
file,
asap
and
and
potentially
even
like,
merge
it
in
a
incomplete
state
just
so
that
it
continuously
represents
like
the
the
decisions
that
have
been
made.
Yeah.
E
I
agree
yeah,
you
know,
there's
like
a
prude
blueprints
and
blueprints
for
consideration
or
something
like
that.
I
think
we
could
just
mark
them
as
such
skip
the
google
doc
phase,
and
it
sounds
like
from
your
description
to
tell
you
that
we
don't
want
to
break
anything.
That's
broken,
it's
good!
That
80
percent
of
these
are
getting
done,
but
there's
a
lot
of
overlap
here.
So
I
think
we
should
it's
it's
a
virtue.
I
think
consolidate
this
case
versus
the
downside,
but
go
ahead.
Jagers.
B
Yeah,
the
reason
why
we
introduced
a
google
doc
face
is
that
we
were
a
bit
afraid
that
we
won't
be
safe
according
to
say
framework
with
you
know,
making
our
blueprints
like
avoiding
forward-looking
statements
or
exposing
things
about
the
bottlenecks
in
the
in
the
application
that
could
be.
You
know
not
safe
information
to
share.
E
Okay,
and
so
maybe
from
a
security
perspective
as
well
right,
so
there's
four
looking
projects
and
mnpi,
but
then
there's
also
like
are
we
are
we
teaching
determined,
knowledgeable
attackers
how
to
you
know
choke
off
our
system
so
yeah?
If
that's
the
case,
then
I
think
we
would
tolerate
the
inefficiency
of
google
doc
and
the
mr,
rather
than
the
simplicity
of
just
mrs
but
public,
so.
G
I
agree
with
the
overlapping
and
I
think
that
we
can
combine
both
approach
because
rfc
lack
a
lot
on
implementation
phase,
as
we
already
mentioned.
So
maybe
we
can
consider
rfc
being
at
step
0
in
terms
of
creating
a
blue
plane.
So
we
have
an
rfc.
We
discussed
everything
like
jabber
setback,
backend
and
then
we
still
implement
the
blueprint
when
everything
is
discussed.
G
F
So
there's
still
some
terminology
in
this
repo
that
I
linked
that
that's
no
longer
applicable,
but
I
have
started
to
define
a
template
that
I
think
captures
all
the
data
that
is
necessary
for
a
pr
and
appsec
review
to
be
performed.
I
I
it's
been.
It's
been
a
couple
weeks
since
I've
done
anything
with
this,
so
I'm
going
to
take
another
look
this
week,
but
any
any
feedback
on
that
would
be
much
appreciated.