►
Description
Epic: https://gitlab.com/groups/gitlab-org/-/epics/11559
Agenda (internal link): https://docs.google.com/document/d/1UYCSHitBldb8x44S8H3OGXE_WN67QI-hTTNSAAkdAPw/edit?usp=sharing
A
All
right
welcome
everybody.
This
is
the
first
call
about
the
architecture,
design
worklow,
the
effort
that
we're
doing
about
the
new
diffs.
If
anybody
has
any
better
naming,
please
suggest
because
we're
really
bad
at
this,
but
let's,
let's
start
away
with
a
little
bit
of
an
introduction:
Phil
I'll,
I'll
ramble
and
I'll
speak,
but
if
you
feel
like
something's
missing,
please
cut
me
off
and
fill
in.
So
why
are
we
here?
A
So
in
the
past
couple
of
years
we've
been
trying
to
trying
to
iterate
with
not
you
write,
iterate
somebody
can
take
notes.
It
would
be
great
try
to
iterate
on
the
current
Mr
diffs
architecture
and
we've
been
we've
been
I'm
going
to
stop
and
we've
been
hitting
some
some
snags
about
how
far
along
can
build
application,
performance-,
Wise,
maintainability
Wise,
and
we
just
keep
having
different
kinds
of
diffs
in
the
application.
A
We
have
the
merge,
request,
diffs
and
we
have
the
repository
diffs
and
we
have
the
compare
view
diffs
between
branches
and
we
have
the
new
merge,
there's
a
bunch
of
like
separate
implementations
of
the
diffs
that
live
elsewhere.
The
more
we
talk
about
these
things.
It
feels
like
we're
taking
the
current
architecture
as
far
as
we
can,
with
getting
things
from
gly
caching
in
the
database,
pushing
it
to
the
front
end
in
multiple
bit
batches
the
front
and
render,
with
a
whole
tree
of
view,
components
still
with
VX.
A
B
A
Like
user
can't
search
the
whole
diffs
right,
the
reason
why
we're
here
is
we
want
to
try
to
build
an
architecture,
design
document
that
will
Envision
the
future
of
diffs
at
gitlab
and
we're
explicitly
avoiding
calling
this
the
merge
request,
because
it's
not
it's
diffs,
one
of
them
will
be
the
merge
requests.
The
other
will
be
the
repository
compare
page
and
anywhere
where
the
diff
comes
up.
We
can
have
a
tool
built
for
that.
So
that's
why
we
have
source
code
code,
review,
gly,
present
and
back
end
and
front
end
of
those
two
teams.
A
A
Awesome,
so
what
are
we
trying
to
accomplish
a
design
document
covering
the
architecture
from
start
to
finish,
which
would
be
I,
don't
know
from
G
to
browser
to
support
a
better
way
of
doing
thiss.
Let's
skip
a
generic
at
this
point,
we'll
cover
a
little
bit
more
detail
down
the
Bott.
So
that's
the
goal
of
this
effort.
We
don't
we
don't
intend
to
ship
code
for
production
as
part
of
this
effort
is
the
design
document
is
the
or
the
documentation.
A
A
A
D
A
It's
not
just
the
dris
that
will
contribute
everybody's
welcome
to
contribute.
The
dris
are
essentially
in
a
case
of
we're
having
a
discussion
that
we
need
further
input
from
the
team,
but
the
team
is
not
aware
the
dris
will
make
sure
to
look
them
in
they'll.
Try
to
make
every
calls
we're
having
or
if
not
at
least
watch
the
recording
and
bring
up
any
potential.
Other
discussions
to
the
relevant
people
say,
for
example,
just
off
the
top
of
my
head.
I
know
that
Robert
May
is
really
knowledgeable
about.
A
Caching,
if
we're
discussing
about
the
topic
of
caching
but
Robert
is
not
present.
I
count
on
eigor
to
Loop
him
in
because
he's
in
he's
in
his
team
and-
and
that
would
be
just
a
great,
a
great
way
to
keep
the
topics
directed
to
the
right
experts
in
case
the
dris
can't
make
the
call
just
make
sure
that
somebody
from
your
team
makes
it
that's
that's
kind
of
it
and
if
you
can't
make
it,
nobody
can
make
it
at
least
watch
the
recording
and
participate
as
synchronously
in
the
discussions
right.
E
A
A
G
What's
the
what's
the
scope
of
the
word
diffs
in
this
context,
because,
if
like,
if
it's,
if
it
can
be
reused
anywhere
that
to
me
means
like
oh
it's
a
component
that
can
render
a
diff,
but
we
could
also
be
talking
about
like
the
entire
diffs
app.
So
what's?
What
are
we
kind
of?
What
are
we
trying
to
scope
out
here
that
can
be
reused.
G
G
E
G
A
For
everyone,
let
me
let
me
step
in
there
you're
correct
in
part
that
the
diffs
app
has
a
lot
of
stuff
that
are
not
relevant
for
every
diff.
However,
a
collection
of
diffs
is
a
diff,
a
file
tree
to
navigate
the
collection
of
diffs,
because,
if
you
think
about
it,
if
you
give
it,
if
you,
if
you
think
of
a
diff
conceptually
in
Git
You,
might
have
more
than
one
file,
you
have
a
long
patch
with
multiple
files.
A
A
However,
the
way
you
worded
it
it's
a
very
frontend
code
review
scope,
which
is
fair
because
that's
where
you
live,
but
we
behind
this
component,
we
need
to
potentially
change
a
few
things
on
how
the
div
gets
to
the
browser
to
make
it
performant
to
make
it
fast.
So
one
of
the
one
of
the
things
we
had
talked
about
already
is
performance
not
being
degraded,
regardless
of
how
big
VMR
is.
A
That's
kind
like
a
like
overall
thing,
the
the
number
one
complaint
we
hear
from
product
and
customers
I
talked
to
Kai
yesterday
about
this
is
the
the
speed
of
the
diffs
I
can't
review
my
5,000
changes.
M
or
my
5,000
files
changed
Mr.
So
we
want
to
make
sure
that
whatever
we
build
should
be
built
with
performance
in
mind
from
the
day.
One
from
the
moment
we
get
data
from
gly.
We
need
to
account
for
performance.
A
Optimizations
are
so
the
user
doesn't
doesn't
see
the
diff
entirely
right
away
the
way
we've
been
iterating
on
the
past
couple
of
years.
Is
we
batch
it?
We
render
the
first
batch
first
push
that
to
the
browser,
render
that
and
then
continue
to
progressively
render
the
rest,
but
the
the
way
we
get
the
data
from
gly
and
the
way
we
started
in
rails
might
not
be
prepared
for
that
not
might
not
be
optimized
for
that.
A
We
can
probably
have
some
clever
ways
of
doing
it
a
little
bit
differently,
if
not
perfectly
fine,
but
we'll
in
this
part
of
the
effort
we'll
reassess
all
of
these
parts
to
see.
Is
there
any
way
that
we
can
do
it
better?
So
the
scope
is
rendering
a
diff
allowing
the
user
to
customize
the
way
it
sees
the
diff
U,
because
preferences
are
relevant,
but
it's
much
more
deeper
than
that.
It
goes
back
to
all
the
way
way
down
to
gly
and
the
way
we
get
information
from
from
that
side.
B
C
A
C
A
The
application
limits
were
designed
to
fit
the
current
way
we
deliver
diffs
to
the
browser.
I
would
say
that
we
could
think
about
it
and
potentially
we
don't
I
think
we're
probably
going
to
need
to
to
think
about
a
way
to
build
this
on
the
side
of
what
we
have.
So
we're
probably
going
to
be.
You
know
new.
A
New
apis
kind
of
thing
and
we
might
have
different
application
limits
there,
whatever
makes
sense
to
keep
the
stability
of
the
platform,
so
I
I,
would
say.
I
would
say
yes,
but
I
think
it's
up
to
us
to
to
test
those
limits.
If
they're
working
we
we
should
keep
it
and
if
they're
not
working,
we
should
revise.
A
Way,
yeah
I
agree
Patrick.
Thank
you.
I
think
it's
important
to
to
to
be
aware
that
at
this
moment,
we're
not
accounting
for
level
of
effort
that
comes
later.
Okay,
if
we
think
about
all
the
work
that
needs
to
get
done
for
this,
it's
a
lot
of
work,
but
we're
not
going
to
stop
ourselves
right
away
to
just
do
the
simp
things
we
want
something
that
gets
to
the
goal
and
then
we'll
plan
the
implementation
around
that
as
we
go
forward.
I
Spoton
and
just
a
quick
question
just
for
clarification,
I
had
an
impression
that
this
new
divs
initiative-
it's
like
we
already
have
like
mer,
Quest
divs,
commit
divs
and
it's
like
it.
Work
works
perfectly,
but
it's
not
so
performant
and
not
so
scalable,
and
we
want
to
have
it
like
to
work.
Have
it
work,
FAS
yeah,
but
after
this
discussion,
I
have
an
impression
that
it's
not
the
case
yeah.
We
just
want
to
improve
like
the
quality,
and
it
doesn't
mean
that
we
it's
only
performance
and
only
scalability.
A
Wrong,
that's
a
really
interesting
question
with
a
really
vague
answer
in
my
part,
because
it's
really
it
to
be
defined
and
I'll
give
you
an
example
what
we
like
the
current
implementation
of
diffs
satisfies
a
need
presenting
the
diff
to
the
users
right.
However,
as
we're
iterating
towards
a
new
solution,
there
might
be
opportunities
to
solve
long
running
problems
and
I'll.
Give
you
an
example
right
now.
Every
comment
is
attached
to
a
to
a
line
and
a
line.
A
It'll
exists
on
a
revision
of
an
emerge
request
or
a
branch
comparison
or
something
which
gets
trickier
because
on
the
merg
requests,
we're
constantly
comparing
to
the
moving
Target,
the
the
moving
head
of
the
target,
Branch
right,
the
patches
might
be
the
same.
We
have
some
patch
ID.
Where
can
flight
and
everything
but
we're
attaching
it
to
the
line
right.
A
We
have
a
bunch
of
ideas
and
features
that
rely
on
being
able
to
leave
comments
on
things
other
than
the
line,
for
example,
commit
message:
why
shouldn't
the
reviewer
be
able
to
comment
on
the
commit
message?
There's
other
things
like
instead
of
commenting
on
a
line.
We
should
why
not
be
able
to
comment
on
a
code
object
and,
if
you
think
about
an
if
Clause
a
for
Loop,
if
you
can
attach
the
comment
to
that
structure
of
code,
if
somebody
adds
lines
at
the
top,
the
comment
should
still
apply
to
the
structure.
A
A
It
doesn't
stop
us
from
thinking
about
what
what
what
doors
we
could
open
for
the
future.
That's
why
it's
an
architecture,
effort
where
we're
thinking
about
the
future,
but
we're
targeting,
if
anything,
if,
if
to
answer
a
little
bit
more
directly
feature
parody,
would
be
okay
like
if
we
have
a
way
to
render
diffs
that
gets
what
we
have
today.
I
think
that's
a
success.
A
If
we
can
go
beyond
that,
that's
amazing,
but
we
should
always
account
for,
for
example,
the
commment
should
be
able
to
leave
suggestions
on
the
diffs,
because
that
we
have.
We
have
that
today
now
does
that
apply
to
merge
requests
only
or
does
that
apply
to
the
repository
as
well.
That's
part
of
the
conversations
we'll
be
having
along
the
way
long.
I
Yeah
thanks
thanks
for
the
answer,
so
then
I,
maybe
I
would
suggest,
and
one
of
the
action
items
is
Gathering
all
the
existing
issues
and
ideas
that
we
have
already
in
one
place
in
case
unless
you
want
like
to
start,
have
a
fresh
start
yeah
and
get
the
new
ideas
and
then
compare
them
to
the
to
the
old
ones,
but
maybe
yeah.
Let's
maybe,
let's
have
the
old
ideas,
so
we
could
like
see
the
problems
that
we
need
need
to
solve
or
yeah
by
our
new
architecture.
Yeah.
Thank
you.
A
That's
fair,
I
added
a
note
here
to
the
immediate
task
that
we'll
talk
about
in
just
a
second,
yes,
I,
think
you're,
right,
I
think
we.
That
is
something
that
will
be.
For
example,
we
know
this
because
we've
been
working
on
this
on
the
code
review
side
of
things,
but
I
don't
expect
you
know
Patrick
from
gly
or
you
from
source
code
to
know
about
what
we've
been
talking
about
on
the
product
side
of
code
review.
For
sure.
That's
definitely
going
to
be
part
of
the
the
tasks.
B
A
A
Everybody
awesome
so
then,
in
terms
of
objectives
like
performance
not
being
degraded,
regardless
of
how
big
the
Mr
is,
I
feel
like
that's
clear
for
everybody
having
some
sort
of
progressive
ways
of
getting
data,
rendering
data.
Caching,
all
that
stuff,
that's
good,
and
this
again
this
means
different
things
for
each
one
of
us
for
the
front
end,
it
means
that
we'll
have
to
find
ways
so
that
the
front
end
architecture
is
not
compromised
when
the
Mr
starts
to
get
large
anything
any
other
objectives
that
we
should
keep
in.
I
Mind
I
I
have
a
quick
question
yeah
but
feel
free
to.
Let
me
know
that
we
should
discuss
it
later
at
some
point.
Regarding
the
Lighting
on
the
front
end.
Yeah,
sorry,
I,
haven't
checked
this
initiative
yeah,
but
I.
Remember
that
we
developed
some
part
of
it
just
wanted
to
know
at
which
stage
we
are.
Is
it
like
fully
rolled
out
or
do
we
have
any.
H
That
are
you
referring
to
the
syntax
lighting
of
the
blobs
yeah
yeah
yeah.
That
would
be
a
separate
initiative.
I
think,
like
the
syntax
highlighting
of
the
blobs
like
the
Highlight
JS,
that
we
use
there
doesn't
really
do
diffs,
that's
part
of
as
far
as
I'm
aware,
and
it's
also
separate
separate
screens
as
well
like
VI.
A
blob
is
not
it's
not
related
to
VI
a
a
specific
commit
or
or
comparing
it
to
a
different
commit.
It's
a
separate.
A
A
However,
I
think
it's
important
to
keep
in
mind
the
lessons
there,
because,
if
we're,
if
we
accept
the
imprecision
of
the
Highlight,
is
an
acceptable
cost,
we
can
try
it.
So
that's
again
at
the
moment,
we
don't
think
that
would
be
applicable,
but
if
anybody
has
any
other
thoughts
on
that
where
we
could
defer
the
highlighting
to
the
front
end
or
we
can
pre-render
it
in
some
ways,
all
of
that
is
valid
and
part
of
this
Gathering
existing
issues
and
potential
proposals.
A
I
know
that
Carrie
you
had
previously
proposed
something
like
do
more
of
pre-calculation
of
the
data
that
we
need
to
render
the
diffs
I
think
we're
going
to
need
to
revisit
that
at
some
point.
So,
let's
make
sure
that
those
issues
are
created
and
documented
at
least
and
highlighted
here
in
this
effort
we
I
don't
know
we'll,
have
a
let's
create
an
epic
and
or
epic.
We
don't
want
to
move
them
from
the
current
epics,
let's
cre
an
issue
and
document
them
all
there.
A
I
I
Why
do
why
do
we
do
it?
Historically?
Just
because
we
want
the
div
to
be
correct,
because
sometimes
it's
context
related
yeah,
for
example,
you
have
a
stream
opened
like
10
lines
somewhere
higher
yeah
behind
the
diff,
and
we
still
want
to
highlight
it
correctly,
so
yeah
I
believe
if
we
start
discussing
performance
improvements
of
the
DS.
These
are
the
questions
that
we
probably
will
be
often
try
to
solve
and
find
like
the
new
tradeoffs,
so
yeah,
it's
something
that
we
can
discuss
later,
but.
H
G
Examples
I
was
doing
a
like
forite,
highlighting
in
the
little
ifs
like
micro,
app
that
I
wrote.
That
was
the
exact
problem
that
I
ran
into
I
never
actually
saw
incorrect
highlighting.
But
the
flaw
was
there
where,
if
we
didn't
have
the
whole
blob,
it
could
have
highlighted
incorrectly.
Because
of
what
you
said,
you
know
30
lines
up.
G
Something
happened
that
needed
that
changed
the
highlighting
if
we
have
to
fetch
the
whole
blob
anyway
in,
in
my
opinion,
frontend
highlighting
allows
us
more
flexibility,
because
we
can
wait
until
the
user
Scrolls
to
near
the
file
to
highlight
it.
But
there's
a
lot
of
there's
a
like.
You
said:
there's
a
lot
of
trade-offs
because
now
you've
got
to
deliver
the
whole
blog
to
the
front
end.
A
So
so
what
the
way
I
Envision
this
and
if
you
have
better
ideas
this
is
like
please
propose-
is
that,
as
the
discussions
evolve,
we're
probably
going
to
have
big
topics
in
specific
calls
to
be
discussed
and
also
be
discussed.
Asynchronously
as
we
go,
we'll
highlight
we'll
pick
these
topics
and
we'll
broadcast
them
all
like.
Let's
have
a
discussion
on
the
syntax,
highlighting
let's
have
a
discussion
on
caching.
A
Let's
have
a
discussion
on
those
things
we're
going
to
need
some
help
in
figuring
out
some
of
the
possibilities,
because
there's
a
bunch
of
possibilities
on
how
do
we
want
to
address
this,
but
we
need
to
come
with
a
choice
or
some
choices
for
the
architectural
design,
so
this
will
be
one
of
them.
Synx
synx
highlighting
is
going
to
have
to
be
part
of
it.
A
Okay,
thanks
eigor
thanks
Thomas
thanks
Jack
and
Carrie
moving
on
one
of
the
things
that
we
have
already
talked
and
I
talked
to
Paulina
about
this
is
we
know
that
accessibility
isn't
the
best
today
on
the
merging
Quest,
diffs
or
diffs
overall,
because
we
haven't
paid
too
much
attention
to
that
since
we're
rethinking
a
lot
of
this
as
a
quality
usability
Improvement,
it
will
be
really
good
if
you
start
incorporating
accessibility
from
the
start.
So
how
should
we
word
this
Paulina?
A
F
Yeah
yeah,
so
I
started
the
document
already
I'll,
be
like
doing
the
audit
of
diffs
now
and
analyzing.
What's
missing
right
now,
but
also
the
second
part
will
be
like
looking
at
the
guidelines
that
we
should
actually
follow
for
the
authoring
tool
and
reinking
AIT
how
we
want
to
show
or
present
the
deps
to
screen
reader
users
for
all
the
other.
A
A
With
contrasts,
color
blindness,
so
Fitz
law,
it's
about
intershell-
is
the
larger
the
target.
It
is
the
easier
it
is
to
acquire
so
make
it
comfortable
for
people
with
you
like
some
motion,
disabilities
and
stuff.
So
again,
if
anything,
this
will
be
leveraged
by
the
designers
that
we'll
be
bringing
in
at
a
later
stage,
but
as
we're
thinking
about
the
front
end
architecture
cure,
we
should
account
for
that.
A
A
G
Yeah,
so
we
can.
We
can
kind
of
fold
accessibility
into
this
as
part
of
my
Milestone
stuff,
I
review,
all
my
assignments.
I
was
assigned
a
metat
task
for
for
new
diffs.
So
it's
weird
that
I
reviewed
it,
because
it's
a
metat
task,
but
I
wrote
some
thoughts
down,
and
one
of
them
is
writing
down
documents
about
about
like
budgets
and
data
flow
and
when,
when
I
talk
about
budgets
in
the
implicit
in
that
is
our
promises
to
users
essentially
and
I.
G
Think
one
of
those
things
should
be
accessibility,
but
other
things
are
how
heavy
on
the
network
is
this
new
structure
of
diffs?
How
heavy
on
a
user's
browser
is
this
new
application
or
or
new
component
or
whatever,
how
much
code
is
executed?
How
how
much?
How
long
does
it
take
those
kinds
of
things
setting
those
budgets
early
and
saying
whatever
we
do
has
to
be
fully
accessible
to
fully
blind
people
or
fully
deaf
people
or
whatever
those
setting?
G
A
But
great
thanks,
Thomas
I,
particularly
like
the
budget
documents.
The
data
flow
we
were
already
like
you'll,
be
part
of
I,
think
the
documentation
anyway,
but
the
budget
document
something
that
we
can
easily
forget
and
when
we're
deciding
about
adding
a
new
thing
because
you're
right
like
we
don't
want
to
build
something
that
is
performant
on
the
day
one
and
then
on
day
365.
Oh
my
God,
it's
slow
again.
Why
yeah
definitely
something
to
keep
us
in
check
and.
A
G
D
G
We
should
probably
I
should
probably
note
somewhere.
We
should
note
that
the
word
budget
is
intentional,
because
budgets
are
reviewed
quarterly
or
yearly,
and
if
you're
not
meeting
them,
you
you
adjust
to
meet
your
budget.
So
we
should
make
sure
that
we're
we're
continually
doing
this,
not
just
as
an
initial
Target.
A
Got
it
thanks?
Okay,
so
there
was
one
thing
that
has
been
throughout
all
these
discussions
that
we
haven't
talked
yet,
which
is
maintainability.
One
of
the
problems
we
faced
with
working
with
diffs
is
that
the
application
itself
is
so
complex
that
over
time,
the
maintainability
of
the
app
just
suffers,
and
especially
with
an
interative
approach
or
building
things,
the
based
off,
boring
Solutions
and
then
eventually
we
can
just
keep
it
at
that
stage
for
a
really
long
time.
A
E
A
Let's
move
that
to
an
issue
I'll
put
here,
then
the
bottom
create
issue
to
Define,
maintainability
cool,
all
right,
any
other
goals
that
we
should
keep
in
mind.
So,
let's,
let's
recap
so
create
a
document
for
the
architecture
which
is
the
main
goal.
We
need
to
cover
all
scenarios
where
diffs
are
used
around
gitlab.
We
need
performant.
We
need
to
keep
it
performant.
A
Oh
sorry,
I
should
read
the
rest
of
the
phrase
per
performance
not
being
degraded
regardless
of
how
big
the
diffs,
the
diff,
is
see
it's
going
to
happen
a
lot
of
times.
It's
not
Mr.
It's
not
Mr.
It's
diffs
accessible
app
for
the
users,
we'll
need
to
Define
define
boundaries
and
user
first
promises,
which
is
documents
for
Budget
documents
for
data
flow
and
potentially
like
targets
for
linting
and
an
improvement
inability
than
what
we
have
today.
Anything
missing
from.
C
A
I
think
I
think
I'm
going
to
channel
my
sters
love
because
he's
sick,
so
I'm
going
to
pull
him
in
and
I'm
going
to
be.
Speaking
as
if
I
was
him
because
he've
talked
about
this
in
the
past
and
I.
Think
Thomas
as
well
is
to
not
not
pursue
vanity
metrics.
What
does
this
mean?
If
we,
if
we
think
about
the
usual
metrics
we
have,
which
is
time
to
first
bite,
I,
don't
know
LCP
and
tbts
and
all
that
stuff
a
lot
of
those
metrics
can
have
it?
Was
you
Thomas?
A
Yes,
that's
blurry,
so
there
you
go
no
you're
like
a
YouTuber.
Look
at
that.
Like
look
at
look
at
my
look
at
my
thing
so
yeah,
the
point
of
that
is,
we
should
pursue
meaningful,
metrics
I!
Think!
That's!
That's
how
we
can
word
it
and
what's
meaningful
is
Meaningful
for
our
project,
which
means
we're
probably
going
to
need
to
define
those
metrics,
and
one
of
them
falls
into
what
Thomas
was
talking
about
the
budget
documents
right?
Is
things
specifically
built
for
us,
because
I
can
give
you
an
example.
A
A
Why
do
we
want
to
move
those
metrics
and
what's
the
impact
of
that
to
the
user,
so
which
goes
a
little
bit
to
my
next
point
of
ordered
priorities,
we're
going
to
grab
all
these
goals
and
we're
going
to
put
them
in
order
and
like
what's
the
most
important
thing
first
and
then
having
if
we
have
to
make
a
choice
between
some
of
those.
So,
for
example,
if
we
need
to
sacrifice
accessibility
for
performance
should
be
right,
I
think
having
an
order
of
priorities
definitely
helps
later
on
the
project.
D3C.
A
Does
this
with
vhml
5
spec,
where
it's
it
specifies
exactly?
Who
comes
first,
like
users
comes
first
then
comes
authors,
then
comes
browser,
Implement
implementers
and
then
comes
speckers
or
whatever
or
theoretical
Purity.
So
there
has
let's
some
priority
order
there.
So
for
us,
and
a
little
bit
more
reasonable,
I
don't
want
to
sacrifice
accessibility,
but
if
you
think
about
more
of
perceived
performance
or
meaningful
metric
like
we're
talking
about
here,
meaningful
metrics
versus
maintainability
I
think
we're.
A
G
G
A
E
A
I
agree
with
you:
I
agree
with
you,
I
think
I
think
it's
just
yeah.
We
we've
lived
through
many
hard
problems
to
solve
to
know
they
come
at
a
cost,
but
yeah
cool,
so
I
wrote
meaningful
metrics
thanks
Patrick
again
we're
probably
going
to
need
to
need
to
be
defined,
create
issue.
I
guess
create
issue
for
Meaningful
metrics
and
we
can
use
some
things
that
we've
used
in
the
past,
which
is
custom
defined.
What
do
we
call
it?
A
The
camet
API
that
we
have
on
the
browser
that
we
can
M
user
markings.
You
can
have
markings
on
the
front
end
that,
like
Define
stages
of
the
render
of
the
application,
which
include
the
performance
of
the
back
end
and
the
front
end
all
at
once.
We
can
define
those
things
and
implemented
at
the
front
end
in
terms
of
that
which
doesn't
exclude
having
other
metrics
forther
back
and
exclusive,
all
the
Magics
for
gly
and
all
that
stuff.
A
A
Objectives,
so
we
have
seven
minutes
before
I
go
to
ordered
priorities,
I'll
ask
should
we
have
also
an
issue
to
discuss
the
I'll
I'll
list,
all
the
goals
of
the
things
that
we
have
defined
above?
Should
we
have
an
issue
to
discuss
this
asynchronously
with
all
with
everyone,
because
I
don't
think
we're
going
to
be
making
a
consensus
here
on
the
call.
We
can
take
a
step
of
an
example
of
what
that
would
look
like,
but
then
everybody
could
go
in
that
issue
and
then
participate
in
in
defining
that
together.
A
A
G
There
yeah
that's
part
of
it
for
sure
there
also
I,
think
it's
also
just
like
Define.
It's
like
defining
deliverables
right
like
like
a
like
something,
is
not
complete.
If
we,
if
it's
not
accessible,
it's
not
complete
if
it's
if
it
takes
a
full
second
to
get
the
code
for
it
across
the
network
or
whatever.
So
it's
like
what
are
acceptable,
deliverable
sort
of
boundary,
yeah,
I'm,
not
sure.
A
Yeah
I
think
that's.
If
we,
if
we
frame
it
I,
think
that's
part
of
the
meaningful
metrics
we
Define
the
meaningful
metrics
and
in
there
would
be
compliance
with
the
budget
in.
There
would
be
time
to
get
the
data
from
G
or
time
to
get
the
data
from
the
rail
side
or
or
anything
like
that.
So
I
think
we
can
keep
it
for
now
covered
with
the
meaningful
matric.
A
G
C
A
G
This
wasn't
I,
didn't
I,
didn't
vocalize
it,
because
we
we
this
is
but
like.
We
can't
work
exclusively
in
issues
right,
because
an
issue
is
like
something
that
eventually
is
closed
or
resolved.
Where,
where
we
going
to
keep
things,
should
we
should
we
create
a
Wiki?
Should
we
use
our
Wiki
feature?
What
like,
what?
How
are
we
going
to
do
this
or
just
Google.
A
Docs
I,
don't
I've,
never
been
involved
in
architecture
design
workflow.
If
anybody
has
please
maybe
Patrick
or
Carrie
you
were
I
was
thinking
about
just
using
the
do
we're
going
to
start
to
put
things
in
the
documentation
itself
of
the
architecture,
design,
there's
already
a
status
for
like
proposed,
accepted
that
sort
of
thing.
So
we
should
not
reinvent
the
wheel
and
just
use
the
documentation
as
a
living
spec
as
we
go.
We
take
it
through
the
the
stages.
I
think
that's
what
makes
more
sense
anybody
disagrees.
Does
that
make.
F
A
That's
okay,
like
a
artifact
of
Investigations
sure,
maybe
that
can
cover
what
Thomas
was
saying.
But
in
terms
of
like,
we
should
keep
in
mind
that
the
effort
should
be
the
updated
documentation
that
we're
putting
out
and
if
like,
for
example,
if
it
makes
sense
to
in
reference
the
arit
that
you
did,
you
can
keep
it
in
a
Google
doc,
but
link
it
on
the
living
spec
living
on
the.
G
Yeah
I
think
we
should
have
a
Google
Drive,
maybe
for
like
drafts
or
like
hey,
I'm,
doing
this
audit
and
here's
a
bunch
of
stuff.
But
if
we're
going
to
be
linking
like
data
or
like
report
results,
we
should
probably
be
using
gitlab.
So
like
that's.
Why
I
suggested
Wiki
like
that?
That
can
maybe
we
can
store
larger
artifacts
over
in
the
wiki
and
then
link
it
from
the
documentation,
I'm,
not
sure,
but.
E
A
F
A
On
slack
and
whatever
people
are
agreeing
I
I
I
have
a
problem
with
all
right.
So
let's
not
take
any
actions.
Let's
discuss,
let's
discuss
the
S
Thomas.
You
start
this,
the
discussion
on
slack
or
on
a
g
lab
issue.
Sorry,
because
we
need
to
talk
for
okay,
so
looking
at
the
immediate
tasks
at
hand.
Sorry,
looking
at
the
ordered
priorities
which
we
need
to
move
to
an
issue.
A
A
Coverage
for
all
diff
scenarios,
that's
a
tricky
one,
but
I
I'm.
Just
giving
an
example
like
you,
don't
have
to
agree
with
that.
I
I
would
say
so.
We
can
keep
it
C
because
he
needs
to
be
accessible,
but
he
some
things
might
not
cover
all
scenarios.
Maintainability.
What's
missing,
two
three:
four:
that's
it
1
2
3,
four
yeah.
D
A
A
Okay,
cool-
and
that
takes
me
we're
over
time,
so
I
need
people
to
claim
these
immediate
tasks
at
hand.
We
need
some
people
to
start
opening
the
mrss
for
the
documentation
just
to
get
it
started
as
a
draft
or
whatever
the
status
is
and
I
need
someone
to
claim
that
task.
I
need
someone
to
create
the
issue
to
gather
all
the
existing
issues
and
that's
the
point
is
we
create
the
issue,
but
then
you
broadcast
it
to
everybody
to
add
comment
to
that
issue.
A
Something
or
add
to
the
description,
an
ask:
what
happened
something
changed?
Oh
yeah
had
a
comment.
The
document
current
approach
for
multiple
disc,
we're,
probably
going
to
need
multiple
C,
my
Google
Talk
crashed.
So
the
document
current
approach
for
multiple
diffs
implementations
is
that,
like
we
don't
have
a
lot
of
visibility
on
how
things
happen
between
gly,
like
we
on
the
front
end
between
gly
and
rails,
we
don't
have
a
lot
of
visibility
on
how
things
on
source
code
happen
on
back
end
and
stuff.
A
So
it
would
be
nice
to
get
some
sort
of
like
quick
snapshot
of
how
the
diffs
are
being
generated
and
handled.
Today,
I
would
would
keep
it
lightish,
because
this
is
just
to
understand
where
we
are:
it's
not
the
outcome.
It's
just
a
a
good
effort
of
capturing
what
we
have
today
and
for
this,
what
I
would
Leverage
is
potentially
grab
all
the
dris
and
assign
and
issue
to
them.
C
A
Something
okay,
sometimes
I'm
afraid
that
I'm
making
no
sense
at
all
it
just
too
respectful
to
call
me
out:
let's
assume
it's
not
that
right,
I'll
take
that
one
document
take
that
is
for
me
and
then
we
need
one
or
we
already
have
one
for
the
Define
maintainability.
This
is,
then
we
need
one
to
create
issue
for
Meaningful
metrics,
then
one
to
an
issue
to
discuss
order
of
priorities.
I
can
take
that
one
too.
A
A
D
G
A
You
are
now
all
right
thanks
everybody
there's
going
to
be
a
lot
of
Discovery
and
a
lot
of
crazy
chaos
through
here,
but
I.
Think
it's
great
that
we're
having
this
conversation
to
that
we
see
so
many
different
Scopes
represented
so
really
appreciative
of
your
time
and
if
you,
by
any
chance
need
some
help.