►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts
A
All
right
so
welcome
everyone
to
the
static
site,
editor
product
and
design
weekly
call.
This
is
august
17th
and
we
were
just
discussing
the
upcoming
static
site.
Editor
group
conversation,
which
is
tomorrow,
the
18th
at
8
a.m,
pacific
time
and
related
to
that.
A
The
only
other
thing
I
wanted
to
call
it
was
that
we
made
an
announcement
today
that
the
static
site
editor
is
available
on
the
entire
handbook
on
all
pages
of
the
handbook,
which
is
very
exciting,
but
a
little
less
dramatic
of
a
reveal
because
it
actually
had
been
like
that
most
of
last
week
too,
we
just
made
the
announcement
today.
So
now
everybody
knows
about
it.
We've
been
we've
had
a
few
people
respond
and
show
their
excitement
and
enthusiasm.
That's
that's
great,
and
I
guess
the
other
thing.
A
The
other
part
of
that
announcement
worth
calling
on
the
recording
was
we
made.
We
hit
we're
nearing
our
goal
for
handbook
pipeline
duration,
average
duration
of
the
pipeline
times
has
been
a
struggle
for
gitlab
in
general.
It
was
peaking
at
over
30
minutes,
sometimes
hitting
40
minutes.
A
It
is
now
just
about
11
minutes,
and
so
the
hard
work
that
many
of
us,
not
just
in
the
startup
site,
editor
group
have
been
doing
to
to
improve
it.
But
I
will
say
mostly
chad
and
lauren
have
been
working
hard
on
getting
that
down
and
their
hard
work
is
paying
off
it's.
A
Our
goal
was
10
minutes
we're
almost
there
and
then
we'll
probably
have
to
have
a
discussion
about
how
we
can
get
it
under
10
minutes
down
to
like
maybe
five
or
something
like
that,
but
that's
very
exciting,
because
it's
when
it's
a
30
minute
build
it's
very
disruptive
to
collaboration.
A
Good
yeah
cool
all
right.
I
just
had
two
things.
The
first
was
just
an
update
on
the
category
maturity
scorecard.
I
saw
the
note
in
there
about
where
we
should
be
sourcing
from
and
how
many
groups
so
it
looks
like
we
should
probably
aim
to
do
to
identify
15
participants.
Three
different
internal
groups,
maybe
like.
A
I
don't
know
that
product
would
be
the
best
one
to
score
our
product.
I
think
maybe
we
should
filter
them
out
for
this,
this
research,
but
yeah,
so
we
can
identify
those
people.
We
don't
need
to
spend
the
time
on
the
call
doing
that.
But
I
think
those
are
that'll
be
the
next
step
and
we
should
get
moving
on
that
now
that
it's
available
everywhere.
A
A
C
A
Yeah,
that's
a
good
point,
I
mean
yeah,
we
can
discuss
it
in
the
issue.
I
think
there
might
be
two
different
groups
in
marketing
or
two
different
groups
in
sales.
You
know
like
this.
Those
are
fairly
large
organizations.
We
don't
need,
we
can
narrow
it
down
a
little
more
to
help.
C
B
C
Things
related
to
maybe
action
items
from
leadership
meetings
or
things
like
that,
like,
for
example,
emily
shario
in
the
internal
strategy
consultant
role.
I
know
she's
moving
on
soon,
but
that
is
also
it's
not
a
it's,
not
a
one
uniform
group,
but
that's
also
another
group
of
people.
I
think
of.
A
Yeah
and
we
have
worked
with
emily
on
some
research
before
she,
she
weren't
moving
on
which
we're
very
excited
for
her
for
the
record,
but
we
would
probably
consider,
but
maybe
she
can
find
some
others
that
she
works
with
or
do
similar
work.
That's
a
good
call.
B
Question:
what's
the
best
way
to
reach
out
to
these
people
slack
directly
or
ping
them
directly
or
using
channels
like
last
time,.
A
A
A
A
I
have
been
talking
with
john
about
how
we
kind
of
need
to
commit
to
some
loose
direction,
for
whether
we're
moving
towards
something
more
like
an
open
text,
area
or
individual
text
areas
like
a
like
a
traditional
cms
or
a
more
flexible
block,
editor
that
has
sort
of
like
every
paragraph
is,
you
know
its
own
block
of
content
and
I've.
A
Given
this
a
lot
of
thought
over
the
past
few
weeks,
I
need
to
document
this,
but
for
the
purposes
of
the
discussion,
if
we
were
to
say
we're
going
to
commit
to
having
a
really,
you
know
really
well
done
best
in
class
block
editor.
What
does
that
look
like?
Who
else
is
doing
it?
Well
that
we
can
draw
inspiration
from
who?
What
other,
what
risks?
Might
we
be
exposing
ourselves
to?
A
As
far
as
the
user
experience
goes
or
limitations
that
we
might
run
into
the
only
things
I
can
think
of
are
very
long
form
content
like
handbook
pages,
that's
a
lot
of
blocks,
it
might
be
a
performance
hit
and
it
might
be
just
difficult
to
manage
like.
If
I
wanted
to
select
multiple
paragraphs
or
select
the
whole
page,
we
I
would
want
to
make
sure
that
whatever
solution
we
have
selection
across
blocks
is
really
solid.
A
I
can
imagine
trying
to
copy
between
multiple
paragraphs
and
it
spans
multiple
blocks
and
how
how
we
handle
that
would
probably
be
very
important
to
define.
Personally,
I
think
notion
does
this
very
well
in
their
editor.
Now,
obviously,
it
is
web-based,
but
it's
not
a
web
editor,
it's
it's
its
own
thing,
but
we've
we've
looked
into
that
before
and
you've
recorded
video
walkthroughs,
and
I
I
think
that
there
it's
very
very
well
done
editor.
I
think
ghost
which
I
haven't
played
with
in
person,
but
I've
seen
screenshots
of
and
little
animated.
A
Gifs
of
I
think
those
are
does
make
me
feel
like
they
have
something
pretty
special
there
and
the
the
reason
I
am
drawn
to
the
block
editor
is
mostly
because
I
want
to
unlock
some
functionality
down
the
road.
A
It
seems
easier
for
me
to
wrap
my
head
around
things
like
partials,
like
including
content
from
partials,
or
includes
extending
the
editor
with
custom
content
types.
So
allowing
a
front-end
engineer
for
their
project
to
say,
I'm
going
to
create
a
gallery
content
block,
and
then
you
provide
any
number
of
images
and
it'll
do
a
slideshow
gallery
right.
We
don't.
A
We
don't
have
to
write
that,
but
somebody
could
write
a
widget
for
lack
of
a
better
word
that
gets
inserted
into
a
page,
and
I
think
this
is
and
I'll
wrap
up
with
this
thought.
This
is
where
we
would
start
to
toe
into
the
page
builder
territory,
because
you
could
have
these
little
a
little
bit
more
elaborate
content
blocks
that
could
be
inserted
into
the
page,
and
that
makes
me
nervous
because
I
don't
think
our
near-term
mission
should
be
to
enable
like
template,
building
and
page
building
and
like
layout
of
landing
pages.
A
But
I
do
think
that
there's
a
very
strong
use
case
for
guided
content.
A
You
know
rearranging
it's
hard
to
it's
hard
to
describe
but
like
having
it
on
rails
a
little
bit
and
giving
the
the
options
to
the
front
engineer
to
configure
the
editor.
A
B
Okay,
I'm
just
going
to
go
here,
and
I
I
saw
catherine
put
down
a
question
saying
is
this
related
to
a
research
issue
around
issue
in
921,
which
is
looking
at
like
other
areas
of
the
handbook,
editing
and
then
the
one
I
put
down
to
tonight.
B
93
is
about
like
the
editing
experience
itself.
So
923
was
looking
at
like
what
kind
of
editing
experience
do
we
want
to
have.
Do
we
want
to
have
the
block
editor?
Do
we
want
like
the
fields
where
you
type
in
on
the
like
sidebar,
and
then
it
populates
into
the
center,
or
do
we
want
side
by
side,
or
you
know
like
that?
Editing
experience
like
what's
that
right
feel
for
that?
That
was
what
923
is
about,
and
91
is
an
interesting
one,
because
it's
like
looking
at.
B
Where
else
could
we
use
static
site,
editing
within
gitlab's
product,
for
example?
You
know
when
you're
writing,
issues
and
stuff
like
that,
like
is
that
you
know
that
editor
there
is.
Should
that
be
the
static
site,
editor
component,
you
know,
that's
like
an
editing
block
itself
or
you
know,
are
we
looking
at
other
use
cases
beyond
the
handbook
and,
like
you
know,
do
we
integrate
with
other
things?
B
So
I
think
what
we
need
to
do
is
frame
what
we're
trying
to
solve
before
we
like
double
down
on
block
editors,
wanted
them,
and
I
think
it's
probably
like
the
one
that
we're
going
to
go
with
at
the
end
but
yeah.
I
think
this
will
be
answered
once
we
get
a
good
feel
of
how
we
want
to
edit
our
edit
with
the
use
cases
that
we
deal
with
gitlab
and
then
looking
beyond
our
internal
and
looking
at
the
external
purposes
of
it.
B
B
B
So
maybe
those
three
somehow
in
combination
will
help
articulate
the
future
of
the
editor,
because
I
think
we're
in
this
like
funny
spot
in
the
middle
now
that
now
that
it's
in
the
handbook,
you
know
when
I
first
joined
the
team
that
was
kind
of
demanding
I
was
like
you
know,
we
want
to
make
it
easier
for
people
to
contribute
to
the
handbook
cool
we're
getting
there,
and
then
we
have
a
good
path
towards
that.
B
But
beyond
the
handbook
is
you're
kind
of
looking
at
that
as
well,
and
I
think
this
is
that
fuzzy
ground-
that's
like
fun
in
product,
where
you
get
to
discover
and
do
more
problem
validation,
and
things
like
that.
I
think
we
just
need
to
get
on
this
and
prioritize
is
maybe
have
a
separate
call
for
talking
about
this
in
detail.
I
think
that
would
be
useful
for
for
discussing
in
detail
outside
this
quote.
A
Yeah
completely
agree,
and
I'm,
as
I
mentioned
last
time-
and
I
didn't
get
a
lot
of
a
lot
further
on
the
jobs
to
be
done
last
week,
just
for
other
things
on
my
plate,
but
the
but
nailing
those
down
and
that's
kind
of
where,
where
I've
come
closer
to
an
opinion,
at
least
not
say
a
decision,
but
an
opinion.
A
stance
on
whether
or
not
we
should
be
investigating
a
block
editor.
And
it's
it's
mostly
around
those
jobs
to
be
done.
A
That
aren't
as
frequently
needed
in
the
handbook,
but
are
when
you
start
thinking
about
it
as
a
as
a
product
that
everybody
can
use
on
multiple
static
site
generators
and
potentially
for
any
number
of
different
types
of
sites,
documentations
or
sites
or
blogs,
or
any
any
marketing
or
landing
page
kind
of
site,
and
the
reason
I
guess
to
distill
it
down
the
reason.
I
think
that
it's
an
interesting
direction
is
for
flexibility
and.
A
A
A
C
Yeah,
so
I
thought
you
brought
up
good
points
from
reading
the
category
direction
page.
It
seemed
like
there's
a
lot
of
in
the
thought
about
where
it
might
go,
but
what
I
see
less
of
is,
I
guess,
the
primary
targets.
So
I
know
currently,
internal
users
are
the
primary
target
users
kind
of
by
default,
but
where
I'm
not
sure
is
beyond
that,
who
will
be
the
next
kind
of
like
core
groups,
because
there's
kind
of
a
lot
of
possibilities?
C
It's
almost
like
a
hypothesis
about
who
you
think
it
can
serve
the
most
and
what
use
cases
they
would
have
and
then
kind
of
understanding
what
how
they
can
accomplish
that
within.
Like
the
context
of
git
lab,
I
think
that's
how
I
tend
to
think
about
it.
So
I
think,
in
this
case,
there's
probably
more
hypothesizing,
but
then
you
can
use
research
to
say
test
and
understand
whether
the
people,
you
think,
would
be
the
target
users
whether
they
would
even
need
this
type
of
feature
for
their
workflow.
C
You
can
make
you
can
do
a
prototype,
that
tests
out
certain
flows
and
see
if
it's
usable,
so
I
think
there
will
probably
be
more
hypotheses
up
front
and
then
research
can
kind
of
test.
Those
hypotheses.
A
A
Marketing
content,
content
marketing,
you
know,
writers,
they
might
be
stakeholders
in
a
small.
You
know
like
an
agency
or
something
like
that
they
could
be
the
clients
themselves.
You
know
for
for
small
projects.
If,
if
I
had
to
pick
one
or
two,
though
I
think
you
know
it's
gonna
be.
A
A
C
I
think
I
saw
a
similar
problem
with
design
management
because
it
was
such
you
know
like
a
new
area
and
in
this
case
a
new
set
of
users
entirely.
But
what
I
think
we
tried
to
think
about
is
how
we
would
be
bringing
people
over
to
the
editors.
So
are
we
saying
this?
C
Isn't
a
product
offering
that
will
bring
in
entirely
new
users
like
people
who
are
totally
unrelated
to
gitlab
and
they'd,
be
interested
in
this,
and
they
could
use
it
in
some
way
or
is
it
kind
of
like
a
bridge
between
a
team
like
say
you
already
have
developers
on
git
lab,
and
now
you
want
designers
on
that
team
to
start
using
gitlab.
So
you
start
talking
to
customers
who
have
expressed
pain
points
related
to
this
feature
set
or
something
like
that.
A
Yeah,
that's
a
great
point
and
I
think
you're
I'll
I'll
probably
ask
a
little
bit
more
about
your
experience
with
the
design
management
because
I
do
think
there's
a
lot
of
parallels.
The
I
think
the
goal
here
is
pretty
clearly
to
be
the
bridge
into
newer
personas
that
are
already
part
of
a
team
that
might
already
be
using
gitlab
we're
not
necessarily
building
this
right
now
in
a
way
that's
going
to
attract
new
customers
in
mass
quantities.
A
There
might
be
some
that
hear
about
it
and
are
like
well
switch
from
another
product
to
this,
or
you
know
I
read
some
kind
of
tutorial
online
and
it
tells
me
that
I
should
just
go
to
gitlab
to
do
this
all
in
one
place.
That
would
be
great,
but
I
think
at
least
at
first
it's
gonna
be
like
okay.
C
B
Yeah,
that's
all
right,
I
think
it's
all
related
and
there's
that
blurry
line
between
design
and
product
and
research,
it's
just
a
happy
space
for
all
of
us
yeah.
My
thing
was
just
like
editing
on
front
matter,
so
adrian
got
the
license
for
the
tool
for
what
we're
going
to
try
to
use
for
the
unmoderated
testing
and
I'm
going
to
start
trying
to
recruit
people
directly.
For
that,
the
way
I'm
kind
of
targeting
people
is
people
who
made
edits
to
the
handbook
related
to
front
matter,
excluding
people
from
our
team.
A
Yeah,
that
sounds
great.
That's
a
good
way
to
filter
it.
We
don't
do
a
ton
on
the
handbook
with
front
matter,
so
that
should
narrow
it
down
pretty
yeah
to
a
pretty
small
pool,
but
those
would
be
the
people
we'd
really
want
to
please.
A
I
think
the
only
thing
I
would
say
is
like
a
for
maybe
further
research
or
or
further
validation
down
the
road.
We
might
try
and
test
this
with
people
who
have
never
edited
frontmen
or
don't
even
know
what
formatter
is
but
want
to
just
like
change
the
title
of
a
page.
A
A
B
Good
to
know,
yeah,
that's
pretty
much
from
my
side,
so
I
guess
with
category
maturity
scorecard
I'll
start
reaching
out
to
people
and
then
same
thing
with
editing
front
matter.
A
And
I
will
get
working
on
those
jobs
to
be
done
and
hopefully
have
a
successful
group
conversation
tomorrow
and
I'll
be
working
on
just
sort
of
backlog,
refinement
and
stuff
over
the
next
week
on
both
the
handbook
and
static
site.
Editor
projects
so
hopefully
get
some
of
these
issues,
and
some
of
these
things
a
little
more
clearly
defined
for
the
next
few
releases.
So
we'll
kind
of
get
ahead
of
things.
B
A
Yeah,
let
me
look
at
the
calendar
and
put
something
either
late
this
week
or
early
next
week,
or
maybe
we
can
just
use
this
time
next
week
to
chat
about
it
in
more
detail
and
that'll.
Just
give
me
a
deadline,
I'll
try
and
get
them
worked
out,
and
then
I
will
be
scheduling
the
the
journey
mapping
think
big
brainstorming
session.
Finally,
this
week
I
don't.
A
Good
all
right
well,
stop
the
recording
thanks.