►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts
A
Hello:
everyone:
this
is
the
product
and
design
weekly
call
for
the
static
site,
editor
group.
It
is
october
19th
and
let's
dive
right
in
with
the
design
section
michael.
If
you
want
to
just
start
reviewing
all.
B
Right,
okay,
so.
B
So
let
me
prefix
that
with
the
ux
research
stuff,
so
the
past
two
days,
I
just
summarized
the
notes,
and
I
added
that
into
the
issue
and
it's
in
dovetail.
It
hasn't
been
reviewed
by
anyone
yet
so
any
feedback
on
that
would
be
good.
So,
based
off
of
that,
I
started
thinking
about
like
the
next
steps
for
the
static
site
editor
and
one
of
those
things
that
we've
been
talking
about
is
allowing
multiple
edits.
B
So
this
is
the
scenario
of
not
really
diving
into
multiple
pages
edited
yet
but
more
like
oh,
I
need
to
make
multiple
changes
to
the
same
file
and
at
the
moment
you
can't
really
do
that
in
the
stack
site.
B
Editor
and
we've
been
exploring
two
different
flows,
one
flow
where
we
enter
from
the
handbook
and
then
you
go
into
the
stack
site
editor
and
then
you,
you
know,
select
the
right,
merge
request
and
the
other
flow
that
we
were
testing
was
like,
starting
from
the
merge
request,
page
itself
and
then
going
to
static
site
editor,
making
a
change
from
the
solution.
Validation.
I
feel
like
starting
from
the
existing
merge
request.
B
Page
seems
like
a
flow
that
resonated
better
with
people
who
are
more
used
to
to
get
the
flow
of
working
so
where
you
would
have
most
of
your
feedback
and
suggestions
coming
from
the
merge
request,
page
so,
jumping
off
from
that
page
felt
quite
natural,
even
with
the
flow
and
there's
already
a
lot
of
things
in
place
that
we
can
just
jump
on
to
to
like
to
tackle,
to
like
have
like
an
iterative
way
to
allow
people
to
make
multiple
commits
onto
the
same
page
and
yeah
just
yeah.
B
B
Of
like
the
main
thing,
I
saw
from
a
product
way
where
it
kind
of
makes
sense.
If
we
want
to
like
tackle
like
adding
a
commit
message,
handling
multiple
commits
to
one
file,
building
that
foundation
and
then
re-tackling
how
we
might
allow
that
from
the
flow
of
handbook
to
static
site
editor
and
then
switching
the
merge
requests
or
the
spot.
You're
planning
to
save.
To.
A
So
I
have
an
old
issue
that
I
made
when
I
mean
I
agree.
First
of
all,
I
I
saw
the
same
theme
in
the
feedback
and
I
think
we
knew
we
were
going
to
need
to
be
able
to
pick
up
this
flow.
I
agree
with
you
on
the
familiarity
with
that,
the
prototype
that
you
had,
where
you
selected
it
from
the
meatball
menu
and
the
merge
requests
on
the
source
file.
A
I
don't
think
that
it's
the
like.
I
think
it's
a
it's
a
great
mvc,
it's
a
good
iteration
towards
giving
people
that
path
I
do.
I
do
have
a
concern
that
it's
too
many
choices
in
there.
It's
too
many
editors,
but
I
know
that
that's
also
something
we're
thinking
about
growing
with
integrations
and
stuff
too,
like
we
have
the
get
pod
integration.
Similarly,
we
might
have
other
editors
or
other
entry
points
into
ides
or
whatever.
A
So
it's
possible
that
as
that
scales,
we
negate
that
concern
by
actually
having
even
more
choices
and
then
it
just
becomes.
How
can
we
be
so
specific
about
our
feature
that
we
know
that
people
can
be
intentional
about
picking
it
and
they
know
what
to
expect,
and
I
think
that
is
my
other
concern.
What
do
we
call
it
in
that
menu?
I
know
you
were
testing
some
different
words.
A
A
I
had
an
issue
back
before
when
I
was
just
thinking
through
user
stories
and
this
I
think,
falls
into
the
same
ballpark,
so
we
can
reuse
this
issue
I
linked
in
the
agenda,
for
I
think
I
called
it
add
additional
changes
to
an
existing
merge
request
and
there's
like
no
description,
obviously
no
real
requirements,
so
we
can
build
out
from
there
and
maybe
use
that
to
track
changes
and
and
designs
and
iterations.
There.
A
But
I'm
I'm
I'm
supportive
of
that
being
another
iteration
that
we
move
towards.
I
think
the
the
only
other
candidate
in
my
mind
would
be.
A
B
Cool
yeah,
let
me
add
some
words
to
that
later
today.
You
know
sure.
B
So
next
point
is
another
point
that
came
up
in
solution.
Validation
was
like
the
thing
that
has
been
something
we've
been
aware
of,
but
we
haven't
really
tackled
yet
now
that
we
got
the
title
and
the
description
from
the
mr
page
over
to
the
static
site
editor.
The
next
big
thing
I
see
is
like
the
assignee,
because
that's
kind
of
an
obstacle
in
publishing,
because
within
the
handbook
scenario
you
can't
just
just
deploy
your
change
directly
to
the
main
branch
you
have
to
get
someone
to
merge
it
for
you
or.
C
B
Cases
there
are
some
people
who
can
just
merge
directly,
but
in
most
people's
scenario
you
need
someone
to
review
it
first,
and
there
is
an
issue
that
was
created
a
few
months
ago
called
suggest
an
assignee
to
merge,
requests
to
the
static
site
editor,
and
I
think
I'm
going
to
take
some
of
these
points
that
are
raised
here,
as
in
like
thank
you,
john,
for
commenting
about
a
reviewer
roulette
not
being
appropriate
for
the
handbook,
and
I
think
we
have
the
code
owners
files
as
some
stuff
to
look
at
like
that
or
your
manager.
B
But
I
think
this
is
something
that
we
can
like
look
into
for
the
next
round
of
solution.
Validation
like
doubling
down
on
like
how
he
might
do
this
better,
because
I
think
that
would
be
good
for
for
people
to
not
have
to
stress
about.
I
really
want
to
help
with
the
engineering
side
of
this
document,
but
I
don't
have
no
idea
who's,
it's
a
ping.
So
I
think
this
would
be
really
useful
to
start
thinking
about
from
the
stack
site.
Editor
standpoint.
A
Yeah,
I
don't
know
if
you
caught
the
end
or
if
I
did
this
after
I
stopped
recording,
but
I
had
an
interesting
aside
with
one
of
the
the
one
solution:
validation
that
I
was
moderating
and
this
came
up
and
the
the
friction
point
was
there
are
it's
very
specific
to
the
handbook,
but
I
could
imagine
at
a
scale
that
some
of
our
users
may
deploy
sites.
This
could
come
up
where
you
have
potentially
half
a
dozen
a
dozen
code
owners
and
you
display
those
as
avatars
and
names
in
your
selection.
A
A
One
interesting
idea
that
came
from
that
back
and
forth
was
like
what,
if
you
just
had
like
a
random
button
and
you
let
the
program
decide
like
you.
Don't
actually
you
just
say
like
assigned
to
any
of
these
code
owners
and
then
we
could
build
out
at
first.
It
might
be
random,
then
we
could
iterate
and
maybe
it
like,
looks
at
people's
get
lab
status
and
then
find
somebody,
that's
not
like
at
capacity
and
then
assigns
it
to
them.
A
B
B
Scenario
that
sparked
this
this
point,
because
I
was
like
that.
That's
a
really
good
idea
and
I
think
that's
why
I
put
down.
I
don't
know
much
about
reviewer
roulette
because
when
you
said
just
pick,
someone
at
random
that
reminded
me
of
the
roulette
concept
or
like
the
google,
like
I'm
feeling
lucky
kind
of
button.
D
B
Then
it's
just
like
auto
science
but
yeah
yeah
that
that's
that
that
comment
from
you
eric
was
exactly
this
part.
My.
A
C
And
one
thing
I
want
to
mention
too,
with
respect
to
so
obviously
in
iteration
from
an
iteration
perspective,
that's
probably
the
best
one
is
like
random.
That
seems
to
be
the
best
one,
but
another
idea
again
just
getting
into
solutioning
a
little
bit,
but
we
could
also
kind
of
infer
a
little
bit
you
you
mentioned
one
thing
specifically,
which
is
like
you
could
look
at
their
status,
which
would
be
a
great
one
another
one
would
be.
C
We
could
actually
query
how
many
things
are
they
already
assigned
and
you
could
kind
of
rank,
how
many
they're
assigned,
and
then
you
probably
like
the
one
with
the
least
amount
of
assignments
would
likely
be.
You
know
if
that's
a
good
heuristic
that
might
be
a
good
one,
yeah
sure
we
could
come
up
with
other
ones
too,
but
again
the
more
we
can
infer
based
off
data
that
exists.
C
I
think
that
increases
our
chances.
I
could
be
wrong
too,
but
that
definitely
comes
to
mind.
A
Yeah
another
interesting
side
note-
and
I
made
this
in
the
doc,
but
code
owners
is
not
available
in
core,
so
we
really
should
be
thinking
about
who's
going
to
be
using
this,
and
these
are
now
we're
talking
about
paid
customers,
and
this
would
be
our
first
feature
we
built
only
for
paid
customers,
so
we
want
to
make
sure
that
we,
you
know,
make
an
appropriate
split
in
the
logic
we
document
that
appropriately
and
we
think
about
the
use
cases
appropriately.
A
Obviously,
if
you
don't
have
code
owners,
you
may
be
in
that
scenario,
where
you're
just
like
it's
a
smaller
project,
you
can
commit
to
the
main
branch
or
you
know
everybody
has
the
same
permissions,
and
so
this
isn't
as
necessary
and
then
you
know
you
have
code
owners.
So
we
respect
that
flow
by
offering
this
option
in
the
in
the
publish
process.
Before
we
go
too
far
down
like
hitching
our
wagon
to
code
owners,
we
may
want
to
think
just
about
make
that
decision
intentionally
that
this
is
a
paid-only
feature.
A
C
Ahead,
I
was
just
going
to
say,
like
yeah,
I
agree:
we'd
have
to
figure
that
out
like
if
it's
by
design,
it's
only
a
paid
for
feature
or
something,
but
it's
not
hard
to
think
like
through
the
config
file
or
something
we
have.
You
know
there's
a
it's
predefined
and
you
kind
of
already
alluded
to
that
earlier.
Basically,
and
then
code
owners
would
essentially
be
the
override
for
paid.
So
it's
a
way
to
get
both
in
if
that
was
actually
desired.
A
Maybe
we
can
explore
some
options
in
the
design
about
like
what
it
looks
like
if
it's
not
there
or
what
it
looks
like
if
it
doesn't
use
code
owners
versus
it
if
it
changes
at
all,
if
it
does
and
then
yeah
we'll
move
forward,
I
I'm
not
against
having
a
feature
that
is
only
available
to
paid
users
by
the
way,
I
think
if
it
makes
sense
architecturally
and
for
for
the
experience
to
just
use
code
owners
and
then
that's
fine
by
me,.
C
I
don't
want
to
like
stick
on
this
too
long,
because
it
sounds
like
we're
probably
moving
on,
but
from
a
front-end
implementation
standpoint.
You
would
be
identical
as
far
as
how
I'm
kind
of
gut
thinking
the
implementation
would
be
on
the
back
end.
You
either
have
this
config
file
and
it's
just
passed
down.
C
So
I
don't
know
if
that
changes
anything.
But
I
would
I
see
that
as
basically
from
a
gut
check,
standpoint
being
kind
of
more
of
a
back
end
determining
factor
and
then
the
front
end
would
almost
literally
have
no
difference
unless
we
actually
wanted
to
have
some
other
thing
to
in
by
design
differentiate
that
if
that
makes.
B
Cool
sounds
good
and
then
my
last
point
is
just
like
my
focus
for
the
week.
So
I'll
be
spending
and
today
and
tomorrow
kind
of
like
going
through
the
316
issues,
just
to
look
at
anything
that
needs
design
and
just
reviewing
some
of
the
descriptions
and
to
make
sure
that
everything's
there
and
then
go
through
some
of
the
settings
bugs
and
cat
spreadsheet
that
she
sent
out
last
week
to
see
what
needs
design
or
solution
validation.
B
So
I
can
jump
on
that.
So
I
think
I'm
playing
a
little
bit
of
catch-up
but
yeah
I'll
get
there
by
the
end
of
the.
B
A
I'll
type
this
out
afterwards,
but
one
thing
on
that
note
that
I
was
thinking
might
really
be
a
big
help
if
you're,
if
you're
going
through
it.
If
you
have
time
this
week,
is
an
audit
on
the
left,
nav
and
what
features
are
available
that
we
would
be
able
to
turn
off
in
the
settings.
A
So
that's
one
of
the
things
that
we're
going
to
pick
up
in
13.6
and
I
was
just
gonna
group
and
instead
at
the
instance
level,
the
group
level,
the
project
level
and
which
features
should
be
able
to
be
turned
off,
which
ones
can
already
be
turned
off,
because
I
know
there's
some
that
can.
I
think
that
would
be
a
good
starting
place
because
catherine-
and
I
you
we
talked
about
this-
we.
B
A
Last
week,
for
like
a
long
time,
it
was
pushing
two
hours
talking
about
all
this
stuff
and
it
was
really
informative
to
me.
But
one
of
the
takeaways
was
when
working
on
the
settings.
It
might
be
nice
to
have
just
like
an
overall
spreadsheet.
That
captures
sounds
ridiculous,
as
I
say
it,
but
every
setting
that's
available
to
every
every
role
that
way
we
can
find
commonalities
and
identify
ones
that
might
make
sense
to
be.
A
You
know
set
it
once
and
forget
it,
and
it
can
just
kind
of
be
buried
in
the
settings
view
or
something
like
that
and
then
also
like.
If
we
can
find
settings
that
can
be
grouped
by
role
like
only
an
advent
needs
to
do
this
or
only
or
everybody
should
be
able
to
have
access
to
this
setting.
A
As
far
as
I
can
tell-
and
I've
asked
around
a
few
people-
nobody
knows
of
a
full
audit-
that's
been
done.
This
wouldn't
be
something
that
one
person
would
do,
but
by
themselves,
but
it's,
I
think,
an
audit
of
the
left-hand
nav
features
would
be
a
good
start
towards
that,
like
overall
spreadsheet,
of
every
setting.
C
For
what
it's
worth,
I
don't
think
that's
ridiculous
or,
however,
you
frame
that
I
think
that's
a
wise
idea
and
then
another
thing
just
kind
of
jumped.
To
my
mind
is
it's
obviously
sounds
like
a
daunting
task,
but
we
may
be
able
to
leverage
automation
right
to
just
crawl.
C
You
know
basically,
some
kind
of
scroller
crawler
some
kind
of
script
to
like.
If
we
know
where
all
the
places
are,
we
could
probably
just
crawl
just
the
dot-com
page
or
something
you
know,
and
obviously
I
don't
know
it
might
get
a
little
hairy,
but
that
could
at
least
get
you
a
lot
further
than
just
manually
reading
or
something
maybe
maybe
not
enough
to
see.
But.
A
Yes,
I
also
thought
that
there
might
be
somewhere
in
the
code
base.
A
I
don't
know
how
the
settings
are
architected,
but
if
there
was
some
way
we
could
extract
even
on
a
per
feature
level
like
there's
a
chunk
here
and
a
chunk
there,
and
we
can
bring
them
all
in
and
then
just
kind
of
like
clean
them
up
in
a
spreadsheet
reward
them
or
something
like
that.
That
would
be
helpful.
I
think
we,
I
don't
know.
D
A
Yeah,
thank
you.
I
forgot
yeah.
You
had
that
you
had
that
list
already
on
the
left
nav.
So
all
of
this
is
in
service.
For
my
update,
one
of
the
things
I'm
working
on
this
week
is
just
cleaning
up
some
static,
editor
issues,
we're
finding
some
issues
and
cleaning
up
some
epics
that
are
already
done
or
maybe
need
to
be
moved
around
and
then
same
thing
goes
with
the
settings
work.
So
the
one
specifically.
A
In
13.6,
I
want
to
make
sure
sure
those
are
good
to
go,
and
then
there's
some
others
and
those
those
epics
are
in
great
shape.
Already,
I
just
want
to,
you
know,
apply
the
appropriate
labels
so
that
we
can
get
them
on
a
workflow
board,
and
things
like
that.
D
Yeah,
oh,
and
did
you
see
eric
brinkman's
epic,
that
was
related
to
the
whole
toggling
situation.
A
Yeah
yeah,
so
I
think
my
plan
specifically
would
be
to
take
that
one
and
and
tweak
it
and
then
in
the
description,
put
more
of
like
a
checklist
and
then
make
sure
that
all
appropriate
issues
are
either
linked
or
created
to
to
make
sure
that
we
capture
the
intent
for
every
feature
that
can't
be
turned
off
now,
but
should
be
able
to
be
turned
off
with
that.
A
I
think
it
would
probably
be
appropriate
to
ping
whoever
the
product
manager
is
for
each
of
those
features
and
and
say,
like
hey,
we're
about
to
make
a
change
to
your
settings.
Are
you
okay,
with
it
kind
of
thing,
but
I
know
for
a
fact
that
you
know,
based
on
that,
epic,
that
you
mentioned,
there
are
at
least
half
a
dozen
existing
issues
where
people
are
just
been
meaning
to
get
to
this
and
and
haven't
so.
We
can
just
pick
up
those.
D
Yeah
yeah
and
one
thing
related
to
that
a
lot
of
those
issues,
kind
of
do
it
as
a
wholesale
thing.
I
don't
even
know
if
that's
the
word
for
it,
but
the
issue
would
be
like
turning
off
the
security
and
compliance
top
level
item
versus
you
know,
security,
dashboard
and
everything
underneath
are
there.
D
A
Items,
I'd
have
to
personally
I'd
have
to
dig
deeper
into
which
sub
items
might
qualify
for
that.
But
I,
my
instinct,
is
that
the
goal
is
to
declutter
the
left
nav
entirely
so
like
if
I
don't
use
analytics
or
if
I
don't
use
requirements,
I
just
don't
want
to
see
it
and
we
could
maybe
move
towards
a
sub
item
level
activation
and
then
so
start
with
this
round
with
the
top
level
and
then
move
towards
sub
level.
If
people
ask
for
it
or
if
it
seems
appropriate.
A
I'm
trying
to
think
of
a
scenario
specifically
where,
like
maybe
within
a
section
within
a
left,
nav
section,
there's
sub
features
that,
like
might
be
less
used
or.
D
D
There
was
only
one
conflict
that
I
remembered
in
the
past
and
I
think
it
was
resolved
eventually,
but
that
was
turning
off
issues
and
having
labels
disappear.
That
was
resolved
and
I
think
it
doesn't
disappear
anymore,
but
I
just
don't
know
if
there
are
any
other
situations
like
that,
where
they're
kind
of
grouped
together
but
they're
not
necessarily
dependent
like
if
you
turn
off
yeah.
That's
that's.
Basically
the
question.
A
A
A
Not
to
retread
everything
I
talked
about
this
morning,
but
for
the
sake
of
my
updates,
my
goals
for
this
week
are
the
issue
refinement,
like
I
mentioned,
documenting
our
static
site,
editor
re-architecture
proposal
with
enrique
trying
to
get
sure
that
make
sure
that
we
have
both
like
a
product
level
pitch
and
a
technical
proposal,
so
that
we
can
spread
the
word
about
how
important
this
could
be
and
how
valuable
it
could
be
to
more
than
just
our
group.
A
I
think
that
is
it's
very
clear
that
the
architecture
is
going
to
make
it
so
that
the
wysiwyg
editor
would
be
a
component,
that
other
teams
would
be
able
to
use
and
there's
a
lot
of
excitement
about
that.
And
so
I
want
to
make
sure
that
it's
very
clear.
Our
intention
is
very
clear
so
that
we
can
just
send
out
an
epic
and
I
don't
need
to
have
like
a
you
know.
C
A
Presentation
prepared
and
and
all
that
stuff
to
to
go
on
a
road
show,
so
I'm
going
to
work
with
him
on
getting
that
written
and
just
keep
digging
into
all
the
settings
and
nav
research
there's
so
many
videos
and
articles
I
have.
I
have
a
window
with
oh
man.
How
many
tabs
now
are
in
this,
like
25
tabs
open
to
just
like
take
through
issues
and
videos,
and
one
of
them
is
a
one
of
them's
that
wonderful
ux
settings.
Ux
playlist.
A
It's
got
like
I
don't
know,
what's
11
videos
now,
so
that's
like
a
day's
worth
of
days
worth
of
watching
videos
too.
This
is
all
great
and
I'm
gonna
keep
digging
in.
B
Yeah
the
ux
settings
playlist
when
I'm
going
through
all
of
them
and
taking
notes
in
dovetails.
So
if
you
want
like
crib
notes
to
on
them
and
that's
a
good
way
to
see
at
least
the
transcription
and
then
maybe
watch
the
parts
that
you
want
to
double
down
on,
but
yeah
yeah.
B
A
D
A
I
spent
most
not
not.
Today
I
mean
I,
I
had
taken
the
past
couple
mondays
off,
so
I
I
thought
another
one
might
be
overkill,
but
this
weekend
we
had
a
lot
of
fun,
went
to
the
zoo
and
did
a
lot
of
fun
stuff.
So
a
lot
of
family
time.
I
just
had
a
nice
take
out
indian
dinner
indian
food
dinner,
so
that
was
my
special
treat
for
today
and
it
was
very
good.
A
That's
what
they're
tuning
in
for
they're,
really
just
tuning
in
for
that?
Okay,
thanks,
everyone
I'll
stop
the
recording.