►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts.
A
We
have
another
looming
milestone
to
consider,
which
is
the
the
planned
maturity
graduation
date
at
the
end
of
the
quarter,
which
aligns
with
13.3
the
end
of
39
3
and
as
we've
talked
about
means
that
for
us,
the
hint
the
handbook
is
fully
integrated
with
the
static
site
editor
people
are
using
it.
People
are
happy
with
it.
My
understanding
and
I
haven't
been
able
to
firmly
confirm.
A
That's
100%
the
graduation
from
minimal
to
viable
Row
is
dependent
on
a
passing
grade
on
our
UX
scorecard
process,
which
is
relatively
new,
but
I
think
could
be
useful,
even
if
it's
not
a
hard
requirement
for
us.
If
it
turns
out
that
it's
not
something
that
would
block
us
from
entering
them.
The
categories
all
that
we're
viable
I
think
can
be
useful
for
us
to
do
in
13
3.
A
So
I'd
like
to
start
talking
about
what
that
looks
like
and
in
planning
that
I
think
it
will
help
augment
our
existing
usability
research
and
knowledge
and
highlight
any
additional
gaps
or
rough
edges
that
we
want
to
smooth
out
before
we
ramp
up
and
I.
Think
13-3
is
really
shaping
up
to
be
a
polishing
milestone.
A
I
mentioned
this
in
the
call
earlier,
but
my
plan
is
really
just
to
continue
to
focus
on
getting
the
handbook
integration
done,
and
that
would
mean
that,
like
there
might
be
some,
if,
like
maybe
the
ability
to
insert
a
video
or
display
like
thumbnails
of
videos
from
YouTube
or
mermaid
diagrams,
or
something
like
that,
that
that
anything
that
like
really
sticks
out
when
we're
working
in
the
handbook,
as
is
something
that
would
like
inhibit
somebody
from
adopting
the
static
site.
Editor
I,
would
consider
four
thirteen
three.
A
Otherwise,
as
we'll
get
in
point
number
two
on
the
agenda,
I've
also
been
thinking
about
just
longer-term
directions
and
larger
feature
work,
but
that'll
play
into
our
discussion
about
UX
research.
As
well
so
I
believe
the
UX
scorecard
is
something
that
Michael.
You
drive
the
issue
forward
because
it's
a
UX
team
like
initiative,
but
that
might
be
an
unfounded
assumption.
I
don't
actually
know
yeah.
B
That
is
true,
I
think
recently,
with
a
UX
scorecard
and
there's
a
new
way
of
calculating
that,
and
so
it's
like
a
1:1.
It's
you
question
kind
of
survey,
but
yeah
I
can
dig
up
some
information
and
attach
it
to
this.
They
do
cool.
A
Here
I
have
a
link
from
down
here.
All
I
really
did
was
pull
out
the
handbook
link,
but
we'll
dig
more
into
that
process.
I
think
it'd
be
fun,
sounds
interesting,
I
mean
I,
hope
we
don't
fail
and
then
we
can't
go
viable,
but
at
the
end
of
the
day,
that's
just
an
indication
that
you
know
we
have
more
work
to
do
than
we
thought
and
I.
Don't
think
it's
gonna,
be
you
know
a
stain
on
anybody's,
permanent
record
or
anything
yeah.
A
So
the
only
other
topic
I
had
and
then
we'll
talk
about
UX
research.
Hopefully
this
will
like
transition
into
it,
but
I
spent
a
fair
bit
of
time
on
Thursday
and
Friday,
trying
to
sketch
out
and
diagram
what's
been
in
my
head
for
a
while
and
what
we've
talked
about
in
a
lot
of
meat
and
what
we've
talked
about
in
some
issues
and
hinted
that
with
longer
term
direction.
A
My
goal
with
this
is
to
try
and
get
it
to
a
point
where
I
can
present
it
clearly
and
concisely,
maybe
even
record
a
video
talking
through
it.
Eventually,
it
might
be
nice
once
we
pick
something
you
know,
or
maybe
a
little
more
comfortable
with.
If
this
could
be
something
where
we
pick
an
end
state
you
and
me
Michael,
and
we
like
really
flesh
it
out
and
and
have
like
a
directional
design,
exercise
and
design
sprint
or
something
like
that.
A
So
this
is
where
we
are
today.
In
the
production
page,
we
have
a
static
site,
that's
in
production
and
an
edit
link
that
sends
markdown
content
to
our
single
page
editor,
which
has
a
WYSIWYG
formatting
bar
and
can
display
images
and
has
a
toggle
between
the
WYSIWYG
and
the
raw
editor.
The
raw
source,
editor
I,
think
what
we
have
been
doing
and
what
we
will
be
doing
for
the
near
term
is
really
just
iterating
on
these
features
and
making
this
experience
better
and
I
think
that's
completely.
A
Ok,
editing,
frontmatter
or
maybe
it
image
tools,
a
cropping
or
like
optimizing
images
to
to
make
them
and
make
them
have
a
smaller
footprint
or
something
like
that.
Inline
media,
maybe
even
things
like
a
visual
mermaid
diagram,
editor
or
the
ability
to
edit
inline
references
to
other
files
includes
or
something
like
that.
There's
there's
lots
of
ways
we
can
take
this.
A
Meant
to
be
illustrative,
they're
not
meant
to
be
wireframes
by
any
means
like
we
don't
actually
need.
You
know,
status
lights
on
em,
RS
or
anything,
but
as
we
iterate
towards
experiences
that
might
be
more
familiar,
we
could
potentially
find
ourselves
implementing
a
block
editor
or
a
page
builder,
or
maybe
like
page
templates,
or
something
like
that
within
this
single
page,
editor
I
could
see
that
happening
where
you
could
drag
and
drop
and
reorder
content
or
insert
new
content
between
blocks.
I
think
that's
something
we've
all
discussed
and
it's
something
we
could
still
do.
A
Obviously
we
would
need
to
validate
this
direction.
It's
not
set
in
stone,
but
same
thing
goes
for
previewing
we've
discussed
the
potential
need
for
very
quick
previewing
using
the
production.
Css
I
should
also
preface
this
before
I
get
into
the
next
section
that
none
of
this
is
meant
to
imply
that
any
of
these
steps
would
be
easy
or
core
or
fast,
there's
a
lot
of
significant
work.
A
That
would
need
to
be
done,
and
some
of
these
might
even
be
downright
impossible
for
for
certain
tasks
or
certain
static
site
generator,
so
I'm
trying
not
to
make
too
many
assumptions,
but
rather
just
think
like
how
this
could
naturally
progress
to
different
directions,
and
so
what
I
have
over
here
or
three
somewhat
divergent
directions
we
could
take
from
there
I
think.
That's
all
the
great
things
we
can
do
to
iterate
on
a
single
page
edit
or
even
have
the
ability
to
jump
between
pages.
A
Maybe
but
I
see
three
directions:
I
like
two
of
them,
but
the
third
is
still
valid.
I'll
talk
about
the
live
page
editor
because
it's
easy
to
say
this
is
a
lot
like
Tina
CMS,
or
even
that
stack
a
bit
product
that
I
did
the
demo
of.
So
you
could
imagine
the
shorthand
by
the
way
for
being
in
the
get
lab
interface.
Is
that
I
did
like
a
little
purple
header,
so
within
the
get
lab
product
we
have
just
a
configuration
tool.
Essentially
this
could
live
within
the
project
or
it
could
be.
A
It
could
just
be
a
ya
know,
file
but
obviously
it'd
be
nice.
If
it
was
visual
from
there,
we
can
package
the
site
and
deploy
and
what
we
could
do.
You
know
I'm
imagining
a
hand
waving
thing
here
where
we
package
that
JavaScript
in
with
the
with
the
site
and
then
on
the
production
site.
We
now
have
an
edit
link
and
we
handle
off
and
when
you
click
Edit,
instead
of
sending
you
into
the
get
lab
product
it
flips
over
into
an
edit
mode.
A
We
we
would
have
the
same
experience
roughly
with
the
static
site
editor
but
embedded
on
the
live
production
site
and
again
hand-waving
and
some
some
environments.
This
might
not
be
possible.
There
won't
be
a
significant
amount
of
work
to
configure
this
to
make
it
work,
but
this
would
be
the
ideal
path
for
this.
For
this
concept
and
from
there
maybe
we
can
extend
that
to
a
really
lightweight
CMS,
like
you
could
navigate
between
pages
that
are
published
on
the
page,
create
a
new
page
from
a
template
preview,
those
changes
and
then
create
an
M
R.
A
This
would
rely
pretty
heavily
on
you
know.
An
API
and
a
sort
of
production
environment
running
live
on
a
on
a
production
server
outside
of
gate
Labs
product.
It
keeps
people
what
I
like
about
this.
Is
it
keeps
people
focused
on
the
production
site
in
the
context
of
that
that
site
that
project
without
having
to
go
into
the
gitlab
interface?
What
I
don't
like
about
it
is
that
it
doesn't
bring
people
into
the
gait
lab
interface,
so
we
can't
reuse
as
many
things
and
we
just
don't
control
the
experience
in
general.
A
The
second
direction
would
be
to
embrace
the
concept
of
our
static
site
editor
as
just
an
alternate
editor
in
the
gitlab
library
of
tools.
So
one
potential
way
we
would
position.
This
is
maybe
in
the
web
IDE
he
toggle
between
for
files
that
support
it
and
projects
that
are
configured
appropriately.
You
toggle
between
source
code
editor
and
a
visual
editor.
Maybe
this
shows
up
in
the
file
view
as
another
option
next
to
web
IDE
for
the
for
compatible
files.
A
But
really
what
we
would
be
saying
here
is
that
if
you
wanted
to
implement
this
on
your
production
site,
all
you'd
have
to
do
is
have
this
persistent
link
to
pass
into
gate
lab
and
again.
This
is
kind
of
what
we're
doing
now,
where
the
the
the
project
itself
is
kind
of
the
configuration
for
it
is
kind
of
lightweight,
there's
not
much
going
on
there.
A
It
passes
the
data
into
the
game
that
product
and
then
that's
where
the
editor
is
stored,
and
then
this
could
also
we
could
end
up
revisiting
our
split
you
conversation
in
this
event,
so
we
have
so
we'd
have
to
validate
that.
That's
even
a
good
idea.
That's
what
users
want
I
in
my
opinion,
of
the
three
directions
I'm
talking
through
this
is
probably
my
least
favorite.
I
think
this
doesn't
quite
address
all
the
concerns
that
we've
heard
from
users
of
our
different
personas
and
what
jobs
they
need
to
get
done.
A
But
it
is,
it
is
an
option
and
the
third
direction
and
then
I'll
stop
talking
is
something
of
a
hybrid
CMS
and
in
this
case
I'll
just
for
the
sake
of
argument,
run
with
the
idea
that
we
just
adopt
and
fully
embrace
the
idea
of
gitlab
pages,
and
maybe
we
kind
of
we
don't
take
over.
But
we
we
sort
of
take
over
though
the
pages
experience
and
then
bring
that
into
a
top-level
item
on
the
left-hand
sidebar
within
the
gitlab
product,
and
that's
where
you
can
configure
your
site
by
choosing
what
generator.
A
Then,
when
you
click
into
one
of
these
pages,
you're
brought
to
the
visual
editor
I
think
what
this
does
is
it
keeps
the
editor
in
the
good
lab.
Experience
introduces
a
lightweight
CMS
to
our
product,
but
it
also
allows
for
advanced
tools
and
integrations
within
the
get
by
product.
So
if
we
wanted
a
code,
editor
inline,
we
could
use
the
Monaco
Lite
editor.
A
Ide
we'd
be
able
to
do
that
and
then
over
here,
I
have
just
to
wrap
this
up,
like
there's
also
the
possibility
that
we
pick
a
direction
here
and
then
in
18
months
or
so
two
years,
three
years
down
the
road,
we
find
that
we
actually
converge
these,
because
I
could
see
us
building
a
CMS
but
then
also
building
the
lie.
Betting
experience
once
we've
learned
a
lot
more
I
could
also
see
it's
building
the
live,
editing,
experience
and
then
finding
that
we
need
a
CMS.
A
B
We
need
a
CMS
kind
of
interface
to
this
whole
thing,
but
things
like
a
CMS
has
come
up
in
the
recent
weeks,
such
as,
like
my
scheduling
posts
and
things
like
that,
where,
at
the
moment,
the
spirit
of
the
static
site
generators
like
get
it
lives
now
versus
that
with
the
scheduling
angle
to
it.
So
I
think
that's
something
that
you
probably
need
to
understand.
The
problem
better,
like
you
know,
because
you
can
almost
like
pseudo,
get
away
around
like.
A
A
And
that's
that's
a
good
plan.
I
should
be
more
precise
when
I
say
CMS,
because
I
think
that
implies
a
lot
of
functionality
and
really
what
I,
what
I
intended
to
get
out
was
like.
We
have
a
list
of
pages
and
content
on
the
site
and
you
can
click
through
the
navigation
tree
and
find
which
one
you
want
to
edit
like
that.
I
think
those
editorial
workflows
or
even
the
like
versioning
and
you
know,
draft
saving,
drafts
and
stuff
like
that
are
no
matter
what
gonna
be
further
down
the
road.
A
A
Share
some
of
the
more
advanced
features
among
our
other
groups
and
other
feature
areas
so
like
embracing
snippets
and
the
web
IDE,
and
rather
than
building
something
that's
an
either/or
and
then
finding
a
way
to
you
know,
simplify
the
file
tree
without
necessarily
hiding
it
completely.
That's
kind
of
what
I
mean
by
CMS
like
just
show.
The
pages
is
that
we
know
about
that
are
compatible
and
kind
of.
Let
you
navigate
between
them.
C
It
almost
kind
of
so
first
of
all,
yeah
I
just
want
to
say.
Obviously
thank
you
for
sharing
that
as
well
on
that
last
comment
regarding
this,
you
know
it
almost
sounds
like
you
just
want
the
simplified
view
of
the
repo
almost
like
you
want
to
only
display
a
certain
amount
of
pages.
Assuming
that
the
content,
the
files
themselves
are
the
CMS
that
they
hold
the
content.
I
always
say
that
again,
there's
a
whole
lot
baked
into
a
CMS
I'm
just
kind
of
reading
into
that.
C
C
A
Anyway,
none
of
this
obviously
meant
to
be
like
dear
alien,
anything
we're
currently
working
on
and
I
I
think
I
hope
that
it
will
at
least
complement
our
armed
UX
research
and
in
that
it
will
show
where
I
was
thinking.
We
might
head
down
the
road
but
yeah.
It's
all
extremely
malleable
at
this
point,
so
it's
just
just
my
way
of
getting
it
out
there.
C
A
A
B
A
A
A
B
Think
the
one
that's
like
most
pertinent
and,
in
my
mind,
is
the
publishing
flow.
So
this
is
the
flow
from
like
this
to
validate
and
kind
of
the
stuff
that
we've
been
doing
on
the
handbook
like
contributed
change.
Might
click
on
that
like
that
page,
whatever
Internet
delivered
for
13.2,
we
really
haven't
done
like
the
solution.
Validation
on
you
know,
is
it
I?
B
So
one
of
the
things
I've
been
holding
me
back
last
week
is
like
again
my
own
head
too
much
about
my
goal:
how
deep
do
I
go
or
like
stuff
like
that,
so
what
I've
been
doing
this
week,
it's
just
like
pushing
little
stuff
over
as
soon
as
possible.
So
yesterday,
I
made
a
little
bit
more
progress
on
the
screener
that
we
want
to
have
for
the
publishing
flow
or
like
just
a
screener
in
general,
for
static
site.
Editor
stuff
so
I
tagged
you
on
that.
So
so.
B
Let's
get
that
going
and
yeah
this
stuff
that
I'm
looking
at
is
like,
especially
not
more
there's
pages,
that
I
think
we
should
do
for
testing
and
Oh
need
your
feedback
in
like
either
tomorrow
about
the
scope
of
it,
because
the
publishing
flow
can
go
really
wild.
It
can
go
from
from
handbook
to
static
site
editor
to
like
creating
the
mr
and
leaving
it
and
then
do
we
want
to
add
a
tack
on
another
one
where
it's
like
from
the
handbook
and
you
jump
into
it
by,
like
hey,
looks
like
you
had
some
changes.
B
Do
you
want
to
continue
like
on
this
existing?
Mr?
Do
you
want
to
create
a
new
one?
So
this
whole
idea
of
like
revisiting
an
mr
or
adding
new
pages
to
NMR,
but
I
think
that's
also
important
to
like
figure
out
because
then
past,
like
the
next
chunky
bit,
that
we
would
need
to
tackle
so
I
guess
from
a
feedback
standpoint
tomorrow,
I'm
gonna
try
to
get
this
out
today
so
that
he
had
tomorrow
to
take
a
look
at
it
or.
B
His
look
at
that
flow,
I'm
gonna
also
send
it
to
my
manager
just
to
get
his
eyes
on
it,
so
that
I'm
a
UX
template.
It
looks
good
so
that
we
can
get
this
moving
by
the
end
of
the
week.
The
other
two
research
topics
the
opportunity
beyond
the
handbook
and
look
at
the
competitors
and
the
editing
experience
itself.
So,
like
you
know
how
far
we
go
down
the
block,
editing
experience
or
do
we
keep
it
and
get
that
specific
to
gain
those
advantages.
B
Like
you
highlighted
in
your
diagram
Eric,
those
ones
are
like
probably
lower
on
my
radar,
but
like
they're
still
equally
important,
so
I
think
we
have
a
lot
of
stuff
to
flesh
out
but
I
think.
For
me,
the
publishing
flow
one
is
kind
of
like
the
one.
That's
a
blocker
to
the
bigger
picture.
For
me,
yep.
B
B
So
what
I've
been
doing
recently
is
like
incorporating
trying
to
get
feedback
on
designs
earlier
through
issues
rather
than
having
enough
channel
chat
about,
in
fact
about
the
designs
or
something
like
that,
and
just
using
the
issues
themselves,
it's
good
that
people
are
collaborating
on
it,
but
then
it
creates
a
lot
of
noise.
So
one
of
the
concerns
was
like
how
do
we
know
which
one's
the
real
one
to
follow
or
like
which
one's
the
current
direction?
B
C
B
If
we
continue
down
this
route,
what
I
suggest
is
that
in
the
description
is
up
to
me
to
like
maintain
my
is
the
current
kind
of
mine
of
thought
or
and
then
finalize
that
up
with
the
updated
final
designs,
once
that's
ready,
yeah,
that's
like
one
way
of
doing
it
and
I
think
for
now.
I
think
that's
a
good
way
for
it
for
me
to
like
prefix
any
concept
designs
with
concepts,
or
at
least
that
stands
out
in
the
design
management
tab.
B
But
let's
continue
this
way
until
we
run
into
more
issues,
because
other
groups
and
get
lab
have
split
off
like
an
issue
like
an
implementation
issue
and
like
a
UX
issue
as
well,
and
we,
this
is
something
we
talked
about
in
the
past
as
well.
I,
don't
think
we
need
to
split
it
yet
and
I
think.
Let's
try.
Let's
try
for
me
to
be
more
disciplined
in
my
naming
convention
and
then
we'll
see
if
we
run
into
any
more
hiccups
or
noise.
A
B
C
B
Trying
to
bring
all
those
diagrams
into
like
the
main
issue
page
so
that
you
don't
need
to
toggle
between
the
two
different
states
back
and
forth
back
and
forth
mm-hmm.
My
point,
the
one
point
I
keep
on
they
nudging
is
like
it's
always
like
symmetric
one.
That's
like
the
main
design
so
like.
If
you
have
like
20
designs
in
there
like,
if
you
can
star
one
nope
in
one
to
be
like
the
current
one,
that
would
be
ideal.
Yeah.
A
Yeah
yeah,
oh
I'll,
share
that
feedback
with
her
and
and
it
sounds
like
they're
working
on
it,
obviously
something
that
other
people
have
run
into,
but
that's
a
good
point
and
I
think
I
think
what
I
would
want
to
do.
Just
it
doesn't
sound
like
you're
advocating
for
this,
but
just
to
say
that
my
stance
on
it
is
I
would
not.
A
I
would
not
want
to
fall
into
the
pattern
of
like
requiring
you
to
create,
like
lengthy
design
specs
for
each
issue
or
each
feature
that
then
get
their
own
issue
as
like
a
source
of
documentation.
I
I,
like
the
lightweight
nature,
as
long
as
it
can
work
that
we've
been
doing
and
keeping
it
in
the
issue.
So
if
we
can,
we
can
try
and
we'll
keep
this
working
and
and
make
it
more
clear
than
I.
Think
that
would
be
my
preference
to.
A
Right,
well,
that's
it
on
my
agenda.
I
will
be
where,
as
I
said,
working
on
thirteen
three
planning,
so
I'll
be
letting
them
people
know.
If
I
have
any
questions
on
issues
and
obviously
Michael
you
can,
we
can
start
working
on
the
spreadsheet.
If
you
have
any
particular
UX
related
issues,
you
you
want
to
promote
for
thirteen
three,
let
me
know
same
for
engineering.
Derek
will
open
it
up
for
the
team's
feedback.