►
Description
Weekly sync call of the Static Site Editor group focused on engineering efforts.
A
A
The
first
one
is
just
about
the
culture
m360
feedback
process
that
we're
currently
undergoing.
I
would
encourage
you
all
to
prioritize
this
and
do
one
or
two
a
day.
I
don't
know
how
many
you
have.
I've
got
13
to
do
so.
I've
got
quite
a
few
that
I
need
to
need
to
get
through,
but
they
take
a
they
take
a
long
time
to
do
if
you're
doing
them
properly,
and
you
want
to
do
them
properly
because
you
want
to
give
you
know
proper
feedback.
We've
got
two
weeks
to
do
them.
A
A
A
I
highly
encourage
you
all
to
watch
the
training
video
that
culture
provides.
They've
got
a
model
called
the
sbi
model,
which
basically
goes
you
know
like
describe
the
situation.
You
know
the
context,
give
the
behavior
that
you're
referencing
and
then
what
the
impact
was.
So,
for
instance,
I
can,
and
I'm
enrique
I'm
going
to
use
you
as
an
example
because
we
all
know
you're
a
bad
apple.
A
So
so
I
can
say
that,
while
working
on
the
graphql
implementation
of
the
static
site,
editor
enrique
was
not
inclusive
in
his
behavior,
and
that
made
the
impact
of
that
was
that
the
team
rest
of
the
team
felt
excluded
from
from
the
decision
making
and
what
was
going
on.
So
that
is
an
example
of
giving
the
situation.
What
was
the
person's
behavior
and
what
was
the
impact?
A
A
So
keep
that
model
in
mind
and
most
important
do
not
forget
to
do
yourself
review.
It's
really
important
to
have
to
have
this
as
well,
so
that
you
can
do
a
benchmark
in
terms
of
how
you
see
yourself
and
how
others
see
you.
If
there's,
if
there's
a
blind
spot
to
to
be
found,
you
will
only
really
bring
it
out.
If
you
do
yourself
review
honestly
as
well,
so
I
encourage
you
all
to
to
do
a
self
review
even.
A
Gate
only
had
been
a
gitlab
for
two
months
or
whatever
it's
still
worth
doing
that
and
getting
some
baseline
establishment
right.
That
said,
that's
all
for
360
feedback
we
also
have
tomorrow
we
have
our
team
day
for
the
jam
stack
virtual
conference.
A
A
If
you
prefer
in
terms
of
how
tomorrow
will
work
I'll
host
a
zoom
call
and
share
my
screen,
which
will
be
a
live
stream
of
the
event,
so
we'll
have
kind
of
like
streaming
inception
going
on,
the
team
members
will
join
my
zoom
call
and
we
can
chat
with
each
other
via
zoom
chat
or
verbally,
between
the
sessions
on
the
call,
and
we
can
take
notes
and
I'll
share
session
notes.
Doc,
then
do
you
have
to
join
the
team?
Zoom
call?
A
No,
you
can
watch
it
on
your
own
if
you
prefer
to
do
that.
Do
you
have
to
be
on
the
zoom
call
the
whole
time?
No,
you
can
jump
off
and
on,
as
you
want,
I'm
personally
going
to
jump
off
at
some
time
during
the
the
evening.
My
time
as
I
will
need
to
help
just
feed
the
kids
and
put
them
to
bed
but
I'll
leave
the
session
running
anyways
and
you
know
you
don't
even
have
to
join
the
call.
A
B
A
You
know
that's
very
relevant
to
to
what
we're
working
all
right.
That's
all
for
the
fyis,
I'm
going
to
move
on
to
the
engineering
section
so,
as
we
discussed
in
our
retro,
we'll
keep
communicating
key
dates
for
milestones
and
so
for
13.1.
A
Our
internal
conflict
cut
off
date
to
make
the
milestone
is
around
the
17th
of
june.
Now
the
17th
is
a
fictional
date.
There
is
no
real
release
cut
off
date
and,
as
you
will
see,
with
the
link
to
the
handbook
that
I've
linked
at
the
bottom
it
could
the
cut
could
be
as
early
as
the
15th
or
as
late
as
the
20th
13.0
was
kind
of
in
the
20th.
It
all
depends
on
the
stability
of
gitlab.com,
and
so
that
will
determine
what
the
actual
date
is.
A
I
think
working
on
the
17th
has
a
rough
kind
of
like
marker
in
the
sound
for
us
is
still
good
because
it
gives
us
something
to
aim
at
and
and
so
on,
and
and
therefore
I
would
suggest
that
if
something
is
is
earmarked
for
for
the
release
and
it's
critical,
which
none
of
our
issues
are
by
the
way
for
13.1,
we
should
aim
to
have
it
maintain
a
review
by
the
15th
of
june.
A
So
with
that
said,
we'll
move
on
to
the
next
item,
which
is
the
ready
for
development
status.
Check
that
I
want
to
do
so.
Last
week,
we
we
had
a
big
focus
on
doing
some
wrapping
up
some
of
these
scenes
and
issues,
but
also
starting
our
planning
for
for
the
13.1
issues
and
making
sure
that
we
get
into
the
implementation.
A
And
so
I
want
us
to
just
run
through
all
the
issues
that
we
have
in
planning
or
have
earmarked
for
13.1
and
make
sure
that
they
are
ready
for
development
and,
if
not
just
briefly,
discuss
what
we
need
to
do
to
move
the
needle
on.
Then
it's
important
that
we
get
some
momentum
building
this
week
so
that
we
get
into
our
development
stride
and
make
sure
that
most
of
what
we've
planned
to
to
release
an
incitement.
But
one
can
be
achieved.
C
Sure,
thank
you
so
the
first
one
with
respect
to
the
front
matter
again,
I
want
to
say
thanks
to
everybody's
feedback.
I
also
got
feedback
from
the
maintainers
so
right
now
the
plan
is
to
do
the
pre-parse
approach.
C
So
that's
something
I
kind
of
learned
this
morning,
basically,
and
then,
as
for
the
display
non-markdown
content,
I
have
a
spike
for
that
with
using
a
custom,
html
renderer.
So
that's
kind
of
the
next
step.
That's
why
I
haven't
confirmed
it
as
a
as
a
ready
for
development.
I
don't
know
if
you
want
to
technically
flag
that
differently
or
something
yeah
there
we
go.
That
makes
sense.
C
So
that's
that
and
then
the
next
one
I
could
get
two.
But
it
sounds
like
from
a
one-on-one
that
I
have
with
jean
this
morning
that
he
might
just
end
up
taking
that
on
just
so,
I
can
focus
on
the
non-markdown
content.
One.
A
Yeah,
just
on
that
one
derek
you
implemented
the
event
tracking
already
for
that
in,
and
so
the
data
is.
Is
there
it's
all
about
just
putting
a
dashboard
together
and.
D
Sorry
about
that,
okay,
so
the
first
one
inserting
an
image
using
a
static
site
editor
that
one's
on
track.
Currently
it's
the
first
merge
request
is
already
in
review
and
the
next
one.
The
final
one
will
probably
be
published
tomorrow:
styling
the
toast,
ui,
contextual
menus.
D
I've
reviewed
the
designs
from
michael
there
and
I
don't
foresee
any
issues
implementing
those
designs
on
our
front
end
then
the
the
tracking
that
one's
currently
on
hold,
as
far
as
I
can
tell
the
event
that
gets
published
on
the
front
end
is
already
already
contains
unique
identifiers
for
the
user.
D
A
D
D
But
there
are
some
default
parameters
as
well,
such
as
the
the
main
user
id,
which
I
believe
is
the
important
one
for
identifying,
whether
it's
a
unique
user
and
that's
the
that's,
probably
the
identifier
that
we'll
use
to
check
whether
it's
a
unique
commit
a
unique
user.
That's
currently
doing
a
commit.
A
Okay,
well,
that
makes
sense.
In
that
case,
I
think
it
makes
sense
if
I
take
this
one
over
as
well,
because
I'll
be
doing
the
dashboard
for
the
for
the
data
we
already
have,
and
I
can
just
do
this
one
thing
while
we're
doing
that.
So
let
me.
B
A
All
right
right,
enrique
over
to
you.
E
So
all
the
deliverables
are
ready
to
be
to
start
working
on
in
the
case
of
the
okay
that
are
tracking
deliverable,
I'm
gonna
build
I'm
gonna
work
on
top
of
what
direct
already
did
to
to
drag
the
number
of
commits
in
the
indicator.
So
I
think
that
that
is
gonna
speed
up
my
work
because
I
just
need
to
to
follow
that
example.
E
The
second
deliverable,
the
confirmation
step
is
quite
straightforward
and
I'm
working
on
it
already
and
in
the
case
of
the
effort
communication
in
the
statistic,
after
some
research,
my
assumption
is
that
we
have
very
little
to
do
in
there
because
we
are
going
to
be
using
public
graphql
apis
that
are
really
relying
on
some
business
logic
that
is
already
implemented
in
the
vacuum.
E
We
have
very
little
room
for
improvement
if
we
are
not
redesigning
the
entire
everest
hunting
strategy
in
public
apis.
So
yeah,
that's
my
that's
my
report.
A
Just
on
that,
one
of
the
things
I,
if
I
recall
we
were
wondering
about,
is
whether
we
should
rely
on
always
receiving
the
the
kind
of
like
error
messages
from
the
back
end
or
whether
we
should
have
error
messages
kind
of
like
defined
logic
on
the
front
end.
Is
there
any
view
on
that
related
to
that
issue?.
E
Yes,
now
the
the
strategy
that
that
the
recipe
address
api
and
the
apis
follow
is
that
they
return
an
error
message.
They
are
not
returning
error
codes,
so
we
can
display
that
that
effort
message,
but
in
my
opinion
they
may
be
too
technical
for
for
showing
that
to
a
user.
What
I,
what
I
am
expecting
to
to
do
is
that,
if,
if
there
is,
if
error
that
is
happening
is
a
client
error,
we
are
sending
about
request.
E
We
are
going
to
find
a
way
of
capturing
that
in
the
context
of
the
client,
so
we
can
display
something
that
is
more
useful
to
the
user
and
any
server-side
error.
We
also
have
to
heighten,
and
just
like,
find
a
way
of
capturing
that
and
displaying
something
that
doesn't
doesn't
expose
any
kind
of
information
that
we
don't
want
to
expose
to
the
user.
So
I
I'm
sure
that
this
is
something
that
probably
we
don't.
We
don't
have
to
work
on
like
to
improve
their
their
strategy
within
the
api.
F
F
It's
like
we
validate
if
the
file
is
a
markdown
file,
if
there
is
a
file
exist
and
something
like
that
and
for
these
errors
right
now
we
display
some
generalized
error
message,
so
we
can
so
we
can
improve
that
and
we
can
provide
like
specific
error
messages
for
each
case
about
the
api
errors
yeah.
I
agree.
We
cannot
do
much
about
that.
It
will
require
us
like
to
redo
this
service
objects
that
we
use
and
yeah.
A
I
can
confirm
it's
definitely
not
something
we
want
to
do
right
now,
so
it
feels
like
there's
not
much
to
do
here,
apart
from
just
wrapping
it
up
and
and
and
kind
of
like
making
sure
that
that
everybody
in
the
team
understands
our
approach
to
dealing
with
these
and
yeah.
It
is
what
it
is
and
we'll
we'll
kind
of
like
follow
that
approach,
and
at
a
later
stage
you
know
like
once
a
maturity
level
is
viable
and
one
might
want
to
make
things
level
we
can
revisit.
A
If
we
want
to
to
bring
some
improvements
on
on
this
to
the
product,
all
right,
vasily
you've
got
the
last
few
ones.
F
A
year,
so
I
have
a
couple
of
graphql
mutation
tasks,
so
one
of
them
was
merged
today.
Another
one
is
on
the
last
stage
of
the
montana
review,
so
I
expected
to
be
merged
this
week
and
the
last
one
is
about
showing
dri
on
the
pages
on
the
handbook
pages.
A
So,
in
summary,
all
of
our
plan
13.1
issues
apart
from
displaying
non-markdown
content,
we've
done
the
thinking,
we're
happy
with
the
approach
we
want
to
take
and
then,
even
with
that
one
derek
you've
got
a
clear
plan
of
action
of
what
you
want
to
validate
next
to
to
just
confirm
the
execution
plan
day.
So
it
feels
like
we're
in
a
good
place
to
to
get
our
heads
down
and
and
make
some
progress
on
these.
So
I'm
happy
with
that
yeah
and
basically
just
a
heads
up.
A
We
might
throw
some
work
relating
to
the
release
post
to
you
just
in
terms
of
helping
stitch
together,
the
the
post
from
a
bunch
of
yaml
files
and
so
on
here
it
will
be
working
on
getting
some
more
clarity
around
the
requirements
and
once
we
have
that
we
might
do
that.
F
A
Cool
all
right,
the
last
item
on
my
list
is
just
to
quickly
talk
about
in
our
twelve
maintain
retro.
We
discussed
how
we
had
issues
with
the
you
know,
having
multiple
assignees
on
an
issue,
and
you
know
tracking
the
different
state
of
front-end
and
back-end
through
the
workflow,
and
you
know
the
the
proposal
that
we
discussed
and
which
we
said
we
were
going
to
try
and
run
with
and
see
how
it
goes.
It
was
this
concept
of
parent
child
issues.
A
I
spent
quite
a
bit
of
time
going
through
that,
and
you
know
just
kind
of
like
seeing
how
this
fits
into
our
overall
process
and
I'd
like
you
all
to
to
just
take
some
time
and
go
through
that
and
make
sure
that
you,
I
understand
it
and
also
agree
with
it,
and
if
you
don't,
please
do
raise
any
concerns.
A
I
would
like
to
to
merge
this
tomorrow
if
there's
no
further
feedback,
but
essentially
it
introduces
this,
and
what
I'm
trying
to
show
with
this
little
diagram
here
is
that
it
introduces
this
concept
of
a
feature
issue
which
will
be
our
parent
issue
essentially
and
feature
issue
will
have
implementation
issues
or
like
derek,
and
I
are
currently
discussing
in
this
third
year.
A
Is
it
could
have
aren't
many
issues
as
well,
but
essentially
these
become
child
issues
of
the
the
parent
issue
and
will
move
this
issue
and
this
issue
separately
through
the
workflow.
So
there
might
be
multiple
implementation
issues
on
the
future.
It
might
be
assigned
to
different
disciplines
and,
and
so,
and
even
an
implementation
issue
can
have
one
or
more,
mrs
against
it.
A
You
can
iterate
your
mrs
as
you
see
fit
best,
but
what
we
will
be
reporting
on
in
terms
of
you
know
where
the
progress
of
the
work
is
is
at
the
implementation
issue
level
and
we
will
be
tracking
our
our
overall
progress
of
our
play
against
plan
for
a
milestone
will
be
at
the
feature
issue
level.
A
So
we
discussed
having
two
boards,
one
that
that
focuses
on
the
status
of
where
the
feature
issues
and
what
that
focus
on
the
implementation
issue
level
so
I'll
be
once
once
I
merge
this
I'll
work
on
getting
those
boards
in
but
yeah.
So
there's
quite
a
bit
of
updates
here.
Please
read
it
make
sure
you
understand
it.
If
anything's
unclear
ask
and-
and
then
we
will
iterate
on
that,
we
can
use
it
and
we'll
discuss
it
in
our
retros
are
how
it's
going
and
whether
it's
helping
us
or
hindering
us
right.
A
That's
all
for
the
engineering
section.
Is
there
anybody
else
that
wants
to
mention
something
before
we
move
on
to
product.
G
I
wasn't
in
the
list,
but
I've
I've
been
doing
work
as
well.
The.
G
Like
you
can
look
at
the
the
first
thing
on
the
list
and
the
work
for
the
middleman
monorepo
stuff,
is
it's
not
very
well
defined,
so
the
approach
I'm
thinking
is.
I
have
one
spike,
mr
and
then,
as
I
find
this
stuff,
I
keep
it
on
that.
Mr
anything,
that
I
can
pull
out
as
a
separate,
mr,
that
is
a
blocker
or
supporting
work
I
do
separately.
G
So
I
think
there
was
like
seven,
mrs
that
I
closed
last
week,
in
addition
to
the
main
one
that
I'm
working
through,
and
I
think
it's
it's
looking
really
good.
The
progress
is
good.
It
is,
I
think,
close
to
getting
ready
to
merge,
but
I
still
need
to
understand
more
about
what
exactly
is
and
is
not
possible
with
the
rules
and
the
new
rules
approach
for
the
get
lab.
G
Ci
there's
some
things
that
I
want
to
do
that
I
are
and
then
I'm
not
sure
is
possible
and
I
need
to
look
at
it
closer
and
maybe
ask
some
people.
A
Yeah,
just
for
the
for
the
rest
of
the
team's
benefit.
What
we've
decided
to
do
with
with
the
handbook
was
not
to
create
too
strong
a
pre-plan
of
how
we're
going
to
approach
this.
A
Essentially,
I'm
letting
chad
pick
the
bleeple
or
the
red
bull
and
go
down
the
rabbit,
hole
and
discover
what
the
best
approach
is
to
to
to
meeting
objective,
and
our
objective
is
defined
as
implementing
the
monorepo
approach
so
separating
the
the
source
code
for
of
the
handbook
from
from
other
projects
of
the
the
repo,
as
well
as
having
independent
pipelines
and
those
those
two
objectives
will
help
create
clarity
around
ownership,
as
well
as
reduce
overhead
for
us
going
forward.
H
You
thank
you.
I
don't
have
much
and
I'll
I'll
chat
more
about
this
in
the
meeting
later
on
with
product
and
design
focus
stuff,
but
I
would
love
some
feedback
on
the
outline
I
made
for
the
status
page,
slash
water,
cooler,
dog,
fooding
opportunity.
You
don't
need
to
give
the
feedback.
Now
it's
kind
of
a
long
outline.
H
My
one
main
concern
is,
as
I
was
putting
it
together.
I
felt
like
I
was
falling
too
heavily
on
it
being
more
like
a
blog
structure,
and
since
we
don't
really
have
the
capability
of
making
new
posts
or
new
pages
from
within
the
static
site
editor,
I
don't
know
that
that's
the
appropriate
way
to
dog
food
it.
H
So
if
we
can
toss
around
some
ideas,
I'll
be
thinking
more
about
how
we
can
keep
things
tied
to
a
single
page,
maybe
simplify
the
outline
a
little
bit
and
then
we'll
try
and
stand
up
a
project
this
week
and
it
can
evolve
and
eventually
it
might
have
a
blog
when
we
when
we
can
create
new
posts
from
the
static
site
or
new
pages.
H
My
main
priority
this
week
is
making
sure
that
I
catch
up
on
all
the
threads
and
the
conversations
going
on
on
the
issues
related
to
13.1,
making
sure
that
everything's
documented
clearly
in
the
issues
so
that
we
can
move
forward.
It
sounds
like
everybody's
good
to
go
for
the
most
part.
I
appreciate
all
the
feedback
and
back
and
forth
last
week.
I
think
we
had
some
really
good
discussions
in
the
issues.
H
So
all
the
thoughtful
comments
in
there
was
very
much
appreciated
and
then
I'm
going
to
give
some
13.2
planning
some
early
13.2
issue
creation
and
and
making
sure
all
those
are
tied
up
tightly.
H
B
H
Not
every
page
of
the
handbook
potentially,
but
maybe
a
section
of
the
handbook
that
we
know
is
relatively
standard
in
format
or
more
or
less
purely
markdown,
with,
like
maybe
just
a
little
bit
a
couple
partials
or
something
like
that.
If
we
can
identify
something
like
maybe
the
product
product
section,
product
subdirectory
and
use
that
as
a
an
opportunity
to
test
it
out,
13.2
might
be
a
time
a
good
time
to
do
that.
H
But
I'm
interested
in
your
thoughts,
especially
as
this
milestone,
goes
on
and
we
uncover
more
around
the
strategy
with
editing
or
rather
identifying
and
not
editing.
Non-Markdown
content
I'd
be
interested
to
see
how
this
goes.
So,
that's
just
generally
my
feeling
for
a
focus
for
13.2.
There
will
obviously
be
other
features
that
will
come
in
support
of
that
and
some
other
work
that
will
get
prioritized.
But
that's
kind
of
where
my
head
is.
A
That
sounds
like
a
good
idea
to
get
some
early
feedback
and
I
think
the
a
good
target
audience
to
get
feedback
from
is
product
managers,
because
they
will
we've
already
seen
jason,
giving
lots
of
good
feedback
to
us
from
his
experience
and
especially
if
we
can
have
a
integration
with
a
smaller
group.
A
You
know
that
would
be
quite
useful
because
I
think,
as
soon
as
we
open
it
open
it
to
the
to
the
whole
handbook
in
the
whole
company,
the
flat
gates
will
open
and
we'll
get
a
lot
of
feedback
and
so
which
isn't
bad
necessarily
in
itself.
But
just
as
we
are,
you
know
still
quite
nascent.
It
would
be
good
to
have
have
the
feedback
drop
in
initially,
and
so
I
think,
yeah.
H
Cool
so
yeah
I'll,
maybe
for
the
13.2
planning,
maybe
a
spike
or
something
like
that,
just
an
issue
to
collaborate
on
on
these
edge
cases
as
we
uncover
them
as
we're
thinking
through
13.1
work,
we
can
kind
of
throw
some
ideas
in
there
about
what
it
would
look
like
to
integrate
with
the
handbook
and
what
challenges
we
might
come
across.