►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts
A
All
right,
hello,
everyone.
This
is
the
static
site,
editor
product
and
design
weekly
meeting
for
august
10th
2020,
and
there
were
a
couple
fyi's
before
we
hit
record
I
should
have
mentioned,
but
this
is
a
short
week.
We
have
a
family
and
friends
day
on
friday,
everybody's
encouraged
to
take
it.
If
you
can,
I
will
be,
I
think,
pretty
much.
The
whole
team
will
be
as
well
so
try
and
spend
time
with
your
family
and
friends,
and
it
looks
like
catherine
dropped.
A
A
note,
even
though
I
didn't
see
her
on
the
call
that
there's
a
new
process
for
documenting
actionable
insights.
But
you
have
a
note
down
in
your
agenda,
so
I
assume
you
already
know
about.
A
That
I
I
had
a
few
issues
or
a
few
items.
A
The
first
one
was
just
also
sort
of
an
fyi,
but
we
made
the
decision
today
and
it's
actually
already
made
it
out
to
it's
already
been
merged
already
in
production.
I
believe
to
go
ahead
and
soft
launch
our
stack
site
editor
on
every
page
of
the
handbook,
we're
still
hedging
a
little
bit
with
the
support
for
the
erv
files.
A
Derek
did
wrap
up
the
work
last
week
he's
off
this
week,
though
we
weren't
quite
sure
how
it
was
gonna,
go
on
every
page,
so
enrique
had
the
idea
to
put
it
behind
a
feature
flag,
so
we
can
quickly
toggle
the
support
on
and
off,
rather
than
waiting
for
the
merge,
train,
etc.
So
that's
complete
and
it's,
I
think,
that's
what
we
went
with
so
I
believe
the
handbook
is
fully
supporting
erie
and
fully
yep
the
the
root
level
handbook
open
on
stacks
identity.
A
A
And
we
will
be
discussing
this
I'll,
have
like
a
more
formal
announcement
and
we'll
have
that
group
conversation
I'm
torn
on
whether
I
should
wait
all
the
way
until
the
18th,
but
I
think
it'll
depend
on
if
we
see
any
issues
or
how
many
people
find
the
link
and
bring
it
up
in
slack
but
yeah
big
day,
cool
cool
cool
and
the
other
thing.
Just
to
recap.
From
earlier
in
the
engineering
meeting,
I
mentioned
that
two
bits
of
feedback
came
our
way
over
the
past
few
days.
A
One
of
them
was
on
friday
from
a
gitlab
team
member,
who
is
a
group
manager
on
the
product
team,
and
he
just
dropped
a
note
in
slack
in
case
he
missed
it.
That
was,
it
was
very
encouraging
and
I
think
it
it
encapsulated
pretty
well
something
that
we've
been
trying
to
something
we've
been
trying
to
convey
about
our
target
persona,
which
is
that
it
doesn't
necessarily
have
to
be
somebody
that
doesn't
know
markdown
or
doesn't
know,
get
or
chooses
not
to
to
learn
those
things.
A
A
So
I
think
that
just
reinforces
the
the
use
case
and
the
use-case-driven
value
that
we're
bringing
versus
the
persona
driven
value
that
we
kind
of
started
around.
You
know
the
group
with
like.
Oh,
let's
make
it
easy
for
people
with
less
technical
knowledge,
but
that's
actually
that's
it's
kind
of
a
side
effect,
which
is
a
great
side
effect,
because
we
can
bring
more
people
in
to
collaborate,
but
it's
it's
actually
not
necessarily.
Our
our
goal
is
to
make
something
for
people
with
without
the
technical
knowledge.
Anyway,
we've
covered
this.
A
I
just
thought
it
was
a
great
piece
to
highlight
and
the
other
bit
actually
came
unsolicited
from
a
community
member
by
way
of
an
issue
that
was
created
in
our
backlog,
feature
request
was
brought
up
and
it
ended
up
being
a
duplicate
of
something
we
had
on
our
roadmap,
and
so
I
responded
and
said
this
is
actually
something
working
on
I'm
going
to
close.
It,
but
you
can
track
it
here
and
then
I
just
said
my
email
is
in
my
profile.
A
If
you
want
to
chat
and
they
sent
me
an
email,
so
I
plan
on
following
up
more.
I
think
it
might
be
a
good
interview
candidate,
and
we
can
talk
about
you
know
when
it
might
be
good
to
engage,
but
they
had
some
really
great
feedback
that
that
validated
our
direction.
I
summarized
the
the
whole
or
like
the
primary
message
down
below.
A
I
won't
copy
and
paste
it
again,
but
sure
I
see
the
the
gist
of
it
was
that
this
is
more
of
an
engineer
that
is
capable
of
really
any
kind
of
managing
any
kind
of
site,
but
what
they
wanted
was
the
ability
to
create
a
static
site
instead
of
a
wordpress
hosted
site
for
their
collaborators
to
to
contribute
to
a
web
webpage.
That
was
more
about
news
and
blog
posts
and
stuff
like
that.
A
So,
like
content
that
needs
to
be
refreshed
on
a
regular
basis,
they
didn't
think
that
a
side-by-side,
markdown
preview
would
be
sufficient
for
those
people
who
were
not
familiar
with
git,
which
is
what
we've
heard
also
from
research,
and
what
our
kind
of
instinct
is
but
they're
very
excited
about
the
statistic
editor.
A
They
would,
I
think,
be
very
happy
with
the
direction
we're
headed
and
I
think
we
can
start
considering
that
an
interesting
user
to
test
some
of
our
our
direction
on
the
future.
So
I
was
very
happy
to
see
that
come
through.
I
think
it
came
through
on
friday
and
it
kind
of
felt
like
a
perfect
testimonial
I'll,
get
it
summarized
and
dovetailed.
C
A
The
next
two
are
kind
of
just
questions,
or
you
know
conversation
starters.
We
should
get
the
ball
rolling
on
the
category
maturity
scorecard
in
light
of
making
it
available
to
everybody
on
the
handbook.
I
think
that's
the
last.
That's
the
last
box
to
check
before
we
consider
ourselves
viable
so,
okay,
if
we
can
get
that
going
maybe
next
week
that
would
be
ideal.
A
Okay,
so
I'm
happy
to
help.
I
haven't
done
it.
I
know
you've
been
helping
out
with
one.
We
can
chat
after
afterwards
about
the
actual
tactics,
but
I
think.
A
A
And
then
the
last
thing
I
you,
you
had
a
link
here,
but.
A
I
think
we
should
get
going
on
some
solution:
validation
for
the
editing
of
front
matter
just
to
test
out
our.
I
know
you
had
some
early
concepts
for
that.
Maybe
we'd
start
with
that
or
if
you
want
to
revisit
them
at
all.
C
Yeah
so
I
put
the
issue
link
down
there
for
10
and
I
have
a
comment:
moderated
versus
unmoderated.
So
one
of
the
ideas
that
the
research
team
has
around
like
improving
the
speed
of
getting
solution.
Validation
is
considering
using
unmoderate
research
for
certain
scenarios
and
I
think
the
editing
front
matter
might
be
a
good
candidate
for
an
unmoderated
one,
because.
B
C
C
We
only
have
like
I
see
four
different
potential
solutions
for
it
from
refining
that
within
the
product
within
our
group,
we
can
probably
take
it
down
to
that
one
or
two
and
test
them
against
our
hypothesis,
and
I
think,
because
it's
internal
it
makes
it
internal
with
people
who
are
more
leaning
towards
the
technical
side,
because
it's
editing
front
matter
is
that
I
think
having
as
an
unmoderated
test,
might
be
a
good
candidate,
and
so
I'm
working
with
one
of
the
researchers
to
see
if
we
can
use
it,
use
one
of
the
tools
that
they're
trialing
to
get
some
feedback
on
that
yeah.
C
C
So
I
agree
yeah
and
then
that
that
might
give
us
more
room
to
do
some
of
the
other
solution,
validations
that
we
have
in
the
pipeline
as
well.
A
Yeah,
that's
it
for
me.
You
want
to
take
your
items.
C
And
yeah,
so
one
of
the
things
that
you
kicked
off
the
call
with
was
this
idea
of
actionable
insights
from
research
studies.
So
the
premise
of
that
is
that
when
you
do
either
solution,
validation
or
problem
validation,
there
might
be
some
things
that
we
find
from
those
sessions
that
we
need
to
take
action
on
and
at
the
moment,
there's
no
good
way
of
correlating.
C
Oh,
yes,
we
did
the
research
and
there
were
some
follow
actions
that
we
should
have
taken
of,
and
it's
holding
the
design
team
accountable
to
say,
like
yeah.
We
actually
follow
up
on
stuff,
so
part
of
that
is
highlighting
the
insights
that
are
actionable
or
that
we're
gonna
follow
up
on
in
dovetail
by
prefixing
the
text
actual,
but
also
raising
a
separate
issue
against
it.
C
So,
for
example,
in
our
latest
round
of
solution,
validation
with
the
publishing
flow
editing
and
creating
an
mro
was
generally
well
received,
but
like
associating
it
to
an
existing,
mr
was
a
little
bit.
It
was
hard
for
people
to
use
because,
for
whatever
reasons,
not
enough
context
or
just
mental
models
of
things
being
reversed,
I
think
it's
a
one
that
we
should
follow
up
one
again
with,
like
a
more
focused
one
around
just
associating
a
change
to
an
mr.
C
Mr
is
another
one
that
will
do
for
solution,
validation,
and
I
think
we
already
have
a
few
people
shortlisted
from
the
previous
requests
for
interviews,
so
I'm
gonna
follow
up
with
those
people
probably
to
get
them
scheduled
as
well,
but
maybe
we'll
have
a
separate
quick
session
later
this
week,
you
and
I
eric
to
just
have
a
chat
about
the
upcoming
research
and
kind
of
prioritizing
and
like
seeing
where
we
should
recruit
more
from
our
previous
from
the
publishing
solution
validations.
C
There
were
some
flow
tweaks
and
improvements
that
were
suggested
like
adding
labels
and
adding
commit
messages
to
the
flow,
whether
we
do
them
or
not.
Right
now,
I
think,
what's
the
best
way
to
field
this,
should
I
create
issues
for
each
of
these
things
or
an
issue
for
both
of
these
things
and
then
we'll
like
address
it
later
or.
A
I
would
say
at
your
discretion
if
you
think
they
are
releasable
and
valuable,
that
in
the
spirit
of
iteration,
make
two
issues
and-
and
we
can
you
know
if
they're
small
enough-
we
can
do
them
both
in
the
same
milestone
and
be
done
with
it.
But
in
the
interest
of
keeping
things
small,
maybe
separate
issues
unless
it's
still
unclear
whether
it
could
be
iteratively
delivered
or
something
like.
A
C
Cool
and
then
the
last
point
I
have
is
you
kind
of
segue
nicely
from
stubbing
out
some
of
these
issues
recently.
C
Is
that
in
the
templates
that
we
have
for
creating
issues,
it
always
asks
like
which
persona
does
this
target
and
what
I
realized
that
looking
at
some
of
our
product
marketing
roles
and
personas
that
we've
been
using
so
far,
it's
sometimes
a
little
bit
hard
to
like
pinpoint
the
exact
personas
that
we're
targeting,
for
example,
that
you
mentioned
earlier.
Where
is
someone
well-versed
in
git,
but
also
like
looking
for
an
easy
ways
for
team
members
to
contribute
a
more
lightweight
version
to
contribute
like
document
editors
or
tech
writers
on
a
team?
C
I
know
that
similar
use
cases
in
the
open
source
community,
where
you
want
more
people
to
contribute,
but
you
know
the
barrier
to
like
clone
the
repo,
create
a
branch
and
all
that
stuff
is,
you
know
a
barrier
so
there's
these
other
use
cases
that
exist.
C
So
what
I'm
thinking
about
is
creating
an
issue
around
this
and
perhaps
using
that
as
a
discussion
point
for
yourself,
catherine
and
and
anyone
else
to
contribute
to
like
saying:
should
we
extend
the
existing
personas
that
we
have,
because
some
of
them
are
extensions
or
should
we
create
a
new
persona
around
this?
So
I'm
a
bit
unclear
about
that.
So
I
think,
starting
off
with
the
issue
might
work
there
for
gathering
feedback.
A
Yeah,
I'm
happy
to
contribute
to
an
issue.
I've
actually
had
a
couple
of
discussions
in
the
past
few
weeks
about
the
same
thing
about
how
we
don't
really
have
a
persona,
that's
targeting
or
that
we
are
directly
targeting
and
again
yeah.
I
mean
we're
to
my
comment
earlier:
we're
kind
of
targeting
everybody.
We
want
to
make
it
accessible
for
everybody,
but
we
do
need
some,
some,
maybe
more,
more
direct
references
to
to
personas
so
that
we
know
who
we're
building.
For
I
don't
know
last
I
left
it.
A
A
B
Who
yeah,
who
this
persona
is,
if
it's
kind
of
geared
towards
internal
people,
then
you
might
be
able
to
create
the
persona
based
off
of
a
lot
of
the
research
that
you
already
did
so
a
lot
of
the
people
you
already
talked
to.
If
there
were
any
commonalities
that
you
want
to
pull
out
of
that.
But
if
you
want
to
do
something,
that's
more
geared
towards
an
external
user,
whoever
that
would
be,
then
you
might
want
to
do
another
dedicated
research
study
to
go
into
their
workflow,
their
current
tools,
they're
using
and
things
like
that.
B
A
B
A
Yeah,
I
think,
getting
an
issue
out
there.
I
I
want
to
make
sure
that
we're
not
building
exclusively
for
internal
personas
for
much
longer.
I
mean
I
think
we
really
now
that
we're
in
the
handbook
we
should.
We
should
focus
on
meeting
the
needs
of
external
users
as
well,
and
some
some
proper
research
on
that
I
think,
would
be
very
appropriate
and.
C
A
Assuming
the
conversation
has
come
up
with
design
management,
so
I
can
chat
with
them
about
whether
or
not
they've
explored
having
designer
profiles,
personas,
created
or
researched,
and
what
point
they
are
in
that,
because
I
think
that
could
be
a
similar
extension
of
some
of
our
personas,
where
you
know
they're,
on
they're,
on
similar
teams
but
they're.
Just
like
you
know,
another
role
within
the
team.
A
The
closest
thing
that
I
that
we
have
that
I've
used
on
online
is
the
product
manager,
but
I
forgot
the
name
we
assigned
to
the
product
manager,
but
that's
the
one
I
usually
put
on
the
issue.
C
C
C
Yeah,
that's
pretty
good,
that's
probably
that's
that's
exactly
it.
Catherine
like
I
was
thinking
of
the
job
titles
and
the
tasks
that
people
that
were
trying
to
target
this
static
site
editor
and
I
did
like
a
control
f
and
I
couldn't
find
it
in
our
rows
and
personas.
So
I
was
just
like.
Oh
okay,
it
looks
like
there's
a
gap.
A
Yeah,
I
think
product
manager
gets
somewhere
in
there,
but
for
me
it's
like
copywriter
or
editor,
or
something
like
that.
Where
there's
somebody
that's
very
focused
on
content,
editing,
technical
writer
would
be
a
big
one.
A
I
think
that
we
could
source
internally
because
we
have
a
whole
team
there,
but
there's
you
know
like
we
could
probably
find
some
research
in
marketing
teams
with
you
know,
people
who
run
blogs
like
internal
marketing
teams,
but
I
don't
want
to
skew
too
hard
on
the
marketing
stuff
yet
because
I
think
the
the
needs
of
that
group,
as
we've
seen
with
our
own
marketing
site,
are.
A
C
Cool
and
then
the
last
point
I
snuck
in
there
is
moving
forward,
I'm
gonna
loop
in
the
technical
writers
on
like
designs
earlier.
This
is
something
I
haven't
done
so
far
and
given
the
nature
of
what
we're
trying
to
do,
where
we're
trying
to
abstract
things,
to
not
be
so
technical
or
like
abstracted
away
from
git
terminology,
it's
good
to
have
more
eyes
on
it
because
yeah
even
internally,
we
struggle
to
agree
on
some
words
sometimes
and
yeah.
C
So
I
think
it's
tricky
so
yeah
having
more
eyes
on
that,
will
always
be
useful,
so
yeah
and
that's
off
the
comment
that
was
made
by
susan
attacker,
but
I
think
maria's,
our
technical
writing
counterpart.
So
I'm
gonna
tag
her
more.
A
Yeah
she's
yeah
she's,
our
tech
writer
and
definitely
getting
her
involved
earlier,
the
better
she's,
obviously
very
busy.
We
don't
have
very
many
technical
writers,
but
I'm
sure
I'm
sure,
she'd
love
to
have
him.
A
Great
anything
else,
catherine,
that
we
should
be
thinking
about.
B
A
Me
great
well
yeah,
looking
forward
to
continuing
to
work
on
the
the
mr
publishing
workflow
after
that
research,
which
I
thought
was
really
helpful
and
insightful
and
then
yeah
excited
for
all
the
next
rounds
of.