►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts.
A
A
Hi
everyone:
this
is
the
static
site,
editor
design
and
product
meeting,
and
we
are
jumping
in
progress,
mid
conversation.
So
I'll
recap
a
little
bit.
It
is
july,
13
2020
and
we
were
just
talking
about
the
potential
future
directions
for
the
static
site,
editor
as
it
relates
to
whether
we're
building
a
cms
or
a
live
page,
editing,
experience
or
something
else,
and
I
was
just
recapping
some
of
the
diagrams
that
I
or
the
diagram
I
had
made
last
week.
So
I'm
going
to
share
my
screen.
B
A
There
so
again
we're
here
in
this
diagram
we're
building
a
production
page
that
sends
or
we're
trying
to
connect
to
a
production
page,
that's
a
static
site.
Send
the
data
that's
linked
to
a
repository
in
the
backend,
so
we
know
which
data
to
send
right
now.
Markdown
and
ruby
templates
would
send
the
data
the
markdown
would
get
parsed
into
this.
A
Wizzywig
single
page,
editor
and
edits
are
edits,
result
in
a
merge
request,
pretty
simple
flow
and
there's
a
pretty
clear
line
for
iteration
and
improvement
on
that
user
experience
just
in
making
that
wysiwyg
mode
more
powerful
and
able
to
handle
different
types
of
content,
either
media
content
or
like
image
tools
for
optimizing
images
and
mermaid
diagrams,
and
things
like
that
handling,
like
potentially
even
referencing
other
files,
like
other
pages
and
includes,
and
things
like
that,
we
can
get
pretty
fancy
with
it.
But
it's
all
just
kind
of
building.
A
On
top
of
the
single
page,
editing
experience,
and
then
we
have
you.
This
is
relevant
because
this
is
sort
of
a
ux
research
task
right
now,
but
we
have
pretty
clear
understanding
that
we
need
to
work
on
a
workflow
that
allows
you
to
edit
multiple
pages
at
once
within
one
mr
and
also
potentially
perform
multiple
edits
on
a
single
page
on
multiple
sessions.
A
So
like
the
idea
of
saving
a
draft
and
coming
back
later,
picking
up
your
work
where
you
left
off-
or
maybe
after
you
create
the
mr,
you
want
to
come
back
and
refine
it
in
the
static
site.
Editor.
Those
workflows
aren't
really
possible
right
now,
so
we
want
to
make
those
possible
a
little
bit
further
down
the
line.
We
have
like
a
preview
using
the
production
css
so
like
a
live
preview
or
block
editor
page
builder
experience.
A
These
are
a
little
fuzzier,
but
these
are
just
the
extensions
on
the
editing
and
previewing
experience,
and
then
then
it
gets
a
little
more
interesting
and
I
think,
there's
a
few
directions
we
can
take,
I'm
actually
going
to,
for
the
sake
of
time,
skip
over
direction
b,
which
is
just
like
we
could
just
be
a
mode
of
the
web
ide.
A
A
more
visual
editing
mode
of
the
web
ide
this
would
probably
require
us
extending
monaco
or
like
adding
a
layer
on
top
of
monaco
editor,
which
is
what
they
use.
I
don't
love
this
direction
because
it
kind
of
limits
our
our
iteration
path.
It
starts
to
starts
to
feel
like
we're
just
adding
a
feature
on
top
of
somebody
else's
feature,
rather
than
building
out
something
really
useful
for
a
large
amount
of
users.
A
So
but
it's
still
a
valid
option.
It
might
be
where
we
hit
the
live
page,
editing
experience.
This
would
be
similar
to
what
we
talked
about
with
tina
cms,
and
we
saw
we
saw
this
on
stack
bit
with
their
live.
Edit
live
page
editor,
but
in
in
this
scenario,
the
little
purple
header
means
we're
in
get
lab
and
underneath
the
gitlab
product
umbrella.
A
You
would
configure
your
page,
probably
within
gitlab,
but
then
package
and
deploy
it
onto
your
cdn
of
choice,
whether
that's
pages
and
gitlab,
or
maybe
you
know,
netlify
or
somewhere
else,
and
then
on
your
production
site.
You'd
have
an
edit
button
and
that
link
we
would
handle
the
auth,
but
then
embed
the
editing.
Experience
on
your
production
site,
whether
that's
running
in
like
a
kubernetes
container
or
something
or
it's
live
javascript,
that's
all
to
be
determined,
there's
a
lot
of
hand
waving
here,
but
this
is
the
cms
approach
right.
A
It
gets
a
little
more
complicated
when
you
start
talking
about
like
adding
new
pages
and
jumping
between
pages
and
authoring
draft
content.
Things
like
that,
but
we
would
explore
it
within
this.
Confine
maybe
there's
like
a
lightweight
cms,
basically
on
the
flip
side
of
your
production
page,
and
I
think
option
c
is
kind
of
the
mirror
image
of
that,
which
is
we
just
kind
of
adopt
the
pages
concept.
This
is
just
a
proposal.
A
A
Then
we
can
get
really
fancy.
We
could
have
advanced
tools
and
integrations
we
could
bring
in
the
actual
web
ide
or
the
editor
lite.
As
our
inline
code
editor,
we
could
have
a
visual
editor
for
working
with
data
files,
like
tables
for
yaml
and
json
things
like
that,
and
then
the
last
bit
on
this
before
I
stop
to
recap:
is
that
long
term?
Two
to
five
years
from
now,
maybe
there's
an
option
for
both
of
these
to
converge.
A
So
anyway,
that's
that's
what
I
presented
last
week
for
lauren
and
katherine:
that's
the
eclipse
notes
version,
there's
a
recording
of
it.
We
talked
about
it
a
little
bit
more
before
I
haven't
added
anything
to
this
since
then,
but
it
just
shows
like
where
we
might
be
headed
and
obviously
each
one
of
these
points
will
be
validating
and
iterating
and
doing
research
and
getting
feedback
from
users.
A
Yeah-
and
I
think
one
of
the
decision
points
for
me-
is
going
to
be
in
in
research
outside
of
gitlab,
so
with
users
that
might
be
hosting
their
static
site.
Editors
already
are
the
static
sites
already
on
netlify
or
or
gitlab
or
github.
The
the
real
question
for
me
is:
where
is
the
most
effective
place
for
these
personas
to
be
making
the
edits?
Is
it
a
custom-built
cms
like
interface
within
the
gitlab
product,
or
are
they
do?
A
We
need
to
kind
of
plant
a
stake
in
the
ground
and
say
that's
actually,
the
old
way
of
doing
things
and
like
the
old
way
of
thinking
and
the
modern
way
of
editing
is,
is
all
edit
meeting
live
on
the
page
and
we'll
just
try
and
figure
that
out?
But
I
I
don't
know
yet
so
that's
where
we
need
to
start
pulling
on
the
threads
and
figuring
out
where
the
best
place
to
what's
the
best
entry
point
into
the
editing
experience
and
what
makes
the
most
sense.
A
But
yeah,
that's
that
was
not
on
the
agenda,
but
it
is
something
that
we
talked
about
before
and
I
wanted
to
recap
for
you
so
open,
obviously
to
any
feedback
on
that.
There's
not
really
an
issue,
but
I
guess
we
could
just
use
the
category
strategy
maturity
to
discuss
this.
Obviously,
the
agenda
doc
is
open.
If
you
want
to
leave
feedback
on
it.
A
A
Our
handbook
site
is
is
very
much
coming
together
as
a
well-defined
set
of
of
content,
separate
from
that
everything
else
on
the
site
could
and
may
be
better
could
be
better
served
on
a
on
a
cms
or
on
having
a
little
more
enterprise
level
management
features
or
something
like
that.
So
they're
drafting
these
requirements
I'm
supportive
of
either
direction.
I
don't
think
that
we
should
we
as
a
static.
A
Editor
group
should
push
our
feature
to
be
included
in
consideration
for
something
that
it's
clearly
not
suited
for
yet,
and
it
could
be
multiple
years
before
it
gets
to
that
level.
I
don't
want
to
put
undue
pressure,
but
at
the
same
time
I'm
always
interested
in
more
feedback
and
dog
fooding
opportunities.
So
if
there's
a
way
we
can
make
it
work,
I'm
happy
to
happy
to
do
so.
A
D
C
I
it
got
pushed
to
this
friday,
so
if
you
have
feedback
and
comments,
please
add
your
your
comments
to
the
issues
of
them
in
our.
A
The
timeline
for
making
a
decision
on
whether
we
should
pursue
a
cms
is
this
week
and
then
there's
going
to
be:
if
the,
if
it's
a
go,
it
would
be
investigation
into
which
one
and
then
how
long
is
it
going
to
take
to
implement
and
who's
going
to
help?
You
know
whether
it's
possible
to
do
internally
or
we
need
to
engage
a
vendor
or
something
like
that.
So
I
think
it's,
my
understanding
is
it's
a
project
that
would
likely
move
into
q3
or
q4
as
far
as
implementation
goes,
but
the
decision
is
happening
shortly.
A
And
the
only
other
topic
I
wanted
to
bring
up
from
a
product
standpoint,
which
is
kind
of
interesting,
was
a
conversation
that
happened
at
the
end
of
last
week,
related
to
formatting
of
markdown
and
actually
spurred
from
michael,
your
question
on
one
of
the
merge
requests
about
the
preference
of
using
dash
versus
asterix
on
the
unordered
list
markup,
and
for
those
that
are
watching
this.
A
That
might
not
know
which
I
can't
imagine
there
would
be,
but
that's
both
valid
markdown
syntax
and
you
can
use
them
interchangeably
as
long
as
they're
used
exclusively
within
a
list,
you
can
actually
use
them
interchangeably
within
a
file
and
it'll
parse
out
a
bullet
in
either
way.
We
have
a
document
and
get
lab
approach.
A
We
a
preference,
I
should
say
for
writing
handbook
and
documentation
and
that's
to
use
hyphen
the
reason
I
didn't
catch.
It
is
because
my
personal
preference
is
to
use
an
asterisk,
and
I
was
like
oh
great.
This
is
formatting
it
perfectly,
but
michael
correctly
pointed
out
that
that
was
I.
B
A
Actually,
inconsistent
in
writing
my
description
because
I
I
wrote
the
correct
gitlab
preference
and
then
proceeded
to
forget
when
I
was
actually
editing
so
we're
working
on
getting
them
consistent,
enrique
and
derek.
Have
an
approach
already
defined
that
will
allow
us
to
tweak
the
toast,
ui
markdown
converter,
to
follow
the
handbook
preferences
and
then
we've
already
started
talking
about
making
it
something
that
can
be
defined
in
a
configuration
file
or
something
passed
in
from
the
user
to
define
their
preferences.
A
So
right
now
we're
focused
on
making
it
work
for
the
handbook
and
then
shortly
we'll
investigate
overrides
for
that.
So
if
you
could
pass
in
preferences
for
using
bullet
type,
there
was
like
a
number
of
indents
like
whether
or
not
you
increment
the
numbered
list.
There's
a
few
others
in
that
issue
that
are
that
are
really
style.
Stylistic
preferences
they're,
not
necessarily
extensions
of
markdown
they're,
just
different
ways
of
writing
it
and
the
the
reason
all
behind
this
is.
A
If
you
had
a
markdown
file
that
already
existed,
and
you
wrote
it
all
using
asterisks
for
your
unordered
list
and
you
bring
it
into
the
static
site.
A
D
D
So
for
the
design
side,
I
think
the
big
thing
on
on
the
plate
is
like
the
internal
solution,
validation
of
editing
the
handbook.
So
the
scope
of
this
is
to
understand
so
we're
looking
at
taking
some
of
the
fields
that
you
would
populate
in
a
merge
request
and
trying
to
pull
them
into
the
static
site
editor
so
that
you
can
bring
it
into
what
integrated
into
the
flow
better.
So
that's
one
of
the
goals
of
the
research
is
to
take
a
look
at
you
know.
D
Are
we
including
the
right
fields
in
the
right
way,
so
that
you
can
do
everything
you
need
to
do
for
merge,
requests
directly
from
the
static
site
editor
so
trying
to
keep
the
user
in
that
world?
So
that's
one
point:
the
other
point
is
looking
at
how
we
handle
multiple
pages
per
edit.
So
at
the
moment
the
static
site
editor
only
handles
one
page
at
it,
and
then
you
create
a
merge
request
and
then
and
that
gets
sent
through
to
get
that
and
what
we're
looking
at
exploring
in
this
one
in
this
solution.
D
Validation.
Is
this
idea
of
allowing
a
user
to
select
an
existing?
Mr
to
base
their
changes
from
so
this
way
you
can
change
multiple
pages.
I
guess
the
big
question
here
is
like
this.
This
idea
of
like,
if
we
should
abstract
all
the
way
through
merge,
requests
instead
of
branch,
so
there's
or
is
it
good
to
have
changes
on
the
branch
levels
of
this
kind
of
complexity
like?
Are
we
gauging
it
at
the
right
level?
Are
we
abstracting
too
much
away
or
are?
D
Are
we
still
using
such
technical
terms
that
it's
still
daunting
or
like
it
brings
another
level
of
confusion
to
the
world
of
good
lab
and
editing
the
handbook?
So
I'm
updating
the
issue
at
the
moment
on
that
and
adding
up
the
prototype.
D
Last
week
I
got
portraits
going,
but
catherine
was
kind
enough
to
take
a
look
at
some
of
those
questions
and
refine
them
out.
So
I
appreciate
that.
I
guess
you
know
pretty
much.
The
questions
are
there,
so
I
guess
that
can
go
live
now
and
we
can
recruit
internally
but
yeah.
D
I'm
not
100
sure
on
the
differences
on
recruiting
internally
externally,
if
it's
as
formal
or
is
it
more
casual
like
the
first
round
of
solution,
validation
that
we
did
back
in
back
in
may
april
may
so
yeah,
that's
kind
of
like
the
stuff
on
the
design
side.
A
I
woke
up
to
this
one
from
jason,
who
has
been
using
it
internally
and
he
basically
asked
for
exactly
what
you're
saying
is
a
little
bit
of
extra
context
to
provide
with
the
mr
but
he's
asking
from
the
standpoint
of
somebody
here
internally,
who
knows
what's
going
on
and
actually
reads
the
change
log
and
looks
at
it
and
sees
that
there
are,
mrs,
that
don't
really
follow
best
practices
for
for
being
descriptive,
which
is
totally
valid,
and
we
knew
that
was
an
issue
so
yeah
just
a
little
bit
of
extra
validation
there.
A
That
this
is
something
internal
users
want.
I'm
sure
he
would
be
willing
to
test
the
prototype
yeah.
D
Cool
one
out
of
four
one
out
of
five
people
yeah
now
we
just
need
to
fight
for
it.
B
I
would
say,
generally
speaking,
you
don't
need
to
create
a
screen
or
survey
unless
there
are
a
series
of
questions
that
you
want
people
to
answer
in
order
to
participate.
So
say
it's
not
open
to
everyone
in
the
company
and
you
want.
You
know
the
right
people
to
participate.
Then
you
can
create
a
question
asked
about
the
tools
they're
using
or
whether
they're
experienced
with
something,
but,
generally
speaking,
you
can
reach
out
to
people.
You
want
to
participate
in
just
similar
to
the
previous
study.
B
You
did,
and
I
would
just
say,
try
not
to
go
within
the
team
too
much
because
yeah
they
have
that
higher
level
of
awareness
of
what's
going
on,
but
it
seems
like
a
lot
of
the
target
users
would
be
outside
of
the
team.
So
maybe
that's
not
as
much
of
a
concern
for
this
area,
but
I
would
just
keep
that
in
mind.
D
B
A
D
Yeah
so
so
that
bigger
one
had
that
kind
of
like
the
external
looking
one
is
probably
the
some
of
the
other
research
issues
that
are
on
the
unlike
kind
of
drafted
up,
not
really,
as
formally,
though,
though,
is
like
the
ones
around
looking
at
other
opportunities
of
the
like
static
site
editor.
So
maybe
we
can
get
get
going
on
that
because
I
guess
recruiting
for
externals
will
be
tougher.
So
maybe
we
have
a
separate
thing
called
to
discuss
that
in
more
detail.
D
Me
I
don't
know
if
there's
like
any
hard
net
timeline,
I
think
you
know
maybe
eric
you
can
jump
in
with
this,
but
like
from
my
point
of
view
on
it
is
maybe
in
the
next
one
or
two
like,
maybe
like
fifteen
5
4,
in
the
sense
that
it
doesn't
affect
any
immediate
decisions
we
make
now.
But
what
it
will
help
is
help
us
guide
like
the
engineering
direction
so
that
we
don't
box
ourselves
up
into
a
box
too
early
but
yeah.
Maybe
here
he
can
add
some
more
color
today.
A
Yeah,
I
know
I
think,
that's
that's
the
program.
I
mean
the
the
research
that's
relevant
to
stuff
that
we
might
want
to
prioritize
in
like
13
4
13
5
would
be
the
stuff
about
managing
that
merge,
request
flow
and
surfacing
some
more
of
the
information
about
the
publishing
and
maybe
saving
drafts
and
things
like
that.
But
the
the
larger
research
questions
you
know
a
couple
months
is
probably
just
fine.
A
What's
our
so
we
get
some
usage
usage
statistics
from
our
users.
We
don't
have
very
many
I'm
looking
now
and
we
right
now
have
a
rolling
average
or
rolling
total
of
23
monthly
active
users,
so
most
of
them
being
internal,
but
we
do
have
some
external
users
that
have
either
mentioned
us
on
issues
or
like
we
have.
I
don't
think
we
have
like
personal
identifiable
information
in
the
statics
editor,
but
how
would
we
go
about
or
can
we
go
about
recruiting
people
from
like
usage
statistics?
A
B
I
am
not
a
hundred
percent
sure.
I
know
that
recently,
one
of
our
researchers
on
the
growth
team
has
been
looking
into
sending
out
emails
like
pulling
a
list
from,
I
think,
from
periscope
like
finding
a
list
of
users
based
off
some
criteria
in
periscope
and
then
using
that
to
create
a
mailing
list
that
might
be
related.
Maybe
if
you
can
kind
of
show
me
the
usage
data
and
then
we
can
see
if
that's
possible,
but.
A
Yeah,
I
can
send
you
a
link.
We
have
a
dashboard
now,
which
is
great
thanks
to
john.
We
one
thing
one
avenue
I
could
think
of
now
would
be
I'm
pretty
sure.
We
know
what
projects
use
it.
We
might
not
know
what
people
are
publishing
using
it,
but
we
know
what
projects
have
integrated
the
statics.
I
editor
because
the
path
to
the
project
gets
sent
in
to
the
editor
itself,
so
we
could
potentially
go
on
to
those
projects
as
people
and
just
leave
comments
and
and
ask
in
there
assuming
they're,
not
private.
A
You
know
we
wouldn't
have
access
to
them,
but
even
that
I'm
not
sure
I
might
it
might
cross
a
line.
So
we
can
talk
about
it.
I'll
I'll
talk
about
the
product
team
also.
A
Well
that
I
think
that's
it
for
our
agenda,
any
other
topics
or
questions
now
that
we've
got
some
extra
visitors
thanks
for
for
joining
by
the
way.
A
Great
well,
let
me
stop
the
recording.