►
From YouTube: Static Site Editor Group Conversation
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone,
my
name,
is
eric
schurter
and
I'm
the
product
manager
for
the
static
site.
Editor
group
excited
to
host
our
first
group
conversation
today
and
answer
any
questions
you
have
about
our
group.
So
I'll
turn
it
over
to
the
agenda
and
the
first
question
isn't
so
much
a
question
as
a
comment
from
patrick
who
can't
attend
so
I'll
verbalize
it
for
him,
but
he
is,
he
says,
amazing,
work,
y'all!
Congratulations
on
the
awesome
stuff!
That's.
B
A
Rolled
out
recently,
super
excited
to
use
the
static
editor
which,
to
edit
all
the
things,
and
we
are
too
we're
very
excited.
I
think
that's
a
good
segue
to
point
out
also
something
from
the
slides
that
the
static
site
editor
is
available
on
all
the
handbook
pages.
So
maybe
not
everything,
but
all
the
gitlab
handbook
is
available
to
be
or
is
compatible
with
the
static
site.
Editor
now
and
john
is
typing
right
now.
So
when
he's
done,
you
can
let
him
verbalize.
C
Yeah
thanks
eric.
Can
you
explain
some
of
the
formatting
changes
that
comes
up
in
a
merge
request
that
the
static
site
editor
makes
when
you
edit
an
existing
page.
A
Yeah,
so
to
explain
that
I'll
explain
a
little
bit
about
how
our
wysiwyg
editor
works.
It's
a
it's.
An
html
editor
that
formats
the
markdown
content
in
a
way
that
looks
more
familiar.
It's
parsed
in
sort
of
a
plain
git
lab
branded
css.
But
it's
you
know,
headers
are
bigger
than
paragraph
text
and
links
look
like
links
a
lot
easier
to
read.
But
to
do
that,
we
need
to
take
the
markdown
content
and
convert
it
to
html.
A
We
don't
always
write
markdown
syntax
with
those
strict
rules
in
mind.
There's
some
peculiarities
of
markdown
that
allow
you
to
write
unordered
lists,
for
example,
with
multiple
different
types
of
identifiers,
asterix
versus
hyphens.
You
can
write
numbered
lists
by
incrementing
them
one.
Two,
three,
four
five.
A
Just
write
one
one,
one
one
one
and
let
the
generator
parse
out
the
the
final
number.
So
we
have
a
round-trip
process
that
requires
sort
of
standardizing
that
format
and
so,
as
a
result,
if
you
open
a
page
that
has
sort
of
mixed
formatting
or
formatting
for
markdown
that
follows
different
rules
that
are
also
still
valid
and
then
bring
it
into
the
static
site
editor
and
make
a
commit.
It
can
look
a
little
noisy.
We
might
change
some
white
space.
A
When
I
add
a
couple
of
lines
we
might
convert
asterisks
to
hyphens,
and
this
is
all
just
right
now,
based
on
our
gitlab
markdown
style
guide.
But
it's
something
we're
looking
to
expose
in
a
sort
of
configuration
file
for
other
users
who
might
have
different
preferences
for
how
they
write,
markdown
or
or
want
to
extend
it
to
even
different
flavors
of
mark
down
like
cram
down
or
something
like
that.
A
All
right,
so
hopefully
that
answers
your
question
and
helps
you
understand
sort
of.
What's
going
on
behind
the
scenes.
Catherine
has
the
next
question
you
want
to
verbalize
your
question.
D
A
Yeah,
that's
a
great
question
and
something
we're
really
focused
on
right
now,
and
I've
been
in
touch
with
kai
about
when
it's
appropriate
he's
the
product
manager
for
the
web
ide
when
it's
appropriate
to
use
which
tool
and
make
sure
you
know
that's
very
clear
and
we're
working
on
making
that
more
clear,
but
really
what
what
we're
focused
on
right
now
with
the
static
site.
Editor
are
edits
to
a
single
page.
So
that's
one
use
case.
That's
very
much.
A
A
differentiator
between
the
web
ide,
multiple
page
edits,
are
are
much
better
suited
right
now
for
the
web
ide
even
after
we
build
in
support
for
multiple
page
edits
in
the
static
site.
Editor,
though
it's
it's
more
about
editing
content,
so
content
collaboration
within
a
markdown
page
or
within
a
markdown
page.
A
That's
eventually
exported
through
a
static
site
generator,
so
anything
that's
not
a
static
site
is
obviously
a
better
suited
for
the
web
ide
and
as
we
narrow
down
on
these
use
cases,
it's
really
about
collaboration
on
content,
smaller
edits,
more
meaningful
edits
even
to
large
chunks
of
a
page
content
and
then
eventually
we'll
be
supporting
creating
new
pages
and
creating
new
content
like
blog
posts
or
things
like
that
from
the
static
site
editor.
Those
are
all
use
cases
we
want
to
support.
A
What
we
don't
want
to
support
is
probably
easier
to
highlight
the
differentiation,
we're
not
really
looking
to
have
a
template
builder,
so
web
id
would
be
a
great
place
to
go
in
and
actually
set
up
your
page
template
and
and
write
the
whatever
template,
syntax
you're,
using
in
this
case
with
middleman.
You
might
be
writing
some
ruby.
The
web
id
is
also
much
better
suited
to
handle
working
with
like
data
files
and
anything.
That's
not.
You
know
plain
text
code,
anything.
That's
code,
not
plain
text
content.
E
Yes
hi
so
as
editor
of
the
blog,
I've
obviously
paid
close
attention
to
pipeline
duration
over
the
past
few
years
and
I'm
just
curious
looking
at
the
the
chart,
which
shows
some
like
huge
spikes
and
then
some
troughs,
I
I'm
curious
kind
of
what
caused
those
changes
like
you
can
see,
sort
of
january
to
march
2019
things
were
in
a
good
place
and
then
it
spiked
again.
Could
you
talk
about
what
causes
those
variations.
A
Yeah,
I
might
hand
it
over
to
jean
for
specific
technical
discussions,
but
I
believe
these
were
mostly
around
different
different
approaches.
We
took
to
things
like
when
the
merge
train
was
introduced
and
how
we
handle
review
apps,
and
then
these
improvements
that
we've
made
have
happened
over
time.
So
these
would
be
things
where,
like
maybe
we
introduced
the
new
caching
approach
or
we
completed
the
first
phase
of
our
monorepo
restructure,
and
so
that's,
where
you're
seeing
some
of
that
stepping
down.
A
But
it
has
been
a
little
volatile
and
maybe
I
can.
I
can
lean
on
john
or
one
of
the
engineers
to
talk
about
specifics.
C
Yeah,
I
think
eric
started
the
spot
on
there
in
terms
of
the
big
spike.
For
instance,
pre-january
was
in
a
it,
wasn't
a
change
in
terms
of
how
we
deployed
the
review
apps,
and
I
won't
go
into
the
full
technical
details
there,
but
that
caused
quite
a
big
spike,
and
then
we
we
worked
how
we
can
encounter
that
and
we
made
the
the
biggest
challenge
we
have
right
now
is
comparing
what
we
have
today
with
what
we
have
two
years
ago,
because
the
pipeline
is
fundamentally
differently.
C
Structured,
we've
taken
an
approach
of
incremental
deployments
rather
than
full
deployments,
and
we
still
have
lots
of
plans
in
the
pipeline
kind
of
pun
intended
to
make
it
faster
to
speak.
To
a
few
of
those,
we
want
to
have
a
separate
pipelines
for
both
the
marketing
site
and
the
handbook.
Right
now,
when
the
site
gets
deployed
to
production,
it
still
builds
the
full
site,
but
what
we
we
want
to
get
is,
if
you
make
a
change,
the
blog
that
it
only
deploys.
C
The
only
runs
the
pipeline
really
relevant
to
the
blog
or,
if
you
make
a
change
in
a
handbook
only
relevant
to
the
handbook,
so
that
would
reduce
the
pipeline
times.
Then
we're
also
in
looking
into
a
new
static
site
generator
so
currently
we're
using
middleman
and
we've
been
using
that
for
the
past
seven
years
on
this
project.
But
it's
reached
a
point
where,
at
the
scale
of
what
the
handbook
is
at
right
now,
I
think
there's
over
8
000
pages
in
the
handbook.
C
It's
taken
quite
a
lot
of
time
to
to
generate
that,
and
so
there's
a
product,
a
project
that
was
started
by
the
documentation
team
at
algolia
called
front
man
which
is
not
like
a
spiritual
successor
to
middle
man.
It's
it's
inspired
by
middlemen
and
they
used
middlemen
before
and
then
they
created
an
internal
project
to
replace
middlemen
and
it's
it's
not
exactly
a
dropping
replacement
or
man,
and
but
it
should.
C
It
supports
most
of
the
features
out
of
the
box.
That
middleman
does-
and
we
actually
have
plans
in
13.4
to
to
try
and
convert
our
handbook
to
using
frontman,
which
we
expect
will
give
us
it's
it's
unknown.
The
the
performance
improvement
we'll
see,
but
there's
a
in
in
some
of
the
tests
that
the
team
have
done
they've
seen
up
to
500
improvement
in
both
times.
So
we're
we're
quite
hopeful
that
that
will
give
us
some
big
performance
jumps
as
well.
A
We've
been
working
with
the
algolia
team
directly
to
we're
actually
one
of
their
first
large
use
cases
they
just
open
sourced
it
and
it's
kind
of
an
alpha
release,
so
we're
testing
it
out
with
them
and
hopefully
can
contribute
back
to
the
project
and
help
them
drive
it
forward,
because
it's
it's
very
exciting
they're
seeing
build
times
that
are
much
more
in
line
with
the
the
modern
static
site,
generator
projects
that
where
you,
where
you
can
see
just
like
a
a
couple
seconds
to
generate
a
page
and
versus
you
know
a
couple
minutes
on
middleman,
so
we're
very
excited.
A
Yeah,
of
course,
jim's
got
the
next
question.
Verbalization
all.
F
Right
so
I'm
in
I'm
on
the
sales
team.
I'm
not
sure
this
is
a
valid
use
case.
But
when
I
hear
collaboration,
what
I
love
about
google
docs
is
we
can
concurrently
collaborate.
So
I
don't
know
if
that's
a
valid
use
case
for
what
you
all
are
looking
to
do.
So
maybe
one
you
could
explain,
is
it
a
valid
or
not?
And
then,
if
it
is,
you
know
what
your
thoughts
are
around
time
frames.
A
Yeah,
so
the
engineers
on
my
team
on
the
call
will
maybe
kick
me
for
saying
that
it
is
a
valid
use
case,
because
we
haven't
really
discussed
what
that
would
look
like
and
we're
not
architected
for
it
right
now.
So
it's
a
little
further
down
the
road,
but
it
is
it's
a
very
valid
use
case
and
I
think
something
that
will
come
up
more
as
we
as
we
gain
users
on
the
static
site,
editor
and,
as
we
see
more
types
of
projects,
adopt
the
editor
itself
and
the
editing
workflow.
A
And
I
know
this
is
a
an
answer
to
a
question
a
little
further
down,
but
we're
really
trying
to
bring
in
different
personas
and
collaborate
across
personas
too.
So
we're
looking
at
the
potential
down
the
road
for
an
editor
that
can
be
opened
up.
You
know
in
in
a
more
of
a
collaborative
session
for
concurrent
edits
and
that's
a
challenge
with
it
being
get
backed,
because
ultimately,
one
person
has
to
write
the
commit
or
you
know,
you're
gonna
get
conflicts,
but
I
think
there's
probably
a
solution
there.
It's
not
likely
to
come.
A
G
Yeah,
so
I
see
the
adding
images
and
the
stacks
to
editor
is
part
of
the
mvc
divideable
plan.
It's
really
exciting.
How
do
you
see
that
working
and
are
users
can
be
able
to
size
images
in
the
interface.
A
Yeah,
our
mvc
for
the
image
feature
is
in
progress
and
we're
working
on
that
right
now
we
have
the
work
actually
completed
where
you
can
upload
the
image
to
the
static
site.
Editor
it's
on
hold
for
actually
delivering
until
we
can
deliver
a
configuration
file,
so
you
can
tell
it
where
to
put
the
image
after
you
upload
it,
and
so
we
want
to
configure
that
and
make
that
something,
that's
flexible
across
the
different
types
of
projects
that
this
could
be
used
even.
B
A
The
handbook
that
is
a
challenge
so
once
we
get
that
in
place,
we
have
some
thoughts
down
the
road
and
sort
of
our
complete
maturity
plan
around
handling
media
and
and
certainly
optimizing
images
as
you
upload
them
so
running
them
through,
like
a
ping
compression
or
or
relevant,
for
whatever
file
type
you
upload
and
making
sure
that
you
have
alt
tags
and
stuff
assigned,
but
then
yeah
providing
a
size
would
be
right
in
there.
A
We've
also
had
some
early
thoughts
about
what
it
would
look
like
to
provide
an
asset
library
down
the
road,
very,
very
lightweight,
we're
not
looking
at
a
digital
asset
management
platform
here,
but
we
probably
find
an
opportunity
to
to
surface
previously
uploaded
files
and
file
assets
that
are
already
in
the
project
and
let
you
easily
add
them
into
your
into
your
page.
Using
the
static
site,
editor.
A
Yeah
christy
you've
got
the
next
one
yeah
yeah.
B
So
I
would
like
to
hear
you
talk
more
about
kind
of
how
you're
thinking
about
thinking
about
static
site
editor
in
that
context
of
expanding
usage.
A
Yeah,
absolutely
that's
our
goal,
so
our
group
was
founded
earlier
or
late
last
year,
but
I
was
hired
in
january
to
and
our
mission
has
always
been
to
to
reach
a
new
audience,
a
new
group
of
personas
for
for
gitlab
to
expand
that
collaboration
pool
because
it's
it's
clear
from
talking
with
our
users
and
just
in
in
general,
understanding
the
the
the
unders
the
the
amount
of
previous
knowledge.
You
need
to
come
into
a
get
lab
environment
with
to
write,
markdown
and
contribute
to
a
project.
A
You
have
to
understand
markdown,
syntax
and
sometimes
even
the
templating
language,
behind
the
static
site
generator
and,
of
course,
I'm
just
talking
about
static
sites,
but
the
collaboration
on
those
is
it's
continually
validated
by
talking
with
internal
users
and
customers
that
that
there,
those
barriers
are
not
easy
to
easily
overcome,
and
so
the
personas
that
we're
really
trying
to
reach
similar
to
design
management,
bringing
in
new
users
that
that
wouldn't
necessarily
have
found
a
home
in
gitlab
and
and
getting
them
comfortable,
using
tools
that
abstract
away
some
of
those
things,
but
still
are
rooted
in
the
the
foundation
of
git
and
our
platform
and
commits
and
branches.
A
And
all
the
same,
you
know
terminology
or
you
know
all
the
same
concepts
are
there,
but
maybe
the
terminology
we
use
is
a
little
bit
different.
How
we
position
things
is
a
little
bit
different.
We
make
some
assumptions
on
the
behalf
of
the
user
in
this
case,
with
our
static
site
editor
right
now.
The
mvc
is
just
like
one.
One
click
submit
an
mr,
and
you
know
it's
going
to
get
a
default
description
and
we're
working
on
making
that
more
flexible
and
more
sustainable.
A
Where
you
can,
you
know,
provide
a
merge
request,
description
in
the
static
site
editor,
but
finding
ways
to
surface
that,
where
it's
it's
more
accessible
and
more
more
familiar
is,
is
our
main
goal,
so
our
secondary
goal,
maybe
even
main
goal.
If
you
really
think
about
it,
is
though
that
is,
is
that
everyone
can
contribute
and
everyone
wants
to
contribute
using
the
tool.
A
So
what
I
get
really
excited
about
is
when
I
hear
from
engineers
or
people
that
do
know
markdown,
that
they
would
actually
prefer
to
use
the
static
site
editor
for
for
some
types
of
edits.
We
got
some
feedback
just
the
other
day
from
an
executive.
That
said,
you
know
we
I
jumped
in,
and
just
I
just
needed
to
change
like
one
word
and
it
took
one
minute
and
it
was
perfect.
It
was
great.
A
It
was
a
perfect
use
case
for
that,
so
collaboration
when
I
talk
about
different
personas
is
really
it's
it's
hard
to
nail
down
what
that
persona
is,
and
that's
that's
a
challenge
for
me
as
a
product
manager,
because
I
want
everybody
to
be
able
to
use
it,
but
it
is.
It
is
really
around
those
those
underserved
personas
in
get
lab
right
now.
B
I
love
hearing
you
talk
about
terminology
because
I
do
think
that's
a
real
problem
that
we
have.
We
do
have,
I
think,
as
a
product
and
expectation
that
someone
is
coming
in
and
understanding
the
fundamentals
of
git
and
source
code
management
and
simple
terminology,
changes
that
are
based
more
in
how
people
talk
in
the
real
world
outside
of
git
could
make
such
a
huge
difference,
and
it's
such
a
small
technical
change
that
could
have
a
really
meaningful
impact.
So
what
do
you
think.
A
Yeah
yeah,
thank
you,
yeah
and,
and
our
ux
designer
michael
who's
in
australia
is
not
a
call,
but
he
could
speak
more
to
that
about
how
we're
looking
to
add
some
layers
of
abstraction
and
sort
of
simplify
the
flow
and
they've
done
some.
The
web
ide
team
has
done
a
great
job
in
paving
the
way
with
this
research
and
finding
ways
to
streamline
the
the
merge
request
process
from
the
web
ide.
A
The
other
thing
I'll
say
about
that
is
we're
really
really
interested
in
not
just
bringing
new
users
in,
but
just
finding
a
way
to
add
a
level
of
cohesion
between
features
in
gitlab
once
you're
there,
because
the
nature
of
a
static
site
is
that
it
needs
it
needs
to
be
configured,
it
needs
to
be
generated
using
a
pipeline,
it
needs
to
be
hosted
and
obviously
there
needs
to
be.
A
You
know
source
code,
storage
and
management
there
it's
it's
sort
of
by
nature,
a
multi-stage
feature,
and
so
we're
trying
to
trying
to
find
a
way
in
the
near
term
to
to
pull
those
things
in
and
make
a
more
cohesive
experience
for
the
for
those
collaborators
where
they're
not
necessarily
jumping
around.
They
don't
have
to
know
that
they're
using
things
that
are
related
to
configure
or
using
things
that
are
in
you
know,
release
management
but
they're
they're,
just
focused
on
getting
the
content
edit
made
and
go
live.
A
Rebecca
you've
got
a
sub
question
there
a
feature
where
we
don't
run
ci
and
content
updates.
I
think
we
would.
E
E
Obviously,
the
pipeline
speed
is
a
big
part
of
that,
but
pipeline
by
reliability
comes
into
play
a
lot
because
the
pipeline
fails
or
something
goes
wrong
with
a
merged
train,
and
then
people
are
lost
because
they
don't
know
if
it's
something
they
did
or
something
that's
going
wrong
on
the
production
side,
and
my
understanding
is,
if
you
build
a
kind
of
safe
environment,
to
make
updates
where
you
can't
possibly
break
something
by
just
fixing
a
typo
or
adding
a
blog
post
or
whatever
that
maybe
ci
doesn't
have
a
role
to
play
in
those
updates.
E
So
I
was
wondering
if
that's
you
envision
some
future
in
which
we
just
don't.
We
separate
content
updates
from
development
updates.
A
A
I
think
we
will
always
be
reliant
on
the
static
site
generator
to
be
triggered
from
a
ci
pipeline,
so
we
will
need
to
find
a
way
to
abstract
that,
as
I
was
mentioning
before
and
say,
you
know,
you're
publishing
or
you're
saving
a
draft
or
something
like
that
that
that
will
trigger
the
build,
and
hopefully
our
performance
improvements
and
and
for
those
that
you
know
when
we,
when
we
eventually
support
other
static
site
generators
for
those
that
don't
have
the
same
performance
challenges
and
can
live
reload
and
do
incremental,
builds
and
things
like
that.
A
If
that
build
only
takes
15
seconds,
we
can
leverage
other
performance
improvements
and
and
and
streamline
that
process.
I
think
you
also
mentioned
pipeline
errors,
which
is
an
important
one,
so
surfacing
errors
or
like
content,
linting
or
finding
ways
to
to
show
warnings
about
content
either
either
before
the
commit
has
been
made.
Or
you
know
when
the
pipeline
is
run.
Finding
a
way
to
surface
that
that
error
in
a
more
accessible
and
friendly
way
is,
is
one
of
the
challenges
we're
looking
to
take
on.
E
Yeah
well
so
I
guess,
if
you're
not
building
out
the
front
matter
yourself,
the
kind
of
room
in
which
to
make
mistakes
is
is
reduced
because.
E
That's
the
cause
of
a
lot
of
of
the
reasons
we
see
broken
pipelines
right
now,.
A
Yeah
and
I'm
glad
you
brought
up
front
matter,
actually
we're
we're
beginning
investigation
right
now.
I
think
it's
linked
in
the
in
the
presentation,
but
we're
we're
working
on
technical
implementation,
details
for
editing
front
matter
within
the
static
site
editor.
So
we
we
imagine
the
editor,
you
don't
see
the
front
matter
it
you
can't
accidentally
edit
it.
You
can't
change
a
comma
or
forget
to
put
a
semicolon
or
a
colon
or
whatever
you
know,
to
break
the
pipeline.
You
can't
even
hopefully
someday
enter
an
invalid
option.
A
You
know
in
a
select
field
that
has
predefined
options
for
templates,
for
example,
so
we're
looking
at
a
way
to
to
surface
the
editing
of
that
front
matter
in
a
more
familiar
form
field
way.
You
know
a
manner
that
is
more
familiar
to
somebody
who
might
be
submitting
a
form
or
or
changing
settings
within
the
gitlab
product
itself,
and
then
the
engineers
of
the
project
that
people
are
configuring
can
can
decide
whether
the
front
matter
is
a
toggle.
True
false,
like
a
switch
or
a
select.
A
C
I
think
the
short
short
to
medium
term-
probably
not
where
I
do
see
us
having
or
the
ability
to
gain
a
lot
of
efficiency,
is
if
we
can
detect
the
type
of
files
or
the
area
of
of
the
site
being
updated,
we
can
run
specific
pipelines
that
are
more
tailored
to
just
that
it
so,
for
instance,
right
now,
if
you
just
update
the
documentation
in
the
gitlab
product,
it
runs
a
pipeline
job
specific
just
to
the
documentation,
and
we
can.
We
can
start
tailoring
the
the
pipelines
based
on
the
content
updates
being
made.
C
The
one
challenge
you
have
with
static
site
that
is
backed
by
markdown
source
files,
for
instance,
is
that
content
becomes
functionality.
So,
for
instance,
when
you
change
a
heading,
you
potentially
change
the
deep
link
to
a
page
and
right
now,
one
of
the
the
jobs
that
we
that
we're
running
or
actually
about
to
introduce
is
a
url
linter
that
make
sure
that
you're
not
introducing
broken
links
with
content
up
through
content
updates.
C
So,
there's
a
there's
a
balanced
strike
between
the
safety
net
of
of
having
these
lending
jobs
to
ensure
that
the
correct
output
versus
the
speed
and
efficiency
of
making
a
small
typo
fix
and
that's
a
tricky
balance
to
make.
But
I
think
in
our
specific
use
case
of
gitlab's
handbook
and
and
even
the
marketing
website,
there's
a
lot
of
efficiency.
We
can
still
gain
by
having
targeted
specific
jobs
run
based
on
the
content
updates.
A
So
we're
at
time,
but
I
want
to
real
quickly
get
to
mark's
question
because
it's
very
important
and
I'll
verbalize
it
for
you,
because
it's
you
said
you're
in
a
noisy
environment
are
the
new
capabilities
available
to
our
self-hosted
customers,
and
can
I
share
the
slide
deck
with
them?
Yes,
and
yes,
though,
the
handbook
pipeline
improvements
won't
be
relevant
to
them
feel
free
to
share
the
slide
deck
with
them.
It
is
available
for
self-hosted
customers,
the
it's
easily
accessible
in
the
new
project
templates.
A
There's
a
middleman
template
with
static
site
editor,
that's
how
you
can
configure
your
first
project
and
then
there's
a
way
to
actually
you
can
kind
of
just
reverse
engineer
that
and
use
it
for
any
project.
That's
middleman
based-
and
I
think,
we're
well
over
time
thanks
everybody
for
the
questions,
and
I
hope
we
get
to
do
this
again.
Sometime
soon,.