►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts.
A
A
A
The
Friday
morning,
my
time
meeting
will
be
moved
to
Thursday
and
our
360
reviews
are
due
next
Monday,
so
I'm
trying
to
get
mine
done
this
week
and
I'm
out
of
our
office
as
already
mentioned.
So
those
are
the
reminders.
I
didn't
have
much.
We
spent
a
little
bit
of
time.
Talking
about
13.2
and
I
saw
you
left
a
few
comments
on
the
spreadsheet
for
planning.
A
We
shared
that
with
the
engineers
this
morning
and
they
added
a
few
things
in
the
doc
down
down
the
list
that
they
would
like
to
add
for
consideration
to
13.2
planning,
I.
Think
all
of
those
were
valuable
things
we
should
be
doing
so.
We're
gonna,
you
no
way
at
all
and
I'll
stack
rank
just
kind
of
top
down
priorities
for
each
team
member
and
it
seemed
like
we
had
a
really
good
handle
on
on
the
general
theme
which,
to
my
point,
number
two
in
the
agenda.
A
Doc
is
just
getting
ready
to
put
in
a
hand
and
I
guess.
My
point
number
two
is
really
what
we
might
want
to
focus
on
for
13.3,
which
is
finding
a
home
for
the
static
site
editor
in
the
handbook
and
who
is
the
dri
for
the
overall
UX
of
the
handbook
we
can
get
to
that
in
a
second.
But
the
theme,
the
theme
that's
coming
together
for
13.2
is
cleaning
up
the
UX,
adding
the
last
bits
of
features
for
non
handling,
non
markdown
content
in
the
WYSIWYG
editor
and
making
sure
that
we
have.
A
We
put
our
best
foot
forward
when
people
in
within
get
lab
really
start
using
this
to
edit
in
the
handbook,
and
that
includes
a
few
extra
handbook
issues
that
I
think
would
make
the
static
site
editor
more
feel
more
at
home
and
give
it
a
give
it
a
more
prominent
place
when
it
is
ready.
So
you've
seen
the
spreadsheet.
A
We
went
over
it
on
the
video,
but
when
I
need
to
add
this
in
the
issue
for
configuring
the
handbook,
but
right
now
we're
looking
for
13.2
to
have
a
almost
like
trial
run
of
being
in
the
handbook.
So
we're
probably
going
to
pick
like
a
category
of
the
handbook.
Like
product
pages
and
put
the
link
there
in
some
fashion,
but
the
architecture
of
the
static
site
editor
means
that
any
URL
that
or
any
page
that
is
supported,
you
can
pass
into
the
static
site
editor
once
we
do
support
it.
A
Once
it's
configured
to
work
in
the
the
get
lab
comm
project
or
the
handbook
project,
any
handle
case,
you
pass
any
markdown
handler
handler
that
you
pass
into
it.
Will
work
and
it'll
just
be
a
little
bit
of
like
a
we're,
not
telling
anybody
yet,
but
that
works
let's.
Let's
start
a
little
bit
small
with
the
product
pages,
get
some
feedback
from
from
product
managers
and
anybody
editing
those
pages
and
then
apply
that
in
13.3
to
to
be
more
widespread
across.
A
That's
my
hope
anyway
and
I
think
rounding
out
the
image
upload
would
be
a
great
addition
to
that.
Although
I
did
say
in
the
morning,
call
that
if
that
one
slipped,
I
wouldn't
block
the
whole
thing,
it's
not
like
hard
dependency.
I.
Just
think
that
that
one
is
gonna
be
something
people
asked
for
almost
immediately
they're
gonna
they're
gonna
want
to
start
tweaking
images,
because
we
heard
that
already
and
I
think
this
is
a
chance.
I
did
the
styling
of
the
markdown
content.
A
The
issue
that
you
created
the
end
of
last
week,
I
think
this
is
just
a
time
to
clean
up
that
UX.
So
adopting
the
full
width
editor
and
improving
the
success
screen,
creating
that
custom
toggle
between
modes
and
making
sure
that
we're
styling
the
code
appropriately
I
think
all
of
those
things
just
make
sure
we
have
a
really
good
first
impression:
do
you
get
lab
team
members
as
they
use
it.
A
So
that's
really
my
theme
and
then
the
the
second
point
on
the
agenda
of
the
handbook
top
as
I
mentioned,
we
have
a
few
UX
handbook,
things
I
know
you're,
not
technically
the
designer
for
the
handbook
and
I
am
calm,
which
is
owned
by
the
marketing
team.
I
think
this
is
close
enough
related
to
the
features
that
were
working
on
and
the
fact
that
we
need
to
have
a
home
that
I
I
think
these.
A
And
if
we
make
it
like
the
default
styling
on
the
project
template
where
it's
like
hovering
fixed
on
the
page,
I
think
too
many
people
will
see
it
and
and
think
that
we
replaced
the
other
ways
of
editing
and
I.
Don't
think
we're
ready
for
that
either.
So
yeah
I
think
if,
if
you're
comfortable
with
it
kind
of
running
with
that
that
concept
for
the
for
showing
the
maintainer
on
the
the
handbook
pages
and
and
adding
a
few
other
bits
of
metadata
common
to
every
page,
we
could.
We
could
build
out
a
nice
little.
A
A
B
A
B
A
A
I
mean
I've
I've
talked
with
enough
people,
which
is
not
by
any
means
like
I
haven't,
talked
to
hundreds
of
people,
but
I've
talked
to
enough
people
that
didn't
know.
Those
links
were
there
to
know
that
they're
not
the
most
visible
and
accessible
links,
and
then
I've
used
it
enough
times
to
know
that
it's
very
frustrating
to
like
see
something
I
want
to
edit
and
then
I
have
to
scroll
way
down
a
really
long
handbook,
page
and
click
Edit.
If
the
Edit
bar
is
fixed
on
the
page,
either
on
the
top
bottom
left
right,
wherever.
A
So
that's!
That's!
All
I'll
update
the
issue
to
reflect
that
and
make
sure
we're
not
confusing
anybody,
but
hopefully
this
is
just
a
mattr.
It's
a
CSS
change
like
this
isn't
like
a
functional
change
and
people
will
just
say
like.
Oh
now,
it's
over
here
and
I'll
take
a
little
adjustment
but
yeah
we're
talking
mostly
about
internal
team
members,
and
we
can
communicate
that
if
we
need
to
like
a
be
test
it
or
roll
it
out
and
slowly
I.
A
B
A
B
A
Especially
cuz
they're
in
the
bottom
of
the
footer,
we
could
just
say
like
looking
for
the
Edit
links
like
right
there,
yeah
cool,
so
yeah
I.
Think
that's
really
like
the
next
couple
months.
I
mean
we're
gonna
get
feedback,
we're
gonna,
have
we're
gonna
have
more
stuff,
come
up.
I,
really
like
to
keep
momentum
on
the
the
editor
itself.
A
Once
we
clean
up
the
UX
I
think
the
shortcuts
for
the
markdown
Pro
users
would
be
a
great
thing
to
do
in
13.3
and
then
I'm,
anticipating
a
lot
of
well,
let's
not
say
roadblocks,
but
like
a
lot
of
new
information
uncovered
as
we
start
to
integrate
into
the
handbook
so
I'm,
leaving
in
my
mind
a
lot
of
space
in
13.3
for
addressing
whatever
that
is,
but
we're
not
talking
about
planning
39
3.
That's
why
we
work
one
release
at
a
time.
A
13
got
to
oh
yeah
and
there's
some
carryover
for
the
non
markdown
content,
so
we'll
try
and
knock
that
out
in
13,
yeah
I
feel
really
good
about
this
release.
I'm
excited
to
record
the
video
I
think
we're
gonna
have
a
lot
of
like
user-facing
value
that
we
can
talk
about
addressing
you
know,
UX
feedback
from
the
first
couple
releases
and
then
yeah
I
mean
uploading.
Images
would
be
amazing
and
I
know
that
there
are
a
lot
of
team
members
that
are
anxious
to
get
this
integrated
in
the
handbook.
B
Cool,
so
you
touched
briefly
like
thinking
about
13.3
that
wide-open
space
of
what
things
could
be
so
going
back
to
solution,
validation
and,
like
some
of
the
themes
that
EMI
you
know
have
I
talked
on
the
side
around
like
the
problem,
validation
and
exploration.
So
last
week,
I
did
some
exploration
on
like.
A
B
Whole
idea
of
simplifying
the
publish
and
merge
flows
and
thinking
about
how
that
I
would
work
I
this
week,
I
want
to
put
together
an
issue
so
that
we
get
research
on
board
to
start
help.
Us
recruit
people
to
test
out
some
of
these
workflows
so
that
when
we
reach
13
leg
lengths
midway
13.2,
we
have
a
good
idea
of
like
the
direction
of
where
we
might
be
taking
some
of
the
editors
experience
right.
A
B
A
A
Yeah
I
think
that's
that's
perfect.
I
mean
I,
agree
that
that's
going
to
be
probably
our
next
focus
that
and
probably
after
this
I
would
say
a
good
opportunity
to
be
how
and
if
we
handle
editing
multiple
pages
and
creating
new
pages
like
like
a
page
management,
or
you
know
like
multiple
page
edits
and
things
like
that
and
I
think
that
would
be
a
natural
progression
and
I
would
guess
at
this
point
that
let's
see
this
is
thirteen
two
or
thirteen.
A
Thirteen,
four
or
five
and
potentially
six
will
be
a
solving
like
those
bigger
things
and
that's
when
we'll
we'll
be
getting
more
mature
as
a
feature
and
we'll
be
able
to
potentially
offer
things
like
create
a
new
page
from
a
template,
and
you
know
edit,
the
gamal
frontmatter
using
a
little
settings
menu
and
things
like
that.
The
yeah
lots
of
exciting
stuff
to
tackle
on
that
following
quarter,
but
getting
ahead
of
that
with
some
some
real
feedback
would
be
fantastic.
So
that
sounds
great.
It's
a
good
good
call
to
get
started
on
that
this
week.
A
B
B
A
And
I'll
try
and
do
my
best
to
round
out
some
of
the
just
like
expectations
that
I
have
in
an
issue
so
that
it's
out
there
there,
like
you
said
there,
we've
talked
about
them
and
I.
Think
it's
mostly
in
our
heads
and
I.
Think
they're
broadly
discussed
in
an
issue
like
we
need
to
you
know,
show
some
information
about
the
mr
as
it
goes
through,
but
I'll
try
and
get
a
little
more
detail
in
there
and
make
it
really
clear
the
goals
and
like
what
user
flows
are
really
trying
to
enable.
B
What
my
helper
might
distract
you,
unless,
which
way
my
goal
is
last
week,
hi
Oh
I'll,
add
the
link
to
this
issue
later
I
attached
the
field
prototypes
and
thoughts
around
the
Mr
flows,
kind
of
what
that
might
look
like.
So
if
people
haven't
had
a
chance
to
look
at
it
yet
Oh
link
that
issue
to
the
notes
today.
B
So
that
might
give
you
where
I'm
thinking
about
handling
starting
NMR
and
then
the
idea
is
that,
like
returning
to
an
MRI,
would
be
not
so
crazy
or
difficult
because
of
being
like,
would
you
like
to
join
an
existing
MRI
started,
meaning
one
and
then
you
can
always
go
and
change.
The
branch
per
anum
are
afterwards,
but
yeah
yeah.
B
B
Dmr
in
this
scenario,
the
commits
are
kind
of
secondary
and
we
can
always
use
the
mr
or
branch
field
to
reveal
the
commit
so
that
that's
almost
like
a
lot
of
information
and
we're
trying
to
balance
that
are
we
yeah
who's,
trying
to
set
an
identity
of
versus
being
more
focused
and
focus
on
the
content
rather
than
the
get
inside
of
life.
Giving
you
that
option
to
go
in
to
get.
If
you
need
to
yeah.